On Fri, Mar 12, 2010 at 8:16 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> > > 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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
