linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stas Sergeev <stsp@list.ru>
To: Jacek Anaszewski <j.anaszewski@samsung.com>
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: Mon, 04 May 2015 15:12:55 +0300	[thread overview]
Message-ID: <55476247.6030007@list.ru> (raw)
In-Reply-To: <554725D4.7090805@samsung.com>

04.05.2015 10:55, Jacek Anaszewski пишет:
>> So it seems the problem is already solved on the per-driver
>> basis. I don't have leds-aat1290 driver, it is probably not
>> in the kernel.
> It is currently on linux-next/master branch.
So that driver is not in line with others.

>> It is likely forgetting to use the work-queue
>> the way all other drivers do. So I think my patch is good for
>> the in-kernel drivers.
>>
>> There is also a led_cdev->set_brightness_work, and it looks
>> unused. I could use it for my patch, but for what, if the
>> drivers already use the work queue when needed?
> It is used in led_set_brightness function.
Only under that condition:
---
if (led_cdev->blink_delay_on || led_cdev->blink_delay_off) {
         led_cdev->delayed_set_value = brightness;
         schedule_work(&led_cdev->set_brightness_work);
---

But the main condition is:
---
if (led_cdev->flags & SET_BRIGHTNESS_ASYNC) {
         led_set_brightness_async(led_cdev, brightness);
---

So I think it is actually unused.
I don't see why schedule_work() above can't be just replaced
with led_set_brightness_async(). Is there the reason not to do so?

> I think that using work queues would compromise the whole idea of
> introducing intervals less than 1ms. After the task is delegated to
> work queue we are losing the control over the moment when it will get
> executed.
No one is going to allow sub-ms intervals when work-queue
is used. The proper solution would be to use work-queue for
drivers that can sleep, and allow sub-ms resolution for others.
Fortunately the drivers seem to already have that information
internally, and use work-queue on their own when needed.
leds-aat1290 may be an exception from that.

> I am becoming reluctant towards the whole idea, as we will be
> unable to guarantee the stability of a delay interval.
So why are you against the idea of improving the precision,
rather than against the code that prevents us from doing so?
The per-driver work queue use can be moved to led-core,
and the precise intervals can be guaranteed for the drivers
that do not need work queue.
Now your leds-aat1290 already asks for such a change,
because it can sleep but does not use a work-queue the
way other drivers do.
If I do such a massive change, I will certainly not be able
to properly test it, while you have a good test-case and
even a driver that needs such a change anyway. So I don't
see the point of being against that.

So what should we do?
I can try the aforementioned massive clean-up with removing
the work-queue from every driver and using the one in
led-core, but my attempts have few chances to succeed
because of no test-cases. Or can you do this instead, so
that leds-aat1290 driver is in line with the others? Or any
other options I can try?

  reply	other threads:[~2015-05-04 12:12 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
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 [this message]
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=55476247.6030007@list.ru \
    --to=stsp@list.ru \
    --cc=j.anaszewski@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --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).