From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Stas Sergeev <stsp@list.ru>
Cc: linux-leds@vger.kernel.org,
Linux kernel <linux-kernel@vger.kernel.org>,
Stas Sergeev <stsp@users.sourceforge.net>,
Bryan Wu <cooloney@gmail.com>, Richard Purdie <rpurdie@rpsys.net>,
Michael Hennerich <michael.hennerich@analog.com>,
Jan-Simon Moeller <jansimon.moeller@gmx.de>,
Support Opensource <support.opensource@diasemi.com>,
Milo Kim <milo.kim@ti.com>, Riku Voipio <riku.voipio@iki.fi>,
Kyungmin Park <kyungmin.park@samsung.com>,
patches@opensource.wolfsonmicro.com
Subject: Re: [PATCH] leds: put hard limit on minimum blink period for slow leds
Date: Tue, 19 May 2015 08:35:35 +0200 [thread overview]
Message-ID: <555AD9B7.1000803@samsung.com> (raw)
In-Reply-To: <5559A29D.5010204@samsung.com>
On 05/18/2015 10:28 AM, Jacek Anaszewski wrote:
> Hi Stas,
>
> On 05/15/2015 06:47 PM, Stas Sergeev wrote:
>>
>> Currently the timer trigger allows to set blink period as small as
>> 1mS. But in fact the minimum period is jiffy, which is usually 10mS.
>> The following mail says:
>> http://lkml.iu.edu/hypermail/linux/kernel/1504.3/03469.html
>> ---
>
> Text after '---' characters is not added to the commit message.
> Please use different characters for this and check how your patch
> looks in git log after applying it locally.
>
>> As I mentioned before even with hr timer it wouldn't be possible
>> to assure that 1ms is achievable due to locking and bus latency
>> reasons.
>> ---
>> So the limit of 10mS should be enforced for drivers that use
>> waiting operations, like transfers across slow bus.
>> This allows to stay on safe side when CONFIG_HZ is set to eg 1000.
>>
>> This patch differentiates the "slow" drivers by marking them with
>> the new LED_BRIGHTNESS_SLOW flag. Currently every driver that uses
>> a work-queue in .brightness_set op, is marked as such.
>> The extra bonus is the possibility of a further development
>> aiming for software PWM for "fast" drivers.
[...]
>> +#define LED_BRIGHTNESS_SLOW (1 << 24)
I think we'd better add LED_BRIGHTNESS_FAST flag instead.
Then the drivers not using work queue will have to be updated.
It will also indicate what drivers are intended to be the actual
beneficiary of the modification.
--
Best Regards,
Jacek Anaszewski
prev parent reply other threads:[~2015-05-19 6:35 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 16:47 [PATCH] leds: put hard limit on minimum blink period for slow leds Stas Sergeev
2015-05-18 8:28 ` Jacek Anaszewski
2015-05-19 6:35 ` Jacek Anaszewski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555AD9B7.1000803@samsung.com \
--to=j.anaszewski@samsung.com \
--cc=cooloney@gmail.com \
--cc=jansimon.moeller@gmx.de \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=michael.hennerich@analog.com \
--cc=milo.kim@ti.com \
--cc=patches@opensource.wolfsonmicro.com \
--cc=riku.voipio@iki.fi \
--cc=rpurdie@rpsys.net \
--cc=stsp@list.ru \
--cc=stsp@users.sourceforge.net \
--cc=support.opensource@diasemi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).