Re: [PATCH v3 0/4] clk: st: New always-on clock domain
On Thu, 02 Apr 2015, Geert Uytterhoeven wrote: > On Thu, Mar 26, 2015 at 8:38 PM, Lee Jones wrote: > > On Thu, 26 Mar 2015, Geert Uytterhoeven wrote: > >> On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones wrote: > >> > On Wed, 25 Mar 2015, Geert Uytterhoeven wrote: > >> >> On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote: > >> >> > On Fri, 06 Mar 2015, Mike Turquette wrote: > >> >> >> This approach looks fine to me. In practice I think it is restricted > >> >> >> to > >> >> >> hardware blocks that don't exist in DT yet (e.g. no driver, in the > >> >> >> case > >> >> >> of your interconnect) and that restriction is probably for the best. > >> >> > > >> >> > Agreed. > >> >> > >> >> I think this restriction should be documented in the DT binding more > >> >> clearly, > >> >> as adding a "clk-always-on" node prohibits you from handling the clock > >> >> correctly in > >> >> the future. > >> > > >> > Would you mind taking the time to explain what you think those > >> > limitations are? > >> > >> If you add a "clk-always-on" node, the clock will always on using that DT. > >> That will still be true later, when you get a better understanding of the > >> hardware, and might discover you're gonna need a driver for the currently > >> hidden core component that's driven by the clock, and may want to manage > >> that clock. > > > > So I have two points here. > > > > First point; I think you're looking at an older version of my set. > > The newer one can be found at [1] and no longer uses 'always-on' > > nodes. Instead the 'clk-always-on' property is applied to the > > provider. See the documentation patch [2] for more details. > > Thanks, I was indeed looking at an old version. > Still, that doesn't change that the clock to not be disabled in specified > explicitly from DT. > > > Second point; this binding is _not_ to be used as a hack because the > > hardware isn't understood. Genuine uses are for clocks that must not > > be turned off ever, else bad things will happen. If the hardware is > > not understood, use 'clk-disable-unused' on the kernel cmdline > > instead. [...] > > If this clock should _genuinely_ be always-on, then use my new > > binding in the clock controller node and the Clk framework will not > > turn it off. > > It's supposed to be on when the application ARM core(s) is/are running. > Many SoCs also have smaller cores (SH, Cortex R or M), intended to > run a real-time OS. If the RT core is in charge, it may decide to shut down > the application ARM core(s), incl. supposedly always-on modules like > the ARM GIC. > > I couldn't find a detailed block diagram of the STiH4xx SoCs, but at least > STiH416 has an "ST proprietary multi-compartmental security IP and DRM > processor". You might be interested in the latest incarnation of the set. See if it solves your issues. https://lkml.org/lkml/2015/4/1/267 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Hi Lee,
On Thu, Mar 26, 2015 at 8:38 PM, Lee Jones wrote:
> On Thu, 26 Mar 2015, Geert Uytterhoeven wrote:
>> On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones wrote:
>> > On Wed, 25 Mar 2015, Geert Uytterhoeven wrote:
>> >> On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote:
>> >> > On Fri, 06 Mar 2015, Mike Turquette wrote:
>> >> >> This approach looks fine to me. In practice I think it is restricted to
>> >> >> hardware blocks that don't exist in DT yet (e.g. no driver, in the case
>> >> >> of your interconnect) and that restriction is probably for the best.
>> >> >
>> >> > Agreed.
>> >>
>> >> I think this restriction should be documented in the DT binding more
>> >> clearly,
>> >> as adding a "clk-always-on" node prohibits you from handling the clock
>> >> correctly in
>> >> the future.
>> >
>> > Would you mind taking the time to explain what you think those
>> > limitations are?
>>
>> If you add a "clk-always-on" node, the clock will always on using that DT.
>> That will still be true later, when you get a better understanding of the
>> hardware, and might discover you're gonna need a driver for the currently
>> hidden core component that's driven by the clock, and may want to manage
>> that clock.
>
> So I have two points here.
>
> First point; I think you're looking at an older version of my set.
> The newer one can be found at [1] and no longer uses 'always-on'
> nodes. Instead the 'clk-always-on' property is applied to the
> provider. See the documentation patch [2] for more details.
Thanks, I was indeed looking at an old version.
Still, that doesn't change that the clock to not be disabled in specified
explicitly from DT.
> Second point; this binding is _not_ to be used as a hack because the
> hardware isn't understood. Genuine uses are for clocks that must not
> be turned off ever, else bad things will happen. If the hardware is
> not understood, use 'clk-disable-unused' on the kernel cmdline
> instead.
[...]
>> (The same is true for devices where the current driver isn't aware of the
>> clock, and shouldn't be, but you still need to enable the clock until the
>> driver has Runtime PM support (E.g. ARM GIC on shmobile, cfr.
>> https://www.marc.info/?l=linux-pm=142670617929493=3 (good, now
>> we have a bidirectional link between these two threads :-) Using a
>> "clk-always-on" property there instead of adding a reference to the clock
>> in the existing GIC device node would be just lying.)
>
> If this clock should _genuinely_ be always-on, then use my new
> binding in the clock controller node and the Clk framework will not
> turn it off.
It's supposed to be on when the application ARM core(s) is/are running.
Many SoCs also have smaller cores (SH, Cortex R or M), intended to
run a real-time OS. If the RT core is in charge, it may decide to shut down
the application ARM core(s), incl. supposedly always-on modules like
the ARM GIC.
I couldn't find a detailed block diagram of the STiH4xx SoCs, but at least
STiH416 has an "ST proprietary multi-compartmental security IP and DRM
processor".
> [1] https://lkml.org/lkml/2015/2/27/548
> [2] https://lkml.org/lkml/2015/2/27/551
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v3 0/4] clk: st: New always-on clock domain
Hi Lee,
On Thu, Mar 26, 2015 at 8:38 PM, Lee Jones lee.jo...@linaro.org wrote:
On Thu, 26 Mar 2015, Geert Uytterhoeven wrote:
On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones lee.jo...@linaro.org wrote:
On Wed, 25 Mar 2015, Geert Uytterhoeven wrote:
On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones lee.jo...@linaro.org wrote:
On Fri, 06 Mar 2015, Mike Turquette wrote:
This approach looks fine to me. In practice I think it is restricted to
hardware blocks that don't exist in DT yet (e.g. no driver, in the case
of your interconnect) and that restriction is probably for the best.
Agreed.
I think this restriction should be documented in the DT binding more
clearly,
as adding a clk-always-on node prohibits you from handling the clock
correctly in
the future.
Would you mind taking the time to explain what you think those
limitations are?
If you add a clk-always-on node, the clock will always on using that DT.
That will still be true later, when you get a better understanding of the
hardware, and might discover you're gonna need a driver for the currently
hidden core component that's driven by the clock, and may want to manage
that clock.
So I have two points here.
First point; I think you're looking at an older version of my set.
The newer one can be found at [1] and no longer uses 'always-on'
nodes. Instead the 'clk-always-on' property is applied to the
provider. See the documentation patch [2] for more details.
Thanks, I was indeed looking at an old version.
Still, that doesn't change that the clock to not be disabled in specified
explicitly from DT.
Second point; this binding is _not_ to be used as a hack because the
hardware isn't understood. Genuine uses are for clocks that must not
be turned off ever, else bad things will happen. If the hardware is
not understood, use 'clk-disable-unused' on the kernel cmdline
instead.
[...]
(The same is true for devices where the current driver isn't aware of the
clock, and shouldn't be, but you still need to enable the clock until the
driver has Runtime PM support (E.g. ARM GIC on shmobile, cfr.
https://www.marc.info/?l=linux-pmm=142670617929493w=3 (good, now
we have a bidirectional link between these two threads :-) Using a
clk-always-on property there instead of adding a reference to the clock
in the existing GIC device node would be just lying.)
If this clock should _genuinely_ be always-on, then use my new
binding in the clock controller node and the Clk framework will not
turn it off.
It's supposed to be on when the application ARM core(s) is/are running.
Many SoCs also have smaller cores (SH, Cortex R or M), intended to
run a real-time OS. If the RT core is in charge, it may decide to shut down
the application ARM core(s), incl. supposedly always-on modules like
the ARM GIC.
I couldn't find a detailed block diagram of the STiH4xx SoCs, but at least
STiH416 has an ST proprietary multi-compartmental security IP and DRM
processor.
[1] https://lkml.org/lkml/2015/2/27/548
[2] https://lkml.org/lkml/2015/2/27/551
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 v3 0/4] clk: st: New always-on clock domain
On Thu, 02 Apr 2015, Geert Uytterhoeven wrote: On Thu, Mar 26, 2015 at 8:38 PM, Lee Jones lee.jo...@linaro.org wrote: On Thu, 26 Mar 2015, Geert Uytterhoeven wrote: On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones lee.jo...@linaro.org wrote: On Wed, 25 Mar 2015, Geert Uytterhoeven wrote: On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones lee.jo...@linaro.org wrote: On Fri, 06 Mar 2015, Mike Turquette wrote: This approach looks fine to me. In practice I think it is restricted to hardware blocks that don't exist in DT yet (e.g. no driver, in the case of your interconnect) and that restriction is probably for the best. Agreed. I think this restriction should be documented in the DT binding more clearly, as adding a clk-always-on node prohibits you from handling the clock correctly in the future. Would you mind taking the time to explain what you think those limitations are? If you add a clk-always-on node, the clock will always on using that DT. That will still be true later, when you get a better understanding of the hardware, and might discover you're gonna need a driver for the currently hidden core component that's driven by the clock, and may want to manage that clock. So I have two points here. First point; I think you're looking at an older version of my set. The newer one can be found at [1] and no longer uses 'always-on' nodes. Instead the 'clk-always-on' property is applied to the provider. See the documentation patch [2] for more details. Thanks, I was indeed looking at an old version. Still, that doesn't change that the clock to not be disabled in specified explicitly from DT. Second point; this binding is _not_ to be used as a hack because the hardware isn't understood. Genuine uses are for clocks that must not be turned off ever, else bad things will happen. If the hardware is not understood, use 'clk-disable-unused' on the kernel cmdline instead. [...] If this clock should _genuinely_ be always-on, then use my new binding in the clock controller node and the Clk framework will not turn it off. It's supposed to be on when the application ARM core(s) is/are running. Many SoCs also have smaller cores (SH, Cortex R or M), intended to run a real-time OS. If the RT core is in charge, it may decide to shut down the application ARM core(s), incl. supposedly always-on modules like the ARM GIC. I couldn't find a detailed block diagram of the STiH4xx SoCs, but at least STiH416 has an ST proprietary multi-compartmental security IP and DRM processor. You might be interested in the latest incarnation of the set. See if it solves your issues. https://lkml.org/lkml/2015/4/1/267 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
On Thu, 26 Mar 2015, Geert Uytterhoeven wrote: > Hi Lee, > > On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones wrote: > > On Wed, 25 Mar 2015, Geert Uytterhoeven wrote: > >> On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote: > >> > On Fri, 06 Mar 2015, Mike Turquette wrote: > >> >> This approach looks fine to me. In practice I think it is restricted to > >> >> hardware blocks that don't exist in DT yet (e.g. no driver, in the case > >> >> of your interconnect) and that restriction is probably for the best. > >> > > >> > Agreed. > >> > >> I think this restriction should be documented in the DT binding more > >> clearly, > >> as adding a "clk-always-on" node prohibits you from handling the clock > >> correctly in > >> the future. > > > > Would you mind taking the time to explain what you think those > > limitations are? > > If you add a "clk-always-on" node, the clock will always on using that DT. > That will still be true later, when you get a better understanding of the > hardware, and might discover you're gonna need a driver for the currently > hidden core component that's driven by the clock, and may want to manage > that clock. So I have two points here. First point; I think you're looking at an older version of my set. The newer one can be found at [1] and no longer uses 'always-on' nodes. Instead the 'clk-always-on' property is applied to the provider. See the documentation patch [2] for more details. Second point; this binding is _not_ to be used as a hack because the hardware isn't understood. Genuine uses are for clocks that must not be turned off ever, else bad things will happen. If the hardware is not understood, use 'clk-disable-unused' on the kernel cmdline instead. > When that happens, you're gonna need a DT update to make use of the > newly introduced driver and the features it provides (e.g. better power > management). The whole point of this set is to manage clocks that can't be power managed. Using the 'clk-always-on' property labels the clock with a big-red-sign saying "DO NOT TURN ME OFF, OR RISK CATASTROPHIC FAILURE", not a "TODO: Fix-me when you understand me". > On the other hand, if you would describe the actual hardware topology in DT, > the device node for the future driver would already be there, and no DT update > is needed (assuming you can guess right w.r.t. its bindings; usually these are > transparent buses, for which bindings are fairly generic, cfr. e.g. > "simple-pm-bus"). In our case the devices these clocks control will never be added to Device Tree. Linux can't see them, they have no registers and they can't be controlled. Added a device driver for all such devices would be foolhardy. > Until you have (a need for) a real driver, you do need some platform code that > makes sure the clock is enabled. When a real driver is introduced, the > platform code has to be updated, but DT doesn't have to change. No, this binding is _not_ for that use-case. If your platform is incomplete you must use 'clk-disable-unused'. > (The same is true for devices where the current driver isn't aware of the > clock, and shouldn't be, but you still need to enable the clock until the > driver has Runtime PM support (E.g. ARM GIC on shmobile, cfr. > https://www.marc.info/?l=linux-pm=142670617929493=3 (good, now > we have a bidirectional link between these two threads :-) Using a > "clk-always-on" property there instead of adding a reference to the clock > in the existing GIC device node would be just lying.) If this clock should _genuinely_ be always-on, then use my new binding in the clock controller node and the Clk framework will not turn it off. > If we start seeing many users, perhaps we need a general framework where > the platform code can register a list of clocks that must be enabled > (properly, > i.e. using clk_prepare_enable())? But I don't think the list should be put > in DT: DT describes hardware, not behavior. I did this in the very first iteration of this set. The DT guys didn't like it, which is why I re-wrote it to look like [1]. > If you don't care about DT stability, and can afford always updating your DT > with your kernel, the above doesn't apply. I heard during the ELC hallways > chats this is actually the case for you? My ears burning eh? Do tell... I think you currently misunderstand the use-case for this set. I hope my points above will clarify the point somewhat. Once we write the bindings and the DT nodes in [1], I don't plan for them to be changed, thus our DT will stay stable in this regard. NB: Yes, we are quite fortunate by the fact that most of are bindings can be considered fairly transient, but that is irrelevant in this particular case. [1] https://lkml.org/lkml/2015/2/27/548 [2] https://lkml.org/lkml/2015/2/27/551 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
Hi Lee,
On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones wrote:
> On Wed, 25 Mar 2015, Geert Uytterhoeven wrote:
>> On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote:
>> > On Fri, 06 Mar 2015, Mike Turquette wrote:
>> >> This approach looks fine to me. In practice I think it is restricted to
>> >> hardware blocks that don't exist in DT yet (e.g. no driver, in the case
>> >> of your interconnect) and that restriction is probably for the best.
>> >
>> > Agreed.
>>
>> I think this restriction should be documented in the DT binding more clearly,
>> as adding a "clk-always-on" node prohibits you from handling the clock
>> correctly in
>> the future.
>
> Would you mind taking the time to explain what you think those
> limitations are?
If you add a "clk-always-on" node, the clock will always on using that DT.
That will still be true later, when you get a better understanding of the
hardware, and might discover you're gonna need a driver for the currently
hidden core component that's driven by the clock, and may want to manage
that clock.
When that happens, you're gonna need a DT update to make use of the
newly introduced driver and the features it provides (e.g. better power
management).
On the other hand, if you would describe the actual hardware topology in DT,
the device node for the future driver would already be there, and no DT update
is needed (assuming you can guess right w.r.t. its bindings; usually these are
transparent buses, for which bindings are fairly generic, cfr. e.g.
"simple-pm-bus").
Until you have (a need for) a real driver, you do need some platform code that
makes sure the clock is enabled. When a real driver is introduced, the
platform code has to be updated, but DT doesn't have to change.
(The same is true for devices where the current driver isn't aware of the
clock, and shouldn't be, but you still need to enable the clock until the
driver has Runtime PM support (E.g. ARM GIC on shmobile, cfr.
https://www.marc.info/?l=linux-pm=142670617929493=3 (good, now
we have a bidirectional link between these two threads :-) Using a
"clk-always-on" property there instead of adding a reference to the clock
in the existing GIC device node would be just lying.)
If we start seeing many users, perhaps we need a general framework where
the platform code can register a list of clocks that must be enabled (properly,
i.e. using clk_prepare_enable())? But I don't think the list should be put
in DT: DT describes hardware, not behavior.
If you don't care about DT stability, and can afford always updating your DT
with your kernel, the above doesn't apply. I heard during the ELC hallways
chats this is actually the case for you?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v3 0/4] clk: st: New always-on clock domain
On Wed, 25 Mar 2015, Geert Uytterhoeven wrote:
> Hi Lee,
>
> On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote:
> > On Fri, 06 Mar 2015, Mike Turquette wrote:
> >> Quoting Lee Jones (2015-03-04 04:00:03)
> >> > Mike,
> >> >
> >> > Do you want me to resend this set with Robert's Reviewed-by applied,
> >> > or are you happy to apply it yourself?
> >>
> >> No need for the resend. I am hoping for a final review from a DT human.
> >>
> >> This approach looks fine to me. In practice I think it is restricted to
> >> hardware blocks that don't exist in DT yet (e.g. no driver, in the case
> >> of your interconnect) and that restriction is probably for the best.
> >
> > Agreed.
>
> I think this restriction should be documented in the DT binding more clearly,
> as adding a "clk-always-on" node prohibits you from handling the clock
> correctly in
> the future.
Would you mind taking the time to explain what you think those
limitations are?
> Still, for simple devices where you don't have a driver, but have
> "predictable"
> bindings (e.g. a bus like "simple-pm-bus"), I think it's better to add
> a device node
> for that simple device now, incl. a reference to the clock, and have a simple
> driver that binds to the device, or platform code that looks for a
> compatible node,
> and enables the clock. That way you don't have to make any chances to the DTS
> later, when you'll have a real driver.
>
> >> > > v2 => v3:
> >> > > - Ensure DT actually reflects h/w
> >> > > - i.e. Nodes should not contain a mishmash of different IP
> >> > > blocks, but should identify related h/w. In the current
> >> > > example we use interconnects
> >> > > - Change naming from clkdomain to clk-always-on
> >> > > - Place "do not abuse" warning in documentation
> >> > >
> >> > > v1 => v2:
> >> > > - Turned the ST specific driver into a generic one
> >> > >
> >> > > Hardware can have a bunch of clocks which must not be turned off.
> >> > > If drivers a) fail to obtain a reference to any of these or b) give
> >> > > up a previously obtained reference during suspend, the common clk
> >> > > framework will attempt to turn them off and the hardware will
> >> > > subsequently die. The only way to recover from this failure is to
> >> > > restart.
> >> > >
> >> > > To avoid either of these two scenarios from catastrophically
> >> > > disabling the running system we have implemented a clock domain
> >> > > where clocks are consumed and references are taken, thus preventing
> >> > > them from being shut down by the framework.
>
> Gr{oetje,eeting}s,
>
> Geert
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v3 0/4] clk: st: New always-on clock domain
Hi Lee,
On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones lee.jo...@linaro.org wrote:
On Wed, 25 Mar 2015, Geert Uytterhoeven wrote:
On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones lee.jo...@linaro.org wrote:
On Fri, 06 Mar 2015, Mike Turquette wrote:
This approach looks fine to me. In practice I think it is restricted to
hardware blocks that don't exist in DT yet (e.g. no driver, in the case
of your interconnect) and that restriction is probably for the best.
Agreed.
I think this restriction should be documented in the DT binding more clearly,
as adding a clk-always-on node prohibits you from handling the clock
correctly in
the future.
Would you mind taking the time to explain what you think those
limitations are?
If you add a clk-always-on node, the clock will always on using that DT.
That will still be true later, when you get a better understanding of the
hardware, and might discover you're gonna need a driver for the currently
hidden core component that's driven by the clock, and may want to manage
that clock.
When that happens, you're gonna need a DT update to make use of the
newly introduced driver and the features it provides (e.g. better power
management).
On the other hand, if you would describe the actual hardware topology in DT,
the device node for the future driver would already be there, and no DT update
is needed (assuming you can guess right w.r.t. its bindings; usually these are
transparent buses, for which bindings are fairly generic, cfr. e.g.
simple-pm-bus).
Until you have (a need for) a real driver, you do need some platform code that
makes sure the clock is enabled. When a real driver is introduced, the
platform code has to be updated, but DT doesn't have to change.
(The same is true for devices where the current driver isn't aware of the
clock, and shouldn't be, but you still need to enable the clock until the
driver has Runtime PM support (E.g. ARM GIC on shmobile, cfr.
https://www.marc.info/?l=linux-pmm=142670617929493w=3 (good, now
we have a bidirectional link between these two threads :-) Using a
clk-always-on property there instead of adding a reference to the clock
in the existing GIC device node would be just lying.)
If we start seeing many users, perhaps we need a general framework where
the platform code can register a list of clocks that must be enabled (properly,
i.e. using clk_prepare_enable())? But I don't think the list should be put
in DT: DT describes hardware, not behavior.
If you don't care about DT stability, and can afford always updating your DT
with your kernel, the above doesn't apply. I heard during the ELC hallways
chats this is actually the case for you?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 v3 0/4] clk: st: New always-on clock domain
On Thu, 26 Mar 2015, Geert Uytterhoeven wrote: Hi Lee, On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones lee.jo...@linaro.org wrote: On Wed, 25 Mar 2015, Geert Uytterhoeven wrote: On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones lee.jo...@linaro.org wrote: On Fri, 06 Mar 2015, Mike Turquette wrote: This approach looks fine to me. In practice I think it is restricted to hardware blocks that don't exist in DT yet (e.g. no driver, in the case of your interconnect) and that restriction is probably for the best. Agreed. I think this restriction should be documented in the DT binding more clearly, as adding a clk-always-on node prohibits you from handling the clock correctly in the future. Would you mind taking the time to explain what you think those limitations are? If you add a clk-always-on node, the clock will always on using that DT. That will still be true later, when you get a better understanding of the hardware, and might discover you're gonna need a driver for the currently hidden core component that's driven by the clock, and may want to manage that clock. So I have two points here. First point; I think you're looking at an older version of my set. The newer one can be found at [1] and no longer uses 'always-on' nodes. Instead the 'clk-always-on' property is applied to the provider. See the documentation patch [2] for more details. Second point; this binding is _not_ to be used as a hack because the hardware isn't understood. Genuine uses are for clocks that must not be turned off ever, else bad things will happen. If the hardware is not understood, use 'clk-disable-unused' on the kernel cmdline instead. When that happens, you're gonna need a DT update to make use of the newly introduced driver and the features it provides (e.g. better power management). The whole point of this set is to manage clocks that can't be power managed. Using the 'clk-always-on' property labels the clock with a big-red-sign saying DO NOT TURN ME OFF, OR RISK CATASTROPHIC FAILURE, not a TODO: Fix-me when you understand me. On the other hand, if you would describe the actual hardware topology in DT, the device node for the future driver would already be there, and no DT update is needed (assuming you can guess right w.r.t. its bindings; usually these are transparent buses, for which bindings are fairly generic, cfr. e.g. simple-pm-bus). In our case the devices these clocks control will never be added to Device Tree. Linux can't see them, they have no registers and they can't be controlled. Added a device driver for all such devices would be foolhardy. Until you have (a need for) a real driver, you do need some platform code that makes sure the clock is enabled. When a real driver is introduced, the platform code has to be updated, but DT doesn't have to change. No, this binding is _not_ for that use-case. If your platform is incomplete you must use 'clk-disable-unused'. (The same is true for devices where the current driver isn't aware of the clock, and shouldn't be, but you still need to enable the clock until the driver has Runtime PM support (E.g. ARM GIC on shmobile, cfr. https://www.marc.info/?l=linux-pmm=142670617929493w=3 (good, now we have a bidirectional link between these two threads :-) Using a clk-always-on property there instead of adding a reference to the clock in the existing GIC device node would be just lying.) If this clock should _genuinely_ be always-on, then use my new binding in the clock controller node and the Clk framework will not turn it off. If we start seeing many users, perhaps we need a general framework where the platform code can register a list of clocks that must be enabled (properly, i.e. using clk_prepare_enable())? But I don't think the list should be put in DT: DT describes hardware, not behavior. I did this in the very first iteration of this set. The DT guys didn't like it, which is why I re-wrote it to look like [1]. If you don't care about DT stability, and can afford always updating your DT with your kernel, the above doesn't apply. I heard during the ELC hallways chats this is actually the case for you? My ears burning eh? Do tell... I think you currently misunderstand the use-case for this set. I hope my points above will clarify the point somewhat. Once we write the bindings and the DT nodes in [1], I don't plan for them to be changed, thus our DT will stay stable in this regard. NB: Yes, we are quite fortunate by the fact that most of are bindings can be considered fairly transient, but that is irrelevant in this particular case. [1] https://lkml.org/lkml/2015/2/27/548 [2] https://lkml.org/lkml/2015/2/27/551 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
On Wed, 25 Mar 2015, Geert Uytterhoeven wrote:
Hi Lee,
On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones lee.jo...@linaro.org wrote:
On Fri, 06 Mar 2015, Mike Turquette wrote:
Quoting Lee Jones (2015-03-04 04:00:03)
Mike,
Do you want me to resend this set with Robert's Reviewed-by applied,
or are you happy to apply it yourself?
No need for the resend. I am hoping for a final review from a DT human.
This approach looks fine to me. In practice I think it is restricted to
hardware blocks that don't exist in DT yet (e.g. no driver, in the case
of your interconnect) and that restriction is probably for the best.
Agreed.
I think this restriction should be documented in the DT binding more clearly,
as adding a clk-always-on node prohibits you from handling the clock
correctly in
the future.
Would you mind taking the time to explain what you think those
limitations are?
Still, for simple devices where you don't have a driver, but have
predictable
bindings (e.g. a bus like simple-pm-bus), I think it's better to add
a device node
for that simple device now, incl. a reference to the clock, and have a simple
driver that binds to the device, or platform code that looks for a
compatible node,
and enables the clock. That way you don't have to make any chances to the DTS
later, when you'll have a real driver.
v2 = v3:
- Ensure DT actually reflects h/w
- i.e. Nodes should not contain a mishmash of different IP
blocks, but should identify related h/w. In the current
example we use interconnects
- Change naming from clkdomain to clk-always-on
- Place do not abuse warning in documentation
v1 = v2:
- Turned the ST specific driver into a generic one
Hardware can have a bunch of clocks which must not be turned off.
If drivers a) fail to obtain a reference to any of these or b) give
up a previously obtained reference during suspend, the common clk
framework will attempt to turn them off and the hardware will
subsequently die. The only way to recover from this failure is to
restart.
To avoid either of these two scenarios from catastrophically
disabling the running system we have implemented a clock domain
where clocks are consumed and references are taken, thus preventing
them from being shut down by the framework.
Gr{oetje,eeting}s,
Geert
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v3 0/4] clk: st: New always-on clock domain
Hi Lee,
On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote:
> On Fri, 06 Mar 2015, Mike Turquette wrote:
>> Quoting Lee Jones (2015-03-04 04:00:03)
>> > Mike,
>> >
>> > Do you want me to resend this set with Robert's Reviewed-by applied,
>> > or are you happy to apply it yourself?
>>
>> No need for the resend. I am hoping for a final review from a DT human.
>>
>> This approach looks fine to me. In practice I think it is restricted to
>> hardware blocks that don't exist in DT yet (e.g. no driver, in the case
>> of your interconnect) and that restriction is probably for the best.
>
> Agreed.
I think this restriction should be documented in the DT binding more clearly,
as adding a "clk-always-on" node prohibits you from handling the clock
correctly in
the future.
Still, for simple devices where you don't have a driver, but have "predictable"
bindings (e.g. a bus like "simple-pm-bus"), I think it's better to add
a device node
for that simple device now, incl. a reference to the clock, and have a simple
driver that binds to the device, or platform code that looks for a
compatible node,
and enables the clock. That way you don't have to make any chances to the DTS
later, when you'll have a real driver.
>> > > v2 => v3:
>> > > - Ensure DT actually reflects h/w
>> > > - i.e. Nodes should not contain a mishmash of different IP
>> > > blocks, but should identify related h/w. In the current
>> > > example we use interconnects
>> > > - Change naming from clkdomain to clk-always-on
>> > > - Place "do not abuse" warning in documentation
>> > >
>> > > v1 => v2:
>> > > - Turned the ST specific driver into a generic one
>> > >
>> > > Hardware can have a bunch of clocks which must not be turned off.
>> > > If drivers a) fail to obtain a reference to any of these or b) give
>> > > up a previously obtained reference during suspend, the common clk
>> > > framework will attempt to turn them off and the hardware will
>> > > subsequently die. The only way to recover from this failure is to
>> > > restart.
>> > >
>> > > To avoid either of these two scenarios from catastrophically
>> > > disabling the running system we have implemented a clock domain
>> > > where clocks are consumed and references are taken, thus preventing
>> > > them from being shut down by the framework.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 v3 0/4] clk: st: New always-on clock domain
Hi Lee,
On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones lee.jo...@linaro.org wrote:
On Fri, 06 Mar 2015, Mike Turquette wrote:
Quoting Lee Jones (2015-03-04 04:00:03)
Mike,
Do you want me to resend this set with Robert's Reviewed-by applied,
or are you happy to apply it yourself?
No need for the resend. I am hoping for a final review from a DT human.
This approach looks fine to me. In practice I think it is restricted to
hardware blocks that don't exist in DT yet (e.g. no driver, in the case
of your interconnect) and that restriction is probably for the best.
Agreed.
I think this restriction should be documented in the DT binding more clearly,
as adding a clk-always-on node prohibits you from handling the clock
correctly in
the future.
Still, for simple devices where you don't have a driver, but have predictable
bindings (e.g. a bus like simple-pm-bus), I think it's better to add
a device node
for that simple device now, incl. a reference to the clock, and have a simple
driver that binds to the device, or platform code that looks for a
compatible node,
and enables the clock. That way you don't have to make any chances to the DTS
later, when you'll have a real driver.
v2 = v3:
- Ensure DT actually reflects h/w
- i.e. Nodes should not contain a mishmash of different IP
blocks, but should identify related h/w. In the current
example we use interconnects
- Change naming from clkdomain to clk-always-on
- Place do not abuse warning in documentation
v1 = v2:
- Turned the ST specific driver into a generic one
Hardware can have a bunch of clocks which must not be turned off.
If drivers a) fail to obtain a reference to any of these or b) give
up a previously obtained reference during suspend, the common clk
framework will attempt to turn them off and the hardware will
subsequently die. The only way to recover from this failure is to
restart.
To avoid either of these two scenarios from catastrophically
disabling the running system we have implemented a clock domain
where clocks are consumed and references are taken, thus preventing
them from being shut down by the framework.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 v3 0/4] clk: st: New always-on clock domain
On Fri, 06 Mar 2015, Mike Turquette wrote: > Quoting Lee Jones (2015-03-04 04:00:03) > > Mike, > > > > Do you want me to resend this set with Robert's Reviewed-by applied, > > or are you happy to apply it yourself? > > No need for the resend. I am hoping for a final review from a DT human. > > This approach looks fine to me. In practice I think it is restricted to > hardware blocks that don't exist in DT yet (e.g. no driver, in the case > of your interconnect) and that restriction is probably for the best. Agreed. > > > v2 => v3: > > > - Ensure DT actually reflects h/w > > > - i.e. Nodes should not contain a mishmash of different IP > > > blocks, but should identify related h/w. In the current > > > example we use interconnects > > > - Change naming from clkdomain to clk-always-on > > > - Place "do not abuse" warning in documentation > > > > > > v1 => v2: > > > - Turned the ST specific driver into a generic one > > > > > > Hardware can have a bunch of clocks which must not be turned off. > > > If drivers a) fail to obtain a reference to any of these or b) give > > > up a previously obtained reference during suspend, the common clk > > > framework will attempt to turn them off and the hardware will > > > subsequently die. The only way to recover from this failure is to > > > restart. > > > > > > To avoid either of these two scenarios from catastrophically > > > disabling the running system we have implemented a clock domain > > > where clocks are consumed and references are taken, thus preventing > > > them from being shut down by the framework. > > > > > > *** BLURB HERE *** > > > > > > Lee Jones (4): > > > ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 > > > ARM: sti: stih407-family: Add platform interconnects to always-on clk > > > domain > > > clk: Provide an always-on clock domain framework > > > clk: dt: Introduce always-on clock domain documentation > > > > > > .../devicetree/bindings/clock/clk-always-on.txt| 35 > > > arch/arm/boot/dts/stih407-family.dtsi | 15 ++ > > > drivers/clk/Makefile | 1 + > > > drivers/clk/clk-always-on.c| 62 > > > ++ > > > include/dt-bindings/clock/stih407-clks.h | 4 ++ > > > 5 files changed, 117 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/clock/clk-always-on.txt > > > create mode 100644 drivers/clk/clk-always-on.c > > > > > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
On Fri, 06 Mar 2015, Mike Turquette wrote: Quoting Lee Jones (2015-03-04 04:00:03) Mike, Do you want me to resend this set with Robert's Reviewed-by applied, or are you happy to apply it yourself? No need for the resend. I am hoping for a final review from a DT human. This approach looks fine to me. In practice I think it is restricted to hardware blocks that don't exist in DT yet (e.g. no driver, in the case of your interconnect) and that restriction is probably for the best. Agreed. v2 = v3: - Ensure DT actually reflects h/w - i.e. Nodes should not contain a mishmash of different IP blocks, but should identify related h/w. In the current example we use interconnects - Change naming from clkdomain to clk-always-on - Place do not abuse warning in documentation v1 = v2: - Turned the ST specific driver into a generic one Hardware can have a bunch of clocks which must not be turned off. If drivers a) fail to obtain a reference to any of these or b) give up a previously obtained reference during suspend, the common clk framework will attempt to turn them off and the hardware will subsequently die. The only way to recover from this failure is to restart. To avoid either of these two scenarios from catastrophically disabling the running system we have implemented a clock domain where clocks are consumed and references are taken, thus preventing them from being shut down by the framework. *** BLURB HERE *** Lee Jones (4): ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 ARM: sti: stih407-family: Add platform interconnects to always-on clk domain clk: Provide an always-on clock domain framework clk: dt: Introduce always-on clock domain documentation .../devicetree/bindings/clock/clk-always-on.txt| 35 arch/arm/boot/dts/stih407-family.dtsi | 15 ++ drivers/clk/Makefile | 1 + drivers/clk/clk-always-on.c| 62 ++ include/dt-bindings/clock/stih407-clks.h | 4 ++ 5 files changed, 117 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt create mode 100644 drivers/clk/clk-always-on.c -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Quoting Lee Jones (2015-03-04 04:00:03) > Mike, > > Do you want me to resend this set with Robert's Reviewed-by applied, > or are you happy to apply it yourself? No need for the resend. I am hoping for a final review from a DT human. This approach looks fine to me. In practice I think it is restricted to hardware blocks that don't exist in DT yet (e.g. no driver, in the case of your interconnect) and that restriction is probably for the best. Regards, Mike > > > v2 => v3: > > - Ensure DT actually reflects h/w > > - i.e. Nodes should not contain a mishmash of different IP > > blocks, but should identify related h/w. In the current > > example we use interconnects > > - Change naming from clkdomain to clk-always-on > > - Place "do not abuse" warning in documentation > > > > v1 => v2: > > - Turned the ST specific driver into a generic one > > > > Hardware can have a bunch of clocks which must not be turned off. > > If drivers a) fail to obtain a reference to any of these or b) give > > up a previously obtained reference during suspend, the common clk > > framework will attempt to turn them off and the hardware will > > subsequently die. The only way to recover from this failure is to > > restart. > > > > To avoid either of these two scenarios from catastrophically > > disabling the running system we have implemented a clock domain > > where clocks are consumed and references are taken, thus preventing > > them from being shut down by the framework. > > > > *** BLURB HERE *** > > > > Lee Jones (4): > > ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 > > ARM: sti: stih407-family: Add platform interconnects to always-on clk > > domain > > clk: Provide an always-on clock domain framework > > clk: dt: Introduce always-on clock domain documentation > > > > .../devicetree/bindings/clock/clk-always-on.txt| 35 > > arch/arm/boot/dts/stih407-family.dtsi | 15 ++ > > drivers/clk/Makefile | 1 + > > drivers/clk/clk-always-on.c| 62 > > ++ > > include/dt-bindings/clock/stih407-clks.h | 4 ++ > > 5 files changed, 117 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/clock/clk-always-on.txt > > create mode 100644 drivers/clk/clk-always-on.c > > > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Quoting Lee Jones (2015-03-04 04:00:03) Mike, Do you want me to resend this set with Robert's Reviewed-by applied, or are you happy to apply it yourself? No need for the resend. I am hoping for a final review from a DT human. This approach looks fine to me. In practice I think it is restricted to hardware blocks that don't exist in DT yet (e.g. no driver, in the case of your interconnect) and that restriction is probably for the best. Regards, Mike v2 = v3: - Ensure DT actually reflects h/w - i.e. Nodes should not contain a mishmash of different IP blocks, but should identify related h/w. In the current example we use interconnects - Change naming from clkdomain to clk-always-on - Place do not abuse warning in documentation v1 = v2: - Turned the ST specific driver into a generic one Hardware can have a bunch of clocks which must not be turned off. If drivers a) fail to obtain a reference to any of these or b) give up a previously obtained reference during suspend, the common clk framework will attempt to turn them off and the hardware will subsequently die. The only way to recover from this failure is to restart. To avoid either of these two scenarios from catastrophically disabling the running system we have implemented a clock domain where clocks are consumed and references are taken, thus preventing them from being shut down by the framework. *** BLURB HERE *** Lee Jones (4): ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 ARM: sti: stih407-family: Add platform interconnects to always-on clk domain clk: Provide an always-on clock domain framework clk: dt: Introduce always-on clock domain documentation .../devicetree/bindings/clock/clk-always-on.txt| 35 arch/arm/boot/dts/stih407-family.dtsi | 15 ++ drivers/clk/Makefile | 1 + drivers/clk/clk-always-on.c| 62 ++ include/dt-bindings/clock/stih407-clks.h | 4 ++ 5 files changed, 117 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt create mode 100644 drivers/clk/clk-always-on.c -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Mike, Do you want me to resend this set with Robert's Reviewed-by applied, or are you happy to apply it yourself? > v2 => v3: > - Ensure DT actually reflects h/w > - i.e. Nodes should not contain a mishmash of different IP > blocks, but should identify related h/w. In the current > example we use interconnects > - Change naming from clkdomain to clk-always-on > - Place "do not abuse" warning in documentation > > v1 => v2: > - Turned the ST specific driver into a generic one > > Hardware can have a bunch of clocks which must not be turned off. > If drivers a) fail to obtain a reference to any of these or b) give > up a previously obtained reference during suspend, the common clk > framework will attempt to turn them off and the hardware will > subsequently die. The only way to recover from this failure is to > restart. > > To avoid either of these two scenarios from catastrophically > disabling the running system we have implemented a clock domain > where clocks are consumed and references are taken, thus preventing > them from being shut down by the framework. > > *** BLURB HERE *** > > Lee Jones (4): > ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 > ARM: sti: stih407-family: Add platform interconnects to always-on clk > domain > clk: Provide an always-on clock domain framework > clk: dt: Introduce always-on clock domain documentation > > .../devicetree/bindings/clock/clk-always-on.txt| 35 > arch/arm/boot/dts/stih407-family.dtsi | 15 ++ > drivers/clk/Makefile | 1 + > drivers/clk/clk-always-on.c| 62 > ++ > include/dt-bindings/clock/stih407-clks.h | 4 ++ > 5 files changed, 117 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt > create mode 100644 drivers/clk/clk-always-on.c > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Mike, Do you want me to resend this set with Robert's Reviewed-by applied, or are you happy to apply it yourself? v2 = v3: - Ensure DT actually reflects h/w - i.e. Nodes should not contain a mishmash of different IP blocks, but should identify related h/w. In the current example we use interconnects - Change naming from clkdomain to clk-always-on - Place do not abuse warning in documentation v1 = v2: - Turned the ST specific driver into a generic one Hardware can have a bunch of clocks which must not be turned off. If drivers a) fail to obtain a reference to any of these or b) give up a previously obtained reference during suspend, the common clk framework will attempt to turn them off and the hardware will subsequently die. The only way to recover from this failure is to restart. To avoid either of these two scenarios from catastrophically disabling the running system we have implemented a clock domain where clocks are consumed and references are taken, thus preventing them from being shut down by the framework. *** BLURB HERE *** Lee Jones (4): ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 ARM: sti: stih407-family: Add platform interconnects to always-on clk domain clk: Provide an always-on clock domain framework clk: dt: Introduce always-on clock domain documentation .../devicetree/bindings/clock/clk-always-on.txt| 35 arch/arm/boot/dts/stih407-family.dtsi | 15 ++ drivers/clk/Makefile | 1 + drivers/clk/clk-always-on.c| 62 ++ include/dt-bindings/clock/stih407-clks.h | 4 ++ 5 files changed, 117 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt create mode 100644 drivers/clk/clk-always-on.c -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
On Mon, 02 Mar 2015, Robert Jarzmik wrote: > Lee Jones writes: > > > On Sat, 28 Feb 2015, Robert Jarzmik wrote: > > > >> Lee Jones writes: > >> it doesn't specify which usecase is not covered by CLK_IGNORE_UNUSED, > >> it > >> says, up to my understanding, that is it another way to have to > >> CLK_IGNORE_UNUSED flag applied. > > > > Well that is exactly what we're doing. Is there an issue with that? > > > > This is a way to do it at a platform level. It means we can support > > multiple platforms where clocksources have been switched around > > without writing new driver code in drivers/clk/st. > > > > If you have something else in mind, let me know. > > > >> 2) I still fail to see why this is necessary > >> IOW why declaring the mandatory always-on clocks with the proper flag > >> should > >> be augmented with a new clock list. Isn't the existing flag the > >> generic way > >> ? > > > > I'm not sure what you mean by this, would you be able to expland a > > little? > > > >> I might not understand the real motivation behind that of course, that's > >> why I'm > >> asking. > > > > Please bear in mind that we don't supply our clocks statically. All > > of the information is extracted from DT, so if the always-on > > information does reside in there, where do you propose it comes from? > > I thought the standard clock binding provided a way to set this flag. Now I > crosschecked the binding, it doesn't ... > > My point was I didn't want the flag to be settable from 2 different places, > where consistency was to be kept across different device-tree leafs. > > > We could just write this code inside our own driver and apply the > > CLK_IGNORE_UNUSED at a local level, but that's not the generic > > solution I am searching for. > > All right, I'm convinced now I undertand the flag was not settable from > devicetree binding before this patchset. > > You can add to patch 3/4 : > Reviewed-by: Robert Jarzmik Until told otherwise, I'm going to apply this onto the other patchset. This one has already been NACKed, due to DT push-back. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Lee Jones writes: > On Sat, 28 Feb 2015, Robert Jarzmik wrote: > >> Lee Jones writes: >> it doesn't specify which usecase is not covered by CLK_IGNORE_UNUSED, it >> says, up to my understanding, that is it another way to have to >> CLK_IGNORE_UNUSED flag applied. > > Well that is exactly what we're doing. Is there an issue with that? > > This is a way to do it at a platform level. It means we can support > multiple platforms where clocksources have been switched around > without writing new driver code in drivers/clk/st. > > If you have something else in mind, let me know. > >> 2) I still fail to see why this is necessary >> IOW why declaring the mandatory always-on clocks with the proper flag >> should >> be augmented with a new clock list. Isn't the existing flag the generic >> way >> ? > > I'm not sure what you mean by this, would you be able to expland a > little? > >> I might not understand the real motivation behind that of course, that's why >> I'm >> asking. > > Please bear in mind that we don't supply our clocks statically. All > of the information is extracted from DT, so if the always-on > information does reside in there, where do you propose it comes from? I thought the standard clock binding provided a way to set this flag. Now I crosschecked the binding, it doesn't ... My point was I didn't want the flag to be settable from 2 different places, where consistency was to be kept across different device-tree leafs. > We could just write this code inside our own driver and apply the > CLK_IGNORE_UNUSED at a local level, but that's not the generic > solution I am searching for. All right, I'm convinced now I undertand the flag was not settable from devicetree binding before this patchset. You can add to patch 3/4 : Reviewed-by: Robert Jarzmik -- Robert -- 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 v3 0/4] clk: st: New always-on clock domain
On Sat, 28 Feb 2015, Robert Jarzmik wrote: > Lee Jones writes: > > >> I wonder why there is a need for a new clock when CLK_IGNORE_UNUSED does > >> exist. What is the usecase that is covered by this patchset which is not > >> used by > >> CLK_IGNORE_UNUSED clock flag ? > >> > >> And if that reason exists, I'd like to find it in the commit message. > > > > The problem is applying that flag in a generic way. > > > > However, I guess you haven't seen this [1] yet? > > > > [1] https://lkml.org/lkml/2015/2/27/548 > I have. > > And yet : > 1) This won't go in a _commit_ message (as opposed to cover-letter). Moreover Did you read rest of the set, or just the cover-letter? I referenced 0/0 because it is the thread parent and from there you can drill down into the commits where I believe there is adequate explanation in each. If you could be more specific and tell me which commit you think requires more explanation, I'd be happy to take a look. > it doesn't specify which usecase is not covered by CLK_IGNORE_UNUSED, it > says, up to my understanding, that is it another way to have to > CLK_IGNORE_UNUSED flag applied. Well that is exactly what we're doing. Is there an issue with that? This is a way to do it at a platform level. It means we can support multiple platforms where clocksources have been switched around without writing new driver code in drivers/clk/st. If you have something else in mind, let me know. > 2) I still fail to see why this is necessary > IOW why declaring the mandatory always-on clocks with the proper flag > should > be augmented with a new clock list. Isn't the existing flag the generic > way > ? I'm not sure what you mean by this, would you be able to expland a little? > I might not understand the real motivation behind that of course, that's why > I'm > asking. Please bear in mind that we don't supply our clocks statically. All of the information is extracted from DT, so if the always-on information does reside in there, where do you propose it comes from? We could just write this code inside our own driver and apply the CLK_IGNORE_UNUSED at a local level, but that's not the generic solution I am searching for. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
On Sat, 28 Feb 2015, Robert Jarzmik wrote: Lee Jones lee.jo...@linaro.org writes: I wonder why there is a need for a new clock when CLK_IGNORE_UNUSED does exist. What is the usecase that is covered by this patchset which is not used by CLK_IGNORE_UNUSED clock flag ? And if that reason exists, I'd like to find it in the commit message. The problem is applying that flag in a generic way. However, I guess you haven't seen this [1] yet? [1] https://lkml.org/lkml/2015/2/27/548 I have. And yet : 1) This won't go in a _commit_ message (as opposed to cover-letter). Moreover Did you read rest of the set, or just the cover-letter? I referenced 0/0 because it is the thread parent and from there you can drill down into the commits where I believe there is adequate explanation in each. If you could be more specific and tell me which commit you think requires more explanation, I'd be happy to take a look. it doesn't specify which usecase is not covered by CLK_IGNORE_UNUSED, it says, up to my understanding, that is it another way to have to CLK_IGNORE_UNUSED flag applied. Well that is exactly what we're doing. Is there an issue with that? This is a way to do it at a platform level. It means we can support multiple platforms where clocksources have been switched around without writing new driver code in drivers/clk/st. If you have something else in mind, let me know. 2) I still fail to see why this is necessary IOW why declaring the mandatory always-on clocks with the proper flag should be augmented with a new clock list. Isn't the existing flag the generic way ? I'm not sure what you mean by this, would you be able to expland a little? I might not understand the real motivation behind that of course, that's why I'm asking. Please bear in mind that we don't supply our clocks statically. All of the information is extracted from DT, so if the always-on information does reside in there, where do you propose it comes from? We could just write this code inside our own driver and apply the CLK_IGNORE_UNUSED at a local level, but that's not the generic solution I am searching for. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Lee Jones lee.jo...@linaro.org writes: On Sat, 28 Feb 2015, Robert Jarzmik wrote: Lee Jones lee.jo...@linaro.org writes: it doesn't specify which usecase is not covered by CLK_IGNORE_UNUSED, it says, up to my understanding, that is it another way to have to CLK_IGNORE_UNUSED flag applied. Well that is exactly what we're doing. Is there an issue with that? This is a way to do it at a platform level. It means we can support multiple platforms where clocksources have been switched around without writing new driver code in drivers/clk/st. If you have something else in mind, let me know. 2) I still fail to see why this is necessary IOW why declaring the mandatory always-on clocks with the proper flag should be augmented with a new clock list. Isn't the existing flag the generic way ? I'm not sure what you mean by this, would you be able to expland a little? I might not understand the real motivation behind that of course, that's why I'm asking. Please bear in mind that we don't supply our clocks statically. All of the information is extracted from DT, so if the always-on information does reside in there, where do you propose it comes from? I thought the standard clock binding provided a way to set this flag. Now I crosschecked the binding, it doesn't ... My point was I didn't want the flag to be settable from 2 different places, where consistency was to be kept across different device-tree leafs. We could just write this code inside our own driver and apply the CLK_IGNORE_UNUSED at a local level, but that's not the generic solution I am searching for. All right, I'm convinced now I undertand the flag was not settable from devicetree binding before this patchset. You can add to patch 3/4 : Reviewed-by: Robert Jarzmik robert.jarz...@free.fr -- Robert -- 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 v3 0/4] clk: st: New always-on clock domain
On Mon, 02 Mar 2015, Robert Jarzmik wrote: Lee Jones lee.jo...@linaro.org writes: On Sat, 28 Feb 2015, Robert Jarzmik wrote: Lee Jones lee.jo...@linaro.org writes: it doesn't specify which usecase is not covered by CLK_IGNORE_UNUSED, it says, up to my understanding, that is it another way to have to CLK_IGNORE_UNUSED flag applied. Well that is exactly what we're doing. Is there an issue with that? This is a way to do it at a platform level. It means we can support multiple platforms where clocksources have been switched around without writing new driver code in drivers/clk/st. If you have something else in mind, let me know. 2) I still fail to see why this is necessary IOW why declaring the mandatory always-on clocks with the proper flag should be augmented with a new clock list. Isn't the existing flag the generic way ? I'm not sure what you mean by this, would you be able to expland a little? I might not understand the real motivation behind that of course, that's why I'm asking. Please bear in mind that we don't supply our clocks statically. All of the information is extracted from DT, so if the always-on information does reside in there, where do you propose it comes from? I thought the standard clock binding provided a way to set this flag. Now I crosschecked the binding, it doesn't ... My point was I didn't want the flag to be settable from 2 different places, where consistency was to be kept across different device-tree leafs. We could just write this code inside our own driver and apply the CLK_IGNORE_UNUSED at a local level, but that's not the generic solution I am searching for. All right, I'm convinced now I undertand the flag was not settable from devicetree binding before this patchset. You can add to patch 3/4 : Reviewed-by: Robert Jarzmik robert.jarz...@free.fr Until told otherwise, I'm going to apply this onto the other patchset. This one has already been NACKed, due to DT push-back. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Lee Jones writes: >> I wonder why there is a need for a new clock when CLK_IGNORE_UNUSED does >> exist. What is the usecase that is covered by this patchset which is not >> used by >> CLK_IGNORE_UNUSED clock flag ? >> >> And if that reason exists, I'd like to find it in the commit message. > > The problem is applying that flag in a generic way. > > However, I guess you haven't seen this [1] yet? > > [1] https://lkml.org/lkml/2015/2/27/548 I have. And yet : 1) This won't go in a _commit_ message (as opposed to cover-letter). Moreover it doesn't specify which usecase is not covered by CLK_IGNORE_UNUSED, it says, up to my understanding, that is it another way to have to CLK_IGNORE_UNUSED flag applied. 2) I still fail to see why this is necessary IOW why declaring the mandatory always-on clocks with the proper flag should be augmented with a new clock list. Isn't the existing flag the generic way ? I might not understand the real motivation behind that of course, that's why I'm asking. Cheers. -- Robert -- 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 v3 0/4] clk: st: New always-on clock domain
On Fri, 27 Feb 2015, Robert Jarzmik wrote: > Lee Jones writes: > > > v2 => v3: > > - Ensure DT actually reflects h/w > > - i.e. Nodes should not contain a mishmash of different IP > > blocks, but should identify related h/w. In the current > > example we use interconnects > > - Change naming from clkdomain to clk-always-on > > - Place "do not abuse" warning in documentation > > > > v1 => v2: > > - Turned the ST specific driver into a generic one > > > > Hardware can have a bunch of clocks which must not be turned off. > > If drivers a) fail to obtain a reference to any of these or b) give > > up a previously obtained reference during suspend, the common clk > > framework will attempt to turn them off and the hardware will > > subsequently die. The only way to recover from this failure is to > > restart. > > > > To avoid either of these two scenarios from catastrophically > > disabling the running system we have implemented a clock domain > > where clocks are consumed and references are taken, thus preventing > > them from being shut down by the framework. > > Hi Lee, > > I wonder why there is a need for a new clock when CLK_IGNORE_UNUSED does > exist. What is the usecase that is covered by this patchset which is not used > by > CLK_IGNORE_UNUSED clock flag ? > > And if that reason exists, I'd like to find it in the commit message. The problem is applying that flag in a generic way. However, I guess you haven't seen this [1] yet? [1] https://lkml.org/lkml/2015/2/27/548 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Lee Jones writes: > v2 => v3: > - Ensure DT actually reflects h/w > - i.e. Nodes should not contain a mishmash of different IP > blocks, but should identify related h/w. In the current > example we use interconnects > - Change naming from clkdomain to clk-always-on > - Place "do not abuse" warning in documentation > > v1 => v2: > - Turned the ST specific driver into a generic one > > Hardware can have a bunch of clocks which must not be turned off. > If drivers a) fail to obtain a reference to any of these or b) give > up a previously obtained reference during suspend, the common clk > framework will attempt to turn them off and the hardware will > subsequently die. The only way to recover from this failure is to > restart. > > To avoid either of these two scenarios from catastrophically > disabling the running system we have implemented a clock domain > where clocks are consumed and references are taken, thus preventing > them from being shut down by the framework. Hi Lee, I wonder why there is a need for a new clock when CLK_IGNORE_UNUSED does exist. What is the usecase that is covered by this patchset which is not used by CLK_IGNORE_UNUSED clock flag ? And if that reason exists, I'd like to find it in the commit message. Cheers. -- Robert -- 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 v3 0/4] clk: st: New always-on clock domain
Lee Jones lee.jo...@linaro.org writes: v2 = v3: - Ensure DT actually reflects h/w - i.e. Nodes should not contain a mishmash of different IP blocks, but should identify related h/w. In the current example we use interconnects - Change naming from clkdomain to clk-always-on - Place do not abuse warning in documentation v1 = v2: - Turned the ST specific driver into a generic one Hardware can have a bunch of clocks which must not be turned off. If drivers a) fail to obtain a reference to any of these or b) give up a previously obtained reference during suspend, the common clk framework will attempt to turn them off and the hardware will subsequently die. The only way to recover from this failure is to restart. To avoid either of these two scenarios from catastrophically disabling the running system we have implemented a clock domain where clocks are consumed and references are taken, thus preventing them from being shut down by the framework. Hi Lee, I wonder why there is a need for a new clock when CLK_IGNORE_UNUSED does exist. What is the usecase that is covered by this patchset which is not used by CLK_IGNORE_UNUSED clock flag ? And if that reason exists, I'd like to find it in the commit message. Cheers. -- Robert -- 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 v3 0/4] clk: st: New always-on clock domain
On Fri, 27 Feb 2015, Robert Jarzmik wrote: Lee Jones lee.jo...@linaro.org writes: v2 = v3: - Ensure DT actually reflects h/w - i.e. Nodes should not contain a mishmash of different IP blocks, but should identify related h/w. In the current example we use interconnects - Change naming from clkdomain to clk-always-on - Place do not abuse warning in documentation v1 = v2: - Turned the ST specific driver into a generic one Hardware can have a bunch of clocks which must not be turned off. If drivers a) fail to obtain a reference to any of these or b) give up a previously obtained reference during suspend, the common clk framework will attempt to turn them off and the hardware will subsequently die. The only way to recover from this failure is to restart. To avoid either of these two scenarios from catastrophically disabling the running system we have implemented a clock domain where clocks are consumed and references are taken, thus preventing them from being shut down by the framework. Hi Lee, I wonder why there is a need for a new clock when CLK_IGNORE_UNUSED does exist. What is the usecase that is covered by this patchset which is not used by CLK_IGNORE_UNUSED clock flag ? And if that reason exists, I'd like to find it in the commit message. The problem is applying that flag in a generic way. However, I guess you haven't seen this [1] yet? [1] https://lkml.org/lkml/2015/2/27/548 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
Lee Jones lee.jo...@linaro.org writes: I wonder why there is a need for a new clock when CLK_IGNORE_UNUSED does exist. What is the usecase that is covered by this patchset which is not used by CLK_IGNORE_UNUSED clock flag ? And if that reason exists, I'd like to find it in the commit message. The problem is applying that flag in a generic way. However, I guess you haven't seen this [1] yet? [1] https://lkml.org/lkml/2015/2/27/548 I have. And yet : 1) This won't go in a _commit_ message (as opposed to cover-letter). Moreover it doesn't specify which usecase is not covered by CLK_IGNORE_UNUSED, it says, up to my understanding, that is it another way to have to CLK_IGNORE_UNUSED flag applied. 2) I still fail to see why this is necessary IOW why declaring the mandatory always-on clocks with the proper flag should be augmented with a new clock list. Isn't the existing flag the generic way ? I might not understand the real motivation behind that of course, that's why I'm asking. Cheers. -- Robert -- 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 v3 0/4] clk: st: New always-on clock domain
On Tue, 24 Feb 2015, Lee Jones wrote: > v2 => v3: > - Ensure DT actually reflects h/w > - i.e. Nodes should not contain a mishmash of different IP > blocks, but should identify related h/w. In the current > example we use interconnects > - Change naming from clkdomain to clk-always-on > - Place "do not abuse" warning in documentation > > v1 => v2: > - Turned the ST specific driver into a generic one > > Hardware can have a bunch of clocks which must not be turned off. > If drivers a) fail to obtain a reference to any of these or b) give > up a previously obtained reference during suspend, the common clk > framework will attempt to turn them off and the hardware will > subsequently die. The only way to recover from this failure is to > restart. > > To avoid either of these two scenarios from catastrophically > disabling the running system we have implemented a clock domain > where clocks are consumed and references are taken, thus preventing > them from being shut down by the framework. > > *** BLURB HERE *** *grumble*, that's annoying, as I removed this. I guess Git caches the patches before sending them. > Lee Jones (4): > ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 > ARM: sti: stih407-family: Add platform interconnects to always-on clk > domain > clk: Provide an always-on clock domain framework > clk: dt: Introduce always-on clock domain documentation > > .../devicetree/bindings/clock/clk-always-on.txt| 35 > arch/arm/boot/dts/stih407-family.dtsi | 15 ++ > drivers/clk/Makefile | 1 + > drivers/clk/clk-always-on.c| 62 > ++ > include/dt-bindings/clock/stih407-clks.h | 4 ++ > 5 files changed, 117 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt > create mode 100644 drivers/clk/clk-always-on.c > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v3 0/4] clk: st: New always-on clock domain
v2 => v3: - Ensure DT actually reflects h/w - i.e. Nodes should not contain a mishmash of different IP blocks, but should identify related h/w. In the current example we use interconnects - Change naming from clkdomain to clk-always-on - Place "do not abuse" warning in documentation v1 => v2: - Turned the ST specific driver into a generic one Hardware can have a bunch of clocks which must not be turned off. If drivers a) fail to obtain a reference to any of these or b) give up a previously obtained reference during suspend, the common clk framework will attempt to turn them off and the hardware will subsequently die. The only way to recover from this failure is to restart. To avoid either of these two scenarios from catastrophically disabling the running system we have implemented a clock domain where clocks are consumed and references are taken, thus preventing them from being shut down by the framework. *** BLURB HERE *** Lee Jones (4): ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 ARM: sti: stih407-family: Add platform interconnects to always-on clk domain clk: Provide an always-on clock domain framework clk: dt: Introduce always-on clock domain documentation .../devicetree/bindings/clock/clk-always-on.txt| 35 arch/arm/boot/dts/stih407-family.dtsi | 15 ++ drivers/clk/Makefile | 1 + drivers/clk/clk-always-on.c| 62 ++ include/dt-bindings/clock/stih407-clks.h | 4 ++ 5 files changed, 117 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt create mode 100644 drivers/clk/clk-always-on.c -- 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 v3 0/4] clk: st: New always-on clock domain
v2 = v3: - Ensure DT actually reflects h/w - i.e. Nodes should not contain a mishmash of different IP blocks, but should identify related h/w. In the current example we use interconnects - Change naming from clkdomain to clk-always-on - Place do not abuse warning in documentation v1 = v2: - Turned the ST specific driver into a generic one Hardware can have a bunch of clocks which must not be turned off. If drivers a) fail to obtain a reference to any of these or b) give up a previously obtained reference during suspend, the common clk framework will attempt to turn them off and the hardware will subsequently die. The only way to recover from this failure is to restart. To avoid either of these two scenarios from catastrophically disabling the running system we have implemented a clock domain where clocks are consumed and references are taken, thus preventing them from being shut down by the framework. *** BLURB HERE *** Lee Jones (4): ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 ARM: sti: stih407-family: Add platform interconnects to always-on clk domain clk: Provide an always-on clock domain framework clk: dt: Introduce always-on clock domain documentation .../devicetree/bindings/clock/clk-always-on.txt| 35 arch/arm/boot/dts/stih407-family.dtsi | 15 ++ drivers/clk/Makefile | 1 + drivers/clk/clk-always-on.c| 62 ++ include/dt-bindings/clock/stih407-clks.h | 4 ++ 5 files changed, 117 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt create mode 100644 drivers/clk/clk-always-on.c -- 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/
Re: [PATCH v3 0/4] clk: st: New always-on clock domain
On Tue, 24 Feb 2015, Lee Jones wrote: v2 = v3: - Ensure DT actually reflects h/w - i.e. Nodes should not contain a mishmash of different IP blocks, but should identify related h/w. In the current example we use interconnects - Change naming from clkdomain to clk-always-on - Place do not abuse warning in documentation v1 = v2: - Turned the ST specific driver into a generic one Hardware can have a bunch of clocks which must not be turned off. If drivers a) fail to obtain a reference to any of these or b) give up a previously obtained reference during suspend, the common clk framework will attempt to turn them off and the hardware will subsequently die. The only way to recover from this failure is to restart. To avoid either of these two scenarios from catastrophically disabling the running system we have implemented a clock domain where clocks are consumed and references are taken, thus preventing them from being shut down by the framework. *** BLURB HERE *** *grumble*, that's annoying, as I removed this. I guess Git caches the patches before sending them. Lee Jones (4): ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 ARM: sti: stih407-family: Add platform interconnects to always-on clk domain clk: Provide an always-on clock domain framework clk: dt: Introduce always-on clock domain documentation .../devicetree/bindings/clock/clk-always-on.txt| 35 arch/arm/boot/dts/stih407-family.dtsi | 15 ++ drivers/clk/Makefile | 1 + drivers/clk/clk-always-on.c| 62 ++ include/dt-bindings/clock/stih407-clks.h | 4 ++ 5 files changed, 117 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt create mode 100644 drivers/clk/clk-always-on.c -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/
