| Message ID | 20161102104010.26959-6-andi.shyti@samsung.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
Hi Andi, Only DT bindings of LED class drivers should be placed in Documentation/devicetree/bindings/leds. Please move it to the media bindings. Thanks, Jacek Anaszewski On 11/02/2016 11:40 AM, Andi Shyti wrote: > Document the ir-spi driver's binding which is a IR led driven > through the SPI line. > > Signed-off-by: Andi Shyti <andi.shyti@samsung.com> > --- > .../devicetree/bindings/leds/spi-ir-led.txt | 29 ++++++++++++++++++++++ > 1 file changed, 29 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/spi-ir-led.txt > > diff --git a/Documentation/devicetree/bindings/leds/spi-ir-led.txt b/Documentation/devicetree/bindings/leds/spi-ir-led.txt > new file mode 100644 > index 0000000..896b699 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/spi-ir-led.txt > @@ -0,0 +1,29 @@ > +Device tree bindings for IR LED connected through SPI bus which is used as > +remote controller. > + > +The IR LED switch is connected to the MOSI line of the SPI device and the data > +are delivered thourgh that. > + > +Required properties: > + - compatible: should be "ir-spi-led". > + > +Optional properties: > + - duty-cycle: 8 bit balue that represents the percentage of one period > + in which the signal is active. It can be 50, 60, 70, 75, 80 or 90. > + - led-active-low: boolean value that specifies whether the output is > + negated with a NOT gate. > + - power-supply: specifies the power source. It can either be a regulator > + or a gpio which enables a regulator, i.e. a regulator-fixed as > + described in > + Documentation/devicetree/bindings/regulator/fixed-regulator.txt > + > +Example: > + > + irled@0 { > + compatible = "ir-spi-led"; > + reg = <0x0>; > + spi-max-frequency = <5000000>; > + power-supply = <&vdd_led>; > + led-active-low; > + duty-cycle = /bits/ 8 <60>; > + }; > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Jacek, > Only DT bindings of LED class drivers should be placed in > Documentation/devicetree/bindings/leds. Please move it to the > media bindings. that's where I placed it first, but Rob asked me to put it in the LED directory and Cc the LED mailining list. That's the discussion of the version 2: https://lkml.org/lkml/2016/9/12/380 Rob, Jacek, could you please agree where I can put the binding? Thanks, Andi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/03/2016 11:10 AM, Andi Shyti wrote: > Hi Jacek, > >> Only DT bindings of LED class drivers should be placed in >> Documentation/devicetree/bindings/leds. Please move it to the >> media bindings. > > that's where I placed it first, but Rob asked me to put it in the > LED directory and Cc the LED mailining list. > > That's the discussion of the version 2: > > https://lkml.org/lkml/2016/9/12/380 > > Rob, Jacek, could you please agree where I can put the binding? I'm not sure if this is a good approach. I've noticed also that backlight bindings have been moved to leds, whereas they don't look similarly. We have common.txt LED bindings, that all LED class drivers' bindings have to follow. Neither backlight bindings nor these ones do that, which introduces some mess. Eventually adding a sub-directory, e.g. remote_control could make it somehow logically justified, but still - shouldn't bindings be placed in the documentation directory related to the subsystem of the driver they are predestined to?
Hi Jacek, > > > Only DT bindings of LED class drivers should be placed in > > > Documentation/devicetree/bindings/leds. Please move it to the > > > media bindings. > > > > that's where I placed it first, but Rob asked me to put it in the > > LED directory and Cc the LED mailining list. > > > > That's the discussion of the version 2: > > > > https://lkml.org/lkml/2016/9/12/380 > > > > Rob, Jacek, could you please agree where I can put the binding? > > I'm not sure if this is a good approach. I've noticed also that > backlight bindings have been moved to leds, whereas they don't look > similarly. > > We have common.txt LED bindings, that all LED class drivers' bindings > have to follow. Neither backlight bindings nor these ones do that, > which introduces some mess. > > Eventually adding a sub-directory, e.g. remote_control could make it > somehow logically justified, but still - shouldn't bindings be > placed in the documentation directory related to the subsystem of the > driver they are predestined to? In principle I agree with you, also because I understood that the led kind of bindings are for those LEDs which main function is to emit light. There is no need for a remote control directory, because there is one already under bindings/media, where all the remote controllers are placed. Now this is a matter of interpretation, is this an IR LED used by the driver as remote controller or is this a remote controller with just an IR LED? In any case, I will wait for you and Rob to agree where is best to place the binding, then I will send a new version. Thanks, Andi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote: > On 11/03/2016 11:10 AM, Andi Shyti wrote: > > Hi Jacek, > > > > > Only DT bindings of LED class drivers should be placed in > > > Documentation/devicetree/bindings/leds. Please move it to the > > > media bindings. > > > > that's where I placed it first, but Rob asked me to put it in the > > LED directory and Cc the LED mailining list. > > > > That's the discussion of the version 2: > > > > https://lkml.org/lkml/2016/9/12/380 > > > > Rob, Jacek, could you please agree where I can put the binding? > > I'm not sure if this is a good approach. I've noticed also that > backlight bindings have been moved to leds, whereas they don't look > similarly. > > We have common.txt LED bindings, that all LED class drivers' bindings > have to follow. Neither backlight bindings nor these ones do that, > which introduces some mess. And there are probably LED bindings that don't follow common.txt either. > Eventually adding a sub-directory, e.g. remote_control could make it > somehow logically justified, but still - shouldn't bindings be > placed in the documentation directory related to the subsystem of the > driver they are predestined to? No. While binding directories often mirror the driver directories, they are not the same. Bindings are grouped by types of h/w and IR LEDs are a type of LED. If you prefer a sub-dir, that is fine with me. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/09/2016 07:26 PM, Rob Herring wrote: > On Thu, Nov 03, 2016 at 11:39:21AM +0100, Jacek Anaszewski wrote: >> On 11/03/2016 11:10 AM, Andi Shyti wrote: >>> Hi Jacek, >>> >>>> Only DT bindings of LED class drivers should be placed in >>>> Documentation/devicetree/bindings/leds. Please move it to the >>>> media bindings. >>> >>> that's where I placed it first, but Rob asked me to put it in the >>> LED directory and Cc the LED mailining list. >>> >>> That's the discussion of the version 2: >>> >>> https://lkml.org/lkml/2016/9/12/380 >>> >>> Rob, Jacek, could you please agree where I can put the binding? >> >> I'm not sure if this is a good approach. I've noticed also that >> backlight bindings have been moved to leds, whereas they don't look >> similarly. >> >> We have common.txt LED bindings, that all LED class drivers' bindings >> have to follow. Neither backlight bindings nor these ones do that, >> which introduces some mess. > > And there are probably LED bindings that don't follow common.txt either. > >> Eventually adding a sub-directory, e.g. remote_control could make it >> somehow logically justified, but still - shouldn't bindings be >> placed in the documentation directory related to the subsystem of the >> driver they are predestined to? > > No. While binding directories often mirror the driver directories, they > are not the same. Bindings are grouped by types of h/w and IR LEDs are a > type of LED. > > If you prefer a sub-dir, that is fine with me. Fine. So how about sub-dir "ir" ?
Hi Jacek, > > > > > Only DT bindings of LED class drivers should be placed in > > > > > Documentation/devicetree/bindings/leds. Please move it to the > > > > > media bindings. > > > > > > > > that's where I placed it first, but Rob asked me to put it in the > > > > LED directory and Cc the LED mailining list. > > > > > > > > That's the discussion of the version 2: > > > > > > > > https://lkml.org/lkml/2016/9/12/380 > > > > > > > > Rob, Jacek, could you please agree where I can put the binding? > > > > > > I'm not sure if this is a good approach. I've noticed also that > > > backlight bindings have been moved to leds, whereas they don't look > > > similarly. > > > > > > We have common.txt LED bindings, that all LED class drivers' bindings > > > have to follow. Neither backlight bindings nor these ones do that, > > > which introduces some mess. > > > > And there are probably LED bindings that don't follow common.txt either. > > > > > Eventually adding a sub-directory, e.g. remote_control could make it > > > somehow logically justified, but still - shouldn't bindings be > > > placed in the documentation directory related to the subsystem of the > > > driver they are predestined to? > > > > No. While binding directories often mirror the driver directories, they > > are not the same. Bindings are grouped by types of h/w and IR LEDs are a > > type of LED. > > > > If you prefer a sub-dir, that is fine with me. > > Fine. So how about sub-dir "ir" ? would we put here all the remote control bindings that currently are under media? Thanks, Andi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 10, 2016 at 4:02 AM, Andi Shyti <andi.shyti@samsung.com> wrote: > Hi Jacek, > >> > > > > Only DT bindings of LED class drivers should be placed in >> > > > > Documentation/devicetree/bindings/leds. Please move it to the >> > > > > media bindings. >> > > > >> > > > that's where I placed it first, but Rob asked me to put it in the >> > > > LED directory and Cc the LED mailining list. >> > > > >> > > > That's the discussion of the version 2: >> > > > >> > > > https://lkml.org/lkml/2016/9/12/380 >> > > > >> > > > Rob, Jacek, could you please agree where I can put the binding? >> > > >> > > I'm not sure if this is a good approach. I've noticed also that >> > > backlight bindings have been moved to leds, whereas they don't look >> > > similarly. >> > > >> > > We have common.txt LED bindings, that all LED class drivers' bindings >> > > have to follow. Neither backlight bindings nor these ones do that, >> > > which introduces some mess. >> > >> > And there are probably LED bindings that don't follow common.txt either. >> > >> > > Eventually adding a sub-directory, e.g. remote_control could make it >> > > somehow logically justified, but still - shouldn't bindings be >> > > placed in the documentation directory related to the subsystem of the >> > > driver they are predestined to? >> > >> > No. While binding directories often mirror the driver directories, they >> > are not the same. Bindings are grouped by types of h/w and IR LEDs are a >> > type of LED. >> > >> > If you prefer a sub-dir, that is fine with me. >> >> Fine. So how about sub-dir "ir" ? > > would we put here all the remote control bindings that currently > are under media? No. Only if they are just an LED that happens to be IR. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/leds/spi-ir-led.txt b/Documentation/devicetree/bindings/leds/spi-ir-led.txt new file mode 100644 index 0000000..896b699 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/spi-ir-led.txt @@ -0,0 +1,29 @@ +Device tree bindings for IR LED connected through SPI bus which is used as +remote controller. + +The IR LED switch is connected to the MOSI line of the SPI device and the data +are delivered thourgh that. + +Required properties: + - compatible: should be "ir-spi-led". + +Optional properties: + - duty-cycle: 8 bit balue that represents the percentage of one period + in which the signal is active. It can be 50, 60, 70, 75, 80 or 90. + - led-active-low: boolean value that specifies whether the output is + negated with a NOT gate. + - power-supply: specifies the power source. It can either be a regulator + or a gpio which enables a regulator, i.e. a regulator-fixed as + described in + Documentation/devicetree/bindings/regulator/fixed-regulator.txt + +Example: + + irled@0 { + compatible = "ir-spi-led"; + reg = <0x0>; + spi-max-frequency = <5000000>; + power-supply = <&vdd_led>; + led-active-low; + duty-cycle = /bits/ 8 <60>; + };
Document the ir-spi driver's binding which is a IR led driven through the SPI line. Signed-off-by: Andi Shyti <andi.shyti@samsung.com> --- .../devicetree/bindings/leds/spi-ir-led.txt | 29 ++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/spi-ir-led.txt