From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Baolin Wang <baolin.wang@linaro.org>, pavel@ucw.cz
Cc: rteysseyre@gmail.com, bjorn.andersson@linaro.org,
broonie@kernel.org, linus.walleij@linaro.org,
linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller
Date: Tue, 4 Sep 2018 22:19:43 +0200 [thread overview]
Message-ID: <ff34b0fd-dd56-f239-94a9-d84673f6869a@gmail.com> (raw)
In-Reply-To: <e7642c73ac1c20b97990a887f76f2f51c41f930b.1536027873.git.baolin.wang@linaro.org>
Hi Baolin,
On 09/04/2018 01:01 PM, Baolin Wang wrote:
> This patch implements the 'pattern_set'and 'pattern_clear'
> interfaces to support SC27XX LED breathing mode.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
> ---
> Changes from v7:
> - Add its own ABI documentation file.
>
> Changes from v6:
> - None.
>
> Changes from v5:
> - None.
>
> Changes from v4:
> - None.
>
> Changes from v3:
> - None.
>
> Changes from v2:
> - None.
>
> Changes from v1:
> - Remove pattern_get interface.
> ---
> .../ABI/testing/sysfs-class-led-driver-sc27xx | 11 +++
> drivers/leds/leds-sc27xx-bltc.c | 94 ++++++++++++++++++++
> 2 files changed, 105 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
>
> diff --git a/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
> new file mode 100644
> index 0000000..ecef3ba
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-led-driver-sc27xx
> @@ -0,0 +1,11 @@
> +What: /sys/class/leds/<led>/hw_pattern
> +Date: September 2018
> +KernelVersion: 4.20
> +Description:
> + Specify a hardware pattern for the SC27XX LED. For the SC27XX
> + LED controller, it only supports 4 hardware patterns to configure
If I understand it correctly then the four components: low, rise, high,
and fall time make a single pattern. So calling it "4 hardware patterns"
can be misleading. Below you're using "stage" notion - it would be good
to use it consequently on the whole span of this document.
> + the low time, rise time, high time and fall time for the breathing
> + mode, and each stage duration unit is 125ms. So the format of
> + the hardware pattern values should be:
I'd be more precise here:
Min stage duration: ???
Max stage duration: ???
Stage duration step: 125 ms
> + "brightness_1 duration_1 brightness_2 duration_2 brightness_3
> + duration_3 brightness_4 duration_4".
Looking at sc27xx_led_pattern_set() it doesn't seem like you would
use brightnesses other then brightness_1. I assume that the low
brightness is fixed to 0 and the high brightness is the brightness_1.
If yes, than we don't need brightnesses in this pattern definition,
since the current brightness will suffice.
You'd need to alter the hw_pattern description to say that the
brightness currently set is to be used as a high brightness, and the
hw_pattern for this driver consists only of the four delta_t components.
This is clear example of what I had on mind when having doubts
about using tuples for pattern_set.
Alternatively, if we want to enforce tuples format for hw_pattern,
and if we want to be consistent - we'd need to require defining target
brightness for each stage properly, i.e.
echo "100 500 100 500 0 500 0 500" > pattern
Which would mean:
1. Rise from brightness 0 to 100 for 500 ms.
2. Keep brightness 100 for 500 ms.
3. Fall from brightness 100 to 0 for 500 ms.
4. Keep brightness 0 for 500 ms.
--
Best regards,
Jacek Anaszewski
next prev parent reply other threads:[~2018-09-04 20:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-04 11:01 [PATCH v8 1/2] leds: core: Introduce LED pattern trigger Baolin Wang
2018-09-04 11:01 ` [PATCH v8 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller Baolin Wang
2018-09-04 20:19 ` Jacek Anaszewski [this message]
2018-09-05 2:43 ` Baolin Wang
2018-09-05 6:52 ` Baolin Wang
2018-09-08 5:02 ` [PATCH v8 1/2] leds: core: Introduce LED pattern trigger Bjorn Andersson
2018-09-08 20:19 ` Jacek Anaszewski
2018-09-09 13:38 ` Baolin Wang
2018-09-10 21:20 ` Pavel Machek
2018-09-11 1:22 ` Baolin Wang
2018-09-10 21:19 ` Pavel Machek
2018-09-11 18:43 ` Jacek Anaszewski
2018-09-12 19:18 ` Pavel Machek
2018-09-12 20:18 ` Jacek Anaszewski
2018-09-12 20:41 ` Pavel Machek
2018-09-13 19:37 ` 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=ff34b0fd-dd56-f239-94a9-d84673f6869a@gmail.com \
--to=jacek.anaszewski@gmail.com \
--cc=baolin.wang@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=broonie@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rteysseyre@gmail.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).