From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Marijn Suijten <marijn.suijten@somainline.org>
Cc: Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>,
Andy Gross <agross@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>,
Lee Jones <lee.jones@linaro.org>,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-pwm@vger.kernel.org,
Yassine Oudjana <y.oudjana@protonmail.com>,
Luca Weiss <luca@z3ntu.xyz>,
Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Subject: Re: [PATCH v10 2/2] leds: Add driver for Qualcomm LPG
Date: Wed, 2 Feb 2022 13:56:10 -0800 [thread overview]
Message-ID: <Yfr9+jvGIyB2ynMS@ripper> (raw)
In-Reply-To: <20220202110305.gbow3e3stolb67v5@SoMainline.org>
On Wed 02 Feb 03:03 PST 2022, Marijn Suijten wrote:
> On 2022-01-28 18:50:42, Bjorn Andersson wrote:
> > On Wed 27 Oct 16:19 CDT 2021, Marijn Suijten wrote:
> >
> > > Hi Bjorn,
> > >
> > > On 2021-10-22 10:25:35, Bjorn Andersson wrote:
> > > > On Sat 09 Oct 21:39 PDT 2021, Bjorn Andersson wrote:
> > > >
> > > > > The Light Pulse Generator (LPG) is a PWM-block found in a wide range of
> > > > > PMICs from Qualcomm. These PMICs typically comes with 1-8 LPG instances,
> > > > > with their output being routed to various other components, such as
> > > > > current sinks or GPIOs.
> > > > >
> > > > > Each LPG instance can operate on fixed parameters or based on a shared
> > > > > lookup-table, altering the duty cycle over time. This provides the means
> > > > > for hardware assisted transitions of LED brightness.
> > > > >
> > > > > A typical use case for the fixed parameter mode is to drive a PWM
> > > > > backlight control signal, the driver therefor allows each LPG instance
> > > > > to be exposed to the kernel either through the LED framework or the PWM
> > > > > framework.
> > > > >
> > > > > A typical use case for the LED configuration is to drive RGB LEDs in
> > > > > smartphones etc, for which the driver support multiple channels to be
> > > > > ganged up to a MULTICOLOR LED. In this configuration the pattern
> > > > > generators will be synchronized, to allow for multi-color patterns.
> > > > >
> > > > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > > > ---
> > > >
> > > > Any feedback on this?
> > >
> > > I asked in #linux-msm whether anything is wrong with the patterns,
> > > since my Sony Discovery (sdm630 with a pm660l) blinks way quicker on a
> > > pattern that's supposed to stay on for 1s and off for 1s:
> > >
> > > echo "0 1000 255 1000" > /sys/class/leds/rgb\:status/hw_pattern
> > >
> > > It however seems to be broken in the same way on an older version now
> > > (this might be v9 or v8) which I don't remember to be the case. Can you
> > > double-check if this is all working fine on your side? If so, I'll have
> > > to find some time to debug it on my end.
> > >
> >
> > I had missed the fact that LPG_RAMP_DURATION_REG is two registers for
> > msg and lsb, for a total of 9 bits of duration. So what you saw was
> > probably ticking at 232ms.
> >
> > Note though that the pattern uses the last time as "high pause", so I
> > expect that you should have seen 232 ms of off, followed by 464ms of
> > light.
>
> Visual inspection seems to confirm those numbers indeed!
>
> > I've fixed this for v11, both rejecting invalid input and writing out
> > all 9 bits.
>
> Doesn't that 512ms limit, together with using only the last value for
> hi_pause (and not the first value for lo_pause) force users to write
> patterns in a certain way which is not easily conveyed to the caller
> except by reading the comment in the driver? I'd guess lo_pause can be
> used even if not in ping-pong mode, it should just hold at the first
> value for the given duration?
>
> (That said hw_pattern is anyway already riddled with device-specific
> information, such as only having one `delta_t` which functions as the
> step size for every entry, and with the change above would need to be
> sourced from another step that's not the first.)
>
Perhaps we should clarify the single delta_t by requiring all those
delta_t to be the same, rather than ignoring their value.
I.e. we make the ping-pong pattern:
<value> <lopause+t> ... <value[N/2-1]> <t> <value[N/2]> <hipause+t> <value[N/2-1]> <t> ... <value> <t>
And for non-ping-pong:
<value> <lopause+t> <value> <t> ... <value> <t> <value> <hipause + t>
What do you think?
> Bit of a stretch, but perhaps worth noting anyway: should this be
> written in documentation somewhere, together with pattern examples and
> their desired outcome to function as testcases too?
>
There's a comment in lpg_pattern_set() where I tried to capture this.
I don't think it's worth documenting the behavior/structure away from
the driver. But let's make sure it's captured properly there.
Regards,
Bjorn
next prev parent reply other threads:[~2022-02-02 21:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-10 4:39 [PATCH v10 1/2] dt-bindings: leds: Add Qualcomm Light Pulse Generator binding Bjorn Andersson
2021-10-10 4:39 ` [PATCH v10 2/2] leds: Add driver for Qualcomm LPG Bjorn Andersson
2021-10-22 17:25 ` Bjorn Andersson
2021-10-27 21:19 ` Marijn Suijten
2021-10-27 21:27 ` Marijn Suijten
2022-01-29 0:53 ` Bjorn Andersson
2022-02-02 10:17 ` Marijn Suijten
2022-01-29 0:50 ` Bjorn Andersson
2022-02-02 11:03 ` Marijn Suijten
2022-02-02 21:56 ` Bjorn Andersson [this message]
2022-02-03 23:13 ` Marijn Suijten
2021-10-26 0:37 ` Subbaraman Narayanamurthy
2021-10-26 2:57 ` Bjorn Andersson
2021-10-16 14:36 ` [PATCH v10 1/2] dt-bindings: leds: Add Qualcomm Light Pulse Generator binding Rob Herring
2022-01-07 0:18 ` Stephen Boyd
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=Yfr9+jvGIyB2ynMS@ripper \
--to=bjorn.andersson@linaro.org \
--cc=agross@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=luca@z3ntu.xyz \
--cc=marijn.suijten@somainline.org \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=subbaram@codeaurora.org \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
--cc=y.oudjana@protonmail.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).