On Fri, 31 Jul 2009 10:58:23 +0300 Eduardo Valentin <[email protected]> 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 <[email protected]> wrote: > > > > > From: Peter Ujfalusi <[email protected]> > > > > > > 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). -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
