Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1630967
| From | Jacek Anaszewski <jacek.anaszewski@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer |
| Date | 2017-04-25 22:20 +0200 |
| Message-ID | <tAf6i-Vi-21@gated-at.bofh.it> (permalink) |
| References | <tzE6J-2cz-1@gated-at.bofh.it> <tzSt3-33H-1@gated-at.bofh.it> <tzZ1w-7uG-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi David, On 04/25/2017 05:05 AM, David Lin wrote: > Hi Jacek, > > On Mon, Apr 24, 2017 at 12:59 PM, Jacek Anaszewski > <jacek.anaszewski@gmail.com> wrote: >> >> Hi David, >> >> Thanks for the patch. >> >> Unfortunately we cannot switch to using hr timers just like that >> without introducing side effects for many devices. We had similar >> attempt of increasing timer tirgger accuracy two years ago [0]. >> >> In short words, for drivers that can sleep while setting brightness >> and/or are using a bus like I2C you will not be able to enforce >> 1ms delay period. >> >> I recommend you to go through the thread [0] so that we had >> a well defined ground for the discussion on how to address this >> issue properly. >> > > I think I understand the background now, and would agree that not all > the LED driver require hrtimer as human eye can't probably tell > there's a 10ms variation in a blink. The main problem are side effects occurring when an event scheduled by hrtimer can't finish before the next one begins. We get warnings like in the example below (copied from [0]) then, and they have probably negative impact on the whole system performance. echo "timer" > trigger echo 1 > delay_on echo 1 > delay_off echo usec > delay_unit [ 178.584433] hrtimer: interrupt took 300747 ns > However, there's a need to > support hrtimer if the LED subsystem claims support the use case of > vibrator (please see Documentation/leds/ledtrig-transient.txt) as even > a 5ms of variation is perceivable to the user. I'm thinking if a > better interim solution is to introduce a > LEDS_TRIGGER_TRANSIENT_HRTIMER config to work with both timers in > compile time. Would you agree? I think that it would be better if LED class driver set a flag marking itself as capable of setting brightness with high rate. I'd limit that only to leds-gpio and devices driven through memory mapped registers. Having the flag e.g. LED_BRIGHTNESS_FAST, we could add support for hr timers also to ledtrig-timer. You can try also the other option mentioned by Pavel in [1]. [1] https://lkml.org/lkml/2017/4/24/881 -- Best regards, Jacek Anaszewski
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer David Lin <dtwlin@google.com> - 2017-04-25 05:10 +0200
Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-04-25 22:20 +0200
Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer David Lin <dtwlin@google.com> - 2017-04-27 05:50 +0200
Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-04-27 20:40 +0200
Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer Pavel Machek <pavel@ucw.cz> - 2017-04-26 00:40 +0200
Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-04-26 22:00 +0200
csiph-web