Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967904AbdD0Dsn (ORCPT ); Wed, 26 Apr 2017 23:48:43 -0400 Received: from mail-yw0-f174.google.com ([209.85.161.174]:34344 "EHLO mail-yw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752139AbdD0Dsl (ORCPT ); Wed, 26 Apr 2017 23:48:41 -0400 MIME-Version: 1.0 In-Reply-To: <475626da-5fb2-c03c-cdf7-feb42ee6b672@gmail.com> References: <20170424044254.145192-1-dtwlin@google.com> <475626da-5fb2-c03c-cdf7-feb42ee6b672@gmail.com> From: David Lin Date: Wed, 26 Apr 2017 20:48:09 -0700 Message-ID: Subject: Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer To: Jacek Anaszewski Cc: rpurdie@rpsys.net, pavel@ucw.cz, robh@kernel.org, Rom Lemarchand , Joel Fernandes , stable@vger.kernel.org, linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1290 Lines: 29 On Tue, Apr 25, 2017 at 1:15 PM, Jacek Anaszewski 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.