| Message ID | 1438010430-5802-2-git-send-email-lee.jones@linaro.org (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Cc'ing few people (whom I cc'd last time as well :)). On 27-07-15, 16:20, Lee Jones wrote: > These OPPs are used in ST's CPUFreq implementation. > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > --- > > Changelog: > - None, new patch > > Documentation/devicetree/bindings/power/opp-st.txt | 76 ++++++++++++++++++++++ > 1 file changed, 76 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt > > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt b/Documentation/devicetree/bindings/power/opp-st.txt > new file mode 100644 > index 0000000..6eb2a91 > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/opp-st.txt > @@ -0,0 +1,76 @@ > +STMicroelectronics OPP (Operating Performance Points) Bindings > +-------------------------------------------------------------- > + > +Frequency Scaling only > +---------------------- > + > +Located in CPU's node: > + > +- operating-points : [See: ./opp.txt] > + > +Example [safe] > +-------------- > + > +cpus { > + cpu@0 { > + /* kHz uV */ > + operating-points = <1500000 0 > + 1200000 0 > + 800000 0 > + 500000 0>; > + }; > +}; > + > +Dynamic Voltage and Frequency Scaling (DVFS) > +-------------------------------------------- > + > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]: > + > +- compatible : Should be "operating-points-v2-sti" > +- opp{1..N} : Each 'oppX' subnode will contain the following properties: Or should we mention: - opp{1..N} : Each 'oppX' subnode shall contain below properties, over what ./opp.txt defines: ? > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] > + - st,avs : List of available voltages [uV] indexed by process code > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] > +- st,syscfg : Phandle to Major number register > + First cell: offset to major number > +- st,syscfg-eng : Phandle to Minor number and Pcode registers > + First cell: offset to process code > + Second cell: offset to minor number > + > +WARNING: The opp{1..N} nodes will be provided by the bootloader. Do not attempt to > + artificially synthesise the opp{1..N} nodes or any of their descendants. > + They are very platform specific and may damage the hardware if created > + incorrectly. > + > +Example [unsafe] > +---------------- > + > +cpus { > + cpu@0 { > + operating-points-v2 = <&cpu0_opp_list>; > + }; > +}; > + > +/* ############################################################ */ > +/* # WARNING: Do not attempt to copy/replicate this node, # */ > +/* # it is only to be supplied by the bootloader !!! # */ > +/* ############################################################ */ > +cpu0-opp-list { > + compatible = "operating-points-v2-sti"; > + st,syscfg = <&syscfg [major_offset]>; > + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>; > + > + opp0 { > + opp-hz = <1200000000>; > + st,avs = <1110 1150 1100 1080 1040 1020 980 930>; > + st,substrate = <0xff>; > + st,cuts = <0xff>; > + }; > + opp1 { > + opp-hz = <1500000000>; > + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>; > + st,substrate = <0xff>; > + st,cuts = <0x2>; > + }; > +}; I don't see more problems here, unless we can move some of this to the generic bindings. @Rob/Stephen: Please respond before it is late :)
On Tue, 28 Jul 2015, Viresh Kumar wrote: > Cc'ing few people (whom I cc'd last time as well :)). > > On 27-07-15, 16:20, Lee Jones wrote: > > These OPPs are used in ST's CPUFreq implementation. > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > > --- > > > > Changelog: > > - None, new patch > > > > Documentation/devicetree/bindings/power/opp-st.txt | 76 ++++++++++++++++++++++ > > 1 file changed, 76 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt > > > > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt b/Documentation/devicetree/bindings/power/opp-st.txt > > new file mode 100644 > > index 0000000..6eb2a91 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/power/opp-st.txt > > @@ -0,0 +1,76 @@ > > +STMicroelectronics OPP (Operating Performance Points) Bindings > > +-------------------------------------------------------------- > > + > > +Frequency Scaling only > > +---------------------- > > + > > +Located in CPU's node: > > + > > +- operating-points : [See: ./opp.txt] > > + > > +Example [safe] > > +-------------- > > + > > +cpus { > > + cpu@0 { > > + /* kHz uV */ > > + operating-points = <1500000 0 > > + 1200000 0 > > + 800000 0 > > + 500000 0>; > > + }; > > +}; > > + > > +Dynamic Voltage and Frequency Scaling (DVFS) > > +-------------------------------------------- > > + > > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]: > > + > > +- compatible : Should be "operating-points-v2-sti" > > +- opp{1..N} : Each 'oppX' subnode will contain the following properties: > > Or should we mention: > - opp{1..N} : Each 'oppX' subnode shall contain below properties, > over what ./opp.txt defines: > > ? I disagree. For one, only 'opp-hz' is defined in ./opp.tx. Secondly it would be annoying to have to have to keep jumping between documents to obtain the whole picture. Finally, generic bindings are repeated in platform/device specific documentation all the time. Grep for 'clocks' or 'regulator-* or 'interrupts' or 'reg' or 'clock-frequency' (which IMHO I think you should have used instead of 'opp-hz', but that's by the by), or any number of other generic properties. > > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] > > + - st,avs : List of available voltages [uV] indexed by process code > > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] > > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] > > +- st,syscfg : Phandle to Major number register > > + First cell: offset to major number > > +- st,syscfg-eng : Phandle to Minor number and Pcode registers > > + First cell: offset to process code > > + Second cell: offset to minor number > > + > > +WARNING: The opp{1..N} nodes will be provided by the bootloader. Do not attempt to > > + artificially synthesise the opp{1..N} nodes or any of their descendants. > > + They are very platform specific and may damage the hardware if created > > + incorrectly. > > + > > +Example [unsafe] > > +---------------- > > + > > +cpus { > > + cpu@0 { > > + operating-points-v2 = <&cpu0_opp_list>; > > + }; > > +}; > > + > > +/* ############################################################ */ > > +/* # WARNING: Do not attempt to copy/replicate this node, # */ > > +/* # it is only to be supplied by the bootloader !!! # */ > > +/* ############################################################ */ > > +cpu0-opp-list { > > + compatible = "operating-points-v2-sti"; > > + st,syscfg = <&syscfg [major_offset]>; > > + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>; > > + > > + opp0 { > > + opp-hz = <1200000000>; > > + st,avs = <1110 1150 1100 1080 1040 1020 980 930>; > > + st,substrate = <0xff>; > > + st,cuts = <0xff>; > > + }; > > + opp1 { > > + opp-hz = <1500000000>; > > + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>; > > + st,substrate = <0xff>; > > + st,cuts = <0x2>; > > + }; > > +}; > > I don't see more problems here, unless we can move some of this to the > generic bindings. > > @Rob/Stephen: Please respond before it is late :) No one knows this stuff better than you. If you can't think of an already existing binding that could suit to portray our 'cuts' and 'substrate' information (with a similar way to support our "all cuts" and "all substrates" options, then there probably isn't one. ;)
On 28-07-15, 08:34, Lee Jones wrote: > I disagree. For one, only 'opp-hz' is defined in ./opp.tx. Secondly There are other properties in op.txt like turbo, opp-suspend, latency, etc.. which can be useful for your platform to. Its not used for now is a different thing. > it would be annoying to have to have to keep jumping between documents > to obtain the whole picture. Finally, generic bindings are repeated > in platform/device specific documentation all the time. Grep for > 'clocks' or 'regulator-* or 'interrupts' or 'reg' or 'clock-frequency' Yeah, I agree. I am not against that. What I meant to say was that its an extension to opp-v2. So whatever is present in opp-v2 can be used by ST's driver, without mentioning that here as well. > (which IMHO I think you should have used instead of 'opp-hz', but > that's by the by), or any number of other generic properties. Hmm, probably yes. See I don't know everything :) > > @Rob/Stephen: Please respond before it is late :) > > No one knows this stuff better than you. If you can't think of an > already existing binding that could suit to portray our 'cuts' and > 'substrate' information (with a similar way to support our "all cuts" > and "all substrates" options, then there probably isn't one. ;) Oh, I wasn't saying that there is an existing binding for supporting your case. But if we want to move the cuts property to the generic bindings so that others can use it. :)
On Tue, 28 Jul 2015, Viresh Kumar wrote: > On 28-07-15, 08:34, Lee Jones wrote: > > I disagree. For one, only 'opp-hz' is defined in ./opp.tx. Secondly > > There are other properties in op.txt like turbo, opp-suspend, latency, > etc.. which can be useful for your platform to. Its not used for now > is a different thing. > > > it would be annoying to have to have to keep jumping between documents > > to obtain the whole picture. Finally, generic bindings are repeated > > in platform/device specific documentation all the time. Grep for > > 'clocks' or 'regulator-* or 'interrupts' or 'reg' or 'clock-frequency' > > Yeah, I agree. I am not against that. What I meant to say was that its > an extension to opp-v2. So whatever is present in opp-v2 can be used > by ST's driver, without mentioning that here as well. > > > (which IMHO I think you should have used instead of 'opp-hz', but > > that's by the by), or any number of other generic properties. > > Hmm, probably yes. See I don't know everything :) > > > > @Rob/Stephen: Please respond before it is late :) > > > > No one knows this stuff better than you. If you can't think of an > > already existing binding that could suit to portray our 'cuts' and > > 'substrate' information (with a similar way to support our "all cuts" > > and "all substrates" options, then there probably isn't one. ;) > > Oh, I wasn't saying that there is an existing binding for supporting > your case. But if we want to move the cuts property to the generic > bindings so that others can use it. :) Okay, so what are we waiting for before you'd be prepared to Ack the binding?
On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones <lee.jones@linaro.org> wrote: > These OPPs are used in ST's CPUFreq implementation. > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > --- > > Changelog: > - None, new patch > > Documentation/devicetree/bindings/power/opp-st.txt | 76 ++++++++++++++++++++++ > 1 file changed, 76 insertions(+) > create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt > > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt b/Documentation/devicetree/bindings/power/opp-st.txt > new file mode 100644 > index 0000000..6eb2a91 > --- /dev/null > +++ b/Documentation/devicetree/bindings/power/opp-st.txt > @@ -0,0 +1,76 @@ > +STMicroelectronics OPP (Operating Performance Points) Bindings > +-------------------------------------------------------------- > + > +Frequency Scaling only > +---------------------- > + > +Located in CPU's node: > + > +- operating-points : [See: ./opp.txt] > + > +Example [safe] > +-------------- > + > +cpus { > + cpu@0 { > + /* kHz uV */ > + operating-points = <1500000 0 > + 1200000 0 > + 800000 0 > + 500000 0>; > + }; > +}; > + > +Dynamic Voltage and Frequency Scaling (DVFS) > +-------------------------------------------- > + > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]: > + > +- compatible : Should be "operating-points-v2-sti" > +- opp{1..N} : Each 'oppX' subnode will contain the following properties: > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] > + - st,avs : List of available voltages [uV] indexed by process code Add a unit suffix (-microvolt). > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] How about not present means all? > +- st,syscfg : Phandle to Major number register > + First cell: offset to major number > +- st,syscfg-eng : Phandle to Minor number and Pcode registers > + First cell: offset to process code > + Second cell: offset to minor number Would the proposed nvmem binding work for this? Rob -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 28 Jul 2015, Rob Herring wrote: > On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones <lee.jones@linaro.org> wrote: > > These OPPs are used in ST's CPUFreq implementation. > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > > --- > > > > Changelog: > > - None, new patch > > > > Documentation/devicetree/bindings/power/opp-st.txt | 76 ++++++++++++++++++++++ > > 1 file changed, 76 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt > > > > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt b/Documentation/devicetree/bindings/power/opp-st.txt > > new file mode 100644 > > index 0000000..6eb2a91 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/power/opp-st.txt > > @@ -0,0 +1,76 @@ > > +STMicroelectronics OPP (Operating Performance Points) Bindings > > +-------------------------------------------------------------- > > + > > +Frequency Scaling only > > +---------------------- > > + > > +Located in CPU's node: > > + > > +- operating-points : [See: ./opp.txt] > > + > > +Example [safe] > > +-------------- > > + > > +cpus { > > + cpu@0 { > > + /* kHz uV */ > > + operating-points = <1500000 0 > > + 1200000 0 > > + 800000 0 > > + 500000 0>; > > + }; > > +}; > > + > > +Dynamic Voltage and Frequency Scaling (DVFS) > > +-------------------------------------------- > > + > > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]: > > + > > +- compatible : Should be "operating-points-v2-sti" > > +- opp{1..N} : Each 'oppX' subnode will contain the following properties: > > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] > > + - st,avs : List of available voltages [uV] indexed by process code > > Add a unit suffix (-microvolt). Sure. > > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] > > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] > > How about not present means all? I think that would be an unsafe assumption. If it's forgotten, then we may try to run an invalid/dangerous voltage/frequency combination. I'd really like 'all' to be defined an deliberate. > > +- st,syscfg : Phandle to Major number register > > + First cell: offset to major number > > +- st,syscfg-eng : Phandle to Minor number and Pcode registers > > + First cell: offset to process code > > + Second cell: offset to minor number > > Would the proposed nvmem binding work for this? We already use sysconf for all of this type of stuff, as this information is contained in ST's Sysconf banks. Moving over to a new API would be a huge move and would require lots of planning discussions with ST.
On Tue, Jul 28, 2015 at 9:39 AM, Lee Jones <lee.jones@linaro.org> wrote: > On Tue, 28 Jul 2015, Rob Herring wrote: > >> On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones <lee.jones@linaro.org> wrote: >> > These OPPs are used in ST's CPUFreq implementation. >> > >> > Signed-off-by: Lee Jones <lee.jones@linaro.org> >> > --- >> > >> > Changelog: >> > - None, new patch >> > >> > Documentation/devicetree/bindings/power/opp-st.txt | 76 ++++++++++++++++++++++ >> > 1 file changed, 76 insertions(+) >> > create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt >> > >> > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt b/Documentation/devicetree/bindings/power/opp-st.txt >> > new file mode 100644 >> > index 0000000..6eb2a91 >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/power/opp-st.txt >> > @@ -0,0 +1,76 @@ >> > +STMicroelectronics OPP (Operating Performance Points) Bindings >> > +-------------------------------------------------------------- >> > + >> > +Frequency Scaling only >> > +---------------------- >> > + >> > +Located in CPU's node: >> > + >> > +- operating-points : [See: ./opp.txt] >> > + >> > +Example [safe] >> > +-------------- >> > + >> > +cpus { >> > + cpu@0 { >> > + /* kHz uV */ >> > + operating-points = <1500000 0 >> > + 1200000 0 >> > + 800000 0 >> > + 500000 0>; >> > + }; >> > +}; >> > + >> > +Dynamic Voltage and Frequency Scaling (DVFS) >> > +-------------------------------------------- >> > + >> > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]: >> > + >> > +- compatible : Should be "operating-points-v2-sti" >> > +- opp{1..N} : Each 'oppX' subnode will contain the following properties: >> > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] >> > + - st,avs : List of available voltages [uV] indexed by process code >> >> Add a unit suffix (-microvolt). > > Sure. > >> > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] >> > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] >> >> How about not present means all? > > I think that would be an unsafe assumption. If it's forgotten, then > we may try to run an invalid/dangerous voltage/frequency combination. > > I'd really like 'all' to be defined an deliberate. Okay. >> > +- st,syscfg : Phandle to Major number register >> > + First cell: offset to major number >> > +- st,syscfg-eng : Phandle to Minor number and Pcode registers >> > + First cell: offset to process code >> > + Second cell: offset to minor number >> >> Would the proposed nvmem binding work for this? > > We already use sysconf for all of this type of stuff, as this > information is contained in ST's Sysconf banks. Moving over to a new > API would be a huge move and would require lots of planning > discussions with ST. Okay. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 28 Jul 2015, Rob Herring wrote: > On Tue, Jul 28, 2015 at 9:39 AM, Lee Jones <lee.jones@linaro.org> wrote: > > On Tue, 28 Jul 2015, Rob Herring wrote: > > > >> On Mon, Jul 27, 2015 at 10:20 AM, Lee Jones <lee.jones@linaro.org> wrote: > >> > These OPPs are used in ST's CPUFreq implementation. > >> > > >> > Signed-off-by: Lee Jones <lee.jones@linaro.org> > >> > --- > >> > > >> > Changelog: > >> > - None, new patch > >> > > >> > Documentation/devicetree/bindings/power/opp-st.txt | 76 ++++++++++++++++++++++ > >> > 1 file changed, 76 insertions(+) > >> > create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt > >> > > >> > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt b/Documentation/devicetree/bindings/power/opp-st.txt > >> > new file mode 100644 > >> > index 0000000..6eb2a91 > >> > --- /dev/null > >> > +++ b/Documentation/devicetree/bindings/power/opp-st.txt > >> > @@ -0,0 +1,76 @@ > >> > +STMicroelectronics OPP (Operating Performance Points) Bindings > >> > +-------------------------------------------------------------- > >> > + > >> > +Frequency Scaling only > >> > +---------------------- > >> > + > >> > +Located in CPU's node: > >> > + > >> > +- operating-points : [See: ./opp.txt] > >> > + > >> > +Example [safe] > >> > +-------------- > >> > + > >> > +cpus { > >> > + cpu@0 { > >> > + /* kHz uV */ > >> > + operating-points = <1500000 0 > >> > + 1200000 0 > >> > + 800000 0 > >> > + 500000 0>; > >> > + }; > >> > +}; > >> > + > >> > +Dynamic Voltage and Frequency Scaling (DVFS) > >> > +-------------------------------------------- > >> > + > >> > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]: > >> > + > >> > +- compatible : Should be "operating-points-v2-sti" > >> > +- opp{1..N} : Each 'oppX' subnode will contain the following properties: > >> > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] > >> > + - st,avs : List of available voltages [uV] indexed by process code > >> > >> Add a unit suffix (-microvolt). > > > > Sure. > > > >> > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] > >> > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] > >> > >> How about not present means all? > > > > I think that would be an unsafe assumption. If it's forgotten, then > > we may try to run an invalid/dangerous voltage/frequency combination. > > > > I'd really like 'all' to be defined an deliberate. > > Okay. > > >> > +- st,syscfg : Phandle to Major number register > >> > + First cell: offset to major number > >> > +- st,syscfg-eng : Phandle to Minor number and Pcode registers > >> > + First cell: offset to process code > >> > + Second cell: offset to minor number > >> > >> Would the proposed nvmem binding work for this? > > > > We already use sysconf for all of this type of stuff, as this > > information is contained in ST's Sysconf banks. Moving over to a new > > API would be a huge move and would require lots of planning > > discussions with ST. > > Okay. Thanks. I'm going to fix up your suggestions above and add your Ack to make Viresh happy. :) Thanks Rob.
On 07/28, Viresh Kumar wrote: > Cc'ing few people (whom I cc'd last time as well :)). > > On 27-07-15, 16:20, Lee Jones wrote: > > These OPPs are used in ST's CPUFreq implementation. > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > > --- > > > > Changelog: > > - None, new patch > > > > Documentation/devicetree/bindings/power/opp-st.txt | 76 ++++++++++++++++++++++ > > 1 file changed, 76 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt > > > > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt b/Documentation/devicetree/bindings/power/opp-st.txt > > new file mode 100644 > > index 0000000..6eb2a91 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/power/opp-st.txt > > @@ -0,0 +1,76 @@ > > +STMicroelectronics OPP (Operating Performance Points) Bindings > > +-------------------------------------------------------------- > > + > > +Frequency Scaling only > > +---------------------- > > + > > +Located in CPU's node: > > + > > +- operating-points : [See: ./opp.txt] > > + > > +Example [safe] > > +-------------- > > + > > +cpus { > > + cpu@0 { > > + /* kHz uV */ > > + operating-points = <1500000 0 > > + 1200000 0 > > + 800000 0 > > + 500000 0>; > > + }; > > +}; > > + > > +Dynamic Voltage and Frequency Scaling (DVFS) > > +-------------------------------------------- > > + > > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]: > > + > > +- compatible : Should be "operating-points-v2-sti" > > +- opp{1..N} : Each 'oppX' subnode will contain the following properties: > > Or should we mention: > - opp{1..N} : Each 'oppX' subnode shall contain below properties, > over what ./opp.txt defines: > > ? > > > > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] > > + - st,avs : List of available voltages [uV] indexed by process code > > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] > > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] > > +- st,syscfg : Phandle to Major number register > > + First cell: offset to major number > > +- st,syscfg-eng : Phandle to Minor number and Pcode registers > > + First cell: offset to process code > > + Second cell: offset to minor number > > + > > +WARNING: The opp{1..N} nodes will be provided by the bootloader. Do not attempt to > > + artificially synthesise the opp{1..N} nodes or any of their descendants. > > + They are very platform specific and may damage the hardware if created > > + incorrectly. > > + > > +Example [unsafe] > > +---------------- > > + > > +cpus { > > + cpu@0 { > > + operating-points-v2 = <&cpu0_opp_list>; > > + }; > > +}; > > + > > +/* ############################################################ */ > > +/* # WARNING: Do not attempt to copy/replicate this node, # */ > > +/* # it is only to be supplied by the bootloader !!! # */ > > +/* ############################################################ */ > > +cpu0-opp-list { > > + compatible = "operating-points-v2-sti"; > > + st,syscfg = <&syscfg [major_offset]>; > > + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>; > > + > > + opp0 { > > + opp-hz = <1200000000>; > > + st,avs = <1110 1150 1100 1080 1040 1020 980 930>; > > + st,substrate = <0xff>; > > + st,cuts = <0xff>; > > + }; > > + opp1 { > > + opp-hz = <1500000000>; > > + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>; > > + st,substrate = <0xff>; > > + st,cuts = <0x2>; > > + }; > > +}; > > I don't see more problems here, unless we can move some of this to the > generic bindings. > > @Rob/Stephen: Please respond before it is late :) > It's interesting to have vendor specific properties like avs, cuts, and substrate. That could replace our planned usage of the opp-names property where we encode similar information (speed bin, revision, etc.) into a string that we look for. So I wonder why the avs/cut/substrate information can't be encoded into the opp name? That would make these properties obsolete, given that all they're used for is to pick out the correct OPP?
On Tue, 28 Jul 2015, Stephen Boyd wrote: > On 07/28, Viresh Kumar wrote: > > Cc'ing few people (whom I cc'd last time as well :)). > > > > On 27-07-15, 16:20, Lee Jones wrote: > > > These OPPs are used in ST's CPUFreq implementation. > > > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > > > --- > > > > > > Changelog: > > > - None, new patch > > > > > > Documentation/devicetree/bindings/power/opp-st.txt | 76 ++++++++++++++++++++++ > > > 1 file changed, 76 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt > > > > > > diff --git a/Documentation/devicetree/bindings/power/opp-st.txt b/Documentation/devicetree/bindings/power/opp-st.txt > > > new file mode 100644 > > > index 0000000..6eb2a91 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/power/opp-st.txt > > > @@ -0,0 +1,76 @@ > > > +STMicroelectronics OPP (Operating Performance Points) Bindings > > > +-------------------------------------------------------------- > > > + > > > +Frequency Scaling only > > > +---------------------- > > > + > > > +Located in CPU's node: > > > + > > > +- operating-points : [See: ./opp.txt] > > > + > > > +Example [safe] > > > +-------------- > > > + > > > +cpus { > > > + cpu@0 { > > > + /* kHz uV */ > > > + operating-points = <1500000 0 > > > + 1200000 0 > > > + 800000 0 > > > + 500000 0>; > > > + }; > > > +}; > > > + > > > +Dynamic Voltage and Frequency Scaling (DVFS) > > > +-------------------------------------------- > > > + > > > +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]: > > > + > > > +- compatible : Should be "operating-points-v2-sti" > > > +- opp{1..N} : Each 'oppX' subnode will contain the following properties: > > > > Or should we mention: > > - opp{1..N} : Each 'oppX' subnode shall contain below properties, > > over what ./opp.txt defines: > > > > ? > > > > > > > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] > > > + - st,avs : List of available voltages [uV] indexed by process code > > > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] > > > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] > > > +- st,syscfg : Phandle to Major number register > > > + First cell: offset to major number > > > +- st,syscfg-eng : Phandle to Minor number and Pcode registers > > > + First cell: offset to process code > > > + Second cell: offset to minor number > > > + > > > +WARNING: The opp{1..N} nodes will be provided by the bootloader. Do not attempt to > > > + artificially synthesise the opp{1..N} nodes or any of their descendants. > > > + They are very platform specific and may damage the hardware if created > > > + incorrectly. > > > + > > > +Example [unsafe] > > > +---------------- > > > + > > > +cpus { > > > + cpu@0 { > > > + operating-points-v2 = <&cpu0_opp_list>; > > > + }; > > > +}; > > > + > > > +/* ############################################################ */ > > > +/* # WARNING: Do not attempt to copy/replicate this node, # */ > > > +/* # it is only to be supplied by the bootloader !!! # */ > > > +/* ############################################################ */ > > > +cpu0-opp-list { > > > + compatible = "operating-points-v2-sti"; > > > + st,syscfg = <&syscfg [major_offset]>; > > > + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>; > > > + > > > + opp0 { > > > + opp-hz = <1200000000>; > > > + st,avs = <1110 1150 1100 1080 1040 1020 980 930>; > > > + st,substrate = <0xff>; > > > + st,cuts = <0xff>; > > > + }; > > > + opp1 { > > > + opp-hz = <1500000000>; > > > + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>; > > > + st,substrate = <0xff>; > > > + st,cuts = <0x2>; > > > + }; > > > +}; > > > > I don't see more problems here, unless we can move some of this to the > > generic bindings. > > > > @Rob/Stephen: Please respond before it is late :) > > It's interesting to have vendor specific properties like avs, > cuts, and substrate. That could replace our planned usage of the > opp-names property where we encode similar information (speed > bin, revision, etc.) into a string that we look for. > > So I wonder why the avs/cut/substrate information can't be > encoded into the opp name? That would make these properties > obsolete, given that all they're used for is to pick out the > correct OPP? You could hack the substrate and cut version into a string, but that's exactly what it would be, a hack. I'm struggling how you would do the same for 'st,avs', which is an array of u32s.
On 07/29, Lee Jones wrote: > On Tue, 28 Jul 2015, Stephen Boyd wrote: > > > On 07/28, Viresh Kumar wrote: > > > Cc'ing few people (whom I cc'd last time as well :)). > > > > > > On 27-07-15, 16:20, Lee Jones wrote: > > > > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] > > > > + - st,avs : List of available voltages [uV] indexed by process code > > > > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] > > > > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] [...] > > > > +cpu0-opp-list { > > > > + compatible = "operating-points-v2-sti"; > > > > + st,syscfg = <&syscfg [major_offset]>; > > > > + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>; > > > > + > > > > + opp0 { > > > > + opp-hz = <1200000000>; > > > > + st,avs = <1110 1150 1100 1080 1040 1020 980 930>; > > > > + st,substrate = <0xff>; > > > > + st,cuts = <0xff>; > > > > + }; > > > > + opp1 { > > > > + opp-hz = <1500000000>; > > > > + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>; > > > > + st,substrate = <0xff>; > > > > + st,cuts = <0x2>; > > > > + }; > > > > +}; > > > > > > I don't see more problems here, unless we can move some of this to the > > > generic bindings. > > > > > > @Rob/Stephen: Please respond before it is late :) > > > > It's interesting to have vendor specific properties like avs, > > cuts, and substrate. That could replace our planned usage of the > > opp-names property where we encode similar information (speed > > bin, revision, etc.) into a string that we look for. > > > > So I wonder why the avs/cut/substrate information can't be > > encoded into the opp name? That would make these properties > > obsolete, given that all they're used for is to pick out the > > correct OPP? > > You could hack the substrate and cut version into a string, but that's > exactly what it would be, a hack. I'm struggling how you would do the > same for 'st,avs', which is an array of u32s. > (I don't understand the st,avs property to begin with, so feel free to ignore the rest of this mail.) For qcom platforms we have the pvs bin and speed bin, and sometimes a revision number. Each one of these properties corresponds to a different set of OPPs (opp table). So we might have speed1-pvs2-v0 for speed bin 1, pvs bin 2 and version 0. We fill out an opp table for this and then point the opps property at the table and have a corresponding opp-name "speed1-pvs2-v0" in the "consumer" node. operating-points-v2 = <&speed1_pvs2_v0>; operating-points-names = "speed1-pvs2-v0"; We have quite a few of these tables because the values are always different. If the values were the same then we could use the same table with different names I suppose, but we're not doing that. From a quick read of the st properties (that I admit I don't understand), it looks like we're trying to compress the OPP tables by listing all the voltages that could be used for a particular frequency depending on which avs is present on the device? And then limiting the frequency voltage pairs depending on which cut and substrate is present? So we'd probably have to expand out the tables to be unique per avs/cut/substrate parameter. Something like: avs0-cut2 { compatible = "operating-points-v2"; opp0 { opp-hz = <1200000000>; opp-microvolt = <1100>; }; opp1 { opp-hz = <1500000000>; opp-microvolt = <1200>; }; }; avs1-cut2 { compatible = "operating-points-v2"; opp0 { opp-hz = <1200000000>; opp-microvolt = <1150>; }; opp1 { opp-hz = <1500000000>; opp-microvolt = <1200>; }; }; And then another copy of these for the devices without cuts != 2 where the top frequency is gone?
On Wed, 29 Jul 2015, Stephen Boyd wrote: > On 07/29, Lee Jones wrote: > > On Tue, 28 Jul 2015, Stephen Boyd wrote: > > > > > On 07/28, Viresh Kumar wrote: > > > > Cc'ing few people (whom I cc'd last time as well :)). > > > > > > > > On 27-07-15, 16:20, Lee Jones wrote: > > > > > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] > > > > > + - st,avs : List of available voltages [uV] indexed by process code > > > > > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] > > > > > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] > [...] > > > > > +cpu0-opp-list { > > > > > + compatible = "operating-points-v2-sti"; > > > > > + st,syscfg = <&syscfg [major_offset]>; > > > > > + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>; > > > > > + > > > > > + opp0 { > > > > > + opp-hz = <1200000000>; > > > > > + st,avs = <1110 1150 1100 1080 1040 1020 980 930>; > > > > > + st,substrate = <0xff>; > > > > > + st,cuts = <0xff>; > > > > > + }; > > > > > + opp1 { > > > > > + opp-hz = <1500000000>; > > > > > + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>; > > > > > + st,substrate = <0xff>; > > > > > + st,cuts = <0x2>; > > > > > + }; > > > > > +}; > > > > > > > > I don't see more problems here, unless we can move some of this to the > > > > generic bindings. > > > > > > > > @Rob/Stephen: Please respond before it is late :) > > > > > > It's interesting to have vendor specific properties like avs, > > > cuts, and substrate. That could replace our planned usage of the > > > opp-names property where we encode similar information (speed > > > bin, revision, etc.) into a string that we look for. > > > > > > So I wonder why the avs/cut/substrate information can't be > > > encoded into the opp name? That would make these properties > > > obsolete, given that all they're used for is to pick out the > > > correct OPP? > > > > You could hack the substrate and cut version into a string, but that's > > exactly what it would be, a hack. I'm struggling how you would do the > > same for 'st,avs', which is an array of u32s. > > > > > (I don't understand the st,avs property to begin with, so feel > free to ignore the rest of this mail.) > > For qcom platforms we have the pvs bin and speed bin, and > sometimes a revision number. Each one of these properties > corresponds to a different set of OPPs (opp table). So we might > have speed1-pvs2-v0 for speed bin 1, pvs bin 2 and version 0. We > fill out an opp table for this and then point the opps property > at the table and have a corresponding opp-name "speed1-pvs2-v0" > in the "consumer" node. > > operating-points-v2 = <&speed1_pvs2_v0>; > operating-points-names = "speed1-pvs2-v0"; > > We have quite a few of these tables because the values are > always different. If the values were the same then we could use > the same table with different names I suppose, but we're not > doing that. > > From a quick read of the st properties (that I admit I don't > understand), it looks like we're trying to compress the OPP > tables by listing all the voltages that could be used for a > particular frequency depending on which avs is present on the > device? And then limiting the frequency voltage pairs depending > on which cut and substrate is present? > > So we'd probably have to expand out the tables to be unique per > avs/cut/substrate parameter. Something like: > > avs0-cut2 { > compatible = "operating-points-v2"; > > opp0 { > opp-hz = <1200000000>; > opp-microvolt = <1100>; > }; > > opp1 { > opp-hz = <1500000000>; > opp-microvolt = <1200>; > }; > }; > > avs1-cut2 { > compatible = "operating-points-v2"; > > opp0 { > opp-hz = <1200000000>; > opp-microvolt = <1150>; > }; > > opp1 { > opp-hz = <1500000000>; > opp-microvolt = <1200>; > }; > }; > > And then another copy of these for the devices without cuts != 2 > where the top frequency is gone? There is nothing stopping us from representing the data in this way. On the plus side, it would mean that we wouldn't need any vendor specific properties. However, far outweighing the positives are the fact that, even in our very simple example provided, where we only have 2 frequencies, differ between only 1 cut and support all substrates, we would still need 16 OPP tables. When any one of those variables increase (and they will), we would then have a large number of permutations and subsequently and unruly amount of OPP tables. (... and we haven't even provided the body-biasing information yet.) The way we've chosen to represent our circumstance is the least intrusive and the most succinct way we can think of. Which IMHO outweighs the fact that we have to introduce a couple of vendor properties by a country mile.
On Thu, Jul 30, 2015 at 3:46 AM, Lee Jones <lee.jones@linaro.org> wrote: > On Wed, 29 Jul 2015, Stephen Boyd wrote: > >> On 07/29, Lee Jones wrote: >> > On Tue, 28 Jul 2015, Stephen Boyd wrote: >> > >> > > On 07/28, Viresh Kumar wrote: >> > > > Cc'ing few people (whom I cc'd last time as well :)). >> > > > >> > > > On 27-07-15, 16:20, Lee Jones wrote: >> > > > > + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] >> > > > > + - st,avs : List of available voltages [uV] indexed by process code >> > > > > + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] >> > > > > + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] >> [...] >> > > > > +cpu0-opp-list { >> > > > > + compatible = "operating-points-v2-sti"; >> > > > > + st,syscfg = <&syscfg [major_offset]>; >> > > > > + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>; >> > > > > + >> > > > > + opp0 { >> > > > > + opp-hz = <1200000000>; >> > > > > + st,avs = <1110 1150 1100 1080 1040 1020 980 930>; >> > > > > + st,substrate = <0xff>; >> > > > > + st,cuts = <0xff>; >> > > > > + }; >> > > > > + opp1 { >> > > > > + opp-hz = <1500000000>; >> > > > > + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>; >> > > > > + st,substrate = <0xff>; >> > > > > + st,cuts = <0x2>; >> > > > > + }; >> > > > > +}; >> > > > >> > > > I don't see more problems here, unless we can move some of this to the >> > > > generic bindings. >> > > > >> > > > @Rob/Stephen: Please respond before it is late :) >> > > >> > > It's interesting to have vendor specific properties like avs, >> > > cuts, and substrate. That could replace our planned usage of the >> > > opp-names property where we encode similar information (speed >> > > bin, revision, etc.) into a string that we look for. >> > > >> > > So I wonder why the avs/cut/substrate information can't be >> > > encoded into the opp name? That would make these properties >> > > obsolete, given that all they're used for is to pick out the >> > > correct OPP? >> > >> > You could hack the substrate and cut version into a string, but that's >> > exactly what it would be, a hack. I'm struggling how you would do the >> > same for 'st,avs', which is an array of u32s. >> > >> >> >> (I don't understand the st,avs property to begin with, so feel >> free to ignore the rest of this mail.) >> >> For qcom platforms we have the pvs bin and speed bin, and >> sometimes a revision number. Each one of these properties >> corresponds to a different set of OPPs (opp table). So we might >> have speed1-pvs2-v0 for speed bin 1, pvs bin 2 and version 0. We >> fill out an opp table for this and then point the opps property >> at the table and have a corresponding opp-name "speed1-pvs2-v0" >> in the "consumer" node. >> >> operating-points-v2 = <&speed1_pvs2_v0>; >> operating-points-names = "speed1-pvs2-v0"; >> >> We have quite a few of these tables because the values are >> always different. If the values were the same then we could use >> the same table with different names I suppose, but we're not >> doing that. >> >> From a quick read of the st properties (that I admit I don't >> understand), it looks like we're trying to compress the OPP >> tables by listing all the voltages that could be used for a >> particular frequency depending on which avs is present on the >> device? And then limiting the frequency voltage pairs depending >> on which cut and substrate is present? >> >> So we'd probably have to expand out the tables to be unique per >> avs/cut/substrate parameter. Something like: >> >> avs0-cut2 { >> compatible = "operating-points-v2"; >> >> opp0 { >> opp-hz = <1200000000>; >> opp-microvolt = <1100>; >> }; >> >> opp1 { >> opp-hz = <1500000000>; >> opp-microvolt = <1200>; >> }; >> }; >> >> avs1-cut2 { >> compatible = "operating-points-v2"; >> >> opp0 { >> opp-hz = <1200000000>; >> opp-microvolt = <1150>; >> }; >> >> opp1 { >> opp-hz = <1500000000>; >> opp-microvolt = <1200>; >> }; >> }; >> >> And then another copy of these for the devices without cuts != 2 >> where the top frequency is gone? > > There is nothing stopping us from representing the data in this way. > On the plus side, it would mean that we wouldn't need any vendor > specific properties. However, far outweighing the positives are the > fact that, even in our very simple example provided, where we only > have 2 frequencies, differ between only 1 cut and support all > substrates, we would still need 16 OPP tables. When any one of those > variables increase (and they will), we would then have a large number > of permutations and subsequently and unruly amount of OPP tables. > > (... and we haven't even provided the body-biasing information yet.) > > The way we've chosen to represent our circumstance is the least > intrusive and the most succinct way we can think of. Which IMHO > outweighs the fact that we have to introduce a couple of vendor > properties by a country mile. Regardless of which is better or worse, you are both doing essentially the same thing. You are selecting OPPs based on some Si parameters. We should not really be doing this 2 different ways. I'd be fine with 2 ways if it was 2 for all SOCs, but right now it is 2 for 2 SOCs. Really, I'd like to see most if not all the selection or fixup of OPPs be done in the bootloader and the kernel just deals with the correct OPP table. Where are you storing the data that gets selected to fill into these properties? Is it just look-up tables or is there some kind of algorithm to generate the values? If the former, then DT is as good a data struct as any to store the tables. There is a lot of duplication though with only a single property varying in each set. If you both have that problem, then perhaps we can come up with a generic way to list all possible values more concisely. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/30, Rob Herring wrote: > On Thu, Jul 30, 2015 at 3:46 AM, Lee Jones <lee.jones@linaro.org> wrote: > > > > There is nothing stopping us from representing the data in this way. > > On the plus side, it would mean that we wouldn't need any vendor > > specific properties. However, far outweighing the positives are the > > fact that, even in our very simple example provided, where we only > > have 2 frequencies, differ between only 1 cut and support all > > substrates, we would still need 16 OPP tables. When any one of those > > variables increase (and they will), we would then have a large number > > of permutations and subsequently and unruly amount of OPP tables. > > > > (... and we haven't even provided the body-biasing information yet.) > > > > The way we've chosen to represent our circumstance is the least > > intrusive and the most succinct way we can think of. Which IMHO > > outweighs the fact that we have to introduce a couple of vendor > > properties by a country mile. > > Regardless of which is better or worse, you are both doing essentially > the same thing. You are selecting OPPs based on some Si parameters. We > should not really be doing this 2 different ways. I'd be fine with 2 > ways if it was 2 for all SOCs, but right now it is 2 for 2 SOCs. > Really, I'd like to see most if not all the selection or fixup of OPPs > be done in the bootloader and the kernel just deals with the correct > OPP table. > > Where are you storing the data that gets selected to fill into these > properties? Is it just look-up tables or is there some kind of > algorithm to generate the values? If the former, then DT is as good a > data struct as any to store the tables. There is a lot of duplication > though with only a single property varying in each set. If you both > have that problem, then perhaps we can come up with a generic way to > list all possible values more concisely. For qcom platforms, the frequency is almost always constant. There may be some tables where we have a couple higher frequencies than others because the speed bin is different. Otherwise the voltage/current is changing based on the silicon characteristics. So the biggest duplication is the frequency property. As far as I know there isn't any algorithm to generate the voltage values. It's all hand tuned tables based on the silicon characterization, so we're left to store these tables in DT and pick the right one at runtime. With regards to the table explosion, on qcom platforms we haven't worried that we have ~40 tables, but I'm not opposed to expressing it in a smaller set of nodes, tables, etc. if that's what's desired. Do we need vendor specific properties for that though? Or do we need some sort of extended frequency/voltage properties that are arrays of values that we can index into based on some silicon characteristics? I like the name based approach because it's simple. Use this OPP table because it's called x-y-z-characteristics and be done. Cramming the tables into less lines may save us some typing and dtb space, but I'm not sure what else it does.
On 31-07-15, 09:37, Stephen Boyd wrote:
> Do we need vendor specific properties for that though?
Sorry Lee :), but this is exactly why I wanted this thread to exist. We must and
should do this in a generic enough way.
diff --git a/Documentation/devicetree/bindings/power/opp-st.txt b/Documentation/devicetree/bindings/power/opp-st.txt new file mode 100644 index 0000000..6eb2a91 --- /dev/null +++ b/Documentation/devicetree/bindings/power/opp-st.txt @@ -0,0 +1,76 @@ +STMicroelectronics OPP (Operating Performance Points) Bindings +-------------------------------------------------------------- + +Frequency Scaling only +---------------------- + +Located in CPU's node: + +- operating-points : [See: ./opp.txt] + +Example [safe] +-------------- + +cpus { + cpu@0 { + /* kHz uV */ + operating-points = <1500000 0 + 1200000 0 + 800000 0 + 500000 0>; + }; +}; + +Dynamic Voltage and Frequency Scaling (DVFS) +-------------------------------------------- + +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]: + +- compatible : Should be "operating-points-v2-sti" +- opp{1..N} : Each 'oppX' subnode will contain the following properties: + - opp-hz : CPU frequency [Hz] for this OPP [See: ./opp.txt] + - st,avs : List of available voltages [uV] indexed by process code + - st,cuts : Cut version this OPP is suitable for [0xFF means ALL] + - st,substrate : Substrate version this OPP is suitable for [0xFF means ALL] +- st,syscfg : Phandle to Major number register + First cell: offset to major number +- st,syscfg-eng : Phandle to Minor number and Pcode registers + First cell: offset to process code + Second cell: offset to minor number + +WARNING: The opp{1..N} nodes will be provided by the bootloader. Do not attempt to + artificially synthesise the opp{1..N} nodes or any of their descendants. + They are very platform specific and may damage the hardware if created + incorrectly. + +Example [unsafe] +---------------- + +cpus { + cpu@0 { + operating-points-v2 = <&cpu0_opp_list>; + }; +}; + +/* ############################################################ */ +/* # WARNING: Do not attempt to copy/replicate this node, # */ +/* # it is only to be supplied by the bootloader !!! # */ +/* ############################################################ */ +cpu0-opp-list { + compatible = "operating-points-v2-sti"; + st,syscfg = <&syscfg [major_offset]>; + st,syscfg-eng = <&syscfg_eng [pcode_offset] [minor_offset]>; + + opp0 { + opp-hz = <1200000000>; + st,avs = <1110 1150 1100 1080 1040 1020 980 930>; + st,substrate = <0xff>; + st,cuts = <0xff>; + }; + opp1 { + opp-hz = <1500000000>; + st,avs = <1200 1200 1200 1200 1170 1140 1100 1070>; + st,substrate = <0xff>; + st,cuts = <0x2>; + }; +};
These OPPs are used in ST's CPUFreq implementation. Signed-off-by: Lee Jones <lee.jones@linaro.org> --- Changelog: - None, new patch Documentation/devicetree/bindings/power/opp-st.txt | 76 ++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 Documentation/devicetree/bindings/power/opp-st.txt