All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Aisheng Dong <aisheng.dong@nxp.com>
Cc: "daniel.thompson@linaro.org" <daniel.thompson@linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Jingoo Han <jingoohan1@gmail.com>,
	"deller@gmx.de" <deller@gmx.de>,
	"lee@kernel.org" <lee@kernel.org>,
	"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"thierry.reding@gmail.com" <thierry.reding@gmail.com>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>
Subject: Regression in deaeeda2051f ("backlight: pwm_bl: Don't rely on a disabled PWM emiting inactive state")
Date: Wed, 22 Mar 2023 08:03:52 +0100	[thread overview]
Message-ID: <20230322070352.xfwmnqyrao3mifuu@pengutronix.de> (raw)
In-Reply-To: <DB9PR04MB84779AF9758B7FE747C6693D80869@DB9PR04MB8477.eurprd04.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]

Hello,

hmm, the subject is wrong, this is about commit deaeeda2051f
("backlight: pwm_bl: Don't rely on a disabled PWM emiting inactive
state") and not 00e7e698bff1 ("backlight: pwm_bl: Configure pwm only
once per backlight toggle"). I fixed it accordingly.

On Wed, Mar 22, 2023 at 05:13:24AM +0000, Aisheng Dong wrote:
> It seems this patch changed the behavior of pwm_backlight_suspend a little bit in
> pwm_backlight_power_off() that pwm state keep unchanged during suspend.
> Then pwm_imx_tpm_suspend() will return -Ebusy due to tpm->enable_count > 0.
> Was this intended behavior? Should we fix pwm core or the driver?

A I see. The problem is the combination of the following facts:

 - Some PWMs don't emit a constant inactive signal when disabled, so a
   consumer who wants a constant inactive signal must not disable the
   PWM.

 - A used PWM is supposed to be disabled by its consumer on suspend.
   (This is right IMHO because on suspend the PWM is likely to stop
   oscillating and if the consumer requested some output wave form a
   suspend usually stops to adhere to the consumer's request.)

So the options to fix this are (in order of my preference):

 a) Improve the check in the pwm_bl driver when it's safe to disable the
    PWM.

 b) Disable the PWM on suspend in the pwm_bl driver.

 c) If the pwm-imx-tpm's PWM output is configured with duty_cycle = 0 and
    is known not to continue driving a constant inactive signal on
    suspend, it might continue to suspend.

I think a) is not possible in general. To determine that: Which machine
do you experience this regression on?

b) is the right one from the PWM framework's POV. If you have a PWM like
pwm-imx27 that might result in the backlight going on on suspend. That's
bad, but compared to the pre-deaeeda2051f state it's still an
improvement (as there the backlight went on on disable *and* suspend).
Depending on the machine the backlight might or might not go off again
later when suspend progresses.

c) isn't that nice because that's an a bit special behaviour and people
who intend to write code that is correct for all PWMs but only have an
pwm-imx-tpm to test might fail to do so.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2023-03-22  7:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-22  5:13 [PATCH v2 1/2] backlight: pwm_bl: Configure pwm only once per backlight toggle Aisheng Dong
2023-03-22  7:03 ` Uwe Kleine-König [this message]
2023-03-22  8:10   ` Regression in deaeeda2051f ("backlight: pwm_bl: Don't rely on a disabled PWM emiting inactive state") Aisheng Dong
2023-03-22  8:51     ` [PATCH] backlight: pwm_bl: Disable PWM on shutdown and suspend " Uwe Kleine-König
2023-03-22  9:14       ` Aisheng Dong
2023-03-22  9:14         ` Aisheng Dong
2023-09-26  7:17       ` Uwe Kleine-König
2023-09-26  7:17         ` Uwe Kleine-König
2023-09-26  8:30         ` Lee Jones
2023-09-26  8:31           ` Lee Jones

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=20230322070352.xfwmnqyrao3mifuu@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=aisheng.dong@nxp.com \
    --cc=daniel.thompson@linaro.org \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jingoohan1@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=lee@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=thierry.reding@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.