linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chen-Yu Tsai <wens@csie.org>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Priit Laes <plaes@plaes.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>
Subject: Re: [RFC PATCH] clk: sunxi-ng: sun4i: Use CLK_SET_RATE_PARENT for mmc2 clock
Date: Tue, 5 Feb 2019 21:44:02 +0800	[thread overview]
Message-ID: <CAGb2v673ntXn7MTRhU1uecO9q8_i79e+Ovio=tucd6qFf5L84Q@mail.gmail.com> (raw)
In-Reply-To: <20190205094529.t7je4ozzu2b4ornc@flea>

On Tue, Feb 5, 2019 at 5:45 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Sat, Feb 02, 2019 at 05:52:09PM +0200, Priit Laes wrote:
> > Recent patch of improving MP clock rate calculations by taking
> > into account whether adjusting parent rate is allowed, have
> > unfortunately broken eMMC support on A20 Olinuxino-Lime2-eMMC
> > boards which fail with following error:
> >
> > [snip]
> > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly filesystem
> > EXT4-fs (mmcblk1p4): write access will be enabled during recovery
> > sunxi-mmc 1c11000.mmc: data error, sending stop command
> > sunxi-mmc 1c11000.mmc: send stop command failed
> > [/snip]
> >
> > Previously, mmc2 clock was requesting 520MHz and settling at 512MHz
> > clock rate with following parents:

You mean 52 and 51.2 MHz.

> > [snip]
> > pll-ddr-base        2  2        0   768000000 0     0  50000
> >    pll-ddr-other    1  1        0   768000000 0     0  50000
> >       mmc2          0  0        0    51200000 0     0  50000
> > [/snip]
> >
> > Now, after the improvements, requested and settled rate are both
> > 520MHz, but as mmc2 clock cannot adjust parent rate, the situation
> > ends up like this:
> > [snip]
> > pll-periph-base     3  3        0  1200000000 0     0  50000
> >    pll-periph       6  6        0   600000000 0     0  50000
> >       mmc2          3  3        0    50000000 0     0  50000
> > [/snip]
> >
> > With this patch (allowing mmc2 to set parent rate), we end up with
> > working tree with both mmc0 (sd-card) and mmc2 (eMMC) working:
> > [snip]
> > pll-periph-base     3  3        0   312000000 0     0  50000
> >    mbus             1  1        0    78000000 0     0  50000
> >    pll-periph-sata  1  1        0    26000000 0     0  50000
> >       sata          1  1        0    26000000 0     0  50000
> >    pll-periph       5  5        0   156000000 0     0  50000
> >       mmc2          0  0        0    52000000 0     0  50000
> >       mmc0          0  0        0    39000000 0     0  50000
> > [/snip]
> >
> > Fixes: 3f790433c3cb ("clk: sunxi-ng: Adjust MP clock parent rate when allowed")
> > Signed-off-by: Priit Laes <plaes@plaes.org>
>
> Applied, thanks!
> Maxime

I'm concerned for other users of the PLL-PERIPH clock. AFAIK
all of them, except the HRTIMER, expect the clock rate to stay
the same and not change underneath them. And SATA expects it to
be at 600 MHz, as the datasheet says. And while it may not directly
apply to the LIME2, eMMC on newer SoCs / boards run at the slightly
reduced rate of 50 MHz just fine.

In the commit in question, clocks without CLK_SET_RATE_PARENT
should be using the old code (now in the if conditional block),
i.e. the behavior should not have changed.

I don't think this actually "fixes" whatever bug was introduced,
but only papers over the issue, and possible introduces further
issues for other users.

Regards
ChenYu

  reply	other threads:[~2019-02-05 13:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-02 15:52 [RFC PATCH] clk: sunxi-ng: sun4i: Use CLK_SET_RATE_PARENT for mmc2 clock Priit Laes
2019-02-05  9:45 ` Maxime Ripard
2019-02-05 13:44   ` Chen-Yu Tsai [this message]
2019-02-06  9:20     ` Maxime Ripard
2019-02-06 10:03       ` Priit Laes
2019-02-06 15:52         ` Maxime Ripard
2019-02-11 14:35           ` Priit Laes
2019-02-11 15:34             ` Maxime Ripard
2019-02-12  9:45               ` Priit Laes

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='CAGb2v673ntXn7MTRhU1uecO9q8_i79e+Ovio=tucd6qFf5L84Q@mail.gmail.com' \
    --to=wens@csie.org \
    --cc=jernej.skrabec@siol.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=mturquette@baylibre.com \
    --cc=plaes@plaes.org \
    --cc=sboyd@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 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).