All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Stuebner <heiko@sntech.de>
To: Ezequiel Garcia <ezequiel@collabora.com>
Cc: "Jagan Teki" <jagan@amarulasolutions.com>,
	"Mylène Josserand" <mylene.josserand@collabora.com>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	kernel@collabora.com, linux-clk <linux-clk@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 1/2] clk: rockchip: rk3288: Handle clock tree for rk3288w
Date: Fri, 03 Jul 2020 17:05:12 +0200	[thread overview]
Message-ID: <2058941.hOsm0qqLio@phil> (raw)
In-Reply-To: <8d667ae2554ebf3d9867f6f449973825c969b062.camel@collabora.com>

Am Freitag, 3. Juli 2020, 17:02:52 CEST schrieb Ezequiel Garcia:
> On Fri, 2020-07-03 at 16:11 +0200, Heiko Stuebner wrote:
> > Hi Jagan,
> > 
> > Am Montag, 29. Juni 2020, 21:11:03 CEST schrieb Jagan Teki:
> > > On Tue, Jun 2, 2020 at 1:37 PM Mylène Josserand
> > > <mylene.josserand@collabora.com> wrote:
> > > > The revision rk3288w has a different clock tree about "hclk_vio"
> > > > clock, according to the BSP kernel code.
> > > > 
> > > > This patch handles this difference by detecting which device-tree
> > > > we are using. If it is a "rockchip,rk3288-cru", let's register
> > > > the clock tree as it was before. If the device-tree node is
> > > > "rockchip,rk3288w-cru", we will apply the difference with this
> > > > version of this SoC.
> > > > 
> > > > Noticed that this new device-tree compatible must be handled in
> > > > bootloader such as u-boot.
> > > > 
> > > > Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com>
> > > > ---
> > > >  drivers/clk/rockchip/clk-rk3288.c | 20 ++++++++++++++++++--
> > > >  1 file changed, 18 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
> > > > index cc2a177bbdbf..204976e2d0cb 100644
> > > > --- a/drivers/clk/rockchip/clk-rk3288.c
> > > > +++ b/drivers/clk/rockchip/clk-rk3288.c
> > > > @@ -425,8 +425,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
> > > >         COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
> > > >                         RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS,
> > > >                         RK3288_CLKGATE_CON(3), 0, GFLAGS),
> > > > -       DIV(0, "hclk_vio", "aclk_vio0", 0,
> > > > -                       RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
> > > >         COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
> > > >                         RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS,
> > > >                         RK3288_CLKGATE_CON(3), 2, GFLAGS),
> > > > @@ -819,6 +817,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
> > > >         INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3, IFLAGS),
> > > >  };
> > > > 
> > > > +static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = {
> > > > +       DIV(0, "hclk_vio", "aclk_vio1", 0,
> > > > +                       RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
> > > > +};
> > > > +
> > > > +static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = {
> > > > +       DIV(0, "hclk_vio", "aclk_vio0", 0,
> > > > +                       RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
> > > > +};
> > > > +
> > > >  static const char *const rk3288_critical_clocks[] __initconst = {
> > > >         "aclk_cpu",
> > > >         "aclk_peri",
> > > > @@ -936,6 +944,14 @@ static void __init rk3288_clk_init(struct device_node *np)
> > > >                                    RK3288_GRF_SOC_STATUS1);
> > > >         rockchip_clk_register_branches(ctx, rk3288_clk_branches,
> > > >                                   ARRAY_SIZE(rk3288_clk_branches));
> > > > +
> > > > +       if (of_device_is_compatible(np, "rockchip,rk3288w-cru"))
> > > > +               rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch,
> > > > +                                              ARRAY_SIZE(rk3288w_hclkvio_branch));
> > > > +       else
> > > > +               rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch,
> > > > +                                              ARRAY_SIZE(rk3288_hclkvio_branch));
> > > > +
> > > 
> > > Sorry for the late query on this. I am a bit unclear about this
> > > compatible change, does Linux expect to replace rockchip,rk3288-cru
> > > with rockchip,rk3288w-cru in bootloader if the chip is RK3288w? or
> > > append the existing cru compatible node with rockchip,rk3288w-cru?
> > > because replace new cru node make clock never probe since the
> > > CLK_OF_DECLARE checking rockchip,rk3288-cru
> > 
> > I guess right now we'd expect "rockchip,rk3288w-cru", "rockchip,rk3288-cru",
> > 
> > Thinking again about this, I'm wondering if we should switch to having
> > only one per variant ... like on the two rk3188 variants,
> > so declaring separate rk3288-cru and rk3288w-cru of-clks with shared
> > common code.
> > 
> 
> If we want to take this route (which I think makes sense), we should
> do that sooner than later, so we don't release two different implementations
> with two different requirements.
> 
> This change should be quite simple, no?

the underlying change is queued for 5.9, but yeah I am currently testing
exactly such a patch ;-)
Especially as when reading the binding addition it states
rk3288w-cru _or_ rk3288-cru for the compatible.


Heiko



WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Ezequiel Garcia <ezequiel@collabora.com>
Cc: "Mylène Josserand" <mylene.josserand@collabora.com>,
	devicetree <devicetree@vger.kernel.org>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Jagan Teki" <jagan@amarulasolutions.com>,
	kernel@collabora.com, linux-clk <linux-clk@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 1/2] clk: rockchip: rk3288: Handle clock tree for rk3288w
Date: Fri, 03 Jul 2020 17:05:12 +0200	[thread overview]
Message-ID: <2058941.hOsm0qqLio@phil> (raw)
In-Reply-To: <8d667ae2554ebf3d9867f6f449973825c969b062.camel@collabora.com>

Am Freitag, 3. Juli 2020, 17:02:52 CEST schrieb Ezequiel Garcia:
> On Fri, 2020-07-03 at 16:11 +0200, Heiko Stuebner wrote:
> > Hi Jagan,
> > 
> > Am Montag, 29. Juni 2020, 21:11:03 CEST schrieb Jagan Teki:
> > > On Tue, Jun 2, 2020 at 1:37 PM Mylène Josserand
> > > <mylene.josserand@collabora.com> wrote:
> > > > The revision rk3288w has a different clock tree about "hclk_vio"
> > > > clock, according to the BSP kernel code.
> > > > 
> > > > This patch handles this difference by detecting which device-tree
> > > > we are using. If it is a "rockchip,rk3288-cru", let's register
> > > > the clock tree as it was before. If the device-tree node is
> > > > "rockchip,rk3288w-cru", we will apply the difference with this
> > > > version of this SoC.
> > > > 
> > > > Noticed that this new device-tree compatible must be handled in
> > > > bootloader such as u-boot.
> > > > 
> > > > Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com>
> > > > ---
> > > >  drivers/clk/rockchip/clk-rk3288.c | 20 ++++++++++++++++++--
> > > >  1 file changed, 18 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
> > > > index cc2a177bbdbf..204976e2d0cb 100644
> > > > --- a/drivers/clk/rockchip/clk-rk3288.c
> > > > +++ b/drivers/clk/rockchip/clk-rk3288.c
> > > > @@ -425,8 +425,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
> > > >         COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
> > > >                         RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS,
> > > >                         RK3288_CLKGATE_CON(3), 0, GFLAGS),
> > > > -       DIV(0, "hclk_vio", "aclk_vio0", 0,
> > > > -                       RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
> > > >         COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
> > > >                         RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS,
> > > >                         RK3288_CLKGATE_CON(3), 2, GFLAGS),
> > > > @@ -819,6 +817,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
> > > >         INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3, IFLAGS),
> > > >  };
> > > > 
> > > > +static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = {
> > > > +       DIV(0, "hclk_vio", "aclk_vio1", 0,
> > > > +                       RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
> > > > +};
> > > > +
> > > > +static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = {
> > > > +       DIV(0, "hclk_vio", "aclk_vio0", 0,
> > > > +                       RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
> > > > +};
> > > > +
> > > >  static const char *const rk3288_critical_clocks[] __initconst = {
> > > >         "aclk_cpu",
> > > >         "aclk_peri",
> > > > @@ -936,6 +944,14 @@ static void __init rk3288_clk_init(struct device_node *np)
> > > >                                    RK3288_GRF_SOC_STATUS1);
> > > >         rockchip_clk_register_branches(ctx, rk3288_clk_branches,
> > > >                                   ARRAY_SIZE(rk3288_clk_branches));
> > > > +
> > > > +       if (of_device_is_compatible(np, "rockchip,rk3288w-cru"))
> > > > +               rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch,
> > > > +                                              ARRAY_SIZE(rk3288w_hclkvio_branch));
> > > > +       else
> > > > +               rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch,
> > > > +                                              ARRAY_SIZE(rk3288_hclkvio_branch));
> > > > +
> > > 
> > > Sorry for the late query on this. I am a bit unclear about this
> > > compatible change, does Linux expect to replace rockchip,rk3288-cru
> > > with rockchip,rk3288w-cru in bootloader if the chip is RK3288w? or
> > > append the existing cru compatible node with rockchip,rk3288w-cru?
> > > because replace new cru node make clock never probe since the
> > > CLK_OF_DECLARE checking rockchip,rk3288-cru
> > 
> > I guess right now we'd expect "rockchip,rk3288w-cru", "rockchip,rk3288-cru",
> > 
> > Thinking again about this, I'm wondering if we should switch to having
> > only one per variant ... like on the two rk3188 variants,
> > so declaring separate rk3288-cru and rk3288w-cru of-clks with shared
> > common code.
> > 
> 
> If we want to take this route (which I think makes sense), we should
> do that sooner than later, so we don't release two different implementations
> with two different requirements.
> 
> This change should be quite simple, no?

the underlying change is queued for 5.9, but yeah I am currently testing
exactly such a patch ;-)
Especially as when reading the binding addition it states
rk3288w-cru _or_ rk3288-cru for the compatible.


Heiko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-07-03 15:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-02  8:06 [PATCH v4 0/2] ARM: Add Rockchip rk3288w support Mylène Josserand
2020-06-02  8:06 ` Mylène Josserand
2020-06-02  8:06 ` Mylène Josserand
2020-06-02  8:06 ` [PATCH v4 1/2] clk: rockchip: rk3288: Handle clock tree for rk3288w Mylène Josserand
2020-06-02  8:06   ` Mylène Josserand
2020-06-29 19:11   ` Jagan Teki
2020-06-29 19:11     ` Jagan Teki
2020-07-03 14:11     ` Heiko Stuebner
2020-07-03 14:11       ` Heiko Stuebner
2020-07-03 14:23       ` Jagan Teki
2020-07-03 14:23         ` Jagan Teki
2020-07-03 14:48         ` Heiko Stuebner
2020-07-03 14:48           ` Heiko Stuebner
2020-07-03 15:43           ` Robin Murphy
2020-07-03 15:43             ` Robin Murphy
2020-07-03 15:02       ` Ezequiel Garcia
2020-07-03 15:02         ` Ezequiel Garcia
2020-07-03 15:05         ` Heiko Stuebner [this message]
2020-07-03 15:05           ` Heiko Stuebner
2020-06-02  8:06 ` [PATCH v4 2/2] dt-bindings: clocks: rk3288: add rk3288w compatible Mylène Josserand
2020-06-02  8:06   ` Mylène Josserand
2020-06-09 22:47   ` Rob Herring
2020-06-09 22:47     ` Rob Herring
2020-06-17  8:58 ` [PATCH v4 0/2] ARM: Add Rockchip rk3288w support Heiko Stuebner
2020-06-17  8:58   ` Heiko Stuebner
2020-06-17  8:58   ` Heiko Stuebner
2020-06-29  7:59   ` Mylene Josserand
2020-06-29  7:59     ` Mylene Josserand

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=2058941.hOsm0qqLio@phil \
    --to=heiko@sntech.de \
    --cc=devicetree@vger.kernel.org \
    --cc=ezequiel@collabora.com \
    --cc=jagan@amarulasolutions.com \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=mylene.josserand@collabora.com \
    --cc=robh+dt@kernel.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 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.