Skip to content
  1. Jan 15, 2021
  2. Jan 14, 2021
  3. Jan 13, 2021
    • Chris Wilson's avatar
      drm/i915: Allow the sysadmin to override security mitigations · 984cadea
      Chris Wilson authored
      The clear-residuals mitigation is a relatively heavy hammer and under some
      circumstances the user may wish to forgo the context isolation in order
      to meet some performance requirement. Introduce a generic module
      parameter to allow selectively enabling/disabling different mitigations.
      
      To disable just the clear-residuals mitigation (on Ivybridge, Baytrail,
      or Haswell) use the module parameter: i915.mitigations=auto,!residuals
      
      Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1858
      Fixes: 47f8253d
      
       ("drm/i915/gen7: Clear all EU/L3 residual contexts")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: stable@vger.kernel.org # v5.7
      Reviewed-by: default avatarJon Bloomfield <jon.bloomfield@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-3-chris@chris-wilson.co.uk
      (cherry picked from commit f7452c7c
      
      )
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      984cadea
    • Chris Wilson's avatar
      drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail · 09aa9e45
      Chris Wilson authored
      The mitigation is required for all gen7 platforms, now that it does not
      cause GPU hangs, restore it for Ivybridge and Baytrail.
      
      Fixes: 47f8253d
      
       ("drm/i915/gen7: Clear all EU/L3 residual contexts")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
      Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
      Cc: Bloomfield Jon <jon.bloomfield@intel.com>
      Reviewed-by: default avatarAkeem G Abodunrin <akeem.g.abodunrin@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-2-chris@chris-wilson.co.uk
      (cherry picked from commit 008ead6e
      
      )
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      09aa9e45
    • Chris Wilson's avatar
      drm/i915/gt: Limit VFE threads based on GT · ffaf9789
      Chris Wilson authored
      MEDIA_STATE_VFE only accepts the 'maximum number of threads' in the
      range [0, n-1] where n is #EU * (#threads/EU) with the number of threads
      based on plaform and the number of EU based on the number of slices and
      subslices. This is a fixed number per platform/gt, so appropriately
      limit the number of threads we spawn to match the device.
      
      v2: Oversaturate the system with tasks to force execution on every HW
      thread; if the thread idles it is returned to the pool and may be reused
      again before an unused thread.
      
      v3: Fix more state commands, which was causing Baytrail to barf.
      v4: STATE_CACHE_INVALIDATE requires a stall on Ivybridge
      
      Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2024
      Fixes: 47f8253d
      
       ("drm/i915/gen7: Clear all EU/L3 residual contexts")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
      Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Randy Wright <rwright@hpe.com>
      Cc: stable@vger.kernel.org # v5.7+
      Reviewed-by: default avatarAkeem G Abodunrin <akeem.g.abodunrin@intel.com>
      Reviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210111225220.3483-1-chris@chris-wilson.co.uk
      (cherry picked from commit eebfb32e
      
      )
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      ffaf9789
  4. Jan 12, 2021
  5. Jan 11, 2021
    • Jani Nikula's avatar
      drm/i915/backlight: fix CPU mode backlight takeover on LPT · bb83d5fb
      Jani Nikula authored
      The pch_get_backlight(), lpt_get_backlight(), and lpt_set_backlight()
      functions operate directly on the hardware registers. If inverting the
      value is needed, using intel_panel_compute_brightness(), it should only
      be done in the interface between hardware registers and
      panel->backlight.level.
      
      The CPU mode takeover code added in commit 5b1ec9ac
      ("drm/i915/backlight: Fix backlight takeover on LPT, v3.") reads the
      hardware register and converts to panel->backlight.level correctly,
      however the value written back should remain in the hardware register
      "domain".
      
      This hasn't been an issue, because GM45 machines are the only known
      users of i915.invert_brightness and the brightness invert quirk, and
      without one of them no conversion is made. It's likely nobody's ever hit
      the problem.
      
      Fixes: 5b1ec9ac
      
       ("drm/i915/backlight: Fix backlight takeover on LPT, v3.")
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: <stable@vger.kernel.org> # v5.1+
      Reviewed-by: default avatarLyude Paul <lyude@redhat.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210108152841.6944-1-jani.nikula@intel.com
      (cherry picked from commit 0d4ced1c
      
      )
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      bb83d5fb
    • Chris Wilson's avatar
      drm/i915: Disable RPM wakeref assertions during driver shutdown · 057fe353
      Chris Wilson authored
      
      
      As with the regular suspend paths, also disable the wakeref assertions
      as we disable the driver during shutdown.
      
      Reported-by: default avatarHans de Goede <hdegoede@redhat.com>
      Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2899
      Fixes: fe0f1e3b
      
       ("drm/i915: Shut down displays gracefully on reboot")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Tested-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20210104203905.19248-1-chris@chris-wilson.co.uk
      (cherry picked from commit 19fe4ac6
      
      )
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      057fe353
    • Hans de Goede's avatar
      drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no... · 00cb645f
      Hans de Goede authored
      drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence
      
      Commit 25b4620e ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
      added an intel_dsi_msleep() helper which skips sleeping if the
      MIPI-sequences have a version of 3 or newer and the panel is in vid-mode;
      and it moved a bunch of msleep-s over to this new helper.
      
      This was based on my reading of the big comment around line 730 which
      starts with "Panel enable/disable sequences from the VBT spec.",
      where the "v3 video mode seq" column does not have any wait t# entries.
      
      Given that this code has been used on a lot of different devices without
      issues until now, it seems that my interpretation of the spec here is
      mostly correct.
      
      But now I have encountered one device, an Acer Aspire Switch 10 E
      SW3-016, where the panel will not light up unless we do actually honor the
      panel_on_delay after exexuting the MIPI_SEQ_PANEL_ON sequence.
      
      What seems to set this model apart is that it is lacking a
      MIPI_SEQ_DEASSERT_RESET sequence, which is where the power-on
      delay usually happens.
      
      Fix the panel not lighting up on this model by using an unconditional
      msleep(panel_on_delay) instead of intel_dsi_msleep() when there is
      no MIPI_SEQ_DEASSERT_RESET sequence.
      
      Fixes: 25b4620e
      
       ("drm/i915/dsi: Skip delays for v3 VBTs in vid-mode")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201118124058.26021-1-hdegoede@redhat.com
      (cherry picked from commit 6fdb335f
      
      )
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      00cb645f