From: Robin Gong <yibin.gong@nxp.com>
To: "m.olbrich@pengutronix.de" <m.olbrich@pengutronix.de>
Cc: dl-linux-imx <linux-imx@nxp.com>,
"thesven73@gmail.com" <thesven73@gmail.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: Tue, 18 Jun 2019 06:08:50 +0000 [thread overview]
Message-ID: <1560867140.26847.12.camel@nxp.com> (raw)
In-Reply-To: <20190617101508.47jk72yrtplxpgzs@pengutronix.de>
On 2019-06-17 at 12:15 +0200, m.olbrich@pengutronix.de wrote:
> On Mon, Jun 17, 2019 at 02:14:34AM +0000, Robin Gong wrote:
> >
> > 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.c
> > > > om>
> > > > 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;
> I think the "stat &= ~1;" can be removed completely. This bit should
> never
> be set, now that the interrupt for channel 0 is disabled.
Okay, but that's harmless, moreover, I like your comment '/* channel 0
is special and not handled here, see run_channel0() */' which said
clearly channel0 interrupt is a special one and NOT handled in
sdma_int_handler. So I'd like to keep it...
>
> 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>
Cc: "thesven73@gmail.com" <thesven73@gmail.com>,
"shawnguo@kernel.org" <shawnguo@kernel.org>,
"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>,
"festevam@gmail.com" <festevam@gmail.com>,
"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: Tue, 18 Jun 2019 06:08:50 +0000 [thread overview]
Message-ID: <1560867140.26847.12.camel@nxp.com> (raw)
In-Reply-To: <20190617101508.47jk72yrtplxpgzs@pengutronix.de>
On 2019-06-17 at 12:15 +0200, m.olbrich@pengutronix.de wrote:
> On Mon, Jun 17, 2019 at 02:14:34AM +0000, Robin Gong wrote:
> >
> > 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.c
> > > > om>
> > > > 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;
> I think the "stat &= ~1;" can be removed completely. This bit should
> never
> be set, now that the interrupt for channel 0 is disabled.
Okay, but that's harmless, moreover, I like your comment '/* channel 0
is special and not handled here, see run_channel0() */' which said
clearly channel0 interrupt is a special one and NOT handled in
sdma_int_handler. So I'd like to keep it...
>
> Michael
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-18 6:43 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
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 [this message]
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=1560867140.26847.12.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.