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 15:43:02 +0200 [thread overview]
Message-ID: <560943E6.1050606@samsung.com> (raw)
In-Reply-To: <20150928132533.GA7306@kw.sim.vm.gnt>
On 09/28/2015 03:25 PM, Simon Guinot wrote:
> On Mon, Sep 28, 2015 at 02:24:40PM +0200, Jacek Anaszewski wrote:
>> 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 think I may have managed to confuse you completely.
>
> The LEDs are controlled by a CPLD. The leds-netxbig driver talks to the
> CPLD via the gpio-ext "kind of" bus:
>
> leds-netxbig -> gpio-ext bus -> CPLD -> LEDs
>
> "LaCie stock firmware" don't refer to the firmware embedded in the CPLD
> but to the stock LaCie Linux system running *on* the board.
>
> "LEDs are only enabled at their maximum level by the LaCie stock
> firmware" means: "In the Linux LaCie system running on the board,
> userland only configures the LED brightness to 0 or 255".
>
> It don't mean that the CPLD does some weird stuff implying that the
> feature is somewhat broken. No, the feature works. Simply userland
> (in the stock LaCie system aka firmware) don't use it.
>
> Remember that your original question was:
>
> "Doesn't specification of your device say what current value given
> brightness level reflects?"
>
> Let me rephrase my answer without using "LaCie stock firmware":
>
> No this information is not available in the board specification. It is
> probably because this feature is not used by the LaCie Linux userland.
> The LED brightness is configured to off or full. Other levels are not
> used. That's probably why no one took care of measuring the LED current
> consumption.
>
> Let me know if it is still unclear for you.
Thanks for this explanation. Now everything is clear.
--
Best Regards,
Jacek Anaszewski
next prev parent reply other threads:[~2015-09-28 13:43 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
2015-09-28 13:25 ` Simon Guinot
2015-09-28 13:43 ` Jacek Anaszewski [this message]
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=560943E6.1050606@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