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

Mark Brown broonie at kernel.org
Sun Mar 22 18:58:51 CET 2015


On Thu, Mar 19, 2015 at 08:06:15PM +0200, Nikolay Dimitrov wrote:

> 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

Not really - it's simply that it's the responsibility of the driver for
the device with the dependency to ensure that the dependency is
satisfied.  There are no general rules about what the requirements of
devices are.

> 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.

There is no need for any hacks, we already know when register accesses
are happening so we can easily add clock enables there (by moving the
code from the MMIO layer to the generic layer, this is the first device
with this unusual requirement).

> 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).

There's nothing audio specific about the idea of a device needing a
clock for register access, doing something at the audio level is the
wrong abstraction layer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20150322/e3693353/attachment.sig>


More information about the Alsa-devel mailing list