Re: [PATCH] ASoC: rt5640: correct 5640's device ID

[Stephen Warren <swarren@wwwdotorg.org>]

On 05/04/2014 09:36 PM, Bard Liao wrote:
>> -----Original Message-----
>> From: Stephen Warren [mailto:swarren@wwwdotorg.org]
>> Sent: Thursday, May 01, 2014 12:10 AM
>> To: Bard Liao; broonie@kernel.org; lgirdwood@gmail.com
>> Cc: alsa-devel@alsa-project.org; lars@metafoo.de; Flove; Oder Chiou
>> Subject: Re: [PATCH] ASoC: rt5640: correct 5640's device ID
>>
>> On 04/30/2014 12:08 AM, bardliao@realtek.com wrote:
>>> From: Bard Liao <bardliao@realtek.com>
>>>
>>> This patch correct rt5640's device ID
>>>
>>> Signed-off-by: Bard Liao <bardliao@realtek.com>
>>> ---
>>> We will send another patch to fix the issue about the "Failed to add route"
>>> error.
>>
>> Tested-by: Stephen Warren <swarren@nvidia.com>
>>
>> (On NVIDIA Tegra Beaver/RT5640, Dalmore/RT5640, Jetson TK1/RT5639)
>>
>> Note that this patch alone (on top of next-20140429) completely eliminates any of
>> the "failed to add route" errors that I mentioned earlier, although perhaps there's
>> still a need to investigate why they happened.
>>
> 
> The "failed to add route" errors is coming from we didn't handle a default case when
> determining which codec is attached. As a result, no _dapm_new_controls is called.
> That's why once we can determine codecs properly, the errors will be gone.
> Actually, there are only three possible ID values, and all of them are in the switch cases now.
> So, I am thinking if we need to add a default case to handle unexpected cases.

Ah, that makes sense.

It's probably worth adding a default case, so that a meaningful error
message can be printed e.g. if the I2C read of the ID register gets
corrupted, or someone tries to use the driver on a chip that isn't (yet)
supported by it.