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

2014-11-19 Thread Doug Anderson
Mike,

On Wed, Nov 19, 2014 at 6:55 PM, Mike Turquette  wrote:
> Quoting Doug Anderson (2014-11-04 13:32:49)
>> Kever
>>
>> On Fri, Oct 31, 2014 at 2:29 AM, Kever Yang  
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-11-19 Thread Doug Anderson
Mike,

On Wed, Nov 19, 2014 at 6:55 PM, Mike Turquette mturque...@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.y...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-11-04 Thread 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  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-11-04 Thread Doug Anderson
Kever

On Fri, Oct 31, 2014 at 2:29 AM, Kever Yang  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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-11-04 Thread Doug Anderson
Kever

On Fri, Oct 31, 2014 at 2:29 AM, Kever Yang kever.y...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-11-04 Thread 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.y...@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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-10-31 Thread 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 
---

 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2014-10-31 Thread 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.y...@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

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/