Re: mss.c pcm fix to ' attach returned 6 ' load failure for v5.x acpi and up

John,

The verbose dmesg doesn't tell you enough.  What was needed was debug 
writes in the pnp and non pnp  mss.c probe routines that displayed the 
parent device id and the probed device id.  That solved it because there 
you could see the acpi parent calling the non-pnp isa mss probe routine 
(mss_probe) which would _accept_ the probe, wrongly, on a few various 
attempts, only to have the non pnp mss_attach fail for lack of resources.

I haven't looked into the newbus logic enough to know for sure but my hunch 
is that the current mss.c call to detect pnp and so avoid to use the non 
pnp probe code (isa_get_logicalid) didn't get mapped through the 
acpi_isa_xxx but instead the isa routine directly-- which returned a zero 
in the context of an ACPI parent bus-- signaling not-a-pnp device -- while 
the acpi version would not have done.  Hence the directive in the manual to 
use the ISA_PNP_PROBE even on non-PNP probe routines.

The environment is a Dell Optiplex, using the Crystal Semiconductor (CSC) 
CS4236B chip.   There are many unresolved postings for 'attach returns 6' 
and pcm that popped up -- with no solution posted when acpi was 
introduced.   So this is my cut at it.  At least it boots properly with 
acpi now and loads the driver at pcm0 instead of pcm3.

The real problem is one I'm still trying to solve, the mappings for the 
mixer for the CS423X chip do not map the ADCs properly so there is no way 
to connect audio on either the line - in or mic ports to the system either 
for loop-through to line out or digitizing.

In the process I've noted the 4236B chip in its (currently unsupported) 
mode 3 allows for different sample rates for playback and digitizing, and 
actually implements an input mixer instead of a simple input selector.  So 
I'm struggling to add support for that in the mss.c driver as I don't want 
the digitizing sample rate to have anything to do with the playback sample 
rate.

I'm still new to *bsd and *nix, but it seems to me that the number of chips 
supported in the mss.c driver is challengingly high.

Harry


At 11:45 AM 7/11/2005 -0400, John Baldwin wrote:
>On Monday 11 July 2005 11:15 am, Harry Coin wrote:
> > The architecture / driver manual has this item:
> >
> > "That means that absolutely every driver, even the ones not supporting any
> > PnP devices must call ISA_PNP_PROBE(), at least with an empty PnP ID table
> > to return failure on unknown PnP
> > devices."
> > (http://www.google.com/search?num=100&hl=en&lr=&newwindow=1&q=freebsd+archi
> >tect+isa+driver)
> >
> > However in mss.c, routine mss_probe we have in the non pnp device detection
> > routine
> >
> > if (isa_get_logicalid(dev)) return ENXIO;
> >
> > which causes the acpi driver to fail to attach multiple times, and to
> > ratchet up x in the pcmx device before giving up.  Often this leads to the
> > isa routine not calling the pnp version of the probe routine and the whole
> > pcm load fails or loads the first and only sound driver on a pcm number
> > like 3 or 6.  Booting without ACPI gives normal results.
> >
> > The fix in mss.c is:
> >
> > static struct isa_pnp_id mss_ids[] = {
> >          {0}
> > };
> >
> > static int
> > mss_probe(device_t dev)
> > {
> >          u_char tmp, tmpx;
> >          int flags, irq, drq, result = ENXIO, setres = 0;
> >          struct mss_info *mss;
> >          result = ISA_PNP_PROBE(device_get_parent(dev), dev, mss_ids);
> >          if (result!=ENOENT) return ENXIO; /* only continue if the device
> > is not pnp */
> >          /* old way- not so good for ACPI: if (isa_get_logicalid(dev))
> > return ENXIO; */
> >
> > Sincerely,
> >
> > Harry Coin
>
>If this is broken then there are a lot of drivers that need fixing.  It 
>sounds
>like ACPI needs fixing instead.  I don't see why pcm's unit number would go
>up, however, as a device reverts back to 'unknown' with a unit of -1 when a
>probe() function fails.  Can you provide more details such as a verbose dmesg
>for both the ACPI and non-ACPI cases without your change?
>
>--
>John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
>"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org