On Fri, Aug 21, 2020 at 09:52:00AM +, Robin Gong wrote:
> On 2020/08/20 14:52 Sascha Hauer wrote:
> > On Wed, Aug 19, 2020 at 01:08:29PM +0200, Lars-Peter Clausen wrote:
> > > > For the first option, which is potentially more performant, we have
> > > > to leave the atomic PCM context and we
On Fri, Aug 21, 2020 at 09:21:37AM +, Robin Gong wrote:
> On 2020/08/21 12:34 Richard Leitner wrote:
> > On Thu, Aug 20, 2020 at 03:01:44PM +, Robin Gong wrote:
> > > On 2020/08/19 22:26 Benjamin Bara - SKIDATA
> > wrote:
> > > >
> > > > @Robin:
> > > > Is it possible to tag the commits
On 2020/08/20 14:52 Sascha Hauer wrote:
> On Wed, Aug 19, 2020 at 01:08:29PM +0200, Lars-Peter Clausen wrote:
> > > For the first option, which is potentially more performant, we have
> > > to leave the atomic PCM context and we are not sure if we are allowed to.
> > > For the second option, we
On 2020/08/21 12:34 Richard Leitner wrote:
> On Thu, Aug 20, 2020 at 03:01:44PM +, Robin Gong wrote:
> > On 2020/08/19 22:26 Benjamin Bara - SKIDATA
> wrote:
> > >
> > > @Robin:
> > > Is it possible to tag the commits for the stable-tree
> > > Cc: sta...@vger.kernel.org?
> > Could my patch
On Thu, Aug 20, 2020 at 03:01:44PM +, Robin Gong wrote:
> On 2020/08/19 22:26 Benjamin Bara - SKIDATA
> wrote:
> >
> > @Robin:
> > Is it possible to tag the commits for the stable-tree
> > Cc: sta...@vger.kernel.org?
> Could my patch work in your side? If yes, I will add
> Cc:
On 2020/08/19 22:26 Benjamin Bara - SKIDATA wrote:
> > -Original Message-
> > From: Lars-Peter Clausen
> > Sent: Mittwoch, 19. August 2020 13:08
> > I think this might be an sdma specific problem after all.
> > dmaengine_terminate_async() will issue a request to stop the DMA. But
> > it
On Wed, Aug 19, 2020 at 01:08:29PM +0200, Lars-Peter Clausen wrote:
> > For the first option, which is potentially more performant, we have to
> > leave the atomic PCM context
> > and we are not sure if we are allowed to.
> > For the second option, we would have to divide the dma_device
> -Original Message-
> From: Lars-Peter Clausen
> Sent: Mittwoch, 19. August 2020 13:08
> I think this might be an sdma specific problem after all.
> dmaengine_terminate_async() will issue a request to stop the DMA. But it
> is still safe to issue the next transfer, even without calling
>
On 8/19/20 1:08 PM, Lars-Peter Clausen wrote:
On 8/17/20 9:28 AM, Benjamin Bara - SKIDATA wrote:
We think this is not an i.MX6-specific problem, but a problem of the
DMAengine usage from the PCM.
In case of a XRUN, the DMA channel is never closed but first a
SNDRV_PCM_TRIGGER_STOP next a
On 8/17/20 9:28 AM, Benjamin Bara - SKIDATA wrote:
We think this is not an i.MX6-specific problem, but a problem of the DMAengine
usage from the PCM.
In case of a XRUN, the DMA channel is never closed but first a
SNDRV_PCM_TRIGGER_STOP next a
SNDRV_PCM_TRIGGER_START is triggered.
The
On 2020/08/17 19:38 Benjamin Bara - SKIDATA wrote:
> > -Original Message-
> > From: Robin Gong
> > Sent: Montag, 17. August 2020 11:23
> > busy_wait is not good I think, would you please have a try with the
> > attached patch which is based on
> >
> -Original Message-
> From: Robin Gong
> Sent: Montag, 17. August 2020 11:23
> busy_wait is not good I think, would you please have a try with the attached
> patch
> which is based on https://lkml.org/lkml/2020/8/11/111? The basic idea is
> to keep the freed descriptor into another list
On 2020/08/17 15:29 Benjamin Bara - SKIDATA wrote:
> We think this is not an i.MX6-specific problem, but a problem of the
> DMAengine usage from the PCM.
> In case of a XRUN, the DMA channel is never closed but first a
> SNDRV_PCM_TRIGGER_STOP next a SNDRV_PCM_TRIGGER_START is triggered.
> The
We think this is not an i.MX6-specific problem, but a problem of the DMAengine
usage from the PCM.
In case of a XRUN, the DMA channel is never closed but first a
SNDRV_PCM_TRIGGER_STOP next a
SNDRV_PCM_TRIGGER_START is triggered.
The SNDRV_PCM_TRIGGER_STOP simply executes a
On Fri, Aug 14, 2020 at 11:18:10AM +0200, Robin Gong wrote:
>
> On 2020/08/13 19:23: Richard Leitner wrote:
> > Hi,
> > we've found a race condition with the PCM on the i.MX6 which results
> > in an -EIO for the SNDRV_PCM_IOCTL_READI_FRAMES ioctl after an -EPIPE
> > (XRUN).
> >
> > A possible
On 2020/08/13 19:23: Richard Leitner wrote:
> Hi,
> we've found a race condition with the PCM on the i.MX6 which results in an
> -EIO for the SNDRV_PCM_IOCTL_READI_FRAMES ioctl after an -EPIPE (XRUN).
>
> A possible reproduction may look like the following reduced call graph during
> a
> PCM
Hi,
we've found a race condition with the PCM on the i.MX6 which results in
an -EIO for the SNDRV_PCM_IOCTL_READI_FRAMES ioctl after an -EPIPE (XRUN).
A possible reproduction may look like the following reduced call graph
during a PCM capture:
us -> ioctl(SNDRV_PCM_IOCTL_READI_FRAMES)
-
17 matches
Mail list logo
