All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robin Gong <yibin.gong@nxp.com>
To: "m.olbrich@pengutronix.de" <m.olbrich@pengutronix.de>,
	"thesven73@gmail.com" <thesven73@gmail.com>
Cc: dl-linux-imx <linux-imx@nxp.com>,
	"festevam@gmail.com" <festevam@gmail.com>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>
Subject: Re: [PATCH v1] dmaengine: imx-sdma: remove BD_INTR for channel0
Date: Mon, 17 Jun 2019 02:14:34 +0000	[thread overview]
Message-ID: <1560766686.30149.36.camel@nxp.com> (raw)
In-Reply-To: <20190614180913.d66bbjrnw3gxt663@pengutronix.de>

On 2019-06-14 at 18:09 +0000, Michael Olbrich wrote:
> On Fri, Jun 14, 2019 at 09:25:51AM -0400, Sven Van Asbroeck wrote:
> > 
> > On Fri, Jun 14, 2019 at 6:49 AM Fabio Estevam <festevam@gmail.com>
> > 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.
> > 
> > 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")
> I think this is correct. Starting with this commit, the interrupt
> status fr
> channel 0 is no longer cleared in sdma_run_channel0() and
> sdma_int_handler() is always called for channel 0.
> During firmware loading the interrupts are enabled again just before
> the
> clocks are disabled. The interrupt is pending at this moment so on a
> single
> core system I think this will always work as expected. If the
> firmware
> loading and the interrupt handler run on different cores then this is
> racy.
> Maybe something else changed to make this more likely?
> 
> With this new change sdma_int_handler() is no longer called for
> channel 0
> right, so you should also remove the special handling there.
What's 'special handling' should be removed here? Do you mean put below
pieces of your patch back?
 static int sdma_load_script(struct sdma_engine *sdma, void *buf, int
size,
@@ -727,9 +720,9 @@ static irqreturn_t sdma_int_handler(int irq, void
*dev_id)
        unsigned long stat;
 
        stat = readl_relaxed(sdma->regs + SDMA_H_INTR);
-       /* not interested in channel 0 interrupts */
-       stat &= ~1;
        writel_relaxed(stat, sdma->regs + SDMA_H_INTR);
+       /* channel 0 is special and not handled here, see
run_channel0() */
+       stat &= ~1;

> 
> Michael
> 

WARNING: multiple messages have this Message-ID (diff)
From: Robin Gong <yibin.gong@nxp.com>
To: "m.olbrich@pengutronix.de" <m.olbrich@pengutronix.de>,
	"thesven73@gmail.com" <thesven73@gmail.com>
Cc: "festevam@gmail.com" <festevam@gmail.com>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	dl-linux-imx <linux-imx@nxp.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v1] dmaengine: imx-sdma: remove BD_INTR for channel0
Date: Mon, 17 Jun 2019 02:14:34 +0000	[thread overview]
Message-ID: <1560766686.30149.36.camel@nxp.com> (raw)
In-Reply-To: <20190614180913.d66bbjrnw3gxt663@pengutronix.de>

On 2019-06-14 at 18:09 +0000, Michael Olbrich wrote:
> On Fri, Jun 14, 2019 at 09:25:51AM -0400, Sven Van Asbroeck wrote:
> > 
> > On Fri, Jun 14, 2019 at 6:49 AM Fabio Estevam <festevam@gmail.com>
> > 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.
> > 
> > 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")
> I think this is correct. Starting with this commit, the interrupt
> status fr
> channel 0 is no longer cleared in sdma_run_channel0() and
> sdma_int_handler() is always called for channel 0.
> During firmware loading the interrupts are enabled again just before
> the
> clocks are disabled. The interrupt is pending at this moment so on a
> single
> core system I think this will always work as expected. If the
> firmware
> loading and the interrupt handler run on different cores then this is
> racy.
> Maybe something else changed to make this more likely?
> 
> With this new change sdma_int_handler() is no longer called for
> channel 0
> right, so you should also remove the special handling there.
What's 'special handling' should be removed here? Do you mean put below
pieces of your patch back?
 static int sdma_load_script(struct sdma_engine *sdma, void *buf, int
size,
@@ -727,9 +720,9 @@ static irqreturn_t sdma_int_handler(int irq, void
*dev_id)
        unsigned long stat;
 
        stat = readl_relaxed(sdma->regs + SDMA_H_INTR);
-       /* not interested in channel 0 interrupts */
-       stat &= ~1;
        writel_relaxed(stat, sdma->regs + SDMA_H_INTR);
+       /* channel 0 is special and not handled here, see
run_channel0() */
+       stat &= ~1;

> 
> Michael
> 
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-06-17  2:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-14  8:39 [PATCH v1] dmaengine: imx-sdma: remove BD_INTR for channel0 yibin.gong
2019-06-14  8:39 ` yibin.gong
2019-06-14 10:49 ` Fabio Estevam
2019-06-14 10:49   ` Fabio Estevam
2019-06-14 13:25   ` Sven Van Asbroeck
2019-06-14 13:25     ` Sven Van Asbroeck
2019-06-14 18:09     ` Michael Olbrich
2019-06-14 18:09       ` Michael Olbrich
2019-06-17  2:14       ` Robin Gong [this message]
2019-06-17  2:14         ` Robin Gong
2019-06-17 10:15         ` m.olbrich
2019-06-17 10:15           ` m.olbrich
2019-06-18  6:08           ` Robin Gong
2019-06-18  6:08             ` Robin Gong
2019-06-18  6:19             ` m.olbrich
2019-06-17  2:02     ` Robin Gong
2019-06-17  2:02       ` Robin Gong
2019-06-17 13:27       ` Sven Van Asbroeck
2019-06-17 13:27         ` Sven Van Asbroeck
2019-06-18  5:50         ` Robin Gong
2019-06-18  5:50           ` Robin Gong
2019-06-14 13:35 ` Sven Van Asbroeck
2019-06-14 13:35   ` Sven Van Asbroeck
2019-06-17  1:42   ` Robin Gong
2019-06-17  1:42     ` Robin Gong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1560766686.30149.36.camel@nxp.com \
    --to=yibin.gong@nxp.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=m.olbrich@pengutronix.de \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    --cc=thesven73@gmail.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.