[alsa-devel] Patches to bind the SGTL5000 chip to AM33XX McASP

[Nikolay Dimitrov]

Hi Peter,

On 03/19/2015 06:07 PM, Peter Ujfalusi wrote:
> On 03/19/2015 04:34 PM, Greg Knight wrote:
>>> SO is it so that the codec's MCLK is coming from McASP AHCLKX (or R) and this
>>> clock need to be present all the time? W/o the MCLK the registers are not
>>> accessible?
>>
>> Correct, the SGTL5000's I2C registers are not accessible without MCLK.
>
> Yeah, according to the datasheet, it needs MCLK in order to communicate with it.
>

Slight clarification here - I can't find any such reference in the
SGTL5000 datasheet where it's explicitly written that the I2C bus
*requires* the MCLK running. Unfortunately, all of us found this
obscure dependency empirically. One more thing - the codec's I2C works
with "any" supported MCLK (8-27 MHz), you can even change the clock on
the fly (not highly recommended, but it works).

>>  From my testing, the clock need only be present when the audio chip is
>> in use. When not in use, the chip appears perfectly happy to not be
>> clocked.
>
> If you change audio controls while you don't have audio activity, you will
> still need to have the MCLK running.

Correct. And this is a big issue. As far as I know, the kernel drivers
control separately the clock domains, and separately i2c devices, so
the basic expectation on the kernel side is that there's no connection
between these 2. In this specific case, because of the SGTL5000's
implementation, there's a dependency. Right now as I see it, there are
several ways to resolve it:

1. Run the reference clock all the time, so the SGTL5000 codec is
happy, and DAPM widgets can work as-is. We've been doing this all the
time - the reference clocks are routinely configured either in the
bootloader, or in the DTS iomuxc node. While this can work in some
cases (or until someone touches the same clock or one of its parents
:D), there are other cases (like battery-powered devices) where people
would want more aggressive power management, which means controlling
the reference clock at runtime (see #2).

2. Add "hacks" in the DAPM widgets that add control to the codec's
reference clocks. While this seems the preferred route to many, the
general feeling is that such approach is not very welcome in upstream.

3. Add explicit support in the kernel's audio subsystem for
dependencies between i2c devices and clocks, maybe via "DAPM clock
widget" or something like this. Provided that the DAPM graphs are
defined properly, this will work out-of-the-box for all use cases,
without the hacks (until we see even more twisted cases).

Kind regards,
Nikolay