linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Sakari Ailus <sakari.ailus@iki.fi>,
	pali.rohar@gmail.com, sre@debian.org, sre@ring0.de,
	kernel list <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	linux-omap@vger.kernel.org, tony@atomide.com, khilman@kernel.org,
	aaro.koskinen@iki.fi, freemangordon@abv.bg,
	bcousson@baylibre.com, robh+dt@kernel.org, pawel.moll@arm.com,
	mark.rutland@arm.com, ijc+devicetree@hellion.org.uk,
	galak@codeaurora.org, devicetree@vger.kernel.org,
	linux-media@vger.kernel.org,
	Linux LED Subsystem <linux-leds@vger.kernel.org>
Subject: Re: [RFC] adp1653: Add device tree bindings for LED controller
Date: Tue, 18 Nov 2014 17:02:14 +0100	[thread overview]
Message-ID: <546B6D86.8090701@samsung.com> (raw)
In-Reply-To: <20141118132159.GA21089@amd>

Hi Pavel,

On 11/18/2014 02:21 PM, Pavel Machek wrote:
> Hi!
>
>>>>> @@ -19,5 +30,10 @@ Examples:
>>>>>   system-status {
>>>>>   	       label = "Status";
>>>>>   	       linux,default-trigger = "heartbeat";
>>>>> +	       iout-torch = <500 500>;
>>>>> +	       iout-flash = <1000 1000>;
>>>>> +	       iout-indicator = <100 100>;
>>>>> +	       flash-timeout = <1000>;
>>>>> +
>>>>> 	...
>>>>>   };
>>>>>
>>>>> I don't get it; system-status describes single LED, why are iout-torch
>>>>> (and friends) arrays of two?
>>>>
>>>> Some devices can control more than one led. The array is for such
>>>> purposes. The system-status should be probably renamed to
>>>> something more generic for both common leds and flash leds,
>>>> e.g. system-led.
>>>
>>> No, sorry. The Documentation/devicetree/bindings/leds/common.txt
>>> describes binding for _one LED_. Yes, your device can have two leds,
>>> so your devices should have two such blocks in the device tree... Each
>>> led should have its own label and default trigger, for example. And I
>>> guess flash-timeout be per-LED, too.
>>
>> I think that a device tree binding describes a single physical device.
>> No matter how many sub-leds a device controls, it is still one
>> piece of hardware.
>
> You got this wrong, sorry.
>
> In my case, there are three physical devices:
>
> adp1653
> 	white LED
> 	red LED

You've mentioned that your white led is torch/flash and indicator
is the red led. They are probably connected to the HPLED and
ILED pins of the ADP1653 device respectively. The device is just
a regulator, that delivers electric current to the leds connected
to it. Kernel cannot directly activate leds, but has to talk
to the device through I2C bus. One I2C device can have only one
related device tree binding.

> Each LED should have an label, and probably default trigger -- default
> trigger for red one should be "we are recording video" and for white
> should be "this is flash for default camera".

default-trigger is not mandatory, the device doesn't have to have
associated led-trigger. I think that you should look at
Documentation/leds/leds-class.txt and drivers/leds/triggers for
more detailed information. In a nutshell triggers are kernel
sources of led events. You can set e.g. "heartbeat", "timer"
trigger etc.
As for now the driver belongs to the V4L2 subsystem it doesn't
support triggers. Moreover your event "we are recording a video"
should be activated by setting V4L2_CID_FLASH_INDICATOR_INTENSITY
v4l2 control followed by V4L2_FLASH_LED_MODE_TORCH. Your event
"this is flash for default camera" seems to be flash strobe,
that can be activated by setting V4L2_CID_FLASH_STROBE control.
The driver by default sets the indicator current for both actions
to the value previously set with V4L2_CID_FLASH_INDICATOR_INTENSITY.

> If the hardware LED changes with one that needs different current, the
> block for the adp1653 stays the same, but white LED block should be
> updated with different value.

I think that you are talking about sub nodes. Indeed I am leaning
towards this type of design.

>> default-trigger property should also be an array of strings.
>
> That is not how it currently works.

OK, I agree.

>
>> I agree that flash-timeout should be per led - an array, similarly
>> as in case of iout's.
>
> Agreed about per-led, disagreed about the array. As all the fields
> would need arrays, and as LED system currently does not use arrays for
> label and linux,default-trigger, I believe we should follow existing
> design and model it as three devices. (It _is_ physically three devices.)

Right, I missed that the leds/common.txt describes child node.

I propose following modifications to the binding:

Optional properties for child nodes:
- iout-mode-led : 	maximum intensity in microamperes of the LED
		  	(torch LED for flash devices)
- iout-mode-flash : 	initial intensity in microamperes of the
			flash LED; it is required to enable support
			for the flash led
- iout-mode-indicator : initial intensity in microamperes of the
			indicator LED; it is required to enable support
			for the indicator led
- max-iout-mode-led : 	maximum intensity in microamperes of the LED
		  	(torch LED for flash devices)
- max-iout-mode-flash : maximum intensity in microamperes of the
			flash LED
- max-iout-mode-indicator : maximum intensity in microamperes of the
			indicator LED
- flash-timeout :	timeout in microseconds after which flash
			led is turned off

system-status {
         label = "max77693_1";
         iout-mode-led = <500>;
         max-iout-mode-led = <500>;
         ...
};

camera-flash1 {
         label = "max77693_2";
         iout-mode-led = <500>;
         iout-mode-flash = <1000>;
	iout-mode-indicator = <100>;
         max-iout-mode-led = <500>;
         max-iout-mode-flash = <1000>;
         max-iout-mode-indicator = <100>;
         flash-timeout = <1000>;
         ...
};


I propose to avoid name "torch", as for ordinary leds it would
be misleading.

Regards,
Jacek

  reply	other threads:[~2014-11-18 16:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-16  7:59 [RFC] adp1653: Add device tree bindings for LED controller Pavel Machek
2014-11-16  8:11 ` Lars-Peter Clausen
2014-11-16  8:43   ` Pavel Machek
2014-11-16 10:09 ` Andreas Färber
2014-11-16 10:15   ` Pavel Machek
2014-11-17  8:43 ` Pali Rohár
2014-11-17 10:05   ` Pavel Machek
2014-11-17 10:09     ` Pali Rohár
2014-11-17 10:15       ` Pavel Machek
2014-11-17 14:55         ` Tony Lindgren
2014-11-17 15:01           ` Pali Rohár
2014-11-17 15:04             ` Sakari Ailus
2014-11-17 15:15               ` Pali Rohár
2014-11-22 18:45                 ` Ivaylo Dimitrov
2014-11-17 15:06             ` Tony Lindgren
2014-11-17 15:21               ` Pali Rohár
2014-11-18 18:35               ` Pavel Machek
2014-11-19 18:01                 ` Sakari Ailus
2014-11-17 14:58 ` Sakari Ailus
2014-11-18  8:09   ` Jacek Anaszewski
2014-11-18  8:46     ` Pavel Machek
2014-11-18 10:04       ` Jacek Anaszewski
2014-11-18 11:32         ` Pavel Machek
2014-11-18 12:52           ` Jacek Anaszewski
2014-11-18 13:21             ` Pavel Machek
2014-11-18 16:02               ` Jacek Anaszewski [this message]
2014-11-18 16:51                 ` Pavel Machek
2014-11-19  9:45                   ` Jacek Anaszewski
2014-11-19 17:53                     ` Sakari Ailus
2014-11-20  9:21                       ` Jacek Anaszewski
2014-11-20 12:13                       ` Pavel Machek
2014-11-20 12:12                     ` Pavel Machek
2014-11-20 12:48                       ` Jacek Anaszewski
2014-11-20 12:38                     ` Jacek Anaszewski
2014-11-18  8:50     ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=546B6D86.8090701@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=bcousson@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=freemangordon@abv.bg \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=khilman@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pali.rohar@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@iki.fi \
    --cc=sre@debian.org \
    --cc=sre@ring0.de \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).