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.
Attachment:
signature.asc
Description: Digital signature
