On 11/10/2015 08:38 AM, Kim, Milo wrote:
[...]
+ cat /sys/class/leds/<led>/pattern_levels
+ low brightness: 0, high brightness: 255
+
+What: /sys/class/leds/<led>/run_pattern
+Date: Oct 2015
+KernelVersion: 4.3
+Contact: Milo Kim <milo.kim@xxxxxx>
+Description: write only
+ After 'pattern_times' and 'pattern_levels' are updated,
+ run the pattern by writing 1 to 'run_pattern'.
+ To stop running pattern, writes 0 to 'run_pattern'.
I wonder how registering an in-driver trigger would work. It would
allow for hiding above pattern attributes when the trigger is inactive,
and thus making the sysfs interface more transparent. You could avoid
the need for run_pattern attribute, as setting the trigger would itself
activate the pattern, and setting brightness to 0 would turn it off.
I like this idea, let me try to fix it.
After thinking it over, I came to conclusion that implementing it as
an in-driver trigger is not a proper way to go, since triggers are
defined as kernel based source of LED events.
This is somehow abused in case of timer trigger which takes hardware
blinking feature as a first choice and applies software blinking as
a fallback only. To be consistent with that, we could go for adding
generic pattern trigger and add a led_pattern_set() API, similarly
to existing led_blink_set().
The problem is that different LED controllers may implement blinking
patterns that are configured with different set of parameters. This
subject would definitely require thorough analysis.
For now, please just expose pattern settings as separate sysfs
attributes of a LED class device.
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
