[PATCH 01/20] OMAP: McBSP: Provide functions for ASoC frame syncronization

[PATCH 01/20] OMAP: McBSP: Provide functions for ASoC frame syncronization

[Eduardo Valentin]

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)
 {
-- 
1.6.2.GIT

[PATCH 02/20] OMAP: McBSP: Wakeups utilized

[Eduardo Valentin]

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);
 
-- 
1.6.2.GIT

Re: [PATCH 01/20] OMAP: McBSP: Provide functions for ASoC frame syncronization

[Peter Ujfalusi]

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)
>  {

-- 
Péter

[PATCH 03/20] OMAP: McBSP: Change wakeup signals

[Eduardo Valentin]

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 {
-- 
1.6.2.GIT

[PATCH 04/20] OMAP: McBSP: Add IRQEN, IRQSTATUS, THRESHOLD2 and THRESHOLD1 registers.

[Eduardo Valentin]

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
-- 
1.6.2.GIT

[PATCH 05/20] OMAP: McBSP: Retain McBSP FCLK clockactivity

[Eduardo Valentin]

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);
-- 
1.6.2.GIT

[PATCH 06/20] OMAP: McBSP: Use appropriate value for startup delay

[Eduardo Valentin]

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);
-- 
1.6.2.GIT

[PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler

[Eduardo Valentin]

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().
-- 
1.6.2.GIT

[PATCH 08/20] OMAP: McBSP: Create and export max_(r|t)x_thres property

[Eduardo Valentin]

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);
-- 
1.6.2.GIT

[PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5

[Eduardo Valentin]

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)
-- 
1.6.2.GIT

[PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols

[Eduardo Valentin]

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);
-- 
1.6.2.GIT

[PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Eduardo Valentin]

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
 
-- 
1.6.2.GIT

[PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold

[Eduardo Valentin]

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);
-- 
1.6.2.GIT

[PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode

[Eduardo Valentin]

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
 
-- 
1.6.2.GIT

[PATCH 14/20] OMAP: McBSP: Disable all wakeups upon exit

[Eduardo Valentin]

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
 
-- 
1.6.2.GIT

[PATCH 15/20] OMAP: McBSP: Let element DMA mode hit retention also

[Eduardo Valentin]

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);
-- 
1.6.2.GIT

[PATCH 16/20] ASoC: OMAP: Use McBSP threshold again

[Eduardo Valentin]

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);
 
-- 
1.6.2.GIT

[PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned

[Eduardo Valentin]

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,
-- 
1.6.2.GIT

[PATCH 18/20] ASoC: OMAP: Enable DMA burst mode

[Eduardo Valentin]

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;
 }
 
-- 
1.6.2.GIT

[PATCH 19/20] ASoC: OMAP: Use DMA operating mode of McBSP

[Eduardo Valentin]

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;
 
-- 
1.6.2.GIT

[PATCH 20/20] ASoC: Always syncronize audio transfers on frames

[Eduardo Valentin]

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;
-- 
1.6.2.GIT

Re: [PATCH 20/20] ASoC: Always syncronize audio transfers on frames

[Jarkko Nikula]

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!

-- 
Jarkko

Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again

[Jarkko Nikula]

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);
> +		else
> +			omap_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.


-- 
Jarkko

Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again

[Eduardo Valentin]

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);
> > +		else
> > +			omap_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

-- 
Eduardo Valentin

Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again

[Jarkko Nikula]

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.


-- 
Jarkko

Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again

[Eduardo Valentin]

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

-- 
Eduardo Valentin

Re: [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold

[Eduardo Valentin]

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);
> +		else
> +			syscon |= 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

-- 
Eduardo Valentin

Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Mark Brown]

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)?

Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Eduardo Valentin]

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.



-- 
Eduardo Valentin

Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Mark Brown]

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.

Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Eduardo Valentin]

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.


-- 
Eduardo Valentin

Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Jarkko Nikula]

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;
>  		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;
>  	}

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.


-- 
Jarkko

Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Peter Ujfalusi]

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.

-- 
Péter

RE: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[ext-Eero.Nurkkala]

>>
>> 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 --
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

Re: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Eduardo Valentin]

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

-- 
Eduardo Valentin
--
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

Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Jarkko Nikula]

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 :-)


-- 
Jarkko

Re: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Eero Nurkkala]

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 :-)
> 
> 

Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Jarkko Nikula]

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


-- 
Jarkko

Re: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Eero Nurkkala]

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
> 
> 

Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection

[Peter Ujfalusi]

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

-- 
Péter

snd_pcm_delay, hw buffers and driver api (was: Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection)

[Kai Vehmanen]

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.

Re: snd_pcm_delay, hw buffers and driver api (was: Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection)

[Mark Brown]

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.

Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5

[Jarkko Nikula]

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?

-- 
Jarkko

Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5

[Eduardo Valentin]

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

-- 
Eduardo Valentin

Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5

[Jarkko Nikula]

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).

-- 
Jarkko

Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5

[Eduardo Valentin]

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

-- 
Eduardo Valentin

Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5

[Eduardo Valentin]

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

Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5

[Jarkko Nikula]

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?

-- 
Jarkko

Re: [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler

[Tony Lindgren]

* 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

Re: [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler

[ext-Eero.Nurkkala]

>>
>> +/********************** 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=arch/arm/plat-omap/include/mach/mcbsp.h;h=bb154ea76769509a7937c4ba472e8d04c5bf41d3;hb=HEAD

to follow the file format exactly, it'd need to be in form of 0x ?

- Eero

Re: [PATCH 06/20] OMAP: McBSP: Use appropriate value for startup delay

[Jarkko Nikula]

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

Re: [PATCH 06/20] OMAP: McBSP: Use appropriate value for startup delay

[ext-Eero.Nurkkala]

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

Re: [PATCH 06/20] OMAP: McBSP: Use appropriate value for startup delay

[Jarkko Nikula]

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.

-- 
Jarkko

Re: [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler

[Tony Lindgren]

* 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=arch/arm/plat-omap/include/mach/mcbsp.h;h=bb154ea76769509a7937c4ba472e8d04c5bf41d3;hb=HEAD
> 
> 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

Re: [PATCH 03/20] OMAP: McBSP: Change wakeup signals

[Peter Ujfalusi]

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.


-- 
Péter

Re: [PATCH 02/20] OMAP: McBSP: Wakeups utilized

[Jarkko Nikula]

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.


-- 
Jarkko

Re: [PATCH 02/20] OMAP: McBSP: Wakeups utilized

[Eduardo Valentin]

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

Re: [PATCH 02/20] OMAP: McBSP: Wakeups utilized

[Eduardo Valentin]

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

Re: [PATCH 02/20] OMAP: McBSP: Wakeups utilized

[Tony Lindgren]

* 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

Re: [PATCH 02/20] OMAP: McBSP: Wakeups utilized

[Tony Lindgren]

* 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

Re: [PATCH 02/20] OMAP: McBSP: Wakeups utilized

[Eduardo Valentin]

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

-- 
Eduardo Valentin

Re: [PATCH 02/20] OMAP: McBSP: Wakeups utilized

[Tony Lindgren]

* 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

Re: [PATCH 00/20] OMAP ASoC changes in DMA utilization

[Mark Brown]

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?

Re: [PATCH 00/20] OMAP ASoC changes in DMA utilization

[Jarkko Nikula]

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.


-- 
Jarkko

Re: [PATCH 00/20] OMAP ASoC changes in DMA utilization

[Mark Brown]

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.

Re: [PATCH 00/20] OMAP ASoC changes in DMA utilization

[Peter Ujfalusi]

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..

-- 
Péter