On Tue, Apr 25, 2017 at 1:15 PM, Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx> wrote: >> 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. Can I resubmit the patch implementing LED_BRIGHTNESS_FAST using hrtimer? > > You can try also the other option mentioned by Pavel in [1]. Thanks, Pavel. It does look like that input-ff is a more appropriate subsystem for implementing a vibrator/haptics driver. It also seems that it's relying on the userspace to control the timing of the play/stop events which is likely to be less accurate than a hrtimer in the kernel. But it provides more effect control than the LED subsystem.