On Mon, 10 Aug 2009 11:53:55 +0300 Eduardo Valentin eduardo.valentin@nokia.com 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.