1. 17 Jan, 2023 2 commits
  2. 10 Jan, 2023 5 commits
  3. 05 Jan, 2023 16 commits
    • Harry Wentland's avatar
      drm/amd/display: Don't restrict bpc to 8 bpc · f2b8a788
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      This will let us pass kms_hdr.bpc_switch.
      
      I don't see any good reasons why we still need to
      limit bpc to 8 bpc and doing so is problematic when
      we enable HDR.
      
      If I remember correctly there might have been some
      displays out there where the advertised link bandwidth
      was not large enough to drive the default timing at
      max bpc. This would leave to an atomic commit/check
      failure which should really be handled in compositors
      with some sort of fallback mechanism.
      
      If this somehow turns out to still be an issue I
      suggest we add a module parameter to allow users to
      limit the max_bpc to a desired value.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      f2b8a788
    • Harry Wentland's avatar
      drm/amd/display: Add default case for output_color_space switch · 1c98f573
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      1c98f573
    • Harry Wentland's avatar
      drm/amd/display: Add debugfs for testing output colorspace · 4783cc7b
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      In order to IGT test colorspace we'll want to print
      the currently enabled colorspace on a stream. We add
      a new debugfs to do so, using the same scheme as
      current bpc reporting.
      
      This might also come in handy when debugging display
      issues.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      4783cc7b
    • Harry Wentland's avatar
      drm/amd/display: Add support for explicit BT601_YCC · 468f3103
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      We use this by default but if userspace passes this explicitly
      we should respect it.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      468f3103
    • Joshua Ashton's avatar
      drm/amd/display: Always set crtcinfo from create_stream_for_sink · 06922168
      Joshua Ashton authored
      
      
      Given that we always pass dm_state into here now, this won't ever
      trigger anymore.
      
      This is needed for we will always fail mode validation with invalid
      clocks or link bandwidth errors.
      
      Signed-off-by: Joshua Ashton's avatarJoshua Ashton <joshua@froggi.es>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      06922168
    • Harry Wentland's avatar
      drm/amd/display: Send correct DP colorspace infopacket · 9c9a9db8
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      Look at connector->colorimetry to determine output colorspace.
      
      We don't want to impact current SDR behavior, so
      DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      9c9a9db8
    • Harry Wentland's avatar
      drm/amd/display: Set colorspace for HDMI infoframe · 556619b9
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      Now that we have the HDMI colorimetry fill the corresponding
      AVI infoframe info. Also signal "mode_changed" if colorimetry
      changed.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      556619b9
    • Harry Wentland's avatar
      drm/amd/display: Register Colorspace property for DP and HDMI · 9246196a
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      We want compositors to be able to set the output
      colorspace on DP and HDMI outputs, based on the
      caps reported from the receiver via EDID.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      9246196a
    • Harry Wentland's avatar
      drm/amd/display: Always pass connector_state to stream validation · f6ab07b4
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      We need the connector_state for colorspace and scaling information
      and can get it from connector->state.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      f6ab07b4
    • Harry Wentland's avatar
      drm/connector: Print connector colorspace in state debugfs · 7e2a454f
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      7e2a454f
    • Harry Wentland's avatar
      drm/connector: Allow drivers to pass list of supported colorspaces · 671b98e5
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      Drivers might not support all colorspaces defined in
      dp_colorspaces and hdmi_colorspaces. This results in
      undefined behavior when userspace is setting an
      unsupported colorspace.
      
      Allow drivers to pass the list of supported colorspaces
      when creating the colorspace property.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      671b98e5
    • Harry Wentland's avatar
      drm/connector: Pull out common create_colorspace_property code · 23badc4d
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      23badc4d
    • Harry Wentland's avatar
      drm/connector: Convert DRM_MODE_COLORIMETRY to enum · be90be3e
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      This allows us to use strongly typed arguments.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      be90be3e
    • Harry Wentland's avatar
      drm/connector: Drop COLORIMETRY_NO_DATA · 619d0805
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      The value is the same as DEFAULT. The HDMI_COLORIMETRY_NO_DATA
      makes sense for the infopacket but it's meaningless for the
      connector colorspace. or, in otherwise, just means to go with
      driver default.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      619d0805
    • Harry Wentland's avatar
      drm/connector: print max_requested_bpc in state debugfs · fa59b88f
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      
      
      This is useful to understand the bpc defaults and
      support of a driver.
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      fa59b88f
    • Harry Wentland's avatar
      drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF · 4efc5b21
      Harry Wentland authored and Joshua Ashton's avatar Joshua Ashton committed
      The EDID of an HDR display defines EOTFs that are supported
      by the display and can be set in the HDR metadata infoframe.
      Userspace is expected to read the EDID and set an appropriate
      HDR_OUTPUT_METADATA.
      
      In drm_parse_hdr_metadata_block the kernel reads the supported
      EOTFs from the EDID and stores them in the
      drm_connector->hdr_sink_metadata. While doing so it also
      filters the EOTFs to the EOTFs the kernel knows about.
      When an HDR_OUTPUT_METADATA is set it then checks to
      make sure the EOTF is a supported EOTF. In cases where
      the kernel doesn't know about a new EOTF this check will
      fail, even if the EDID advertises support.
      
      Since it is expected that userspace reads the EDID to understand
      what the display supports it doesn't make sense for DRM to block
      an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't
      understand.
      
      This comes with the added benefit of future-proofing metadata
      support. If the spec defines a new EOTF there is no need to
      update DRM and an compositor can immediately make use of it.
      
      Fixes: wayland/weston#609
      
      
      
      v2: Distinguish EOTFs defind in kernel and ones defined
          in EDID in the commit description (Pekka)
      
      v3: Rebase; drm_hdmi_infoframe_set_hdr_metadata moved
          to drm_hdmi_helper.c
      
      Signed-off-by: Harry Wentland's avatarHarry Wentland <harry.wentland@amd.com>
      Cc: Pekka Paalanen <ppaalanen@gmail.com>
      Cc: Sebastian Wick <sebastian.wick@redhat.com>
      Cc: Vitaly.Prosyak@amd.com
      Cc: Uma Shankar <uma.shankar@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Joshua Ashton <joshua@froggi.es>
      Cc: dri-devel@lists.freedesktop.org
      Cc: amd-gfx@lists.freedesktop.org
      Acked-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.com>
      4efc5b21
  4. 30 Dec, 2022 1 commit
    • Randy Dunlap's avatar
      drm/amd/display: fix dc/core/dc.c kernel-doc · 01fdc9c0
      Randy Dunlap authored
      
      
      Fix all kernel-doc warnings in dc/core/dc.c:
      
      dc.c:385: warning: missing initial short description on line:
       *  dc_stream_adjust_vmin_vmax:
      dc.c:392: warning: contents before sections
      dc.c:399: warning: No description found for return value of 'dc_stream_adjust_vmin_vmax'
      dc.c:434: warning: Excess function parameter 'adjust' description in 'dc_stream_get_last_used_drr_vtotal'
      dc.c:434: warning: No description found for return value of 'dc_stream_get_last_used_drr_vtotal'
      dc.c:574: warning: No description found for return value of 'dc_stream_configure_crc'
      dc.c:1746: warning: No description found for return value of 'dc_commit_state_no_check'
      dc.c:4991: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
       * dc_extended_blank_supported 0 Decide whether extended blank is supported
      dc.c:4991: warning: missing initial short description on line:
       * dc_extended_blank_supported 0 Decide whether extended blank is supported
      dc.c:4723: warning: Function parameter or member 'dc' not described in 'dc_enable_dmub_outbox'
      dc.c:4926: warning: Function parameter or member 'dc' not described in 'dc_process_dmub_dpia_hpd_int_enable'
      dc.c:4926: warning: Function parameter or member 'hpd_int_enable' not described in 'dc_process_dmub_dpia_hpd_int_enable'
      12 warnings
      
      Signed-off-by: Randy Dunlap's avatarRandy Dunlap <rdunlap@infradead.org>
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Hamza Mahfooz <hamza.mahfooz@amd.com>
      Cc: Harry Wentland <harry.wentland@amd.com>
      Cc: Leo Li <sunpeng.li@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com>
      Cc: amd-gfx@lists.freedesktop.org
      Signed-off-by: default avatarHamza Mahfooz <hamza.mahfooz@amd.com>
      01fdc9c0
  5. 27 Dec, 2022 2 commits
  6. 22 Dec, 2022 3 commits
    • bhawanpreet lakha's avatar
      drm/amd/display: Fix dsc mismatch of acquire and validation of dsc engine · 712d8e71
      bhawanpreet lakha authored
      
      
      [Why]
      We skip dsc_validation on pipes that are underlays, but in the
      acquire_dsc code we don't have this check.
      
      In certain conditions (when underlay pipe index is lower) we will assign
      the dsc resource to the underlay pipe and skip the base pipe.
      
      Now during dsc_validation we will skip the underlay pipe (this has the
      dsc resource) but try to validate the base pipe(this doesn't have a dsc
      resource) due to this mismatch we hit a NULLPTR
      
      [How]
      In the acquire_dsc add a check for underlay pipe so we
      don't acquire a dsc resource for this pipe. This will match the
      acquire/validation conditions.
      
      Reviewed-by: default avatarWenjing Liu <Wenjing.Liu@amd.com>
      Reviewed-by: default avatarHersen Wu <Hersenxs.Wu@amd.com>
      Acked-by: default avatarPraful Swarnakar <Praful.Swarnakar@amd.com>
      Signed-off-by: bhawanpreet lakha's avatarBhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
      712d8e71
    • stanley yang's avatar
      drm/amdgpu: remove enable ras cmd call trace · 2da03936
      stanley yang authored
      
      
      [Why]
          [   41.285804] RIP: 0010:amdgpu_ras_feature_enable+0x15c/0x310 [amdgpu]
          [   41.285945] Code: 48 89 c1 48 c7 c2 b9 f2 88 c1 48 c7 c0 c0 f2 88 c1 49 8b 3c 24 48 0f 44 d0 48 c7 c6 98 33 80 c1 e8 5f 52 75 d9 e9 fa fe ff ff <0f> 0b e9 66 ff ff ff 48 8b 3d 86 8c 0f da ba 00 04 00 00 be c0 0d
          [   41.285946] RSP: 0018:ffffbccdc72efc90 EFLAGS: 00010246
          [   41.285948] RAX: 0000000000000004 RBX: ffff931897406980 RCX: 0000000000000002
          [   41.285949] RDX: 0000000000000dc0 RSI: 0000000000000002 RDI: ffff931500042b00
          [   41.285950] RBP: ffffbccdc72efcc0 R08: 0000000000000002 R09: ffff931885b87000
          [   41.285951] R10: 0000000000ffff10 R11: 0000000000000001 R12: ffff931893e20000
          [   41.285952] R13: 0000000000000001 R14: ffff931885b87000 R15: 0000000000000000
          [   41.285953] FS:  0000000000000000(0000) GS:ffff931c6f200000(0000) knlGS:0000000000000000
          [   41.285954] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
          [   41.285955] CR2: 000055dd6f532008 CR3: 000000061b010006 CR4: 00000000003706e0
          [   41.285956] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
          [   41.285957] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
          [   41.285958] Call Trace:
          [   41.285959]  <TASK>
          [   41.285963]  ? gfx_v11_0_early_init+0x250/0x250 [amdgpu]
          [   41.286117]  gfx_v11_0_late_init+0x8c/0xb0 [amdgpu]
          [   41.286271]  amdgpu_device_ip_late_init+0x8d/0x3c0 [amdgpu]
          [   41.286401]  amdgpu_device_init.cold+0x1677/0x1fda [amdgpu]
          [   41.286616]  ? pci_bus_read_config_word+0x4a/0x70
          [   41.286621]  ? do_pci_enable_device+0xdb/0x110
          [   41.286625]  amdgpu_driver_load_kms+0x1a/0x160 [amdgpu]
          [   41.286762]  amdgpu_pci_probe+0x18d/0x3a0 [amdgpu]
          [   41.286898]  local_pci_probe+0x4b/0x90
          [   41.286901]  work_for_cpu_fn+0x1a/0x30
          [   41.286903]  process_one_work+0x22b/0x3d0
          [   41.286905]  worker_thread+0x223/0x420
          [   41.286907]  ? process_one_work+0x3d0/0x3d0
          [   41.286908]  kthread+0x12a/0x150
          [   41.286911]  ? set_kthread_struct+0x50/0x50
          [   41.286913]  ret_from_fork+0x22/0x30
      
      [How]
          For specific asic, only mem ecc is enabled, sram ecc is not enabled,
          but it still need to send ras enable cmd to gfx block to support
          poison mode, so add check posion mode.
      
      Signed-off-by: stanley yang's avatarStanley.Yang <Stanley.Yang@amd.com>
      Reviewed-by: default avatarHawking Zhang <Hawking.Zhang@amd.com>
      2da03936
    • stanley yang's avatar
      drm/amdgpu: correct umc poison mode set value · 2bc5cec3
      stanley yang authored
      
      
      For GFX 11.0.3, Due to security policy, there is no way to check UcFatalEn
      field of UMCCH0_0_GeccCtrl to identify UMC poison mode. This is workaround
      force set umc poison mode as 1 for GFX 11.0.3
      
      Signed-off-by: stanley yang's avatarStanley.Yang <Stanley.Yang@amd.com>
      Reviewed-by: default avatarHawking Zhang <Hawking.Zhang@amd.com>
      2bc5cec3
  7. 21 Dec, 2022 11 commits