All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Richard Purdie <rpurdie@rpsys.net>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-leds@vger.kernel.org, kernel@pyra-handheld.com,
	marek@goldelico.com, letux-kernel@openphoenux.org,
	Andrey Utkin <andrey_utkin@fastmail.com>
Subject: Re: [PATCH v3 1/2] drivers: led: is31fl319x: 1/3/6/9-channel light effect led driver
Date: Wed, 13 Jul 2016 09:45:01 +0200	[thread overview]
Message-ID: <5785F17D.3010108@samsung.com> (raw)
In-Reply-To: <55F90A44-0B60-4342-8143-56F85EA24772@goldelico.com>

Hi Nikolaus,

On 07/13/2016 08:09 AM, H. Nikolaus Schaller wrote:
[...]
>>> +	/*
>>> +	 * Kernel conventions require per-LED led-max-microamp property.
>>> +	 * But the chip does not allow to limit individual LEDs.
>>> +	 * So we take minimum from all subnodes.
>>
>> Why minimum? Choose maximum and reduce max_brightness properties
>> of the sub-LEDs with lesser led-max-microamp.
>
> Hm. Is this really the correct way to handle it?
>
> Assume you connect an LED which is specified with 10mA peak current.
> And another with 20mA peak current.
>
> So you define led-max-microamp in the DT as 10 mA and 20 mA.
>
> Firstly a user can set the brightness only to 50% of LED_FULL since it is limited
> by a reduced max_brightness. And heshe finds that not all LEDs have the same
> max_brightness. The first LED will have 127 and the second one 255 for reasons
> not directly understandable.

You have to know that led-max-microamp property was introduced
to standarize Device Tree definition of maximum brightness allowed for
a sub-LED.

Earlier people defined max-brightness property in DT, but at
some point we realized that brightness level is not a proper unit for
describing a hardware property.

It was not global max-microamp setting that appears in recent LED
controllers that drove the introduction of led-max-microamp property.

If you question the idea of having different maximum brightness per
sub-LEDs controlled by the same device, then it means that you have
objections to the entire idea of LED subsystem max_brightness property,
whereas it has been broadly accepted and successfully used for years.

> This entangles "brightness" with "max-current" - which are IMHO two independent
> things.

The fact that recent LED controllers use the same notion for one of its
settings shouldn't mislead us.

> Next, this will set the hardware limit to 20 mA. So there will be current peaks
> of 20 mA for an LED where the DT developer thinks to have specified a led-max-microamp
> of 10 mA. So you run the LED outside of its specs although the DT seems to
> tell that it is inside and user-space thinks it is ok. This will reduce lifetime of LEDs.

In what circumstances would such current peaks occur? On reset?
Shouldn't such a device be considered as broken by design?
What if all LEDs would have low amperage? Would there be some way
to protect them from being damaged by current peaks?

> So either "led-max-microamp" is the wrong name for this property (could better
> be "led-max-average-microamp") or the whole logic is broken.
>
> This is why we hesitate to hide (or even disable because you can't set the limit
> to 10mA by DT) the current limiting chip feature by such a difficult to understand
> automatic feature.
>
> Using the minimum of all led-max-microamp keeps everything on the safe
> side, running some LEDs with less current than specified. But never outside
> of the spec. And all LEDs have the same max_brightness which is IMHO
> more intuitive for the user.
>
> Our original proposal was to define led-max-microamp for the whole chip
> instead of individual LEDs, which is IMHO much easier to understand,
> because it corresponds one-to-one with the data sheet.



-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2016-07-13  7:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-08 19:49 [PATCH v3 0/2] driver: leds: is31fl319x dimmable LED driver H. Nikolaus Schaller
2016-07-08 19:49 ` [PATCH v3 1/2] drivers: led: is31fl319x: 1/3/6/9-channel light effect led driver H. Nikolaus Schaller
2016-07-08 20:53   ` Andrey Utkin
     [not found]   ` <524f16ecba240bacf57924f43ec38404cfdcde8f.1468007377.git.hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
2016-07-12 20:14     ` Jacek Anaszewski
2016-07-12 20:14       ` Jacek Anaszewski
2016-07-13  6:09       ` H. Nikolaus Schaller
2016-07-13  7:45         ` Jacek Anaszewski [this message]
2016-07-13  8:52           ` H. Nikolaus Schaller
2016-07-13  9:26             ` Jacek Anaszewski
2016-07-13  9:34               ` H. Nikolaus Schaller
2016-07-15  8:08       ` H. Nikolaus Schaller
2016-07-19  6:59         ` Jacek Anaszewski
     [not found] ` <cover.1468007377.git.hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
2016-07-08 19:49   ` [PATCH v3 2/2] Bindings documentation for ISSI is31fl319x driver H. Nikolaus Schaller
2016-07-08 19:49     ` H. Nikolaus Schaller
     [not found]     ` <44b0cd33fc831d55dd7d012c4d4554ed9e2d70f4.1468007377.git.hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
2016-07-12 20:14       ` Jacek Anaszewski
2016-07-12 20:14         ` Jacek Anaszewski
2016-07-16  0:18     ` Rob Herring

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=5785F17D.3010108@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=andrey_utkin@fastmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=hns@goldelico.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jacek.anaszewski@gmail.com \
    --cc=kernel@pyra-handheld.com \
    --cc=letux-kernel@openphoenux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=marek@goldelico.com \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=rpurdie@rpsys.net \
    /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.