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>
Subject: Re: [PATCH v2 0/3] leds: blink resolution improvements
Date: Tue, 28 Apr 2015 14:58:04 +0200 [thread overview]
Message-ID: <553F83DC.8080701@samsung.com> (raw)
In-Reply-To: <553F5CFF.9090601@list.ru>
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 tried it with Samsung M0 board and
>> my leds-aat1290 driver. It didn't work well. And for small delay
>> intervals it will not have a chance to work reliably with all drivers,
>> especially the ones which use mutex in their brightness_set op,
>> since mutex can sleep.
> OK, I can remove the nsec resolution.
usec also didn't work, please look at my use case and warning:
echo "timer" > trigger
echo 1 > delay_on
echo 1 > delay_off
echo usec > delay_unit
[ 178.584433] hrtimer: interrupt took 300747 ns
Only some time later I realized that for AAT1290 brightness is set
through ASCwire pulse protocol, which takes few ms.
Please note that with this approach users would have to wonder why
they are getting the warnings and why they can't get their LEDs to work
with given settings.
> I added it for the future, it doesn't work for me either, but
> hrtimer has an API for it, so I thought it may work on another hw.
> I don't see why it can't stay, but if it bothers you that much,
> I'll remove it.
>
>> I am afraid that we have to stay with what we have currently.
> This is a counter-productive conclusion.
>
> My patch does 1000 times precision improvement with gpio driver.
> If you only want nsec to be removed as it doesn't work - that's
> fine with me.
>
--
Best Regards,
Jacek Anaszewski
next prev parent reply other threads:[~2015-04-28 12:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-27 17:08 [PATCH v2 0/3] leds: blink resolution improvements Stas Sergeev
2015-04-27 17:09 ` [PATCH 1/3] leds: use hrtimer for blinking Stas Sergeev
2015-04-27 17:11 ` Stas Sergeev
2015-04-27 17:12 ` [PATCH 2/3] ledtrig-timer: add blink delay_unit control Stas Sergeev
2015-04-27 17:14 ` [PATCH 3/3] leds: update documentation about new delay units Stas Sergeev
2015-04-27 20:54 ` [PATCH v2 0/3] leds: blink resolution improvements Pavel Machek
2015-04-27 21:14 ` Stas Sergeev
2015-04-30 17:30 ` Pavel Machek
2015-04-30 20:42 ` Stas Sergeev
2015-05-03 10:34 ` Pavel Machek
2015-05-03 11:35 ` Stas Sergeev
2015-05-11 22:11 ` Pavel Machek
2015-04-27 22:23 ` Stas Sergeev
2015-04-28 8:57 ` Jacek Anaszewski
2015-04-28 10:12 ` Stas Sergeev
2015-04-28 12:58 ` Jacek Anaszewski [this message]
2015-04-28 13:26 ` Stas Sergeev
2015-04-29 15:06 ` Jacek Anaszewski
2015-04-29 11:26 ` Stas Sergeev
2015-04-29 15:14 ` Jacek Anaszewski
2015-04-30 17:11 ` Stas Sergeev
2015-05-04 7:55 ` Jacek Anaszewski
2015-05-04 12:12 ` Stas Sergeev
2015-05-04 15:22 ` Jacek Anaszewski
2015-05-04 17:20 ` Stas Sergeev
2015-05-05 8:22 ` Jacek Anaszewski
2015-05-05 13:02 ` Stas Sergeev
2015-05-06 7:20 ` Jacek Anaszewski
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=553F83DC.8080701@samsung.com \
--to=j.anaszewski@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=stsp@list.ru \
--cc=stsp@users.sourceforge.net \
/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).