* [PATCH 08/20] OMAP: McBSP: Create and export max_(r|t)x_thres property
2009-07-30 12:49 ` Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Eduardo Valentin
2009-07-30 12:49 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
2009-07-30 12:49 ` [PATCH 08/20] OMAP: McBSP: Create and export max_(r|t)x_thres property Eduardo Valentin
` (2 subsequent siblings)
3 siblings, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, 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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5
2009-07-30 12:49 ` [PATCH 08/20] OMAP: McBSP: Create and export max_(r|t)x_thres property Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel; +Cc: Peter Ujfalusi, Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
2009-07-30 12:49 ` [PATCH 08/20] OMAP: McBSP: Create and export max_(r|t)x_thres property Eduardo Valentin
2009-07-30 12:49 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols Eduardo Valentin
` (3 more replies)
1 sibling, 4 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols
2009-07-30 12:49 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
2009-07-30 12:49 ` [PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols Eduardo Valentin
` (2 subsequent siblings)
3 siblings, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, 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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 12:49 ` [PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold Eduardo Valentin
` (5 more replies)
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
1 sibling, 6 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, 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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` Eduardo Valentin
` (4 subsequent siblings)
5 siblings, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Eduardo Valentin, Peter Ujfalusi,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
2009-07-30 12:49 ` [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode Eduardo Valentin
` (3 more replies)
2009-07-30 13:04 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Mark Brown
` (3 subsequent siblings)
5 siblings, 4 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, 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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode
2009-07-30 12:49 ` Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 14/20] OMAP: McBSP: Disable all wakeups upon exit Eduardo Valentin
2009-07-30 12:49 ` [PATCH 14/20] OMAP: McBSP: Disable all wakeups upon exit Eduardo Valentin
2009-07-30 12:49 ` [PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode Eduardo Valentin
` (2 subsequent siblings)
3 siblings, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, Eero Nurkkala
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 14/20] OMAP: McBSP: Disable all wakeups upon exit
2009-07-30 12:49 ` [PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 15/20] OMAP: McBSP: Let element DMA mode hit retention also Eduardo Valentin
2009-07-30 12:49 ` [PATCH 15/20] OMAP: McBSP: Let element DMA mode hit retention also Eduardo Valentin
2009-07-30 12:49 ` [PATCH 14/20] OMAP: McBSP: Disable all wakeups upon exit Eduardo Valentin
1 sibling, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, Eero Nurkkala
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 15/20] OMAP: McBSP: Let element DMA mode hit retention also
2009-07-30 12:49 ` [PATCH 14/20] OMAP: McBSP: Disable all wakeups upon exit Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again Eduardo Valentin
2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 15/20] OMAP: McBSP: Let element DMA mode hit retention also Eduardo Valentin
1 sibling, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, Eero Nurkkala
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
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again
2009-07-30 12:49 ` [PATCH 15/20] OMAP: McBSP: Let element DMA mode hit retention also Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned Eduardo Valentin
` (3 more replies)
2009-07-30 12:49 ` Eduardo Valentin
1 sibling, 4 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, 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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned
2009-07-30 12:49 ` [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 18/20] ASoC: OMAP: Enable DMA burst mode Eduardo Valentin
2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned Eduardo Valentin
` (2 subsequent siblings)
3 siblings, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, 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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 18/20] ASoC: OMAP: Enable DMA burst mode
2009-07-30 12:49 ` [PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Eduardo Valentin, Peter Ujfalusi,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 18/20] ASoC: OMAP: Enable DMA burst mode
2009-07-30 12:49 ` [PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned Eduardo Valentin
2009-07-30 12:49 ` [PATCH 18/20] ASoC: OMAP: Enable DMA burst mode Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 19/20] ASoC: OMAP: Use DMA operating mode of McBSP Eduardo Valentin
2009-07-30 12:49 ` [PATCH 19/20] ASoC: OMAP: Use DMA operating mode of McBSP Eduardo Valentin
1 sibling, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, 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
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 19/20] ASoC: OMAP: Use DMA operating mode of McBSP
2009-07-30 12:49 ` Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 20/20] ASoC: Always syncronize audio transfers on frames Eduardo Valentin
2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 19/20] ASoC: OMAP: Use DMA operating mode of McBSP Eduardo Valentin
1 sibling, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, 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
^ permalink raw reply related [flat|nested] 115+ messages in thread* [PATCH 20/20] ASoC: Always syncronize audio transfers on frames
2009-07-30 12:49 ` [PATCH 19/20] ASoC: OMAP: Use DMA operating mode of McBSP Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 18:57 ` Jarkko Nikula
2009-07-30 18:57 ` Jarkko Nikula
2009-07-30 12:49 ` Eduardo Valentin
1 sibling, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: linux-omap, alsa-devel
Cc: Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, Eero Nurkkala
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* Re: [PATCH 20/20] ASoC: Always syncronize audio transfers on frames
2009-07-30 12:49 ` [PATCH 20/20] ASoC: Always syncronize audio transfers on frames Eduardo Valentin
@ 2009-07-30 18:57 ` Jarkko Nikula
2009-07-30 18:57 ` Jarkko Nikula
1 sibling, 0 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-07-30 18:57 UTC (permalink / raw)
To: alsa-devel
Cc: Eero Nurkkala, linux-omap, Peter Ujfalusi, alsa-devel,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 20/20] ASoC: Always syncronize audio transfers on frames
2009-07-30 12:49 ` [PATCH 20/20] ASoC: Always syncronize audio transfers on frames Eduardo Valentin
2009-07-30 18:57 ` Jarkko Nikula
@ 2009-07-30 18:57 ` Jarkko Nikula
1 sibling, 0 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-07-30 18:57 UTC (permalink / raw)
To: Eduardo Valentin
Cc: linux-omap, alsa-devel, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi, Eero Nurkkala
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* [PATCH 20/20] ASoC: Always syncronize audio transfers on frames
2009-07-30 12:49 ` [PATCH 19/20] ASoC: OMAP: Use DMA operating mode of McBSP Eduardo Valentin
2009-07-30 12:49 ` [PATCH 20/20] ASoC: Always syncronize audio transfers on frames Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Peter Ujfalusi, Eero Nurkkala,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 19/20] ASoC: OMAP: Use DMA operating mode of McBSP
2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 19/20] ASoC: OMAP: Use DMA operating mode of McBSP Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Eduardo Valentin, Peter Ujfalusi,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned
2009-07-30 12:49 ` [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again Eduardo Valentin
2009-07-30 12:49 ` [PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-08-05 7:48 ` [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again Jarkko Nikula
2009-08-05 7:48 ` Jarkko Nikula
3 siblings, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Eduardo Valentin, Peter Ujfalusi,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again
2009-07-30 12:49 ` [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again Eduardo Valentin
2009-07-30 12:49 ` [PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned Eduardo Valentin
2009-07-30 12:49 ` [PATCH 17/20] ASoC: OMAP: Make DMA 64 aligned Eduardo Valentin
@ 2009-08-05 7:48 ` Jarkko Nikula
2009-08-05 7:48 ` Jarkko Nikula
3 siblings, 0 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-08-05 7:48 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap, Peter Ujfalusi, alsa-devel,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again
2009-07-30 12:49 ` [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again Eduardo Valentin
` (2 preceding siblings ...)
2009-08-05 7:48 ` [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again Jarkko Nikula
@ 2009-08-05 7:48 ` Jarkko Nikula
2009-08-10 8:53 ` Eduardo Valentin
2009-08-10 8:53 ` Eduardo Valentin
3 siblings, 2 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-08-05 7:48 UTC (permalink / raw)
To: Eduardo Valentin
Cc: linux-omap, alsa-devel, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again
2009-08-05 7:48 ` Jarkko Nikula
@ 2009-08-10 8:53 ` Eduardo Valentin
2009-08-10 8:53 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-10 8:53 UTC (permalink / raw)
To: alsa-devel
Cc: Ujfalusi Peter (Nokia-D/Tampere), linux-omap@vger.kernel.org,
Valentin Eduardo (Nokia-D/Helsinki), alsa-devel@vger.kernel.org,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again
2009-08-05 7:48 ` Jarkko Nikula
2009-08-10 8:53 ` Eduardo Valentin
@ 2009-08-10 8:53 ` Eduardo Valentin
2009-08-11 5:34 ` Jarkko Nikula
1 sibling, 1 reply; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-10 8:53 UTC (permalink / raw)
To: ext Jarkko Nikula
Cc: Valentin Eduardo (Nokia-D/Helsinki), linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again
2009-08-10 8:53 ` Eduardo Valentin
@ 2009-08-11 5:34 ` Jarkko Nikula
2009-08-11 6:22 ` Eduardo Valentin
2009-08-11 6:22 ` Eduardo Valentin
0 siblings, 2 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-08-11 5:34 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap@vger.kernel.org, Ujfalusi Peter (Nokia-D/Tampere),
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again
2009-08-11 5:34 ` Jarkko Nikula
@ 2009-08-11 6:22 ` Eduardo Valentin
2009-08-11 6:22 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-11 6:22 UTC (permalink / raw)
To: alsa-devel
Cc: Ujfalusi Peter (Nokia-D/Tampere), linux-omap@vger.kernel.org,
Valentin Eduardo (Nokia-D/Helsinki), alsa-devel@vger.kernel.org,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again
2009-08-11 5:34 ` Jarkko Nikula
2009-08-11 6:22 ` Eduardo Valentin
@ 2009-08-11 6:22 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-11 6:22 UTC (permalink / raw)
To: ext Jarkko Nikula
Cc: Valentin Eduardo (Nokia-D/Helsinki), linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again
2009-07-30 12:49 ` [PATCH 15/20] OMAP: McBSP: Let element DMA mode hit retention also Eduardo Valentin
2009-07-30 12:49 ` [PATCH 16/20] ASoC: OMAP: Use McBSP threshold again Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Eduardo Valentin, Peter Ujfalusi,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 15/20] OMAP: McBSP: Let element DMA mode hit retention also
2009-07-30 12:49 ` [PATCH 14/20] OMAP: McBSP: Disable all wakeups upon exit Eduardo Valentin
2009-07-30 12:49 ` [PATCH 15/20] OMAP: McBSP: Let element DMA mode hit retention also Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Peter Ujfalusi, Eero Nurkkala,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 14/20] OMAP: McBSP: Disable all wakeups upon exit
2009-07-30 12:49 ` [PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode Eduardo Valentin
2009-07-30 12:49 ` [PATCH 14/20] OMAP: McBSP: Disable all wakeups upon exit Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Peter Ujfalusi, Eero Nurkkala,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode
2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-08-06 12:00 ` [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold Eduardo Valentin
2009-08-06 12:00 ` Eduardo Valentin
3 siblings, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Peter Ujfalusi, Eero Nurkkala,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* Re: [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold
2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode Eduardo Valentin
2009-07-30 12:49 ` [PATCH 13/20] OMAP: McBSP: Do not enable wakeups for no-idle mode Eduardo Valentin
@ 2009-08-06 12:00 ` Eduardo Valentin
2009-08-06 12:00 ` Eduardo Valentin
3 siblings, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-06 12:00 UTC (permalink / raw)
To: Valentin Eduardo (Nokia-D/Helsinki)
Cc: linux-omap@vger.kernel.org, alsa-devel@vger.kernel.org,
Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold
2009-07-30 12:49 ` Eduardo Valentin
` (2 preceding siblings ...)
2009-08-06 12:00 ` [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold Eduardo Valentin
@ 2009-08-06 12:00 ` Eduardo Valentin
3 siblings, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-06 12:00 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap@vger.kernel.org, Ujfalusi Peter (Nokia-D/Tampere),
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
2009-07-30 12:49 ` [PATCH 12/20] OMAP: McBSP: Configure NO IDLE mode for DMA mode different of threshold Eduardo Valentin
2009-07-30 12:49 ` Eduardo Valentin
@ 2009-07-30 13:04 ` Mark Brown
2009-07-30 13:04 ` Mark Brown
` (2 subsequent siblings)
5 siblings, 0 replies; 115+ messages in thread
From: Mark Brown @ 2009-07-30 13:04 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap, Peter Ujfalusi, alsa-devel,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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)?
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
` (2 preceding siblings ...)
2009-07-30 13:04 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Mark Brown
@ 2009-07-30 13:04 ` Mark Brown
2009-07-30 13:28 ` Eduardo Valentin
2009-07-30 13:28 ` Eduardo Valentin
2009-08-05 7:39 ` Jarkko Nikula
2009-08-05 7:39 ` Jarkko Nikula
5 siblings, 2 replies; 115+ messages in thread
From: Mark Brown @ 2009-07-30 13:04 UTC (permalink / raw)
To: Eduardo Valentin
Cc: linux-omap, alsa-devel, Jarkko Nikula,
Nurkkala Eero.An (EXT-Offcode/Oulu), Peter Ujfalusi
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)?
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 13:04 ` Mark Brown
@ 2009-07-30 13:28 ` Eduardo Valentin
2009-07-30 13:47 ` Mark Brown
2009-07-30 13:47 ` Mark Brown
2009-07-30 13:28 ` Eduardo Valentin
1 sibling, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 13:28 UTC (permalink / raw)
To: ext Mark Brown
Cc: Valentin Eduardo (Nokia-D/Helsinki), linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org, Jarkko Nikula,
Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 13:28 ` Eduardo Valentin
@ 2009-07-30 13:47 ` Mark Brown
2009-07-30 13:47 ` Mark Brown
1 sibling, 0 replies; 115+ messages in thread
From: Mark Brown @ 2009-07-30 13:47 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap@vger.kernel.org, Ujfalusi Peter (Nokia-D/Tampere),
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu)
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.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 13:28 ` Eduardo Valentin
2009-07-30 13:47 ` Mark Brown
@ 2009-07-30 13:47 ` Mark Brown
2009-08-03 10:15 ` Eduardo Valentin
2009-08-03 10:15 ` Eduardo Valentin
1 sibling, 2 replies; 115+ messages in thread
From: Mark Brown @ 2009-07-30 13:47 UTC (permalink / raw)
To: Eduardo Valentin
Cc: linux-omap@vger.kernel.org, alsa-devel@vger.kernel.org,
Jarkko Nikula, Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 13:47 ` Mark Brown
@ 2009-08-03 10:15 ` Eduardo Valentin
2009-08-03 10:15 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-03 10:15 UTC (permalink / raw)
To: alsa-devel
Cc: Ujfalusi Peter (Nokia-D/Tampere),
Valentin Eduardo (Nokia-D/Helsinki),
Nurkkala Eero.An (EXT-Offcode/Oulu), linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 13:47 ` Mark Brown
2009-08-03 10:15 ` Eduardo Valentin
@ 2009-08-03 10:15 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-03 10:15 UTC (permalink / raw)
To: ext Mark Brown
Cc: Valentin Eduardo (Nokia-D/Helsinki), linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org, Jarkko Nikula,
Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 13:04 ` Mark Brown
2009-07-30 13:28 ` Eduardo Valentin
@ 2009-07-30 13:28 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 13:28 UTC (permalink / raw)
To: alsa-devel
Cc: Ujfalusi Peter (Nokia-D/Tampere),
Valentin Eduardo (Nokia-D/Helsinki),
Nurkkala Eero.An (EXT-Offcode/Oulu), linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
` (3 preceding siblings ...)
2009-07-30 13:04 ` Mark Brown
@ 2009-08-05 7:39 ` Jarkko Nikula
2009-08-05 7:39 ` Jarkko Nikula
5 siblings, 0 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-08-05 7:39 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap, Peter Ujfalusi, alsa-devel,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
` (4 preceding siblings ...)
2009-08-05 7:39 ` Jarkko Nikula
@ 2009-08-05 7:39 ` Jarkko Nikula
2009-08-05 8:58 ` Peter Ujfalusi
5 siblings, 1 reply; 115+ messages in thread
From: Jarkko Nikula @ 2009-08-05 7:39 UTC (permalink / raw)
To: Eduardo Valentin
Cc: linux-omap, alsa-devel, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-08-05 7:39 ` Jarkko Nikula
@ 2009-08-05 8:58 ` Peter Ujfalusi
2009-08-06 18:15 ` [alsa-devel] " ext-Eero.Nurkkala
0 siblings, 1 reply; 115+ messages in thread
From: Peter Ujfalusi @ 2009-08-05 8:58 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap@vger.kernel.org, alsa-devel@vger.kernel.org,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-08-05 8:58 ` Peter Ujfalusi
@ 2009-08-06 18:15 ` ext-Eero.Nurkkala
2009-08-07 13:11 ` Eduardo Valentin
2009-08-11 6:04 ` Jarkko Nikula
0 siblings, 2 replies; 115+ messages in thread
From: ext-Eero.Nurkkala @ 2009-08-06 18:15 UTC (permalink / raw)
To: peter.ujfalusi, alsa-devel; +Cc: jhnikula, linux-omap, alsa-devel
>>
>> 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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-08-06 18:15 ` [alsa-devel] " ext-Eero.Nurkkala
@ 2009-08-07 13:11 ` Eduardo Valentin
2009-08-11 6:04 ` Jarkko Nikula
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-07 13:11 UTC (permalink / raw)
To: Nurkkala Eero.An (EXT-Offcode/Oulu)
Cc: Ujfalusi Peter (Nokia-D/Tampere), alsa-devel@alsa-project.org,
jhnikula@gmail.com, linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-08-06 18:15 ` [alsa-devel] " ext-Eero.Nurkkala
2009-08-07 13:11 ` Eduardo Valentin
@ 2009-08-11 6:04 ` Jarkko Nikula
2009-08-11 6:18 ` [alsa-devel] " Eero Nurkkala
1 sibling, 1 reply; 115+ messages in thread
From: Jarkko Nikula @ 2009-08-11 6:04 UTC (permalink / raw)
To: ext-Eero.Nurkkala; +Cc: alsa-devel, linux-omap, peter.ujfalusi, alsa-devel
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-08-11 6:04 ` Jarkko Nikula
@ 2009-08-11 6:18 ` Eero Nurkkala
2009-08-12 11:45 ` Jarkko Nikula
0 siblings, 1 reply; 115+ messages in thread
From: Eero Nurkkala @ 2009-08-11 6:18 UTC (permalink / raw)
To: ext Jarkko Nikula
Cc: Ujfalusi Peter (Nokia-D/Tampere), alsa-devel@alsa-project.org,
linux-omap@vger.kernel.org, alsa-devel@vger.kernel.org
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 :-)
>
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-08-11 6:18 ` [alsa-devel] " Eero Nurkkala
@ 2009-08-12 11:45 ` Jarkko Nikula
2009-08-12 11:48 ` [alsa-devel] " Eero Nurkkala
2009-08-13 20:46 ` snd_pcm_delay, hw buffers and driver api (was: Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection) Kai Vehmanen
0 siblings, 2 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-08-12 11:45 UTC (permalink / raw)
To: ext-eero.nurkkala
Cc: alsa-devel@alsa-project.org, linux-omap@vger.kernel.org,
Ujfalusi Peter (Nokia-D/Tampere), alsa-devel@vger.kernel.org
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [alsa-devel] [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-08-12 11:45 ` Jarkko Nikula
@ 2009-08-12 11:48 ` Eero Nurkkala
2009-08-13 6:01 ` Peter Ujfalusi
2009-08-13 20:46 ` snd_pcm_delay, hw buffers and driver api (was: Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection) Kai Vehmanen
1 sibling, 1 reply; 115+ messages in thread
From: Eero Nurkkala @ 2009-08-12 11:48 UTC (permalink / raw)
To: ext Jarkko Nikula
Cc: Ujfalusi Peter (Nokia-D/Tampere), alsa-devel@alsa-project.org,
linux-omap@vger.kernel.org, alsa-devel@vger.kernel.org
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
>
>
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-08-12 11:48 ` [alsa-devel] " Eero Nurkkala
@ 2009-08-13 6:01 ` Peter Ujfalusi
0 siblings, 0 replies; 115+ messages in thread
From: Peter Ujfalusi @ 2009-08-13 6:01 UTC (permalink / raw)
To: Nurkkala Eero.An (EXT-Offcode/Oulu)
Cc: alsa-devel@alsa-project.org, linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* snd_pcm_delay, hw buffers and driver api (was: Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection)
2009-08-12 11:45 ` Jarkko Nikula
2009-08-12 11:48 ` [alsa-devel] " Eero Nurkkala
@ 2009-08-13 20:46 ` Kai Vehmanen
2009-08-13 20:59 ` Mark Brown
1 sibling, 1 reply; 115+ messages in thread
From: Kai Vehmanen @ 2009-08-13 20:46 UTC (permalink / raw)
To: alsa-devel@alsa-project.org
Cc: Ujfalusi Peter (Nokia-D/Tampere), alsa-devel@vger.kernel.org,
ext-eero.nurkkala
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.
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: snd_pcm_delay, hw buffers and driver api (was: Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection)
2009-08-13 20:46 ` snd_pcm_delay, hw buffers and driver api (was: Re: [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection) Kai Vehmanen
@ 2009-08-13 20:59 ` Mark Brown
0 siblings, 0 replies; 115+ messages in thread
From: Mark Brown @ 2009-08-13 20:59 UTC (permalink / raw)
To: Kai Vehmanen
Cc: alsa-devel@alsa-project.org, Ujfalusi Peter (Nokia-D/Tampere),
alsa-devel@vger.kernel.org, ext-eero.nurkkala
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.
^ permalink raw reply [flat|nested] 115+ messages in thread
* [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection
2009-07-30 12:49 ` [PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols Eduardo Valentin
2009-07-30 12:49 ` [PATCH 11/20] OMAP: McBSP: Add link DMA mode selection Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Eduardo Valentin, Peter Ujfalusi,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread
* [PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols
2009-07-30 12:49 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
2009-07-30 12:49 ` [PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 18:57 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Jarkko Nikula
2009-07-30 18:57 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Jarkko Nikula
3 siblings, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Eduardo Valentin, Peter Ujfalusi,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5
2009-07-30 12:49 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
2009-07-30 12:49 ` [PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols Eduardo Valentin
2009-07-30 12:49 ` [PATCH 10/20] OMAP: McBSP: Rename thres sysfs symbols Eduardo Valentin
@ 2009-07-30 18:57 ` Jarkko Nikula
2009-07-30 18:57 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Jarkko Nikula
3 siblings, 0 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-07-30 18:57 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap, Peter Ujfalusi, alsa-devel,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
2009-07-30 12:49 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
` (2 preceding siblings ...)
2009-07-30 18:57 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Jarkko Nikula
@ 2009-07-30 18:57 ` Jarkko Nikula
2009-07-31 7:58 ` Eduardo Valentin
2009-07-31 7:58 ` Eduardo Valentin
3 siblings, 2 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-07-30 18:57 UTC (permalink / raw)
To: Eduardo Valentin
Cc: linux-omap, alsa-devel, Nurkkala Eero.An (EXT-Offcode/Oulu),
Peter Ujfalusi
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
2009-07-30 18:57 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Jarkko Nikula
@ 2009-07-31 7:58 ` Eduardo Valentin
2009-07-31 17:26 ` Jarkko Nikula
2009-07-31 17:26 ` Jarkko Nikula
2009-07-31 7:58 ` Eduardo Valentin
1 sibling, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-31 7:58 UTC (permalink / raw)
To: ext Jarkko Nikula
Cc: Valentin Eduardo (Nokia-D/Helsinki), linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
2009-07-31 7:58 ` Eduardo Valentin
@ 2009-07-31 17:26 ` Jarkko Nikula
2009-08-03 8:11 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Eduardo Valentin
2009-08-03 8:11 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
2009-07-31 17:26 ` Jarkko Nikula
1 sibling, 2 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-07-31 17:26 UTC (permalink / raw)
To: eduardo.valentin
Cc: linux-omap@vger.kernel.org, alsa-devel@vger.kernel.org,
Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5
2009-07-31 17:26 ` Jarkko Nikula
@ 2009-08-03 8:11 ` Eduardo Valentin
2009-08-03 8:11 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-03 8:11 UTC (permalink / raw)
To: alsa-devel
Cc: Ujfalusi Peter (Nokia-D/Tampere), linux-omap@vger.kernel.org,
Valentin Eduardo (Nokia-D/Helsinki), alsa-devel@vger.kernel.org,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
2009-07-31 17:26 ` Jarkko Nikula
2009-08-03 8:11 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Eduardo Valentin
@ 2009-08-03 8:11 ` Eduardo Valentin
2009-08-03 8:36 ` Jarkko Nikula
2009-08-03 8:36 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Jarkko Nikula
1 sibling, 2 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-03 8:11 UTC (permalink / raw)
To: ext Jarkko Nikula
Cc: Valentin Eduardo (Nokia-D/Helsinki), linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
2009-08-03 8:11 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
@ 2009-08-03 8:36 ` Jarkko Nikula
2009-08-03 8:36 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Eduardo Valentin
2009-08-03 8:36 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
2009-08-03 8:36 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Jarkko Nikula
1 sibling, 2 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-08-03 8:36 UTC (permalink / raw)
To: eduardo.valentin
Cc: linux-omap@vger.kernel.org, alsa-devel@vger.kernel.org,
Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5
2009-08-03 8:36 ` Jarkko Nikula
@ 2009-08-03 8:36 ` Eduardo Valentin
2009-08-03 8:36 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-03 8:36 UTC (permalink / raw)
To: alsa-devel
Cc: Ujfalusi Peter (Nokia-D/Tampere), linux-omap@vger.kernel.org,
Valentin Eduardo (Nokia-D/Helsinki), alsa-devel@vger.kernel.org,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5
2009-08-03 8:36 ` Jarkko Nikula
2009-08-03 8:36 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5 Eduardo Valentin
@ 2009-08-03 8:36 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-08-03 8:36 UTC (permalink / raw)
To: ext Jarkko Nikula
Cc: Valentin Eduardo (Nokia-D/Helsinki), linux-omap@vger.kernel.org,
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu),
Ujfalusi Peter (Nokia-D/Tampere)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5
2009-08-03 8:11 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Eduardo Valentin
2009-08-03 8:36 ` Jarkko Nikula
@ 2009-08-03 8:36 ` Jarkko Nikula
1 sibling, 0 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-08-03 8:36 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap@vger.kernel.org, Ujfalusi Peter (Nokia-D/Tampere),
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5
2009-07-31 7:58 ` Eduardo Valentin
2009-07-31 17:26 ` Jarkko Nikula
@ 2009-07-31 17:26 ` Jarkko Nikula
1 sibling, 0 replies; 115+ messages in thread
From: Jarkko Nikula @ 2009-07-31 17:26 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap@vger.kernel.org, Ujfalusi Peter (Nokia-D/Tampere),
alsa-devel@vger.kernel.org, Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1, 3, 4, 5
2009-07-30 18:57 ` [PATCH 09/20] OMAP3: McBSP: Lower the maximum buffersize for McBSP1,3,4,5 Jarkko Nikula
2009-07-31 7:58 ` Eduardo Valentin
@ 2009-07-31 7:58 ` Eduardo Valentin
1 sibling, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-31 7:58 UTC (permalink / raw)
To: alsa-devel
Cc: Ujfalusi Peter (Nokia-D/Tampere), linux-omap@vger.kernel.org,
Valentin Eduardo (Nokia-D/Helsinki), alsa-devel@vger.kernel.org,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply [flat|nested] 115+ messages in thread
* [PATCH 08/20] OMAP: McBSP: Create and export max_(r|t)x_thres property
2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 08/20] OMAP: McBSP: Create and export max_(r|t)x_thres property Eduardo Valentin
@ 2009-07-30 12:49 ` Eduardo Valentin
2009-08-06 12:10 ` [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler Tony Lindgren
2009-08-06 12:10 ` Tony Lindgren
3 siblings, 0 replies; 115+ messages in thread
From: Eduardo Valentin @ 2009-07-30 12:49 UTC (permalink / raw)
To: alsa-devel
Cc: Eduardo Valentin, Peter Ujfalusi,
Nurkkala Eero.An (EXT-Offcode/Oulu)
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
^ permalink raw reply related [flat|nested] 115+ messages in thread* Re: [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler
2009-07-30 12:49 ` Eduardo Valentin
2009-07-30 12:49 ` [PATCH 08/20] OMAP: McBSP: Create and export max_(r|t)x_thres property Eduardo Valentin
2009-07-30 12:49 ` [PATCH 08/20] OMAP: McBSP: Create and export max_(r|t)x_thres property Eduardo Valentin
@ 2009-08-06 12:10 ` Tony Lindgren
2009-08-06 12:20 ` ext-Eero.Nurkkala
2009-08-06 12:20 ` ext-Eero.Nurkkala
2009-08-06 12:10 ` Tony Lindgren
3 siblings, 2 replies; 115+ messages in thread
From: Tony Lindgren @ 2009-08-06 12:10 UTC (permalink / raw)
To: Eduardo Valentin
Cc: linux-omap, alsa-devel, Jarkko Nikula,
Nurkkala Eero.An (EXT-Offcode/Oulu), Peter Ujfalusi
* 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
^ permalink raw reply [flat|nested] 115+ messages in thread
* RE: [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler
2009-08-06 12:10 ` [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler Tony Lindgren
@ 2009-08-06 12:20 ` ext-Eero.Nurkkala
2009-08-06 12:24 ` Tony Lindgren
2009-08-06 12:24 ` Tony Lindgren
2009-08-06 12:20 ` ext-Eero.Nurkkala
1 sibling, 2 replies; 115+ messages in thread
From: ext-Eero.Nurkkala @ 2009-08-06 12:20 UTC (permalink / raw)
To: tony, eduardo.valentin; +Cc: linux-omap, alsa-devel, jhnikula, peter.ujfalusi
>>
>> +/********************** 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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler
2009-08-06 12:20 ` ext-Eero.Nurkkala
@ 2009-08-06 12:24 ` Tony Lindgren
2009-08-06 12:24 ` Tony Lindgren
1 sibling, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2009-08-06 12:24 UTC (permalink / raw)
To: alsa-devel; +Cc: linux-omap, eduardo.valentin, alsa-devel, peter.ujfalusi
* 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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler
2009-08-06 12:20 ` ext-Eero.Nurkkala
2009-08-06 12:24 ` Tony Lindgren
@ 2009-08-06 12:24 ` Tony Lindgren
1 sibling, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2009-08-06 12:24 UTC (permalink / raw)
To: ext-Eero.Nurkkala
Cc: eduardo.valentin, linux-omap, alsa-devel, jhnikula,
peter.ujfalusi
* 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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler
2009-08-06 12:10 ` [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler Tony Lindgren
2009-08-06 12:20 ` ext-Eero.Nurkkala
@ 2009-08-06 12:20 ` ext-Eero.Nurkkala
1 sibling, 0 replies; 115+ messages in thread
From: ext-Eero.Nurkkala @ 2009-08-06 12:20 UTC (permalink / raw)
To: alsa-devel; +Cc: linux-omap, peter.ujfalusi, alsa-devel
>>
>> +/********************** 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
^ permalink raw reply [flat|nested] 115+ messages in thread
* Re: [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler
2009-07-30 12:49 ` Eduardo Valentin
` (2 preceding siblings ...)
2009-08-06 12:10 ` [PATCH 07/20] OMAP: McBSP: Add transmit/receive threshold handler Tony Lindgren
@ 2009-08-06 12:10 ` Tony Lindgren
3 siblings, 0 replies; 115+ messages in thread
From: Tony Lindgren @ 2009-08-06 12:10 UTC (permalink / raw)
To: alsa-devel
Cc: linux-omap, Peter Ujfalusi, alsa-devel,
Nurkkala Eero.An (EXT-Offcode/Oulu)
* 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
^ permalink raw reply [flat|nested] 115+ messages in thread