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.