1. 24 Nov, 2020 1 commit
  2. 23 Nov, 2020 1 commit
  3. 20 Nov, 2020 2 commits
  4. 19 Nov, 2020 2 commits
  5. 18 Nov, 2020 16 commits
  6. 17 Nov, 2020 2 commits
    • Bob Paauwe's avatar
      drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms · b896898c
      Bob Paauwe authored
      The WA specifies that we need to toggle a SDE chicken bit on and then
      off as the final step in preparation for s0ix entry.
      
          Bspec: 33450
          Bspec: 8402
      
      However, something is happening after we toggle the bit that causes
      the WA to be invalidated. This makes dispcnlunit1_cp_xosc_clkreq
      active being already in s0ix state i.e SLP_S0 counter incremented.
      Tweaking the Wa_14010685332 by setting the bit on suspend and clearing
      it on resume turns down the dispcnlunit1_cp_xosc_clkreq.
      B.Spec has Documented this tweaked sequence of WA as an alternative.
      Let keep this tweaked WA for Gen11 platforms and keep untweaked WA for
      other platforms which never observed this issue.
      
      v2 (MattR):
       - Change the comment on the workaround to give PCH names rather than
         platform names.  Although the bspec is setup to list workarounds by
         platform, the hardware team has confirmed that the actual issue being
         worked around here is something that was introduced back in the
         Cannon Lake PCH and carried forward to subsequent PCH's.
       - Extend the untweaked version of the workaround to include  PCH_CNP as
         well.  Note that since PCH_CNP is used to represent CMP, this will
         apply on CML and some variants of RKL too.
       - Cap the untweaked version of the workaround so that it won't apply to
         "fake" PCH's (i.e., DG1).  The issue we're working around really is
         an issue in the PCH itself, not the South Display, so it shouldn't
         apply when there isn't a real PCH.
      
      v3:
       - use intel_de_rmw(). [Rodrigo]
      
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarBob Paauwe <bob.j.paauwe@intel.com>
      Signed-off-by: default avatarAnshuman Gupta <anshuman.gupta@intel.com>
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201110121700.4338-1-anshuman.gupta@intel.comReviewed-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      b896898c
    • Ville Syrjälä's avatar
      drm/i915: Handle max_bpc==16 · 2ca5a7b8
      Ville Syrjälä authored
      EDID can declare the maximum supported bpc up to 16,
      and apparently there are displays that do so. Currently
      we assume 12 bpc is tha max. Fix the assumption and
      toss in a MISSING_CASE() for any other value we don't
      expect to see.
      
      This fixes modesets with a display with EDID max bpc > 12.
      Previously any modeset would just silently fail on platforms
      that didn't otherwise limit this via the max_bpc property.
      In particular we don't add the max_bpc property to HDMI
      ports on gmch platforms, and thus we would see the raw
      max_bpc coming from the EDID.
      
      I suppose we could already adjust this to also allow 16bpc,
      but seeing as no current platform supports that there is
      little point.
      
      Cc: stable@vger.kernel.org
      Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2632Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20201110210447.27454-1-ville.syrjala@linux.intel.comReviewed-by: default avatarJosé Roberto de Souza <jose.souza@intel.com>
      2ca5a7b8
  7. 16 Nov, 2020 12 commits
  8. 13 Nov, 2020 4 commits