Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1260903 > unrolled thread

Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding Stephen Boyd <sboyd@codeaurora.org> - 2015-11-02 20:30 +0100
    Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding Viresh Kumar <viresh.kumar@linaro.org> - 2015-11-03 03:20 +0100
      Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding Stephen Boyd <sboyd@codeaurora.org> - 2015-11-04 23:20 +0100

#1260903 — Re: [PATCH 1/3] PM / OPP: Add "opp-supported-hw" binding

On 10/31, Viresh Kumar wrote:
> 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
> > numbers with more bits if we need to.
> 
> Yeah, we discussed this earlier when Lee had the same query and I
> suggested the exact same thing to him then.
> 

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?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1261157

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/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index 96892057586a..b6ca2239838b 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -123,11 +123,15 @@ properties.
 - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
   the table should have this.
 
-- opp-supported-hw: User defined array containing a hierarchy of hardware
-  version numbers, supported by the OPP. For example: a platform with hierarchy
-  of three levels of versions (A, B and C), this field should be like <X Y Z>,
-  where X corresponds to Version hierarchy A, Y corresponds to version hierarchy
-  B and Z corresponds to version hierarchy C.
+- opp-supported-hw: This enables us to select only a subset of OPPs from the
+  larger OPP table, based on what version of the hardware we are running on. We
+  still can't have multiple nodes with the same opp-hz value in OPP table.
+
+  Its an user defined array containing a hierarchy of hardware version numbers,
+  supported by the OPP. For example: a platform with hierarchy of three levels
+  of versions (A, B and C), this field should be like <X Y Z>, where X
+  corresponds to Version hierarchy A, Y corresponds to version hierarchy B and Z
+  corresponds to version hierarchy C.
 
   Each level of hierarchy is represented by a 32 bit value, and so there can be
   only 32 different supported version per hierarchy. i.e. 1 bit per version. A
@@ -135,6 +139,10 @@ properties.
   level. And a value of 0x00000000 will disable the OPP completely, and so we
   never want that to happen.
 
+  If 32 values aren't sufficient for a version hierarchy, than that version
+  hierarchy can be contained in multiple 32 bit values. i.e. <X Y Z1 Z2> in the
+  above example, Z1 & Z2 refer to the version hierarchy Z.
+
 - status: Marks the node enabled/disabled.
 


-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1262641

On 11/03, Viresh Kumar wrote:
> 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:

Yep looks good. Assuming this is squashed into the original:

Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>

One typo below.

> 
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 96892057586a..b6ca2239838b 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -123,11 +123,15 @@ properties.
>  - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
>    the table should have this.
>  
> -- opp-supported-hw: User defined array containing a hierarchy of hardware
> -  version numbers, supported by the OPP. For example: a platform with hierarchy
> -  of three levels of versions (A, B and C), this field should be like <X Y Z>,
> -  where X corresponds to Version hierarchy A, Y corresponds to version hierarchy
> -  B and Z corresponds to version hierarchy C.
> +- opp-supported-hw: This enables us to select only a subset of OPPs from the
> +  larger OPP table, based on what version of the hardware we are running on. We
> +  still can't have multiple nodes with the same opp-hz value in OPP table.
> +
> +  Its an user defined array containing a hierarchy of hardware version numbers,

s/Its/It's/

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web