[alsa-devel] [PATCH] ALSA: ASoC: support more sample rates on raumfeld devices

[Mark Brown]

On Wed, Jan 13, 2010 at 04:43:20PM +0100, Daniel Mack wrote:

> For this application, the codec driver would need to be as dumb as
> possible: I would just get the information about which MCLK and LRCLK it
> runs with and it could reject invalid configurations by return value.
> But that would imply major changes to the clocking logic in the cs4270
> driver, which is fine as-is when it acts as master.

That's not quite true.  The problem you're seeing is that the CODEC
driver has variable constraints depending on the master clock, so it at
least needs to know what master clocks it might get so it can specify
the constraints.  Even more ideally than what I suggested we'd be able
to use a clock API with constraint handling which we could use to figure
stuff out but obviously tackling that is very much an uphill struggle.

> I'm uncertain and hence I just went the other way which bypasses this
> logic for now, also not to break existing platforms.

It doesn't do anything for maintainability of the stack, though,
especially if other people try to copy it.

If you're going to do anything that doesn't involve the core API I'd
have the CODEC driver manually apply the constraints from MCLK in the
startup function iff an MCLK is currently set.  Machines with fixed
MCLKs can set the MCLK on init() and machines with dynamic MCLKs can set
the value in hw_params() and reset it when shutting down, imposing any
constraints that do exist themselves.  The rates fixed in the DAI would
be all the rates that can possibly be used.