On Monday 09 November 2009 08:57:22 ext Jarkko Nikula wrote: > On Sun, 08 Nov 2009 20:27:01 +0000 > > Liam Girdwood <lrg@xxxxxxxxxxxxxxx> wrote: > > > Seems to be working fine, tried playing several different sample rates > > > and also recording path. FYI pandora has TWL4030 256FS clock connected > > > to OMAP's CLKS pin. > > > > > > Tested-by: Grazvydas Ignotas <notasas@xxxxxxxxx> > > > > Jarkko, Peter, > > > > Any chance we could have your Ack before applying. > > Definitely. I just sent a patch which must be applied before yours to > the Pandora. It is otherwise the same than I sent before but now with > commit log and 8*32 replaced with 256. > > Mark: The omap3pandora.c must be patches before Liam's patch. > > http://mailman.alsa-project.org/pipermail/alsa-devel/2009-November/022921.h > tml > http://mailman.alsa-project.org/pipermail/alsa-devel/2009-November/022797. > html > > Acked-by: Jarkko Nikula <jhnikula@xxxxxxxxx> I would reconsider this ack, since the patch breaks the McBSP slave operation.. There is no meaning for the infrequency nor for the divider in slave mode, but we can invent something like OMAP_MCBSP_FAKECLK_MASTER to be 'handled' in omap_mcbsp_dai_set_dai_sysclk, when the OMAP_MCBSP_FAKECLK_MASTER is being configured, we just take the frequency, which ahs to be calculated in the machine drivers beforehand (sample rate * bits * channels?), than we need to update all the machine drivers, where McBSP is slave to pass this information in order to pass the test in omap_mcbsp_dai_hw_params. > -- Péter _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
