[alsa-devel] [PATCH] ASoC: Add delay information for Samsung IISv2 DAIs
Report the current FIFO depth when delay is queried. The FIFO is only 16 frames deep so the latency will be at most a couple of miliseconds (and we tend to end up reporting zero most of the time) but it may help some applications.
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/s3c24xx/s3c-i2s-v2.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/sound/soc/s3c24xx/s3c-i2s-v2.c b/sound/soc/s3c24xx/s3c-i2s-v2.c index e994d83..04a00fa 100644 --- a/sound/soc/s3c24xx/s3c-i2s-v2.c +++ b/sound/soc/s3c24xx/s3c-i2s-v2.c @@ -550,6 +550,21 @@ static int s3c2412_i2s_set_clkdiv(struct snd_soc_dai *cpu_dai, return 0; }
+static long s3c2412_i2s_delay(struct snd_pcm_substream *substream, + struct snd_soc_dai *dai) +{ + struct s3c_i2sv2_info *i2s = to_info(dai); + u32 reg = readl(i2s->regs + S3C2412_IISFIC); + int delay; + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + delay = S3C2412_IISFIC_TXCOUNT(reg); + else + delay = S3C2412_IISFIC_RXCOUNT(reg); + + return delay; +} + /* default table of all avaialable root fs divisors */ static unsigned int iis_fs_tab[] = { 256, 512, 384, 768 };
@@ -736,6 +751,10 @@ int s3c_i2sv2_register_dai(struct snd_soc_dai *dai) ops->set_fmt = s3c2412_i2s_set_fmt; ops->set_clkdiv = s3c2412_i2s_set_clkdiv;
+ /* Allow overriding by (for example) IISv4 */ + if (!ops->delay) + ops->delay = s3c2412_i2s_delay, + dai->suspend = s3c2412_i2s_suspend; dai->resume = s3c2412_i2s_resume;
On Thu, Mar 4, 2010 at 9:05 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
@@ -550,6 +550,21 @@ static int s3c2412_i2s_set_clkdiv(struct snd_soc_dai *cpu_dai, return 0; }
+static long s3c2412_i2s_delay(struct snd_pcm_substream *substream,
- struct snd_soc_dai *dai)
return type snd_pcm_sframes_t ?
+{
- struct s3c_i2sv2_info *i2s = to_info(dai);
- u32 reg = readl(i2s->regs + S3C2412_IISFIC);
- int delay;
'delay' type snd_pcm_sframes_t ?
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
- delay = S3C2412_IISFIC_TXCOUNT(reg);
- else
- delay = S3C2412_IISFIC_RXCOUNT(reg);
- return delay;
+}
- /* Allow overriding by (for example) IISv4 */
- if (!ops->delay)
- ops->delay = s3c2412_i2s_delay,
Ok for now. I am trying to make functions in s3c-i2s-v2.c re-entrant as much as possible, 'delay' too seems to be a good candidate.
On Thu, Mar 04, 2010 at 10:18:59PM +0900, jassi brar wrote:
On Thu, Mar 4, 2010 at 9:05 PM, Mark Brown
+static long s3c2412_i2s_delay(struct snd_pcm_substream *substream,
- ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??struct snd_soc_dai *dai)
return type snd_pcm_sframes_t ?
Meh, yeah. It's actually the same type underneath.
I am trying to make functions in s3c-i2s-v2.c re-entrant as much as possible, 'delay' too seems to be a good candidate.
Could you expand on what you mean by this? All we're doing here is directly reporting a value read from a memory mapped register so there's nothing to be worried about from a locking point of view unless there were a multi-core system and the bus to the IP needed some locking, which is vanishingly unlikely to ever happen.
On Thu, Mar 4, 2010 at 10:24 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Mar 04, 2010 at 10:18:59PM +0900, jassi brar wrote:
On Thu, Mar 4, 2010 at 9:05 PM, Mark Brown
+static long s3c2412_i2s_delay(struct snd_pcm_substream *substream,
- ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??struct snd_soc_dai *dai)
return type snd_pcm_sframes_t ?
Meh, yeah. It's actually the same type underneath.
of course, but still...
I am trying to make functions in s3c-i2s-v2.c re-entrant as much as possible, 'delay' too seems to be a good candidate.
Could you expand on what you mean by this?
I mean, 'delay' is such a trival func that it can perhaps do controller specific stuff after checking some flag(new) in s3c_i2sv2_info.
All we're doing here is directly reporting a value read from a memory mapped register so there's nothing to be worried about from a locking point of view unless there were a multi-core system and the bus to the IP needed some locking, which is vanishingly unlikely to ever happen.
As I said, I am OK. I just see this func being modified soon to handle i2sv4 too.
On Thu, Mar 04, 2010 at 10:38:39PM +0900, jassi brar wrote:
On Thu, Mar 4, 2010 at 10:24 PM, Mark Brown
On Thu, Mar 04, 2010 at 10:18:59PM +0900, jassi brar wrote:
I am trying to make functions in s3c-i2s-v2.c re-entrant as much as possible, 'delay' too seems to be a good candidate.
Could you expand on what you mean by this?
I mean, 'delay' is such a trival func that it can perhaps do controller specific stuff after checking some flag(new) in s3c_i2sv2_info.
OK, that's nothing to do with the normal definition of "reentrant" - normally reentrancy means the ability to handle simultaneous calls from multiple threads of execution which is not at all relevant here since supporting more hardware is an orthogonal issue.
All we're doing here is directly reporting a value read from a memory mapped register so there's nothing to be worried about from a locking point of view unless there were a multi-core system and the bus to the IP needed some locking, which is vanishingly unlikely to ever happen.
As I said, I am OK. I just see this func being modified soon to handle i2sv4 too.
Looking at the hardware I suspect that all you'd be able to do would be try to take a guess as to which of the FIFOs you might want to report on or faff around averaging them but given that everything is clocked in lockstep I'm not sure it's worth bothering.
On Thu, Mar 4, 2010 at 11:01 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Mar 04, 2010 at 10:38:39PM +0900, jassi brar wrote:
On Thu, Mar 4, 2010 at 10:24 PM, Mark Brown
On Thu, Mar 04, 2010 at 10:18:59PM +0900, jassi brar wrote:
I am trying to make functions in s3c-i2s-v2.c re-entrant as much as possible, 'delay' too seems to be a good candidate.
Could you expand on what you mean by this?
I mean, 'delay' is such a trival func that it can perhaps do controller specific stuff after checking some flag(new) in s3c_i2sv2_info.
OK, that's nothing to do with the normal definition of "reentrant" - normally reentrancy means the ability to handle simultaneous calls from multiple threads of execution which is not at all relevant here since supporting more hardware is an orthogonal issue.
That is but one out of many criteria, another is that the func works only on the data provided to it by the caller.
All we're doing here is directly reporting a value read from a memory mapped register so there's nothing to be worried about from a locking point of view unless there were a multi-core system and the bus to the IP needed some locking, which is vanishingly unlikely to ever happen.
As I said, I am OK. I just see this func being modified soon to handle i2sv4 too.
Looking at the hardware I suspect that all you'd be able to do would be try to take a guess as to which of the FIFOs you might want to report on or faff around averaging them but given that everything is clocked in lockstep I'm not sure it's worth bothering.
I see.
On Thu, Mar 04, 2010 at 11:16:37PM +0900, jassi brar wrote:
On Thu, Mar 4, 2010 at 11:01 PM, Mark Brown
OK, that's nothing to do with the normal definition of "reentrant" - normally reentrancy means the ability to handle simultaneous calls from multiple threads of execution which is not at all relevant here since supporting more hardware is an orthogonal issue.
That is but one out of many criteria, another is that the func works only on the data provided to it by the caller.
Of course, but my point is that it's confusing to talk about additional hardware support as reentrancy.
participants (2)
-
jassi brar -
Mark Brown