Linux LED subsystem development
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@linaro.org>
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: luca.weiss@fairphone.com, 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
Subject: Re: [PATCH v4 4/7] leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM
Date: Thu, 7 Sep 2023 22:42:02 +0200	[thread overview]
Message-ID: <09109739-cb9c-42e2-80ab-e919774b4173@linaro.org> (raw)
In-Reply-To: <a9aa7bd9-7d42-3897-443e-b3ef2d73d05c@quicinc.com>

On 7.09.2023 21:55, Anjelique Melendez wrote:
> 
> 
> On 8/30/2023 11:34 AM, Konrad Dybcio wrote:
>> On 30.08.2023 20:05, Anjelique Melendez wrote:
>>> In some PMICs like pmi632, the pattern look up table (LUT) and LPG
>>> configuration can be stored in a single SDAM module instead of LUT
>>> peripheral. This feature is called PPG. PPG uses Qualcomm Programmable
>>> Boot Sequencer (PBS) inorder to trigger pattern sequences for PMICs.
>> I still fail to understand what benefit this brings.
>>
>> Is this a "can be used", or "should be used", or maybe "must be used"?
>>
>> Are there any distinct advantages to using one over the other?
>> I see some limitations in the code below, but that's not being made
>> obvious.
>>
>> This all should be in the commit message, the current one includes
>> a lot of cryptic names that mean nothing to most people.
>>
>> [...]
> This is a must be used if you would like to trigger patterns. Will update commit message to try and 
> make that more clear for next patch.
So essentially without this patchset, PM8350C and PMI632 are not capable
of producing LED patterns. Is that correct?

[...]

>>> @@ -860,14 +1043,21 @@ static int lpg_pattern_set(struct lpg_led *led, struct led_pattern *led_pattern,
>>>  	 * Validate that all delta_t in the pattern are the same, with the
>>>  	 * exception of the middle element in case of ping_pong.
>>>  	 */
>>> -	delta_t = pattern[1].delta_t;
>>> -	for (i = 2; i < len; i++) {
>>> +	if (lpg->lpg_chan_nvmem) {
>>> +		i = 1;
>>> +		delta_t = pattern[0].delta_t;
>>> +	} else {
>>> +		i = 2;
>>> +		delta_t = pattern[1].delta_t;
>>> +	}
>> Why?
>>
>> What's the rationale behind this change?
> Patterns are required to have the same duration for each step of the pattern. Devices with LUT peripherals support low/high
> pause which is when the first/last entry of the pattern can have a longer duration. This loop checks that the all of the
> pattern durations are the same with the exception of the first and last entry for low/hi pause.
That's the explanation I was looking for! :)

Things like these that are only known to inside folks should
definitely be stated either as a comment, or inside the commit
message. Since you're changing the code flow in a noticeable manner,
this could probably be a good fit for a comment.

> 
> This change was made because devices that use single SDAM do not support low/high pause, so we must check every
> single pattern duration. Instead of changing the loop arguments with an if statement I was thinking we could either:
> 
> a. keep the original loop arguments and when loop exits we can check first element for single SDAM devices
> 
>    delta_t = pattern[1].delta_t;
>    for (i = 2; i < len; i++) {
> 	if (pattern[i].delta_t != delta_t) {
> + 		if (i != actual_len - 1 || lpg->lpg_chan_nvmem)
>   			goto out_free_pattern;
>   		}
>   	}
> 
> + if (lpg->lpg_chan_nvmem) {
> +	if (delta_t != pattern[0].delta_t)
> +		goto out_free_pattern
> + }
We assign hi/lo_pause a couple lines below. Moving these assignments
a bit higher up could let us make this clearer:

/* LPGs using SDAM for patterns require equal duration of all steps */
if ((delta_t != lo_pause) && lpg->lpg_chan_nvmem)
	goto out_free_pattern;

Though I think that (in a separate patch, or perhaps series), it would
be worth redoing the code such that hi/lo_pause expresses the deviation
from the duration of the rest instead of the duration itself. Then we
could just:

if ((lo_pause || hi_pause)) && lpg->lpg_chan_nvmem)
	goto out_free_pattern;

But that's just a suggestion from somebody that didn't work on this code.

Also, I think that using lpg_chan_nvmem interchangeably with SDAM is a
bit confusing. Do we expect NVMEMs/SRAMs that aren't SDAM to make an
appearence here?

> 
> b. Change the loop argument to start with i=0 and for LUT device we could just skip checking first and last element duration
>   ** We would end up checking if pattern[1].delta_t == pattern[1].delta_t inside the loop when i == 1
> 
>    delta_t = pattern[1].delta_t;
> +  for (i = 0; i < len; i++) {
> 	if (pattern[i].delta_t != delta_t) {
> +		if (lpg->lut_base && (i == 0 || i == actual_len - 1)
> +			continue;
> +               else
> +			goto out_free_pattern;
Meh, too many magic literals for my liking

Konrad

  reply	other threads:[~2023-09-07 20:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-30 18:05 [PATCH v4 0/7] Add support for LUT PPG Anjelique Melendez
2023-08-30 18:05 ` [PATCH v4 1/7] dt-bindings: soc: qcom: Add qcom,pbs bindings Anjelique Melendez
2023-08-30 18:05 ` [PATCH v4 2/7] dt-bindings: leds: leds-qcom-lpg: Add support for LPG PPG Anjelique Melendez
2023-08-31 15:58   ` Conor Dooley
2023-08-30 18:05 ` [PATCH v4 3/7] soc: qcom: add QCOM PBS driver Anjelique Melendez
2023-08-30 18:20   ` Konrad Dybcio
2023-08-30 18:05 ` [PATCH v4 4/7] leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM Anjelique Melendez
2023-08-30 18:34   ` Konrad Dybcio
2023-09-07 19:55     ` Anjelique Melendez
2023-09-07 20:42       ` Konrad Dybcio [this message]
2023-09-07 22:01         ` Anjelique Melendez
2023-08-30 18:06 ` [PATCH v4 5/7] leds: rgb: leds-qcom-lpg: Update PMI632 lpg_data to support PPG Anjelique Melendez
2023-08-30 18:34   ` Konrad Dybcio
2023-09-07 19:54     ` Anjelique Melendez
2023-09-07 20:26       ` Konrad Dybcio
2023-09-07 20:31         ` Konrad Dybcio
2023-09-08  0:30           ` Anjelique Melendez
2023-09-08  8:28             ` Konrad Dybcio
2023-09-08 18:58               ` Anjelique Melendez
2023-08-30 18:06 ` [PATCH v4 6/7] leds: rgb: leds-qcom-lpg: Include support for dedicated LUT SDAM PPG Scheme Anjelique Melendez
2023-08-30 18:06 ` [PATCH v4 7/7] leds: rgb: Update PM8350C lpg_data to support two-nvmem " Anjelique Melendez

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=09109739-cb9c-42e2-80ab-e919774b4173@linaro.org \
    --to=konrad.dybcio@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@quicinc.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.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.weiss@fairphone.com \
    --cc=pavel@ucw.cz \
    --cc=quic_amelende@quicinc.com \
    --cc=quic_gurus@quicinc.com \
    --cc=quic_subbaram@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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