Re: [PATCH] clk: rockchip: change hierarchy for some clocks
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
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
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
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
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
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
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
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/
