From: Mike Turquette <mturquette@linaro.org>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: devicetree@vger.kernel.org, ulf.hansson@linaro.org,
Emilio Lopez <emilio@elopez.com.ar>,
linux-mmc@vger.kernel.org, chris@printf.net,
Hans de Goede <hdegoede@redhat.com>,
wens@csie.org, david.lanzendoerfer@o2s.ch,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 03/12] clk: Add a function to retrieve phase
Date: Tue, 30 Sep 2014 00:01:17 -0700 [thread overview]
Message-ID: <20140930070117.19023.51389@quantum> (raw)
In-Reply-To: <20140929082421.GA4388@lukather>
Quoting Maxime Ripard (2014-09-29 01:24:21)
> Hi Mike,
>
> On Sat, Sep 27, 2014 at 05:17:32PM -0700, Mike Turquette wrote:
> > Quoting Maxime Ripard (2014-09-11 13:18:17)
> > > The current phase API doesn't look into the actual hardware to get the phase
> > > value, but will rather get it from a variable only set by the set_phase
> > > function.
> > >
> > > This will cause issue when the client driver will never call the set_phase
> > > function, where we can end up having a reported phase that will not match what
> > > the hardware has been programmed to by the bootloader or what phase is
> > > programmed out of reset.
> > >
> > > Add a new get_phase function for the drivers to implement so that we can get
> > > this value.
> > >
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > ---
> > > drivers/clk/clk.c | 10 ++++++++++
> > > include/linux/clk-provider.h | 5 +++++
> > > 2 files changed, 15 insertions(+)
> > >
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > index d87661af0c72..113d75db371d 100644
> > > --- a/drivers/clk/clk.c
> > > +++ b/drivers/clk/clk.c
> > > @@ -1934,6 +1934,16 @@ int __clk_init(struct device *dev, struct clk *clk)
> > > clk->accuracy = 0;
> > >
> > > /*
> > > + * Set clk's phase.
> > > + * Since a phase is by definition relative to its parent, just
> > > + * query the current clock phase, or just assume it's in phase.
> > > + */
> > > + if (clk->ops->get_phase)
> > > + clk->phase = clk->ops->get_phase(clk->hw);
> > > + else
> > > + clk->phase = 0;
> >
> > I probably wasn't paying enough attention to this. Based on the
> > coverletter I thought that v3 would introduce something like
> > CLK_GET_PHASE_NOCACHE and stuff that logic into a __clk_get_phase
> > function? Looks like this version of the series doesn't handle phases
> > that can be changed by hardware (e.g. coming out of idle).
> >
> > Correct me if I am wrong, but it looks like we retrieve the phase only
> > once at init and then never again? The rest of the time we rely on
> > clk->phase to always be accurate...
>
> Yeah, I didn't have any use for it at the moment, and thought that if
> someone ever needed it, it would be trivial to add, so I left it out.
>
> If you want me to still do it, I can send an additional patch.
No it is fine. A bit asymmetrical for my brain but it is dead code if no
one is using it (yet).
Regards,
Mike
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: mturquette@linaro.org (Mike Turquette)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 03/12] clk: Add a function to retrieve phase
Date: Tue, 30 Sep 2014 00:01:17 -0700 [thread overview]
Message-ID: <20140930070117.19023.51389@quantum> (raw)
In-Reply-To: <20140929082421.GA4388@lukather>
Quoting Maxime Ripard (2014-09-29 01:24:21)
> Hi Mike,
>
> On Sat, Sep 27, 2014 at 05:17:32PM -0700, Mike Turquette wrote:
> > Quoting Maxime Ripard (2014-09-11 13:18:17)
> > > The current phase API doesn't look into the actual hardware to get the phase
> > > value, but will rather get it from a variable only set by the set_phase
> > > function.
> > >
> > > This will cause issue when the client driver will never call the set_phase
> > > function, where we can end up having a reported phase that will not match what
> > > the hardware has been programmed to by the bootloader or what phase is
> > > programmed out of reset.
> > >
> > > Add a new get_phase function for the drivers to implement so that we can get
> > > this value.
> > >
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > ---
> > > drivers/clk/clk.c | 10 ++++++++++
> > > include/linux/clk-provider.h | 5 +++++
> > > 2 files changed, 15 insertions(+)
> > >
> > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > > index d87661af0c72..113d75db371d 100644
> > > --- a/drivers/clk/clk.c
> > > +++ b/drivers/clk/clk.c
> > > @@ -1934,6 +1934,16 @@ int __clk_init(struct device *dev, struct clk *clk)
> > > clk->accuracy = 0;
> > >
> > > /*
> > > + * Set clk's phase.
> > > + * Since a phase is by definition relative to its parent, just
> > > + * query the current clock phase, or just assume it's in phase.
> > > + */
> > > + if (clk->ops->get_phase)
> > > + clk->phase = clk->ops->get_phase(clk->hw);
> > > + else
> > > + clk->phase = 0;
> >
> > I probably wasn't paying enough attention to this. Based on the
> > coverletter I thought that v3 would introduce something like
> > CLK_GET_PHASE_NOCACHE and stuff that logic into a __clk_get_phase
> > function? Looks like this version of the series doesn't handle phases
> > that can be changed by hardware (e.g. coming out of idle).
> >
> > Correct me if I am wrong, but it looks like we retrieve the phase only
> > once at init and then never again? The rest of the time we rely on
> > clk->phase to always be accurate...
>
> Yeah, I didn't have any use for it at the moment, and thought that if
> someone ever needed it, it would be trivial to add, so I left it out.
>
> If you want me to still do it, I can send an additional patch.
No it is fine. A bit asymmetrical for my brain but it is dead code if no
one is using it (yet).
Regards,
Mike
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
next prev parent reply other threads:[~2014-09-30 7:01 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-11 20:18 [PATCH v3 00/12] clk: sunxi: Improve MMC clocks support Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-11 20:18 ` [PATCH v3 01/12] clk: introduce clk_set_phase function & callback Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-24 10:41 ` Heiko Stübner
2014-09-24 10:41 ` Heiko Stübner
2014-09-11 20:18 ` [PATCH v3 02/12] clk: Include of.h in clock-provider.h Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-11 20:18 ` [PATCH v3 03/12] clk: Add a function to retrieve phase Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-24 10:42 ` Heiko Stübner
2014-09-24 10:42 ` Heiko Stübner
2014-09-28 0:17 ` Mike Turquette
2014-09-28 0:17 ` Mike Turquette
2014-09-29 8:24 ` Maxime Ripard
2014-09-29 8:24 ` Maxime Ripard
2014-09-30 7:01 ` Mike Turquette [this message]
2014-09-30 7:01 ` Mike Turquette
2014-09-11 20:18 ` [PATCH v3 05/12] clk: sunxi: Introduce mbus compatible Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
[not found] ` <1410466706-27386-1-git-send-email-maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-09-11 20:18 ` [PATCH v3 04/12] clk: sunxi: factors: Invert the probing logic Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-11 20:18 ` [PATCH v3 06/12] ARM: sunxi: dt: Switch to the new mbus compatible Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-11 20:18 ` [PATCH v3 09/12] ARM: sunxi: dt: Add sample and output mmc clocks Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-12 10:23 ` Chen-Yu Tsai
2014-09-12 10:23 ` Chen-Yu Tsai
2014-09-13 8:18 ` Maxime Ripard
2014-09-13 8:18 ` Maxime Ripard
2014-09-13 8:24 ` Chen-Yu Tsai
2014-09-13 8:24 ` Chen-Yu Tsai
2014-09-11 20:18 ` [PATCH v3 07/12] clk: sunxi: Move mod0 clock to a file of its own Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-11 20:18 ` [PATCH v3 08/12] clk: sunxi: Move mbus to mod0 file Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-11 20:18 ` [PATCH v3 10/12] clk: sunxi: mod0: Introduce MMC proper phase handling Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-11 20:18 ` [PATCH v3 11/12] mmc: sunxi: Convert MMC driver to the standard clock phase API Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-26 14:27 ` David Lanzendörfer
2014-09-26 14:27 ` David Lanzendörfer
[not found] ` <3992138.y6J8TjIuMq-pgFh0Jf6HD9Xzn/AsuzBOg@public.gmane.org>
2014-09-26 15:02 ` Maxime Ripard
2014-09-26 15:02 ` Maxime Ripard
2014-09-26 20:47 ` David Lanzendörfer
2014-09-26 20:47 ` David Lanzendörfer
2014-09-11 20:18 ` [PATCH v3 12/12] clk: sunxi: Remove custom phase function Maxime Ripard
2014-09-11 20:18 ` Maxime Ripard
2014-09-12 7:22 ` [PATCH v3 00/12] clk: sunxi: Improve MMC clocks support Hans de Goede
2014-09-12 7:22 ` Hans de Goede
2014-09-22 11:31 ` Maxime Ripard
2014-09-22 11:31 ` Maxime Ripard
2014-09-26 0:42 ` Mike Turquette
2014-09-26 0:42 ` Mike Turquette
2014-09-26 6:55 ` Maxime Ripard
2014-09-26 6:55 ` Maxime Ripard
2014-09-26 17:52 ` Mike Turquette
2014-09-26 17:52 ` Mike Turquette
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=20140930070117.19023.51389@quantum \
--to=mturquette@linaro.org \
--cc=chris@printf.net \
--cc=david.lanzendoerfer@o2s.ch \
--cc=devicetree@vger.kernel.org \
--cc=emilio@elopez.com.ar \
--cc=hdegoede@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=ulf.hansson@linaro.org \
--cc=wens@csie.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.