Re: Issues w/ Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG

[Alnie <memobook80@comcast.net>]

On 03/09/2015 09:00 AM, Takashi Iwai wrote:
> At Mon, 09 Mar 2015 08:22:34 -0700,
> Alnie wrote:
>>
>> On 03/07/2015 10:06 AM, Alnie wrote:
>>> On 03/07/2015 08:32 AM, Takashi Iwai wrote:
>>>> At Sat, 07 Mar 2015 08:28:29 -0800,
>>>> Alnie wrote:
>>>>>
>>>>> On 03/06/2015 11:56 PM, Takashi Iwai wrote:
>>>>>> At Fri, 06 Mar 2015 15:31:32 -0800,
>>>>>> Alnie wrote:
>>>>>>>
>>>>>>> On 03/04/2015 01:35 AM, Takashi Iwai wrote:
>>>>>>>> At Wed, 04 Mar 2015 01:01:32 -0800,
>>>>>>>> Alnie wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03/04/2015 12:00 AM, Takashi Iwai wrote:
>>>>>>>>>> At Tue, 03 Mar 2015 18:12:31 -0800,
>>>>>>>>>> Alnie wrote:
>>>>>>>>>>>
>>>>>>>>>>>> My suggestion isn't about a compile option but that you add
>>>>>>>>>>>> some debug
>>>>>>>>>>>> printk() calls manually around some codes.  We need to know
>>>>>>>>>>>> the value
>>>>>>>>>>>> written and read by azx_write*() and azx_read*() calls.
>>>>>>>>>>>> Especially
>>>>>>>>>>>> the value read in pci_azx_read*() is more interesting. You can
>>>>>>>>>>>> try to
>>>>>>>>>>>> modify sound/pci/hda/hda_intel.c and add a printk() to each
>>>>>>>>>>>> pci_azx_read*() function for printing the value to be returned.
>>>>>>>>>>>> Beware that this will likely flood many messages, so just try
>>>>>>>>>>>> once.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Takashi
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I can not find any reference to pci_azx_read in hda_intel.c
>>>>>>>>>>
>>>>>>>>>> You must be using a too old kernel, then.  Please use the latest
>>>>>>>>>> kernel for debugging.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Takashi
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok. I now have latest kernel.
>>>>>>>>>
>>>>>>>>> Here is a small portion...
>>>>>>>>>
>>>>>>>>> /* PCI register access. */
>>>>>>>>> static void pci_azx_writel(u32 value, u32 __iomem *addr)
>>>>>>>>> {
>>>>>>>>>      writel(value, addr);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> static u32 pci_azx_readl(u32 __iomem *addr)
>>>>>>>>> {
>>>>>>>>>      return readl(addr);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Can you show me how I can properly place printk without breaking
>>>>>>>>> things
>>>>>>>>> and produce relevant messages?
>>>>>>>>
>>>>>>>> Something like:
>>>>>>>>
>>>>>>>> static u32 pci_azx_readl(u32 __iomem *addr)
>>>>>>>> {
>>>>>>>>      u32 val = readl(addr);
>>>>>>>>      pr_info("XXX readl %p %x\n", addr, val);
>>>>>>>>      return val;
>>>>>>>> }
>>>>>>>>
>>>>>>>> But since there are quite lots of accesses, it might be safer to use
>>>>>>>> the ratelimited version.  Use like the following:
>>>>>>>>      pr_info_ratelimited("XXX readl %p %x\n", addr, val);
>>>>>>>>
>>>>>>>> Also there are variants pci_azx_readw() and _readb().
>>>>>>>>
>>>>>>>>
>>>>>>>> Takashi
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ok, I was only able to guess through the code for the read values. If
>>>>>>> you need write information too please show me how.
>>>>>>> here are the mods I made...
>>>>>>>
>>>>>>> /* PCI register access. */
>>>>>>> static void pci_azx_writel(u32 value, u32 __iomem *addr)
>>>>>>> {
>>>>>>>      writel(value, addr);
>>>>>>> }
>>>>>>>
>>>>>>> static u32 pci_azx_readl(u32 __iomem *addr)
>>>>>>> {
>>>>>>>         u32 val = readl(addr);
>>>>>>>         pr_info_ratelimited("XXX readl %p %x\n", addr, val);
>>>>>>>         return val;
>>>>>>> }
>>>>>>>
>>>>>>> static void pci_azx_writew(u16 value, u16 __iomem *addr)
>>>>>>> {
>>>>>>>      writew(value, addr);
>>>>>>> }
>>>>>>>
>>>>>>> static u16 pci_azx_readw(u16 __iomem *addr)
>>>>>>> {
>>>>>>>      u16 val = readw(addr);
>>>>>>>      pr_info_ratelimited("XXX readw %p %x\n", addr, val);
>>>>>>>      return val;
>>>>>>> }
>>>>>>>
>>>>>>> static void pci_azx_writeb(u8 value, u8 __iomem *addr)
>>>>>>> {
>>>>>>>      writeb(value, addr);
>>>>>>> }
>>>>>>>
>>>>>>> static u8 pci_azx_readb(u8 __iomem *addr)
>>>>>>> {
>>>>>>>      u8 val = readb(addr);
>>>>>>>      pr_info_ratelimited("XXX readb %p %x\n", addr, val);
>>>>>>>      return val;
>>>>>>> }
>>>>>>>
>>>>>>> and i was able to produce this...
>>>>>>>
>>>>>>> dmesg | grep -i read
>>>>>>> [    0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to
>>>>>>> read a pcr value
>>>>>>> [    0.769674] Write protecting the kernel read-only data: 12288k
>>>>>>> [    1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
>>>>>>> enabled, doesn't support DPO or FUA
>>>>>>> [    2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache:
>>>>>>> enabled, doesn't support DPO or FUA
>>>>>>> [    2.778875] EXT4-fs (sda5): INFO: recovery required on readonly
>>>>>>> filesystem
>>>>>>> [    2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs
>>>>>>> [    4.662442] XXX readw ffffc90004f30000 4401
>>>>>>
>>>>>> This reads good, but I thought you have two sound devices (onboard and
>>>>>> Creative)?  If so, disable the onboard one via enable=0 option (if the
>>>>>> onboard one is assigned first).  Otherwise the all good and bad
>>>>>> results are mixed up.
>>>>>>
>>>>>>
>>>>>> Takashi
>>>>>>
>>>>>
>>>>> I included options snd-hda-intel enable=0 index=0
>>>>>
>>>>> This is dmesg output (1b is onboard)...
>>>>> dmesg | grep -i hda
>>>>> [    3.700213] snd_hda_intel: probe of 0000:00:1b.0 failed with error -2
>>>>> [   37.729507] snd_hda_intel 0000:06:00.0: enabling device (0000 ->
>>>>> 0002)
>>>>> [   37.729703] snd_hda_intel 0000:06:00.0: enabling bus mastering
>>>>> [   37.736026] snd_hda_intel 0000:06:00.0: CORB reset timeout#1,
>>>>> CORBRP = 0
>>>>> [   38.740090] snd_hda_intel 0000:06:00.0: Codec #1 probe error;
>>>>> disabling it...
>>>>> [   38.747292] snd_hda_intel 0000:06:00.0: CORB reset timeout#1,
>>>>> CORBRP = 0
>>>>> [   43.776089] snd_hda_intel 0000:06:00.0: no AFG or MFG node found
>>>>> [   43.776111] snd_hda_intel 0000:06:00.0: no codecs initialized
>>>>>
>>>>> dmesg | grep -i XXX
>>>>> [   37.729723] XXX readw ffffc90005188000 3300
>>>>> [   37.729768] XXX readl ffffc90005188008 0
>>>>
>>>> OK, so all read look fine.  Right now we saw a bug report with git
>>>> bisection showing a bad commit in HD-audio controller code.  This
>>>> might be your issue, too.  Could you try the following oneliner?
>>>>
>>>>
>>>> thanks,
>>>>
>>>> Takashi
>>>>
>>>> diff --git a/sound/pci/hda/hda_controller.c
>>>> b/sound/pci/hda/hda_controller.c
>>>> index 7b4377265b25..57c4575fac26 100644
>>>> --- a/sound/pci/hda/hda_controller.c
>>>> +++ b/sound/pci/hda/hda_controller.c
>>>> @@ -1194,7 +1194,7 @@ static unsigned int azx_rirb_get_response(struct
>>>> hda_bus *bus,
>>>>            }
>>>>        }
>>>>
>>>> -    if (!bus->no_response_fallback)
>>>> +    if (bus->no_response_fallback)
>>>>            return -1;
>>>>
>>>>        if (!chip->polling_mode && chip->poll_count < 2) {
>>>>
>>>
>>>
>>> I believe I applied the patch correctly... if you would like to double
>>> check here is the hda_controller.c file (http://pastebin.com/NA7AV2n1)
>>>
>>> Same complaint comes up, after reinsert and force-reload as well...
>>>
>>> [  419.344572] snd_hda_intel 0000:06:00.0: enabling bus mastering
>>> [  419.350967] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0
>>> [  422.360107] snd_hda_intel 0000:06:00.0: azx_get_response timeout,
>>> switching to polling mode: last cmd=0x100f0000
>>> [  423.364094] snd_hda_intel 0000:06:00.0: Codec #1 probe error;
>>> disabling it...
>>> [  423.371128] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0
>>> [  424.376098] snd_hda_intel 0000:06:00.0: azx_get_response timeout,
>>> switching to single_cmd mode: last cmd=0x100f0000
>>> [  424.377052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found
>>> [  424.377067] snd_hda_intel 0000:06:00.0: no codecs initialized
>>>
>>
>> I'm assuming we've exhausted our options for now. It seems probable this
>> model card (ExpressCard/54) never worked in Linux to begin with. I
>> looked over the forum posts from those claiming they had it operational
>> (in 2.6 kernel), but it was for the PCI-E version. I greatly appreciate
>> your assistance with this. Thank you.
>
> Yes, some PCI-e version has worked, I personally tested it once.
> But yours is apparently a different one, and we finally go back to the
> starting point again.
>
> What you need to do from now on is to analyze why the codec probe
> fails.  It failed even with single_cmd mode.  This is strange, but it
> might be that the board is never 100% compliant, so it might not
> support that mode.
>
> There are some workarounds done specific to the Creative devices.  For
> example, azx_init_cmd_io() in hda_controller.c has a special handling
> to set RIRB interrupt count to 0xc0.  I guess this needs to be set
> normally.  That is, disable the following if () check, and run always
> azx_writew(chip, RINTCNT, 1) instead:
>
> 	if (chip->driver_caps & AZX_DCAPS_CTX_WORKAROUND)
> 		azx_writew(chip, RINTCNT, 0xc0);
> 	else
> 		azx_writew(chip, RINTCNT, 1);

This modification alone produced the same complaint. These are the edits 
I made...

	/* set N=1, get RIRB response interrupt for new entry */
	//if (chip->driver_caps & AZX_DCAPS_CTX_WORKAROUND)
		//azx_writew(chip, RINTCNT, 0xc0);
	//else
	azx_writew(chip, RINTCNT, 1);

>
> There is another workaround in azx_pcm_prepare() for the capture
> streams, but this is irrelevant as of now -- we're concentrating only
> on the codec probe issue.
>
> If modifying above still doesn't work, you may try to force continuing
> the probe by removing -EIO return from probe_codec() in
> hda_controller.c.  That is, remove the following line from that
> function:
>
> 	if (res == -1)
> 		return -EIO;

This is the edit I made...

	mutex_unlock(&chip->bus->cmd_mutex);
	//if (res == -1)
		//return -EIO;
	dev_dbg(chip->card->dev, "codec #%d probed OK\n", addr);

I assume I did this correctly, but here is the full hda_controller.c I 
compiled if you would like to double check http://pastebin.com/fvVVA1Ew

>
> Of course, it doesn't mean this would work, but we can see whether the
> board reacts somehow better.
>

Same complaint comes up.

[    7.600051] snd_hda_intel 0000:06:00.0: azx_get_response timeout, 
switching to polling mode: last cmd=0x100f0000
[    9.608050] snd_hda_intel 0000:06:00.0: azx_get_response timeout, 
switching to single_cmd mode: last cmd=0x100f0000
[    9.609976] snd_hda_intel 0000:06:00.0: no AFG or MFG node found
[    9.611023] snd_hda_intel 0000:06:00.0: no codecs initialized
[   10.776445] init: alsa-restore main process (1461) terminated with 
status 19