[PATCH] clk: rockchip: change hierarchy for some clocks

[PATCH] clk: rockchip: change hierarchy for some clocks

[Kever Yang]

This patch change the hierarchy for some clocks, to met the following
bus hierarchy:
hclk_usb_peri is bus clock for
|- hclk_otg0,
|- hclk_host0,
|- hclk_host1,
|- hclk_hsic

hclk_emem is bus clock for
|- hclk_nandc0
|- hclk_nandc1

hclk_mem is bus clock for
|- hclk_sdmmc
|- hclk_sdio0
|- hclk_sdio1
|- hclk_emmc

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
---

 drivers/clk/rockchip/clk-rk3288.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
index 7a0741d..e1106ad 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -652,21 +652,21 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
 
 	/* hclk_peri gates */
 	GATE(0, "hclk_peri_matrix", "hclk_peri", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(6), 0, GFLAGS),
-	GATE(HCLK_OTG0, "hclk_otg0", "hclk_peri", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(7), 4, GFLAGS),
-	GATE(HCLK_USBHOST0, "hclk_host0", "hclk_peri", 0, RK3288_CLKGATE_CON(7), 6, GFLAGS),
-	GATE(HCLK_USBHOST1, "hclk_host1", "hclk_peri", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(7), 7, GFLAGS),
-	GATE(HCLK_HSIC, "hclk_hsic", "hclk_peri", 0, RK3288_CLKGATE_CON(7), 8, GFLAGS),
+	GATE(HCLK_OTG0, "hclk_otg0", "hclk_usb_peri", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(7), 4, GFLAGS),
+	GATE(HCLK_USBHOST0, "hclk_host0", "hclk_usb_peri", 0, RK3288_CLKGATE_CON(7), 6, GFLAGS),
+	GATE(HCLK_USBHOST1, "hclk_host1", "hclk_usb_peri", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(7), 7, GFLAGS),
+	GATE(HCLK_HSIC, "hclk_hsic", "hclk_usb_peri", 0, RK3288_CLKGATE_CON(7), 8, GFLAGS),
 	GATE(0, "hclk_usb_peri", "hclk_peri", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(7), 9, GFLAGS),
 	GATE(0, "hclk_peri_ahb_arbi", "hclk_peri", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(7), 10, GFLAGS),
 	GATE(0, "hclk_emem", "hclk_peri", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(7), 12, GFLAGS),
 	GATE(0, "hclk_mem", "hclk_peri", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(7), 13, GFLAGS),
-	GATE(HCLK_NANDC0, "hclk_nandc0", "hclk_peri", 0, RK3288_CLKGATE_CON(7), 14, GFLAGS),
-	GATE(HCLK_NANDC1, "hclk_nandc1", "hclk_peri", 0, RK3288_CLKGATE_CON(7), 15, GFLAGS),
+	GATE(HCLK_NANDC0, "hclk_nandc0", "hclk_emem", 0, RK3288_CLKGATE_CON(7), 14, GFLAGS),
+	GATE(HCLK_NANDC1, "hclk_nandc1", "hclk_emem", 0, RK3288_CLKGATE_CON(7), 15, GFLAGS),
 	GATE(HCLK_TSP, "hclk_tsp", "hclk_peri", 0, RK3288_CLKGATE_CON(8), 8, GFLAGS),
-	GATE(HCLK_SDMMC, "hclk_sdmmc", "hclk_peri", 0, RK3288_CLKGATE_CON(8), 3, GFLAGS),
-	GATE(HCLK_SDIO0, "hclk_sdio0", "hclk_peri", 0, RK3288_CLKGATE_CON(8), 4, GFLAGS),
-	GATE(HCLK_SDIO1, "hclk_sdio1", "hclk_peri", 0, RK3288_CLKGATE_CON(8), 5, GFLAGS),
-	GATE(HCLK_EMMC, "hclk_emmc", "hclk_peri", 0, RK3288_CLKGATE_CON(8), 6, GFLAGS),
+	GATE(HCLK_SDMMC, "hclk_sdmmc", "hclk_mem", 0, RK3288_CLKGATE_CON(8), 3, GFLAGS),
+	GATE(HCLK_SDIO0, "hclk_sdio0", "hclk_mem", 0, RK3288_CLKGATE_CON(8), 4, GFLAGS),
+	GATE(HCLK_SDIO1, "hclk_sdio1", "hclk_mem", 0, RK3288_CLKGATE_CON(8), 5, GFLAGS),
+	GATE(HCLK_EMMC, "hclk_emmc", "hclk_mem", 0, RK3288_CLKGATE_CON(8), 6, GFLAGS),
 	GATE(HCLK_HSADC, "hclk_hsadc", "hclk_peri", 0, RK3288_CLKGATE_CON(8), 7, GFLAGS),
 	GATE(0, "pmu_hclk_otg0", "hclk_peri", 0, RK3288_CLKGATE_CON(7), 5, GFLAGS),
 
-- 
1.9.1

Re: [PATCH] clk: rockchip: change hierarchy for some clocks

[Doug Anderson]

Kever

On Fri, Oct 31, 2014 at 2:29 AM, Kever Yang <kever.yang@rock-chips.com> wrote:
> This patch change the hierarchy for some clocks, to met the following
> bus hierarchy:
> hclk_usb_peri is bus clock for
> |- hclk_otg0,
> |- hclk_host0,
> |- hclk_host1,
> |- hclk_hsic
>
> hclk_emem is bus clock for
> |- hclk_nandc0
> |- hclk_nandc1
>
> hclk_mem is bus clock for
> |- hclk_sdmmc
> |- hclk_sdio0
> |- hclk_sdio1
> |- hclk_emmc

So as I understand it the "parent" clocks aren't really parents but
are actually peer clocks.  That is if "hclk_usb_peri" is gated
"hclk_otg0" continues to run.  ...but the OTG periperhal is useless
without "hclk_usb_peri" also being enabled.

There doesn't seem to be any real downside to modeling thing as you
have done it, though it's not quite a true representation of the
world.  A slightly more true representation would be to make it so
that whenever "hclk_otg0" is enabled/disabled that it makes an
enable/disable call to "hclk_usb_peri".  I think you'd have to
subclass the gate clock and patch your stuff in the "enable" function.

I'm personally OK with things landing as you've described it (I can
see no downside), but it seems like this at least deserves a comment
(either in the code or the commit message).

If Mike T. thinks that we should use a more truthful model or if
there's some better way to express this, you should of course listen
to him and not to me.


-Doug

Re: [PATCH] clk: rockchip: change hierarchy for some clocks

[Kever Yang]

Hi Doug,

On 11/05/2014 05:32 AM, Doug Anderson wrote:
> Kever
>
> On Fri, Oct 31, 2014 at 2:29 AM, Kever Yang <kever.yang@rock-chips.com> wrote:
>> This patch change the hierarchy for some clocks, to met the following
>> bus hierarchy:
>> hclk_usb_peri is bus clock for
>> |- hclk_otg0,
>> |- hclk_host0,
>> |- hclk_host1,
>> |- hclk_hsic
>>
>> hclk_emem is bus clock for
>> |- hclk_nandc0
>> |- hclk_nandc1
>>
>> hclk_mem is bus clock for
>> |- hclk_sdmmc
>> |- hclk_sdio0
>> |- hclk_sdio1
>> |- hclk_emmc
> So as I understand it the "parent" clocks aren't really parents but
> are actually peer clocks.  That is if "hclk_usb_peri" is gated
> "hclk_otg0" continues to run.  ...but the OTG periperhal is useless
> without "hclk_usb_peri" also being enabled.
Correct.
>
> There doesn't seem to be any real downside to modeling thing as you
> have done it, though it's not quite a true representation of the
> world.  A slightly more true representation would be to make it so
> that whenever "hclk_otg0" is enabled/disabled that it makes an
> enable/disable call to "hclk_usb_peri".  I think you'd have to
> subclass the gate clock and patch your stuff in the "enable" function.
>
> I'm personally OK with things landing as you've described it (I can
> see no downside), but it seems like this at least deserves a comment
> (either in the code or the commit message).
I will update the commit message in new version, I describe it
in a private mail ask for how to handle this kind of clock, but not
in this patch, I will add it.
>
> If Mike T. thinks that we should use a more truthful model or if
> there's some better way to express this, you should of course listen
> to him and not to me.
Sure, I'm always looks for a better way for these kind of clocks,
there are many other clocks like *_arbi and *_niu still on rk3288
are not handled by any module which we have to use
CLK_IGNORE_UNUSED tag when disable unused init.

- Kever

Re: [PATCH] clk: rockchip: change hierarchy for some clocks

[Doug Anderson]

Mike,

On Wed, Nov 19, 2014 at 6:55 PM, Mike Turquette <mturquette@linaro.org> wrote:
> Quoting Doug Anderson (2014-11-04 13:32:49)
>> Kever
>>
>> On Fri, Oct 31, 2014 at 2:29 AM, Kever Yang <kever.yang@rock-chips.com> wrote:
>> > This patch change the hierarchy for some clocks, to met the following
>> > bus hierarchy:
>> > hclk_usb_peri is bus clock for
>> > |- hclk_otg0,
>> > |- hclk_host0,
>> > |- hclk_host1,
>> > |- hclk_hsic
>> >
>> > hclk_emem is bus clock for
>> > |- hclk_nandc0
>> > |- hclk_nandc1
>> >
>> > hclk_mem is bus clock for
>> > |- hclk_sdmmc
>> > |- hclk_sdio0
>> > |- hclk_sdio1
>> > |- hclk_emmc
>>
>> So as I understand it the "parent" clocks aren't really parents but
>> are actually peer clocks.  That is if "hclk_usb_peri" is gated
>> "hclk_otg0" continues to run.  ...but the OTG periperhal is useless
>> without "hclk_usb_peri" also being enabled.
>>
>> There doesn't seem to be any real downside to modeling thing as you
>> have done it, though it's not quite a true representation of the
>> world.  A slightly more true representation would be to make it so
>> that whenever "hclk_otg0" is enabled/disabled that it makes an
>> enable/disable call to "hclk_usb_peri".  I think you'd have to
>> subclass the gate clock and patch your stuff in the "enable" function.
>>
>> I'm personally OK with things landing as you've described it (I can
>> see no downside), but it seems like this at least deserves a comment
>> (either in the code or the commit message).
>>
>> If Mike T. thinks that we should use a more truthful model or if
>> there's some better way to express this, you should of course listen
>> to him and not to me.
>
> I'm coming back to this thread sort of late (V2 is posted but the
> discussion is here in V1). I strongly believe that we should model the
> hardware closely, unless there is a convincing reason to do otherwise.
> That makes it more maintainable and more debuggable (e.g. the code
> matches the data sheet).
>
> Seems like there isn't a reason to make these clocks follow a
> parent/child relationship except for convenience?
>
> To clarify further, the requirement for enabling/maintaining the clocks
> isn't really about the clocks themselves, but about the downstream IP
> that consumes the clocks, right? In that case it is the downstream
> driver's responsibility to enable/disable these clocks to spec, not the
> clock driver's job to hide these details.

I don't think it's the downstream driver's job in this case.  Let me
see if I can describe it as I understand it:

1. We've got 4 different USB IP blocks _plus_ an IP block that all 4
blocks are connected to that helps interconnect them to the rest of
the system.

2. The USB IP blocks are not accessible unless the interconnect is clocked.

3. The Interconnect's clock is not truly the parent of the USB IP blocks.

You could maybe draw it like this (assumes fixed width)

                        clk_interconnect
                                |
            +------+       +---------+
-clk_usb1---| USB1 |==bus==|         |
            +------+       |         |
            +------+       |         |
-clk_usb2---| USB2 |==bus==| inter-  |==bus==
            +------+       | connect |
            +------+       |         |
-clk_usb3---| USB3 |==bus==|         |
            +------+       +---------+


The USB driver shouldn't need to know that there is an interconnect
hooking up the USB block to the rest of the system.  It's an artifact
of the SoC.  The USB driver should just turn on its bus clock.

In a pure sense we should have it so that if we turn on any of
clk_usb1, clk_usb2, or clk_usb3 we should tun on the interconnect.
...but we shouldn't describe them as parents because in the hardware
there's no real parent child relationship.

...but since we don't care about the rate of the clk_interconnect (we
can't control it separately) and if we list clk_usb1, clk_usb2, and
clk_usb3 as children of clk_interconnect we magically get everything
we want...


-Doug