From: Jerome Brunet <jbrunet@baylibre.com>
To: Shawn Lin <shawn.lin@rock-chips.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>
Cc: Heiko Stuebner <heiko@sntech.de>,
linux-clk@vger.kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH] clk: Don't show the incorrect clock phase
Date: Thu, 08 Mar 2018 13:03:53 +0100 [thread overview]
Message-ID: <1520510633.4264.42.camel@baylibre.com> (raw)
In-Reply-To: <ceb696cb-9961-00c0-20ef-324c590fb0ed@rock-chips.com>
On Thu, 2018-03-08 at 19:46 +0800, Shawn Lin wrote:
> > > > Good point!
> > > >
> > > > (1)So either we should update phase once its rate is updated, for
> > > > instance, doing it in clk_change_rate, or
> > >
> > > I don't think this would be a good option. The phase depending on the rate is
> > > just one example. I'm pretty sure one could come up with another example
> > >
> > > >
> > > > (2)we should always try to get the actual phase here.
> > >
> > > If the callback is available, lets use it. I prefer this second option
> > >
>
> okay.
>
> > > >
> > > > If we do anyway call ->get_phase, we should never need core->phase since
> > > > it doesn't reflect the actual phase maybe.
> > >
> > > The cached value is used by debugfs so it is still a valuable information. I
> > > would keep it around for now.
> >
> > Oh ! and let's not forget that a clock driver is allowed to implement
> > set_phase() w/o implementing get_phase() ... so you definitively want to keep
> > the cached value around
> >
>
> Yes, it's a little complicated. I just thought a case that, if the
> driver need a fixed phase i.e. by call clk_set_phase(180), but the clk's
> phase depends on the clk rate. So if the clk rate changed, the phase is
> changed as well. This isn't good to the IP should sample the data based
> on the phase shift but never get notified that the phase is changed.
I suppose this use case comes from the mmc (most phase users are mmc drivers) ?
The fact that you would want ,for your use case, to lock the phase whatever the
rate changes seems like a choice. It makes sense for sure, but maybe not all
driver would want to enforce that. I'm not sure we should bake that in the
framework itself.
For such case, a solution could be to use clock notifiers to call
clk_set_phase() on rate change,
OR
in the clock driver set_rate() callback, cache the phase at the beginning and
call set_phase() again before returning.
Anyway, let's keep it simple for now and report the phase correctly. We can
still deal these particular situations with some other patches.
next prev parent reply other threads:[~2018-03-08 12:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-08 7:54 [PATCH] clk: Don't show the incorrect clock phase Shawn Lin
2018-03-08 9:40 ` Geert Uytterhoeven
2018-03-08 11:15 ` Shawn Lin
2018-03-08 10:04 ` Jerome Brunet
2018-03-08 11:28 ` Shawn Lin
2018-03-08 11:37 ` Jerome Brunet
2018-03-08 11:39 ` Jerome Brunet
2018-03-08 11:46 ` Shawn Lin
2018-03-08 12:03 ` Jerome Brunet [this message]
2018-03-08 12:11 ` Shawn Lin
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=1520510633.4264.42.camel@baylibre.com \
--to=jbrunet@baylibre.com \
--cc=geert@linux-m68k.org \
--cc=heiko@sntech.de \
--cc=linux-clk@vger.kernel.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@kernel.org \
--cc=shawn.lin@rock-chips.com \
/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