All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.