On Fri, Jul 31, 2009 at 07:26:11PM +0200, ext Jarkko Nikula wrote:
On Fri, 31 Jul 2009 10:58:23 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
On Thu, Jul 30, 2009 at 08:57:21PM +0200, ext Jarkko Nikula wrote:
On Thu, 30 Jul 2009 15:49:32 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
From: Peter Ujfalusi peter.ujfalusi@nokia.com
Do not allow applications to use the full buffer found on McBSP1,3,4,5. Using the full buffer in threshold mode causes the McBSP buffer to run dry, which can be observed as channels are switching (in reality the channels are shifting).
...
--- a/arch/arm/mach-omap2/mcbsp.c +++ b/arch/arm/mach-omap2/mcbsp.c @@ -129,7 +129,7 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = { .rx_irq = INT_24XX_MCBSP1_IRQ_RX, .tx_irq = INT_24XX_MCBSP1_IRQ_TX, .ops = &omap2_mcbsp_ops,
.buffer_size = 0x7F,
.buffer_size = 0x6F,Is it possible that also McBSP2 would require that maximum burst transmit size should be 0x10 smaller than size of internal buffer/fifo?
That's already not at full size. There is room for 1024+256 places on mcbsp2.
True, but I was wondering can this same problem occur also on McBSP2 if using proper size threshold? Like size near the McBSP2 audio buffer (1024x32) or near the TX buffer (256x32).
Yes, it can happen with mcbsp2 also if you use all places (1024+256).
-- Jarkko