| Message ID | 1248958183-15015-10-git-send-email-eduardo.valentin@nokia.com (mailing list archive) |
|---|---|
| State | Awaiting Upstream, archived |
| Headers | show |
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?
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. > > -- > Jarkko
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).
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
On Mon, Aug 03, 2009 at 10:36:38AM +0200, ext Jarkko Nikula wrote: > On Mon, 3 Aug 2009 11:11:07 +0300 > Eduardo Valentin <eduardo.valentin@nokia.com> wrote: > > > > 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). > > > So should the patch then take into account McBSP2 also? hmmm.. But I've seen the problem only if you use 1024+256 for mcbsp2 (0x500) or very close to that (0x4F0). I haven't seen this problem using 0x3FF, as currently is. > > -- > Jarkko > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 3 Aug 2009 11:11:07 +0300 Eduardo Valentin <eduardo.valentin@nokia.com> wrote: > > 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). > So should the patch then take into account McBSP2 also?
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c index f837114..7d22caf 100644 --- 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, }, { .phys_base = OMAP34XX_MCBSP2_BASE, @@ -147,7 +147,7 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = { .rx_irq = INT_24XX_MCBSP3_IRQ_RX, .tx_irq = INT_24XX_MCBSP3_IRQ_TX, .ops = &omap2_mcbsp_ops, - .buffer_size = 0x7F, + .buffer_size = 0x6F, }, { .phys_base = OMAP34XX_MCBSP4_BASE, @@ -156,7 +156,7 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = { .rx_irq = INT_24XX_MCBSP4_IRQ_RX, .tx_irq = INT_24XX_MCBSP4_IRQ_TX, .ops = &omap2_mcbsp_ops, - .buffer_size = 0x7F, + .buffer_size = 0x6F, }, { .phys_base = OMAP34XX_MCBSP5_BASE, @@ -165,7 +165,7 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = { .rx_irq = INT_24XX_MCBSP5_IRQ_RX, .tx_irq = INT_24XX_MCBSP5_IRQ_TX, .ops = &omap2_mcbsp_ops, - .buffer_size = 0x7F, + .buffer_size = 0x6F, }, }; #define OMAP34XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap34xx_mcbsp_pdata)