From: Thierry Reding <thierry.reding@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-pwm@vger.kernel.org,
intel-gfx <intel-gfx@lists.freedesktop.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
linux-acpi@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Len Brown" <lenb@kernel.org>
Subject: Re: [Intel-gfx] [PATCH v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state
Date: Thu, 3 Sep 2020 12:59:09 +0200 [thread overview]
Message-ID: <20200903105909.GA3756465@ulmo> (raw)
In-Reply-To: <20200903105114.9969-7-hdegoede@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2156 bytes --]
On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote:
> Before this commit pwm_lpss_apply() was making 2 assuming
> 2 pre-conditions were met by the existing hardware state:
I think that "making 2" is too much.
>
> 1. That the base-unit and on-time-div read back from the
> control register are those actually in use, so that it
> can skip setting the update bit if the read-back value
> matches the desired values.
>
> 2. That the controller is enabled when the cached
> pwm_state.enabled says that the controller is enabled.
>
> As the long history of fixes for subtle (often suspend/resume)
> lpss-pwm issues shows, this assumptions are not necessary
> always true.
>
> 1. Specifically is not true on some (*) Cherry Trail devices
> with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
> b. sets the base-unit to 0 and writes the update bit to apply/commit
> c. restores the original ctrl value without setting the update bit,
> so that the 0 base-unit value is still in use.
>
> 2. Assumption 2. currently is true, but only because of the code which
> saves/restores the state on suspend/resume. By convention restoring the
> PWM state should be done by the PWM consumer and the presence of this
> code in the pmw-lpss driver is a bug. Therefor the save/restore code will
> be dropped in the next patch in this series, after which this assumption
> also is no longer true.
>
> This commit changes the pwm_lpss_apply() to make any assumptions about the
Did you mean to say "... to _not_ make any assumptions ..."?
> state the hardware is in. Instead it makes pwm_lpss_apply() always fully
> program the PWM controller, making it much less fragile.
>
> *) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
> and various Medion models.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/pwm/pwm-lpss.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
Other than the two small nits, this looks much more idiomatic and true
to the atomic API, so:
Acked-by: Thierry Reding <thierry.reding@gmail.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
"Len Brown" <lenb@kernel.org>,
linux-pwm@vger.kernel.org,
intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel@lists.freedesktop.org,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
linux-acpi@vger.kernel.org
Subject: Re: [PATCH v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state
Date: Thu, 3 Sep 2020 12:59:09 +0200 [thread overview]
Message-ID: <20200903105909.GA3756465@ulmo> (raw)
In-Reply-To: <20200903105114.9969-7-hdegoede@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]
On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote:
> Before this commit pwm_lpss_apply() was making 2 assuming
> 2 pre-conditions were met by the existing hardware state:
I think that "making 2" is too much.
>
> 1. That the base-unit and on-time-div read back from the
> control register are those actually in use, so that it
> can skip setting the update bit if the read-back value
> matches the desired values.
>
> 2. That the controller is enabled when the cached
> pwm_state.enabled says that the controller is enabled.
>
> As the long history of fixes for subtle (often suspend/resume)
> lpss-pwm issues shows, this assumptions are not necessary
> always true.
>
> 1. Specifically is not true on some (*) Cherry Trail devices
> with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
> b. sets the base-unit to 0 and writes the update bit to apply/commit
> c. restores the original ctrl value without setting the update bit,
> so that the 0 base-unit value is still in use.
>
> 2. Assumption 2. currently is true, but only because of the code which
> saves/restores the state on suspend/resume. By convention restoring the
> PWM state should be done by the PWM consumer and the presence of this
> code in the pmw-lpss driver is a bug. Therefor the save/restore code will
> be dropped in the next patch in this series, after which this assumption
> also is no longer true.
>
> This commit changes the pwm_lpss_apply() to make any assumptions about the
Did you mean to say "... to _not_ make any assumptions ..."?
> state the hardware is in. Instead it makes pwm_lpss_apply() always fully
> program the PWM controller, making it much less fragile.
>
> *) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
> and various Medion models.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/pwm/pwm-lpss.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
Other than the two small nits, this looks much more idiomatic and true
to the atomic API, so:
Acked-by: Thierry Reding <thierry.reding@gmail.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-pwm@vger.kernel.org,
intel-gfx <intel-gfx@lists.freedesktop.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
linux-acpi@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Len Brown" <lenb@kernel.org>
Subject: Re: [PATCH v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state
Date: Thu, 3 Sep 2020 12:59:09 +0200 [thread overview]
Message-ID: <20200903105909.GA3756465@ulmo> (raw)
In-Reply-To: <20200903105114.9969-7-hdegoede@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2156 bytes --]
On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote:
> Before this commit pwm_lpss_apply() was making 2 assuming
> 2 pre-conditions were met by the existing hardware state:
I think that "making 2" is too much.
>
> 1. That the base-unit and on-time-div read back from the
> control register are those actually in use, so that it
> can skip setting the update bit if the read-back value
> matches the desired values.
>
> 2. That the controller is enabled when the cached
> pwm_state.enabled says that the controller is enabled.
>
> As the long history of fixes for subtle (often suspend/resume)
> lpss-pwm issues shows, this assumptions are not necessary
> always true.
>
> 1. Specifically is not true on some (*) Cherry Trail devices
> with a nasty GFX0._PS3 method which: a. saves the ctrl reg value.
> b. sets the base-unit to 0 and writes the update bit to apply/commit
> c. restores the original ctrl value without setting the update bit,
> so that the 0 base-unit value is still in use.
>
> 2. Assumption 2. currently is true, but only because of the code which
> saves/restores the state on suspend/resume. By convention restoring the
> PWM state should be done by the PWM consumer and the presence of this
> code in the pmw-lpss driver is a bug. Therefor the save/restore code will
> be dropped in the next patch in this series, after which this assumption
> also is no longer true.
>
> This commit changes the pwm_lpss_apply() to make any assumptions about the
Did you mean to say "... to _not_ make any assumptions ..."?
> state the hardware is in. Instead it makes pwm_lpss_apply() always fully
> program the PWM controller, making it much less fragile.
>
> *) Seen on the Acer One 10 S1003, Lenovo Ideapad Miix 310 and 320 models
> and various Medion models.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/pwm/pwm-lpss.c | 21 +++++++++------------
> 1 file changed, 9 insertions(+), 12 deletions(-)
Other than the two small nits, this looks much more idiomatic and true
to the atomic API, so:
Acked-by: Thierry Reding <thierry.reding@gmail.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-09-03 10:59 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-03 10:50 [Intel-gfx] [PATCH v9 00/17] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API Hans de Goede
2020-09-03 10:50 ` Hans de Goede
2020-09-03 10:50 ` Hans de Goede
2020-09-03 10:50 ` [Intel-gfx] [PATCH v9 01/17] ACPI / LPSS: Resume Cherry Trail PWM controller in no-irq phase Hans de Goede
2020-09-03 10:50 ` Hans de Goede
2020-09-03 10:50 ` Hans de Goede
2020-09-03 10:50 ` [Intel-gfx] [PATCH v9 02/17] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once (at activation) Hans de Goede
2020-09-03 10:50 ` Hans de Goede
2020-09-03 10:50 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 03/17] pwm: lpss: Fix off by one error in base_unit math in pwm_lpss_prepare() Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 04/17] pwm: lpss: Add range limit check for the base_unit register value Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 05/17] pwm: lpss: Add pwm_lpss_prepare_enable() helper Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on existing hardware state Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:59 ` Thierry Reding [this message]
2020-09-03 10:59 ` Thierry Reding
2020-09-03 10:59 ` Thierry Reding
2020-09-03 11:12 ` [Intel-gfx] " Hans de Goede
2020-09-03 11:12 ` Hans de Goede
2020-09-03 11:12 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 07/17] pwm: lpss: Remove suspend/resume handlers Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 11:00 ` [Intel-gfx] " Thierry Reding
2020-09-03 11:00 ` Thierry Reding
2020-09-03 11:00 ` Thierry Reding
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 08/17] pwm: crc: Fix period / duty_cycle times being off by a factor of 256 Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 09/17] pwm: crc: Fix off-by-one error in the clock-divider calculations Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 10/17] pwm: crc: Fix period changes not having any effect Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 11/17] pwm: crc: Enable/disable PWM output on enable/disable Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 12/17] pwm: crc: Implement apply() method to support the new atomic PWM API Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 13/17] pwm: crc: Implement get_state() method Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 14/17] drm/i915: panel: Add get_vbt_pwm_freq() helper Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 15/17] drm/i915: panel: Honor the VBT PWM frequency for devs with an external PWM controller Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 16/17] drm/i915: panel: Honor the VBT PWM min setting " Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` [Intel-gfx] [PATCH v9 17/17] drm/i915: panel: Use atomic PWM API " Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 10:51 ` Hans de Goede
2020-09-03 11:34 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API Patchwork
2020-09-03 11:49 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-09-03 19:58 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
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=20200903105909.GA3756465@ulmo \
--to=thierry.reding@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=rjw@rjwysocki.net \
--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 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.