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

From: Harry Coin <harrycoin_at_qconline.com>
Date: Mon, 11 Jul 2005 16:20:49 -0500
John,

1) Indeed the mss driver just ignores the further logical devices the chip 
offers -- which is most likely the right thing to do.
Logical device 0 is the WSS codec, Synthesizer, and alternate Sound Blaster 
pro interface.  Handled by MSS.c
Logical device 1 is a game port.  2 is a 'master chip control' device 
(defaults all are ok I think).  3 is an MPU-401 midi, 4 (not enabled) is a 
CD Rom controller, 5 (not enabled) is a modem.  The data sheet for the 
CS4236B is available online.  I'll send it as a private attachment in an email.

To be tidy, the mss.c controller should 'talk to' a device for the 'master 
chip controller' to be sure sound related bits are set the way WSS needs 
them to be set.  The power up defaults are ok so far as I can tell.  I'm 
not sure where to read to understand how to program a 'multifunction' chip 
when several of the on chip logical devices have dependencies on a 
'separate' chip control device.   To be very tidy, the device for the 
master chip controller should be up and running before the attach routines 
of any of its subordinate functions is called, those routines would then 
send setup commands to the master chip control device. Don't have a clue 
how to get that done.

2) Be advised that the mss driver as shipped with ACPI turned off puts 
internally generated sounds to the line-out port with no problems.  (line 
in and mic in are not processed, but that's another story).

3) Give me a clue or a doc ref about how to apply the RCS / diff patch you 
sent me.

4)  See http://www.n4comm.com/gxa.acpidump  and 
http://www.n4comm.com/gxa.dsdt per your request

At 04:26 PM 7/11/2005 -0400, John Baldwin wrote:
>On Monday 11 July 2005 03:03 pm, Harry Coin wrote:
> > John,
> >
> > Here are the results you asked for.  You will seein the acpi boot the
> > isa_get_logicalid(dev) returns 0 for a probe call to the non-pnp routine
> > mss_probe
> >
> > dmesg excerpt ...
> > mss_probe: bus acpi0 is probing device pcm0
> > mss_probe: isa_get_logicalid() returned 0!
> > mss_probe: no address given, try 0x530
> > mss_detect - chip revision 0x0a
> > mss_detect() - Detected CS4236
> > pcm0: <CS4236> port 0x530-0x537 on acpi0
> > device_attach: pcm0 attach returned 6
> > mss_probe: bus acpi0 is probing device pcm1
> > ...
> >
> > Here are the changes I made for debugging output to the two probe routines
> > in mss.c
> >
> > static int
> > mss_probe(device_t dev)
> > {
> >          u_char tmp, tmpx;
> >          int flags, irq, drq, result = ENXIO, setres = 0;
> >          struct mss_info *mss;
> > printf("mss_probe: bus %s is probing device
> > %s\n",device_get_nameunit(device_get_parent(dev)),device_get_nameunit(dev))
> >; //      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;
> > printf("mss_probe: isa_get_logicalid() returned 0!\n");
> > ....
>
>Ok, let's do this one step at a time.  I'll give you a patch for mss.c to try
>to get some more information.  It also looks like your soundcard creates 4
>different devices (Game, MPU, etc.) so it may be that mss is not handling
>your card correctly when it sees all the devices.
>
>Also, can you upload your acpidump somewhere and provide a URL?  I'm curious
>if you have ACPI devices like thermal zones that don't have _HID's and only
>have _CIDs.  In fact, here's a patch to fix acpi_get_logicalid() in that
>case.  Give this a try first and let me know if it fixes it.
>
>Index: acpi.c
>===================================================================
>RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v
>retrieving revision 1.214
>diff -u -r1.214 acpi.c
>--- acpi.c      3 Jun 2005 20:12:12 -0000       1.214
>+++ acpi.c      11 Jul 2005 20:23:14 -0000
>_at__at_ -1138,6 +1138,7 _at__at_
>      ACPI_HANDLE                h;
>      ACPI_STATUS                error;
>      u_int32_t          pnpid;
>+    int                        i;
>
>      ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
>
>_at__at_ -1153,8 +1154,24 _at__at_
>         goto out;
>      devinfo = (ACPI_DEVICE_INFO *)buf.Pointer;
>
>-    if ((devinfo->Valid & ACPI_VALID_HID) != 0)
>+    if ((devinfo->Valid & ACPI_VALID_HID) != 0) {
>         pnpid = PNP_EISAID(devinfo->HardwareId.Value);
>+       goto out;
>+    }
>+
>+    /*
>+     * If we don't have a HID but do have at least one CID, return the first
>+     * CID.  This is so that ISA drivers that use isa_get_logicalid() to
>+     * determine if a device is a PnP device or not will work correctly.
>+     */
>+    if ((devinfo->Valid & ACPI_VALID_CID) != 0) {
>+       for (i = 0; i < devinfo->CompatibilityId.Count; i++) {
>+           if (strncmp(devinfo->CompatibilityId.Id[i].Value, "PNP", 3) != 0)
>+               continue;
>+           pnpid = PNP_EISAID(devinfo->CompatibilityId.Id[i].Value);
>+           goto out;
>+       }
>+    }
>
>  out:
>      if (buf.Pointer != NULL)
>
>
>--
>John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
>"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
Received on Mon Jul 11 2005 - 19:21:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC