Hi,
On 02-04-19 21:17, Jacek Anaszewski wrote:
On 4/1/19 10:21 AM, Hans de Goede wrote:
Hi,
On 31-03-19 20:53, Pavel Machek wrote:
On Thu 2019-03-28 23:47:08, Hans de Goede wrote:
Hi,
On 28-03-19 23:43, Marek Behun wrote:
This indeed seems to give most of the infra, but the whole trigger
mechanism currently only allows setting-up blinking through triggers,
not glowing. I'm tempted to just use the blink interface to implement
glowing on this hardware, since that is what we really want (blinking
is to distracting for the user IMHO). What is your take on just
implementing glowing through the standard blink interface ?
Optionally we could add a custom sysfs attr to the driver to
switch between the blink interface between actually blinking and
glowing and default to glowing.
Isn't glowing doable via led patterns?
A (software) trigger cannot select / set a led pattern, so either we
need a whole separate glowing API which seems overkill, or we need
to use the existing blink API. I guess one option would be to give
the led_trigger_blink function a "glow_if_possible" bool extra
parameter and pass this along to the actual led-driver.
Call it pattern API and it will be useful for more than glowing :-).
True, but the pattern API is very generic, where as glowing is pretty
specific, having triggers request glowing sounds like something which
I can see more triggers do; as for random patterns not so much.
More specifically we will often want to use hw glowing when available,
but not use a software pattern for this because that will cause too
much wakeups.
What's the problem with defining specific pattern tuple constraints
for enabling glowing for this device via hw_pattern file?
Well we want to extend the trigger(s) in:
drivers/power/supply/power_supply_leds.c
To enable glowing through the trigger, currently the
"battery-charging-blink-full-solid" trigger there calls
led_trigger_event or led_trigger_blink depending on the status of
the battery.
The idea for the PMIC LED controller we are discussing now is to
not focus on exporting all functionality, but only that functionality
for which we actually have a use-case. The primary use-case there will
be a new trigger called: "battery-charging-glow-full-solid", which
will be set as the default trigger for the charging LED controlled by
the PMIC LED controller.
This requires adding a new led_trigger_glow() or led_trigger_hw_pattern()
to the kernel's internal LED API. I prefer the simpler and more
expressive led_trigger_glow() option. One reason for me preferring this
is that we want to keep the trigger code in power_supply_leds.c
generic and if we implement glowing through the hw_pattern API then
the PMIC led-driver will have very specific expectations of the pattern
and the power_supply_leds.c code will not know about these expectations.
Or to put it differently, if you can give me some pseudo-code examples of
how you see generic trigger code, without awareness of the LED driver
on the other side, do _hardware_ glowing through a new led_trigger_hw_pattern()
I'm happy to go that route, but I just don't see how you envision this
working.
Regards,
Hans
