All of lore.kernel.org
 help / color / mirror / Atom feed
From: jbrunet@baylibre.com (Jerome Brunet)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH 2/3] clk: meson: clk-pll: remove od parameters
Date: Sat, 21 Jul 2018 22:42:25 +0200	[thread overview]
Message-ID: <1532205745.26720.81.camel@baylibre.com> (raw)
In-Reply-To: <CAFBinCAcqwhJUoLF3XkhOR2gnNk3cjEgh=ChTDybeRPLHgzeSg@mail.gmail.com>

On Sat, 2018-07-21 at 22:01 +0200, Martin Blumenstingl wrote:
> > +static struct clk_regmap gxbb_hdmi_pll_od = {
> > +       .data = &(struct clk_regmap_div_data){
> > +               .offset = HHI_HDMI_PLL_CNTL2,
> > +               .shift = 16,
> > +               .width = 2,
> > +               .flags = CLK_DIVIDER_POWER_OF_TWO,
> > +       },
> > +       .hw.init = &(struct clk_init_data){
> > +               .name = "hdmi_pll_od",
> > +               .ops = &clk_regmap_divider_ro_ops,
> > +               .parent_names = (const char *[]){ "hdmi_pll_dco" },
> > +               .num_parents = 1,
> > +               .flags = CLK_GET_RATE_NOCACHE,
> 
> why do we need CLK_GET_RATE_NOCACHE here?
> also, shouldn't all _od clocks use CLK_SET_RATE_PARENT?
> (this applies to all new _od clocks, not just this one)

The goal was to retain the original behavior of the clock.
The pll has CLK_GET_RATE_NOCACHE, which is why I put it again in the od
dividers. Same goes for ro_ops

For the particular case of the HDMI PLL, the display driver still set the pll
parameters m, n and ods directly which justify CLK_GET_RATE_NOCACHE for now.
Of course, the goal is to remove this flag someday. I think there has been some
good progress in the DRM driver to reach this goal.

If we think the use CLK_GET_RATE_NOCACHE is not justified for some other plls, I
would prefer if it was addressed in another patchset.

Regarding SET_RATE_PARENT, with the pll set with ro_ops, it does not change
anything but, I agree, it would be better to set flag for the future.

Cheers
Jerome

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet@baylibre.com>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>,
	linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-kernel@vger.kernel.org, khilman@baylibre.com
Subject: Re: [PATCH 2/3] clk: meson: clk-pll: remove od parameters
Date: Sat, 21 Jul 2018 22:42:25 +0200	[thread overview]
Message-ID: <1532205745.26720.81.camel@baylibre.com> (raw)
In-Reply-To: <CAFBinCAcqwhJUoLF3XkhOR2gnNk3cjEgh=ChTDybeRPLHgzeSg@mail.gmail.com>

On Sat, 2018-07-21 at 22:01 +0200, Martin Blumenstingl wrote:
> > +static struct clk_regmap gxbb_hdmi_pll_od = {
> > +       .data = &(struct clk_regmap_div_data){
> > +               .offset = HHI_HDMI_PLL_CNTL2,
> > +               .shift = 16,
> > +               .width = 2,
> > +               .flags = CLK_DIVIDER_POWER_OF_TWO,
> > +       },
> > +       .hw.init = &(struct clk_init_data){
> > +               .name = "hdmi_pll_od",
> > +               .ops = &clk_regmap_divider_ro_ops,
> > +               .parent_names = (const char *[]){ "hdmi_pll_dco" },
> > +               .num_parents = 1,
> > +               .flags = CLK_GET_RATE_NOCACHE,
> 
> why do we need CLK_GET_RATE_NOCACHE here?
> also, shouldn't all _od clocks use CLK_SET_RATE_PARENT?
> (this applies to all new _od clocks, not just this one)

The goal was to retain the original behavior of the clock.
The pll has CLK_GET_RATE_NOCACHE, which is why I put it again in the od
dividers. Same goes for ro_ops

For the particular case of the HDMI PLL, the display driver still set the pll
parameters m, n and ods directly which justify CLK_GET_RATE_NOCACHE for now.
Of course, the goal is to remove this flag someday. I think there has been some
good progress in the DRM driver to reach this goal.

If we think the use CLK_GET_RATE_NOCACHE is not justified for some other plls, I
would prefer if it was addressed in another patchset.

Regarding SET_RATE_PARENT, with the pll set with ro_ops, it does not change
anything but, I agree, it would be better to set flag for the future.

Cheers
Jerome

  reply	other threads:[~2018-07-21 20:42 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17  9:56 [PATCH 0/3] clk: meson: clk-pll driver update Jerome Brunet
2018-07-17  9:56 ` Jerome Brunet
2018-07-17  9:56 ` [PATCH 1/3] clk: meson: clk-pll: add enable bit Jerome Brunet
2018-07-17  9:56   ` Jerome Brunet
2018-07-17  9:56   ` Jerome Brunet
2018-07-19  8:33   ` Neil Armstrong
2018-07-19  8:33     ` Neil Armstrong
2018-07-21 19:48   ` Martin Blumenstingl
2018-07-21 19:48     ` Martin Blumenstingl
2018-07-21 20:26     ` Jerome Brunet
2018-07-21 20:26       ` Jerome Brunet
2018-07-17  9:56 ` [PATCH 2/3] clk: meson: clk-pll: remove od parameters Jerome Brunet
2018-07-17  9:56   ` Jerome Brunet
2018-07-19  8:42   ` Neil Armstrong
2018-07-19  8:42     ` Neil Armstrong
2018-07-19  8:45     ` Jerome Brunet
2018-07-19  8:45       ` Jerome Brunet
2018-07-21 20:01   ` Martin Blumenstingl
2018-07-21 20:01     ` Martin Blumenstingl
2018-07-21 20:42     ` Jerome Brunet [this message]
2018-07-21 20:42       ` Jerome Brunet
2018-07-21 21:37       ` Martin Blumenstingl
2018-07-21 21:37         ` Martin Blumenstingl
2018-07-17  9:56 ` [PATCH 3/3] clk: meson: clk-pll: drop hard-coded rates from pll tables Jerome Brunet
2018-07-17  9:56   ` Jerome Brunet
2018-07-19  8:44   ` Neil Armstrong
2018-07-19  8:44     ` Neil Armstrong
2018-07-19  8:59     ` Jerome Brunet
2018-07-19  8:59       ` Jerome Brunet
2018-07-21 20:16     ` Martin Blumenstingl
2018-07-21 20:16       ` Martin Blumenstingl
2018-07-21 20:46       ` Jerome Brunet
2018-07-21 20:46         ` Jerome Brunet
2018-07-21 21:34         ` Martin Blumenstingl
2018-07-21 21:34           ` Martin Blumenstingl
2018-07-26  8:48           ` jbrunet at baylibre.com
2018-07-26  8:48             ` jbrunet
2018-07-21 20:17 ` [PATCH 0/3] clk: meson: clk-pll driver update Martin Blumenstingl
2018-07-21 20:17   ` Martin Blumenstingl
2018-07-21 20:48   ` Jerome Brunet
2018-07-21 20:48     ` Jerome Brunet

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=1532205745.26720.81.camel@baylibre.com \
    --to=jbrunet@baylibre.com \
    --cc=linus-amlogic@lists.infradead.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.