Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[PATCH] ARM: imx6q: Add missing esai_ahb clock to current clock tree
1 view
Skip to first unread message
Nicolin Chen
Jan 8, 2014, 10:10:02 PM1/8/14
to
esai_ahb clock is derived from ahb and used to provide ESAI the capability of
register accessing and FSYS clock source for I2S clocks dividing. Although the
gate of this esai_ahb is duplicated with esai clock -- the baud clock, yet
considering about the differences of their clock rates, it's quite essential
to patch this missing clock.
Signed-off-by: Nicolin Chen <Guangy...@freescale.com>
---
Documentation/devicetree/bindings/clock/imx6q-clock.txt | 1 +
arch/arm/mach-imx/clk-imx6q.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 6aab72b..90ec91f 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -220,6 +220,7 @@ clocks and IDs.
lvds2_sel 205
lvds1_gate 206
lvds2_gate 207
+ esai_ahb 208
Examples:
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index af2e582..20215b9 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -107,7 +107,7 @@ enum mx6q_clks {
sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, pll4_audio_div,
- lvds1_sel, lvds2_sel, lvds1_gate, lvds2_gate, clk_max
+ lvds1_sel, lvds2_sel, lvds1_gate, lvds2_gate, esai_ahb, clk_max
};
static struct clk *clk[clk_max];
@@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
+ clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
clk[gpt_ipg] = imx_clk_gate2("gpt_ipg", "ipg", base + 0x6c, 20);
clk[gpt_ipg_per] = imx_clk_gate2("gpt_ipg_per", "ipg_per", base + 0x6c, 22);
if (cpu_is_imx6dl())
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
register accessing and FSYS clock source for I2S clocks dividing. Although the
gate of this esai_ahb is duplicated with esai clock -- the baud clock, yet
considering about the differences of their clock rates, it's quite essential
to patch this missing clock.
Signed-off-by: Nicolin Chen <Guangy...@freescale.com>
---
Documentation/devicetree/bindings/clock/imx6q-clock.txt | 1 +
arch/arm/mach-imx/clk-imx6q.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 6aab72b..90ec91f 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -220,6 +220,7 @@ clocks and IDs.
lvds2_sel 205
lvds1_gate 206
lvds2_gate 207
+ esai_ahb 208
Examples:
diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index af2e582..20215b9 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -107,7 +107,7 @@ enum mx6q_clks {
sata_ref, sata_ref_100m, pcie_ref, pcie_ref_125m, enet_ref, usbphy1_gate,
usbphy2_gate, pll4_post_div, pll5_post_div, pll5_video_div, eim_slow,
spdif, cko2_sel, cko2_podf, cko2, cko, vdoa, pll4_audio_div,
- lvds1_sel, lvds2_sel, lvds1_gate, lvds2_gate, clk_max
+ lvds1_sel, lvds2_sel, lvds1_gate, lvds2_gate, esai_ahb, clk_max
};
static struct clk *clk[clk_max];
@@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
+ clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
clk[gpt_ipg] = imx_clk_gate2("gpt_ipg", "ipg", base + 0x6c, 20);
clk[gpt_ipg_per] = imx_clk_gate2("gpt_ipg_per", "ipg_per", base + 0x6c, 22);
if (cpu_is_imx6dl())
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Shawn Guo
Jan 8, 2014, 11:00:01 PM1/8/14
to
problem in clock disabling. Clock enabling is fine, since either
one who calls clk_enable() first will just set the gate bit. But in
case that clk_enable() is called on both clocks, and then when either
clock calls clk_disable(), the gate bit will be cleared and thus breaks
the other one that might still be in use.
Shawn
Nicolin Chen
Jan 8, 2014, 11:10:02 PM1/8/14
to
On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > static struct clk *clk[clk_max];
> > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> > clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> > clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
>
> Hmm, having two clocks operating on the same gate bit will get us
> problem in clock disabling. Clock enabling is fine, since either
> one who calls clk_enable() first will just set the gate bit. But in
> case that clk_enable() is called on both clocks, and then when either
> clock calls clk_disable(), the gate bit will be cleared and thus breaks
> the other one that might still be in use.
Understood. But how could we handle this situation? The only way I can figure
> > static struct clk *clk[clk_max];
> > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> > clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> > clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
>
> Hmm, having two clocks operating on the same gate bit will get us
> problem in clock disabling. Clock enabling is fine, since either
> one who calls clk_enable() first will just set the gate bit. But in
> case that clk_enable() is called on both clocks, and then when either
> clock calls clk_disable(), the gate bit will be cleared and thus breaks
> the other one that might still be in use.
out is to make sure the driver open/close them at the same time, it's not a
perfect way though.
Nicolin
Shawn Guo
Jan 9, 2014, 2:00:01 AM1/9/14
to
On Thu, Jan 09, 2014 at 11:49:41AM +0800, Nicolin Chen wrote:
> On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > static struct clk *clk[clk_max];
> > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > > clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> > > clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> > > clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> > > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
> >
> > Hmm, having two clocks operating on the same gate bit will get us
> > problem in clock disabling. Clock enabling is fine, since either
> > one who calls clk_enable() first will just set the gate bit. But in
> > case that clk_enable() is called on both clocks, and then when either
> > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > the other one that might still be in use.
>
> Understood. But how could we handle this situation? The only way I can figure
> out is to make sure the driver open/close them at the same time, it's not a
> perfect way though.
Hmm, we generally leave the gate bit to the clock used to access
> On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > static struct clk *clk[clk_max];
> > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > > clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> > > clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> > > clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> > > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
> >
> > Hmm, having two clocks operating on the same gate bit will get us
> > problem in clock disabling. Clock enabling is fine, since either
> > one who calls clk_enable() first will just set the gate bit. But in
> > case that clk_enable() is called on both clocks, and then when either
> > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > the other one that might still be in use.
>
> Understood. But how could we handle this situation? The only way I can figure
> out is to make sure the driver open/close them at the same time, it's not a
> perfect way though.
register, because usually it's the first one to be on and the last one
to be off.
Shawn
Sascha Hauer
Jan 9, 2014, 3:00:02 AM1/9/14
to
On Thu, Jan 09, 2014 at 03:41:38PM +0800, Nicolin Chen wrote:
> the clock used to access memory, shouldn't we?
Please wait for Mikes input or let's look how a proper solution can look
like. I've already seen the case that a single bit controls multiple
clocks. Hacking around this issue each time is not a solution.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
> On Thu, Jan 09, 2014 at 02:57:42PM +0800, Shawn Guo wrote:
> > On Thu, Jan 09, 2014 at 11:49:41AM +0800, Nicolin Chen wrote:
> > > On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > > > static struct clk *clk[clk_max];
> > > > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > > > > clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> > > > > clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> > > > > clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> > > > > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
> > > >
> > > > Hmm, having two clocks operating on the same gate bit will get us
> > > > problem in clock disabling. Clock enabling is fine, since either
> > > > one who calls clk_enable() first will just set the gate bit. But in
> > > > case that clk_enable() is called on both clocks, and then when either
> > > > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > > > the other one that might still be in use.
> > >
> > > Understood. But how could we handle this situation? The only way I can figure
> > > out is to make sure the driver open/close them at the same time, it's not a
> > > perfect way though.
> >
> > Hmm, we generally leave the gate bit to the clock used to access
> > register, because usually it's the first one to be on and the last one
> > to be off.
>
> Then we should attach CLK_IGNORE_UNUSED to clk[esai] since clk[esai_ahb] is
> > On Thu, Jan 09, 2014 at 11:49:41AM +0800, Nicolin Chen wrote:
> > > On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > > > static struct clk *clk[clk_max];
> > > > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > > > > clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> > > > > clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> > > > > clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> > > > > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
> > > >
> > > > Hmm, having two clocks operating on the same gate bit will get us
> > > > problem in clock disabling. Clock enabling is fine, since either
> > > > one who calls clk_enable() first will just set the gate bit. But in
> > > > case that clk_enable() is called on both clocks, and then when either
> > > > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > > > the other one that might still be in use.
> > >
> > > Understood. But how could we handle this situation? The only way I can figure
> > > out is to make sure the driver open/close them at the same time, it's not a
> > > perfect way though.
> >
> > Hmm, we generally leave the gate bit to the clock used to access
> > register, because usually it's the first one to be on and the last one
> > to be off.
>
> the clock used to access memory, shouldn't we?
Please wait for Mikes input or let's look how a proper solution can look
like. I've already seen the case that a single bit controls multiple
clocks. Hacking around this issue each time is not a solution.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Nicolin Chen
Jan 9, 2014, 3:00:02 AM1/9/14
to
On Thu, Jan 09, 2014 at 02:57:42PM +0800, Shawn Guo wrote:
> On Thu, Jan 09, 2014 at 11:49:41AM +0800, Nicolin Chen wrote:
> > On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > > static struct clk *clk[clk_max];
> > > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > > > clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> > > > clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> > > > clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> > > > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
> > >
> > > Hmm, having two clocks operating on the same gate bit will get us
> > > problem in clock disabling. Clock enabling is fine, since either
> > > one who calls clk_enable() first will just set the gate bit. But in
> > > case that clk_enable() is called on both clocks, and then when either
> > > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > > the other one that might still be in use.
> >
> > Understood. But how could we handle this situation? The only way I can figure
> > out is to make sure the driver open/close them at the same time, it's not a
> > perfect way though.
>
> Hmm, we generally leave the gate bit to the clock used to access
> register, because usually it's the first one to be on and the last one
> to be off.
> On Thu, Jan 09, 2014 at 11:49:41AM +0800, Nicolin Chen wrote:
> > On Thu, Jan 09, 2014 at 11:58:12AM +0800, Shawn Guo wrote:
> > > > static struct clk *clk[clk_max];
> > > > @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> > > > clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> > > > clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> > > > clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> > > > + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
> > >
> > > Hmm, having two clocks operating on the same gate bit will get us
> > > problem in clock disabling. Clock enabling is fine, since either
> > > one who calls clk_enable() first will just set the gate bit. But in
> > > case that clk_enable() is called on both clocks, and then when either
> > > clock calls clk_disable(), the gate bit will be cleared and thus breaks
> > > the other one that might still be in use.
> >
> > Understood. But how could we handle this situation? The only way I can figure
> > out is to make sure the driver open/close them at the same time, it's not a
> > perfect way though.
>
> Hmm, we generally leave the gate bit to the clock used to access
> register, because usually it's the first one to be on and the last one
> to be off.
Then we should attach CLK_IGNORE_UNUSED to clk[esai] since clk[esai_ahb] is
the clock used to access memory, shouldn't we?
Thank you.
Nicolin
Sascha Hauer
Jan 9, 2014, 3:00:02 AM1/9/14
to
[Added Mike Turquette to Cc]
On Thu, Jan 09, 2014 at 11:04:59AM +0800, Nicolin Chen wrote:
> static struct clk *clk[clk_max];
> @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
We have the situation here that a single bit controls two clocks. As
Shawn mentioned just using two gates on the same bit doesn't work
properly. Do we need a new basic clock type or expand the common gate
code somehow?
This situation happens from time to time and I haven't seen a solution
for this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Thu, Jan 09, 2014 at 11:04:59AM +0800, Nicolin Chen wrote:
> esai_ahb clock is derived from ahb and used to provide ESAI the capability of
> register accessing and FSYS clock source for I2S clocks dividing. Although the
> gate of this esai_ahb is duplicated with esai clock -- the baud clock, yet
> considering about the differences of their clock rates, it's quite essential
> to patch this missing clock.
>
[...]
> register accessing and FSYS clock source for I2S clocks dividing. Although the
> gate of this esai_ahb is duplicated with esai clock -- the baud clock, yet
> considering about the differences of their clock rates, it's quite essential
> to patch this missing clock.
>
> static struct clk *clk[clk_max];
> @@ -355,6 +355,7 @@ static void __init imx6q_clocks_init(struct device_node *ccm_node)
> clk[ecspi5] = imx_clk_gate2("ecspi5", "ecspi_root", base + 0x6c, 8);
> clk[enet] = imx_clk_gate2("enet", "ipg", base + 0x6c, 10);
> clk[esai] = imx_clk_gate2("esai", "esai_podf", base + 0x6c, 16);
> + clk[esai_ahb] = imx_clk_gate2("esai_ahb", "ahb", base + 0x6c, 16);
Shawn mentioned just using two gates on the same bit doesn't work
properly. Do we need a new basic clock type or expand the common gate
code somehow?
This situation happens from time to time and I haven't seen a solution
for this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Nicolin Chen
Jan 9, 2014, 3:10:01 AM1/9/14
to
Thank you, Sascha.
Gerhard Sittig
Jan 9, 2014, 10:00:02 AM1/9/14
to
On Thu, Jan 09, 2014 at 08:55 +0100, Sascha Hauer wrote:
>
> [ ... ]
Date: Tue, 23 Jul 2013 15:14:06 +0200
From: Gerhard Sittig <g...@denx.de>
To: linuxp...@lists.ozlabs.org, Anatolij Gustschin <ag...@denx.de>,
Mike Turquette <mturq...@linaro.org>,
linux-ar...@lists.infradead.org, devic...@vger.kernel.org
Cc: [ ... ]
Subject: Re: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185687.html
The specific situation was for MS-CAN on PowerPC, but it inspired
my outlining an approach to "shared clock gates". See an example
implementation towards the end of the message with both the
clk-gate.c extension, as well as rather generic example use.
My approach turned out to not be needed, but it might serve as a
starting point for you. You'd have to add support for static
declaration though, but this should be straight forward.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
>
> [ ... ]
>
> We have the situation here that a single bit controls two clocks. As
> Shawn mentioned just using two gates on the same bit doesn't work
> properly. Do we need a new basic clock type or expand the common gate
> code somehow?
> This situation happens from time to time and I haven't seen a solution
> for this.
You may want to lookup the following message:
> We have the situation here that a single bit controls two clocks. As
> Shawn mentioned just using two gates on the same bit doesn't work
> properly. Do we need a new basic clock type or expand the common gate
> code somehow?
> This situation happens from time to time and I haven't seen a solution
> for this.
Date: Tue, 23 Jul 2013 15:14:06 +0200
From: Gerhard Sittig <g...@denx.de>
To: linuxp...@lists.ozlabs.org, Anatolij Gustschin <ag...@denx.de>,
Mike Turquette <mturq...@linaro.org>,
linux-ar...@lists.infradead.org, devic...@vger.kernel.org
Cc: [ ... ]
Subject: Re: [PATCH v3 17/31] clk: mpc512x: introduce COMMON_CLK for MPC512x
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185687.html
The specific situation was for MS-CAN on PowerPC, but it inspired
my outlining an approach to "shared clock gates". See an example
implementation towards the end of the message with both the
clk-gate.c extension, as well as rather generic example use.
My approach turned out to not be needed, but it might serve as a
starting point for you. You'd have to add support for static
declaration though, but this should be straight forward.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
Russell King - ARM Linux
Jan 9, 2014, 10:10:02 AM1/9/14
to
Sascha, your messages have the Mail-Followup-To: header...
Mail-Followup-To: Nicolin Chen <Guangy...@freescale.com>,
shaw...@linaro.org, ker...@pengutronix.de, li...@arm.linux.org.uk,
linux-ar...@lists.infradead.org, linux-...@vger.kernel.org,
rob.h...@calxeda.com, pawel...@arm.com, mark.r...@arm.com,
ijc+dev...@hellion.org.uk, ga...@codeaurora.org,
devic...@vger.kernel.org, r...@landley.net, mturq...@linaro.org
resulting in me (and others) getting mails marked as To: me where they're
not supposed to be To: me in the first place.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
Mail-Followup-To: Nicolin Chen <Guangy...@freescale.com>,
shaw...@linaro.org, ker...@pengutronix.de, li...@arm.linux.org.uk,
linux-ar...@lists.infradead.org, linux-...@vger.kernel.org,
rob.h...@calxeda.com, pawel...@arm.com, mark.r...@arm.com,
ijc+dev...@hellion.org.uk, ga...@codeaurora.org,
devic...@vger.kernel.org, r...@landley.net, mturq...@linaro.org
resulting in me (and others) getting mails marked as To: me where they're
not supposed to be To: me in the first place.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
Sascha Hauer
Jan 10, 2014, 5:10:01 AM1/10/14
to
Russell,
On Thu, Jan 09, 2014 at 03:01:41PM +0000, Russell King - ARM Linux wrote:
> Sascha, your messages have the Mail-Followup-To: header...
>
> Mail-Followup-To: Nicolin Chen <Guangy...@freescale.com>,
> shaw...@linaro.org, ker...@pengutronix.de, li...@arm.linux.org.uk,
> linux-ar...@lists.infradead.org, linux-...@vger.kernel.org,
> rob.h...@calxeda.com, pawel...@arm.com, mark.r...@arm.com,
> ijc+dev...@hellion.org.uk, ga...@codeaurora.org,
> devic...@vger.kernel.org, r...@landley.net, mturq...@linaro.org
>
> resulting in me (and others) getting mails marked as To: me where they're
> not supposed to be To: me in the first place.
This should be fixed with this mail.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Thu, Jan 09, 2014 at 03:01:41PM +0000, Russell King - ARM Linux wrote:
> Sascha, your messages have the Mail-Followup-To: header...
>
> Mail-Followup-To: Nicolin Chen <Guangy...@freescale.com>,
> shaw...@linaro.org, ker...@pengutronix.de, li...@arm.linux.org.uk,
> linux-ar...@lists.infradead.org, linux-...@vger.kernel.org,
> rob.h...@calxeda.com, pawel...@arm.com, mark.r...@arm.com,
> ijc+dev...@hellion.org.uk, ga...@codeaurora.org,
> devic...@vger.kernel.org, r...@landley.net, mturq...@linaro.org
>
> resulting in me (and others) getting mails marked as To: me where they're
> not supposed to be To: me in the first place.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
0 new messages