[alsa-devel] Ordering in soc_pcm_hw_params()

[Mark Brown]

On Wed, Aug 13, 2014 at 01:00:02PM -0400, jonsmirl at gmail.com wrote:

> Right now I could make the set_sysclk implementations return -EINVAL
> if the clock is out of range. Then add some logic to simple-card to
> try again with a different FS multipler. Or at least I can print some
> error message to give a clue as to why the song won't play.

Well, error checking would be good.

> What ASoC platforms haven't implemented the clock API? Using the clock

There's still some ARM platforms that don't implement the common clock
API yet (or make it optional), Blackfin, MIPS, some PowerPC, SH and x86
doesn't enable it for most platforms and when I've tried sending patches
the maintainers didn't bother replying.  Life would be a lot easier if
the common clock API were available by default but the infrastructure
for asm-generic leaves something to be desired too.

> API, simple-card would have a phandle to the clock master. Then it
> could set the proposed rate into it. Codec and CPU would have
> clk_notifier implemented so that they could reject the proposed change
> based on their constraints.  Simple could then adjust the FS multiple
> until both devices are happy.

Even for fairly simple cards the solution is often more complex than
this - the master clock might not be directly connected to one or both
of the devices and there may be programmablility for the dividers
between them.  It therefore seems more likely to be useful to set the
rate we actually want rather than some parent rate, that at least gives
the best information to the code trying to do the resolution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140813/a5d8223a/attachment.sig>