Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422868AbbD2L1J (ORCPT ); Wed, 29 Apr 2015 07:27:09 -0400 Received: from smtp52.i.mail.ru ([94.100.177.112]:41985 "EHLO smtp52.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753509AbbD2L1E (ORCPT ); Wed, 29 Apr 2015 07:27:04 -0400 Message-ID: <5540BFFD.4090205@list.ru> Date: Wed, 29 Apr 2015 14:26:53 +0300 From: Stas Sergeev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jacek Anaszewski CC: linux-leds@vger.kernel.org, Linux kernel , Stas Sergeev Subject: Re: [PATCH v2 0/3] leds: blink resolution improvements References: <553E6CF5.4030601@list.ru> <553F4B60.20204@samsung.com> <553F5CFF.9090601@list.ru> <553F83DC.8080701@samsung.com> In-Reply-To: <553F83DC.8080701@samsung.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam: Not detected X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2330 Lines: 51 28.04.2015 15:58, Jacek Anaszewski пишет: > On 04/28/2015 12:12 PM, Stas Sergeev wrote: >> 28.04.2015 11:57, Jacek Anaszewski пишет: >>> Hi Stas, >>> >>> Have you tested it? >> Of course I did. >> Works with gpio driver and provides up to 10usec precision on >> armada-xp board. >> This is 1000 times better than without my patch - the precision >> was 10ms (jiffy). > > Please take into account that this could work reliably only for gpio > LEDs. For the LEDs driven though a bus (e.g. I2C) delays below 1ms > might be hard to achieve. The minimum available delay would vary from > driver to driver. > > We could think of adding the hr_timer mode to the led-class. > The mode could be turned on with use of a new led_set_high_res_timer > API. The API would be called by drivers/leds/leds-gpio.c driver when > a dedicated sysfs attribute was set adequately. > The other drivers could also set this mode if they controlled device > with a suitable LED switching rate. The minimum delay value could > be made configurable by the driver and readable through sysfs > when in hr_timer mode. I've found the SET_BRIGHTNESS_ASYNC and SET_BRIGHTNESS_SYNC flags. Sounds interesting for my patch, but the only "documentation" I was able to find, is this: --- /* Setting a torch brightness needs to have immediate effect */ led_cdev->flags &= ~SET_BRIGHTNESS_ASYNC; led_cdev->flags |= SET_BRIGHTNESS_SYNC; --- Aren't these flags mutually exclusive, and so just one could have been used? Anyway, from that comment I can try to guess that if the driver supports ASYNC mode, it should be fast enough and without sleeps. The drivers that do i2c transfers with sleeps, should be using SYNC mode. Or was the intention for these flags entirely different? My intention is to use either a work-queue or a direct hrtimer callback, depending on whether the driver supports sync or async mode. This is instead of the driver being able to set the minimum delay - much simpler to implement. Makes sense? Can I use the above flags for that purpose, or will I need a new one? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/