From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org,
sakari.ailus@linux.intel.com
Subject: Re: [PATCH 2/5] Documentation: leds: Add description of brightness setting API
Date: Wed, 23 Sep 2015 11:24:01 +0200 [thread overview]
Message-ID: <56026FB1.20804@samsung.com> (raw)
In-Reply-To: <20150922192750.GG20029@lunn.ch>
On 09/22/2015 09:27 PM, Andrew Lunn wrote:
> On Mon, Sep 21, 2015 at 04:29:27PM +0200, Jacek Anaszewski wrote:
>> This patch adds description of the LED subsystem API for
>> setting an LED brightness.
>>
>> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
>> ---
>> Documentation/leds/leds-class.txt | 21 +++++++++++++++++++++
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt
>> index 62261c0..2cc38fa 100644
>> --- a/Documentation/leds/leds-class.txt
>> +++ b/Documentation/leds/leds-class.txt
>> @@ -52,6 +52,27 @@ above leaves scope for further attributes should they be needed. If sections
>> of the name don't apply, just leave that section blank.
>>
>>
>> +Brightness setting API
>> +======================
>> +
>> +LED subsystem core exposes following API for setting brightness:
>> +
>> + - led_set_brightness : if necessary, cancels the software blink timer that
>> + implements blinking when the hardware doesn't; it is guaranteed
>> + not to sleep
>
> I would put this in the reverse order. Not sleeping is the most
> important bit.
OK.
> Also, stopping blinking should also happen if the
> hardware is performing the blinking. There is no need to mention
> software blinking, that is an implementation detail.
OK.
>
> which implies the possibility of delegating the
>> + job to a work queue task (uses led_set_brightness_nosleep
>> + underneath - see below),
>
> This bit is also an implementation detail and not relevant to the API.
>
>
>> + - led_set_brightness_sync : for use cases when immediate effect is desired;
>> + it can block the caller for the time required for accessing
>> + device registers and can sleep,
>
> In fact, i would probably have a separate paragraph that says passing
> LED_OFF to either of these two functions stops blinking.
In case of led_set_brightness_sync passing LED_OFF will disable only
hardware blinking. I noticed this discrepancy before a while. We can't
disable soft blinking, because we would have to do it in a work queue
task, which would in turn compromise the contract offering by the API,
i.e. brightness is guaranteed to be set after function returns.
Since Sakari proposed to return error from the function if soft blinking
is on, then this has to be explicitly stated here too.
--
Best Regards,
Jacek Anaszewski
next prev parent reply other threads:[~2015-09-23 9:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-21 14:29 [PATCH 0/5] LED flash: Set brightness in a sync way on demand Jacek Anaszewski
2015-09-21 14:29 ` [PATCH 1/5] leds: core: Drivers shouldn't enforce SYNC/ASYNC brightness setting Jacek Anaszewski
2015-09-22 6:42 ` Sakari Ailus
2015-09-22 7:09 ` Jacek Anaszewski
2015-09-22 19:16 ` Andrew Lunn
2015-10-08 15:50 ` Pavel Machek
2015-10-09 6:28 ` Jacek Anaszewski
2015-10-09 7:02 ` Pavel Machek
2015-10-09 8:08 ` Jacek Anaszewski
2015-10-09 11:16 ` Pavel Machek
2015-09-21 14:29 ` [PATCH 2/5] Documentation: leds: Add description of brightness setting API Jacek Anaszewski
2015-09-22 10:26 ` Sakari Ailus
2015-09-22 11:03 ` Jacek Anaszewski
2015-09-22 19:27 ` Andrew Lunn
2015-09-23 9:24 ` Jacek Anaszewski [this message]
2015-09-21 14:29 ` [PATCH 3/5] leds: max77693: Remove work queue Jacek Anaszewski
2015-09-22 10:28 ` Sakari Ailus
2015-09-21 14:29 ` [PATCH 4/5] leds: aat1290: " Jacek Anaszewski
2015-09-21 14:29 ` [PATCH 5/5] leds: ktd2692: " Jacek Anaszewski
2015-10-08 15:50 ` Pavel Machek
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=56026FB1.20804@samsung.com \
--to=j.anaszewski@samsung.com \
--cc=andrew@lunn.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=sakari.ailus@linux.intel.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).