Re: Generic clock divider indices

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1228 bytes --]

On Thu, Jun 06, 2013 at 04:09:52PM +0200, Daniel Mack wrote:
> On 06.06.2013 15:56, Mark Brown wrote:

> > I don't think this is a terribly sensible idea; as soon as you start
> > relying on these dividers in machine code you're going to run into
> > drivers that just don't implement them either due to hardware or due to
> > them being able to figure things out by themselves and...

> I do see that we have a way to propagate the sysclk, but how would you
> determine the bit clock rate from a codec driver?

Usually you just set the bit clock to be whatever the minimim clock
needed for the data is - there's helpers in soc-utils.c to get the
number - or the next highest sensible rate if there's a division
problem.

> Also, the same problem with freely definable indices is true for
> .set_sysclk() as well. Not all drivers expect the actual MCLK rate here.

Yes, and thus you start to see the problems doing this sort of stuff
generically.  There's often also a whole bunch of different ways the
clocking can be set up which can make a material difference to the
quality of the output and may require some system specific taste to
choose.

The fact that the clock API isn't usefully generic is not a help here of
course.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]