diff mbox

[v3,5/6] Documentation: bindings: add documentation for ir-spi device driver

Message ID 20161102104010.26959-6-andi.shyti@samsung.com (mailing list archive)
State New, archived
Headers show

Commit Message

Andi Shyti Nov. 2, 2016, 10:40 a.m. UTC
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

Comments

Jacek Anaszewski Nov. 3, 2016, 8:32 a.m. UTC | #1
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 linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andi Shyti Nov. 3, 2016, 10:10 a.m. UTC | #2
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 linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jacek Anaszewski Nov. 3, 2016, 10:39 a.m. UTC | #3
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?
Andi Shyti Nov. 4, 2016, 4:28 a.m. UTC | #4
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 linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring (Arm) Nov. 9, 2016, 6:26 p.m. UTC | #5
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 linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jacek Anaszewski Nov. 10, 2016, 7:46 a.m. UTC | #6
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" ?
Andi Shyti Nov. 10, 2016, 10:02 a.m. UTC | #7
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 linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rob Herring (Arm) Nov. 14, 2016, 4:10 p.m. UTC | #8
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 linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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>;
+	};