From: Pavel Machek <pavel@ucw.cz>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Rob Herring <robh@kernel.org>, Richard Purdie <rpurdie@rpsys.net>,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org
Subject: Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
Date: Sat, 8 Apr 2017 11:57:59 +0200 [thread overview]
Message-ID: <20170408095759.GB17007@amd> (raw)
In-Reply-To: <20170407202603.GC15143@minitux>
[-- Attachment #1: Type: text/plain, Size: 3467 bytes --]
Hi!
> > On 04/03/2017 09:00 PM, Bjorn Andersson wrote:
> [..]
> > > For the patterns I don't know how a trigger for this would look like,
> > > how would setting the pattern of a trigger be propagated down to the
> > > hardware?
> >
> > We'd need a new op and API similar to blink_set()/led_blink_set().
> >
>
> I've tried to find different LED circuits with some sort of pattern
> generator in an attempt to figure out how to design this interface, but
> turned out to be quite hard to find examples; the three I can compare
> are:
>
> * LP5xx series "implements" pattern generation by executing code.
It supports "linear" and "exponential" transitions between
values. Variable number of steps.
> * Qualcomm LPG iterates over 2-64 brightness-values in a pattern, at a
> fixed rate with knobs to configure what happens before starting and
> after finishing iterating over the defined values. It does not support
> smooth transitions between values.
>
> * AS3676 supports a pattern of 32 values controlling if the output
> should be enabled or disabled for each 32.5ms (or 250ms) time period.
> The delay before repeating the pattern can be configured. It support
> smooth transitions between the states.
Ok, that's "really interesting" one. As far as I can see, the pattern
really should only contain justtwo intensities...
> So, while I think I see how you would like to architect this interface I
> am not sure how to figure out the details.
>
> The pattern definition would have to be expressive enough to support the
> features of LP5xx and direct enough to support the limited AS3676. It
> would likely have to express transitions, so that the LPG could generate
> intermediate steps (and we will have to adapt the resolution of the
> ramps based on the other LPGs in the system).
That's why I believe it is important to present whole pattern engine
as one unit to the userspace. Userspace should always upload pattern
for _all_ the LEDs at once.
> How do we do with patterns that are implementable by the LP5xx but are
> not with the LPG? Should we reject those or should we do some sort of
> best-effort approach in the kernel?
Up to you, I guess. Both rejecting and best-effort make some sense.
OTOH if pattern is "(off, 0msec), (white, +1000msec), (off,
+0msec)"... you can't really do it "exactly" even on LP5xx, due to
non-trivial conversion between PWM and what user sees....
So on LPG you'd really do "(off, 0msec), (10% white, +100msec), (20%
white, +100msec), ..."
AS3676... I guess after we reject all patterns that have more than 0
and one specific brightness, we can use similar approximation we'd do
on LPG?
> > This is what we have now, so we can live with it. Addition of a new
> > RGB trigger would be an improvement of the existing state.
> >
>
> If we do the brightness compensation (for e.g. white balance
> adjustments) in a trigger then there's added value.
>
> The part where I see this affects the LPG driver is that the brightness
> of the patterns might have to be adjusted accordingly - which probably
> would be easier to implement if the kernel just exposed the compensation
> values to user space.
Well, compensation needs to happen "during the transitions",
too.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2017-04-08 9:58 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-23 5:54 [PATCH 1/2] leds: Add driver for Qualcomm LPG Bjorn Andersson
2017-03-23 5:54 ` [PATCH 2/2] DT: leds: Add Qualcomm Light Pulse Generator binding Bjorn Andersson
2017-03-29 2:26 ` Rob Herring
2017-03-29 19:26 ` Bjorn Andersson
2017-03-29 22:13 ` Pavel Machek
2017-03-23 20:37 ` [PATCH 1/2] leds: Add driver for Qualcomm LPG Pavel Machek
2017-03-27 4:48 ` Bjorn Andersson
2017-03-29 2:17 ` Rob Herring
2017-03-29 19:07 ` Bjorn Andersson
2017-03-29 22:23 ` Pavel Machek
2017-03-30 0:09 ` Bjorn Andersson
2017-03-30 7:43 ` Pavel Machek
2017-03-31 9:28 ` Jacek Anaszewski
2017-04-02 12:54 ` Jacek Anaszewski
2017-04-03 18:21 ` Bjorn Andersson
2017-04-03 20:38 ` Jacek Anaszewski
2017-04-10 9:52 ` Pavel Machek
2017-04-03 19:00 ` Bjorn Andersson
2017-04-03 20:38 ` Jacek Anaszewski
2017-04-07 20:26 ` Bjorn Andersson
2017-04-08 9:57 ` Pavel Machek [this message]
2017-04-08 13:39 ` Pavel Machek
2017-04-09 12:32 ` Jacek Anaszewski
2017-04-10 19:19 ` Bjorn Andersson
2017-04-11 17:54 ` Pavel Machek
2017-04-11 23:17 ` Bjorn Andersson
2017-04-07 13:32 ` Pavel Machek
2017-04-07 20:36 ` Bjorn Andersson
2017-04-08 9:33 ` Pavel Machek
2017-04-07 12:54 ` Pavel Machek
2022-05-23 16:30 ` Pavel Machek
2022-05-23 22:01 ` Marijn Suijten
2022-05-23 22:18 ` Pavel Machek
2022-05-24 18:19 ` Marijn Suijten
2022-05-24 15:02 ` Bjorn Andersson
2022-05-24 18:26 ` Marijn Suijten
2022-05-24 20:10 ` 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=20170408095759.GB17007@amd \
--to=pavel@ucw.cz \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh@kernel.org \
--cc=rpurdie@rpsys.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).