Messages in this thread | | | Date | Mon, 23 Nov 2015 12:17:15 +0100 | From | Jacek Anaszewski <> | Subject | Re: [PATCH RESEND 15/16] leds: add LM3633 driver |
| |
Hi Milo,
On 11/23/2015 12:40 AM, Kim, Milo wrote: > Hi Jacek, > > On 11/20/2015 6:22 PM, Jacek Anaszewski wrote: >> 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@ti.com> >>>>> +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. >> > > Thanks for your suggestion. > Then, LM3633 LED driver will support 8 device attributes. > > pattern_time_delay > pattern_time_rise > pattern_time_high > pattern_time_fall > pattern_time_low > pattern_brightness_low > pattern_brightness_high > pattern_run_pattern > > Details will be updated in > Documentation/ABI/testing/sysfs-class-led-lm3633.
OK, it looks reasonable.
-- Best Regards, Jacek Anaszewski
| |