* shekhar, chandra <x0044955@xxxxxx> [080910 14:45]: > > ----- Original Message ----- From: "Jarkko Nikula" > <jarkko.nikula@xxxxxxxxx> > To: "ext shekhar, chandra" <x0044955@xxxxxx> > Cc: "Tony Lindgren" <tony@xxxxxxxxxxx>; <linux-omap@xxxxxxxxxxxxxxx> > Sent: Wednesday, September 10, 2008 4:44 PM > Subject: Re: [PATCH 1/2] McBSP DMA support for 34xx > > >> On Wed, 10 Sep 2008 15:47:34 +0530 >> "ext shekhar, chandra" <x0044955@xxxxxx> wrote: >> >>> Most importantly, >>> 4> McBSP buffer ( To save power, for 34xx). >>> OMAP3430 McBSP interface 2 has 5k buffer for audio. handling of this >>> buffer should be specific to McBSP. >>> >> Actually it's not specific to McBSP only. I haven't paid attention into >> these HW buffering issues but they have an effect. Like >> >> - IRCC ALSA expects that playback/record is really stopped when trigger >> callback returns >> - How HW buffering affects pointer callback? Some low-latency audio >> algorithms require that buffer position is known very precisely. E.g. >> if modifying already queued audio buffer content but which is not >> played out yet > > This harware buffer is not user accessible, but during data transfer it > is related to dma transfer. > During data transfer instead of element sync, packet sync data transfer > can be used. > DMA request length can be configured buffer threshold and packet sync > transfer can be used instead of element sync. Let's put these on hold until we see the use cases. We should first get all the other pending mcbsp patches into the mainline kernel, and then all legacy audio code removed from l-o tree. Then let's see how we can make use of the McBSP fifo and chaining if needed. Cheers, Tony -- 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
