All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Jacek Anaszewski <j.anaszewski@samsung.com>
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:51:48 +0100	[thread overview]
Message-ID: <20141118165148.GA11711@amd> (raw)
In-Reply-To: <546B6D86.8090701@samsung.com>

Hi!

> >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.

I think I am :-).

> >>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

Ok, I took a look, and "iout" is notation I understand, but people may
have trouble with and I don't see it used anywhere else.

Also... do we need both "current" and "max-current" properties?

But regulators already have "regulator-max-microamp" property. So what
about:

max-microamp : 	maximum intensity in microamperes of the LED
 		  	(torch LED for flash devices)
max-flash-microamp : 	initial intensity in microamperes of the
 			flash LED; it is required to enable support
 			for the flash led
flash-timeout-microseconds : timeout in microseconds after which flash
 			led is turned off

If you had indicator on the same led, I guess

indicator-microamp : recommended intensity in microamperes of the LED
		         for indication

...would do?

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

Agreed.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

WARNING: multiple messages have this Message-ID (diff)
From: pavel@ucw.cz (Pavel Machek)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] adp1653: Add device tree bindings for LED controller
Date: Tue, 18 Nov 2014 17:51:48 +0100	[thread overview]
Message-ID: <20141118165148.GA11711@amd> (raw)
In-Reply-To: <546B6D86.8090701@samsung.com>

Hi!

> >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.

I think I am :-).

> >>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

Ok, I took a look, and "iout" is notation I understand, but people may
have trouble with and I don't see it used anywhere else.

Also... do we need both "current" and "max-current" properties?

But regulators already have "regulator-max-microamp" property. So what
about:

max-microamp : 	maximum intensity in microamperes of the LED
 		  	(torch LED for flash devices)
max-flash-microamp : 	initial intensity in microamperes of the
 			flash LED; it is required to enable support
 			for the flash led
flash-timeout-microseconds : timeout in microseconds after which flash
 			led is turned off

If you had indicator on the same led, I guess

indicator-microamp : recommended intensity in microamperes of the LED
		         for indication

...would do?

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

Agreed.

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

Thread overview: 79+ 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  7:59 ` Pavel Machek
2014-11-16  8:11 ` Lars-Peter Clausen
2014-11-16  8:11   ` Lars-Peter Clausen
     [not found]   ` <54685C18.1020109-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
2014-11-16  8:43     ` Pavel Machek
2014-11-16  8:43       ` Pavel Machek
2014-11-16  8:43       ` Pavel Machek
2014-11-16 10:09 ` Andreas Färber
2014-11-16 10:09   ` Andreas Färber
2014-11-16 10:09   ` Andreas Färber
2014-11-16 10:15   ` Pavel Machek
2014-11-16 10:15     ` Pavel Machek
2014-11-17  8:43 ` Pali Rohár
2014-11-17  8:43   ` Pali Rohár
2014-11-17  8:43   ` Pali Rohár
2014-11-17 10:05   ` Pavel Machek
2014-11-17 10:05     ` Pavel Machek
2014-11-17 10:09     ` Pali Rohár
2014-11-17 10:09       ` Pali Rohár
2014-11-17 10:09       ` Pali Rohár
2014-11-17 10:15       ` Pavel Machek
2014-11-17 10:15         ` Pavel Machek
2014-11-17 14:55         ` Tony Lindgren
2014-11-17 14:55           ` Tony Lindgren
2014-11-17 15:01           ` Pali Rohár
2014-11-17 15:01             ` Pali Rohár
2014-11-17 15:04             ` Sakari Ailus
2014-11-17 15:04               ` Sakari Ailus
     [not found]               ` <20141117150407.GP8907-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>
2014-11-17 15:15                 ` Pali Rohár
2014-11-17 15:15                   ` Pali Rohár
2014-11-17 15:15                   ` Pali Rohár
2014-11-22 18:45                   ` Ivaylo Dimitrov
2014-11-22 18:45                     ` Ivaylo Dimitrov
2014-11-17 15:06             ` Tony Lindgren
2014-11-17 15:06               ` Tony Lindgren
2014-11-17 15:21               ` Pali Rohár
2014-11-17 15:21                 ` Pali Rohár
     [not found]               ` <20141117150617.GD7046-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
2014-11-18 18:35                 ` Pavel Machek
2014-11-18 18:35                   ` Pavel Machek
2014-11-18 18:35                   ` Pavel Machek
2014-11-19 18:01                   ` Sakari Ailus
2014-11-19 18:01                     ` Sakari Ailus
2014-11-17 14:58 ` Sakari Ailus
2014-11-17 14:58   ` Sakari Ailus
     [not found]   ` <20141117145857.GO8907-S+BSfZ9RZZmRSg0ZkenSGLdO1Tsj/99ntUK59QYPAWc@public.gmane.org>
2014-11-18  8:09     ` Jacek Anaszewski
2014-11-18  8:09       ` Jacek Anaszewski
2014-11-18  8:09       ` Jacek Anaszewski
     [not found]       ` <546AFEA5.9020000-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-11-18  8:46         ` Pavel Machek
2014-11-18  8:46           ` Pavel Machek
2014-11-18  8:46           ` Pavel Machek
2014-11-18 10:04           ` Jacek Anaszewski
2014-11-18 10:04             ` Jacek Anaszewski
2014-11-18 11:32             ` Pavel Machek
2014-11-18 11:32               ` Pavel Machek
2014-11-18 12:52               ` Jacek Anaszewski
2014-11-18 12:52                 ` Jacek Anaszewski
2014-11-18 13:21                 ` Pavel Machek
2014-11-18 13:21                   ` Pavel Machek
2014-11-18 16:02                   ` Jacek Anaszewski
2014-11-18 16:02                     ` Jacek Anaszewski
2014-11-18 16:51                     ` Pavel Machek [this message]
2014-11-18 16:51                       ` Pavel Machek
2014-11-19  9:45                       ` Jacek Anaszewski
2014-11-19  9:45                         ` Jacek Anaszewski
2014-11-19  9:45                         ` Jacek Anaszewski
2014-11-19 17:53                         ` Sakari Ailus
2014-11-19 17:53                           ` Sakari Ailus
2014-11-20  9:21                           ` Jacek Anaszewski
2014-11-20  9:21                             ` Jacek Anaszewski
2014-11-20 12:13                           ` Pavel Machek
2014-11-20 12:13                             ` Pavel Machek
2014-11-20 12:12                         ` Pavel Machek
2014-11-20 12:12                           ` Pavel Machek
2014-11-20 12:48                           ` Jacek Anaszewski
2014-11-20 12:48                             ` Jacek Anaszewski
2014-11-20 12:38                         ` Jacek Anaszewski
2014-11-20 12:38                           ` Jacek Anaszewski
2014-11-18  8:50       ` Pavel Machek
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=20141118165148.GA11711@amd \
    --to=pavel@ucw.cz \
    --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=j.anaszewski@samsung.com \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.