Thread (63 messages) 63 messages, 11 authors, 2012-08-07

Re: [RFC][PATCH v3 1/3] runtime interpreted power sequences

From: Alex Courbot <acourbot@nvidia.com>
Date: 2012-08-06 02:26:03
Also in: linux-devicetree, linux-tegra, lkml

On 08/04/2012 11:12 PM, Mark Brown wrote:
On Fri, Aug 03, 2012 at 10:15:46AM +0900, Alex Courbot wrote:
quoted
On Fri 03 Aug 2012 03:11:12 AM JST, Mark Brown wrote:
quoted
quoted
I missed some of the earlier bits of the thread here but why can't we do
device based lookups?
quoted
That is because the phandles would not be properties of the device
node but rather of its sub-nodes:
quoted
backlight {
     compatible = "pwm-backlight";
     ...
     power-on-sequence {
         step@0 {
             regulator = <&backlight_reg>;
             enable;
         };
quoted
So here simply using regulator_get on the backlight device would not work.
Ah, right.  DT isn't being terribly helpful here...  I think the thing
I'd expect to work here is that you have a reference back to the supply
property of the backlight device rather than direct to the regulator so
you end up writing "enable supply X" rather than "enable regulator X".

Not quite sure how exactly you'd accomplish that - I guess if
regulator_get() would recursively follow phandles until it hits a node
that'd do the trick?
Do you mean that regulator_get() would parse sub-nodes looking for a 
match? That seems rather dangerous and error-prone, especially if one 
has actual devices within the sub-nodes - their regulators could be 
stolen by the parent device.

I think we only have two choices for this:

1) Stick to the scheme where resources are declared at the device level, 
such as they can be referenced by name in the sub-nodes (basically what 
I did in this patch):

backlight {
      compatible = "pwm-backlight";
      ...
      backlight-supply = <&backlight_reg>;

      power-on-sequence {
          step@0 {
              regulator = "backlight";
              enable;
          };

This would translate by a get_regulator(dev, "backlight") in the code 
which would be properly resolved.

2) Export a lower-level DT API for resolving phandles directly from a 
property, similar to of_get_named_gpio. We would then have 
of_get_named_regulator and of_get_named_pwm.

If 2) is deemed acceptable, then I think we should go for it as it would 
provide the most compact and readable DT syntax. Otherwise 1) is still 
acceptable IMHO, as it should at least make sense to people already 
familiar with how the DT works.

Opinions from DT experts?

Alex.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help