from:"David Lin"

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

2017-09-28 Thread David Lin

On Wed, Sep 27, 2017 at 10:43 PM, Dmitry Torokhov
 wrote:
>>One thing I noticed is that input_ff_create_memless() also does not
>>use high-resolution timer hence it also does not have the stop-time
>>precision that I'm looking for.
>
> I'll take patches for high resolution timers in ff memless, they should also 
> help with more accurate scheduling of ramping up and fading of events.

Thanks.

>
>>
>>Another thing is that ff_reply duration value is maxed-out at 32767 ms
>>(u16) while the Android/userspace requires size long for performing
>>long notification alert.
>>
>
> You need unattended vibrations lasting longer than 30 seconds? Anyway, 
> replay.length == 0 means endless IIRC, so you only need to schedule stopping. 
> We still will clean up properly if your process crashes or exits or closes 
> the fd.

Yes, it's up to the application to vibrate for as long as it requires.
Is there any concern making the duration variable a type long? [If
this is getting off-topic, I'll follow up with another email]
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-09-27 Thread David Lin

Dmitry,

On Fri, Sep 15, 2017 at 3:30 PM, Dmitry Torokhov
 wrote:
> On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski
>  wrote:
>> On 09/15/2017 08:34 PM, Dmitry Torokhov wrote:
>>> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek  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.
>

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

2017-09-14 Thread David Lin

On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski
 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-09-14 Thread David Lin

On Wed, Sep 13, 2017 at 2:34 PM, Pavel Machek  wrote:
>
> On Wed 2017-09-13 14:20:58, David Lin wrote:
> > On Wed, Sep 13, 2017 at 1: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 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-09-13 Thread David Lin

On Wed, Sep 13, 2017 at 1: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 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-09-13 Thread David Lin

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 
---
 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_INDICATORBIT(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

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-09-13 Thread David Lin

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 
Signed-off-by: David Lin 
---
 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_INDICATORBIT(20)
 #define LED_BRIGHT_HW_CHANGED  BIT(21)
 #define LED_RETAIN_AT_SHUTDOWN BIT(22)
+#define LED_BRIGHTNESS_FASTBIT(23)
 
/* set_brightness_work / blink_timer flags, atomic, private. */
unsigned long   work_flags;
-- 
2.14.1.581.gf28d330327-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-09-13 Thread David Lin

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

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-09-13 Thread David Lin

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 
---
 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 
 #include 
 #include 
+#include 
 #include 
 #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

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-05-03 Thread David Lin

+Cc: Greg KH

On Sun, Apr 30, 2017 at 2:36 PM, 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].
>
> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-04-30 Thread David Lin

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 
---
 include/linux/leds.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/leds.h b/include/linux/leds.h
index 64c56d454f7d..f9d10a9efcbe 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -43,12 +43,12 @@ struct led_classdev {
 #define LED_SUSPENDED  (1 << 0)
 #define LED_UNREGISTERING  (1 << 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_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_INDICATORBIT(20)
+#define LED_BRIGHT_HW_CHANGED  BIT(21)
 
/* set_brightness_work / blink_timer flags, atomic, private. */
unsigned long   work_flags;
-- 
2.13.0.rc0.306.g87b477812d-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-04-30 Thread David Lin

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 
---
 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..63be54772596 100644
--- a/drivers/leds/trigger/ledtrig-transient.c
+++ b/drivers/leds/trigger/ledtrig-transient.c
@@ -24,15 +24,18 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #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 inline 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 inline 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 inline 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.13.0.rc0.306.g87b477812d-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-04-30 Thread David Lin

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 
Signed-off-by: David Lin 
---
 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_INDICATORBIT(20)
 #define LED_BRIGHT_HW_CHANGED  BIT(21)
+#define LED_BRIGHTNESS_FASTBIT(22)
 
/* set_brightness_work / blink_timer flags, atomic, private. */
unsigned long   work_flags;
-- 
2.13.0.rc0.306.g87b477812d-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2017-04-30 Thread David Lin

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

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14 matches

Site Navigation

Mail list logo

Footer information