[alsa-devel] [PATCH 00/20] OMAP ASoC changes in DMA utilization
Hellos guys,
This series provides a way to allow DMA go to idle while performing playback/capture in OMAP3 devices using ASoC driver.
The idea behind it is to do not use DMA element mode, but frame mode. In addition to that, it also configures McBSP threshold accordingly to alsa period. Also, McBSP wakeup signals are configured to generate wakeups for threshold events.
Besides that, this series also include a way to allow choosing between element mode or the frame mode added here.
Patches 1-15 are McBSP changes and, for this reason, are intended to be include in linux-omap tree. Patches 16-20 are OMAP ASoC driver changes, so, they are for alsa-devel.
BR,
Eduardo Valentin (11): OMAP: McBSP: Change wakeup signals OMAP: McBSP: Add IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers. OMAP: McBSP: Use appropriate value for startup delay OMAP: McBSP: Add transmit/receive threshold handler OMAP: McBSP: Create and export max_(r|t)x_thres property OMAP: McBSP: Rename thres sysfs symbols OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold ASoC: OMAP: Use McBSP threshold again ASoC: OMAP: Make DMA 64 aligned ASoC: OMAP: Enable DMA burst mode ASoC: OMAP: Use DMA operating mode of McBSP
Eero Nurkkala (7): OMAP: McBSP: Provide functions for ASoC frame syncronization OMAP: McBSP: Wakeups utilized OMAP: McBSP: Retain McBSP FCLK clockactivity OMAP: McBSP: Do not enable wakeups for no-idle mode OMAP: McBSP: Disable all wakeups upon exit OMAP: McBSP: Let element DMA mode hit retention also ASoC: Always syncronize audio transfers on frames
Peter Ujfalusi (2): OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 OMAP: McBSP: Add link DMA mode selection
arch/arm/mach-omap2/mcbsp.c | 5 + arch/arm/plat-omap/include/mach/mcbsp.h | 54 +++++ arch/arm/plat-omap/mcbsp.c | 343 ++++++++++++++++++++++++++++++- sound/soc/omap/omap-mcbsp.c | 16 ++- sound/soc/omap/omap-pcm.c | 57 +++++- 5 files changed, 468 insertions(+), 7 deletions(-)
-- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
ASoC has an annoying bug letting either L or R channel to be played on L channel. In other words, L and R channels can switch at random. This provides McBSP funtionality that may be used to fix this feature.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h | 2 + arch/arm/plat-omap/mcbsp.c | 52 +++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index bb154ea..77191c5 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -389,6 +389,8 @@ int omap_mcbsp_request(unsigned int id); void omap_mcbsp_free(unsigned int id); void omap_mcbsp_start(unsigned int id); void omap_mcbsp_stop(unsigned int id); +void omap_mcbsp_xmit_enable(unsigned int id, u8 enable); +void omap_mcbsp_recv_enable(unsigned int id, u8 enable); void omap_mcbsp_xmit_word(unsigned int id, u32 word); u32 omap_mcbsp_recv_word(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index efa0e01..84cc323 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -398,6 +398,58 @@ void omap_mcbsp_stop(unsigned int id) } EXPORT_SYMBOL(omap_mcbsp_stop);
+void omap_mcbsp_xmit_enable(unsigned int id, u8 enable) +{ + struct omap_mcbsp *mcbsp; + void __iomem *io_base; + u16 w; + + if (!(cpu_is_omap2430() || cpu_is_omap34xx())) + return; + + if (!omap_mcbsp_check_valid_id(id)) { + printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1); + return; + } + + mcbsp = id_to_mcbsp_ptr(id); + io_base = mcbsp->io_base; + + w = OMAP_MCBSP_READ(io_base, XCCR); + + if (enable) + OMAP_MCBSP_WRITE(io_base, XCCR, w & ~(XDISABLE)); + else + OMAP_MCBSP_WRITE(io_base, XCCR, w | XDISABLE); +} +EXPORT_SYMBOL(omap_mcbsp_xmit_enable); + +void omap_mcbsp_recv_enable(unsigned int id, u8 enable) +{ + struct omap_mcbsp *mcbsp; + void __iomem *io_base; + u16 w; + + if (!(cpu_is_omap2430() || cpu_is_omap34xx())) + return; + + if (!omap_mcbsp_check_valid_id(id)) { + printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1); + return; + } + + mcbsp = id_to_mcbsp_ptr(id); + io_base = mcbsp->io_base; + + w = OMAP_MCBSP_READ(io_base, RCCR); + + if (enable) + OMAP_MCBSP_WRITE(io_base, RCCR, w & ~(RDISABLE)); + else + OMAP_MCBSP_WRITE(io_base, RCCR, w | RDISABLE); +} +EXPORT_SYMBOL(omap_mcbsp_recv_enable); + /* polled mcbsp i/o operations */ int omap_mcbsp_pollwrite(unsigned int id, u16 buf) {
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
This patch enables the smart idle mode while McBPS is being utilized. Once it's done, force idle mode is taken instead. Apart of it, it also configures what signals will wake mcbsp up.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h | 17 +++++++++++++++ arch/arm/plat-omap/mcbsp.c | 35 +++++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 77191c5..758ad5c 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -134,6 +134,7 @@ #define OMAP_MCBSP_REG_XCERG 0x74 #define OMAP_MCBSP_REG_XCERH 0x78 #define OMAP_MCBSP_REG_SYSCON 0x8C +#define OMAP_MCBSP_REG_WAKEUPEN 0xA8 #define OMAP_MCBSP_REG_XCCR 0xAC #define OMAP_MCBSP_REG_RCCR 0xB0
@@ -249,8 +250,24 @@ #define RDISABLE 0x0001
/********************** McBSP SYSCONFIG bit definitions ********************/ +#define SIDLEMODE(value) ((value)<<3) +#define ENAWAKEUP 0x0004 #define SOFTRST 0x0002
+/********************** McBSP WAKEUPEN bit definitions *********************/ +#define XEMPTYEOFEN 0x4000 +#define XRDYEN 0x0400 +#define XEOFEN 0x0200 +#define XFSXEN 0x0100 +#define XSYNCERREN 0x0080 +#define RRDYEN 0x0008 +#define REOFEN 0x0004 +#define RFSREN 0x0002 +#define RSYNCERREN 0x0001 +#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \ + XSYNCERREN | RRDYEN | REOFEN | RFSREN | \ + RSYNCERREN) + /* we don't do multichannel for now */ struct omap_mcbsp_reg_cfg { u16 spcr2; diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 84cc323..b64896b 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -257,6 +257,23 @@ int omap_mcbsp_request(unsigned int id) clk_enable(mcbsp->iclk); clk_enable(mcbsp->fclk);
+#ifdef CONFIG_ARCH_OMAP34XX + /* + * Enable wakup behavior, smart idle and all wakeups + * REVISIT: some wakeups may be unnecessary + */ + if (cpu_is_omap34xx()) { + u16 syscon; + + syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON); + syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03)); + syscon |= (ENAWAKEUP | SIDLEMODE(0x02)); + OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon); + + OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, WAKEUPEN_ALL); + } +#endif + /* * Make sure that transmitter, receiver and sample-rate generator are * not running before activating IRQs. @@ -295,6 +312,7 @@ EXPORT_SYMBOL(omap_mcbsp_request); void omap_mcbsp_free(unsigned int id) { struct omap_mcbsp *mcbsp; + u16 wakeupen;
if (!omap_mcbsp_check_valid_id(id)) { printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1); @@ -305,6 +323,23 @@ void omap_mcbsp_free(unsigned int id) if (mcbsp->pdata && mcbsp->pdata->ops && mcbsp->pdata->ops->free) mcbsp->pdata->ops->free(id);
+#ifdef CONFIG_ARCH_OMAP34XX + /* + * Disable wakup behavior, smart idle and all wakeups + */ + if (cpu_is_omap34xx()) { + u16 syscon; + + syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON); + syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03)); + OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon); + + wakeupen = OMAP_MCBSP_READ(mcbsp->io_base, WAKEUPEN); + wakeupen &= ~WAKEUPEN_ALL; + OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, wakeupen); + } +#endif + clk_disable(mcbsp->fclk); clk_disable(mcbsp->iclk);
Configure only XRDYEN and RRDYEN wakeup signals in order to get better power consumption.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 758ad5c..89d1bea 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -264,9 +264,7 @@ #define REOFEN 0x0004 #define RFSREN 0x0002 #define RSYNCERREN 0x0001 -#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \ - XSYNCERREN | RRDYEN | REOFEN | RFSREN | \ - RSYNCERREN) +#define WAKEUPEN_ALL (XRDYEN | RRDYEN)
/* we don't do multichannel for now */ struct omap_mcbsp_reg_cfg {
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 89d1bea..57157b4 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -134,6 +134,10 @@ #define OMAP_MCBSP_REG_XCERG 0x74 #define OMAP_MCBSP_REG_XCERH 0x78 #define OMAP_MCBSP_REG_SYSCON 0x8C +#define OMAP_MCBSP_REG_THRSH2 0x90 +#define OMAP_MCBSP_REG_THRSH1 0x94 +#define OMAP_MCBSP_REG_IRQST 0xA0 +#define OMAP_MCBSP_REG_IRQEN 0xA4 #define OMAP_MCBSP_REG_WAKEUPEN 0xA8 #define OMAP_MCBSP_REG_XCCR 0xAC #define OMAP_MCBSP_REG_RCCR 0xB0
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
FCLK may get autogated so that it prevents the McBSP to work properly. It is the bit 9 that must be set for maintaining the McBSP FCLK.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com Acked-by: Jarkko Nikula jarkko.nikula@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h | 1 + arch/arm/plat-omap/mcbsp.c | 6 +++--- 2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 57157b4..e3b300c 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -254,6 +254,7 @@ #define RDISABLE 0x0001
/********************** McBSP SYSCONFIG bit definitions ********************/ +#define CLOCKACTIVITY(value) ((value)<<8) #define SIDLEMODE(value) ((value)<<3) #define ENAWAKEUP 0x0004 #define SOFTRST 0x0002 diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index b64896b..6b39656 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -266,8 +266,8 @@ int omap_mcbsp_request(unsigned int id) u16 syscon;
syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON); - syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03)); - syscon |= (ENAWAKEUP | SIDLEMODE(0x02)); + syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); + syscon |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY(0x02)); OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);
OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, WAKEUPEN_ALL); @@ -331,7 +331,7 @@ void omap_mcbsp_free(unsigned int id) u16 syscon;
syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON); - syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03)); + syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);
wakeupen = OMAP_MCBSP_READ(mcbsp->io_base, WAKEUPEN);
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/mcbsp.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 6b39656..373926d 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -394,7 +394,8 @@ void omap_mcbsp_start(unsigned int id) w = OMAP_MCBSP_READ(io_base, SPCR1); OMAP_MCBSP_WRITE(io_base, SPCR1, w | 1);
- udelay(100); + /* Worst case: CLKSRG*2 = 8000khz: (1/8000) * 2 * 2 usec */ + udelay(500);
/* Start frame sync */ w = OMAP_MCBSP_READ(io_base, SPCR2);
This patch adds a way to handle transmit/receive threshold. It export to mcbsp users a callback registration procedure.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h | 13 ++++++++ arch/arm/plat-omap/mcbsp.c | 50 +++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index e3b300c..26bcab8 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -259,6 +259,10 @@ #define ENAWAKEUP 0x0004 #define SOFTRST 0x0002
+/********************** McBSP IRQSTATUS bit definitions ********************/ +#define IRQST_XRDY (1<<10) +#define IRQST_RRDY (1<<3) + /********************** McBSP WAKEUPEN bit definitions *********************/ #define XEMPTYEOFEN 0x4000 #define XRDYEN 0x0400 @@ -405,6 +409,15 @@ int omap_mcbsp_init(void); void omap_mcbsp_register_board_cfg(struct omap_mcbsp_platform_data *config, int size); void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg * config); +#ifdef CONFIG_ARCH_OMAP34XX +void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold); +void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold); +#else +static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold) +{ } +static inline void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold) +{ } +#endif int omap_mcbsp_request(unsigned int id); void omap_mcbsp_free(unsigned int id); void omap_mcbsp_start(unsigned int id); diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 373926d..60e9254 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -198,6 +198,56 @@ void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg *config) } EXPORT_SYMBOL(omap_mcbsp_config);
+#ifdef CONFIG_ARCH_OMAP34XX +/* + * omap_mcbsp_set_tx_threshold configures how to deal + * with transmit threshold. the threshold value and handler can be + * configure in here. + */ +void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold) +{ + struct omap_mcbsp *mcbsp; + void __iomem *io_base; + + if (!cpu_is_omap34xx()) + return; + + if (!omap_mcbsp_check_valid_id(id)) { + printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1); + return; + } + mcbsp = id_to_mcbsp_ptr(id); + io_base = mcbsp->io_base; + + OMAP_MCBSP_WRITE(io_base, THRSH2, threshold); +} +EXPORT_SYMBOL(omap_mcbsp_set_tx_threshold); + +/* + * omap_mcbsp_set_rx_threshold configures how to deal + * with receive threshold. the threshold value and handler can be + * configure in here. + */ +void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold) +{ + struct omap_mcbsp *mcbsp; + void __iomem *io_base; + + if (!cpu_is_omap34xx()) + return; + + if (!omap_mcbsp_check_valid_id(id)) { + printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1); + return; + } + mcbsp = id_to_mcbsp_ptr(id); + io_base = mcbsp->io_base; + + OMAP_MCBSP_WRITE(io_base, THRSH1, threshold); +} +EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold); +#endif + /* * We can choose between IRQ based or polled IO. * This needs to be called before omap_mcbsp_request().
This patch export through sysfs two properties to configure maximum threshold for transmission and reception on each mcbsp instance. Also, it exports two helper functions to allow mcbsp users to read this values.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/mach-omap2/mcbsp.c | 5 ++ arch/arm/plat-omap/include/mach/mcbsp.h | 11 +++ arch/arm/plat-omap/mcbsp.c | 114 +++++++++++++++++++++++++++++++ 3 files changed, 130 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c index a5c0f04..f837114 100644 --- a/arch/arm/mach-omap2/mcbsp.c +++ b/arch/arm/mach-omap2/mcbsp.c @@ -129,6 +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, }, { .phys_base = OMAP34XX_MCBSP2_BASE, @@ -137,6 +138,7 @@ static struct omap_mcbsp_platform_data omap34xx_mcbsp_pdata[] = { .rx_irq = INT_24XX_MCBSP2_IRQ_RX, .tx_irq = INT_24XX_MCBSP2_IRQ_TX, .ops = &omap2_mcbsp_ops, + .buffer_size = 0x3FF, }, { .phys_base = OMAP34XX_MCBSP3_BASE, @@ -145,6 +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, }, { .phys_base = OMAP34XX_MCBSP4_BASE, @@ -153,6 +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, }, { .phys_base = OMAP34XX_MCBSP5_BASE, @@ -161,6 +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, }, }; #define OMAP34XX_MCBSP_PDATA_SZ ARRAY_SIZE(omap34xx_mcbsp_pdata) diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 26bcab8..b0fc675 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -368,6 +368,9 @@ struct omap_mcbsp_platform_data { u8 dma_rx_sync, dma_tx_sync; u16 rx_irq, tx_irq; struct omap_mcbsp_ops *ops; +#ifdef CONFIG_ARCH_OMAP34XX + u16 buffer_size; +#endif };
struct omap_mcbsp { @@ -401,6 +404,10 @@ struct omap_mcbsp { struct omap_mcbsp_platform_data *pdata; struct clk *iclk; struct clk *fclk; +#ifdef CONFIG_ARCH_OMAP34XX + u16 max_tx_thres; + u16 max_rx_thres; +#endif }; extern struct omap_mcbsp **mcbsp_ptr; extern int omap_mcbsp_count; @@ -412,11 +419,15 @@ void omap_mcbsp_config(unsigned int id, const struct omap_mcbsp_reg_cfg * config #ifdef CONFIG_ARCH_OMAP34XX void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold); void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold); +u16 omap_mcbsp_get_max_tx_threshold(unsigned int id); +u16 omap_mcbsp_get_max_rx_threshold(unsigned int id); #else static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold) { } static inline void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold) { } +static inline u16 omap_mcbsp_get_max_tx_threshold(unsigned int id) { return 0; } +static inline u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) { return 0; } #endif int omap_mcbsp_request(unsigned int id); void omap_mcbsp_free(unsigned int id); diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 60e9254..6fed8cf 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -246,6 +246,42 @@ void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold) OMAP_MCBSP_WRITE(io_base, THRSH1, threshold); } EXPORT_SYMBOL(omap_mcbsp_set_rx_threshold); + +/* + * omap_mcbsp_get_max_tx_thres just return the current configured + * maximum threshold for transmission + */ +u16 omap_mcbsp_get_max_tx_threshold(unsigned int id) +{ + struct omap_mcbsp *mcbsp; + + if (!omap_mcbsp_check_valid_id(id)) { + printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1); + return -ENODEV; + } + mcbsp = id_to_mcbsp_ptr(id); + + return mcbsp->max_tx_thres; +} +EXPORT_SYMBOL(omap_mcbsp_get_max_tx_threshold); + +/* + * omap_mcbsp_get_max_rx_thres just return the current configured + * maximum threshold for reception + */ +u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) +{ + struct omap_mcbsp *mcbsp; + + if (!omap_mcbsp_check_valid_id(id)) { + printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1); + return -ENODEV; + } + mcbsp = id_to_mcbsp_ptr(id); + + return mcbsp->max_rx_thres; +} +EXPORT_SYMBOL(omap_mcbsp_get_max_rx_threshold); #endif
/* @@ -1021,6 +1057,69 @@ void omap_mcbsp_set_spi_mode(unsigned int id, } EXPORT_SYMBOL(omap_mcbsp_set_spi_mode);
+#ifdef CONFIG_ARCH_OMAP34XX +#define max_thres(m) (mcbsp->pdata->buffer_size) +#define valid_threshold(m, val) ((val) <= max_thres(m)) +#define THRESHOLD_PROP_BUILDER(prop) \ +static ssize_t prop##_show(struct device *dev, \ + struct device_attribute *attr, char *buf) \ +{ \ + struct omap_mcbsp *mcbsp = dev_get_drvdata(dev); \ + \ + return sprintf(buf, "%u\n", mcbsp->prop); \ +} \ + \ +static ssize_t prop##_store(struct device *dev, \ + struct device_attribute *attr, \ + const char *buf, size_t size) \ +{ \ + struct omap_mcbsp *mcbsp = dev_get_drvdata(dev); \ + unsigned long val; \ + int status; \ + \ + status = strict_strtoul(buf, 0, &val); \ + if (status) \ + return status; \ + \ + if (!valid_threshold(mcbsp, val)) \ + return -EDOM; \ + \ + mcbsp->prop = val; \ + return size; \ +} \ + \ +static DEVICE_ATTR(prop, 0644, prop##_show, prop##_store); + +THRESHOLD_PROP_BUILDER(max_tx_thres); +THRESHOLD_PROP_BUILDER(max_rx_thres); + +static const struct attribute *threshold_attrs[] = { + &dev_attr_max_tx_thres.attr, + &dev_attr_max_rx_thres.attr, + NULL, +}; + +static const struct attribute_group threshold_attr_group = { + .attrs = (struct attribute **)threshold_attrs, +}; + +static inline int __devinit omap_thres_add(struct platform_device *pdev) +{ + return sysfs_create_group(&pdev->dev.kobj, &threshold_attr_group); +} + +static inline void __devexit omap_thres_remove(struct platform_device *pdev) +{ + sysfs_remove_group(&pdev->dev.kobj, &threshold_attr_group); +} +#else +static inline int __devinit omap_thres_add(struct platform_device *pdev) +{ + return 0; +} +static inline void __devexit omap_thres_remove(struct platform_device *pdev) {} +#endif /* CONFIG_ARCH_OMAP34XX */ + /* * McBSP1 and McBSP3 are directly mapped on 1610 and 1510. * 730 has only 2 McBSP, and both of them are MPU peripherals. @@ -1091,6 +1190,19 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev) mcbsp->dev = &pdev->dev; mcbsp_ptr[id] = mcbsp; platform_set_drvdata(pdev, mcbsp); + #ifdef CONFIG_ARCH_OMAP34XX + if (cpu_is_omap34xx()) { + mcbsp->max_tx_thres = max_thres(mcbsp); + mcbsp->max_rx_thres = max_thres(mcbsp); + if (omap_thres_add(pdev)) + dev_warn(&pdev->dev, + "Unable to create threshold controls\n"); + } else { + mcbsp->max_tx_thres = -EINVAL; + mcbsp->max_rx_thres = -EINVAL; + } + #endif + return 0;
err_fclk: @@ -1114,6 +1226,8 @@ static int __devexit omap_mcbsp_remove(struct platform_device *pdev) mcbsp->pdata->ops->free) mcbsp->pdata->ops->free(mcbsp->id);
+ if (cpu_is_omap34xx()) + omap_thres_remove(pdev); clk_disable(mcbsp->fclk); clk_disable(mcbsp->iclk); clk_put(mcbsp->fclk);
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).
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- arch/arm/mach-omap2/mcbsp.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
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)
This patch renames the symbols that handles threshold sysfs properties. This way we can add more sysfs properties to them.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/mcbsp.c | 23 ++++++++++++----------- 1 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 6fed8cf..1b8ff9e 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -1093,31 +1093,32 @@ static DEVICE_ATTR(prop, 0644, prop##_show, prop##_store); THRESHOLD_PROP_BUILDER(max_tx_thres); THRESHOLD_PROP_BUILDER(max_rx_thres);
-static const struct attribute *threshold_attrs[] = { +static const struct attribute *additional_attrs[] = { &dev_attr_max_tx_thres.attr, &dev_attr_max_rx_thres.attr, NULL, };
-static const struct attribute_group threshold_attr_group = { - .attrs = (struct attribute **)threshold_attrs, +static const struct attribute_group additional_attr_group = { + .attrs = (struct attribute **)additional_attrs, };
-static inline int __devinit omap_thres_add(struct platform_device *pdev) +static inline int __devinit omap_additional_add(struct platform_device *pdev) { - return sysfs_create_group(&pdev->dev.kobj, &threshold_attr_group); + return sysfs_create_group(&pdev->dev.kobj, &additional_attr_group); }
-static inline void __devexit omap_thres_remove(struct platform_device *pdev) +static inline void __devexit omap_additional_rem(struct platform_device *pdev) { - sysfs_remove_group(&pdev->dev.kobj, &threshold_attr_group); + sysfs_remove_group(&pdev->dev.kobj, &additional_attr_group); } #else -static inline int __devinit omap_thres_add(struct platform_device *pdev) +static inline int __devinit omap_additional_add(struct platform_device *pdev) { return 0; } -static inline void __devexit omap_thres_remove(struct platform_device *pdev) {} +static inline void __devexit omap_additional_rem(struct platform_device *pdev) +{ } #endif /* CONFIG_ARCH_OMAP34XX */
/* @@ -1194,7 +1195,7 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev) if (cpu_is_omap34xx()) { mcbsp->max_tx_thres = max_thres(mcbsp); mcbsp->max_rx_thres = max_thres(mcbsp); - if (omap_thres_add(pdev)) + if (omap_additional_add(pdev)) dev_warn(&pdev->dev, "Unable to create threshold controls\n"); } else { @@ -1227,7 +1228,7 @@ static int __devexit omap_mcbsp_remove(struct platform_device *pdev) mcbsp->pdata->ops->free(mcbsp->id);
if (cpu_is_omap34xx()) - omap_thres_remove(pdev); + omap_additional_rem(pdev); clk_disable(mcbsp->fclk); clk_disable(mcbsp->iclk); clk_put(mcbsp->fclk);
From: Peter Ujfalusi peter.ujfalusi@nokia.com
It adds a new sysfs file, where the user can configure the mcbsp mode to use. If the mcbsp channel is in use, it does not allow the change. Than in omap_pcm_open we can call the omap_mcbsp_get_opmode to get the mode, store it, than use it to implement the different modes.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/include/mach/mcbsp.h | 8 +++ arch/arm/plat-omap/mcbsp.c | 73 +++++++++++++++++++++++++++++++ 2 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index b0fc675..61c55ec 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -275,6 +275,11 @@ #define RSYNCERREN 0x0001 #define WAKEUPEN_ALL (XRDYEN | RRDYEN)
+/********************** McBSP DMA operating modes **************************/ +#define MCBSP_DMA_MODE_ELEMENT 0 +#define MCBSP_DMA_MODE_THRESHOLD 1 +#define MCBSP_DMA_MODE_FRAME 2 + /* we don't do multichannel for now */ struct omap_mcbsp_reg_cfg { u16 spcr2; @@ -405,6 +410,7 @@ struct omap_mcbsp { struct clk *iclk; struct clk *fclk; #ifdef CONFIG_ARCH_OMAP34XX + int dma_op_mode; u16 max_tx_thres; u16 max_rx_thres; #endif @@ -421,6 +427,7 @@ void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold); void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold); u16 omap_mcbsp_get_max_tx_threshold(unsigned int id); u16 omap_mcbsp_get_max_rx_threshold(unsigned int id); +int omap_mcbsp_get_dma_op_mode(unsigned int id); #else static inline void omap_mcbsp_set_tx_threshold(unsigned int id, u16 threshold) { } @@ -428,6 +435,7 @@ static inline void omap_mcbsp_set_rx_threshold(unsigned int id, u16 threshold) { } static inline u16 omap_mcbsp_get_max_tx_threshold(unsigned int id) { return 0; } static inline u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) { return 0; } +static inline int omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; } #endif int omap_mcbsp_request(unsigned int id); void omap_mcbsp_free(unsigned int id); diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 1b8ff9e..6c535b3 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -282,6 +282,29 @@ u16 omap_mcbsp_get_max_rx_threshold(unsigned int id) return mcbsp->max_rx_thres; } EXPORT_SYMBOL(omap_mcbsp_get_max_rx_threshold); + +/* + * omap_mcbsp_get_dma_op_mode just return the current configured + * operating mode for the mcbsp channel + */ +int omap_mcbsp_get_dma_op_mode(unsigned int id) +{ + struct omap_mcbsp *mcbsp; + int dma_op_mode; + + if (!omap_mcbsp_check_valid_id(id)) { + printk(KERN_ERR "%s: Invalid id (%u)\n", __func__, id + 1); + return -ENODEV; + } + mcbsp = id_to_mcbsp_ptr(id); + + spin_lock_irq(&mcbsp->lock); + dma_op_mode = mcbsp->dma_op_mode; + spin_unlock_irq(&mcbsp->lock); + + return dma_op_mode; +} +EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode); #endif
/* @@ -1093,9 +1116,57 @@ static DEVICE_ATTR(prop, 0644, prop##_show, prop##_store); THRESHOLD_PROP_BUILDER(max_tx_thres); THRESHOLD_PROP_BUILDER(max_rx_thres);
+static ssize_t dma_op_mode_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct omap_mcbsp *mcbsp = dev_get_drvdata(dev); + int dma_op_mode; + + spin_lock_irq(&mcbsp->lock); + dma_op_mode = mcbsp->dma_op_mode; + spin_unlock_irq(&mcbsp->lock); + + return sprintf(buf, "%d\n", dma_op_mode); +} + +static ssize_t dma_op_mode_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t size) +{ + struct omap_mcbsp *mcbsp = dev_get_drvdata(dev); + unsigned long val; + int status; + + status = strict_strtoul(buf, 0, &val); + if (status) + return status; + + spin_lock_irq(&mcbsp->lock); + + if (!mcbsp->free) { + size = -EBUSY; + goto unlock; + } + + if (val > MCBSP_DMA_MODE_FRAME || val < MCBSP_DMA_MODE_ELEMENT) { + size = -EINVAL; + goto unlock; + } + + mcbsp->dma_op_mode = val; + +unlock: + spin_unlock_irq(&mcbsp->lock); + + return size; +} + +static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, dma_op_mode_store); + static const struct attribute *additional_attrs[] = { &dev_attr_max_tx_thres.attr, &dev_attr_max_rx_thres.attr, + &dev_attr_dma_op_mode.attr, NULL, };
@@ -1195,12 +1266,14 @@ static int __devinit omap_mcbsp_probe(struct platform_device *pdev) if (cpu_is_omap34xx()) { mcbsp->max_tx_thres = max_thres(mcbsp); mcbsp->max_rx_thres = max_thres(mcbsp); + mcbsp->dma_op_mode = MCBSP_DMA_MODE_THRESHOLD; if (omap_additional_add(pdev)) dev_warn(&pdev->dev, "Unable to create threshold controls\n"); } else { mcbsp->max_tx_thres = -EINVAL; mcbsp->max_rx_thres = -EINVAL; + mcbsp->dma_op_mode = MCBSP_DMA_MODE_ELEMENT; } #endif
Use dma mode property to configure NO IDLE or SMART IDLE of McBSPs.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/mcbsp.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 6c535b3..11cfcfe 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -376,7 +376,15 @@ int omap_mcbsp_request(unsigned int id)
syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON); syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); - syscon |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY(0x02)); + + spin_lock_irq(&mcbsp->lock); + if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) + syscon |= SIDLEMODE(0x02); + else + syscon |= SIDLEMODE(0x01); + spin_unlock_irq(&mcbsp->lock); + + syscon |= (ENAWAKEUP | CLOCKACTIVITY(0x02)); OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);
OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, WAKEUPEN_ALL);
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
When no-idle mode is taken, wakeups need not to be enabled. Moreover, CLOCKACTIVITY bits are unnecessary with this mode also.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com Acked-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/mcbsp.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 11cfcfe..cb4a455 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -378,16 +378,17 @@ int omap_mcbsp_request(unsigned int id) syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
spin_lock_irq(&mcbsp->lock); - if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) - syscon |= SIDLEMODE(0x02); - else + if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) { + syscon |= (ENAWAKEUP | SIDLEMODE(0x02) | + CLOCKACTIVITY(0x02)); + OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, + WAKEUPEN_ALL); + } else { syscon |= SIDLEMODE(0x01); + } spin_unlock_irq(&mcbsp->lock);
- syscon |= (ENAWAKEUP | CLOCKACTIVITY(0x02)); OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon); - - OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, WAKEUPEN_ALL); } #endif
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
Quite a few wakeups were left on while the McBSP was being closed. This patch leaves no single wakeup enabled.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com Acked-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/mcbsp.c | 5 +---- 1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index cb4a455..3c6b98e 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -430,7 +430,6 @@ EXPORT_SYMBOL(omap_mcbsp_request); void omap_mcbsp_free(unsigned int id) { struct omap_mcbsp *mcbsp; - u16 wakeupen;
if (!omap_mcbsp_check_valid_id(id)) { printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1); @@ -452,9 +451,7 @@ void omap_mcbsp_free(unsigned int id) syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);
- wakeupen = OMAP_MCBSP_READ(mcbsp->io_base, WAKEUPEN); - wakeupen &= ~WAKEUPEN_ALL; - OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, wakeupen); + OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, 0); } #endif
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
The device no longer hits retention if element DMA mode is taken for at least the duration of the serial console timeout. Force element DMA mode to shut down through smartidle.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com Acked-by: Eduardo Valentin eduardo.valentin@nokia.com --- arch/arm/plat-omap/mcbsp.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 3c6b98e..13f79c6 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -449,6 +449,15 @@ void omap_mcbsp_free(unsigned int id)
syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON); syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03)); + /* + * HW bug workaround - If no_idle mode is taken, we need to + * go to smart_idle before going to always_idle, or the + * device will not hit retention anymore. + */ + syscon |= SIDLEMODE(0x02); + OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon); + + syscon &= ~(SIDLEMODE(0x03)); OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);
OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, 0);
Now this patch implements again the McBSP threshold usage for OMAP ASoC.
We figured out that there is no need to have so much SW control in order to have DMA in idle state during audio streaming. Configuring McBSP threshold value and DMA to FRAME_SYNC are sufficient.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- sound/soc/omap/omap-pcm.c | 37 +++++++++++++++++++++++++++++++++++-- 1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 84a1950..03cb420 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -28,10 +28,11 @@ #include <sound/pcm_params.h> #include <sound/soc.h>
+#include <mach/mcbsp.h> #include <mach/dma.h> #include "omap-pcm.h"
-static const struct snd_pcm_hardware omap_pcm_hardware = { +static struct snd_pcm_hardware omap_pcm_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | @@ -135,6 +136,7 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) struct omap_runtime_data *prtd = runtime->private_data; struct omap_pcm_dma_data *dma_data = prtd->dma_data; struct omap_dma_channel_params dma_params; + int sync_mode;
/* return if this is a bufferless transfer e.g. * codec <--> BT codec or GSM modem -- lg FIXME */ @@ -142,13 +144,19 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream) return 0;
memset(&dma_params, 0, sizeof(dma_params)); + + if (cpu_is_omap34xx()) + sync_mode = OMAP_DMA_SYNC_FRAME; + else + sync_mode = OMAP_DMA_SYNC_ELEMENT; + /* * Note: Regardless of interface data formats supported by OMAP McBSP * or EAC blocks, internal representation is always fixed 16-bit/sample */ dma_params.data_type = OMAP_DMA_DATA_TYPE_S16; dma_params.trigger = dma_data->dma_req; - dma_params.sync_mode = OMAP_DMA_SYNC_ELEMENT; + dma_params.sync_mode = sync_mode; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { dma_params.src_amode = OMAP_DMA_AMODE_POST_INC; dma_params.dst_amode = OMAP_DMA_AMODE_CONSTANT; @@ -183,8 +191,11 @@ static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd) { struct snd_pcm_runtime *runtime = substream->runtime; struct omap_runtime_data *prtd = runtime->private_data; + struct snd_soc_pcm_runtime *rtd = substream->private_data; unsigned long flags; int ret = 0; + unsigned int bus_id = *(unsigned int *)rtd->dai->cpu_dai->private_data; + u16 samples = snd_pcm_lib_period_bytes(substream) >> 1;
spin_lock_irqsave(&prtd->lock, flags); switch (cmd) { @@ -192,6 +203,12 @@ static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd) case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: prtd->period_index = 0; + /* Configure McBSP internal buffer usage */ + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + omap_mcbsp_set_tx_threshold(bus_id, samples - 1); + else + omap_mcbsp_set_rx_threshold(bus_id, samples - 1); + omap_start_dma(prtd->dma_ch); break;
@@ -235,7 +252,23 @@ static int omap_pcm_open(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; struct omap_runtime_data *prtd; + struct snd_soc_pcm_runtime *rtd = substream->private_data; + unsigned int bus_id = *(unsigned int *)rtd->dai->cpu_dai->private_data; int ret; + int max_period; + + if (cpu_is_omap34xx()) { + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + max_period = omap_mcbsp_get_max_tx_threshold(bus_id); + else + max_period = omap_mcbsp_get_max_rx_threshold(bus_id); + max_period++; + max_period <<= 1; + } else { + omap_pcm_hardware.period_bytes_max = 64 * 1024; + } + + omap_pcm_hardware.period_bytes_max = max_period;
snd_soc_set_runtime_hwparams(substream, &omap_pcm_hardware);
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- sound/soc/omap/omap-pcm.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 03cb420..a18b3bf 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -321,7 +321,7 @@ static struct snd_pcm_ops omap_pcm_ops = { .mmap = omap_pcm_mmap, };
-static u64 omap_pcm_dmamask = DMA_BIT_MASK(32); +static u64 omap_pcm_dmamask = DMA_BIT_MASK(64);
static int omap_pcm_preallocate_dma_buffer(struct snd_pcm *pcm, int stream) @@ -371,7 +371,7 @@ int omap_pcm_new(struct snd_card *card, struct snd_soc_dai *dai, if (!card->dev->dma_mask) card->dev->dma_mask = &omap_pcm_dmamask; if (!card->dev->coherent_dma_mask) - card->dev->coherent_dma_mask = DMA_BIT_MASK(32); + card->dev->coherent_dma_mask = DMA_BIT_MASK(64);
if (dai->playback.channels_min) { ret = omap_pcm_preallocate_dma_buffer(pcm,
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- sound/soc/omap/omap-pcm.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index a18b3bf..a30e7a0 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -184,6 +184,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream)
omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ);
+ omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); + omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); + return 0; }
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com --- sound/soc/omap/omap-pcm.c | 21 +++++++++++++++++---- 1 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index a30e7a0..f4903e0 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -51,6 +51,7 @@ struct omap_runtime_data { struct omap_pcm_dma_data *dma_data; int dma_ch; int period_index; + int dma_op_mode; };
static void omap_pcm_dma_irq(int ch, u16 stat, void *data) @@ -145,7 +146,9 @@ static int omap_pcm_prepare(struct snd_pcm_substream *substream)
memset(&dma_params, 0, sizeof(dma_params));
- if (cpu_is_omap34xx()) + /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */ + if (cpu_is_omap34xx() && + (prtd->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)) sync_mode = OMAP_DMA_SYNC_FRAME; else sync_mode = OMAP_DMA_SYNC_ELEMENT; @@ -198,9 +201,16 @@ static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd) unsigned long flags; int ret = 0; unsigned int bus_id = *(unsigned int *)rtd->dai->cpu_dai->private_data; - u16 samples = snd_pcm_lib_period_bytes(substream) >> 1; + u16 samples;
spin_lock_irqsave(&prtd->lock, flags); + + /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */ + if (prtd->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) + samples = snd_pcm_lib_period_bytes(substream) >> 1; + else + samples = 1; + switch (cmd) { case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: @@ -257,10 +267,12 @@ static int omap_pcm_open(struct snd_pcm_substream *substream) struct omap_runtime_data *prtd; struct snd_soc_pcm_runtime *rtd = substream->private_data; unsigned int bus_id = *(unsigned int *)rtd->dai->cpu_dai->private_data; + int dma_op_mode = omap_mcbsp_get_dma_op_mode(bus_id); int ret; int max_period;
- if (cpu_is_omap34xx()) { + /* TODO: Currently, MODE_ELEMENT == MODE_FRAME */ + if (cpu_is_omap34xx() && (dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)) { if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) max_period = omap_mcbsp_get_max_tx_threshold(bus_id); else @@ -268,7 +280,7 @@ static int omap_pcm_open(struct snd_pcm_substream *substream) max_period++; max_period <<= 1; } else { - omap_pcm_hardware.period_bytes_max = 64 * 1024; + max_period = 64 * 1024; }
omap_pcm_hardware.period_bytes_max = max_period; @@ -286,6 +298,7 @@ static int omap_pcm_open(struct snd_pcm_substream *substream) ret = -ENOMEM; goto out; } + prtd->dma_op_mode = dma_op_mode; spin_lock_init(&prtd->lock); runtime->private_data = prtd;
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
All these steps are required for ASoC to behave correctly. This is, no RFIG or XFIG (Not defined in 34xx), correct initiliazation of rccr and xccr. They are format dependent, for example TDM audio has different values than I2S or DSP_A. Also the omap_mcbsp_xmit_enable and/or omap_mcbsp_recv_enable must be called right after the DMA has started. This provides no longer L and R channels switching at random.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com --- sound/soc/omap/omap-mcbsp.c | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index a5d46a7..0272d3f 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -191,6 +191,11 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream *substream, int cmd, case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: if (!mcbsp_data->active++) omap_mcbsp_start(mcbsp_data->bus_id); + /* Make sure data transfer is frame synchronized */ + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + omap_mcbsp_xmit_enable(mcbsp_data->bus_id, 1); + else + omap_mcbsp_recv_enable(mcbsp_data->bus_id, 1); break;
case SNDRV_PCM_TRIGGER_STOP: @@ -321,8 +326,11 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, /* Generic McBSP register settings */ regs->spcr2 |= XINTM(3) | FREE; regs->spcr1 |= RINTM(3); - regs->rcr2 |= RFIG; - regs->xcr2 |= XFIG; + /* RFIG and XFIG are not defined in 34xx */ + if (!cpu_is_omap34xx()) { + regs->rcr2 |= RFIG; + regs->xcr2 |= XFIG; + } if (cpu_is_omap2430() || cpu_is_omap34xx()) { regs->xccr = DXENDLY(1) | XDMAEN; regs->rccr = RFULL_CYCLE | RDMAEN; @@ -333,11 +341,15 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, /* 1-bit data delay */ regs->rcr2 |= RDATDLY(1); regs->xcr2 |= XDATDLY(1); + regs->rccr |= RFULL_CYCLE | RDMAEN | RDISABLE; + regs->xccr |= (DXENDLY(1) | XDMAEN | XDISABLE); break; case SND_SOC_DAIFMT_DSP_A: /* 1-bit data delay */ regs->rcr2 |= RDATDLY(1); regs->xcr2 |= XDATDLY(1); + regs->rccr |= RFULL_CYCLE | RDMAEN | RDISABLE; + regs->xccr |= (DXENDLY(1) | XDMAEN | XDISABLE); /* Invert FS polarity configuration */ temp_fmt ^= SND_SOC_DAIFMT_NB_IF; break;
On Thu, 30 Jul 2009 15:49:43 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
@@ -321,8 +326,11 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, /* Generic McBSP register settings */ regs->spcr2 |= XINTM(3) | FREE; regs->spcr1 |= RINTM(3);
- regs->rcr2 |= RFIG;
- regs->xcr2 |= XFIG;
- /* RFIG and XFIG are not defined in 34xx */
- if (!cpu_is_omap34xx()) {
regs->rcr2 |= RFIG;regs->xcr2 |= XFIG;- }
This is true. These bits are marked as reserved read only bits in 34xx. I'm fine if you do change here in this patch but I can add immediate acked-by if you want to post this as a separate change for 2.6.32 (setting them for 34xx is null-op at the moment AFAIK).
If you find generic fix for channel switching problem found also from older OMAP's like 2420 then I give you a deep bow and acked-by for 2.6.31!
On Thu, 30 Jul 2009 15:49:39 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
Now this patch implements again the McBSP threshold usage for OMAP ASoC.
We figured out that there is no need to have so much SW control in order to have DMA in idle state during audio streaming. Configuring McBSP threshold value and DMA to FRAME_SYNC are sufficient.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com
sound/soc/omap/omap-pcm.c | 37 +++++++++++++++++++++++++++++++++++-- 1 files changed, 35 insertions(+), 2 deletions(-)
@@ -192,6 +203,12 @@ static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd) case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: prtd->period_index = 0;
/* Configure McBSP internal buffer usage */if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)omap_mcbsp_set_tx_threshold(bus_id, samples - 1);elseomap_mcbsp_set_rx_threshold(bus_id, samples - 1);- omap_start_dma(prtd->dma_ch); break;
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.
Hi Jarkko,
On Wed, Aug 05, 2009 at 09:48:56AM +0200, ext Jarkko Nikula wrote:
On Thu, 30 Jul 2009 15:49:39 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
Now this patch implements again the McBSP threshold usage for OMAP ASoC.
We figured out that there is no need to have so much SW control in order to have DMA in idle state during audio streaming. Configuring McBSP threshold value and DMA to FRAME_SYNC are sufficient.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com
sound/soc/omap/omap-pcm.c | 37 +++++++++++++++++++++++++++++++++++-- 1 files changed, 35 insertions(+), 2 deletions(-)
@@ -192,6 +203,12 @@ static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd) case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: prtd->period_index = 0;
/* Configure McBSP internal buffer usage */if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)omap_mcbsp_set_tx_threshold(bus_id, samples - 1);elseomap_mcbsp_set_rx_threshold(bus_id, samples - 1);- omap_start_dma(prtd->dma_ch); break;
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??
-- Jarkko
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.
On Tue, Aug 11, 2009 at 07:34:45AM +0200, ext Jarkko Nikula wrote:
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.
Ok, I was wrong here. My point was to add new stuff in here: struct omap_pcm_dma_data { char *name; /* stream identifier */ int dma_req; /* DMA request line */ unsigned long port_addr; /* transmit/receive register */
/* additional things go here */ };
This one is already shared.
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.
True, that would become cleaner.
But, there are some points to re-think here. Max threshold value is dependent on mcbsp instance (and possibly, on omap version as well, if something change for next omap versions). The way max threshold is implemented now, it comes first from board file, then you can query it using new added function in this series.
So far nothing prevent us to move max threshold usage to omap-mcbsp.c. But at open time, we add a restriction to make buffer size a multiple of period size. And I think to properly make this, we need max threshold value in advance, as we the idea is to bind periods with thresholds.
A similar issue may happen whilst setting current threshold value. We want to set it before starting DMA. And that value must be bind to chosen period size for that stream. In which place we can do that in omap-mcbsp.c?
Thoughts?
-- Jarkko
Tony and Jarkko,
On Thu, Jul 30, 2009 at 02:49:35PM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote:
Use dma mode property to configure NO IDLE or SMART IDLE of McBSPs.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com
arch/arm/plat-omap/mcbsp.c | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 6c535b3..11cfcfe 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -376,7 +376,15 @@ int omap_mcbsp_request(unsigned int id)
syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON); syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
syscon |= (ENAWAKEUP | SIDLEMODE(0x02) | CLOCKACTIVITY(0x02));
spin_lock_irq(&mcbsp->lock);if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD)syscon |= SIDLEMODE(0x02);elsesyscon |= SIDLEMODE(0x01);spin_unlock_irq(&mcbsp->lock);syscon |= (ENAWAKEUP | CLOCKACTIVITY(0x02));
Because of this piece of code that patch 0002 is using ifdefs.
OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon); OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, WAKEUPEN_ALL);-- 1.6.2.GIT
On Thu, Jul 30, 2009 at 03:49:34PM +0300, Eduardo Valentin wrote:
It adds a new sysfs file, where the user can configure the mcbsp mode to use. If the mcbsp channel is in use, it does not allow the change. Than in omap_pcm_open we can call the omap_mcbsp_get_opmode to get the mode, store it, than use it to implement the different modes.
Is this really something that people would want to tweak at runtime (except for test purposes)? -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 30, 2009 at 03:04:42PM +0200, ext Mark Brown wrote:
On Thu, Jul 30, 2009 at 03:49:34PM +0300, Eduardo Valentin wrote:
It adds a new sysfs file, where the user can configure the mcbsp mode to use. If the mcbsp channel is in use, it does not allow the change. Than in omap_pcm_open we can call the omap_mcbsp_get_opmode to get the mode, store it, than use it to implement the different modes.
Is this really something that people would want to tweak at runtime (except for test purposes)?
Yes, test purposes, bug also, the same link could be sometime used for low-power playback while sometime for low-latency processing where as accurate as possible DMA pointer position info is needed.
On Thu, Jul 30, 2009 at 04:28:08PM +0300, Eduardo Valentin wrote:
On Thu, Jul 30, 2009 at 03:04:42PM +0200, ext Mark Brown wrote:
Is this really something that people would want to tweak at runtime (except for test purposes)?
Yes, test purposes, bug also, the same link could be sometime used for low-power playback while sometime for low-latency processing where as accurate as possible DMA pointer position info is needed.
Latency you *should* be able to infer from the application behaviour. -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 30, 2009 at 03:47:25PM +0200, ext Mark Brown wrote:
On Thu, Jul 30, 2009 at 04:28:08PM +0300, Eduardo Valentin wrote:
On Thu, Jul 30, 2009 at 03:04:42PM +0200, ext Mark Brown wrote:
Is this really something that people would want to tweak at runtime (except for test purposes)?
Yes, test purposes, bug also, the same link could be sometime used for low-power playback while sometime for low-latency processing where as accurate as possible DMA pointer position info is needed.
Latency you *should* be able to infer from the application behaviour.
Yes that's true. But I think using ELEMENT mode, position reports are much more accurate, which will result in more precise inferences for latencies.
On Thu, 30 Jul 2009 15:49:34 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
From: Peter Ujfalusi peter.ujfalusi@nokia.com
It adds a new sysfs file, where the user can configure the mcbsp mode to use. If the mcbsp channel is in use, it does not allow the change. Than in omap_pcm_open we can call the omap_mcbsp_get_opmode to get the mode, store it, than use it to implement the different modes.
...
+/********************** McBSP DMA operating modes **************************/ +#define MCBSP_DMA_MODE_ELEMENT 0 +#define MCBSP_DMA_MODE_THRESHOLD 1 +#define MCBSP_DMA_MODE_FRAME 2
...
+static ssize_t dma_op_mode_show(struct device *dev,
struct device_attribute *attr, char *buf)+{
- struct omap_mcbsp *mcbsp = dev_get_drvdata(dev);
- int dma_op_mode;
- spin_lock_irq(&mcbsp->lock);
- dma_op_mode = mcbsp->dma_op_mode;
- spin_unlock_irq(&mcbsp->lock);
- return sprintf(buf, "%d\n", dma_op_mode);
It would be good to handle this as an ascii like e.g /sys/power/state does. "element", "threshold" or "frame". A number value doesn't tell much (for me when testing).
@@ -1195,12 +1266,14 @@ static int __devinit omap_mcbsp_probe
(struct platform_device *pdev)
if (cpu_is_omap34xx()) { mcbsp->max_tx_thres = max_thres(mcbsp); mcbsp->max_rx_thres = max_thres(mcbsp);
mcbsp->dma_op_mode = MCBSP_DMA_MODE_THRESHOLD;mcbsp->dma_op_mode = MCBSP_DMA_MODE_ELEMENT;
I would say the default mode for the omap34xx should be also element as it keeps the omap_pcm_pointer behavior the same than currently and avoids possible regression.
On Wednesday 05 August 2009 10:39:00 ext Jarkko Nikula wrote:
On Thu, 30 Jul 2009 15:49:34 +0300
Eduardo Valentin eduardo.valentin@nokia.com wrote:
From: Peter Ujfalusi peter.ujfalusi@nokia.com
- return sprintf(buf, "%d\n", dma_op_mode);
It would be good to handle this as an ascii like e.g /sys/power/state does. "element", "threshold" or "frame". A number value doesn't tell much (for me when testing).
At least when reading it it would be nice to have asci, like "element (0)", "threshold (1)"...
I would say the default mode for the omap34xx should be also element as it keeps the omap_pcm_pointer behavior the same than currently and avoids possible regression.
Yes, the default mode should be the element mode in my opinion as well.
I would say the default mode for the omap34xx should be also element as it keeps the omap_pcm_pointer behavior the same than currently and avoids possible regression.
Yes, the default mode should be the element mode in my opinion as well.
-- Péter
Well, the element mode is fine for !McBSP2. One doesn't really loose the buffer pointer accuracy, because you can get the last DMA irq timestamp with SNDRV_PCM_IOCTL_TTSTAMP (and compare that to current time). The accuracy is not far off from the element mode? (If you read the DMA portion of TRM, I think there were some issues as well)
Don't want to be piccy, but McBSP2 with element mode is more or less like a "joke"? As there's a large HW bugger, why not take advantage of it..why "bypass" it as default?
For !McBSP2, it doesn't even pay to have the threshold mode at all, because the effect on PM is actually adverse - too frequent wakeups will cause more adverse net effect on PM (IIRC) @ VBAT.
- Eero
Hello guys,
On Thu, Aug 06, 2009 at 08:15:40PM +0200, Nurkkala Eero.An (EXT-Offcode/Oulu) wrote:
I would say the default mode for the omap34xx should be also element as it keeps the omap_pcm_pointer behavior the same than currently and avoids possible regression.
Yes, the default mode should be the element mode in my opinion as well.
-- Péter
Well, the element mode is fine for !McBSP2. One doesn't really loose the buffer pointer accuracy, because you can get the last DMA irq timestamp with SNDRV_PCM_IOCTL_TTSTAMP (and compare that to current time). The accuracy is not far off from the element mode? (If you read the DMA portion of TRM, I think there were some issues as well)
Don't want to be piccy, but McBSP2 with element mode is more or less like a "joke"? As there's a large HW bugger, why not take advantage of it..why "bypass" it as default?
For !McBSP2, it doesn't even pay to have the threshold mode at all, because the effect on PM is actually adverse - too frequent wakeups will cause more adverse net effect on PM (IIRC) @ VBAT.
I agree with Eero in this point. We can set mcbsp2 default op mode to threshold.
I think we are even here :) two believe that must be element mode by default, while two want default threshold (at least for mcbsp2). We need another opinion.
- Eero --
To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sorry for the late reply.
On Thu, 6 Aug 2009 20:15:40 +0200 ext-Eero.Nurkkala@nokia.com wrote:
Well, the element mode is fine for !McBSP2. One doesn't really loose the buffer pointer accuracy, because you can get the last DMA irq timestamp with SNDRV_PCM_IOCTL_TTSTAMP (and compare that to current time). The accuracy is not far off from the element mode? (If you read the DMA portion of TRM, I think there were some issues as well)
Well the threshold mode makes the offset returned from omap_pcm_pointer to behave gradually as the threshold size is set. This would affect a SW which is doing sub-period processing like mixing audio n samples ahead the current DMA pointer. Of course HW buffer in McBSP2 adds static latency but otherwise processing is similar compared to other ports and OMAPs.
I would like to see this new threshold based transfer functionality to be integrated so that projects can take the advantage of it and helps generic PM development too but I don't want that it would cause any regression now. Later on it is easy to switch threshold based transfer to be the default for McBSP2 on OMAP3 but it's safer to keep current mode default over one kernel release.
For !McBSP2, it doesn't even pay to have the threshold mode at all, because the effect on PM is actually adverse - too frequent wakeups will cause more adverse net effect on PM (IIRC) @ VBAT.
This is good information and integrating these functionalities allow to collect more. Without regression of course :-)
On Tue, 2009-08-11 at 08:04 +0200, ext Jarkko Nikula wrote:
Sorry for the late reply.
On Thu, 6 Aug 2009 20:15:40 +0200 ext-Eero.Nurkkala@nokia.com wrote:
Well, the element mode is fine for !McBSP2. One doesn't really loose the buffer pointer accuracy, because you can get the last DMA irq timestamp with SNDRV_PCM_IOCTL_TTSTAMP (and compare that to current time). The accuracy is not far off from the element mode? (If you read the DMA portion of TRM, I think there were some issues as well)
Well the threshold mode makes the offset returned from omap_pcm_pointer to behave gradually as the threshold size is set. This would affect a SW which is doing sub-period processing like mixing audio n samples ahead the current DMA pointer. Of course HW buffer in McBSP2 adds static latency but otherwise processing is similar compared to other ports and OMAPs.
I would like to see this new threshold based transfer functionality to be integrated so that projects can take the advantage of it and helps generic PM development too but I don't want that it would cause any regression now. Later on it is easy to switch threshold based transfer to be the default for McBSP2 on OMAP3 but it's safer to keep current mode default over one kernel release.
What regression are you addressing to? Of course in OMAP2s there could be issues I'm not aware of. But does this have any effect on them? (isn't this only OMAP3).
There's regression indeed with McBSP2 as it is. The same regression is available for you, even with the element mode; See, the problem is the large HW buffer, and I think there's efforts to fix those issues; for example: http://bugzilla.gnome.org/show_bug.cgi?id=545807 That is causing the "known regression", it's not really the threshold/dma mode. (of course I'm probably not aware of all)
If one wishes to perform runtime mixing of several channels etc, it's known to the men in the art that of course the McBSP buffer latency, was it in element or threshold mode, is required to be calculated so that the time until the sample is played, need to be considered. That can be done easily with either of the threshold/element mode.
DMA transfers may also have delays due to DMA controller scheduling (other channels present). Thus, there's always some unpredictable, but rather tiny, delays.
For !McBSP2, it doesn't even pay to have the threshold mode at all, because the effect on PM is actually adverse - too frequent wakeups will cause more adverse net effect on PM (IIRC) @ VBAT.
This is good information and integrating these functionalities allow to collect more. Without regression of course :-)
On Tue, 11 Aug 2009 09:18:01 +0300 Eero Nurkkala ext-eero.nurkkala@nokia.com wrote:
I would like to see this new threshold based transfer functionality to be integrated so that projects can take the advantage of it and helps generic PM development too but I don't want that it would cause any regression now. Later on it is easy to switch threshold based transfer to be the default for McBSP2 on OMAP3 but it's safer to keep current mode default over one kernel release.
What regression are you addressing to? Of course in OMAP2s there could be issues I'm not aware of. But does this have any effect on them? (isn't this only OMAP3).
A possible regression to a SW which is using McBSP2 on OMAP3. There many of those boards.
The threshold based transfer will cause that omap_pcm_pointer will loose a bit its accuracy. Probably irrelevant but still better to play safe at least over one kernel release before making it default.
Return value prints from omap_pcm_pointer while playing "aplay -f dat /dev/zero"
element: 614 669 691 712 734 755
threshold: 512 512 512 1024 1024 1536
On Wed, 2009-08-12 at 13:45 +0200, ext Jarkko Nikula wrote:
The threshold based transfer will cause that omap_pcm_pointer will loose a bit its accuracy. Probably irrelevant but still better to play safe at least over one kernel release before making it default.
No, it doesn't loose accuracy =) It's as accurate with both modes. The difference is, that the other does things in bursts; that's called evolution rather than regression =) That's how things will be in the future =)
Return value prints from omap_pcm_pointer while playing "aplay -f dat /dev/zero"
element: 614 669 691 712 734 755
threshold: 512 512 512 1024 1024 1536
On Wednesday 12 August 2009 14:48:33 Nurkkala Eero.An (EXT-Offcode/Oulu) wrote:
On Wed, 2009-08-12 at 13:45 +0200, ext Jarkko Nikula wrote:
The threshold based transfer will cause that omap_pcm_pointer will loose a bit its accuracy. Probably irrelevant but still better to play safe at least over one kernel release before making it default.
No, it doesn't loose accuracy =) It's as accurate with both modes. The difference is, that the other does things in bursts;
In element mode it is kind of easy to estimate where the hardware actually in the playback case (aplay -f dat /dev/zero):
omap_pcm_pointer returns 669, than the HW is around 669-512=157 (plus few samples).
In threshold mode you only know that the HW is playing in between 0-512, 512-1024 somewhere.
I know neither of these are accurate and these examples are quite oversimplified, but there is a difference and that difference is quite significant.
that's called evolution rather than regression =)
Note that evolution can also introduce regression...
That's how things will be in the future =)
I agree with you on this, since the threshold mode provides quite good power saving benefits. But on the other hand it would be still better to keep the element mode as default for at least one release cycle. If no report is coming about problems, than we can make the threshold mode for McBSP2 as the default
Hi,
not strictly related to the patch in question, but this touches on, and is a good example of, one question I've been wondering for some time now as an app developer. Could Takashi, Jaroslav, Mark, or others comment on this as well, perhaps? Dropping linux-omap as this is a generic ALSA question.
On Wed, 12 Aug 2009, Jarkko Nikula wrote: [i.e. pcm_pointer == hw_ptr]
The threshold based transfer will cause that omap_pcm_pointer will loose a bit its accuracy. Probably irrelevant but still better to play safe at least over one kernel release before making it default.
[...]
element: 614 669 691
[...]
threshold: 512 512 1024 1024
In both cases, this value (hw_ptr) shows the status of sending data to an separate entity, and one that has its own buffer (multiple ms) before the actual DAC/ADC.
So when application developer uses snd_pcm_delay(), the result is not quite what the ALSA API says:
alsa-lib.git/src/pcm/pcm.c: --cut-- * For playback the delay is defined as the time that a frame that is written * to the PCM stream shortly after this call will take to be actually * audible. It is as such the overall latency from the write call to the final * DAC. [...] int snd_pcm_delay(snd_pcm_t *pcm, snd_pcm_sframes_t *delayp) --cut--
Of course, there are many other cases where the same happens, as the latency of the HW (or where it is connected) is not known. But we also have many cases where we _do_ know more about the latency, and we are just missing the means to expose this info. I think this applies to this OMAP patch as well. E.g. the HW can tell fairly accurately the current status (i.e. which sample is played-out/captured _now_). Now that brings us to my question -- how to expose this info in an ALSA driver.
Elsewhere in alsa-lib docs, there is more accurate description of current implementation and behaviour of snd_pcm_delay(): alsa-lib.git/src/pcm/pcm.c: --cut-- The function #snd_pcm_delay() returns the delay in samples. For playback, it means count of samples in the ring buffer before the next sample will be sent to DAC. --cut--
So e.g. the OMAP patch that this thread started from, complies with this definition, and element/threshold modes just differ in accuracy (although threshold implementation should warn the application with the SNDRV_PCM_INFO_BATCH flag).
But how would a driver expose both bits of info to apps (in a standard fashion): 1) the hw_ptr for shuffling bits out of the ringbuffer, and 2) the delay to next played-out/captured sample. For application developers, (2) is the piece of info we are mostly interested in (if I write a sample now, how long it will be until it's played out).
One obvious solution (that has been used already in other ALSA drivers) is to virtualize the hw_ptr, but this way you lose the accurate info about ringbuffer status. Ideally both pieces of info could be exposed. But as I see it, drivers currently can only implement "pointer" to relay this info.
Jaroslav proposed some ideas earlier this year, but then the discussion faded: "Re: Driver code with mpc5200 pointer problem.", 2009-04-28 http://article.gmane.org/gmane.linux.alsa.devel/62170
Takashi made basicly the same point I've tried to make above "Re: Driver code with mpc5200 pointer problem.", 2009-04-28 http://article.gmane.org/gmane.linux.alsa.devel/62172
Mark also commented to the same thread: http://article.gmane.org/gmane.linux.alsa.devel/62176, 2009-04-28
Any update/ideas on this topic? Personally I think adding a new driver callback would make most sense, as that would allow to take full benefit from hardware that allows to query sample-accurate position of playout (i.e. not just support exposing a fixed latency). Of course that's potentially a big change. In alsa-lib, snd_pcm_hwsync() could call this driver callback, and a new variant of snd_pcm_delay() could present the information to the applications.
On Thu, Aug 13, 2009 at 11:46:52PM +0300, Kai Vehmanen wrote:
not strictly related to the patch in question, but this touches on, and is a good example of, one question I've been wondering for some time now as an app developer. Could Takashi, Jaroslav, Mark, or others comment on this as well, perhaps? Dropping linux-omap as this is a generic ALSA question.
I'd suggest starting a new thread to discuss this - I'd imagine that several of the people you're trying to get answers from are at best just scanning the thread since it's very large and very OMAP-specific.
(Incidentally, can be very helpful to use --no-chain-reply-to when posting large patch sets like this to avoid massive indentation in threaded mail readers).
In both cases, this value (hw_ptr) shows the status of sending data to an separate entity, and one that has its own buffer (multiple ms) before the actual DAC/ADC.
But how would a driver expose both bits of info to apps (in a standard fashion): 1) the hw_ptr for shuffling bits out of the ringbuffer, and 2) the delay to next played-out/captured sample. For application developers, (2) is the piece of info we are mostly interested in (if I write a sample now, how long it will be until it's played out).
Both bits of information are very interesting to applications - some applications want to work on the data they're sending for as long as possible (things like pulse which do mixing are the obvious example of this).
Any update/ideas on this topic? Personally I think adding a new driver callback would make most sense, as that would allow to take full benefit from hardware that allows to query sample-accurate position of playout (i.e. not just support exposing a fixed latency). Of course that's potentially a big change. In alsa-lib, snd_pcm_hwsync() could call this driver callback, and a new variant of snd_pcm_delay() could present the information to the applications.
If we're adding a new API it should be possible to add one which provides the required information without disturbing the semantics of the existing APIs.
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, 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?
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
* Eduardo Valentin eduardo.valentin@nokia.com [090730 16:01]:
This patch adds a way to handle transmit/receive threshold. It export to mcbsp users a callback registration procedure.
Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com
arch/arm/plat-omap/include/mach/mcbsp.h | 13 ++++++++ arch/arm/plat-omap/mcbsp.c | 50 +++++++++++++++++++++++++++++++ 2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index e3b300c..26bcab8 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -259,6 +259,10 @@ #define ENAWAKEUP 0x0004 #define SOFTRST 0x0002
+/********************** McBSP IRQSTATUS bit definitions ********************/ +#define IRQST_XRDY (1<<10) +#define IRQST_RRDY (1<<3)
/********************** McBSP WAKEUPEN bit definitions *********************/ #define XEMPTYEOFEN 0x4000 #define XRDYEN 0x0400
Please add spaces around << defines above.
Regards,
Tony -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
+/********************** McBSP IRQSTATUS bit definitions ********************/ +#define IRQST_XRDY (1<<10) +#define IRQST_RRDY (1<<3)
/********************** McBSP WAKEUPEN bit definitions *********************/ #define XEMPTYEOFEN 0x4000 #define XRDYEN 0x0400
Please add spaces around << defines above.
Regards,
Tony
No spaces are used in this file at such declarations: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f...
to follow the file format exactly, it'd need to be in form of 0x ?
- Eero-- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* ext-Eero.Nurkkala@nokia.com ext-Eero.Nurkkala@nokia.com [090806 15:22]:
+/********************** McBSP IRQSTATUS bit definitions ********************/ +#define IRQST_XRDY (1<<10) +#define IRQST_RRDY (1<<3)
/********************** McBSP WAKEUPEN bit definitions *********************/ #define XEMPTYEOFEN 0x4000 #define XRDYEN 0x0400
Please add spaces around << defines above.
Regards,
Tony
No spaces are used in this file at such declarations: http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f...
to follow the file format exactly, it'd need to be in form of 0x ?
OK, never mind then, it could be done in a clean-up patch later on.
Tony -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 30 Jul 2009 15:49:29 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
--- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -394,7 +394,8 @@ void omap_mcbsp_start(unsigned int id) w = OMAP_MCBSP_READ(io_base, SPCR1); OMAP_MCBSP_WRITE(io_base, SPCR1, w | 1);
- udelay(100);
- /* Worst case: CLKSRG*2 = 8000khz: (1/8000) * 2 * 2 usec */
- udelay(500);
Note: udelay(100) us used to wait at least 2 CLKSRG cycles (as stated in TRM).
Are you sure this change is necessary? CLKSRG is kind of master clock to McBSP so original stetson guessed (?) 100 us should be fine for all serial links where bit clock is higher than 20 kHz.
Jarkko Nikula [jhnikula@gmail.com] wrote:
Are you sure this change is necessary? CLKSRG is kind of master clock to McBSP so original stetson guessed (?) 100 us should be fine for all serial links where bit clock is higher than 20 kHz.
The McBSP / DMA stuff doesn't really work properly, when PM is enabled to full extent. The first DMA goes in _before_ the omap_mcbsp_start(), so the higher delay compensates DMA misbehavior in a way...
.. L/R channels also may switch at random initially with full PM enabled. So the L/R fix is only working, if no PM is enabled (sigh).
Need to make that work fine (no L/R switching and early no DMA completions) to get rid of the higher, 500us, timeout. Maybe try not having XCCR/RCCR dma enable bit initially, but enabling them at omap_mcbsp_start()? (I'd try if I wasn't also on vacation).
- Eero-- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 31 Jul 2009 09:21:30 +0200 ext-Eero.Nurkkala@nokia.com wrote:
Jarkko Nikula [jhnikula@gmail.com] wrote:
Are you sure this change is necessary? CLKSRG is kind of master clock to McBSP so original stetson guessed (?) 100 us should be fine for all serial links where bit clock is higher than 20 kHz.
The McBSP / DMA stuff doesn't really work properly, when PM is enabled to full extent. The first DMA goes in _before_ the omap_mcbsp_start(), so the higher delay compensates DMA misbehavior in a way...
.. L/R channels also may switch at random initially with full PM enabled. So the L/R fix is only working, if no PM is enabled (sigh).
Need to make that work fine (no L/R switching and early no DMA completions) to get rid of the higher, 500us, timeout. Maybe try not having XCCR/RCCR dma enable bit initially, but enabling them at omap_mcbsp_start()? (I'd try if I wasn't also on vacation).
Ok, 500 us is not so long delay here compared to benefits but it would be good to have a little revisit comment for future reference. I think that by default 100 us provides enough time for two CLKSRG cycles but due some unknown PM related, clock gating etc. reason it must be extended to 500 us now.
On Thursday 30 July 2009 15:49:26 Valentin Eduardo (Nokia-D/Helsinki) wrote:
Configure only XRDYEN and RRDYEN wakeup signals in order to get better power consumption.
@@ -264,9 +264,7 @@ #define REOFEN 0x0004 #define RFSREN 0x0002 #define RSYNCERREN 0x0001 -#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \
XSYNCERREN | RRDYEN | REOFEN | RFSREN | \RSYNCERREN)+#define WAKEUPEN_ALL (XRDYEN | RRDYEN)
Or don't use the WAKEUPEN_ALL in the code, but replace it with (XRDYEN | RRDYEN)? It is confusing to use WAKEUPEN_ALL, which is actually _not_ enabling all wakeups.
On Thu, 30 Jul 2009 15:49:25 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
--- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -257,6 +257,23 @@ int omap_mcbsp_request(unsigned int id) clk_enable(mcbsp->iclk); clk_enable(mcbsp->fclk);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
I'm sure there is a way to avoid all of these added ifdefs in this patch and in patches 7 and 8 as well.
On Thu, Jul 30, 2009 at 08:56:02PM +0200, ext Jarkko Nikula wrote:
On Thu, 30 Jul 2009 15:49:25 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
--- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -257,6 +257,23 @@ int omap_mcbsp_request(unsigned int id) clk_enable(mcbsp->iclk); clk_enable(mcbsp->fclk);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
I'm sure there is a way to avoid all of these added ifdefs in this patch and in patches 7 and 8 as well.
hmmm.. these ifdef's are required because I've put the extra field (for 34xx only) inside an ifdef on their declaration in mcbsp.h. We can remove it there, but will leave a few extra bytes on !omap3xx binaries.
-- Jarkko
* Eduardo Valentin eduardo.valentin@nokia.com [090731 11:08]:
On Thu, Jul 30, 2009 at 08:56:02PM +0200, ext Jarkko Nikula wrote:
On Thu, 30 Jul 2009 15:49:25 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
--- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -257,6 +257,23 @@ int omap_mcbsp_request(unsigned int id) clk_enable(mcbsp->iclk); clk_enable(mcbsp->fclk);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
I'm sure there is a way to avoid all of these added ifdefs in this patch and in patches 7 and 8 as well.
hmmm.. these ifdef's are required because I've put the extra field (for 34xx only) inside an ifdef on their declaration in mcbsp.h. We can remove it there, but will leave a few extra bytes on !omap3xx binaries.
Hmm which field are you talking about? The define does not matter, and the u16 syscon also gets optimized out if 34xx is not selected.
Tony -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 06, 2009 at 02:05:25PM +0200, ext Tony Lindgren wrote:
- Eduardo Valentin eduardo.valentin@nokia.com [090731 11:08]:
On Thu, Jul 30, 2009 at 08:56:02PM +0200, ext Jarkko Nikula wrote:
On Thu, 30 Jul 2009 15:49:25 +0300 Eduardo Valentin eduardo.valentin@nokia.com wrote:
--- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -257,6 +257,23 @@ int omap_mcbsp_request(unsigned int id) clk_enable(mcbsp->iclk); clk_enable(mcbsp->fclk);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
I'm sure there is a way to avoid all of these added ifdefs in this patch and in patches 7 and 8 as well.
hmmm.. these ifdef's are required because I've put the extra field (for 34xx only) inside an ifdef on their declaration in mcbsp.h. We can remove it there, but will leave a few extra bytes on !omap3xx binaries.
Hmm which field are you talking about? The define does not matter, and the u16 syscon also gets optimized out if 34xx is not selected.
dma_op_mode. see patch 0012.
Tony
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
* Eduardo Valentin eduardo.valentin@nokia.com [090730 16:01]:
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
This patch enables the smart idle mode while McBPS is being utilized. Once it's done, force idle mode is taken instead. Apart of it, it also configures what signals will wake mcbsp up.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com
arch/arm/plat-omap/include/mach/mcbsp.h | 17 +++++++++++++++ arch/arm/plat-omap/mcbsp.c | 35 +++++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 77191c5..758ad5c 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -134,6 +134,7 @@ #define OMAP_MCBSP_REG_XCERG 0x74 #define OMAP_MCBSP_REG_XCERH 0x78 #define OMAP_MCBSP_REG_SYSCON 0x8C +#define OMAP_MCBSP_REG_WAKEUPEN 0xA8 #define OMAP_MCBSP_REG_XCCR 0xAC #define OMAP_MCBSP_REG_RCCR 0xB0
@@ -249,8 +250,24 @@ #define RDISABLE 0x0001
/********************** McBSP SYSCONFIG bit definitions ********************/ +#define SIDLEMODE(value) ((value)<<3) +#define ENAWAKEUP 0x0004 #define SOFTRST 0x0002
+/********************** McBSP WAKEUPEN bit definitions *********************/ +#define XEMPTYEOFEN 0x4000 +#define XRDYEN 0x0400 +#define XEOFEN 0x0200 +#define XFSXEN 0x0100 +#define XSYNCERREN 0x0080 +#define RRDYEN 0x0008 +#define REOFEN 0x0004 +#define RFSREN 0x0002 +#define RSYNCERREN 0x0001 +#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \
XSYNCERREN | RRDYEN | REOFEN | RFSREN | \RSYNCERREN)/* we don't do multichannel for now */ struct omap_mcbsp_reg_cfg { u16 spcr2; diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 84cc323..b64896b 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -257,6 +257,23 @@ int omap_mcbsp_request(unsigned int id) clk_enable(mcbsp->iclk); clk_enable(mcbsp->fclk);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
* Enable wakup behavior, smart idle and all wakeups* REVISIT: some wakeups may be unnecessary*/- if (cpu_is_omap34xx()) {
u16 syscon;syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON);syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03));syscon |= (ENAWAKEUP | SIDLEMODE(0x02));OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, WAKEUPEN_ALL);- }
+#endif
- /*
- Make sure that transmitter, receiver and sample-rate generator are
- not running before activating IRQs.
@@ -295,6 +312,7 @@ EXPORT_SYMBOL(omap_mcbsp_request); void omap_mcbsp_free(unsigned int id) { struct omap_mcbsp *mcbsp;
u16 wakeupen;
if (!omap_mcbsp_check_valid_id(id)) { printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
@@ -305,6 +323,23 @@ void omap_mcbsp_free(unsigned int id) if (mcbsp->pdata && mcbsp->pdata->ops && mcbsp->pdata->ops->free) mcbsp->pdata->ops->free(id);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
* Disable wakup behavior, smart idle and all wakeups*/- if (cpu_is_omap34xx()) {
u16 syscon;syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON);syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03));OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);wakeupen = OMAP_MCBSP_READ(mcbsp->io_base, WAKEUPEN);wakeupen &= ~WAKEUPEN_ALL;OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, wakeupen);- }
+#endif
- clk_disable(mcbsp->fclk); clk_disable(mcbsp->iclk);
Looks like you should not need the ifdefs here, cpu_is_omap34xx() already optimizes the code out if not selected.
Regards,
Tony -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
* Tony Lindgren tony@atomide.com [090806 15:00]:
- Eduardo Valentin eduardo.valentin@nokia.com [090730 16:01]:
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
This patch enables the smart idle mode while McBPS is being utilized. Once it's done, force idle mode is taken instead. Apart of it, it also configures what signals will wake mcbsp up.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com
arch/arm/plat-omap/include/mach/mcbsp.h | 17 +++++++++++++++ arch/arm/plat-omap/mcbsp.c | 35 +++++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 77191c5..758ad5c 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -134,6 +134,7 @@ #define OMAP_MCBSP_REG_XCERG 0x74 #define OMAP_MCBSP_REG_XCERH 0x78 #define OMAP_MCBSP_REG_SYSCON 0x8C +#define OMAP_MCBSP_REG_WAKEUPEN 0xA8 #define OMAP_MCBSP_REG_XCCR 0xAC #define OMAP_MCBSP_REG_RCCR 0xB0
@@ -249,8 +250,24 @@ #define RDISABLE 0x0001
/********************** McBSP SYSCONFIG bit definitions ********************/ +#define SIDLEMODE(value) ((value)<<3) +#define ENAWAKEUP 0x0004 #define SOFTRST 0x0002
+/********************** McBSP WAKEUPEN bit definitions *********************/ +#define XEMPTYEOFEN 0x4000 +#define XRDYEN 0x0400 +#define XEOFEN 0x0200 +#define XFSXEN 0x0100 +#define XSYNCERREN 0x0080 +#define RRDYEN 0x0008 +#define REOFEN 0x0004 +#define RFSREN 0x0002 +#define RSYNCERREN 0x0001 +#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \
XSYNCERREN | RRDYEN | REOFEN | RFSREN | \RSYNCERREN)/* we don't do multichannel for now */ struct omap_mcbsp_reg_cfg { u16 spcr2; diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 84cc323..b64896b 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -257,6 +257,23 @@ int omap_mcbsp_request(unsigned int id) clk_enable(mcbsp->iclk); clk_enable(mcbsp->fclk);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
* Enable wakup behavior, smart idle and all wakeups* REVISIT: some wakeups may be unnecessary*/- if (cpu_is_omap34xx()) {
u16 syscon;syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON);syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03));syscon |= (ENAWAKEUP | SIDLEMODE(0x02));OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, WAKEUPEN_ALL);- }
+#endif
- /*
- Make sure that transmitter, receiver and sample-rate generator are
- not running before activating IRQs.
@@ -295,6 +312,7 @@ EXPORT_SYMBOL(omap_mcbsp_request); void omap_mcbsp_free(unsigned int id) { struct omap_mcbsp *mcbsp;
u16 wakeupen;
if (!omap_mcbsp_check_valid_id(id)) { printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
@@ -305,6 +323,23 @@ void omap_mcbsp_free(unsigned int id) if (mcbsp->pdata && mcbsp->pdata->ops && mcbsp->pdata->ops->free) mcbsp->pdata->ops->free(id);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
* Disable wakup behavior, smart idle and all wakeups*/- if (cpu_is_omap34xx()) {
u16 syscon;syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON);syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03));OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);wakeupen = OMAP_MCBSP_READ(mcbsp->io_base, WAKEUPEN);wakeupen &= ~WAKEUPEN_ALL;OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, wakeupen);- }
+#endif
- clk_disable(mcbsp->fclk); clk_disable(mcbsp->iclk);
Looks like you should not need the ifdefs here, cpu_is_omap34xx() already optimizes the code out if not selected.
Oops, sorry looks like Jarkko already made the same comment.
Regards,
Tony
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
-- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 06, 2009 at 02:02:09PM +0200, ext Tony Lindgren wrote:
- Tony Lindgren tony@atomide.com [090806 15:00]:
- Eduardo Valentin eduardo.valentin@nokia.com [090730 16:01]:
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
This patch enables the smart idle mode while McBPS is being utilized. Once it's done, force idle mode is taken instead. Apart of it, it also configures what signals will wake mcbsp up.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com Signed-off-by: Eduardo Valentin eduardo.valentin@nokia.com
arch/arm/plat-omap/include/mach/mcbsp.h | 17 +++++++++++++++ arch/arm/plat-omap/mcbsp.c | 35 +++++++++++++++++++++++++++++++ 2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index 77191c5..758ad5c 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -134,6 +134,7 @@ #define OMAP_MCBSP_REG_XCERG 0x74 #define OMAP_MCBSP_REG_XCERH 0x78 #define OMAP_MCBSP_REG_SYSCON 0x8C +#define OMAP_MCBSP_REG_WAKEUPEN 0xA8 #define OMAP_MCBSP_REG_XCCR 0xAC #define OMAP_MCBSP_REG_RCCR 0xB0
@@ -249,8 +250,24 @@ #define RDISABLE 0x0001
/********************** McBSP SYSCONFIG bit definitions ********************/ +#define SIDLEMODE(value) ((value)<<3) +#define ENAWAKEUP 0x0004 #define SOFTRST 0x0002
+/********************** McBSP WAKEUPEN bit definitions *********************/ +#define XEMPTYEOFEN 0x4000 +#define XRDYEN 0x0400 +#define XEOFEN 0x0200 +#define XFSXEN 0x0100 +#define XSYNCERREN 0x0080 +#define RRDYEN 0x0008 +#define REOFEN 0x0004 +#define RFSREN 0x0002 +#define RSYNCERREN 0x0001 +#define WAKEUPEN_ALL (XEMPTYEOFEN | XRDYEN | XEOFEN | XFSXEN | \
XSYNCERREN | RRDYEN | REOFEN | RFSREN | \RSYNCERREN)/* we don't do multichannel for now */ struct omap_mcbsp_reg_cfg { u16 spcr2; diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index 84cc323..b64896b 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -257,6 +257,23 @@ int omap_mcbsp_request(unsigned int id) clk_enable(mcbsp->iclk); clk_enable(mcbsp->fclk);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
* Enable wakup behavior, smart idle and all wakeups* REVISIT: some wakeups may be unnecessary*/- if (cpu_is_omap34xx()) {
u16 syscon;syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON);syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03));syscon |= (ENAWAKEUP | SIDLEMODE(0x02));OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, WAKEUPEN_ALL);- }
+#endif
- /*
- Make sure that transmitter, receiver and sample-rate generator are
- not running before activating IRQs.
@@ -295,6 +312,7 @@ EXPORT_SYMBOL(omap_mcbsp_request); void omap_mcbsp_free(unsigned int id) { struct omap_mcbsp *mcbsp;
u16 wakeupen;
if (!omap_mcbsp_check_valid_id(id)) { printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
@@ -305,6 +323,23 @@ void omap_mcbsp_free(unsigned int id) if (mcbsp->pdata && mcbsp->pdata->ops && mcbsp->pdata->ops->free) mcbsp->pdata->ops->free(id);
+#ifdef CONFIG_ARCH_OMAP34XX
- /*
* Disable wakup behavior, smart idle and all wakeups*/- if (cpu_is_omap34xx()) {
u16 syscon;syscon = OMAP_MCBSP_READ(mcbsp->io_base, SYSCON);syscon &= ~(ENAWAKEUP | SIDLEMODE(0x03));OMAP_MCBSP_WRITE(mcbsp->io_base, SYSCON, syscon);wakeupen = OMAP_MCBSP_READ(mcbsp->io_base, WAKEUPEN);wakeupen &= ~WAKEUPEN_ALL;OMAP_MCBSP_WRITE(mcbsp->io_base, WAKEUPEN, wakeupen);- }
+#endif
- clk_disable(mcbsp->fclk); clk_disable(mcbsp->iclk);
Looks like you should not need the ifdefs here, cpu_is_omap34xx() already optimizes the code out if not selected.
Oops, sorry looks like Jarkko already made the same comment.
Yes, no problem, I'll collect all comments and resend the series in its v2.
The ifdefs are needed because I've enclosed the extra omap3 fields of struct omap_mcbsp inside a ifdef (following patch). And that will rise a compilation error for other arch's if no ifdefs were put here. But I'll remove the ifdefs from the struct declaration and leave then as extra bytes for arch != omap3.
Regards,
Tony
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 Thursday 30 July 2009 15:49:24 Valentin Eduardo (Nokia-D/Helsinki) wrote:
From: Eero Nurkkala ext-eero.nurkkala@nokia.com
ASoC has an annoying bug letting either L or R channel to be played on L channel. In other words, L and R channels can switch at random. This provides McBSP funtionality that may be used to fix this feature.
Signed-off-by: Eero Nurkkala ext-eero.nurkkala@nokia.com
arch/arm/plat-omap/include/mach/mcbsp.h | 2 + arch/arm/plat-omap/mcbsp.c | 52 +++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h b/arch/arm/plat-omap/include/mach/mcbsp.h index bb154ea..77191c5 100644 --- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -389,6 +389,8 @@ int omap_mcbsp_request(unsigned int id); void omap_mcbsp_free(unsigned int id); void omap_mcbsp_start(unsigned int id); void omap_mcbsp_stop(unsigned int id); +void omap_mcbsp_xmit_enable(unsigned int id, u8 enable); +void omap_mcbsp_recv_enable(unsigned int id, u8 enable); void omap_mcbsp_xmit_word(unsigned int id, u32 word); u32 omap_mcbsp_recv_word(unsigned int id);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c index efa0e01..84cc323 100644 --- a/arch/arm/plat-omap/mcbsp.c +++ b/arch/arm/plat-omap/mcbsp.c @@ -398,6 +398,58 @@ void omap_mcbsp_stop(unsigned int id) } EXPORT_SYMBOL(omap_mcbsp_stop);
+void omap_mcbsp_xmit_enable(unsigned int id, u8 enable) +{
- struct omap_mcbsp *mcbsp;
- void __iomem *io_base;
- u16 w;
- if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
return;- if (!omap_mcbsp_check_valid_id(id)) {
printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);return;- }
- mcbsp = id_to_mcbsp_ptr(id);
- io_base = mcbsp->io_base;
- w = OMAP_MCBSP_READ(io_base, XCCR);
- if (enable)
OMAP_MCBSP_WRITE(io_base, XCCR, w & ~(XDISABLE));- else
OMAP_MCBSP_WRITE(io_base, XCCR, w | XDISABLE);
Have you tried to play with the SPCR2:XRST bit instead of the XCCR:XDISABLE? It places the transmitter to reset, thus disabling it also, furthermore it is available on OMAP1 as well, so we can use the same code there as well...
+} +EXPORT_SYMBOL(omap_mcbsp_xmit_enable);
+void omap_mcbsp_recv_enable(unsigned int id, u8 enable) +{
- struct omap_mcbsp *mcbsp;
- void __iomem *io_base;
- u16 w;
- if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
return;- if (!omap_mcbsp_check_valid_id(id)) {
printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);return;- }
- mcbsp = id_to_mcbsp_ptr(id);
- io_base = mcbsp->io_base;
- w = OMAP_MCBSP_READ(io_base, RCCR);
- if (enable)
OMAP_MCBSP_WRITE(io_base, RCCR, w & ~(RDISABLE));- else
OMAP_MCBSP_WRITE(io_base, RCCR, w | RDISABLE);
Same goes here: can you try the SPCR1:RRST bit here instead of the RCCR:RDISABLE?
+} +EXPORT_SYMBOL(omap_mcbsp_recv_enable);
/* polled mcbsp i/o operations */ int omap_mcbsp_pollwrite(unsigned int id, u16 buf) {
On Thu, Jul 30, 2009 at 03:49:23PM +0300, Eduardo Valentin wrote:
Patches 1-15 are McBSP changes and, for this reason, are intended to be include in linux-omap tree. Patches 16-20 are OMAP ASoC driver changes, so, they are for alsa-devel.
I'm OK with the ASoC changes. It looks like there are some dependencies on the OMAP changes in there so they should probably go via the OMAP tree?
On Thu, 30 Jul 2009 14:52:57 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Jul 30, 2009 at 03:49:23PM +0300, Eduardo Valentin wrote:
Patches 1-15 are McBSP changes and, for this reason, are intended to be include in linux-omap tree. Patches 16-20 are OMAP ASoC driver changes, so, they are for alsa-devel.
I'm OK with the ASoC changes. It looks like there are some dependencies on the OMAP changes in there so they should probably go via the OMAP tree?
Is Peter available or having a vacation? He would have better possibilities to say and test the PM changes. Now omap_pcm_pointer is very accurate and I would like that it remains accurate unless user especially wants low-power over it.
I post few, more like minor notes than show stoppers to some of these patches.
My wife and kids are having vacation so my ability to review, test and understand those more fundamental changes is somewhat reduced.
On Thu, Jul 30, 2009 at 09:55:46PM +0300, Jarkko Nikula wrote:
On Thu, 30 Jul 2009 14:52:57 +0100 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
I'm OK with the ASoC changes. It looks like there are some dependencies on the OMAP changes in there so they should probably go via the OMAP tree?
Is Peter available or having a vacation? He would have better possibilities to say and test the PM changes. Now omap_pcm_pointer is very accurate and I would like that it remains accurate unless user especially wants low-power over it.
No idea; I've not seen him recently but there's not been much TWL4030 or OMAP activity so that's not surprising. It'd be nice (but not essential) to be able to automatically dial back the accuracy when given enormous buffers to play since that's normally a good indication that the data is non-critical.
My wife and kids are having vacation so my ability to review, test and understand those more fundamental changes is somewhat reduced.
I've no OMAP hardware I can readily do anything with so you're probably still ahead of me for the OMAP-specifics.
On Thursday 30 July 2009 21:55:46 ext Jarkko Nikula wrote:
On Thu, 30 Jul 2009 14:52:57 +0100
Is Peter available or having a vacation? He would have better possibilities to say and test the PM changes. Now omap_pcm_pointer is very accurate and I would like that it remains accurate unless user especially wants low-power over it.
I was on vacation for the past four weeks, but now I'm back. Slowly going through the mails.
I'll go through the series, but generally I think that the old element mode should be selected by default on OMAP3 and give possibility for changing it to a more PM friendly mode if necessary . I'm not sure which mode is the default after this series..
participants (8)
-
Eduardo Valentin -
Eero Nurkkala -
ext-Eero.Nurkkala＠nokia.com
-
Jarkko Nikula -
Kai Vehmanen -
Mark Brown -
Peter Ujfalusi -
Tony Lindgren