This was never filled in and thus never truly used.

Checking the EDID for content_type support is not required for sending the avi infoframe packet.

Signed-off-by: Joshua Ashton <joshua@froggi.es>

Signed-off-by: Joshua Ashton <joshua@froggi.es>

Signed-off-by: Joshua Ashton <joshua@froggi.es>

Code in get_output_color_space depends on knowing the pixel encoding to
determine whether to pick between eg. COLOR_SPACE_SRGB or
COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver.

Signed-off-by: Joshua Ashton <joshua@froggi.es>

Signed-off-by: Joshua Ashton <joshua@froggi.es>

Replace the messy two if-else chains here that were on the same value with a switch on the enum.

Signed-off-by: Joshua Ashton <joshua@froggi.es>

Signed-off-by: Joshua Ashton <joshua@froggi.es>

Harry Wentland authored Dec 12, 2022 and Joshua Ashton committed Jan 05, 2023

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 <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

Harry Wentland authored Nov 30, 2022 and Joshua Ashton committed Jan 05, 2023

Signed-off-by: Harry 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

Harry Wentland authored Nov 29, 2022 and Joshua Ashton committed Jan 05, 2023

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 <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

Harry Wentland authored Nov 29, 2022 and Joshua Ashton committed Jan 05, 2023

We use this by default but if userspace passes this explicitly
we should respect it.

Signed-off-by: Harry 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

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 <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

Harry Wentland authored Mar 29, 2022 and Joshua Ashton committed Jan 05, 2023

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 <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

Harry Wentland authored Mar 29, 2022 and Joshua Ashton committed Jan 05, 2023

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 <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

Harry Wentland authored Mar 25, 2022 and Joshua Ashton committed Jan 05, 2023

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 <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

Harry Wentland authored Apr 01, 2022 and Joshua Ashton committed Jan 05, 2023

We need the connector_state for colorspace and scaling information
and can get it from connector->state.

Signed-off-by: Harry 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

Harry Wentland authored Nov 30, 2022 and Joshua Ashton committed Jan 05, 2023

Signed-off-by: Harry 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

Harry Wentland authored Nov 29, 2022 and Joshua Ashton committed Jan 05, 2023

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 <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

Harry Wentland authored Nov 30, 2022 and Joshua Ashton committed Jan 05, 2023

Signed-off-by: Harry 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

Harry Wentland authored Nov 30, 2022 and Joshua Ashton committed Jan 05, 2023

This allows us to use strongly typed arguments.

Signed-off-by: Harry 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

Harry Wentland authored Nov 30, 2022 and Joshua Ashton committed Jan 05, 2023

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 <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

Harry Wentland authored Nov 25, 2022 and Joshua Ashton committed Jan 05, 2023

This is useful to understand the bpc defaults and
support of a driver.

Signed-off-by: Harry 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

Harry Wentland authored Jun 01, 2022 and Joshua Ashton committed Jan 05, 2023

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 <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 <pekka.paalanen@collabora.com>

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 <rdunlap@infradead.org>
Reported-by: kernel 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: Hamza Mahfooz <hamza.mahfooz@amd.com>

This reverts commit de05abe6.

The bug referenced below was bisected to this commit. There has been no
activity toward fixing it in 3 months, so let's revert for now.

Bug: drm/amd#2162


Signed-off-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

The function dmub_outbox_irq_info_funcs is defined in the
irq_service_dcn201.c file, but not called elsewhere, so remove this
unused function.

drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:139:43: warning: unused variable 'dmub_outbox_irq_info_funcs'.

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3520


Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

[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: Wenjing Liu <Wenjing.Liu@amd.com>
Reviewed-by: Hersen Wu <Hersenxs.Wu@amd.com>
Acked-by: Praful Swarnakar <Praful.Swarnakar@amd.com>
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>

[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 <Stanley.Yang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>

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 <Stanley.Yang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>

Aric Cyr authored Dec 11, 2022 and Aurabindo Pillai committed Dec 21, 2022

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

Aric Cyr authored Dec 03, 2022 and Aurabindo Pillai committed Dec 21, 2022

[why & how]
By moving bw_ctx field to the end of the dc_state the state can be
cleared more efficiently without resulting in large DML memcpy
operations, resulting in better mode enumeration performance on some
platforms.

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Aric Cyr <aric.cyr@amd.com>
Reviewed-by: Nevenko Stupar <Nevenko.Stupar@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

Leo Chen authored Dec 09, 2022 and Aurabindo Pillai committed Dec 21, 2022

[Why & How]
For certain features, there will be more implementations needed in the if-block.
Braces are added as part of the preparation.

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Leo Chen <sancchen@amd.com>
Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

[Why&How]

ignore_msa_timing_param is used by SubVP logic to determine if SubVP
+ DRR is possible. Linux does not support freesync on multi display
config, which results in incorrect assumption of VRR support if we
set this parameter when VRR is supported, but not enabled.

Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

Wenjing Liu authored Dec 07, 2022 and Aurabindo Pillai committed Dec 21, 2022

[why]
During DP2.1 LL CTS if test equipment requests to change between
DP2.1 and DP1.4 link rates, we need to swap between HPO and DIO
encoders by remapping encoder resource.

[how]
Add a function dc resource to update encoder resources and toggle
dpms state for all enabled stream associated witht the link under test.

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

Wenjing Liu authored Dec 06, 2022 and Aurabindo Pillai committed Dec 21, 2022

[why]
Pixel rate div depends on the type of encoder
that we are enabling stream with. If we swap between
HPO and DIO encoder at the time we call enable stream
for the new encoder, we must reprogram pixel rate div
based on the new encoder type.

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

Wenjing Liu authored Dec 05, 2022 and Aurabindo Pillai committed Dec 21, 2022

[why] dccg clock programming shouldn't be part of link hwss programming
sequence. The scope of link hwss is limited to encoder and phy
programming.

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Wenjing Liu <wenjing.liu@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

Dmytro Laktyushkin authored Dec 06, 2022 and Aurabindo Pillai committed Dec 21, 2022

This function is meant to be used on multi-edp systems and only makes sense
if only links with connected panels are considered.

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

Nicholas Kazlauskas authored Dec 06, 2022 and Aurabindo Pillai committed Dec 21, 2022

[Why]
On some monitors we see a brief flash of corruption during the
monitor disable sequence caused by FIFO being disabled in the middle
of an active DP stream.

[How]
Wait until DP vid stream is disabled before turning off the FIFO.

The FIFO reset on DP unblank should take care of clearing any FIFO
error, if any.

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Syed Hassan <Syed.Hassan@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

Swapnil Patel authored Dec 05, 2022 and Aurabindo Pillai committed Dec 21, 2022

[Why]
DCN301 resource function is missing function pointer to
handle cases with unknown plane state.
This causes assertion when global state is validated while
using swizzle parameter as “DC_UNKNOWN”

[How]
Add function pointer to handle and patch cases when plane
state is unknown.

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Swapnil Patel <Swapnil.Patel@amd.com>
Reviewed-by: Sung joon Kim <Sungjoon.Kim@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>

Lee, Alvin authored Dec 07, 2022 and Aurabindo Pillai committed Dec 21, 2022

[Description]
- Proper phantom pipe disable sequence was missing in
  commit_planes_for_stream
- If disabling phantom pipe, turn on phantom OTG first, and turn
  off the phantom OTG after the plane is disabled
- Also update sequence for enabling / disabling phantom streams
  (apply_ctx_to_hw). When enabling phantom pipes, enable before
  doing front end programming for phantom pipes. If disabling
  phantom pipes, disable after front end programming (i.e. after
  phantom plane disable)
- TODO: Still need to properly handle transition case when a phantom
  pipe is transitioned directly into a real pipe (need to fully disable
  the phantom pipe first)

Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>