On Mon, 10 Aug 2009 11:53:55 +0300
Eduardo Valentin <eduardo.valentin@xxxxxxxxx> wrote:
> > Oops, didn't notice this before. This will hard glue the DMA and McBSP
> > together. Even currently there is only McBSP based DAI link driver,
> > there can be others as well. EAC DAI for OMAP2420 would be necessary
> > for instance if one wants to develop ASoC support for Nokia N800. Nokia
> > N810 could use that too.
>
> True. And the same comment is valid for the patch which adds op mode selection.
> My idea to un-glue them is to put some callbacks in omap_mcbsp_data of omap-mcbsp.c,
> and share it as something more generic, so that they can be called from omap-pcm.c.
>
> Something like:
>
> struct omap_dma_data {
> unsigned int bus_id;
> unsigned int fmt;
> /*
> * Flags indicating is the bus already activated and configured by
> * another substream
> */
> int active;
> int configured;
> /* threshold callbacks can be added then here */
> void *data; /* struct omap_mcbsp_reg_cfg regs; can go here */
> };
>
> And this goes in omap-pcm.h.
>
> what do you think??
>
I'm thinking is it just enough to share sync_mode between the
omap-pcm.c and omap-mcbsp.c? For me it looks that both period_bytes_max
(by using snd_pcm_hw_constraint_minmax) adjustment and threshold
setting can be done in omap-mcbsp.c. Then there is no need to invent
any callbacks to the omap_dma_data (for now) and omap-pcm.c remains
cleanear as the threshold is not so much DMA programming specific.
--
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
