[PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property

[PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property

[Jacek Anaszewski]

This patch adds a description of 'flashes' property
to the samsung-fimc.txt.

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: <devicetree@vger.kernel.org>
---
 .../devicetree/bindings/media/samsung-fimc.txt     |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 922d6f8..4b7ed03 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated
 and the port B deactivated and for the state "active-b" it should be the other
 way around.
 
+Optional properties:
+
+- flashes - array of strings with flash led names; the name has to
+	    be same with the related led label
+	    (see Documentation/devicetree/bindings/leds/common.txt)
+
 The 'camera' node must include at least one 'fimc' child node.
 
 
@@ -166,6 +172,7 @@ Example:
 		clock-output-names = "cam_a_clkout", "cam_b_clkout";
 		pinctrl-names = "default";
 		pinctrl-0 = <&cam_port_a_clk_active>;
+		flashes = "max77693-flash1", "max77693-flash2";
 		status = "okay";
 		#address-cells = <1>;
 		#size-cells = <1>;
-- 
1.7.9.5

[PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693

[Jacek Anaszewski]

This patch adds device tree binding documentation for
the flash cell of the Maxim max77693 multifunctional device.

Signed-off-by: Jacek Anaszewski <j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Acked-by: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: SangYoung Son <hello.son-T5JinQjy6aBBDgjK7y7TUQ@public.gmane.org>
Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Bryan Wu <cooloney-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Richard Purdie <rpurdie-Fm38FmjxZ/leoWH0uzbU5w@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
---
 Documentation/devicetree/bindings/mfd/max77693.txt |   74 ++++++++++++++++++++
 1 file changed, 74 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt
index 01e9f30..50a8dad 100644
--- a/Documentation/devicetree/bindings/mfd/max77693.txt
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -41,6 +41,62 @@ Optional properties:
 	 To get more informations, please refer to documentaion.
 	[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
 
+- led-flash : the LED submodule device node
+
+There are two led outputs available - fled1 and fled2. Each of them can
+control a separate led or they can be connected together to double
+the maximum current for a single connected led. One led is represented
+by one child node.
+
+Required properties:
+- compatible : must be "maxim,max77693-flash"
+
+Optional properties:
+- maxim,fleds : array of current outputs in order: fled1, fled2
+	Note: both current outputs can be connected to a single led
+	Possible values:
+		0 - the output is left disconnected,
+		1 - a diode is connected to the output.
+- maxim,trigger-type : Array of trigger types in order: flash, torch
+	Possible trigger types:
+		0 - Rising edge of the signal triggers the flash/torch,
+		1 - Signal level controls duration of the flash/torch.
+- maxim,trigger : Array of flags indicating which trigger can activate given led
+	in order: fled1, fled2
+	Possible flag values (can be combined):
+		1 - FLASH pin of the chip,
+		2 - TORCH pin of the chip,
+		4 - software via I2C command.
+- maxim,boost-mode :
+	In boost mode the device can produce up to 1.2A of total current
+	on both outputs. The maximum current on each output is reduced
+	to 625mA then. If there are two child led nodes defined then boost
+	is enabled by default.
+	Possible values:
+		0 - no boost,
+		1 - adaptive mode,
+		2 - fixed mode.
+- maxim,boost-vout : Output voltage of the boost module in millivolts.
+- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired
+	if chip estimates that system voltage could drop below this level due
+	to flash power consumption.
+
+A child node must be defined per sub-led.
+
+Required properties of the LED child node:
+- label : see Documentation/devicetree/bindings/leds/common.txt
+- maxim,fled_id : identifier of the fled output the led is connected to:
+		1 - FLED1,
+		2 - FLED2.
+
+Optional properties of the LED child node:
+- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+		Range: 15625 - 250000
+- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
+		Range: 15625 - 1000000
+- flash-timeout-microsec : see Documentation/devicetree/bindings/leds/common.txt
+		Range: 62500 - 1000000
+
 Example:
 	max77693@66 {
 		compatible = "maxim,max77693";
@@ -73,4 +129,22 @@ Example:
 			pwms = <&pwm 0 40000 0>;
 			pwm-names = "haptic";
 		};
+
+		led_flash: led-flash {
+			compatible = "maxim,max77693-flash";
+			maxim,fleds = <1 0>;
+			maxim,trigger = <7 0>;
+			maxim,trigger-type = <0 1>;
+			maxim,boost-mode = <0>;
+			maxim,boost-vout = <5000>;
+			maxim,vsys-min = <2400>;
+
+			camera-flash {
+				maxim,fled_id = <1>
+				label = "max77693-flash";
+				max-microamp = <250000>;
+				flash-max-microamp = <1000000>;
+				flash-timeout-microsec = <1000000>;
+			}
+		};
 	};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH/RFC v8 13/14] of: Add Skyworks Solutions, Inc. vendor prefix

[Jacek Anaszewski]

Use "skyworks" as the vendor prefix for the
Skyworks Solutions, Inc.

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: <devicetree@vger.kernel.org>
---
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index c177cd7..3006825 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -137,6 +137,7 @@ ricoh	Ricoh Co. Ltd.
 rockchip	Fuzhou Rockchip Electronics Co., Ltd
 samsung	Samsung Semiconductor
 sandisk	Sandisk Corporation
+skyworks	Skyworks Solutions, Inc.
 sbs	Smart Battery System
 schindler	Schindler
 seagate	Seagate Technology PLC
-- 
1.7.9.5

[PATCH/RFC v8 14/14] DT: Add documentation for the Skyworks AAT1290

[Jacek Anaszewski]

This patch adds device tree binding documentation for
1.5A Step-Up Current Regulator for Flash LEDs.

Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: <devicetree@vger.kernel.org>
---
 .../devicetree/bindings/leds/leds-aat1290.txt      |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-aat1290.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-aat1290.txt b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
new file mode 100644
index 0000000..8f001dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
@@ -0,0 +1,17 @@
+* Skyworks Solutions, Inc. AAT1290 Current Regulator for Flash LEDs
+
+Required properties:
+
+- compatible : should be "skyworks,aat1290"
+- gpios : two gpio pins in order FLEN, EN/SET
+- flash-timeout-microsec : maximum flash timeout in microseconds -
+			   it can be calculated using following formula:
+			   T = 8.82 * 10^9 * Ct
+
+Example:
+
+flash_led: flash-led {
+	compatible = "skyworks,aat1290";
+	gpios = <&gpj1 1 0>, <&gpj1 2 0>;
+	flash-timeout-microsec = <1940000>;
+}
-- 
1.7.9.5

Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property

[Mark Rutland]

On Fri, Nov 28, 2014 at 09:18:00AM +0000, Jacek Anaszewski wrote:
> This patch adds a description of 'flashes' property
> to the samsung-fimc.txt.
> 
> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: <devicetree@vger.kernel.org>
> ---
>  .../devicetree/bindings/media/samsung-fimc.txt     |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> index 922d6f8..4b7ed03 100644
> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated
>  and the port B deactivated and for the state "active-b" it should be the other
>  way around.
>  
> +Optional properties:
> +
> +- flashes - array of strings with flash led names; the name has to
> +	    be same with the related led label
> +	    (see Documentation/devicetree/bindings/leds/common.txt)
> +

Why is this not an array of phandles to the LED nodes? That's much
better than strings.

Also, I only seem to have recevied the documentation patches and none of
the code -- in future when posting RFC DT patches, please Cc for the
code too as it's useful context.

Mark.

>  The 'camera' node must include at least one 'fimc' child node.
>  
>  
> @@ -166,6 +172,7 @@ Example:
>  		clock-output-names = "cam_a_clkout", "cam_b_clkout";
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&cam_port_a_clk_active>;
> +		flashes = "max77693-flash1", "max77693-flash2";
>  		status = "okay";
>  		#address-cells = <1>;
>  		#size-cells = <1>;
> -- 
> 1.7.9.5
> 
> --
> 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
> 

Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property

[Jacek Anaszewski]

On 11/28/2014 12:14 PM, Mark Rutland wrote:
> On Fri, Nov 28, 2014 at 09:18:00AM +0000, Jacek Anaszewski wrote:
>> This patch adds a description of 'flashes' property
>> to the samsung-fimc.txt.
>>
>> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>> Cc: Kumar Gala <galak@codeaurora.org>
>> Cc: <devicetree@vger.kernel.org>
>> ---
>>   .../devicetree/bindings/media/samsung-fimc.txt     |    7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
>> index 922d6f8..4b7ed03 100644
>> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
>> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
>> @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated
>>   and the port B deactivated and for the state "active-b" it should be the other
>>   way around.
>>
>> +Optional properties:
>> +
>> +- flashes - array of strings with flash led names; the name has to
>> +	    be same with the related led label
>> +	    (see Documentation/devicetree/bindings/leds/common.txt)
>> +
>
> Why is this not an array of phandles to the LED nodes? That's much
> better than strings.

This is because a single flash led device can control many sub-leds,
which are represented by child nodes in the Device Tree.
Every sub-led is registered as a separate LED Flash class device
in the LED subsystem, but in fact they share the same struct device
and thus have access only to the parent's phandle. The LED Flash
class devices are wrapped by V4L2 sub-devices and register
asynchronously within a media device. Since the v4l2_subdev structure
has a 'name' field, it is convenient to initialize it with
parsed 'label' property of a child led node and match the
sub-devices in the media device basing on it.

> Also, I only seem to have recevied the documentation patches and none of
> the code -- in future when posting RFC DT patches, please Cc for the
> code too as it's useful context.

Of course, I'll keep it in mind.

Regards,
Jacek

Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property

[Mark Rutland]

On Fri, Nov 28, 2014 at 12:09:14PM +0000, Jacek Anaszewski wrote:
> On 11/28/2014 12:14 PM, Mark Rutland wrote:
> > On Fri, Nov 28, 2014 at 09:18:00AM +0000, Jacek Anaszewski wrote:
> >> This patch adds a description of 'flashes' property
> >> to the samsung-fimc.txt.
> >>
> >> Signed-off-by: Jacek Anaszewski <j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >> Acked-by: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >> Cc: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> >> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> >> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> >> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> >> ---
> >>   .../devicetree/bindings/media/samsung-fimc.txt     |    7 +++++++
> >>   1 file changed, 7 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >> index 922d6f8..4b7ed03 100644
> >> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >> @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated
> >>   and the port B deactivated and for the state "active-b" it should be the other
> >>   way around.
> >>
> >> +Optional properties:
> >> +
> >> +- flashes - array of strings with flash led names; the name has to
> >> +	    be same with the related led label
> >> +	    (see Documentation/devicetree/bindings/leds/common.txt)
> >> +
> >
> > Why is this not an array of phandles to the LED nodes? That's much
> > better than strings.
> 
> This is because a single flash led device can control many sub-leds,
> which are represented by child nodes in the Device Tree.
> Every sub-led is registered as a separate LED Flash class device
> in the LED subsystem, but in fact they share the same struct device
> and thus have access only to the parent's phandle.

But that's a Linux infrastrcture issue, no? You don't have to use the
node from the struct device to find the relevant phandle.

> The LED Flash
> class devices are wrapped by V4L2 sub-devices and register
> asynchronously within a media device. Since the v4l2_subdev structure
> has a 'name' field, it is convenient to initialize it with
> parsed 'label' property of a child led node and match the
> sub-devices in the media device basing on it.

While that might be convenient, I don't think it's fantastic to use that
to describe the relationship, as this leaks Linux internals (e.g. I can
refer to a name that doesn't exist in the DT but happens to be what
Linux used, and it would work). Also, are the labels guaranteed to be
globally unique?

Using phandles is much better for the binding. I appreciate that this
may require more code, but IMO it's worth that for the safety and
uniformity given by the use of phandles for referring to nodes.

> > Also, I only seem to have recevied the documentation patches and none of
> > the code -- in future when posting RFC DT patches, please Cc for the
> > code too as it's useful context.
> 
> Of course, I'll keep it in mind.

Thanks!

Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property

[Jacek Anaszewski]

On 11/28/2014 01:30 PM, Mark Rutland wrote:
> On Fri, Nov 28, 2014 at 12:09:14PM +0000, Jacek Anaszewski wrote:
>> On 11/28/2014 12:14 PM, Mark Rutland wrote:
>>> On Fri, Nov 28, 2014 at 09:18:00AM +0000, Jacek Anaszewski wrote:
>>>> This patch adds a description of 'flashes' property
>>>> to the samsung-fimc.txt.
>>>>
>>>> Signed-off-by: Jacek Anaszewski <j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>> Acked-by: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>> Cc: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>>>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>>> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>>>> ---
>>>>    .../devicetree/bindings/media/samsung-fimc.txt     |    7 +++++++
>>>>    1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
>>>> index 922d6f8..4b7ed03 100644
>>>> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
>>>> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
>>>> @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated
>>>>    and the port B deactivated and for the state "active-b" it should be the other
>>>>    way around.
>>>>
>>>> +Optional properties:
>>>> +
>>>> +- flashes - array of strings with flash led names; the name has to
>>>> +	    be same with the related led label
>>>> +	    (see Documentation/devicetree/bindings/leds/common.txt)
>>>> +
>>>
>>> Why is this not an array of phandles to the LED nodes? That's much
>>> better than strings.
>>
>> This is because a single flash led device can control many sub-leds,
>> which are represented by child nodes in the Device Tree.
>> Every sub-led is registered as a separate LED Flash class device
>> in the LED subsystem, but in fact they share the same struct device
>> and thus have access only to the parent's phandle.
>
> But that's a Linux infrastrcture issue, no? You don't have to use the
> node from the struct device to find the relevant phandle.

Right.

>> The LED Flash
>> class devices are wrapped by V4L2 sub-devices and register
>> asynchronously within a media device. Since the v4l2_subdev structure
>> has a 'name' field, it is convenient to initialize it with
>> parsed 'label' property of a child led node and match the
>> sub-devices in the media device basing on it.
>
> While that might be convenient, I don't think it's fantastic to use that
> to describe the relationship, as this leaks Linux internals (e.g. I can
> refer to a name that doesn't exist in the DT but happens to be what
> Linux used, and it would work). Also, are the labels guaranteed to be
> globally unique?

The labels are used for initializing class device name and kernel
doesn't allow to initialize two devices with same names.
This implies that labels are guaranteed to be globally unique.
Unless I am missing something.

Regards,
Jacek
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC v8 08/14] DT: Add documentation for exynos4-is 'flashes' property

[Mark Rutland]

On Fri, Nov 28, 2014 at 02:11:04PM +0000, Jacek Anaszewski wrote:
> On 11/28/2014 01:30 PM, Mark Rutland wrote:
> > On Fri, Nov 28, 2014 at 12:09:14PM +0000, Jacek Anaszewski wrote:
> >> On 11/28/2014 12:14 PM, Mark Rutland wrote:
> >>> On Fri, Nov 28, 2014 at 09:18:00AM +0000, Jacek Anaszewski wrote:
> >>>> This patch adds a description of 'flashes' property
> >>>> to the samsung-fimc.txt.
> >>>>
> >>>> Signed-off-by: Jacek Anaszewski <j.anaszewski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >>>> Acked-by: Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >>>> Cc: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >>>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> >>>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> >>>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> >>>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >>>> Cc: <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> >>>> ---
> >>>>    .../devicetree/bindings/media/samsung-fimc.txt     |    7 +++++++
> >>>>    1 file changed, 7 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >>>> index 922d6f8..4b7ed03 100644
> >>>> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >>>> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >>>> @@ -40,6 +40,12 @@ should be inactive. For the "active-a" state the camera port A must be activated
> >>>>    and the port B deactivated and for the state "active-b" it should be the other
> >>>>    way around.
> >>>>
> >>>> +Optional properties:
> >>>> +
> >>>> +- flashes - array of strings with flash led names; the name has to
> >>>> +	    be same with the related led label
> >>>> +	    (see Documentation/devicetree/bindings/leds/common.txt)
> >>>> +
> >>>
> >>> Why is this not an array of phandles to the LED nodes? That's much
> >>> better than strings.
> >>
> >> This is because a single flash led device can control many sub-leds,
> >> which are represented by child nodes in the Device Tree.
> >> Every sub-led is registered as a separate LED Flash class device
> >> in the LED subsystem, but in fact they share the same struct device
> >> and thus have access only to the parent's phandle.
> >
> > But that's a Linux infrastrcture issue, no? You don't have to use the
> > node from the struct device to find the relevant phandle.
> 
> Right.
> 
> >> The LED Flash
> >> class devices are wrapped by V4L2 sub-devices and register
> >> asynchronously within a media device. Since the v4l2_subdev structure
> >> has a 'name' field, it is convenient to initialize it with
> >> parsed 'label' property of a child led node and match the
> >> sub-devices in the media device basing on it.
> >
> > While that might be convenient, I don't think it's fantastic to use that
> > to describe the relationship, as this leaks Linux internals (e.g. I can
> > refer to a name that doesn't exist in the DT but happens to be what
> > Linux used, and it would work). Also, are the labels guaranteed to be
> > globally unique?
> 
> The labels are used for initializing class device name and kernel
> doesn't allow to initialize two devices with same names.
> This implies that labels are guaranteed to be globally unique.

On Linux, yes, but that's an implementation detail, not a property of
the binding·

Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693

[Pavel Machek]

Hi!

> diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt
> index 01e9f30..50a8dad 100644
> --- a/Documentation/devicetree/bindings/mfd/max77693.txt
> +++ b/Documentation/devicetree/bindings/mfd/max77693.txt
> @@ -41,6 +41,62 @@ Optional properties:
>  	 To get more informations, please refer to documentaion.
>  	[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
>  
> +- led-flash : the LED submodule device node
> +
> +There are two led outputs available - fled1 and fled2. Each of them can
> +control a separate led or they can be connected together to double
> +the maximum current for a single connected led. One led is represented
> +by one child node.
> +
> +Required properties:
> +- compatible : must be "maxim,max77693-flash"
> +
> +Optional properties:
> +- maxim,fleds : array of current outputs in order: fled1, fled2
> +	Note: both current outputs can be connected to a single led
> +	Possible values:
> +		0 - the output is left disconnected,
> +		1 - a diode is connected to the output.

Is this one needed? Just ommit child note if it is not there.

> +- maxim,trigger-type : Array of trigger types in order: flash, torch
> +	Possible trigger types:
> +		0 - Rising edge of the signal triggers the flash/torch,
> +		1 - Signal level controls duration of the flash/torch.
> +- maxim,trigger : Array of flags indicating which trigger can activate given led
> +	in order: fled1, fled2
> +	Possible flag values (can be combined):
> +		1 - FLASH pin of the chip,
> +		2 - TORCH pin of the chip,
> +		4 - software via I2C command.

Is it good idea to have bitfields like this?

Make these required properties of the subnode?
     									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693

[Lee Jones]

On Fri, 28 Nov 2014, Jacek Anaszewski wrote:

> This patch adds device tree binding documentation for
> the flash cell of the Maxim max77693 multifunctional device.
> 
> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: SangYoung Son <hello.son@smasung.com>
> Cc: Samuel Ortiz <sameo@linux.intel.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: <devicetree@vger.kernel.org>
> ---
>  Documentation/devicetree/bindings/mfd/max77693.txt |   74 ++++++++++++++++++++
>  1 file changed, 74 insertions(+)

This definitely requires a DT Ack.

> diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt
> index 01e9f30..50a8dad 100644
> --- a/Documentation/devicetree/bindings/mfd/max77693.txt
> +++ b/Documentation/devicetree/bindings/mfd/max77693.txt
> @@ -41,6 +41,62 @@ Optional properties:
>  	 To get more informations, please refer to documentaion.
>  	[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
>  
> +- led-flash : the LED submodule device node
> +
> +There are two led outputs available - fled1 and fled2. Each of them can
> +control a separate led or they can be connected together to double
> +the maximum current for a single connected led. One led is represented
> +by one child node.
> +
> +Required properties:
> +- compatible : must be "maxim,max77693-flash"

I'm not sure this compatible string is suitable.  It looks like
NOR/NAND Flash to me.  Perhaps 'fled', or just 'led' would be better.

> +Optional properties:
> +- maxim,fleds : array of current outputs in order: fled1, fled2

Nit: Sentences start with an uppercase character.

This is true for all other occurrences.

> +	Note: both current outputs can be connected to a single led
> +	Possible values:
> +		0 - the output is left disconnected,
> +		1 - a diode is connected to the output.
> +- maxim,trigger-type : Array of trigger types in order: flash, torch
> +	Possible trigger types:
> +		0 - Rising edge of the signal triggers the flash/torch,
> +		1 - Signal level controls duration of the flash/torch.
> +- maxim,trigger : Array of flags indicating which trigger can activate given led
> +	in order: fled1, fled2
> +	Possible flag values (can be combined):
> +		1 - FLASH pin of the chip,
> +		2 - TORCH pin of the chip,
> +		4 - software via I2C command.
> +- maxim,boost-mode :
> +	In boost mode the device can produce up to 1.2A of total current
> +	on both outputs. The maximum current on each output is reduced
> +	to 625mA then. If there are two child led nodes defined then boost
> +	is enabled by default.
> +	Possible values:
> +		0 - no boost,
> +		1 - adaptive mode,
> +		2 - fixed mode.
> +- maxim,boost-vout : Output voltage of the boost module in millivolts.
> +- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired
> +	if chip estimates that system voltage could drop below this level due
> +	to flash power consumption.
> +
> +A child node must be defined per sub-led.
> +
> +Required properties of the LED child node:
> +- label : see Documentation/devicetree/bindings/leds/common.txt
> +- maxim,fled_id : identifier of the fled output the led is connected to:
> +		1 - FLED1,
> +		2 - FLED2.

Better to define all of these random numbers in include/dt-bindings.

> +Optional properties of the LED child node:
> +- max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +		Range: 15625 - 250000
> +- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt
> +		Range: 15625 - 1000000
> +- flash-timeout-microsec : see Documentation/devicetree/bindings/leds/common.txt
> +		Range: 62500 - 1000000
> +
>  Example:
>  	max77693@66 {
>  		compatible = "maxim,max77693";
> @@ -73,4 +129,22 @@ Example:
>  			pwms = <&pwm 0 40000 0>;
>  			pwm-names = "haptic";
>  		};
> +
> +		led_flash: led-flash {

Should both be underscore.  I believe the second portion here should
be more generic "led" for instance.

> +			compatible = "maxim,max77693-flash";
> +			maxim,fleds = <1 0>;
> +			maxim,trigger = <7 0>;
> +			maxim,trigger-type = <0 1>;
> +			maxim,boost-mode = <0>;
> +			maxim,boost-vout = <5000>;
> +			maxim,vsys-min = <2400>;

These will all have to be signed off by a DT maintainer.

> +			camera-flash {
> +				maxim,fled_id = <1>
> +				label = "max77693-flash";
> +				max-microamp = <250000>;
> +				flash-max-microamp = <1000000>;
> +				flash-timeout-microsec = <1000000>;
> +			}

Missing ';'

You should probably test your example code.

> +		};
>  	};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693

[Jacek Anaszewski]

Hi Pavel,

Thanks for the review.

On 11/29/2014 08:26 PM, Pavel Machek wrote:
> Hi!
>
>> diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt
>> index 01e9f30..50a8dad 100644
>> --- a/Documentation/devicetree/bindings/mfd/max77693.txt
>> +++ b/Documentation/devicetree/bindings/mfd/max77693.txt
>> @@ -41,6 +41,62 @@ Optional properties:
>>   	 To get more informations, please refer to documentaion.
>>   	[*] refer Documentation/devicetree/bindings/pwm/pwm.txt
>>
>> +- led-flash : the LED submodule device node
>> +
>> +There are two led outputs available - fled1 and fled2. Each of them can
>> +control a separate led or they can be connected together to double
>> +the maximum current for a single connected led. One led is represented
>> +by one child node.
>> +
>> +Required properties:
>> +- compatible : must be "maxim,max77693-flash"
>> +
>> +Optional properties:
>> +- maxim,fleds : array of current outputs in order: fled1, fled2
>> +	Note: both current outputs can be connected to a single led
>> +	Possible values:
>> +		0 - the output is left disconnected,
>> +		1 - a diode is connected to the output.
>
> Is this one needed? Just ommit child note if it is not there.

It is needed because you can have one led connected two both
outputs. This allows to describe such a design.

>> +- maxim,trigger-type : Array of trigger types in order: flash, torch
>> +	Possible trigger types:
>> +		0 - Rising edge of the signal triggers the flash/torch,
>> +		1 - Signal level controls duration of the flash/torch.
>> +- maxim,trigger : Array of flags indicating which trigger can activate given led
>> +	in order: fled1, fled2
>> +	Possible flag values (can be combined):
>> +		1 - FLASH pin of the chip,
>> +		2 - TORCH pin of the chip,
>> +		4 - software via I2C command.
>
> Is it good idea to have bitfields like this?
>
> Make these required properties of the subnode?

This is related to a single property: trigger. I think that splitting
it to three properties would make unnecessary noise in the
binding.

Best Regards,
Jacek Anaszewski

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693

[Pavel Machek]

Hi!

> >Is this one needed? Just ommit child note if it is not there.
> 
> It is needed because you can have one led connected two both
> outputs. This allows to describe such a design.

Ok.

> >>+- maxim,trigger-type : Array of trigger types in order: flash, torch
> >>+	Possible trigger types:
> >>+		0 - Rising edge of the signal triggers the flash/torch,
> >>+		1 - Signal level controls duration of the flash/torch.
> >>+- maxim,trigger : Array of flags indicating which trigger can activate given led
> >>+	in order: fled1, fled2
> >>+	Possible flag values (can be combined):
> >>+		1 - FLASH pin of the chip,
> >>+		2 - TORCH pin of the chip,
> >>+		4 - software via I2C command.
> >
> >Is it good idea to have bitfields like this?
> >
> >Make these required properties of the subnode?
> 
> This is related to a single property: trigger. I think that splitting
> it to three properties would make unnecessary noise in the
> binding.

Well, maybe it is not that much noise, and you'll have useful names
(not a bitfield).

Should these properties move to the LED subnode?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH/RFC v8 11/14] DT: Add documentation for the mfd Maxim max77693

[Jacek Anaszewski]

Hi Pavel,

On 12/01/2014 02:02 PM, Pavel Machek wrote:
> Hi!
>
>>> Is this one needed? Just ommit child note if it is not there.
>>
>> It is needed because you can have one led connected two both
>> outputs. This allows to describe such a design.
>
> Ok.
>
>>>> +- maxim,trigger-type : Array of trigger types in order: flash, torch
>>>> +	Possible trigger types:
>>>> +		0 - Rising edge of the signal triggers the flash/torch,
>>>> +		1 - Signal level controls duration of the flash/torch.
>>>> +- maxim,trigger : Array of flags indicating which trigger can activate given led
>>>> +	in order: fled1, fled2
>>>> +	Possible flag values (can be combined):
>>>> +		1 - FLASH pin of the chip,
>>>> +		2 - TORCH pin of the chip,
>>>> +		4 - software via I2C command.
>>>
>>> Is it good idea to have bitfields like this?
>>>
>>> Make these required properties of the subnode?
>>
>> This is related to a single property: trigger. I think that splitting
>> it to three properties would make unnecessary noise in the
>> binding.
>
> Well, maybe it is not that much noise, and you'll have useful names
> (not a bitfield).

I think we'd need an opinion of at least one more person :)

> Should these properties move to the LED subnode?

I would leave them device specific.

Regards,
Jacek