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

Groups > linux.kernel > #1731753 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-13 20:00 +0200
    [PATCH v2 2/3] leds: Add the LED_BRIGHTNESS_FAST flag David Lin <dtwlin@google.com> - 2017-09-13 20:00 +0200
    [PATCH v2 3/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-13 20:00 +0200
    [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros David Lin <dtwlin@google.com> - 2017-09-13 20:00 +0200
      Re: [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-14 21:50 +0200
    Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-13 22:30 +0200
      Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-13 23:30 +0200
        Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-13 23:40 +0200
          Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-14 19:40 +0200
            Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-14 21:50 +0200
      Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-14 21:40 +0200
        Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-14 21:40 +0200
          Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-14 22:10 +0200
        Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-14 23:00 +0200
          Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-15 20:40 +0200
            Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-16 00:00 +0200
              Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-16 00:40 +0200
                Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-17 18:50 +0200
                  Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-17 20:30 +0200
                    Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-17 23:20 +0200
                    Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-18 23:00 +0200
                      Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-19 00:30 +0200
                        Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-19 22:50 +0200
                          Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-19 23:10 +0200
                            Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-20 21:40 +0200
                          Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-20 13:30 +0200
                            Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-20 22:10 +0200
                      Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-20 13:30 +0200
              Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-16 15:10 +0200
          Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-16 00:00 +0200
            Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-16 14:40 +0200
              Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-17 18:50 +0200
                Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-17 20:00 +0200
                  Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-18 22:50 +0200
                    Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-20 13:20 +0200
                      Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-20 20:50 +0200

Page 1 of 2  [1] 2  Next page →

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

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

Changes from v1 to v2:
- Convert all the bit shifting flag in leds.h to use the BIT macro.
- Removed inline modifiers for the timer helper function.

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                     | 19 +++++-----
 3 files changed, 69 insertions(+), 14 deletions(-)

-- 
2.14.1.581.gf28d330327-goog

[toc] | [next] | [standalone]

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

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 5579c64c8fd6..ccfa0a1799fe 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -50,6 +50,7 @@ struct led_classdev {
 #define LED_PANIC_INDICATOR	BIT(20)
 #define LED_BRIGHT_HW_CHANGED	BIT(21)
 #define LED_RETAIN_AT_SHUTDOWN	BIT(22)
+#define LED_BRIGHTNESS_FAST	BIT(23)
 
 	/* set_brightness_work / blink_timer flags, atomic, private. */
 	unsigned long		work_flags;
-- 
2.14.1.581.gf28d330327-goog

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

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

This patch adds a hrtimer to ledtrig-transient so that when driver is
registered with LED_BRIGHTNESS_FAST, the hrtimer is used for the better
time accuracy in handling the duration.

Signed-off-by: David Lin <dtwlin@google.com>
---
 drivers/leds/trigger/ledtrig-transient.c | 59 +++++++++++++++++++++++++++++---
 1 file changed, 54 insertions(+), 5 deletions(-)

diff --git a/drivers/leds/trigger/ledtrig-transient.c b/drivers/leds/trigger/ledtrig-transient.c
index 7e6011bd3646..7d2ce757b39d 100644
--- a/drivers/leds/trigger/ledtrig-transient.c
+++ b/drivers/leds/trigger/ledtrig-transient.c
@@ -24,15 +24,18 @@
 #include <linux/device.h>
 #include <linux/slab.h>
 #include <linux/timer.h>
+#include <linux/hrtimer.h>
 #include <linux/leds.h>
 #include "../leds.h"
 
 struct transient_trig_data {
+	struct led_classdev *led_cdev;
 	int activate;
 	int state;
 	int restore_state;
 	unsigned long duration;
 	struct timer_list timer;
+	struct hrtimer hrtimer;
 };
 
 static void transient_timer_function(unsigned long data)
@@ -44,6 +47,54 @@ static void transient_timer_function(unsigned long data)
 	led_set_brightness_nosleep(led_cdev, transient_data->restore_state);
 }
 
+static enum hrtimer_restart transient_hrtimer_function(struct hrtimer *timer)
+{
+	struct transient_trig_data *transient_data =
+		container_of(timer, struct transient_trig_data, hrtimer);
+
+	transient_timer_function((unsigned long)transient_data->led_cdev);
+
+	return HRTIMER_NORESTART;
+}
+
+static void transient_timer_setup(struct led_classdev *led_cdev)
+{
+	struct transient_trig_data *tdata = led_cdev->trigger_data;
+
+	if (led_cdev->flags & LED_BRIGHTNESS_FAST) {
+		tdata->led_cdev = led_cdev;
+		hrtimer_init(&tdata->hrtimer, CLOCK_MONOTONIC,
+			     HRTIMER_MODE_REL);
+		tdata->hrtimer.function = transient_hrtimer_function;
+	} else {
+		setup_timer(&tdata->timer, transient_timer_function,
+			    (unsigned long)led_cdev);
+	}
+}
+
+static void transient_timer_start(struct led_classdev *led_cdev)
+{
+	struct transient_trig_data *tdata = led_cdev->trigger_data;
+
+	if (led_cdev->flags & LED_BRIGHTNESS_FAST) {
+		hrtimer_start(&tdata->hrtimer, ms_to_ktime(tdata->duration),
+			      HRTIMER_MODE_REL);
+	} else {
+		mod_timer(&tdata->timer,
+			  jiffies + msecs_to_jiffies(tdata->duration));
+	}
+}
+
+static void transient_timer_cancel(struct led_classdev *led_cdev)
+{
+	struct transient_trig_data *tdata = led_cdev->trigger_data;
+
+	if (led_cdev->flags & LED_BRIGHTNESS_FAST)
+		hrtimer_cancel(&tdata->hrtimer);
+	else
+		del_timer_sync(&tdata->timer);
+}
+
 static ssize_t transient_activate_show(struct device *dev,
 		struct device_attribute *attr, char *buf)
 {
@@ -70,7 +121,7 @@ static ssize_t transient_activate_store(struct device *dev,
 
 	/* cancel the running timer */
 	if (state == 0 && transient_data->activate == 1) {
-		del_timer(&transient_data->timer);
+		transient_timer_cancel(led_cdev);
 		transient_data->activate = state;
 		led_set_brightness_nosleep(led_cdev,
 					transient_data->restore_state);
@@ -84,8 +135,7 @@ static ssize_t transient_activate_store(struct device *dev,
 		led_set_brightness_nosleep(led_cdev, transient_data->state);
 		transient_data->restore_state =
 		    (transient_data->state == LED_FULL) ? LED_OFF : LED_FULL;
-		mod_timer(&transient_data->timer,
-			  jiffies + msecs_to_jiffies(transient_data->duration));
+		transient_timer_start(led_cdev);
 	}
 
 	/* state == 0 && transient_data->activate == 0
@@ -182,8 +232,7 @@ static void transient_trig_activate(struct led_classdev *led_cdev)
 	if (rc)
 		goto err_out_state;
 
-	setup_timer(&tdata->timer, transient_timer_function,
-		    (unsigned long) led_cdev);
+	transient_timer_setup(led_cdev);
 	led_cdev->activated = true;
 
 	return;
-- 
2.14.1.581.gf28d330327-goog

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

#1731757 — [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros

This is for readability as well as to avoid checkpatch warnings when
adding new bit flag information in the future.

Signed-off-by: David Lin <dtwlin@google.com>
---
 include/linux/leds.h | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/linux/leds.h b/include/linux/leds.h
index bf6db4fe895b..5579c64c8fd6 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -40,16 +40,16 @@ struct led_classdev {
 	int			 flags;
 
 	/* Lower 16 bits reflect status */
-#define LED_SUSPENDED		(1 << 0)
-#define LED_UNREGISTERING	(1 << 1)
+#define LED_SUSPENDED		BIT(0)
+#define LED_UNREGISTERING	BIT(1)
 	/* Upper 16 bits reflect control information */
-#define LED_CORE_SUSPENDRESUME	(1 << 16)
-#define LED_SYSFS_DISABLE	(1 << 17)
-#define LED_DEV_CAP_FLASH	(1 << 18)
-#define LED_HW_PLUGGABLE	(1 << 19)
-#define LED_PANIC_INDICATOR	(1 << 20)
-#define LED_BRIGHT_HW_CHANGED	(1 << 21)
-#define LED_RETAIN_AT_SHUTDOWN	(1 << 22)
+#define LED_CORE_SUSPENDRESUME	BIT(16)
+#define LED_SYSFS_DISABLE	BIT(17)
+#define LED_DEV_CAP_FLASH	BIT(18)
+#define LED_HW_PLUGGABLE	BIT(19)
+#define LED_PANIC_INDICATOR	BIT(20)
+#define LED_BRIGHT_HW_CHANGED	BIT(21)
+#define LED_RETAIN_AT_SHUTDOWN	BIT(22)
 
 	/* set_brightness_work / blink_timer flags, atomic, private. */
 	unsigned long		work_flags;
-- 
2.14.1.581.gf28d330327-goog

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

#1732539 — Re: [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros

Hi David,

Thanks for the patch.

On 09/13/2017 07:53 PM, David Lin wrote:
> This is for readability as well as to avoid checkpatch warnings when
> adding new bit flag information in the future.
> 
> Signed-off-by: David Lin <dtwlin@google.com>
> ---
>  include/linux/leds.h | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index bf6db4fe895b..5579c64c8fd6 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -40,16 +40,16 @@ struct led_classdev {
>  	int			 flags;
>  
>  	/* Lower 16 bits reflect status */
> -#define LED_SUSPENDED		(1 << 0)
> -#define LED_UNREGISTERING	(1 << 1)
> +#define LED_SUSPENDED		BIT(0)
> +#define LED_UNREGISTERING	BIT(1)
>  	/* Upper 16 bits reflect control information */
> -#define LED_CORE_SUSPENDRESUME	(1 << 16)
> -#define LED_SYSFS_DISABLE	(1 << 17)
> -#define LED_DEV_CAP_FLASH	(1 << 18)
> -#define LED_HW_PLUGGABLE	(1 << 19)
> -#define LED_PANIC_INDICATOR	(1 << 20)
> -#define LED_BRIGHT_HW_CHANGED	(1 << 21)
> -#define LED_RETAIN_AT_SHUTDOWN	(1 << 22)
> +#define LED_CORE_SUSPENDRESUME	BIT(16)
> +#define LED_SYSFS_DISABLE	BIT(17)
> +#define LED_DEV_CAP_FLASH	BIT(18)
> +#define LED_HW_PLUGGABLE	BIT(19)
> +#define LED_PANIC_INDICATOR	BIT(20)
> +#define LED_BRIGHT_HW_CHANGED	BIT(21)
> +#define LED_RETAIN_AT_SHUTDOWN	BIT(22)
>  
>  	/* set_brightness_work / blink_timer flags, atomic, private. */
>  	unsigned long		work_flags;
> 

This one should not raise any doubts.

Applied to the for-4.15 branch of linux-leds.git.

-- 
Best regards,
Jacek Anaszewski

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

#1731836

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

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].

NAK.

LEDs do not need extra overhead, and vibrator control should not go
through LED subsystem.

Input subsystem includes support for vibrations and force
feedback. Please use that instead.

									Pavel

> 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                     | 19 +++++-----
>  3 files changed, 69 insertions(+), 14 deletions(-)
> 

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

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

#1731885

On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek <pavel@ucw.cz> 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].
>
> NAK.
>
> LEDs do not need extra overhead, and vibrator control should not go
> through LED subsystem.
>
> Input subsystem includes support for vibrations and force
> feedback. Please use that instead.

I thought we are already over this discussion. As of now, the support
of vibrator through ledtrig is documented
(Documentation/leds/ledtrig-transient.txt) and there are users using
it.

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

#1731889

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

On Wed 2017-09-13 14:20:58, David Lin wrote:
> On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek <pavel@ucw.cz> 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].
> >
> > NAK.
> >
> > LEDs do not need extra overhead, and vibrator control should not go
> > through LED subsystem.
> >
> > Input subsystem includes support for vibrations and force
> > feedback. Please use that instead.
> 
> I thought we are already over this discussion. As of now, the support
> of vibrator through ledtrig is documented
> (Documentation/leds/ledtrig-transient.txt) and there are users using
> it.

I also thought we are over with that discussion.

Yes, I'm working on fixing the docs.

What mainline users are doing that?

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

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

#1732480

On Wed, Sep 13, 2017 at 2:34 PM, Pavel Machek <pavel@ucw.cz> wrote:
>
> On Wed 2017-09-13 14:20:58, David Lin wrote:
> > On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek <pavel@ucw.cz> 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].
> > >
> > > NAK.
> > >
> > > LEDs do not need extra overhead, and vibrator control should not go
> > > through LED subsystem.
> > >
> > > Input subsystem includes support for vibrations and force
> > > feedback. Please use that instead.
> >
> > I thought we are already over this discussion. As of now, the support
> > of vibrator through ledtrig is documented
> > (Documentation/leds/ledtrig-transient.txt) and there are users using
> > it.
>
> I also thought we are over with that discussion.
>
> Yes, I'm working on fixing the docs.
>
> What mainline users are doing that?

Please refer to patch:
https://patchwork.kernel.org/patch/8664831/ and
https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9b

I don't think currently there are drivers in the mainline using it
yet, the reason being most of the Android devices are still on 4.4
kernel which still uses the legacy timed_output device.

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

#1732542

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

Hi!

> > > > NAK.
> > > >
> > > > LEDs do not need extra overhead, and vibrator control should not go
> > > > through LED subsystem.
> > > >
> > > > Input subsystem includes support for vibrations and force
> > > > feedback. Please use that instead.
> > >
> > > I thought we are already over this discussion. As of now, the support
> > > of vibrator through ledtrig is documented
> > > (Documentation/leds/ledtrig-transient.txt) and there are users using
> > > it.

Stop misleading people. No _users_ are using Android on mainline
kernel, as there is not a single Android phone supported by mainline
kernel.

> > I also thought we are over with that discussion.
> >
> > Yes, I'm working on fixing the docs.
> >
> > What mainline users are doing that?
> 
> Please refer to patch:
> https://patchwork.kernel.org/patch/8664831/ and
> https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9b
> 
> I don't think currently there are drivers in the mainline using it
> yet, the reason being most of the Android devices are still on 4.4
> kernel which still uses the legacy timed_output device.

Ok. I'm sorry commit 61701df363310a5cbd95e3e1638baa9526e42c9b pushed
your libhardware into wrong direction, but that is exactly what
happened.

LED subsystem is not suitable for vibrations. We have input subsystem
for that, it is handling vibrations for 10+ years, and for example
Nokia N900 cellphone (which is supported by mainline) uses them.

Please fix libhardware accordingly.

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

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

#1732534

Hi David and Pavel,

On 09/13/2017 10:20 PM, Pavel Machek 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].
> 
> NAK.
> 
> LEDs do not need extra overhead, and vibrator control should not go
> through LED subsystem.
> 
> Input subsystem includes support for vibrations and force
> feedback. Please use that instead.

I think that most vital criterion here is the usability of the
interface. If it can be harnessed for doing the work seemingly
unrelated to the primary subsystem's purpose, that's fine.
Moreover, it is extremely easy to use in comparison to the force
feedback one.

I would change one more thing in this patch, though. The hr_timer engine
should be made optional and not used by default for fast LEDs.
It could be made configurable by exposing additional sysfs file from
ledtrig-transient.c, e.g. hr_timer_support, accepting boolean value.

-- 
Best regards,
Jacek Anaszewski

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

#1732537

On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
> I would change one more thing in this patch, though. The hr_timer engine
> should be made optional and not used by default for fast LEDs.
> It could be made configurable by exposing additional sysfs file from
> ledtrig-transient.c, e.g. hr_timer_support, accepting boolean value.

Do you mean in additional to checking the LED_BRIGHTNESS_FAST flag,
userspace has to explicitly enable it via sysfs for ledtrig to select
hrtimer? This seems to be redundant to me. Could you please explain
your concerns and the benefit of doing this? Thanks.

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

#1732547

On 09/14/2017 09:38 PM, David Lin wrote:
> On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski
> <jacek.anaszewski@gmail.com> wrote:
>> I would change one more thing in this patch, though. The hr_timer engine
>> should be made optional and not used by default for fast LEDs.
>> It could be made configurable by exposing additional sysfs file from
>> ledtrig-transient.c, e.g. hr_timer_support, accepting boolean value.
> 
> Do you mean in additional to checking the LED_BRIGHTNESS_FAST flag,
> userspace has to explicitly enable it via sysfs for ledtrig to select
> hrtimer? This seems to be redundant to me. Could you please explain
> your concerns and the benefit of doing this? Thanks.

My concern is that fast LED users would be automatically
imposed a hr_timer overhead, which they may not need.

-- 
Best regards,
Jacek Anaszewski

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

#1732571 — Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

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

On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote:
> Hi David and Pavel,
> 
> On 09/13/2017 10:20 PM, Pavel Machek 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].
> > 
> > NAK.
> > 
> > LEDs do not need extra overhead, and vibrator control should not go
> > through LED subsystem.
> > 
> > Input subsystem includes support for vibrations and force
> > feedback. Please use that instead.
> 
> I think that most vital criterion here is the usability of the
> interface. If it can be harnessed for doing the work seemingly
> unrelated to the primary subsystem's purpose, that's fine.
> Moreover, it is extremely easy to use in comparison to the force
> feedback one.

Well, no.

Kernel is supposed to provide hardware abstraction, that means it
should hide differences between different devices.

And we already have devices using input as designed. We don't want to
have situation where "on phones A, D and E, vibrations are handled via
input, while on B, C and F, they are handled via /sys/class/leds".

If we want to have discussion "how to make vibrations in input
easier to use", well that's fair. But I don't think it is particulary hard.

If we want to say "lets move all vibrations from input to LED
subsystem"... I don't think that is good idea, but its a valid
discussion. Some good reasons would be needed.

But having half devices use one interface and half use different one
is just bad... especially when only reason to do it that way is
"David wants to do it that way, android library made a mistake and he
now wants it to propagate to whole world".

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

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

#1733009 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> wrote:
> On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote:
>> Hi David and Pavel,
>>
>> On 09/13/2017 10:20 PM, Pavel Machek 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].
>> >
>> > NAK.
>> >
>> > LEDs do not need extra overhead, and vibrator control should not go
>> > through LED subsystem.
>> >
>> > Input subsystem includes support for vibrations and force
>> > feedback. Please use that instead.
>>
>> I think that most vital criterion here is the usability of the
>> interface. If it can be harnessed for doing the work seemingly
>> unrelated to the primary subsystem's purpose, that's fine.
>> Moreover, it is extremely easy to use in comparison to the force
>> feedback one.
>
> Well, no.
>
> Kernel is supposed to provide hardware abstraction, that means it
> should hide differences between different devices.
>
> And we already have devices using input as designed. We don't want to
> have situation where "on phones A, D and E, vibrations are handled via
> input, while on B, C and F, they are handled via /sys/class/leds".
>
> If we want to have discussion "how to make vibrations in input
> easier to use", well that's fair. But I don't think it is particulary hard.
>

I would like to know more about why you find the FF interface hard,
given that for rumble you need calls - one ioctl to set up rumble
parameters, and a write to start the playback. The FF core should take
care of handling duration of the effect, ramping it up and decaying,
if desired, and we make sure to automatically stop effects when
userspace closes the fd (because of ordinary exit or crash or FD being
revoked).

> If we want to say "lets move all vibrations from input to LED
> subsystem"... I don't think that is good idea, but its a valid
> discussion. Some good reasons would be needed.
>
> But having half devices use one interface and half use different one
> is just bad...

Completely agree here. I just merged PWM vibra driver from Sebastian
Reichel, we already had regulator-haptic driver, do we need gpio-based
one? Or make regulator-based one working with fixed regulators?

Thanks.

-- 
Dmitry

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

#1733111 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On 09/15/2017 08:34 PM, Dmitry Torokhov wrote:
> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote:
>>> Hi David and Pavel,
>>>
>>> On 09/13/2017 10:20 PM, Pavel Machek 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].
>>>>
>>>> NAK.
>>>>
>>>> LEDs do not need extra overhead, and vibrator control should not go
>>>> through LED subsystem.
>>>>
>>>> Input subsystem includes support for vibrations and force
>>>> feedback. Please use that instead.
>>>
>>> I think that most vital criterion here is the usability of the
>>> interface. If it can be harnessed for doing the work seemingly
>>> unrelated to the primary subsystem's purpose, that's fine.
>>> Moreover, it is extremely easy to use in comparison to the force
>>> feedback one.
>>
>> Well, no.
>>
>> Kernel is supposed to provide hardware abstraction, that means it
>> should hide differences between different devices.
>>
>> And we already have devices using input as designed. We don't want to
>> have situation where "on phones A, D and E, vibrations are handled via
>> input, while on B, C and F, they are handled via /sys/class/leds".
>>
>> If we want to have discussion "how to make vibrations in input
>> easier to use", well that's fair. But I don't think it is particulary hard.
>>
> 
> I would like to know more about why you find the FF interface hard,

led-transient trigger can be activated using only following bash
commands:

# echo 1 > state
# echo 1000 > duration
# while [ 1 ]; do echo 1 > activate; sleep 3; done

Could you share sample sequence of commands to use ff driver?

> given that for rumble you need calls - one ioctl to set up rumble
> parameters, and a write to start the playback. The FF core should take
> care of handling duration of the effect, ramping it up and decaying,
> if desired, and we make sure to automatically stop effects when
> userspace closes the fd (because of ordinary exit or crash or FD being
> revoked).
> 
>> If we want to say "lets move all vibrations from input to LED
>> subsystem"... I don't think that is good idea, but its a valid
>> discussion. Some good reasons would be needed.
>>
>> But having half devices use one interface and half use different one
>> is just bad...
> 
> Completely agree here. I just merged PWM vibra driver from Sebastian
> Reichel, we already had regulator-haptic driver, do we need gpio-based
> one? Or make regulator-based one working with fixed regulators?

Just to clarify: the background of this discussion is the question
whether we should remove the following lines from
Documentation/leds/ledtrig-transient.txt:

-As a specific example of this use-case, let's look at vibrate feature on
-phones. Vibrate function on phones is implemented using PWM pins on SoC or
-PMIC. There is a need to activate one shot timer to control the vibrate
-feature, to prevent user space crashes leaving the phone in vibrate mode
-permanently causing the battery to drain.
whether we should remove the following use case example from

In effect Pavel has objections to increasing ledtrig-transient
interval accuracy by adding hr_timer support to it, because vibrate
devices, as one of the use cases, can benefit from it.

So there are two issues:
1. Addition of hr_timer support to LED trigger.
2. Removal of vibrate devices use case from ledtrig-transient doc.

I am in favour of 1. and against 2. since we're not gaining anything
by hiding information about some kernel functionality when it will
still be there. It also doesn't define the location of any vibrate
device drivers, since sheer leds-gpio driver can be used for that
purpose.

-- 
Best regards,
Jacek Anaszewski

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

#1733128 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
> On 09/15/2017 08:34 PM, Dmitry Torokhov wrote:
>> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> wrote:
>>> On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote:
>>>> Hi David and Pavel,
>>>>
>>>> On 09/13/2017 10:20 PM, Pavel Machek 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].
>>>>>
>>>>> NAK.
>>>>>
>>>>> LEDs do not need extra overhead, and vibrator control should not go
>>>>> through LED subsystem.
>>>>>
>>>>> Input subsystem includes support for vibrations and force
>>>>> feedback. Please use that instead.
>>>>
>>>> I think that most vital criterion here is the usability of the
>>>> interface. If it can be harnessed for doing the work seemingly
>>>> unrelated to the primary subsystem's purpose, that's fine.
>>>> Moreover, it is extremely easy to use in comparison to the force
>>>> feedback one.
>>>
>>> Well, no.
>>>
>>> Kernel is supposed to provide hardware abstraction, that means it
>>> should hide differences between different devices.
>>>
>>> And we already have devices using input as designed. We don't want to
>>> have situation where "on phones A, D and E, vibrations are handled via
>>> input, while on B, C and F, they are handled via /sys/class/leds".
>>>
>>> If we want to have discussion "how to make vibrations in input
>>> easier to use", well that's fair. But I don't think it is particulary hard.
>>>
>>
>> I would like to know more about why you find the FF interface hard,
>
> led-transient trigger can be activated using only following bash
> commands:
>
> # echo 1 > state
> # echo 1000 > duration
> # while [ 1 ]; do echo 1 > activate; sleep 3; done
>
> Could you share sample sequence of commands to use ff driver?

Cut what you need from this:
https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c

If your objection is that FF is not easily engaged from the shell -
yes, but I do not think that actual users who want to do vibration do
that via shell either. On the other hand, can you drop privileges and
still allow a certain process control your vibrator via LED interface?
With FF you can pass an FD to whoever you deem worthy and later revoke
access.

IOW sysfs interfaces are nice for quick hacks, but when you want to
use them in real frameworks, where you need to think about proper
namespaces, isolation, etc, etc, other kinds of interfaces might suit
better.

>
>> given that for rumble you need calls - one ioctl to set up rumble
>> parameters, and a write to start the playback. The FF core should take
>> care of handling duration of the effect, ramping it up and decaying,
>> if desired, and we make sure to automatically stop effects when
>> userspace closes the fd (because of ordinary exit or crash or FD being
>> revoked).
>>
>>> If we want to say "lets move all vibrations from input to LED
>>> subsystem"... I don't think that is good idea, but its a valid
>>> discussion. Some good reasons would be needed.
>>>
>>> But having half devices use one interface and half use different one
>>> is just bad...
>>
>> Completely agree here. I just merged PWM vibra driver from Sebastian
>> Reichel, we already had regulator-haptic driver, do we need gpio-based
>> one? Or make regulator-based one working with fixed regulators?
>
> Just to clarify: the background of this discussion is the question
> whether we should remove the following lines from
> Documentation/leds/ledtrig-transient.txt:
>
> -As a specific example of this use-case, let's look at vibrate feature on
> -phones. Vibrate function on phones is implemented using PWM pins on SoC or
> -PMIC. There is a need to activate one shot timer to control the vibrate
> -feature, to prevent user space crashes leaving the phone in vibrate mode
> -permanently causing the battery to drain.
> whether we should remove the following use case example from
>
> In effect Pavel has objections to increasing ledtrig-transient
> interval accuracy by adding hr_timer support to it, because vibrate
> devices, as one of the use cases, can benefit from it.
>
> So there are two issues:
> 1. Addition of hr_timer support to LED trigger.
> 2. Removal of vibrate devices use case from ledtrig-transient doc.
>
> I am in favour of 1. and against 2. since we're not gaining anything
> by hiding information about some kernel functionality when it will
> still be there. It also doesn't define the location of any vibrate
> device drivers, since sheer leds-gpio driver can be used for that
> purpose.

I would say that while leds-gpio can be used to do whatever (you can
wire PS/2 mouse to a set of gpios and probably manage to drive it
through a set of leds-gpio devices) it does not make it right
interface for everything. We do have a standard interface for haptic
(via rumble FF), at this moment I see no reason why we need another
one. It just confuses userspace as it now needs to implement multiple
interfaces, depending on the system it runs. Android expects that HAL
will take care of hiding all of that from their upper layers and does
not really pay close attention to kernel ABIs, but I think we should.

Thanks.

-- 
Dmitry

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

#1733494 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On 09/16/2017 12:30 AM, Dmitry Torokhov wrote:
> On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski
> <jacek.anaszewski@gmail.com> wrote:
>> On 09/15/2017 08:34 PM, Dmitry Torokhov wrote:
>>> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> wrote:
>>>> On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote:
>>>>> Hi David and Pavel,
>>>>>
>>>>> On 09/13/2017 10:20 PM, Pavel Machek 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].
>>>>>>
>>>>>> NAK.
>>>>>>
>>>>>> LEDs do not need extra overhead, and vibrator control should not go
>>>>>> through LED subsystem.
>>>>>>
>>>>>> Input subsystem includes support for vibrations and force
>>>>>> feedback. Please use that instead.
>>>>>
>>>>> I think that most vital criterion here is the usability of the
>>>>> interface. If it can be harnessed for doing the work seemingly
>>>>> unrelated to the primary subsystem's purpose, that's fine.
>>>>> Moreover, it is extremely easy to use in comparison to the force
>>>>> feedback one.
>>>>
>>>> Well, no.
>>>>
>>>> Kernel is supposed to provide hardware abstraction, that means it
>>>> should hide differences between different devices.
>>>>
>>>> And we already have devices using input as designed. We don't want to
>>>> have situation where "on phones A, D and E, vibrations are handled via
>>>> input, while on B, C and F, they are handled via /sys/class/leds".
>>>>
>>>> If we want to have discussion "how to make vibrations in input
>>>> easier to use", well that's fair. But I don't think it is particulary hard.
>>>>
>>>
>>> I would like to know more about why you find the FF interface hard,
>>
>> led-transient trigger can be activated using only following bash
>> commands:
>>
>> # echo 1 > state
>> # echo 1000 > duration
>> # while [ 1 ]; do echo 1 > activate; sleep 3; done
>>
>> Could you share sample sequence of commands to use ff driver?
> 
> Cut what you need from this:
> https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c
> 
> If your objection is that FF is not easily engaged from the shell -
> yes, but I do not think that actual users who want to do vibration do
> that via shell either. On the other hand, can you drop privileges and
> still allow a certain process control your vibrator via LED interface?
> With FF you can pass an FD to whoever you deem worthy and later revoke
> access.
> 
> IOW sysfs interfaces are nice for quick hacks, but when you want to
> use them in real frameworks, where you need to think about proper
> namespaces, isolation, etc, etc, other kinds of interfaces might suit
> better.

I'd leave the decision to the user. We could add a note to the
Documentation/leds/ledtrig-transient.txt that force feedback interface
should be preferable choice for driving vibrate devices.
However only if following conditions are met:
- force feedback driver supports gpio driven devices
- there is sample application in tools/input showing how to
  setup gpio driven vibrate device with use of ff interface
- it will be possible to setup vibrate interval with 1ms accuracy,
  similarly to what the discussed patch allows to do

>>
>>> given that for rumble you need calls - one ioctl to set up rumble
>>> parameters, and a write to start the playback. The FF core should take
>>> care of handling duration of the effect, ramping it up and decaying,
>>> if desired, and we make sure to automatically stop effects when
>>> userspace closes the fd (because of ordinary exit or crash or FD being
>>> revoked).
>>>
>>>> If we want to say "lets move all vibrations from input to LED
>>>> subsystem"... I don't think that is good idea, but its a valid
>>>> discussion. Some good reasons would be needed.
>>>>
>>>> But having half devices use one interface and half use different one
>>>> is just bad...
>>>
>>> Completely agree here. I just merged PWM vibra driver from Sebastian
>>> Reichel, we already had regulator-haptic driver, do we need gpio-based
>>> one? Or make regulator-based one working with fixed regulators?
>>
>> Just to clarify: the background of this discussion is the question
>> whether we should remove the following lines from
>> Documentation/leds/ledtrig-transient.txt:
>>
>> -As a specific example of this use-case, let's look at vibrate feature on
>> -phones. Vibrate function on phones is implemented using PWM pins on SoC or
>> -PMIC. There is a need to activate one shot timer to control the vibrate
>> -feature, to prevent user space crashes leaving the phone in vibrate mode
>> -permanently causing the battery to drain.
>> whether we should remove the following use case example from
>>
>> In effect Pavel has objections to increasing ledtrig-transient
>> interval accuracy by adding hr_timer support to it, because vibrate
>> devices, as one of the use cases, can benefit from it.
>>
>> So there are two issues:
>> 1. Addition of hr_timer support to LED trigger.
>> 2. Removal of vibrate devices use case from ledtrig-transient doc.
>>
>> I am in favour of 1. and against 2. since we're not gaining anything
>> by hiding information about some kernel functionality when it will
>> still be there. It also doesn't define the location of any vibrate
>> device drivers, since sheer leds-gpio driver can be used for that
>> purpose.
> 
> I would say that while leds-gpio can be used to do whatever (you can
> wire PS/2 mouse to a set of gpios and probably manage to drive it
> through a set of leds-gpio devices) it does not make it right
> interface for everything. We do have a standard interface for haptic
> (via rumble FF), at this moment I see no reason why we need another
> one. It just confuses userspace as it now needs to implement multiple
> interfaces, depending on the system it runs. Android expects that HAL
> will take care of hiding all of that from their upper layers and does
> not really pay close attention to kernel ABIs, but I think we should.

Generally I agree, provided that user will be able to achieve the
same using force feedback device as in case of LED transient
trigger, with the same easy guidance on how to employ it to do this
particular task with given hardware configuration.

-- 
Best regards,
Jacek Anaszewski

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

#1733514 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

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

Hi!

> > If your objection is that FF is not easily engaged from the shell -
> > yes, but I do not think that actual users who want to do vibration do
> > that via shell either. On the other hand, can you drop privileges and
> > still allow a certain process control your vibrator via LED interface?
> > With FF you can pass an FD to whoever you deem worthy and later revoke
> > access.
> > 
> > IOW sysfs interfaces are nice for quick hacks, but when you want to
> > use them in real frameworks, where you need to think about proper
> > namespaces, isolation, etc, etc, other kinds of interfaces might suit
> > better.
> 
> I'd leave the decision to the user. We could add a note to the
> Documentation/leds/ledtrig-transient.txt that force feedback interface
> should be preferable choice for driving vibrate devices.

We don't want to leave decision to the user; because then we'll end up
with userland applications having to support _both_ interfaces.

Plus, it is not really your decision. Dmitry is maintainer of input
subsystem, input was doing force feedback for 10+ years, and he
already made a decision.

> However only if following conditions are met:
> - force feedback driver supports gpio driven devices
> - there is sample application in tools/input showing how to
>   setup gpio driven vibrate device with use of ff interface
> - it will be possible to setup vibrate interval with 1ms accuracy,
>   similarly to what the discussed patch allows to do

I agree these would be nice. Interested parties are welcome to help
there. But I don't think this should have any impact on LED
susbystem. Force feedback just does not belong to LED subsystem.

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

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

#1733538 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

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

Hi!

> > However only if following conditions are met:
> > - force feedback driver supports gpio driven devices

INPUT_PWM_VIBRA option was just merged into v4.14.

 									Pavel



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

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web