On Thu, Jan 15, 2015 at 6:33 AM, Sylwester Nawrocki
[off-list ref] wrote:

On 12/01/15 18:06, Mark Brown wrote:

quoted

On Mon, Jan 12, 2015 at 10:55:29AM -0600, Rob Herring wrote:

quoted

quoted

On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski

quoted

quoted

There are however devices that don't fall into this category, i.e. they
have many outputs, that can be connected to a single LED or to many LEDs
and the driver has to know what is the actual arrangement.

We may need to extend the regulator binding slightly and allow for
multiple phandles on a supply property, but wouldn't something like
this work:
led-supply = <&led-reg0>, <&led-reg1>, <&led-reg2>, <&led-reg3>;
The shared source is already supported by the regulator binding.

What is the reasoning for this?  If a single supply is being supplied by
multiple regulators then in general those regulators will all know about
each other at a hardware level and so from a functional and software
point of view will effectively be one regulator.  If they don't/aren't
then they tend to interfere with each other.

For LED current regulators like this one [1] we want to be able to
communicate to the software the hardware wiring, e.g. if a single LED is
connected to only one or both the current regulators.  The device needs
to be programmed differently for each configuration, as shown on page 36
of the datasheet [2].

Now, the LED DT binding describes the LEDs (current consumers) as child
nodes of the LED driver IC (current supplier), e.g. (from [3]):

pca9632@62 {
        compatible = "nxp,pca9632";
        #address-cells = <1>;
        #size-cells = <0>;
        reg = <0x62>;

        red@0 {
                label = "red";
                reg = <0>;

This only works if you don't have sub blocks or different functions to
describe. I suppose you could add yet another level of nodes. This
feels like abuse of the reg property even though to use the reg
property is a frequent review comment.

OTOH, we don't need 2 ways to describe this.

                linux,default-trigger = "none";
        };
        green@1 {
                label = "green";
                reg = <1>;
                linux,default-trigger = "none";
        };
        ...
};

What is missing in this binding is the ability to tell that a single LED
is connected to more than one current source.

We could, for example adopt the multiple phandle in the supply property
scheme, but not use the kernel regulator API, e.g.

flash-led {
         compatible = "maxim,max77387";

         current-reg1 { // FLED1
                 led-output-id = <0>;
         };

         current-reg2 { // FLED2
                 led-output-id = <1>;
         };

         red_led {
                 led-supply = <&current-reg1>, <&current-reg2>;
         };
};

However my feeling is that it is unnecessarily complicated that way.

This example is not so complicated, but I already agreed on not using
regulators on the basis there are other properties of the driver
unique to LEDs.

Perhaps we could use the 'reg' property to describe actual connections,
I'm not sure if it's better than a LED specific property, e.g.

max77387@52 {
        compatible = "nxp,max77387";
        #address-cells = <2>;
        #size-cells = <0>;
        reg = <0x52>;

        flash_led {
                reg = <1 1>;

Don't you mean <0 1> as the values are the "address" which in this
case are the LED driver output indexes.

Rob

                ...
        };
};

[1] http://www.maximintegrated.com/en/products/power/led-drivers/MAX77387.html
[2] http://datasheets.maximintegrated.com/en/ds/MAX77387.pdf
[3] Documentation/devicetree/bindings/leds/pca963x.txt