Hi Mark, On Fri, Nov 16, 2012 at 7:35 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > Given there are several ARM platforms that may have an interest in this, please > consider posting this to the ARM mailing list: > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx. That's right. New revision on the way. >> +Similarly, each power sequence declares its steps as sub-nodes of itself. Steps >> +must be named sequentially, with the first step named step0, the second step1, >> +etc. Failure to follow this rule will result in a parsing error. > > Could we not encode the step number in the unit-address? i.e. step@N rather than > stepN. That was the way I did it initially, but it has been pointed out that doing so would require to have #address-cells and #size-cells in every power sequence, as well as a "reg" property in every step (see https://lkml.org/lkml/2012/7/31/454 ). Although I'd prefer to use the @ notation too (and neither dtc nor the kernel complained when I did it), I tend to think the current solution is less burdensome than having these redundant properties. >> +"gpio" type required properties: >> + - gpio: phandle of the GPIO to use. >> + - value: value this GPIO should take. Must be 0 or 1. > > Is there any reason for id to be a name rather than a phandle? It seems > inconsistent with the gpio case. That's another long story. But to make it short, I'd like to make it possible for power sequences to be referenced and shared between devices of the same type (as everybody knows, copy/pasting is bad). If we use phandles in steps, the power sequence becomes tied to the referred resources and thus cannot be shared with another instance of the same device. On the other hand, using an identifier that is resolved at runtime (through e.g. regulator_get(device *, char *) leverages the existing frameworks and makes things more flexible. GPIO is currently the exception. It is the only framework for which you cannot currently resolve a resource from a device and an identifier. So at the moment we have to use a phandle - but we are also working with Linus Walleij to provide an alternative GPIO API that will be more like what we have for regulators/pinctrl/PWM/etc. Another problem with phandles is that some of the functions that resolve them are not publicly exported (i.e. AFAIK there is no public function that returns a regulator from a phandle - the only to obtain one is through regulator_get) > I also see from the example below that the gpio property is not just a phandle, > as it has the gpio-specifier appended. Is there a better way of describing this > format in the documentation? This is already clearly be defined in Documentation/devicetree/bindings/gpio/, isn't it? Thanks, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
