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

[Nikolay Dimitrov <picmaster@mail.bg>]

Hi Peter,

On 03/20/2015 10:05 AM, Peter Ujfalusi wrote:
> On 03/19/2015 08:06 PM, Nikolay Dimitrov wrote:
>> 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.
>
> It is not spelled out as such, but in:
> http://cache.freescale.com/files/analog/doc/data_sheet/SGTL5000.pdf?pspll=1
> bottom of page9 (note 1) and the power up sequence in page10. See also page13,
> RESET section.
>
>>> 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).
>
> Note the the codec driver will enable the clock and will not let it to be
> turned off. You need to work on the codec driver to sort this out.
>
>> 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.
>
> SND_SOC_DAPM_CLOCK_SUPPLY()
>
>> 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).
>
> This can be handled within the codec driver with some changes. If you have
> external clock which can be enabled/diabled with a GPIO, then you can use
> that. We already have binding for this type of external clocks (in
> linux-next): look for "gpio-gate-clock"
> You define your external GPIO controlled clock with this binding and use the
> phandle in the codec driver.
> Change the codec driver to enable/disable the clock when needed.
> When you do not have audio activity, set the regmap to cache only so any
> change in the controls will not reach the HW. When you power up next time the
> regmap will sync the changes to the chip, so you will have the changes commited.

Thanks a lot for your detailed explanation!

Kind regards,
Nikolay