linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Lee Jones <lee.jones@linaro.org>,
	Linux LED Subsystem <linux-leds@vger.kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	Andrew Lunn <andrew@lunn.ch>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 3/3] devicetree: Add led-backlight binding
Date: Fri, 04 Sep 2015 17:03:36 +0200	[thread overview]
Message-ID: <55E9B2C8.1020407@samsung.com> (raw)
In-Reply-To: <CAL_JsqK=QiNk=ZEqJ=T6_rHbjnHq7UY9=ZtWg1HLoU=qdSn8Gg@mail.gmail.com>

On 09/01/2015 01:12 AM, Rob Herring wrote:
> On Wed, Aug 26, 2015 at 4:56 AM, Jacek Anaszewski
> <j.anaszewski@samsung.com> wrote:
>> On 08/26/2015 11:11 AM, Tomi Valkeinen wrote:
>>>
>>>
>>>
>>> On 26/08/15 10:07, Jacek Anaszewski wrote:
>>>>
>>>> On 08/25/2015 05:41 PM, Tomi Valkeinen wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 25/08/15 16:39, Jacek Anaszewski wrote:
>>>>>
>>>>>>> +Example:
>>>>>>> +
>>>>>>> +    backlight {
>>>>>>> +        compatible = "led-backlight";
>>>>>>> +        leds = <&backlight_led>;
>>>>>>> +
>>>>>>> +        brightness-levels = <0 4 8 16 32 64 128 255>;
>>>>>>
>>>>>>
>>>>>> brightness level is not a suitable unit for describing LED brightness
>>>>>> in a Device Tree, as it is not a physical unit. We have
>>>>>> led-max-microamp
>>>>>> property for this, expressed in microamperes, please refer to [0] from
>>>>>> linux-next.
>>>>>
>>>>>
>>>>> Hmm, ok, but what should the driver do with microamperes? As far as I
>>>>> see, "enum led_brightness" (which is between 0-255) is used to set the
>>>>> brightness to LEDs. I don't see any function accepting microamperes.
>>>>
>>>>
>>>> This is implementation detail. You can convert microamperes to
>>>> enum led_brightness in the driver. Please refer to the discussion [1].
>>>
>>>
>>> The led_set_brightness() takes "enum led_brightness", so I don't
>>> understand what this driver would do with the microampere value. It
>>> could, of course, do an arbitrary conversion, say, direct mapping of the
>>> mA value to brightness, but that would just confuse things further.
>>
>>
>> OK, I was looking at the problem from LED-centric perspective. Indeed,
>> backlight subsystem has no other way to pass brightness to the LED
>> subsystem than in the form of levels. However, the last word belongs
>> to DT maintainer in this matter.
>>
>> Cc'ing devicetree@vger.kernel.org.
>
> I don't have a simple answer for you...
>
> There was a similar discussion for pm8941-wled and
> "default-brightness-level" units[1]. The conclusion was it should be
> units matching the h/w so that there is no conversion between
> bootloader and OS units to h/w units. That principle probably applies
> here.
>
> If the brightness levels are non-linear, then you need a translation
> from percent to h/w level. What's needed here for h/w levels depends
> on whether the brightness control is PWM, current control or both. For
> PWM, units of the PWM control makes sense. For current control, units
> of microamps probably makes sense. I don't know what you do with both,
> but I have seen that h/w (FSL PMICs).
>
> This all certainly needs some more work on defining some common
> binding. We already have some bindings for backlights with the LED and
> PWM bindings (perhaps incomplete?). Do we need another way here? This
> also introduces possibility of multiple ways to define GPIO controlled
> backlights: gpio -> gpio-leds ->  led-backlight or gpio ->
> gpio-backlight. We don't want that...
>
> This problem is not really specific at all to backlights, but applies
> to all LEDs. Some LEDs you may not have control beyond on/off or
> really care about fine-grained control of level, but they are really
> no different. The main unique thing about backlights is what display
> are they associated with.

Some time ago I was trying to add common LEDs DT properties that would
have defined brightness in levels, but other people insisted on
microamperes [1]. The discussion was focused on flash LEDs, where
currents are significantly greater and there is risk of hardware
damage in case underrated LED is connected [2]. Having the property in
microamperes removes the need for consulting documentation to check
current value for given brightness level.

As it was mentioned earlier in this thread, this approach is not
suitable for PWM driven leds, and they have their own bindings,
which allow for describing brightness in levels. Probably we
should add some note to the common LEDs DT bindings that would
state explicitly that such exceptions are allowed.

In case of backlights which are built upon LED class devices we could
stick to brightness levels, as a LED class driver will assert
brightness level to the leds-max-microamp value anyway.


[1] http://www.spinics.net/lists/linux-leds/msg03416.html
[2] http://patchwork.ozlabs.org/patch/456622/

-- 
Best Regards,
Jacek Anaszewski

      reply	other threads:[~2015-09-04 15:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-25 11:33 [PATCH 0/3] backlight: led-backlight driver Tomi Valkeinen
2015-08-25 11:34 ` [PATCH 1/3] leds: Add of_led_get() and led_put() Tomi Valkeinen
2015-08-25 12:18   ` Andrew Lunn
2015-08-25 12:53     ` Tomi Valkeinen
2015-09-08 11:23     ` Tomi Valkeinen
2015-08-25 13:25   ` Jacek Anaszewski
2015-09-07 12:35     ` Tomi Valkeinen
2015-09-07 14:11       ` Jacek Anaszewski
2015-09-08  7:10         ` Tomi Valkeinen
2015-09-08  9:21           ` Jacek Anaszewski
2015-09-08 10:41             ` Tomi Valkeinen
2015-09-08 10:57               ` Jacek Anaszewski
2015-09-07 13:18     ` Tomi Valkeinen
2015-09-07 14:10       ` Jacek Anaszewski
2015-08-25 11:34 ` [PATCH 2/3] backlight: add led-backlight driver Tomi Valkeinen
2015-08-25 12:39   ` Andrew Lunn
2015-08-25 13:00     ` Tomi Valkeinen
2015-08-25 11:34 ` [PATCH 3/3] devicetree: Add led-backlight binding Tomi Valkeinen
2015-08-25 13:39   ` Jacek Anaszewski
2015-08-25 15:41     ` Tomi Valkeinen
2015-08-26  7:07       ` Jacek Anaszewski
2015-08-26  9:11         ` Tomi Valkeinen
2015-08-26  9:56           ` Jacek Anaszewski
2015-08-31 23:12             ` Rob Herring
2015-09-04 15:03               ` Jacek Anaszewski [this message]

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=55E9B2C8.1020407@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=andrew@lunn.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=robherring2@gmail.com \
    --cc=tomi.valkeinen@ti.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).