[Intel-gfx] [PATCH v2 2/6] drm/i915: Disable preemption and sleeping while using the punit sideband
Hans de Goede
hdegoede at redhat.com
Mon Jan 15 11:49:56 UTC 2018
Hi,
On 15-01-18 11:28, Chris Wilson wrote:
> While we talk to the punit over its sideband, we need to prevent the cpu
> from sleeping in order to prevent a potential machine hang.
>
> Note that by itself, it appears that pm_qos_update_request (via
> intel_idle) doesn't provide a sufficient barrier to ensure that all core
> are indeed awake (out of Cstate) and that the package is awake. To do so,
> we need to supplement the pm_qos with a manual ping on_each_cpu.
>
> v2: Restrict the heavy-weight wakeup to just the ISOF_PORT_PUNIT, there
> is insufficient evidence to implicate a wider problem atm. Similarly,
> restrict the w/a to Valleyview, as Cherryview doesn't have an angry cadre
> of users.
>
> The working theory, courtesy of Ville and Hans, is the issue lies within
> the power delivery and so is likely to be unit and board specific and
> occurs when both the unit/fw require extra power at the same time as the
> cpu package is changing its own power state.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109051
> References: https://bugs.freedesktop.org/show_bug.cgi?id=102657
> References: https://bugzilla.kernel.org/show_bug.cgi?id=195255
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Mika Kuoppala <mika.kuoppala at linux.intel.com>
> Cc: Hans de Goede <hdegoede at redhat.com>
> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
First of all, Chris many thanks for working on this and tracking this
down!
This looks good to me:
Acked-by: Hans de Goede <hdegoede at redhat.com>
As you may know from: https://bugzilla.kernel.org/show_bug.cgi?id=109051
I've 2 patches which people in that bug are testing to workaround this
issue, but it seems that this is a much better fix. The people testing
are capable of building their own kernels and actually have VLV systems
in production(ish) use, they have been running with my patches for a
couple of weeks now.
If we want to go with this patch instead I think we should ask them to
switch to running a test-kernel with this patch (any other patches needed?)
rather then that they keep testing 2 patches which we've no intent to
upstream ...
So shall I ask people in bug109051 to test this patch, or do you want to
just keep this to the intel-gfx list for now?
Regards,
Hans
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 +++
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_sideband.c | 89 +++++++++++++++++++++++++++--------
> 3 files changed, 77 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 6c8da9d20c33..d4b90cc0130b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -902,6 +902,9 @@ static int i915_driver_init_early(struct drm_i915_private *dev_priv,
> spin_lock_init(&dev_priv->uncore.lock);
>
> mutex_init(&dev_priv->sb_lock);
> + pm_qos_add_request(&dev_priv->sb_qos,
> + PM_QOS_CPU_DMA_LATENCY, PM_QOS_DEFAULT_VALUE);
> +
> mutex_init(&dev_priv->modeset_restore_lock);
> mutex_init(&dev_priv->av_mutex);
> mutex_init(&dev_priv->wm.wm_mutex);
> @@ -953,6 +956,9 @@ static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
> intel_irq_fini(dev_priv);
> i915_workqueues_cleanup(dev_priv);
> i915_engines_cleanup(dev_priv);
> +
> + pm_qos_remove_request(&dev_priv->sb_qos);
> + mutex_destroy(&dev_priv->sb_lock);
> }
>
> static int i915_mmio_setup(struct drm_i915_private *dev_priv)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c42015b05b47..d95d8c3d04aa 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1886,6 +1886,7 @@ struct drm_i915_private {
>
> /* Sideband mailbox protection */
> struct mutex sb_lock;
> + struct pm_qos_request sb_qos;
>
> /** Cached value of IMR to avoid reads in updating the bitfield */
> union {
> diff --git a/drivers/gpu/drm/i915/intel_sideband.c b/drivers/gpu/drm/i915/intel_sideband.c
> index 75c872bb8cc9..d56eda33734e 100644
> --- a/drivers/gpu/drm/i915/intel_sideband.c
> +++ b/drivers/gpu/drm/i915/intel_sideband.c
> @@ -22,6 +22,8 @@
> *
> */
>
> +#include <asm/iosf_mbi.h>
> +
> #include "i915_drv.h"
> #include "intel_drv.h"
>
> @@ -39,18 +41,48 @@
> /* Private register write, double-word addressing, non-posted */
> #define SB_CRWRDA_NP 0x07
>
> -static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
> - u32 port, u32 opcode, u32 addr, u32 *val)
> +static void ping(void *info)
> {
> - u32 cmd, be = 0xf, bar = 0;
> - bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
> +}
>
> - cmd = (devfn << IOSF_DEVFN_SHIFT) | (opcode << IOSF_OPCODE_SHIFT) |
> - (port << IOSF_PORT_SHIFT) | (be << IOSF_BYTE_ENABLES_SHIFT) |
> - (bar << IOSF_BAR_SHIFT);
> +static void __vlv_punit_get(struct drm_i915_private *dev_priv)
> +{
> + iosf_mbi_punit_acquire();
>
> - WARN_ON(!mutex_is_locked(&dev_priv->sb_lock));
> + /*
> + * Prevent the cpu from sleeping while we use this sideband, otherwise
> + * the punit may cause a machine hang. The issue appears to be isolated
> + * with changing the power state of the CPU package while changing
> + * the power state via the punit, and we have only observed it
> + * reliably on 4-core Baytail systems suggesting the issue is in the
> + * power delivery mechanism and likely to be be board/function
> + * specific. Hence we presume the workaround needs only be applied
> + * to the Valleyview P-unit and not all sideband communications.
> + */
> + if (IS_VALLEYVIEW(dev_priv)) {
> + pm_qos_update_request(&dev_priv->sb_qos, 0);
> + on_each_cpu(ping, NULL, 1);
> + }
> +}
> +
> +static void __vlv_punit_put(struct drm_i915_private *dev_priv)
> +{
> + if (IS_VALLEYVIEW(dev_priv))
> + pm_qos_update_request(&dev_priv->sb_qos, PM_QOS_DEFAULT_VALUE);
>
> + iosf_mbi_punit_release();
> +}
> +
> +static int vlv_sideband_rw(struct drm_i915_private *dev_priv,
> + u32 devfn, u32 port, u32 opcode,
> + u32 addr, u32 *val)
> +{
> + const bool is_read = (opcode == SB_MRD_NP || opcode == SB_CRRDDA_NP);
> + int err;
> +
> + lockdep_assert_held(&dev_priv->sb_lock);
> +
> + /* Flush the previous comms, just in case it failed last time. */
> if (intel_wait_for_register(dev_priv,
> VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
> 5)) {
> @@ -59,22 +91,33 @@ static int vlv_sideband_rw(struct drm_i915_private *dev_priv, u32 devfn,
> return -EAGAIN;
> }
>
> - I915_WRITE(VLV_IOSF_ADDR, addr);
> - I915_WRITE(VLV_IOSF_DATA, is_read ? 0 : *val);
> - I915_WRITE(VLV_IOSF_DOORBELL_REQ, cmd);
> -
> - if (intel_wait_for_register(dev_priv,
> - VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
> - 5)) {
> + preempt_disable();
> +
> + I915_WRITE_FW(VLV_IOSF_ADDR, addr);
> + I915_WRITE_FW(VLV_IOSF_DATA, is_read ? 0 : *val);
> + I915_WRITE_FW(VLV_IOSF_DOORBELL_REQ,
> + (devfn << IOSF_DEVFN_SHIFT) |
> + (opcode << IOSF_OPCODE_SHIFT) |
> + (port << IOSF_PORT_SHIFT) |
> + (0xf << IOSF_BYTE_ENABLES_SHIFT) |
> + (0 << IOSF_BAR_SHIFT) |
> + IOSF_SB_BUSY);
> +
> + if (__intel_wait_for_register_fw(dev_priv,
> + VLV_IOSF_DOORBELL_REQ, IOSF_SB_BUSY, 0,
> + 10000, 0, NULL) == 0) {
> + if (is_read)
> + *val = I915_READ_FW(VLV_IOSF_DATA);
> + err = 0;
> + } else {
> DRM_DEBUG_DRIVER("IOSF sideband finish wait (%s) timed out\n",
> is_read ? "read" : "write");
> - return -ETIMEDOUT;
> + err = -ETIMEDOUT;
> }
>
> - if (is_read)
> - *val = I915_READ(VLV_IOSF_DATA);
> + preempt_enable();
>
> - return 0;
> + return err;
> }
>
> u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr)
> @@ -84,8 +127,12 @@ u32 vlv_punit_read(struct drm_i915_private *dev_priv, u32 addr)
> WARN_ON(!mutex_is_locked(&dev_priv->pcu_lock));
>
> mutex_lock(&dev_priv->sb_lock);
> + __vlv_punit_get(dev_priv);
> +
> vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_PUNIT,
> SB_CRRDDA_NP, addr, &val);
> +
> + __vlv_punit_put(dev_priv);
> mutex_unlock(&dev_priv->sb_lock);
>
> return val;
> @@ -98,8 +145,12 @@ int vlv_punit_write(struct drm_i915_private *dev_priv, u32 addr, u32 val)
> WARN_ON(!mutex_is_locked(&dev_priv->pcu_lock));
>
> mutex_lock(&dev_priv->sb_lock);
> + __vlv_punit_get(dev_priv);
> +
> err = vlv_sideband_rw(dev_priv, PCI_DEVFN(0, 0), IOSF_PORT_PUNIT,
> SB_CRWRDA_NP, addr, &val);
> +
> + __vlv_punit_put(dev_priv);
> mutex_unlock(&dev_priv->sb_lock);
>
> return err;
>
More information about the Intel-gfx
mailing list