Hi everyone,
Jon, as we talked about earlier today, I've spent some time working
on the MPC5200 AC97 driver to try and get rid of some of the nagging
bugs. The two big changes that I ended up making were to remove the
tracking of appl_ptr (and all the race conditions that went with it),
and to fi
All DMA blocks are lined up to period boundaries, but the DMA
handling code tracks bytes instead. This patch reworks the code
to track the period index into the DMA buffer instead of the
physical address pointer. Doing so makes the code simpler and
easier to understand.
Signed-off-by: Grant Like
Sound drivers PCM DMA is supposed to free-run until told to stop
by the trigger callback. The current code tries to track appl_ptr,
to avoid stale buffer data getting played out at the end of the
data stream. Unfortunately it also results in race conditions
which can cause the audio to stall.
Si
Signed-off-by: Grant Likely
---
sound/soc/fsl/mpc5200_dma.c | 15 ++-
sound/soc/fsl/mpc5200_dma.h |1 +
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
index 4e47586..658e3fa 100644
--- a/sound/soc/fsl/mp
Move the resolving of the psc_dma_stream pointer to a helper function
to reduce duplicate code
Signed-off-by: Grant Likely
---
sound/soc/fsl/mpc5200_dma.c |7 +--
sound/soc/fsl/mpc5200_dma.h |9 +
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/sound/soc/fsl/
The MPC5200 AC97 driver is disabling the slots when a stop
trigger is received, but not reenabling them if the stream
is started again without processing the hw_params again.
This patch fixes the problem by caching the slot enable bit
settings calculated at hw_params time so that they can be
reapp
ALSA playback seems to be more reliable if the .pointer() hook reports
a value slightly into the period, rather than right on the period
boundary. This patch adds a fudge factor of 1/4 the period size
to better estimate the actual position of the DMA engine in the
audio buffer.
Signed-off-by: Gra
On Sat, 2009-11-07 at 01:33 -0700, Grant Likely wrote:
> All DMA blocks are lined up to period boundaries, but the DMA
> handling code tracks bytes instead. This patch reworks the code
> to track the period index into the DMA buffer instead of the
> physical address pointer. Doing so makes the co
On Sat, Nov 7, 2009 at 3:34 AM, Grant Likely wrote:
> Sound drivers PCM DMA is supposed to free-run until told to stop
> by the trigger callback. The current code tries to track appl_ptr,
> to avoid stale buffer data getting played out at the end of the
> data stream. Unfortunately it also resul
On Sat, Nov 07, 2009 at 01:34:31AM -0700, Grant Likely wrote:
> +/* Utility for retrieving psc_dma_stream structure from a substream */
> +inline struct psc_dma_stream *
> +to_psc_dma_stream(struct snd_pcm_substream *substream, struct psc_dma
> *psc_dma)
> +{
> + if (substream->pstr->stream =
On Sat, Nov 07, 2009 at 01:33:40AM -0700, Grant Likely wrote:
> However, I was able to reproduce the noise problem when using aplay
> if I have DEBUG #defined at the top of the mpc5200_dma.c file with
> debug console logs being spit out the serial port. In that situation,
> the STOP trigger calls
On Sat, Nov 7, 2009 at 7:51 AM, Jon Smirl wrote:
> On Sat, Nov 7, 2009 at 3:34 AM, Grant Likely
> wrote:
>> Sound drivers PCM DMA is supposed to free-run until told to stop
>> by the trigger callback. The current code tries to track appl_ptr,
>> to avoid stale buffer data getting played out at
On Sat, Nov 7, 2009 at 3:35 AM, Liam Girdwood wrote:
> On Sat, 2009-11-07 at 01:33 -0700, Grant Likely wrote:
>> All DMA blocks are lined up to period boundaries, but the DMA
>> handling code tracks bytes instead. This patch reworks the code
>> to track the period index into the DMA buffer instea
On Sat, Nov 7, 2009 at 5:57 AM, Mark Brown
wrote:
> On Sat, Nov 07, 2009 at 01:33:40AM -0700, Grant Likely wrote:
>> So, please test. Let me know if these work or not. I've don't know
>> if the last patch (Add fudge factor...) is needed or not.
>
> I've applied patches 1-5 since they seem fairly
On Sat, Nov 07, 2009 at 01:34:55AM -0700, Grant Likely wrote:
> ALSA playback seems to be more reliable if the .pointer() hook reports
> a value slightly into the period, rather than right on the period
> boundary. This patch adds a fudge factor of 1/4 the period size
> to better estimate the actu
On Sat, Nov 7, 2009 at 11:11 AM, Mark Brown
wrote:
> On Sat, Nov 07, 2009 at 01:34:55AM -0700, Grant Likely wrote:
>> ALSA playback seems to be more reliable if the .pointer() hook reports
>> a value slightly into the period, rather than right on the period
>> boundary. This patch adds a fudge fa
On Sat, Nov 7, 2009 at 5:51 AM, Jon Smirl wrote:
> On Sat, Nov 7, 2009 at 3:34 AM, Grant Likely
> wrote:
>> Sound drivers PCM DMA is supposed to free-run until told to stop
>> by the trigger callback. The current code tries to track appl_ptr,
>> to avoid stale buffer data getting played out at
On Sat, Nov 7, 2009 at 6:04 AM, Jon Smirl wrote:
> On Sat, Nov 7, 2009 at 7:51 AM, Jon Smirl wrote:
>> On Sat, Nov 7, 2009 at 3:34 AM, Grant Likely
>> wrote:
>>> Sound drivers PCM DMA is supposed to free-run until told to stop
>>> by the trigger callback. The current code tries to track appl_p
On Sat, Nov 07, 2009 at 11:19:54AM -0700, Grant Likely wrote:
> On Sat, Nov 7, 2009 at 11:11 AM, Mark Brown
> > It occurs to me that in terms of dealing with what's going on here this
> > probably is achieving exactly the same effect as Jon's code in that it
> > tells ALSA that things are a bit ah
On Sat, Nov 7, 2009 at 12:33 PM, Mark Brown
wrote:
> On Sat, Nov 07, 2009 at 11:19:54AM -0700, Grant Likely wrote:
>> On Sat, Nov 7, 2009 at 11:11 AM, Mark Brown
>
>> > It occurs to me that in terms of dealing with what's going on here this
>> > probably is achieving exactly the same effect as Jon
On Sat, Nov 07, 2009 at 11:51:16AM -0700, Grant Likely wrote:
> On Sat, Nov 7, 2009 at 5:51 AM, Jon Smirl wrote:
> current period. My understanding of ALSA is that the application is
> supposed to make sure there is enough silence in the buffer to handle
> the lag between notification that the l
Hi Ben,
On Sat, 07 Nov 2009 09:55:44 +1100 Benjamin Herrenschmidt
wrote:
>
> Looks reasonable. But iseries can be a bitch, so we do need to test it
> on monday.
It should be safe as the spinlocks cannot be access until after the
following ppc_md pointer initialisations are done (and all this ha
22 matches
Mail list logo
