[alsa-devel] Issues w/ Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG
Alnie
memobook80 at comcast.net
Thu Mar 12 04:59:58 CET 2015
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
More information about the Alsa-devel
mailing list