[alsa-devel] Clock generators in ASoC setups
Hi Mark and Liam,
some board I'm working on feature chips (connected via I2C) that are in charge of generating clocks for both the CPU DAI and the codecs. Previously, I configured them manually in platform specific code, but I wonder if there's a better, more generic way to get the job done, especially with regards to DT driven boards?
Thanks, Daniel
On Wed, Jul 25, 2012 at 10:18:24AM +0200, Daniel Mack wrote:
some board I'm working on feature chips (connected via I2C) that are in charge of generating clocks for both the CPU DAI and the codecs. Previously, I configured them manually in platform specific code, but I wonder if there's a better, more generic way to get the job done, especially with regards to DT driven boards?
The problem here is that we don't have a usable clock API to work with.
On 25.07.2012 12:52, Mark Brown wrote:
On Wed, Jul 25, 2012 at 10:18:24AM +0200, Daniel Mack wrote:
some board I'm working on feature chips (connected via I2C) that are in charge of generating clocks for both the CPU DAI and the codecs. Previously, I configured them manually in platform specific code, but I wonder if there's a better, more generic way to get the job done, especially with regards to DT driven boards?
The problem here is that we don't have a usable clock API to work with.
Hmm, could you elaborate a bit about the background here? So the idea is to have the clock framework that handles all system clocks also take care for clocks related to audio?
What would such a framework need to accomplish, and what missing in - for example - the common clock framework in that regard?
If there's a discussion thread about that topic, a pointer to that would suffice.
Thanks, Daniel
On Thu, Aug 02, 2012 at 10:50:13PM +0200, Daniel Mack wrote:
On 25.07.2012 12:52, Mark Brown wrote:
On Wed, Jul 25, 2012 at 10:18:24AM +0200, Daniel Mack wrote:
The problem here is that we don't have a usable clock API to work with.
Hmm, could you elaborate a bit about the background here? So the idea is to have the clock framework that handles all system clocks also take care for clocks related to audio?
Yes, since many of them are the same clocks - we certainly have massive overlap here and clocks can go in both directions.
What would such a framework need to accomplish, and what missing in - for example - the common clock framework in that regard?
Well, for a start it'd need to be deployed on a useful set of platforms. Right now we've not got any clock API at all on most platforms and only a vanishingly small set are using the generic API. I'm hopefully going to persuade Arnd to unblock the one issue preventing me fixing the first problem and obviously there's some progress on the second.
As things stand there just isn't a non-specific clock API that anything that generates clocks can realistically use.
participants (2)
-
Daniel Mack -
Mark Brown