Re: [PATCH v5 2/2] ASoC: sgtl5000: Fix driver probe after reset

[Troy Kisky <troy.kisky@boundarydevices.com>]

On 5/10/2013 12:11 PM, Troy Kisky wrote:
> On 5/9/2013 7:12 PM, Fabio Estevam wrote:
>> On Thu, May 9, 2013 at 10:17 PM, Troy Kisky
>> <troy.kisky@boundarydevices.com> wrote:
>>
>>> Did you test a reset/reboot ?  Since the fill_defaults now happens 
>>> after the
>>> read of the device id,
>>> how does this fix the mentioned problem ?
>> Yes, tested several times :-)

Since Sabrelite uses "dummy" regulators (always on), have you tested 
with a boards that
actually uses regulators?

I would think that some regulators would need to be on before you could 
even read
the ID register.


>>
>> The chip ID has to be read from the register and it always read
>> correctly. In patch 1/2, I  just moved the reading to a more standard
>> location (in i2c_probe function), just like many other codecs do.
>>
>> Patch 2/2 fixes the issue by ensuring that we start from sane values
>> from power-on reset.
>>
>> Let's look at the original error:
>>
>> sgtl5000 0-000a: Device with ID register ffff is not a sgtl5000
>> sgtl5000 0-000a: ASoC: failed to probe CODEC -19
>> imx-sgtl5000 sound.12: ASoC: failed to instantiate card -19
>> imx-sgtl5000 sound.12: snd_soc_register_card failed (-19)
>>
>> If I move the chip ID reading to i2c_probe (ie, only apply patch 1/2),
>> the device ID would be read correctly, but the fail would happen at a
>> later point:
>>
>> sgtl5000 0-000a: sgtl5000 revision 0x11
>> sgtl5000 0-000a: Failed to get supply 'VDDD': -517
>>   mmcblk0: p1
>> 0-000a: 1200 mV normal
>> sgtl5000 0-000a: Using internal LDO instead of VDDD
>> usb 2-1: new high-speed USB device number 2 using ci_hdrc
>> hub 2-1:1.0: USB hub found
>> hub 2-1:1.0: 3 ports detected
>> sgtl5000 0-000a: ASoC: failed to probe CODEC -110
>> imx-sgtl5000 sound.12: ASoC: failed to instantiate card -110
>> imx-sgtl5000 sound.12: snd_soc_register_card failed (-110)
>> imx-sgtl5000: probe of sound.12 failed with error -110
>
> Shouldn't you update your commit log with this then ?
>>
>> So the original issue was not about reading the chip ID correctly.
>>
>> The power related registers change from POR to reset (among others)
>>
>> If the chip is not properly powered, then we are not able to read its
>> ID and we get that original error.
>>
>
> Thanks for fixing, I guess I don't need to understand how the fix works.
>
> Troy
>