Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1273889 > unrolled thread
| Started by | Jacek Anaszewski <j.anaszewski@samsung.com> |
|---|---|
| First post | 2015-11-20 10:30 +0100 |
| Last post | 2015-11-23 12:20 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH RESEND 15/16] leds: add LM3633 driver Jacek Anaszewski <j.anaszewski@samsung.com> - 2015-11-20 10:30 +0100
Re: [PATCH RESEND 15/16] leds: add LM3633 driver "Kim, Milo" <milo.kim@ti.com> - 2015-11-23 00:50 +0100
Re: [PATCH RESEND 15/16] leds: add LM3633 driver Jacek Anaszewski <j.anaszewski@samsung.com> - 2015-11-23 12:20 +0100
| From | Jacek Anaszewski <j.anaszewski@samsung.com> |
|---|---|
| Date | 2015-11-20 10:30 +0100 |
| Subject | Re: [PATCH RESEND 15/16] leds: add LM3633 driver |
| Message-ID | <qwQb0-5kb-11@gated-at.bofh.it> |
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. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | "Kim, Milo" <milo.kim@ti.com> |
|---|---|
| Date | 2015-11-23 00:50 +0100 |
| Message-ID | <qxMym-2f4-5@gated-at.bofh.it> |
| In reply to | #1273889 |
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. Best regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Jacek Anaszewski <j.anaszewski@samsung.com> |
|---|---|
| Date | 2015-11-23 12:20 +0100 |
| Message-ID | <qxXk5-123-3@gated-at.bofh.it> |
| In reply to | #1274996 |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web