On Fri, Mar 12, 2010 at 8:16 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Fri, Mar 12, 2010 at 01:38:52PM +0900, Jassi Brar wrote:
For ASoC, if either CPU or CODEC driver has set the flag, the MACHINE driver should be given a chance to figure out if the dai, that set the flag, can accomodate a rate that it does not explicitly specify but is specified by the dai at the other end of the link.
Signed-off-by: Jassi Brar jassi.brar@samsung.com
Applied, thanks.
We'll have to work out how to manage the sharing of responsibility for the clock configuration between the component drivers and the machine drivers. My first thought is to have the component drivers provide functions machine drivers can use if they want to. It might also be desirable to allow machine drivers to suppress these flags if they just want to use standard rates, though IIRC the core does the right thing anyway.
Usually even the non-standard rates, those not explicitly mentioned in the chip's manual, are possible to generate given a suitable source of clock and this source clock usually closely depends on the board/machine. That suggests having the MACHINE driver decide which rates would be supported on it (as only it knows cpu/codec dais and the source of clocks). But functions seem overkill, the machine driver could already extract supported rates from cpu_dai and codec_dai members of the dai_link.
So, imho, rates specified by dais should be used only by the machine driver which, after considering the design and purpose of the device, provide a list of supported rates to the ASoC. Of course, soc-core.c would need to be modified.