Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2;
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date:   Fri, 13 Oct 2023 08:35:31 +0200
Message-Id: <CW73PXH7OBDG.22PGA47PJR8T2@fairphone.com>
Subject: Re: [PATCH v5 0/7] Add support for LUT PPG
From:   "Luca Weiss" <luca.weiss@fairphone.com>
To:     "Anjelique Melendez" <quic_amelende@quicinc.com>, <pavel@ucw.cz>,
        <lee@kernel.org>, <thierry.reding@gmail.com>, <robh+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
        <agross@kernel.org>, <andersson@kernel.org>
Cc:     <konrad.dybcio@linaro.org>, <u.kleine-koenig@pengutronix.de>,
        <quic_subbaram@quicinc.com>, <quic_gurus@quicinc.com>,
        <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>, <kernel@quicinc.com>
References: <20230929003901.15086-1-quic_amelende@quicinc.com>
 <CVX5ZUGU9BVE.2TA819U1AI6BZ@otso>
 <a2781978-2081-f4cb-dfe3-0489860dab8e@quicinc.com>
In-Reply-To: <a2781978-2081-f4cb-dfe3-0489860dab8e@quicinc.com>
Precedence: bulk

On Thu Oct 12, 2023 at 11:50 PM CEST, Anjelique Melendez wrote:
>
>
> On 10/1/2023 7:15 AM, Luca Weiss wrote:
> > On Fri Sep 29, 2023 at 2:38 AM CEST, Anjelique Melendez wrote:
> >> In certain PMICs, LUT pattern and LPG configuration is stored in SDAM
> >> modules instead of LUT peripheral. This feature is called PPG.
> >>
> >> This change series adds support for PPG. Thanks!
> [..]
> >>
> >> Tested-by: Luca Weiss <luca.weiss@fairphone.com> # sdm632-fairphone-fp=
3 (pmi632)
> >=20
> > Hi Anjelique,
> >=20
> > Actually I've retested this now on PMI632 (and also realized that my
> > previous tests weren't correct and wasn't actually using hw_pattern).
> >=20
> > Using the following commands (after boot) I'm expecting to get a
> > 500ms on 500ms off blinking pattern between white (255 255 255) and off
> > (0 0 0).
> >=20
> >   echo pattern > /sys/class/leds/rgb:status/trigger
> >   echo -1 > /sys/class/leds/rgb:status/repeat
> >=20
> >   echo "255 255 255" > /sys/class/leds/rgb:status/multi_intensity
> >   echo "255 500 255 0 0 500 0 0" > /sys/class/leds/rgb:status/hw_patter=
n
> >=20
> > What I actually see is it blinking between cyan (0 255 255) and red (25=
5
> > 0 0).
> > At some point after playing with many patterns I got it to actually
> > cycle between white and off, but I couldn't reproduce this again (or I
> > didn't try hard enough).
> >=20
> >=20
> > But with this example it correctly blinks red on-off.
> >=20
> >   echo "255 0 0" > /sys/class/leds/rgb:status/multi_intensity
> >   echo "255 500 255 0 0 500 0 0" > /sys/class/leds/rgb:status/hw_patter=
n
> >=20
> > With "0 255 0" and "0 0 255" the other colors also work fine, it's just
> > the combinations that seem somewhat broken.
> >=20
> > Regards
> > Luca
> >=20
> >=20
> Hi Luca,
>
> Thanks for testing again and the feedback!
> Looks like for multicolor devices there is a small concurrency issue with
> enabling pattern at the same time for all the led channels. This could be
> why you observed your device blinking between red (255 0 0) and cyan (0 2=
55 255),
> instead of seeing all channels (255 255 255) blink.
> The fix I'm planing to include in the next series is is to disable the mu=
lticolor led
> channels first, then configure all channels, and finally re-enable channe=
ls
> so that pattern is triggered at the same time for each all of the channel=
s.

Sounds reasonable I think!

>
> I am currently testing with pm8350c device so if you are able to test nex=
t series
> on pmi632 it would be very appreciated!

Will do, thanks for fixing it up!

Regards
Luca

>
> Thanks,
> Anjelique