On 2019-06-14 at 13:25 +0000, Sven Van Asbroeck wrote:
> On Fri, Jun 14, 2019 at 6:49 AM Fabio Estevam <festevam@xxxxxxxxx>
> wrote:
> >
> >
> > According to the original report from Sven the issue started to
> > happen
> > on 5.0, so it would be good to add a Fixes tag and Cc stable so
> > that
> > this fix could be backported to 5.0/5.1 stable trees.
> Good catch !
>
> However, the issue is highly timing-dependent. It will come and go
> depending
> on the kernel version, devicetree and defconfig. If it works for me
> on
> 4.19, that
> doesn't mean the bug is gone on 4.19.
The default imx defconfig and dts should be ok, because firmware load
is delayed after rootfs mounted where firmware located in and before
that, some driver which use sdma such as spi/uart/audio may have
already enable sdma clock which means channel0 interrupt could be
cleared immediately without interrupt storm. That's why I can't
reproduce your issue at first, but catch it once I sync with your
directly firmware load defconfig. So seems not very must to CC stable
tree?
>
> Looking at the commit history, I think the commit below possibly
> introduced the
> issue. Until this commit, sdma_run_channel() would wait on the
> interrupt
> before proceeding. It has been there since 4.8:
>
> Fixes: 1d069bfa3c78 ("dmaengine: imx-sdma: ack channel 0 IRQ in the
> interrupt handler")
Yes, but Michael's patch is the right direction, at least it fix RT
case and meaningless channel0 interrupt storm coming before clearing
channel0 interrupt status in sdma_run_channel0(). Now, this patch could
fix its minor side-effect.
>
> But my knowledge of imx-sdma is non-existent, so I invite the more
> knowledgeable
> people in this thread to take a look at this commit.
>
> [Adding Michael Olbrich to the thread]
