Hi,
On 28-03-19 10:15, Pavel Machek wrote:
Hi!
so I've been thinking a little about LED HW triggering API since Jacek
replied to my patch for Turris LEDs.
There are many chips which expose SW control of LEDs which can also be
put into HW control mode, for example network PHYs, switches, wireless
cards etc.
Jacek proposed a hardware_controlled file to the LED core, exposed only
if supported by hardware when the a new flag LED_DEV_CAP_HW_CONTROL is
set on the LED.
...
- if the device supports several hardware controlled modes, it is
put into one of these modes and a hardware_trigger file is
created, via which these mode can be changed.
This hardware_trigger file behaves similarly to classic trigger
file, ie. on read it returns space-separated list of supported
hardware triggers, the currently selected one in brackets.
Ok, so it seems we need "hardware_trigger" (or "hw_trigger"?) file,
anyway, because it is common for hardware to have few modes.
What about getting rid of hardware_controlled file, and just having
"hw_trigger", working similar to current "trigger" semantics?
hw_trigger would
* only be present if LED can be hardware controlled
* echo none > hw_trigger would give control to software
* echo mode > hw_trigger would give control to hardware, in given mode
* cat hw_trigger would list possible modes.
* echo 0 > brightness would clear set both "trigger" and "hw_trigger" to
none.
* any change to trigger or hw_trigger would set the other one to
"none".
But .. looking at proposal. I believe most consistent / logical
solution would be to simply add hardware triggers into list of
triggers, and treat them the same way. Yes, that would mean different
trigger lists per LED, but I don't think that's a problem, and it is
logical solution for our users.
OK, so we would have say a hw_battery_is_charging trigger for the PMIC
led driver we were discussing recently, and selecting this buts the
LED under hw control but this hw-trigger just turns the LED on and off.
The device also has a hw_pattern (on / blink / glow) which selects what
it shows when "triggered" (or manually turned on).
I assume this would then use a hw_pattern file, how do you see these
2 interacting ? What happens when the trigger is changed, does the
pattern then gets reset ? etc.
Regards,
Hans
