linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean-Jacques Hiblot <jjhiblot@ti.com>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>, <pavel@ucw.cz>,
	<daniel.thompson@linaro.org>
Cc: <linux-leds@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<dmurphy@ti.com>, <tomi.valkeinen@ti.com>
Subject: Re: [PATCH v4 1/3] led: make led_set_brightness_sync() use led_set_brightness_nosleep()
Date: Tue, 24 Sep 2019 15:43:21 +0200	[thread overview]
Message-ID: <360f37a8-da8d-6ea9-3164-35d2289097dc@ti.com> (raw)
In-Reply-To: <2de8d45c-dc0f-90d2-ed8d-96494a6386c1@gmail.com>


On 23/09/2019 23:03, Jacek Anaszewski wrote:
> Hi Jean,
>
> On 9/23/19 11:14 AM, Jean-Jacques Hiblot wrote:
>> Hi Jacek,
>>
>> On 20/09/2019 23:10, Jacek Anaszewski wrote:
>>> Hi Jean,
>>>
>>> On 9/20/19 2:25 PM, Jean-Jacques Hiblot wrote:
>>>> Making led_set_brightness_sync() use led_set_brightness_nosleep() has 2
>>>> advantages:
>>>> - works for LED controllers that do not provide
>>>> brightness_set_blocking()
>>>> - When the blocking callback is used, it uses the workqueue to update
>>>> the
>>>>     LED state, removing the need for mutual exclusion between
>>>>     led_set_brightness_sync() and set_brightness_delayed().
>>> And third:
>>>
>>> - it compromises the "sync" part of the function name :-)
>> Making it sync is the role of the flush_work() function. It waits until
>> the deferred work has been done.
> The thing is not in the blocking character of the function, but rather
> in the fastest possible way of setting torch brightness.
> led_set_brightness_nosleep() will defer brightness_set_blocking op
> to the workqueue so this condition will not be met then.

OK. I see the point there.

>
> This function was added specifically for LED class flash v4l2 wrapper:
> drivers/media/v4l2-core/v4l2-flash-led-class.c.
>
> It may need an addition of support for brightness_set only drivers,
> but we haven't had a use case so far, since all client flash LED
> controllers are driven via blocking buses (there are not many of them).
>
> Also, when LED flash class (and thus LED class also as a parent)
> is hijacked by v4l2-flash-led wrapper, its sysfs is disabled,
> so it is not possible to set e.g. timer trigger which could
> interfere with the led_set_brightness_sync() (and it also returns
> -EBUSY when blinking is enabled).

Then this is a really special use case and we don't really have to  
worry about synchronization with the other ways to set the LED 
brightness. I'll drop any change to this function then.

Thanks for the detailed explanation.

JJ


>
>>> This function has been introduced specifically to be blocking
>>> and have the immediate effect. Its sole client is
>>> drivers/media/v4l2-core/v4l2-flash-led-class.c.
>>>
>>>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
>>>> ---
>>>>    drivers/leds/led-core.c | 12 +++++++-----
>>>>    1 file changed, 7 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
>>>> index f1f718dbe0f8..50e28a8f9357 100644
>>>> --- a/drivers/leds/led-core.c
>>>> +++ b/drivers/leds/led-core.c
>>>> @@ -294,15 +294,17 @@ EXPORT_SYMBOL_GPL(led_set_brightness_nosleep);
>>>>    int led_set_brightness_sync(struct led_classdev *led_cdev,
>>>>                    enum led_brightness value)
>>>>    {
>>>> +    int ret;
>>>> +
>>>>        if (led_cdev->blink_delay_on || led_cdev->blink_delay_off)
>>>>            return -EBUSY;
>>>>    -    led_cdev->brightness = min(value, led_cdev->max_brightness);
>>>> -
>>>> -    if (led_cdev->flags & LED_SUSPENDED)
>>>> -        return 0;
>>>> +    ret = led_set_brightness_nosleep(led_cdev, value);
>>>> +    if (!ret)
>>>> +        return ret;
>>>>    -    return __led_set_brightness_blocking(led_cdev,
>>>> led_cdev->brightness);
>>>> +    flush_work(&led_cdev->set_brightness_work);
>>>> +    return 0;
>>>>    }
>>>>    EXPORT_SYMBOL_GPL(led_set_brightness_sync);
>>>>   

  reply	other threads:[~2019-09-24 13:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20 12:25 [PATCH v4 0/3] leds: Add control of the voltage/current regulator to the LED core Jean-Jacques Hiblot
2019-09-20 12:25 ` [PATCH v4 1/3] led: make led_set_brightness_sync() use led_set_brightness_nosleep() Jean-Jacques Hiblot
2019-09-20 21:10   ` Jacek Anaszewski
2019-09-23  9:14     ` Jean-Jacques Hiblot
2019-09-23 21:03       ` Jacek Anaszewski
2019-09-24 13:43         ` Jean-Jacques Hiblot [this message]
2019-09-21 16:13   ` kbuild test robot
2019-09-20 12:25 ` [PATCH v4 2/3] dt-bindings: leds: document the "power-supply" property Jean-Jacques Hiblot
2019-09-20 12:25 ` [PATCH v4 3/3] leds: Add control of the voltage/current regulator to the LED core Jean-Jacques Hiblot

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=360f37a8-da8d-6ea9-3164-35d2289097dc@ti.com \
    --to=jjhiblot@ti.com \
    --cc=daniel.thompson@linaro.org \
    --cc=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=tomi.valkeinen@ti.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).