On Wed, Aug 10, 2016 at 12:31:28PM -0500, Pierre-Louis Bossart wrote: > If we want to be consistent then we need to have a framework that handles > both the SOC clock sources and the codec internal clock tree (including > dividers and switches) > I wonder if what you are hinting at is the codec driver modeling its > internal PLL/clock tree with the clock API? I'm not just hinting at that, I've openly stated it quite a few times now! :P For the simpler CODECs it's kind of marginal if you need to bother but for anything more complex (even things with PLLs) it seems like the way forwards. > If we have the clock API requesting the mclk only, and the rest of the codec > configuration is done by the machine driver there is no real progress I can > see. It's still useful in that we can consistently manage the clocks external to the CODEC that way, especially when looking at systems where it is useful to dynamically start and stop the clocks. > > The CODEC clearly has *some* idea of what's going on here, and > > especially for simpler CODECs the code to drive the clocking should be > > fairly easy to generalize as there's few options. From a clock API > > point of view the CODEC really ought to be the one requesting the clocks > > that go into it, though there's nothing that says it has to only use its > > own information to do that. > I don't get the last part, how would the codec use information it doesn't > own or have access to? I'd expect that a clock consumer should (like a regulator consumer can) be able to figure out what constraints there are on the rates it has set. Those could be fixed restrictions but it'd be good to also have ways for other actors in the system to change things at runtime. > At any rate, I am only trying to define the problem statement, probably > something to talk about at the Audio Miniconference. Yup. I really should chase to see if that actually got accepted or not...
Attachment:
signature.asc
Description: PGP signature
