Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1633498 > unrolled thread

[PATCH 0/3] led: ledtrig-transient: add support for hrtimer

Started byDavid Lin <dtwlin@google.com>
First post2017-04-30 23:40 +0200
Last post2017-05-09 22:50 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-04-30 23:40 +0200
    [PATCH 2/3] leds: Add the LED_BRIGHTNESS_FAST flag David Lin <dtwlin@google.com> - 2017-04-30 23:40 +0200
    Re: [PATCH 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-05-04 02:30 +0200
    Re: [PATCH 0/3] led: ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-05-08 23:10 +0200
      Re: [PATCH 0/3] led: ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-05-09 22:50 +0200

#1633498 — [PATCH 0/3] led: ledtrig-transient: add support for hrtimer

FromDavid Lin <dtwlin@google.com>
Date2017-04-30 23:40 +0200
Subject[PATCH 0/3] led: ledtrig-transient: add support for hrtimer
Message-ID<tC4Jr-8ub-11@gated-at.bofh.it>
Hi,

These patch series add the LED_BRIGHTNESS_FAST flag support for
ledtrig-transient to use hrtimer so that platforms with high-resolution timer
support can have better accuracy in the trigger duration timing. The need for
this support is driven by the fact that Android has removed the timed_ouput [1]
and is now using led-trigger for handling vibrator control which requires the
timer to be accurate up to a millisecond. However, this flag support would also
allow hrtimer to co-exist with the ktimer without causing warning to the
existing drivers [2].

David

[1] https://patchwork.kernel.org/patch/8664831/
[2] https://lkml.org/lkml/2015/4/28/260

David Lin (3):
  leds: Replace flags bit shift with BIT() macros
  leds: Add the LED_BRIGHTNESS_FAST flag
  led: ledtrig-transient: add support for hrtimer

 Documentation/leds/leds-class.txt        |  5 +++
 drivers/leds/trigger/ledtrig-transient.c | 59 +++++++++++++++++++++++++++++---
 include/linux/leds.h                     | 13 +++----
 3 files changed, 66 insertions(+), 11 deletions(-)

-- 
2.13.0.rc0.306.g87b477812d-goog

[toc] | [next] | [standalone]


#1633499 — [PATCH 2/3] leds: Add the LED_BRIGHTNESS_FAST flag

FromDavid Lin <dtwlin@google.com>
Date2017-04-30 23:40 +0200
Subject[PATCH 2/3] leds: Add the LED_BRIGHTNESS_FAST flag
Message-ID<tC4Js-8ub-29@gated-at.bofh.it>
In reply to#1633498
This patch adds the LED_BRIGHTNESS_FAST flag to allow the driver to
indicate that the brightness_set() callback is implemented on a fastpath
so that the LED core may choose to for example use a hrtimer to
implement the duration of a trigger for better timing accuracy.

Suggested-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: David Lin <dtwlin@google.com>
---
 Documentation/leds/leds-class.txt | 5 +++++
 include/linux/leds.h              | 1 +
 2 files changed, 6 insertions(+)

diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt
index 836cb16d6f09..70d7a3dca621 100644
--- a/Documentation/leds/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -80,6 +80,11 @@ flag must be set in flags before registering. Calling
 led_classdev_notify_brightness_hw_changed on a classdev not registered with
 the LED_BRIGHT_HW_CHANGED flag is a bug and will trigger a WARN_ON.
 
+Optionally, the driver may choose to register with the LED_BRIGHTNESS_FAST flag.
+This flag indicates that the driver implements the brightness_set() callback
+function using a fastpath so the LED core can use hrtimer if the driver requires
+high precision for the trigger timing.
+
 Hardware accelerated blink of LEDs
 ==================================
 
diff --git a/include/linux/leds.h b/include/linux/leds.h
index f9d10a9efcbe..78d2880ccd39 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -49,6 +49,7 @@ struct led_classdev {
 #define LED_HW_PLUGGABLE	BIT(19)
 #define LED_PANIC_INDICATOR	BIT(20)
 #define LED_BRIGHT_HW_CHANGED	BIT(21)
+#define LED_BRIGHTNESS_FAST	BIT(22)
 
 	/* set_brightness_work / blink_timer flags, atomic, private. */
 	unsigned long		work_flags;
-- 
2.13.0.rc0.306.g87b477812d-goog

[toc] | [prev] | [next] | [standalone]


#1635351

FromDavid Lin <dtwlin@google.com>
Date2017-05-04 02:30 +0200
Message-ID<tDcOB-4jz-1@gated-at.bofh.it>
In reply to#1633498
+Cc: Greg KH

On Sun, Apr 30, 2017 at 2:36 PM, David Lin <dtwlin@google.com> wrote:
> Hi,
>
> These patch series add the LED_BRIGHTNESS_FAST flag support for
> ledtrig-transient to use hrtimer so that platforms with high-resolution timer
> support can have better accuracy in the trigger duration timing. The need for
> this support is driven by the fact that Android has removed the timed_ouput [1]
> and is now using led-trigger for handling vibrator control which requires the
> timer to be accurate up to a millisecond. However, this flag support would also
> allow hrtimer to co-exist with the ktimer without causing warning to the
> existing drivers [2].
>
> David
>
> [1] https://patchwork.kernel.org/patch/8664831/
> [2] https://lkml.org/lkml/2015/4/28/260
>
> David Lin (3):
>   leds: Replace flags bit shift with BIT() macros
>   leds: Add the LED_BRIGHTNESS_FAST flag
>   led: ledtrig-transient: add support for hrtimer
>
>  Documentation/leds/leds-class.txt        |  5 +++
>  drivers/leds/trigger/ledtrig-transient.c | 59 +++++++++++++++++++++++++++++---
>  include/linux/leds.h                     | 13 +++----
>  3 files changed, 66 insertions(+), 11 deletions(-)
>
> --
> 2.13.0.rc0.306.g87b477812d-goog
>

[toc] | [prev] | [next] | [standalone]


#1637724

FromPavel Machek <pavel@ucw.cz>
Date2017-05-08 23:10 +0200
Message-ID<tEY4O-I2-25@gated-at.bofh.it>
In reply to#1633498

[Multipart message — attachments visible in raw view] — view raw

On Sun 2017-04-30 14:36:58, David Lin wrote:
> Hi,
> 
> These patch series add the LED_BRIGHTNESS_FAST flag support for
> ledtrig-transient to use hrtimer so that platforms with high-resolution timer
> support can have better accuracy in the trigger duration timing. The need for
> this support is driven by the fact that Android has removed the timed_ouput [1]
> and is now using led-trigger for handling vibrator control which requires the
> timer to be accurate up to a millisecond. However, this flag support would also
> allow hrtimer to co-exist with the ktimer without causing warning to the
> existing drivers [2].

Yes, and objection still stands: You are misusing LED subsystem for
vibration motors. We already have support for haptic feedback in input
subsystem.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]


#1638396

FromJacek Anaszewski <jacek.anaszewski@gmail.com>
Date2017-05-09 22:50 +0200
Message-ID<tFkeZ-6Un-5@gated-at.bofh.it>
In reply to#1637724
On 05/08/2017 11:06 PM, Pavel Machek wrote:
> On Sun 2017-04-30 14:36:58, David Lin wrote:
>> Hi,
>>
>> These patch series add the LED_BRIGHTNESS_FAST flag support for
>> ledtrig-transient to use hrtimer so that platforms with high-resolution timer
>> support can have better accuracy in the trigger duration timing. The need for
>> this support is driven by the fact that Android has removed the timed_ouput [1]
>> and is now using led-trigger for handling vibrator control which requires the
>> timer to be accurate up to a millisecond. However, this flag support would also
>> allow hrtimer to co-exist with the ktimer without causing warning to the
>> existing drivers [2].
> 
> Yes, and objection still stands: You are misusing LED subsystem for
> vibration motors. We already have support for haptic feedback in input
> subsystem.

Regardless of whether it is a misuse or not (ledtrig-transient
documentation suggests that it is one of use cases) we have to keep
it as it has been around for a long time and it has userspace users [0].

Moreover there seems to be broad consensus about it among kernel
people [1].


[0]
https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9b
[1] https://patchwork.kernel.org/patch/8664831/

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web