linux-mips.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Cercueil <paul@crapouillou.net>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	od@opendingux.net, linux-pwm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 2/5] pwm: jz4740: Fix pin level of disabled TCU2 channels, part 2
Date: Tue, 29 Nov 2022 12:25:56 +0000	[thread overview]
Message-ID: <8VZ3MR.B9R316RWSFMQ@crapouillou.net> (raw)
In-Reply-To: <20221128143911.n3woy6mjom5n4sad@pengutronix.de>

Hi Uwe,

Le lun. 28 nov. 2022 à 15:39:11 +0100, Uwe Kleine-König 
<u.kleine-koenig@pengutronix.de> a écrit :
> Hello,
> 
> On Tue, Oct 25, 2022 at 11:10:46AM +0100, Paul Cercueil wrote:
>>  Le mar. 25 oct. 2022 à 08:44:10 +0200, Uwe Kleine-König
>>  <u.kleine-koenig@pengutronix.de> a écrit :
>>  > On Mon, Oct 24, 2022 at 09:52:10PM +0100, Paul Cercueil wrote:
>>  > >  After commit a020f22a4ff5 ("pwm: jz4740: Make PWM start with 
>> the
>>  > > active part"),
>>  > >  the trick to set duty > period to properly shut down TCU2 
>> channels
>>  > > did
>>  > >  not work anymore, because of the polarity inversion.
>>  > >
>>  > >  Address this issue by restoring the proper polarity before
>>  > > disabling the
>>  > >  channels.
>>  > >
>>  > >  Fixes: a020f22a4ff5 ("pwm: jz4740: Make PWM start with the 
>> active
>>  > > part")
>>  > >  Signed-off-by: Paul Cercueil <paul@crapouillou.net>
>>  > >  Cc: stable@vger.kernel.org
>>  > >  ---
>>  > >   drivers/pwm/pwm-jz4740.c | 62
>>  > > ++++++++++++++++++++++++++--------------
>>  > >   1 file changed, 40 insertions(+), 22 deletions(-)
>>  > >
>>  > >  diff --git a/drivers/pwm/pwm-jz4740.c 
>> b/drivers/pwm/pwm-jz4740.c
>>  > >  index 228eb104bf1e..65462a0052af 100644
>>  > >  --- a/drivers/pwm/pwm-jz4740.c
>>  > >  +++ b/drivers/pwm/pwm-jz4740.c
>>  > >  @@ -97,6 +97,19 @@ static int jz4740_pwm_enable(struct pwm_chip
>>  > > *chip, struct pwm_device *pwm)
>>  > >   	return 0;
>>  > >   }
>>  > >
>>  > >  +static void jz4740_pwm_set_polarity(struct jz4740_pwm_chip 
>> *jz,
>>  > >  +				    unsigned int hwpwm,
>>  > >  +				    enum pwm_polarity polarity)
>>  > >  +{
>>  > >  +	unsigned int value = 0;
>>  > >  +
>>  > >  +	if (polarity == PWM_POLARITY_INVERSED)
>>  > >  +		value = TCU_TCSR_PWM_INITL_HIGH;
>>  > >  +
>>  > >  +	regmap_update_bits(jz->map, TCU_REG_TCSRc(hwpwm),
>>  > >  +			   TCU_TCSR_PWM_INITL_HIGH, value);
>>  > >  +}
>>  > >  +
>>  > >   static void jz4740_pwm_disable(struct pwm_chip *chip, struct
>>  > > pwm_device *pwm)
>>  > >   {
>>  > >   	struct jz4740_pwm_chip *jz = to_jz4740(chip);
>>  > >  @@ -130,6 +143,7 @@ static int jz4740_pwm_apply(struct pwm_chip
>>  > > *chip, struct pwm_device *pwm,
>>  > >   	unsigned long long tmp = 0xffffull * NSEC_PER_SEC;
>>  > >   	struct clk *clk = pwm_get_chip_data(pwm);
>>  > >   	unsigned long period, duty;
>>  > >  +	enum pwm_polarity polarity;
>>  > >   	long rate;
>>  > >   	int err;
>>  > >
>>  > >  @@ -169,6 +183,9 @@ static int jz4740_pwm_apply(struct pwm_chip
>>  > > *chip, struct pwm_device *pwm,
>>  > >   	if (duty >= period)
>>  > >   		duty = period - 1;
>>  > >
>>  > >  +	/* Restore regular polarity before disabling the channel. */
>>  > >  +	jz4740_pwm_set_polarity(jz4740, pwm->hwpwm, state->polarity);
>>  > >  +
>>  >
>>  > Does this introduce a glitch?
>> 
>>  Maybe. But the PWM is shut down before finishing its period anyway, 
>> so there
>>  was already a glitch.
>> 
>>  > >   	jz4740_pwm_disable(chip, pwm);
>>  > >
>>  > >   	err = clk_set_rate(clk, rate);
>>  > >  @@ -190,29 +207,30 @@ static int jz4740_pwm_apply(struct 
>> pwm_chip
>>  > > *chip, struct pwm_device *pwm,
>>  > >   	regmap_update_bits(jz4740->map, TCU_REG_TCSRc(pwm->hwpwm),
>>  > >   			   TCU_TCSR_PWM_SD, TCU_TCSR_PWM_SD);
>>  > >
>>  > >  -	/*
>>  > >  -	 * Set polarity.
>>  > >  -	 *
>>  > >  -	 * The PWM starts in inactive state until the internal timer
>>  > > reaches the
>>  > >  -	 * duty value, then becomes active until the timer reaches 
>> the
>>  > > period
>>  > >  -	 * value. In theory, we should then use (period - duty) as 
>> the
>>  > > real duty
>>  > >  -	 * value, as a high duty value would otherwise result in the 
>> PWM
>>  > > pin
>>  > >  -	 * being inactive most of the time.
>>  > >  -	 *
>>  > >  -	 * Here, we don't do that, and instead invert the polarity 
>> of the
>>  > > PWM
>>  > >  -	 * when it is active. This trick makes the PWM start with its
>>  > > active
>>  > >  -	 * state instead of its inactive state.
>>  > >  -	 */
>>  > >  -	if ((state->polarity == PWM_POLARITY_NORMAL) ^ 
>> state->enabled)
>>  > >  -		regmap_update_bits(jz4740->map, TCU_REG_TCSRc(pwm->hwpwm),
>>  > >  -				   TCU_TCSR_PWM_INITL_HIGH, 0);
>>  > >  -	else
>>  > >  -		regmap_update_bits(jz4740->map, TCU_REG_TCSRc(pwm->hwpwm),
>>  > >  -				   TCU_TCSR_PWM_INITL_HIGH,
>>  > >  -				   TCU_TCSR_PWM_INITL_HIGH);
>>  > >  -
>>  > >  -	if (state->enabled)
>>  > >  +	if (state->enabled) {
>>  > >  +		/*
>>  > >  +		 * Set polarity.
>>  > >  +		 *
>>  > >  +		 * The PWM starts in inactive state until the internal timer
>>  > >  +		 * reaches the duty value, then becomes active until the 
>> timer
>>  > >  +		 * reaches the period value. In theory, we should then use
>>  > >  +		 * (period - duty) as the real duty value, as a high duty 
>> value
>>  > >  +		 * would otherwise result in the PWM pin being inactive 
>> most of
>>  > >  +		 * the time.
>>  > >  +		 *
>>  > >  +		 * Here, we don't do that, and instead invert the polarity 
>> of
>>  > >  +		 * the PWM when it is active. This trick makes the PWM start
>>  > >  +		 * with its active state instead of its inactive state.
>>  > >  +		 */
>>  > >  +		if (state->polarity == PWM_POLARITY_NORMAL)
>>  > >  +			polarity = PWM_POLARITY_INVERSED;
>>  > >  +		else
>>  > >  +			polarity = PWM_POLARITY_NORMAL;
>>  > >  +
>>  > >  +		jz4740_pwm_set_polarity(jz4740, pwm->hwpwm, polarity);
>>  > >  +
>>  > >   		jz4740_pwm_enable(chip, pwm);
>>  > >  +	}
>>  >
>>  > Note that for disabled PWMs there is no official guaranty about 
>> the pin
>>  > state. So it would be ok (but admittedly not great) to simplify 
>> the
>>  > driver and accept that the pinstate is active while the PWM is 
>> off.
>>  > IMHO this is also better than a glitch.
>>  >
>>  > If a consumer wants the PWM to be in its inactive state, they 
>> should
>>  > not disable it.
>> 
>>  Completely disagree. I absolutely do not want the backlight to go 
>> full
>>  bright mode when the PWM pin is disabled. And disabling the 
>> backlight is a
>>  thing (for screen blanking and during mode changes).
> 
> For some hardwares there is no pretty choice. So the gist is: If the
> backlight driver wants to ensure that the PWM pin is driven to its
> inactive level, it should use:
> 
> 	pwm_apply(pwm, { .period = ..., .duty_cycle = 0, .enabled = true });
> 
> and better not
> 
> 	pwm_apply(pwm, { ..., .enabled = false });

Well that sounds pretty stupid to me; why doesn't the PWM subsystem 
enforce that the pins must be driven to their inactive level when the 
PWM function is disabled? Then for such hardware you describe, the 
corresponding PWM driver could itself apply a duty_cycle = 0 if that's 
what it takes to get an inactive state.

Cheers,
-Paul



  parent reply	other threads:[~2022-11-29 12:26 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-24 20:52 [PATCH 0/5] pwm: jz4740: Fixes and some light changes Paul Cercueil
2022-10-24 20:52 ` [PATCH 1/5] pwm: jz4740: Fix pin level of disabled TCU2 channels, part 1 Paul Cercueil
2022-10-25  6:21   ` Uwe Kleine-König
2022-10-25 10:02     ` Paul Cercueil
2022-11-17 13:29       ` Uwe Kleine-König
2022-11-18  9:55         ` Paul Cercueil
2023-01-17 21:35           ` Uwe Kleine-König
2023-01-17 23:05             ` Paul Cercueil
2023-01-18  8:16               ` Uwe Kleine-König
2022-10-24 20:52 ` [PATCH 2/5] pwm: jz4740: Fix pin level of disabled TCU2 channels, part 2 Paul Cercueil
2022-10-25  6:44   ` Uwe Kleine-König
2022-10-25 10:10     ` Paul Cercueil
2022-11-28 14:39       ` Uwe Kleine-König
2022-11-29 12:16         ` Thierry Reding
2022-11-29 12:34           ` Paul Cercueil
2022-11-29 12:25         ` Paul Cercueil [this message]
2022-11-29 16:24           ` Uwe Kleine-König
2022-11-29 16:58             ` Paul Cercueil
2022-11-29 17:46               ` Uwe Kleine-König
2022-10-24 20:52 ` [PATCH 3/5] pwm: jz4740: Force dependency on Device Tree Paul Cercueil
2022-11-28 14:41   ` Uwe Kleine-König
2022-10-24 20:52 ` [PATCH 4/5] pwm: jz4740: Depend on MACH_INGENIC instead of MIPS Paul Cercueil
2022-10-25 10:32   ` Philippe Mathieu-Daudé
2022-11-15 10:40   ` Uwe Kleine-König
2022-10-24 20:52 ` [PATCH 5/5] pwm: jz4740: Use regmap_{set,clear}_bits Paul Cercueil
2022-10-25 10:46   ` Philippe Mathieu-Daudé
2022-11-15 10:51   ` Uwe Kleine-König

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=8VZ3MR.B9R316RWSFMQ@crapouillou.net \
    --to=paul@crapouillou.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=od@opendingux.net \
    --cc=stable@vger.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;
as well as URLs for NNTP newsgroup(s).