Skip to content
  1. May 26, 2021
  3. May 25, 2021
    • Imre Deak's avatar
      drm/i915/debugfs: Print remap info for DPT VMAs as well · 0f926e5c
      Imre Deak authored 
      

Similarly to GGTT VMAs, DPT VMAs can be also a remapped or rotated view
of the mapped object, so make sure we debug print the details for these
views as well besides the normal view.

While at it also fix the debug print for the VMA type of DPT VMAs.

Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
Reviewed-by: default avatarJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-3-imre.deak@intel.com
      0f926e5c
    • Imre Deak's avatar
      drm/i915/adlp: Fix GEM VM asserts for DPT VMs · 74862d4c
      Imre Deak authored 
      

An object mapped via DPT can have remapped and rotated VMA instances
besides the normal VMA instance, similarly to GGTT VMA instances.
Adjust the corresponding VMA lookup asserts.

While at it also check if a DPT VM is passed incorrectly to
i915_vm_to_ppgtt().

Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
Reviewed-by: default avatarJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-2-imre.deak@intel.com
      74862d4c
    • Imre Deak's avatar
      drm/i915/adlp: Require DPT FB CCS color planes to be 2MB aligned · b3de1d07
      Imre Deak authored 
      

All DPT FB color plane surface base addresses must be 2MB aligned. On
ADL_P this means that the offsets in CCS FB object must be also 2MB
aligned. Adjusting unaligned offsets for these FBs during commit time
(compensating with the x/y offsets) doesn't work, since the big
alignment would most probably lead to an x/y offset mismatch error
between the main and CCS planes.

We can overcome this limitation by remapping CCS FBs, so that each color
plane is at an aligned offset, leaving x/y for each plane unadjusted
during commit and so not causing an x/y mismatch error. However
remapping for CCS FBs will be done as a follow-up, so for now require
that user space allocates the FB obj with properly aligned planes.

v2: s/SZ_2M/512*4k/ for clarity. (Ville)

Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210524172703.2113058-1-imre.deak@intel.com
      b3de1d07
    • Lucas De Marchi's avatar
      drm/i915/display: fix typo when returning table · 6f20785b
      Lucas De Marchi authored 
      Fix table returned when port_clock > 270000:

	drivers/gpu/drm/i915/display/intel_ddi_buf_trans.c:752:47: error: variable 'adlp_dkl_phy_dp_ddi_trans_hbr2_hbr3' is not needed and will not be emitted [-Werror,-Wunneeded-internal-declaration]

Initial version of the patch had it in a single table, but on second
version the table got split, but we continued to reference just one of
them.

Fixes: ca962882

 ("drm/i915/adl_p: Define and use ADL-P specific DP translation tables")
Reported-by: default avatarkernel test robot <lkp@intel.com>
Signed-off-by: default avatarLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: default avatarAnusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210521005209.4058702-1-lucas.demarchi@intel.com
      6f20785b
  5. May 24, 2021
  7. May 21, 2021
    • Imre Deak's avatar
      drm/i915: Reenable LTTPR non-transparent LT mode for DPCD_REV<1.4 · cb4920cc
      Imre Deak authored 
      

The driver currently disables the LTTPR non-transparent link training
mode for sinks with a DPCD_REV<1.4, based on the following description
of the LTTPR DPCD register range in DP standard 2.0 (at the 0xF0000
register description):

""
LTTPR-related registers at DPCD Addresses F0000h through F02FFh are valid
only for DPCD r1.4 (or higher).
"""

The transparent link training mode should still work fine, however the
implementation for this in some retimer FWs seems to be broken, see the
References: link below.

After discussions with DP standard authors the above "DPCD r1.4" does
not refer to the DPCD revision (stored in the DPCD_REV reg at 0x00000),
rather to the "LTTPR field data structure revision" stored in the
0xF0000 reg. An update request has been filed at vesa.org (see
wg/Link/documentComment/3746) for the upcoming v2.1 specification to
clarify the above description along the following lines:

"""
LTTPR-related registers at DPCD Addresses F0000h through F02FFh are
valid only for LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 1.4 (or
higher)
"""

Based on my tests Windows uses the non-transparent link training mode
for DPCD_REV==1.2 sinks as well (so presumably for all DPCD_REVs), and
forcing it to use transparent mode on ICL/TGL platforms leads to the
same LT failure as reported at the References: link.

Based on the above let's assume that the transparent link training mode
is not well tested/supported and align the code to the correct
interpretation of what the r1.4 version refers to.

Reported-and-tested-by: default avatarCasey Harkins <caseyharkins@gmail.com>
Tested-by: default avatarKhaled Almahallawy <khaled.almahallawy@intel.com>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3415
Fixes: 264613b4

 ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4")
Cc: <stable@vger.kernel.org> # v5.11+
Signed-off-by: default avatarImre Deak <imre.deak@intel.com>
Reviewed-by: default avatarKhaled Almahallawy <khaled.almahallawy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210512212809.1234701-1-imre.deak@intel.com
      cb4920cc
  9. May 20, 2021
  11. May 19, 2021
  13. May 18, 2021
  15. May 15, 2021