mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: "Uwe Kleine-König" <uwe@kleine-koenig.org>,
	"Pavel Machek" <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org, Tomas Hlavacek <tomas.hlavacek@nic.cz>
Subject: Re: led: hw-trigger, global brightness and multi-colored leds
Date: Thu, 3 May 2018 23:14:17 +0200	[thread overview]
Message-ID: <4b8da1c0-60a6-e19c-379d-9649036c9ba4@gmail.com> (raw)
In-Reply-To: <69651d45-7566-95ad-2a83-53dd76e5680e@kleine-koenig.org>

Hi Uwe and Pavel,

On 05/03/2018 08:49 PM, Uwe Kleine-König wrote:
> Hello Pavel,
> 
> On 05/02/2018 11:21 PM, Pavel Machek wrote:
>>> on the Turris Omnia[1] the LEDs are controllable via an i2c device. Each
>>> LED can be either in "manual mode" or in a mode I'd call "native mode"
>>> which is the default. In this native mode the LED being on or off
>>> depends on an input line that is controlled by another hardware. So a
>>> LED signals for example activity on the WAN ethernet port without any
>>> software intervention, but can be used as a normal LED, too, when in
>>> "manual mode" where it can be switched on and off by a register
>>> write.
>>
>> "Native mode" is quite common. We have it for example on Nokia N900
>> here (charger has hw option to automatically control the LED).
> 
> git grep -i n900 -- drivers/leds doesn't yield any output. Do I miss
> anything?
> 
>> I believe reasonable solution would be to have "hardware" trigger, and
>> have it selected by default. When active, LED would be controlled by
>> hardware.

The question is whether there is a way for a driver to tell whether
the device is in the manual or in the native mode. If yes,
then we could just return -EBUSY on any attempt of brightness setting
when in the native mode.

Also, if it is possible to detect brightness changes originating
from hardware, then we have an optional brightness_hw_changed sysfs
file supporting POLLPRI events
(compare drivers/platform/x86/thinkpad_acpi.c).

If we can't tell whether the LED is in native or manual mode,
but it is possible to read the current brightness from a register, then
implementing brightness_get op will allow to detect it indirectly (to
some extent since we cannot guarantee that brightness is not changed
by another process).

In each case I'd rather not use trigger mechanism here, which is
defined as __kernel__ based source of LED events.

> There is no prior art for that available as source code, right?
> 
>>> Another feature of the LED device is that there is a global brightness
>>> register that influences all LED's brightness (if on) independent of the
>>> operating mode.
>>
>> We can't describe that easily.
> 
> Given that I can give an RGB value (i.e. 3x 8 bit) for the LED, I can
> change brightness per LED. Have to play around a bit.
> 
>>> Further the color of each LED can be set to an RGB triplet.
>>
>> We normally handle RGB LED as three independend LEDs, like
>> notify::red, notify::green, notify::blue. Again, example is Nokia N900
>> or Motorola Droid 4.
> 
> I cannot find source code for LEDs on the Droid 4 either.
> 
> An ugly property here is that the hardware trigger only operates on all
> three colors at once. Hmm, will think a bit about the way to go.
> 
> Best regards and thanks for your input,
> Uwe
> 

-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2018-05-03 21:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-02 15:11 Uwe Kleine-König
2018-05-02 21:21 ` Pavel Machek
2018-05-03 18:49   ` Uwe Kleine-König
2018-05-03 21:14     ` Jacek Anaszewski [this message]
2018-05-03 21:52     ` Pavel Machek
2018-05-24 22:08 ` Tomas Hlavacek
2018-05-25  6:08   ` Turris Omnia firmware possibilities [Was: Re: led: hw-trigger, global brightness and multi-colored leds] Uwe Kleine-König
2018-05-25 14:02     ` Tomas Hlavacek
2018-05-25 18:50       ` Pavel Machek
2018-08-14  7:11       ` Uwe Kleine-König

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=4b8da1c0-60a6-e19c-379d-9649036c9ba4@gmail.com \
    --to=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=tomas.hlavacek@nic.cz \
    --cc=uwe@kleine-koenig.org \
    /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

all inboxes | Powered by JetHome®