* [PATCHv2 1/5] ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry
2010-03-03 13:08 [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Peter Ujfalusi
@ 2010-03-03 13:08 ` Peter Ujfalusi
2010-03-03 13:27 ` [alsa-devel] " Liam Girdwood
2010-03-03 13:08 ` [PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules Peter Ujfalusi
` (5 subsequent siblings)
6 siblings, 1 reply; 21+ messages in thread
From: Peter Ujfalusi @ 2010-03-03 13:08 UTC (permalink / raw)
To: broonie, tony; +Cc: alsa-devel, linux-omap, lrg, jhnikula, ext-eero.nurkkala
My editor removes the tailing spaces, which causes problems when
changing the soc-core.c
Removing the space.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
---
sound/soc/soc-core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index a03bac9..37c872e 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -315,7 +315,7 @@ static int soc_pcm_apply_symmetry(struct snd_pcm_substream *substream)
if (codec_dai->symmetric_rates || cpu_dai->symmetric_rates ||
machine->symmetric_rates) {
- dev_dbg(card->dev, "Symmetry forces %dHz rate\n",
+ dev_dbg(card->dev, "Symmetry forces %dHz rate\n",
machine->rate);
ret = snd_pcm_hw_constraint_minmax(substream->runtime,
--
1.7.0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules
2010-03-03 13:08 [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Peter Ujfalusi
2010-03-03 13:08 ` [PATCHv2 1/5] ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry Peter Ujfalusi
@ 2010-03-03 13:08 ` Peter Ujfalusi
2010-03-03 14:08 ` Peter Ujfalusi
2010-03-03 14:46 ` Jarkko Nikula
2010-03-03 13:08 ` [PATCHv2 2/5] ASoC: core: soc level wrapper for pcm_pointer callback Peter Ujfalusi
` (4 subsequent siblings)
6 siblings, 2 replies; 21+ messages in thread
From: Peter Ujfalusi @ 2010-03-03 13:08 UTC (permalink / raw)
To: broonie, tony; +Cc: alsa-devel, linux-omap, lrg, jhnikula, ext-eero.nurkkala
Wake-up from McBSP ports are needed, especially when the THRESHOLD
dma mode is in use for audio playback.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
---
arch/arm/mach-omap2/pm34xx.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 81ed252..6b17647 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -878,12 +878,16 @@ static void __init prcm_setup_regs(void)
/* Enable wakeups in PER */
prm_write_mod_reg(OMAP3430_EN_GPIO2 | OMAP3430_EN_GPIO3 |
OMAP3430_EN_GPIO4 | OMAP3430_EN_GPIO5 |
- OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3,
+ OMAP3430_EN_GPIO6 | OMAP3430_EN_UART3 |
+ OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 |
+ OMAP3430_EN_MCBSP4,
OMAP3430_PER_MOD, PM_WKEN);
/* and allow them to wake up MPU */
prm_write_mod_reg(OMAP3430_GRPSEL_GPIO2 | OMAP3430_EN_GPIO3 |
OMAP3430_GRPSEL_GPIO4 | OMAP3430_EN_GPIO5 |
- OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3,
+ OMAP3430_GRPSEL_GPIO6 | OMAP3430_EN_UART3 |
+ OMAP3430_EN_MCBSP2 | OMAP3430_EN_MCBSP3 |
+ OMAP3430_EN_MCBSP4,
OMAP3430_PER_MOD, OMAP3430_PM_MPUGRPSEL);
/* Don't attach IVA interrupts */
--
1.6.5.3
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules
2010-03-03 13:08 ` [PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules Peter Ujfalusi
@ 2010-03-03 14:08 ` Peter Ujfalusi
2010-03-03 14:46 ` Jarkko Nikula
1 sibling, 0 replies; 21+ messages in thread
From: Peter Ujfalusi @ 2010-03-03 14:08 UTC (permalink / raw)
To: broonie
Cc: alsa-devel, tony, Nurkkala Eero.An (EXT-Offcode/Oulu), linux-omap, lrg
On Wednesday 03 March 2010 15:08:05 Ujfalusi Peter (Nokia-D/Tampere) wrote:
> Wake-up from McBSP ports are needed, especially when the THRESHOLD
> dma mode is in use for audio playback.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Hmmm, please disregard this patch, I have forgot to clean up the directory.
This has been already taken for 2.6.33 kernel.
Only the [PATCHv2] prefix is valid for this series.
Sorry for the noise.
--
Péter
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules
2010-03-03 13:08 ` [PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules Peter Ujfalusi
2010-03-03 14:08 ` Peter Ujfalusi
@ 2010-03-03 14:46 ` Jarkko Nikula
1 sibling, 0 replies; 21+ messages in thread
From: Jarkko Nikula @ 2010-03-03 14:46 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: alsa-devel, tony, broonie, ext-eero.nurkkala, linux-omap, lrg
On Wed, 3 Mar 2010 15:08:05 +0200
Peter Ujfalusi <peter.ujfalusi@nokia.com> wrote:
> Wake-up from McBSP ports are needed, especially when the THRESHOLD
> dma mode is in use for audio playback.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
> ---
> arch/arm/mach-omap2/pm34xx.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
How about the commit e3d9329640e4b291cdd2c6d178774c28bba47d59 in
mainline?
--
Jarkko
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCHv2 2/5] ASoC: core: soc level wrapper for pcm_pointer callback
2010-03-03 13:08 [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Peter Ujfalusi
2010-03-03 13:08 ` [PATCHv2 1/5] ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry Peter Ujfalusi
2010-03-03 13:08 ` [PATCH] OMAP3: PM: Enable wake-up from McBSP2, 3 and 4 modules Peter Ujfalusi
@ 2010-03-03 13:08 ` Peter Ujfalusi
2010-03-03 13:27 ` [alsa-devel] " Liam Girdwood
2010-03-03 13:08 ` [PATCHv2 3/5] ASoC: core: Add delay operation to snd_soc_dai_ops Peter Ujfalusi
` (3 subsequent siblings)
6 siblings, 1 reply; 21+ messages in thread
From: Peter Ujfalusi @ 2010-03-03 13:08 UTC (permalink / raw)
To: broonie, tony; +Cc: alsa-devel, linux-omap, ext-eero.nurkkala, lrg
Create a soc level wrapper for pcm_pointer callback.
This will facilitate the soc level handling of different
HW buffers in the audio path.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
---
sound/soc/soc-core.c | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 37c872e..de5223d 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -797,6 +797,23 @@ static int soc_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
return 0;
}
+/*
+ * soc level wrapper for pointer callback
+ */
+static snd_pcm_uframes_t soc_pcm_pointer(struct snd_pcm_substream *substream)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_device *socdev = rtd->socdev;
+ struct snd_soc_card *card = socdev->card;
+ struct snd_soc_platform *platform = card->platform;
+ snd_pcm_uframes_t offset = 0;
+
+ if (platform->pcm_ops->pointer)
+ offset = platform->pcm_ops->pointer(substream);
+
+ return offset;
+}
+
/* ASoC PCM operations */
static struct snd_pcm_ops soc_pcm_ops = {
.open = soc_pcm_open,
@@ -805,6 +822,7 @@ static struct snd_pcm_ops soc_pcm_ops = {
.hw_free = soc_pcm_hw_free,
.prepare = soc_pcm_prepare,
.trigger = soc_pcm_trigger,
+ .pointer = soc_pcm_pointer,
};
#ifdef CONFIG_PM
@@ -1331,7 +1349,6 @@ static int soc_new_pcm(struct snd_soc_device *socdev,
dai_link->pcm = pcm;
pcm->private_data = rtd;
soc_pcm_ops.mmap = platform->pcm_ops->mmap;
- soc_pcm_ops.pointer = platform->pcm_ops->pointer;
soc_pcm_ops.ioctl = platform->pcm_ops->ioctl;
soc_pcm_ops.copy = platform->pcm_ops->copy;
soc_pcm_ops.silence = platform->pcm_ops->silence;
--
1.7.0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCHv2 3/5] ASoC: core: Add delay operation to snd_soc_dai_ops
2010-03-03 13:08 [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Peter Ujfalusi
` (2 preceding siblings ...)
2010-03-03 13:08 ` [PATCHv2 2/5] ASoC: core: soc level wrapper for pcm_pointer callback Peter Ujfalusi
@ 2010-03-03 13:08 ` Peter Ujfalusi
2010-03-03 13:28 ` Liam Girdwood
2010-03-03 13:08 ` [PATCHv2 4/5] OMAP3: McBSP: Add interface for FIFO caused delay query Peter Ujfalusi
` (2 subsequent siblings)
6 siblings, 1 reply; 21+ messages in thread
From: Peter Ujfalusi @ 2010-03-03 13:08 UTC (permalink / raw)
To: broonie, tony; +Cc: alsa-devel, linux-omap, lrg, jhnikula, ext-eero.nurkkala
The delay callback can be used by the core to query the delay
on the dai caused by FIFO or delay in the platform side.
In case if both CPU and CODEC dai has FIFO the delay reported
by each will be added to form the full delay on the chain.
If none of the dai has FIFO, than the delay will be kept as
zero.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
---
include/sound/soc-dai.h | 6 ++++++
include/sound/soc.h | 7 +++++++
sound/soc/soc-core.c | 18 ++++++++++++++++++
3 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/include/sound/soc-dai.h b/include/sound/soc-dai.h
index 061f16d..be9cd47 100644
--- a/include/sound/soc-dai.h
+++ b/include/sound/soc-dai.h
@@ -182,6 +182,12 @@ struct snd_soc_dai_ops {
struct snd_soc_dai *);
int (*trigger)(struct snd_pcm_substream *, int,
struct snd_soc_dai *);
+ /*
+ * For hardware based FIFO caused delay reporting.
+ * Optional.
+ */
+ snd_pcm_sframes_t (*delay)(struct snd_pcm_substream *,
+ struct snd_soc_dai *);
};
/*
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 5d234a8..c010824 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -469,6 +469,13 @@ struct snd_soc_platform {
struct snd_pcm *);
void (*pcm_free)(struct snd_pcm *);
+ /*
+ * For platform caused delay reporting.
+ * Optional.
+ */
+ snd_pcm_sframes_t (*delay)(struct snd_pcm_substream *,
+ struct snd_soc_dai *);
+
/* platform stream ops */
struct snd_pcm_ops *pcm_ops;
};
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index de5223d..e9c2dc1 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -799,6 +799,8 @@ static int soc_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
/*
* soc level wrapper for pointer callback
+ * If cpu_dai, codec_dai, platform driver has the delay callback, than
+ * the runtime->delay will be updated accordingly.
*/
static snd_pcm_uframes_t soc_pcm_pointer(struct snd_pcm_substream *substream)
{
@@ -806,11 +808,27 @@ static snd_pcm_uframes_t soc_pcm_pointer(struct snd_pcm_substream *substream)
struct snd_soc_device *socdev = rtd->socdev;
struct snd_soc_card *card = socdev->card;
struct snd_soc_platform *platform = card->platform;
+ struct snd_soc_dai_link *machine = rtd->dai;
+ struct snd_soc_dai *cpu_dai = machine->cpu_dai;
+ struct snd_soc_dai *codec_dai = machine->codec_dai;
+ struct snd_pcm_runtime *runtime = substream->runtime;
snd_pcm_uframes_t offset = 0;
+ snd_pcm_sframes_t delay = 0;
if (platform->pcm_ops->pointer)
offset = platform->pcm_ops->pointer(substream);
+ if (cpu_dai->ops->delay)
+ delay += cpu_dai->ops->delay(substream, cpu_dai);
+
+ if (codec_dai->ops->delay)
+ delay += codec_dai->ops->delay(substream, codec_dai);
+
+ if (platform->delay)
+ delay += platform->delay(substream, codec_dai);
+
+ runtime->delay = delay;
+
return offset;
}
--
1.7.0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCHv2 3/5] ASoC: core: Add delay operation to snd_soc_dai_ops
2010-03-03 13:08 ` [PATCHv2 3/5] ASoC: core: Add delay operation to snd_soc_dai_ops Peter Ujfalusi
@ 2010-03-03 13:28 ` Liam Girdwood
0 siblings, 0 replies; 21+ messages in thread
From: Liam Girdwood @ 2010-03-03 13:28 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, tony, broonie, ext-eero.nurkkala, linux-omap
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote:
> The delay callback can be used by the core to query the delay
> on the dai caused by FIFO or delay in the platform side.
> In case if both CPU and CODEC dai has FIFO the delay reported
> by each will be added to form the full delay on the chain.
> If none of the dai has FIFO, than the delay will be kept as
> zero.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCHv2 4/5] OMAP3: McBSP: Add interface for FIFO caused delay query
2010-03-03 13:08 [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Peter Ujfalusi
` (3 preceding siblings ...)
2010-03-03 13:08 ` [PATCHv2 3/5] ASoC: core: Add delay operation to snd_soc_dai_ops Peter Ujfalusi
@ 2010-03-03 13:08 ` Peter Ujfalusi
2010-03-03 14:38 ` Jarkko Nikula
2010-03-03 13:08 ` [PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO Peter Ujfalusi
2010-03-03 13:38 ` [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Mark Brown
6 siblings, 1 reply; 21+ messages in thread
From: Peter Ujfalusi @ 2010-03-03 13:08 UTC (permalink / raw)
To: broonie, tony; +Cc: alsa-devel, linux-omap, lrg, jhnikula, ext-eero.nurkkala
New functions for querying the FIFO caused delay on both
TX and RX path.
On TX path the return value shows the number of used
locations in the FIFO.
On RX papth it returns the number of locations to be filled
to reach the threshold value (DMA will be triggered to read
the data out from the FIFO).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
---
arch/arm/plat-omap/include/plat/mcbsp.h | 6 +++
arch/arm/plat-omap/mcbsp.c | 55 +++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/mcbsp.h b/arch/arm/plat-omap/include/plat/mcbsp.h
index 3974835..1bd7021 100644
--- a/arch/arm/plat-omap/include/plat/mcbsp.h
+++ b/arch/arm/plat-omap/include/plat/mcbsp.h
@@ -149,6 +149,8 @@
#define OMAP_MCBSP_REG_WAKEUPEN 0xA8
#define OMAP_MCBSP_REG_XCCR 0xAC
#define OMAP_MCBSP_REG_RCCR 0xB0
+#define OMAP_MCBSP_REG_XBUFFSTAT 0xB4
+#define OMAP_MCBSP_REG_RBUFFSTAT 0xB8
#define OMAP_MCBSP_REG_SSELCR 0xBC
#define OMAP_ST_REG_REV 0x00
@@ -471,6 +473,8 @@ 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);
+u16 omap_mcbsp_get_tx_delay(unsigned int id);
+u16 omap_mcbsp_get_rx_delay(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)
@@ -479,6 +483,8 @@ 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 u16 omap_mcbsp_get_tx_delay(unsigned int id) { return 0; }
+static inline u16 omap_mcbsp_get_rx_delay(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);
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index e47686e..5e6d309 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -561,6 +561,61 @@ u16 omap_mcbsp_get_max_rx_threshold(unsigned int id)
}
EXPORT_SYMBOL(omap_mcbsp_get_max_rx_threshold);
+#define MCBSP2_FIFO_SIZE 0x500 /* 1024 + 256 locations */
+#define MCBSP1345_FIFO_SIZE 0x80 /* 128 locations */
+/*
+ * omap_mcbsp_get_tx_delay returns the number of used slots in the McBSP FIFO
+ */
+u16 omap_mcbsp_get_tx_delay(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+ u16 buffstat;
+
+ 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);
+
+ /* Returns the number of free locations in the buffer */
+ buffstat = MCBSP_READ(mcbsp, XBUFFSTAT);
+
+ /* Number of slots are different in McBSP ports */
+ if (mcbsp->id == 2)
+ return MCBSP2_FIFO_SIZE - buffstat;
+ else
+ return MCBSP1345_FIFO_SIZE - buffstat;
+}
+EXPORT_SYMBOL(omap_mcbsp_get_tx_delay);
+
+/*
+ * omap_mcbsp_get_rx_delay returns the number of free slots in the McBSP FIFO
+ * to reach the threshold value (when the DMA will be triggered to read it)
+ */
+u16 omap_mcbsp_get_rx_delay(unsigned int id)
+{
+ struct omap_mcbsp *mcbsp;
+ u16 buffstat, threshold;
+
+ 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);
+
+ /* Returns the number of used locations in the buffer */
+ buffstat = MCBSP_READ(mcbsp, RBUFFSTAT);
+ /* RX threshold */
+ threshold = MCBSP_READ(mcbsp, THRSH1);
+
+ /* Return the number of location till we reach the threshold limit */
+ if (threshold <= buffstat)
+ return 0;
+ else
+ return threshold - buffstat;
+}
+EXPORT_SYMBOL(omap_mcbsp_get_rx_delay);
+
/*
* omap_mcbsp_get_dma_op_mode just return the current configured
* operating mode for the mcbsp channel
--
1.7.0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCHv2 4/5] OMAP3: McBSP: Add interface for FIFO caused delay query
2010-03-03 13:08 ` [PATCHv2 4/5] OMAP3: McBSP: Add interface for FIFO caused delay query Peter Ujfalusi
@ 2010-03-03 14:38 ` Jarkko Nikula
0 siblings, 0 replies; 21+ messages in thread
From: Jarkko Nikula @ 2010-03-03 14:38 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: broonie, tony, alsa-devel, linux-omap, lrg, ext-eero.nurkkala
On Wed, 3 Mar 2010 15:08:08 +0200
Peter Ujfalusi <peter.ujfalusi@nokia.com> wrote:
> New functions for querying the FIFO caused delay on both
> TX and RX path.
> On TX path the return value shows the number of used
> locations in the FIFO.
> On RX papth it returns the number of locations to be filled
> to reach the threshold value (DMA will be triggered to read
> the data out from the FIFO).
>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO
2010-03-03 13:08 [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Peter Ujfalusi
` (4 preceding siblings ...)
2010-03-03 13:08 ` [PATCHv2 4/5] OMAP3: McBSP: Add interface for FIFO caused delay query Peter Ujfalusi
@ 2010-03-03 13:08 ` Peter Ujfalusi
2010-03-03 13:28 ` Liam Girdwood
2010-03-03 13:38 ` [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Mark Brown
6 siblings, 1 reply; 21+ messages in thread
From: Peter Ujfalusi @ 2010-03-03 13:08 UTC (permalink / raw)
To: broonie, tony; +Cc: alsa-devel, linux-omap, ext-eero.nurkkala, lrg
Use the new delay calback function to report the delay through
ALSA for application caused by the internal FIFO.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
---
sound/soc/omap/omap-mcbsp.c | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
index e814a95..2952fb0 100644
--- a/sound/soc/omap/omap-mcbsp.c
+++ b/sound/soc/omap/omap-mcbsp.c
@@ -256,6 +256,31 @@ static int omap_mcbsp_dai_trigger(struct snd_pcm_substream *substream, int cmd,
return err;
}
+static snd_pcm_sframes_t omap_mcbsp_dai_delay(
+ struct snd_pcm_substream *substream,
+ struct snd_soc_dai *dai)
+{
+ struct snd_soc_pcm_runtime *rtd = substream->private_data;
+ struct snd_soc_dai *cpu_dai = rtd->dai->cpu_dai;
+ struct omap_mcbsp_data *mcbsp_data = to_mcbsp(cpu_dai->private_data);
+ u16 fifo_use;
+ snd_pcm_sframes_t delay;
+
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ fifo_use = omap_mcbsp_get_tx_delay(mcbsp_data->bus_id);
+ else
+ fifo_use = omap_mcbsp_get_rx_delay(mcbsp_data->bus_id);
+
+ /*
+ * Divide the used locations with the channel count to get the
+ * FIFO usage in samples (don't care about partial samples in the
+ * buffer).
+ */
+ delay = fifo_use / substream->runtime->channels;
+
+ return delay;
+}
+
static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
@@ -607,6 +632,7 @@ static struct snd_soc_dai_ops omap_mcbsp_dai_ops = {
.startup = omap_mcbsp_dai_startup,
.shutdown = omap_mcbsp_dai_shutdown,
.trigger = omap_mcbsp_dai_trigger,
+ .delay = omap_mcbsp_dai_delay,
.hw_params = omap_mcbsp_dai_hw_params,
.set_fmt = omap_mcbsp_dai_set_dai_fmt,
.set_clkdiv = omap_mcbsp_dai_set_clkdiv,
--
1.7.0
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO
2010-03-03 13:08 ` [PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO Peter Ujfalusi
@ 2010-03-03 13:28 ` Liam Girdwood
2010-03-03 14:30 ` Jarkko Nikula
0 siblings, 1 reply; 21+ messages in thread
From: Liam Girdwood @ 2010-03-03 13:28 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: tony, alsa-devel, broonie, ext-eero.nurkkala, linux-omap
On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote:
> Use the new delay calback function to report the delay through
> ALSA for application caused by the internal FIFO.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
> ---
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO
2010-03-03 13:28 ` Liam Girdwood
@ 2010-03-03 14:30 ` Jarkko Nikula
0 siblings, 0 replies; 21+ messages in thread
From: Jarkko Nikula @ 2010-03-03 14:30 UTC (permalink / raw)
To: Liam Girdwood
Cc: alsa-devel, tony, broonie, Peter Ujfalusi, ext-eero.nurkkala, linux-omap
On Wed, 03 Mar 2010 13:28:24 +0000
Liam Girdwood <lrg@slimlogic.co.uk> wrote:
> On Wed, 2010-03-03 at 15:08 +0200, Peter Ujfalusi wrote:
> > Use the new delay calback function to report the delay through
> > ALSA for application caused by the internal FIFO.
> >
> > Signed-off-by: Peter Ujfalusi <peter.ujfalusi@nokia.com>
> > ---
>
> Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Acked-by: Jarkko Nikula <jhnikula@gmail.com>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap
2010-03-03 13:08 [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Peter Ujfalusi
` (5 preceding siblings ...)
2010-03-03 13:08 ` [PATCHv2 5/5] ASoC: OMAP3: Report delay caused by the internal FIFO Peter Ujfalusi
@ 2010-03-03 13:38 ` Mark Brown
2010-03-11 22:26 ` Tony Lindgren
6 siblings, 1 reply; 21+ messages in thread
From: Mark Brown @ 2010-03-03 13:38 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, tony, ext-eero.nurkkala, linux-omap, lrg
On Wed, Mar 03, 2010 at 03:08:03PM +0200, Peter Ujfalusi wrote:
> Peter Ujfalusi (5):
> ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry
> ASoC: core: soc level wrapper for pcm_pointer callback
> ASoC: core: Add delay operation to snd_soc_dai_ops
I'll apply these just now, thanks!
> OMAP3: McBSP: Add interface for FIFO caused delay query
> ASoC: OMAP3: Report delay caused by the internal FIFO
These also look OK to me but there's the arch/arm dependency.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap
2010-03-03 13:38 ` [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap Mark Brown
@ 2010-03-11 22:26 ` Tony Lindgren
2010-03-11 22:43 ` Mark Brown
0 siblings, 1 reply; 21+ messages in thread
From: Tony Lindgren @ 2010-03-11 22:26 UTC (permalink / raw)
To: Mark Brown
Cc: Peter Ujfalusi, alsa-devel, linux-omap, lrg, jhnikula, ext-eero.nurkkala
* Mark Brown <broonie@opensource.wolfsonmicro.com> [100303 05:34]:
> On Wed, Mar 03, 2010 at 03:08:03PM +0200, Peter Ujfalusi wrote:
>
> > Peter Ujfalusi (5):
> > ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry
> > ASoC: core: soc level wrapper for pcm_pointer callback
> > ASoC: core: Add delay operation to snd_soc_dai_ops
>
> I'll apply these just now, thanks!
>
> > OMAP3: McBSP: Add interface for FIFO caused delay query
> > ASoC: OMAP3: Report delay caused by the internal FIFO
>
> These also look OK to me but there's the arch/arm dependency.
I think the only one is the McBSP patch above.
Care to take that too to keep things working?
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap
2010-03-11 22:26 ` Tony Lindgren
@ 2010-03-11 22:43 ` Mark Brown
2010-03-12 6:18 ` Peter Ujfalusi
0 siblings, 1 reply; 21+ messages in thread
From: Mark Brown @ 2010-03-11 22:43 UTC (permalink / raw)
To: Tony Lindgren
Cc: alsa-devel, Peter Ujfalusi, ext-eero.nurkkala, linux-omap, lrg
On 11 Mar 2010, at 22:26, Tony Lindgren <tony@atomide.com> wrote:
> * Mark Brown <broonie@opensource.wolfsonmicro.com> [100303 05:34]:
>> On Wed, Mar 03, 2010 at 03:08:03PM +0200, Peter Ujfalusi wrote:
>>
>>> Peter Ujfalusi (5):
>>> ASoC: core: fix tailing whitespace in soc_pcm_apply_symmetry
>>> ASoC: core: soc level wrapper for pcm_pointer callback
>>> ASoC: core: Add delay operation to snd_soc_dai_ops
>>
>> I'll apply these just now, thanks!
>>
>>> OMAP3: McBSP: Add interface for FIFO caused delay query
>>> ASoC: OMAP3: Report delay caused by the internal FIFO
>>
>> These also look OK to me but there's the arch/arm dependency.
>
> I think the only one is the McBSP patch above.
>
> Care to take that too to keep things working?
>
> Acked-by: Tony Lindgren <tony@atomide.com>
I can do, though there was some debate about how useful the
information the hardware returns actually is - could folks confirm
what the consensus there was, please?
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap
2010-03-11 22:43 ` Mark Brown
@ 2010-03-12 6:18 ` Peter Ujfalusi
2010-03-12 8:30 ` Jarkko Nikula
0 siblings, 1 reply; 21+ messages in thread
From: Peter Ujfalusi @ 2010-03-12 6:18 UTC (permalink / raw)
To: ext Mark Brown
Cc: alsa-devel, Tony Lindgren, Nurkkala Eero.An (EXT-Offcode/Oulu),
linux-omap, lrg
On Friday 12 March 2010 00:43:41 ext Mark Brown wrote:
> I can do, though there was some debate about how useful the
> information the hardware returns actually is - could folks confirm
> what the consensus there was, please?
Yeah, that thread went silent without final go or no go...
I do agree with Eero, that the BUFFSTAT register is not the most reliable source
of information, but I still believe that the way we are going to use it will
give pretty close to the reality estimation on the statuses.
Eero also mentioned timestamp based estimation, which I think can also be used
in this way:
In element mode, we just return the delay as the whole size of the buffer (which
is not accurate when we initially fill the buffer, and when we drain it at the
end, but it is not a real problem).
In threshold mode, than we can take timestamp at DMA completion interrupts, and
calculate the delay based on the FIFO size (FIFO size - samples played out since
the last timstamp). This can also give false numbers at the start of the
playback (for few periods, until the buffer utilization settles).
So the timestamp based solution looks good, but it is only usable when the codec
is running synchronously. It will definitely falls apart as soon as we use a
codec like tlv320dac33 in burst mode (FIFO on the codec as well).
We could have ~100 ms between DMA interrupts, so the countdown for McBSP FIFO
usage is already broken.
Furthermore since there is no way at the moment to actually synchronize the
omap-mcbsp, omap-pcm and tlv320dac33 (in DMA, McBSP threshold, McBSP mode and
DAC33 mode sense), there could be cases, that this big silence on the bus (when
DAC33 is playing from it's buffer) is not happening exactly after the DMA filled
up the McBSP FIFO, but a bit later (could be just one sample away from the next
McBSP threshold event), which means that the McBSP FIFO is nowhere near to be
full.
In this case the BUFFSTAT register would give good estimation, than any
timestamp based solution for McBSP FIFO.
All in all, I think the usage of the BUFFSTAT register is a good compromise for
all cases, and it is needed for the cases, where the codec also have buffer of
it's own.
Never the less, we can also add the timestamp based estimation later, but we
need to make sure, that those can be picked somehow for the given setup.
--
Péter
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap
2010-03-12 6:18 ` Peter Ujfalusi
@ 2010-03-12 8:30 ` Jarkko Nikula
2010-03-12 11:12 ` Mark Brown
0 siblings, 1 reply; 21+ messages in thread
From: Jarkko Nikula @ 2010-03-12 8:30 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: ext Mark Brown, Tony Lindgren, alsa-devel, linux-omap, lrg,
Nurkkala Eero.An (EXT-Offcode/Oulu)
On Fri, 12 Mar 2010 08:18:30 +0200
Peter Ujfalusi <peter.ujfalusi@nokia.com> wrote:
> On Friday 12 March 2010 00:43:41 ext Mark Brown wrote:
>
> > I can do, though there was some debate about how useful the
> > information the hardware returns actually is - could folks confirm
> > what the consensus there was, please?
>
> Yeah, that thread went silent without final go or no go...
>
...
> All in all, I think the usage of the BUFFSTAT register is a good compromise for
> all cases, and it is needed for the cases, where the codec also have buffer of
> it's own.
>
And one point is that the BUFFSTAT use doesn't make things worse than
currently. Now the application doesn't have any information about the
HW buffer caused audio latencies so reporting them makes the things
better than currently.
--
Jarkko
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCHv2 0/5] FIFO caused playback delay (latency) handling in soc/omap
2010-03-12 8:30 ` Jarkko Nikula
@ 2010-03-12 11:12 ` Mark Brown
0 siblings, 0 replies; 21+ messages in thread
From: Mark Brown @ 2010-03-12 11:12 UTC (permalink / raw)
To: Jarkko Nikula
Cc: alsa-devel, Tony Lindgren, Peter Ujfalusi,
Nurkkala Eero.An (EXT-Offcode/Oulu),
linux-omap, lrg
On Fri, Mar 12, 2010 at 10:30:50AM +0200, Jarkko Nikula wrote:
> Peter Ujfalusi <peter.ujfalusi@nokia.com> wrote:
> > All in all, I think the usage of the BUFFSTAT register is a good compromise for
> > all cases, and it is needed for the cases, where the codec also have buffer of
> > it's own.
> And one point is that the BUFFSTAT use doesn't make things worse than
> currently. Now the application doesn't have any information about the
> HW buffer caused audio latencies so reporting them makes the things
> better than currently.
OK, that's what I thought - just wanted to confirm. I've applied both
patches now.
^ permalink raw reply [flat|nested] 21+ messages in thread