From: Christian Eggers <ceggers@arri.de>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: "Stefan Riedmüller" <S.Riedmueller@phytec.de>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"han.xu@nxp.com" <han.xu@nxp.com>,
"michael@amarulasolutions.com" <michael@amarulasolutions.com>,
"Christian Hemp" <C.Hemp@phytec.de>,
"gerg@kernel.org" <gerg@kernel.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: GPMI iMX6ull timeout on DMA
Date: Sat, 9 Oct 2021 08:26:36 +0200 [thread overview]
Message-ID: <2811233.e9J7NaK4W3@n95hx1g2> (raw)
In-Reply-To: <20211008180752.09f33896@xps13>
On Friday, 8 October 2021, 18:07:52 CEST, Miquel Raynal wrote:
> Hi Christian,
>
> ceggers@arri.de wrote on Fri, 8 Oct 2021 15:49:21 +0200:
>
> > On Friday, 8 October 2021, 15:36:31 CEST, Miquel Raynal wrote:
> > >
> > > miquel.raynal@bootlin.com wrote on Fri, 8 Oct 2021 15:29:05 +0200:
> > >
> > > >
> > > > If this clock (as I understand) does not prevent us to access the
> > > > registers but only feeds the external NAND bus part, then there is no
> > > > need to enable it in the probe, just acquiring it will be enough.
> >
> > clocks[0] is "gpmi_io" which sounds more like i/o than registers. So lets
> > try to remove the initial call to clk_set_rate().
From the GPMI description (i.MX6 ULL):
> [GPMI] Registers are clocked on the HCLK domain. The I/O and pin timing are
> clocked on a dedicated GPMICLK domain. GPMICLK can be set to maximize I/O
> performance.
Additionally, figure 17-1 in IMX6ULLRM.pdf shows that both (BCH and GPMI)
registers are connected to APBH.
I checked this with the debugger: For accessing the BCH and GPMI
registers, only CCGR0::CG2 [APBHDMA_HCLK_ENABLE] is required. This bit is
enabled in mxs_dma_alloc_chan_resources():
-000|mxs_dma_alloc_chan_resources(chan = 0xC2090154)
-001|__refcount_inc_not_zero(inline)
-001|refcount_inc_not_zero(inline)
-001|kref_get_unless_zero(inline)
-001|dma_chan_get(:chan = 0xC2090154)
-002|find_candidate(device = 0xC2090050, :mask = 0xC209BD38, :fn = 0xC0254679, :fn_param = 0xC209BD3C)
-003|__dma_request_channel(:mask = 0xC209BD38, :fn = 0xC0254679, :fn_param = 0xC209BD3C, np = 0xC7EEB0B0)
-004|mxs_dma_xlate(:dma_spec = 0xC209BD60, :ofdma = 0xC2264840)
-005|of_dma_request_slave_channel(np = 0xC7EEB2B4, name = 0xC04F923A -> "rx-tx")
-006|dma_request_chan(dev = 0xC2182410, :name = 0xC04F923A -> "rx-tx")
-007|acquire_dma_channels(inline)
-007|acquire_resources(:this = 0xC200F840)
-008|gpmi_nand_probe(:pdev = 0xC2182400)
The root clock is BCH_CLK_ROOT. It doesn't depend on ENFC_PRED or ENFC_PODF
(the dividers which are actually set in clk_set_rate(r->clock[0], 22000000)).
--> clk_set_rate(r->clock[0], 22000000) is not required for accessing the
registers. I removed the call entirely and everything works fine.
> >
> > > > Then, the first call for an IO operation with ->must_apply_timings
> > > > should:
> > > >
> > > > if (imx6)
> > > > disable_clk();
> > > >
> > > > clk_set_rate();
> > > >
> > > > if (imx6)
> > > > enable_clk();
> >
> > Do you think that the need for avoiding clock glitches is i.MX6 specific?
> > The errata I mentioned is specific for the bootloader software, but (I think)
> > the requirement for switching off the clocks gates prior changing the dividers
> > may apply also for other series.
>
> I honestly don't know, perhaps Han have more details about it. If you
> think it's a wider issue, then we can just do the disable/enable step
> without any further checks.
I also don't know. I can not find the required sequence in the reference manual
(only in the errata sheet), so I cannot compare with other series. For best
performance we can start with checking for GPMI_IS_MX6Q(x) and extend it later
if this issue comes up on other devices.
I sent a question for this on NXP community:
https://community.nxp.com/t5/i-MX-Processors/ERR007117-Which-i-MX-devices-require-gating-the-clocks-when/m-p/1353018
> > > Actually we should ensure clks are enabled in the !imx6 case anyway,
> > > but this is needed only once so either we keep enabling the clock in
> > > the probe or we check here if the clk has already been enabled or not.
> > The clocks are already enabled (and kept on) in probe. The initial call to
> > clk_set_rate() is just above this (but the clocks are not disabled at this
> > stage as all gates have been enabled by the boot loader).
>
> The IO clock should be enabled and set to a particular rate the first
> time the die is selected to perform a NAND operation, or when we switch
> from one device to the other (this does not apply to the GPMI driver
> for now). So we can drop the enable/set_rate call in the probe if the
> assumption that this clock only feeds the external bus is right.
I think that this assumption is right.
regards
Christian
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2021-10-09 6:27 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-29 6:41 GPMI iMX6ull timeout on DMA Greg Ungerer
2019-07-29 8:36 ` Miquel Raynal
2019-07-29 8:42 ` Michael Nazzareno Trimarchi
2019-07-29 12:18 ` Greg Ungerer
2019-07-29 12:20 ` Michael Nazzareno Trimarchi
2019-07-29 12:33 ` Greg Ungerer
2019-07-29 12:47 ` Miquel Raynal
2019-07-29 12:49 ` Michael Nazzareno Trimarchi
2019-07-29 12:55 ` Miquel Raynal
2019-07-29 13:00 ` Michael Nazzareno Trimarchi
2019-07-29 13:22 ` Miquel Raynal
2019-07-29 20:00 ` Michael Nazzareno Trimarchi
2019-07-29 21:02 ` Miquel Raynal
2019-07-30 0:28 ` Greg Ungerer
2019-07-30 0:41 ` Greg Ungerer
2019-07-30 6:06 ` Greg Ungerer
2019-07-30 8:38 ` Miquel Raynal
2019-07-30 8:58 ` Boris Brezillon
2019-07-31 2:05 ` Greg Ungerer
2019-07-31 6:28 ` Boris Brezillon
2019-08-02 7:19 ` Greg Ungerer
2019-08-02 12:34 ` Greg Ungerer
2019-08-02 12:51 ` Boris Brezillon
2019-08-05 5:51 ` Greg Ungerer
2019-08-07 16:05 ` Miquel Raynal
2019-08-08 0:43 ` Greg Ungerer
2019-08-08 16:36 ` Boris Brezillon
2019-08-09 5:20 ` Greg Ungerer
2019-08-09 6:23 ` Boris Brezillon
2019-08-09 6:55 ` Greg Ungerer
2019-08-09 7:32 ` Boris Brezillon
2019-08-09 13:57 ` Greg Ungerer
2019-08-09 13:59 ` Boris Brezillon
2019-08-12 2:50 ` Greg Ungerer
2019-08-12 4:04 ` Greg Ungerer
2019-08-12 7:31 ` Boris Brezillon
2019-08-13 0:50 ` Greg Ungerer
2021-01-28 9:45 ` Michael Nazzareno Trimarchi
2021-01-28 10:26 ` Miquel Raynal
2021-01-28 10:35 ` Michael Nazzareno Trimarchi
2021-01-28 11:55 ` Michael Nazzareno Trimarchi
2021-01-29 12:43 ` Greg Ungerer
2021-01-30 9:41 ` Michael Nazzareno Trimarchi
2021-02-01 14:13 ` Miquel Raynal
2021-02-01 14:32 ` Michael Nazzareno Trimarchi
2021-02-01 15:08 ` Michael Nazzareno Trimarchi
2021-02-01 15:14 ` Miquel Raynal
2021-02-01 15:17 ` Michael Nazzareno Trimarchi
2021-10-15 20:05 ` Michael Trimarchi
2021-10-15 20:12 ` Michael Nazzareno Trimarchi
2021-10-18 7:19 ` Miquel Raynal
2021-10-18 7:33 ` Michael Nazzareno Trimarchi
2021-10-18 7:43 ` Miquel Raynal
2021-10-04 5:54 ` Christian Eggers
2021-10-04 6:27 ` Michael Nazzareno Trimarchi
2021-10-04 15:33 ` Miquel Raynal
2021-10-04 16:06 ` Han Xu
2021-10-05 6:02 ` Christian Eggers
2021-10-08 9:55 ` Christian Eggers
2021-10-08 12:08 ` Stefan Riedmüller
2021-10-08 12:27 ` Miquel Raynal
2021-10-08 13:11 ` Christian Eggers
2021-10-08 13:29 ` Miquel Raynal
2021-10-08 13:36 ` Miquel Raynal
2021-10-08 13:49 ` Christian Eggers
2021-10-08 16:07 ` Miquel Raynal
2021-10-09 5:53 ` Michael Nazzareno Trimarchi
2021-10-11 6:46 ` Miquel Raynal
2021-10-12 9:02 ` [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 Stefan Riedmueller
2021-10-12 9:02 ` [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings Stefan Riedmueller
2021-10-13 5:01 ` Han Xu
2021-10-22 8:45 ` Stefan Riedmüller
2021-10-22 14:35 ` han.xu
2021-10-25 9:39 ` Stefan Riedmüller
2021-10-28 9:28 ` Stefan Riedmüller
2021-11-01 4:01 ` han.xu
2021-10-13 6:10 ` Christian Eggers
2021-10-13 6:00 ` [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 Christian Eggers
2021-10-09 6:26 ` Christian Eggers [this message]
2021-10-13 6:15 ` GPMI iMX6ull timeout on DMA Christian Eggers
2021-10-08 13:13 ` Christian Eggers
2021-10-08 13:30 ` Miquel Raynal
2021-10-09 6:33 ` Christian Eggers
-- strict thread matches above, loose matches on Subject: below --
2018-10-02 13:22 GPMI IMX6ull timeout on dma Michael Nazzareno Trimarchi
2018-10-04 14:36 ` Michael Nazzareno Trimarchi
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=2811233.e9J7NaK4W3@n95hx1g2 \
--to=ceggers@arri.de \
--cc=C.Hemp@phytec.de \
--cc=S.Riedmueller@phytec.de \
--cc=gerg@kernel.org \
--cc=han.xu@nxp.com \
--cc=linux-mtd@lists.infradead.org \
--cc=michael@amarulasolutions.com \
--cc=miquel.raynal@bootlin.com \
--cc=s.hauer@pengutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).