On 05-01-16, 11:21, Arnd Bergmann wrote:
> On Monday 28 December 2015 08:43:40 Viresh Kumar wrote:
> > On 27-12-15, 14:21, Pi-Cheng Chen wrote:
> > > Add operating-points-v2, clock, and regulator supply properties
> > > required by mt8173-cpufreq driver to enable it.
>
cpumask
> return -ENOENT;
> }
>
> + cpumask_set_cpu(cpu_dev->id, cpumask);
> +
> /* OPPs are shared ? */
> if (!of_property_read_bool(np, "opp-shared"))
> goto put_cpu_node;
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe fr
2 files changed, 108 insertions(+)
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
; 1 file changed, 11 insertions(+), 6 deletions(-)
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 27-12-15, 14:21, Pi-Cheng Chen wrote:
> Don't skip cpu_dev->id when setting up cpumask for CPUs that share the
> same OPP table. This might be helpful when handling cpumask without the
> original CPU bitfield set.
>
> Signed-off-by: Pi-Cheng Chen
> ---
> drivers/base/power/opp/cpu.c | 4
PU temperature.
>
> Binding document is refer to this patchset
> https://lkml.org/lkml/2015/11/30/239
>
> Change since V5:
> 1. Remove thermal sensor ID from phandles
Though you should have included this in the new version, but still
Acked-by: Viresh Kumar
--
viresh
--
To
PU temperature.
>
> Binding document is refer to this patchset
> https://lkml.org/lkml/2015/11/30/239
>
> Change since V4:
> 1. Remove unnecessary error-checking for mt8173-cpufreq.c
> 2. Initializing variable capacitance with 0
Acked-by: Viresh Kumar
--
viresh
--
On 11-12-15, 15:17, Krzysztof Kozlowski wrote:
> Exynos5420 and Exynos5800 boards boot from big core (A15) but
> Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this
s/Exynos5420/Exynos5422
and then you can add
Reviewed-by: Viresh Kumar
--
viresh
--
To unsubscrib
On 10-12-15, 22:38, Rafael J. Wysocki wrote:
> Do they depend on anything special?
My opp-binding-parsing patches which you applied to bleeding-edge.
Yes, Lee should have mentioned that explicitly.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of
arch/arm/boot/dts/spear*
> F: arch/arm/mach-spear/
>
> SPEAR CLOCK FRAMEWORK SUPPORT
Reviewed-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 10-12-15, 09:42, Lee Jones wrote:
> Hi Rafael,
>
> Would you be kind enough to pick these 2 patches up please.
> The have the required Acks.
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body
> drivers/cpufreq/sti-cpufreq.c | 294
> ++
> 3 files changed, 305 insertions(+)
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
27; patches in the set which are not necessarily
> related to CPUFreq, but are required to get it to work. Anyone
> who is not interested in general STi DT changes can safely
> ignore these.
Apart from minor comments in the 8th patch, everything else looks
fine.
Reviewed-by: Viresh Kumar
-
On 09-12-15, 15:58, Lee Jones wrote:
> +/*
> + * Only match on "suitable for ALL versions" entries
> + *
> + * This will be used with the BIT() macro. It sets the
> + * top bit of a 32bit value and is equal to 0x8000.
> + */
> +#define DEFAULT_VERSION 31
Okay, I misread it in the
On 09-12-15, 10:15, Arnd Bergmann wrote:
> On Tuesday 08 December 2015 14:32:01 Lee Jones wrote:
> > @@ -161,3 +166,11 @@ struct smp_operations __initdata sti_smp_ops = {
> > .smp_secondary_init = sti_secondary_init,
> > .smp_boot_secondary = sti_boot_secondary,
> > };
> >
On 09-12-15, 08:27, Viresh Kumar wrote:
> Good work Lee, looks mostly okay. Few nits below.
Also, it may make sense to quit early of opp-v2 isn't present in your
/cpus/cpuX node. As we wouldn't be using any of this then.
--
viresh
--
To unsubscribe from this list: send the line
Good work Lee, looks mostly okay. Few nits below.
On 08-12-15, 14:32, Lee Jones wrote:
> The bootloader is charged with the responsibility to provide platform
> specific Dynamic Voltage and Frequency Scaling (DVFS) information via
> Device Tree. This driver takes the supplied configuration and
>
On 08-12-15, 14:32, Lee Jones wrote:
> +/**
> + * SMP Operations
> + */
Why do you need a documentation style comment here?
> static void write_pen_release(int val)
> {
> pen_release = val;
> @@ -161,3 +166,11 @@ struct smp_operations __initdata sti_smp_ops = {
> .smp_secondary_init
On 08-12-15, 14:31, Lee Jones wrote:
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi
> b/arch/arm/boot/dts/stih407-family.dtsi
> index 81f8121..9fa1e58 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -22,15 +22,29 @@
>
On 05-12-15, 16:53, Pi-Cheng Chen wrote:
> diff --git a/drivers/cpufreq/mt8173-cpufreq.c
> b/drivers/cpufreq/mt8173-cpufreq.c
> index 257bcb9..17e9cad 100644
> --- a/drivers/cpufreq/mt8173-cpufreq.c
> +++ b/drivers/cpufreq/mt8173-cpufreq.c
> @@ -344,6 +344,9 @@ static int mtk_cpu_dvfs_info_init(st
On 05-12-15, 16:53, Pi-Cheng Chen wrote:
> + cluster0_opp: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> + opp00 {
These have to named like: opp@5070, look at linux-next for this.
--
viresh
--
To unsubscribe from this list: sen
On 30-11-15, 18:21, dawei chien wrote:
> As far as I know, user or shell script has the right for using command
> online/offline cpu.
Right.
> Either user by console or shell script could make cpu2 online even cpu2
> already onlined.
Hey, no. You can't online that is already online. You can wr
On 30-11-15, 17:26, dawei chien wrote:
> On Mon, 2015-11-30 at 11:08 +0530, Viresh Kumar wrote:
> > On 27-11-15, 17:32, Dawei Chien wrote:
> > > MT8173 cpufreq driver use of_cpufreq_power_cooling_register registering
> > > cooling devices with dynamic power coefficient.
On 27-11-15, 17:32, Dawei Chien wrote:
> MT8173 cpufreq driver use of_cpufreq_power_cooling_register registering
> cooling devices with dynamic power coefficient.
>
> Signed-off-by: Dawei Chien
> ---
> This patch is base on patchset:
> https://lkml.org/lkml/2015/11/17/251
> ---
> drivers/cpufreq
return;
Drop this and add my:
Reviewed-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 24-11-15, 14:55, Jia Hongtao wrote:
> + /* Register CPU cooling device for QorIQ platform */
> + for_each_node_with_property(cpu_np, "#cooling-cells") {
> + of_property_read_u32(cpu_np, "reg", &cpu_id);
> + cpufreq_get_policy(&cpu_policy, cpu_id);
That's not the
On 24-11-15, 00:02, Rafael J. Wysocki wrote:
> I'm tentatively queuing this series up for 4.5, but ACKs from Rob are
> still missing for patches [2,5/5] AFAICS.
He may not Ack the 5th one as that's a platform patch, and I have
asked him yesterday again to have a look at 2/5.
--
viresh
--
To unsu
On 12-11-15, 10:38, Viresh Kumar wrote:
> On 11-11-15, 14:31, Rob Herring wrote:
> > > + opp00 {
> >
> > Thought we are doing frequency for unit address here.
>
> That's done by the (Already reviewed) 4th patch..
Ping for the pending Ack :)
--
vire
On 18-11-15, 13:33, Punit Agrawal wrote:
> Thanks for the Ack.
>
> Will you or Rafael be picking up the series or do they need to go via
> arm-soc?
Rafael will pick this up, it should go via PM tree.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body
with all the existing thermal
> governors including the power allocator governor.
>
> A cooling device will be created per individual frequency domain and
> can be bound to thermal zones via the thermal DT bindings.
>
> Signed-off-by: Punit Agrawal
> Cc: Viresh Kumar
> Cc:
t to be used with all the existing thermal
> governors including the power allocator governor.
>
> A cooling device will be created per individual frequency domain and
> can be bound to thermal zones via the thermal DT bindings.
>
> Signed-off-by: Punit Agrawal
> Acked-by: Viresh
the clock frequency (f). The coefficient is used
> to
> + calculate the dynamic power as below -
> +
> + Pdyn = dynamic-power-coefficient * V^2 * f
> +
> + where voltage is in uV, frequency i
On Tue, Nov 17, 2015 at 1:00 AM, Punit Agrawal wrote:
> Hi,
>
> This patchset adds support to build a single-coefficient dynamic power
> model for a CPU. The model is used by the CPU cooling device to
> provide an estimate of power consumption and also translate allocated
> power to performance ca
On 10-11-15, 11:20, Javi Merino wrote:
> The way they are described here is useful only for this platform, but
> it's not generic. It only takes into account voltage as (I assume)
> it's the only variable that affects it in this implementation. A
> generalized version of the static power should t
with all the existing thermal
> governors including the power allocator governor.
>
> A cooling device will be created per individual frequency domain and
> can be bound to thermal zones via the thermal DT bindings.
>
> Signed-off-by: Punit Agrawal
> Acked-by: Viresh Kumar
On 11-11-15, 14:31, Rob Herring wrote:
> > + opp00 {
>
> Thought we are doing frequency for unit address here.
That's done by the (Already reviewed) 4th patch..
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vge
-microvolt-
- opp-microamp-
If the name string isn't provided by the platform, or if it is provided
but doesn't match the properties present in the OPP node, we will fall
back to the original properties without the - string, if they are
available.
Reviewed-by: Stephen Boyd
Signed-off-by: Vi
These aren't used until now by any DT files and wouldn't be used now as
we have a better scheme in place now, i.e. opp-property-
properties.
Remove the (useless) binding without breaking ABI.
Reviewed-by: Stephen Boyd
Acked-by: Rob Herring
Signed-off-by: Viresh Kumar
---
Doc
g the
same opp-hz frequency.
Suggested-by: Stephen Boyd
Reviewed-by: Stephen Boyd
Acked-by: Rob Herring
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/Document
OPP bindings got updated to name OPP nodes this way, make changes
according to that.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Viresh Kumar
---
arch/arm/boot/dts/exynos4412.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm
ed-hw'. It
can support any number of hierarchy levels of the versions the hardware
follows. And based on the selected hardware versions, we can pick only
the relevant OPPs at runtime.
Reviewed-by: Stephen Boyd
Acked-by: Rob Herring
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bi
updates the existing users of
these bindings for it.
V2->V3:
- dropped turbo/suspend named properties
- Applied all the Acks
Viresh Kumar (5):
PM / OPP: Add "opp-supported-hw" binding
PM / OPP: Add {opp-microvolt|opp-microamp}- binding
PM / OPP: Remove 'operating-points-n
On 06-11-15, 07:23, Viresh Kumar wrote:
> Yeah, but in that case 1200 *may* not be a turbo frequency anymore, as
> the voltage constraints might have changed.
>
> So turbo frequency is something that should be used only in small
> bursts, as they are consume lot of power. They aren
Cc'ing Javi (which you should have as he wrote the power-thing for
cpu-cooling).
On 05-11-15, 19:10, dawei chien wrote:
> This is because our platform currently only support mt8173_cpufreq.c, so
> that I only add static power model for our owner IC.
Bindings are (normally) supposed to be general
On 05-11-15, 19:09, dawei chien wrote:
> Thank you for your kindly explaining, now I could understand what I
> miss, I will send device tree binding on next version such like
> following description.
>
> --- a/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt
> +++ b/Documentation/device
On 05-11-15, 17:33, Rob Herring wrote:
> On Wed, Nov 4, 2015 at 9:19 PM, Viresh Kumar wrote:
> > On 04-11-15, 21:02, Rob Herring wrote:
> >> > +- turbo-mode-: Named turbo-mode property. Similar to
> >> > opp-microvolt-
> >> > + property, but f
On 05-11-15, 23:31, Rafael J. Wysocki wrote:
> So this clearly is a new feature and it clearly missed the merge window
> boundary
> for v4.4. I can queue it up for v4.5.
No issues as the relevant code is also going to get merged in 4.5 :)
--
viresh
--
To unsubscribe from this list: send the li
On 04-11-15, 21:02, Rob Herring wrote:
> > +- turbo-mode-: Named turbo-mode property. Similar to
> > opp-microvolt-
> > + property, but for turbo mode instead.
> > +
> > - opp-suspend: Marks the OPP to be used during device suspend. Only one
> > OPP in
> >the table should have this.
> >
>
On 05-11-15, 10:51, Krzysztof Kozlowski wrote:
> I see this patch does not depend on the rest of patchset so I presume
> this can co through samsung-soc?
Yeah, I wouldn't mind that. But I would wait for a confirmation from
Rafael for the bindings first, for an unlikely case where he doesn't
like t
These aren't used until now by any DT files and wouldn't be used now as
we have a better scheme in place now, i.e. opp-property-
properties.
Remove the (useless) binding without breaking ABI.
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bi
g the
same opp-hz frequency.
Suggested-by: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/binding
e original properties without the - string, if they are
available.
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 58 +++
1 file changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Doc
ed-hw'. It
can support any number of hierarchy levels of the versions the hardware
follows. And based on the selected hardware versions, we can pick only
the relevant OPPs at runtime.
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/op
(and then reviewed)
in the earlier series, and the 5th one updates the existing users of
these bindings for it.
Viresh Kumar (5):
PM / OPP: Add "opp-supported-hw" binding
PM / OPP: Add
{opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
PM / OPP: Remove 'operating-points-
OPP bindings got updated to name OPP nodes this way, make changes
according to that.
Signed-off-by: Viresh Kumar
---
arch/arm/boot/dts/exynos4412.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm
ar frequency in
> the same node. Following this style would make dt compilation
> fail if two nodes have the same frequency.
From: Viresh Kumar
Date: Tue, 3 Nov 2015 07:51:09 +0530
Subject: [PATCH] PM / OPP: Rename OPP nodes as opp@
It would be better to name OPP nodes as opp@ as that will en
On 02-11-15, 11:21, Stephen Boyd wrote:
> Ah I see that after looking at the previous thread. Perhaps we
> can add such information into the documentation so that people
> aren't misled into thinking they're limited to 32 bits?
What about these changes:
diff --git a/Documentation/devicetree/bindi
On 02-11-15, 15:53, Punit Agrawal wrote:
> For dynamic power, I had posted some patches[0][1][2] introducing the
> binding as well as updating cooling device registration via cpufreq
> driver. Now that the SCPI hwmon driver is merged, I should re-send the
> remaining patches.
>
> [0] http://lkml.i
On 02-11-15, 09:13, Rob Herring wrote:
> There is no special meaning, just convention which is the unit-address
> should match the reg property address. I'm okay with an exception
> here.
Thanks, I will update this separately.
--
viresh
--
To unsubscribe from this list: send the line "unsubscrib
On 30-10-15, 14:49, Stephen Boyd wrote:
> I suppose if you wanted to have 64 possible combinations of some
> attribute you would just extend it to two 32 bit numbers in
> sequence? I don't see the limitation here, and hopefully there
> isn't a limitation so that we can specify sufficiently large
>
On 02-11-15, 18:46, dawei chien wrote:
> On Wed, 2015-10-28 at 21:14 +0530, Viresh Kumar wrote:
> > Sorry for being extremely late in reviewing this stuff. You are
> > already on v3 and I haven't reviewed it once. Mostly due to bad timing
> > of my holidays and other
On 30-10-15, 12:26, Rob Herring wrote:
> It looks okay to me, but I'll defer to Stephen and Lee as they are the users.
Thanks.
> I'd imagine Rafael will tell you the same thing, but it is too late
> for 4.4 anyway.
Yeah I know, but perhaps Rafael is still going to apply few more
patches and then
On 30-10-15, 15:18, Stephen Boyd wrote:
> A side-note. I wonder if it would be better style to have the
> node name be:
>
> opp@6 {
I thought the @... had a special meaning and we might end up creating
some device for the node then? Perhaps I am mistaken.
But then, yeah it
On 30-10-15, 14:49, Stephen Boyd wrote:
> I suppose if you wanted to have 64 possible combinations of some
> attribute you would just extend it to two 32 bit numbers in
> sequence? I don't see the limitation here, and hopefully there
> isn't a limitation so that we can specify sufficiently large
>
e original properties without the - string, if they are
available.
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 58 +++
1 file changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bi
These aren't used until now by any DT files and wouldn't be used now as
we have a better scheme in place now, i.e. opp-property-
properties.
Remove the (useless) binding without breaking ABI.
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/op
ed-hw'. It
can support any number of hierarchy levels of the versions the hardware
follows. And based on the selected hardware versions, we can pick only
the relevant OPPs at runtime.
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 57 +
h with a better solution.
@Stephen/Rob: I already have working code for these bindings, which I
shared with Lee earlier. Just that I need to rebase that without the
multi-regulator series, will do that in coming days. But please see if
we can get these Acked/merged before that :)
Viresh Kumar (3):
On 22-10-15, 20:02, Dawei Chien wrote:
> Use Intelligent Power Allocation (IPA) technical to add static/dynamic power
> model for binding CPU thermal zone.
> The power allocator governor allocates power budget to control CPU
> temperature.
>
> Power Allocator governor is able to keep SOC tempera
On 22-10-15, 20:02, Dawei Chien wrote:
> Add thermal zone node to mt8173.dtsi.
>
> Signed-off-by: Dawei Chien
> ---
> This patch is base on
> https://patchwork.kernel.org/patch/7249821/
> https://patchwork.kernel.org/patch/7249861/
> https://patchwork.kernel.org/patch/7249891/
> ---
> arch/arm64
On 23-10-15, 01:39, Mark Brown wrote:
> When we start doing this we also start having to worry about things like
> the sequencing of the updates between the various supplies and end up in
> full on power sequencing (or at least baking some sequencing into the DT
> which will doubtless need extendin
On 17-10-15, 09:40, Viresh Kumar wrote:
> Hehe, no.
>
> Okay here is the problem statement:
>
> We have two supplies for a device and the device node will have
> something like:
>
> name1-supply = <&supply1>;
> name2-supply = <&supply2>;
>
>
On 16-10-15, 12:16, Stephen Boyd wrote:
> On 10/16, Viresh Kumar wrote:
> > On 15-10-15, 17:22, Stephen Boyd wrote:
> > > I'm lost why we need this property at all. What happened to using
> > >
> > > opp-microvolt-0 = <1 2 3>;
> > >
On 15-10-15, 17:22, Stephen Boyd wrote:
> I'm lost why we need this property at all. What happened to using
>
> opp-microvolt-0 = <1 2 3>;
> opp-microvolt-1 = <1>;
> opp-microvolt-2 = <3 4 5>;
> etc.
Perhaps you are confusing this with the bindings we came up for
picking right voltage levels
fied
> "wakeup-source" property which inturn fixes the above mentioned issue.
>
> Cc: Heiko Stuebner
> Cc: linux-rockc...@lists.infradead.org
> Cc: Viresh Kumar
> Signed-off-by: Sudeep Holla
> ---
> arch/arm/boot/dts/spear1310-evb.dts | 2 +-
> arch/
Rob,
On 15-09-15, 08:17, Viresh Kumar wrote:
> On 14-09-15, 15:22, Rob Herring wrote:
> > What if we have a 2nd device and supply rail? For example, what if the
> > L2$ has a separate rail from the cores but is linked to the OPPs.
>
> Right, so that is the case with the
On 10-09-15, 09:31, Lee Jones wrote:
> I think you answered your own question.
>
> No users == !ABI == Strip it out.
Okay, as I have delayed things enough for you, didn't wanted to do
that anymore. And so worked on it despite very tight schedule :)
Below is the refreshed binding changes (I have
[+Cc Mark, I thought I cc'd him earlier, but no, I cc'd him only for
the first patch]
On 14-09-15, 15:30, Rob Herring wrote:
> On 09/11/2015 07:01 AM, Viresh Kumar wrote:
> > If 'opp-microvolt' is used to specify values for multiple regulators,
> > then we need
On 14-09-15, 15:22, Rob Herring wrote:
> What if we have a 2nd device and supply rail? For example, what if the
> L2$ has a separate rail from the cores but is linked to the OPPs.
Right, so that is the case with the Mediatek SoC as well, AFAIR. How
do we plan to treat L2 devices? For example, in t
rnel.org
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index 8759bc4783ed..719603b87353 100644
---
y the order in which values must be
present in 'opp-microvolt' and 'opp-microamp' properties.
Cc: Mark Brown
Cc: devicetree@vger.kernel.org
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 26 +++---
1 file changed, 19 in
On 09-09-15, 17:57, Stephen Boyd wrote:
> I think it will work for qcom use cases.
Thanks for the Rant Rob, it finally got me moving :)
> We can collapse the
> tables down to one node and have speed bin and version as the
> opp-supported-hw property. The opp-microvolt-names property would
I am p
On 09-09-15, 14:39, Lee Jones wrote:
> Okay, I see what you mean. Sound fine, although only allows up to 31
> versions. Not an issue for us I don't think, but could be for other
> vendors. Taking a recent example, the kernel recently went up to
> v2.6.39 and some of the stable releases have gone
On 09-09-15, 08:59, Lee Jones wrote:
> Thanks for doing this Viresh. I appreciate your efforts.
I wanted to get this sorted out, before we meet face to face :)
> > -8<-
> > From: Viresh Kumar
> > Date: Wed, 9 Sep 2015 11
is can take care of the complexity
of both Qualcomm and ST Microelectronics SoCs.
@Lee and Stephen: Lemme know if this still wouldn't work :(
-8<-----
From: Viresh Kumar
Date: Wed, 9 Sep 2015 11:47:37 +0530
Subject: [PATCH] PM / OPP: Add "opp-cut
On 04-09-15, 17:01, Dawei Chien wrote:
> Use Intelligent Power Allocation (IPA) technical to add
> static/dynamic power model for binding CPU thermal zone.
> The power allocator governor allocates power budget to control
> CPU temperature.
Sorry but this isn't enough really.. I don't have time to
On 26-08-15, 13:06, Lee Jones wrote:
> On Wed, 12 Aug 2015, Viresh Kumar wrote:
>
> > On 11-08-15, 16:17, Lee Jones wrote:
> > > This would work if we only had a single variable to contend with, but
> > > what I showed you in my previous example is that we have 3 va
On 26-08-15, 09:25, Pi-Cheng Chen wrote:
> The [3/3] is based on Mediatek SoC maintainer tree[1] and the patch which
> introduce a new clock type[2] consumed by MT8173 cpufreq driver. So it will
> cause some conflicts if it goes through your tree. I am not sure how this
> should be handled, but sho
On Tue, Aug 25, 2015 at 8:35 AM, Olof Johansson wrote:
> That's OK, others surely capitalize their platform names too in
> documentation. Some of them even have funkier capitalization than
> that, such as "SPEAr".
That's how the company projected it :(
www.st.com/spear
--
To unsubscribe from thi
s those mechanisms to enable CPU DVFS support for Mediatek
> MT8173 SoC.
>
> Signed-off-by: Pi-Cheng Chen
> Acked-by: Viresh Kumar
> ---
>
> Changes in v7:
> - add of_machine_is_compatible() check to be multiplatform friendly
Looks fine, thanks.
--
viresh
--
To unsubs
On 18-08-15, 12:09, Bartlomiej Zolnierkiewicz wrote:
> > + pdev = platform_device_register_simple("mt8173-cpufreq", -1, NULL, 0);
>
> This is not very friendly for multiplatform support
> (mt8173_cpufreq_driver_init() can be called on other platforms,
> i.e. Samsung Exynos7 one if ARCH_EXYNOS7 i
On 11-08-15, 16:17, Lee Jones wrote:
> This would work if we only had a single variable to contend with, but
> what I showed you in my previous example is that we have 3 variables
> to consider; cut (version), pcode and substrate.
>
> Using the two (simple) examples I provided, how would your sugg
On 11-08-15, 14:27, Lee Jones wrote:
> Okay, so what you're saying is that you've already made the decision
> to create a separate node for every OPP permutation,
Absolutely not.
> despite the fact
> that I've told you this could lead to more nodes than anyone would
> care to successfully write o
On 11-08-15, 12:54, Lee Jones wrote:
> The framework does not need to parse this information. It is used
> solely by the platform driver, whose job it is to decide which OPPs
> are appropriate for the running platform.
The OPP layer needs to parse OPP nodes in DT. But for doing that it
needs to k
On 11-08-15, 10:30, Lee Jones wrote:
> On Tue, 11 Aug 2015, Viresh Kumar wrote:
>
> > On 10-08-15, 14:22, Lee Jones wrote:
> > > > Optional properties:
> > > > +- opp-cuts: One or more strings, describing the versions of hardware
> > > > the OPPs
On 10-08-15, 14:22, Lee Jones wrote:
> > Optional properties:
> > +- opp-cuts: One or more strings, describing the versions of hardware the
> > OPPs
> > + can support.
>
> This isn't very generic.
>
> I'm guessing some vendors my have quite a few ways to differentiate
> between board versions/
On 31-07-15, 09:37, Stephen Boyd wrote:
> 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
> characteri
On 9 July 2015 at 15:57, Pi-Cheng Chen wrote:
> MT8173 is a ARMv8 based SoC with 2 clusters. All CPUs in a single cluster
> share the same power and clock domain. This series tries to add cpufreq
> support
> for MT8173 SoC.
>
> changes in v6:
> - Move clock and regulator consumer properties docum
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.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicet
More platform specific extended opp bindings will follow and it would be
easy to manage them with a directory for opp. Lets create that and move
the existing opp bindings into it.
Signed-off-by: Viresh Kumar
---
Resending to get cc list fixed, which isn't getting populated due to a
bug
1 - 100 of 314 matches
Mail list logo
