From: j.anaszewski@samsung•com (Jacek Anaszewski)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness
Date: Mon, 28 Sep 2015 14:24:40 +0200 [thread overview]
Message-ID: <56093188.4050405@samsung.com> (raw)
In-Reply-To: <20150928115033.GZ7306@kw.sim.vm.gnt>
On 09/28/2015 01:50 PM, Simon Guinot wrote:
> On Mon, Sep 28, 2015 at 12:15:22PM +0200, Jacek Anaszewski wrote:
>> On 09/28/2015 11:19 AM, Simon Guinot wrote:
>>> On Mon, Sep 28, 2015 at 10:02:35AM +0200, Jacek Anaszewski wrote:
>>>> Hi Simon,
>>>
>>> Hi Jacek,
>>>
>>>>
>>>> Does your device support reading the brightness currently set?
>>>
>>> No it don't.
>>>
>>>> If so, it would be good to implement brightness_get op, because
>>>> AFAIR you mentioned that the firmware you are working with sets
>>>> always maximum brightness value. Having the op implemented would
>>>> allow to find this out.
>>>
>>> I don't understand how this can help. I mean, the only issue is that at
>>> startup the initial LED state is unknown. And the software brightness
>>> value could be false. But once the LED is configured, the brightness
>>> values for software and hardware are synchronized. The brightness value
>>> is stored/cached in led_classdev and it can be retrieved by the user via
>>> sysfs...
>>>
>>> For my own knowledge, is there some interest in having brightness_get(),
>>> aside of guessing the LED initial state ?
>>
>> Some LED controllers can adjust brightness in case battery voltage level
>> falls below some threshold.
>
> OK, thanks for the explanation.
>
>>
>>> What does the embedded firmware is writing 255 or 0 into the brightness
>>> sysfs attribute. The max_brightness value is ignored. After this patch,
>>> writing 255 and 0 still allows to configure the LED in the same way:
>>> maximum brightness or off. Thus, I believe there is no compatibility
>>> issue.
>>
>> LED core always assures that brightness value passed to brightness_set
>> op does not exceed max_brightness value. So, now after executing
>> "echo 255 > brightness", LED core will adjust it to max_brightness
>> (e.g. 7) before passing to brightness_set.
>>
>> In the message [1], you mentioned that "LEDs are only enabled at their
>> maximum level", so IIUC following is possible:
>>
>> #echo 3 > "brightness"
>>
>> firmware sets brightness to max_brightness from DT (e.g. 7), but
>>
>> #cat brightness
>> #3
>>
>> Is it true?
>
> Oh no sorry, it is a misunderstanding. By "LEDs are only enabled at
> their maximum level", I was meaning "LEDs are only enabled at their
> maximum level by the LaCie stock firmware". The firmware don't make
> use of the different hardware brightness levels available. But the
> feature works perfectly. If you write 3 into sysfs "brightness", then
> you get the third brightness level.
I thought that driver talks to firmware, which controls the LEDs.
From your explanation I infer that this driver replaces LaCie stock
firmware, am I right? There must be however some circuit that controls
LED brightness then.
> OK, I understand you remark now. Sorry for not being very clear in a
> first place.
--
Best Regards,
Jacek Anaszewski
next prev parent reply other threads:[~2015-09-28 12:24 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-26 21:02 [PATCH v6 0/5] Add DT support for netxbig LEDs Simon Guinot
2015-09-26 21:02 ` [PATCH v6 1/5] leds: netxbig: add device tree binding Simon Guinot
2015-09-26 21:02 ` [PATCH v6 2/5] ARM: Kirkwood: add LED DT entries for netxbig boards Simon Guinot
2015-09-26 21:02 ` [PATCH v6 3/5] ARM: mvebu: remove static LED setup " Simon Guinot
2015-09-26 21:02 ` [PATCH v6 4/5] leds: netxbig: convert to use the devm_ functions Simon Guinot
2015-09-26 21:02 ` [PATCH v6 5/5] leds: netxbig: set led_classdev max_brightness Simon Guinot
2015-09-28 8:02 ` Jacek Anaszewski
2015-09-28 9:19 ` Simon Guinot
2015-09-28 10:15 ` Jacek Anaszewski
2015-09-28 11:50 ` Simon Guinot
2015-09-28 12:24 ` Jacek Anaszewski [this message]
2015-09-28 13:25 ` Simon Guinot
2015-09-28 13:43 ` Jacek Anaszewski
2015-10-09 9:43 ` [PATCH v6 0/5] Add DT support for netxbig LEDs Jacek Anaszewski
2015-10-15 7:16 ` Gregory CLEMENT
2015-10-15 8:11 ` Jacek Anaszewski
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=56093188.4050405@samsung.com \
--to=j.anaszewski@samsung$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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