--- /dev/null
+From 341421084d705475817f7f0d68e130370d10b20d Mon Sep 17 00:00:00 2001
+From: Leo Chen <sancchen@amd.com>
+Date: Thu, 20 Oct 2022 11:46:40 -0400
+Subject: drm/amd/display: Update DSC capabilitie for DCN314
+
+From: Leo Chen <sancchen@amd.com>
+
+commit 341421084d705475817f7f0d68e130370d10b20d upstream.
+
+dcn314 has 4 DSC - conflicted hardware document updated and confirmed.
+
+Tested-by: Mark Broadworth <mark.broadworth@amd.com>
+Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
+Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Signed-off-by: Leo Chen <sancchen@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org # 6.0.x
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c
++++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_resource.c
+@@ -847,7 +847,7 @@ static const struct resource_caps res_ca
+ .num_ddc = 5,
+ .num_vmid = 16,
+ .num_mpc_3dlut = 2,
+- .num_dsc = 3,
++ .num_dsc = 4,
+ };
+
+ static const struct dc_plane_cap plane_cap = {
--- /dev/null
+From c580d758ba1b79de9ea7a475d95a6278736ae462 Mon Sep 17 00:00:00 2001
+From: Dillon Varone <Dillon.Varone@amd.com>
+Date: Thu, 20 Oct 2022 11:46:47 -0400
+Subject: drm/amd/display: Update latencies on DCN321
+
+From: Dillon Varone <Dillon.Varone@amd.com>
+
+commit c580d758ba1b79de9ea7a475d95a6278736ae462 upstream.
+
+Update DF related latencies based on new measurements.
+
+Tested-by: Mark Broadworth <mark.broadworth@amd.com>
+Reviewed-by: Jun Lei <Jun.Lei@amd.com>
+Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Signed-off-by: Dillon Varone <Dillon.Varone@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org # 6.0.x
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/dml/dcn321/dcn321_fpu.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/dml/dcn321/dcn321_fpu.c
++++ b/drivers/gpu/drm/amd/display/dc/dml/dcn321/dcn321_fpu.c
+@@ -119,15 +119,15 @@ struct _vcs_dpi_soc_bounding_box_st dcn3
+ },
+ },
+ .num_states = 1,
+- .sr_exit_time_us = 12.36,
+- .sr_enter_plus_exit_time_us = 16.72,
++ .sr_exit_time_us = 19.95,
++ .sr_enter_plus_exit_time_us = 24.36,
+ .sr_exit_z8_time_us = 285.0,
+ .sr_enter_plus_exit_z8_time_us = 320,
+ .writeback_latency_us = 12.0,
+ .round_trip_ping_latency_dcfclk_cycles = 263,
+- .urgent_latency_pixel_data_only_us = 4.0,
+- .urgent_latency_pixel_mixed_with_vm_data_us = 4.0,
+- .urgent_latency_vm_data_only_us = 4.0,
++ .urgent_latency_pixel_data_only_us = 9.35,
++ .urgent_latency_pixel_mixed_with_vm_data_us = 9.35,
++ .urgent_latency_vm_data_only_us = 9.35,
+ .fclk_change_latency_us = 20,
+ .usr_retraining_latency_us = 2,
+ .smn_latency_us = 2,
--- /dev/null
+From a3e5ce56f3d260f2ec8e5242c33f57e60ae9eba7 Mon Sep 17 00:00:00 2001
+From: Graham Sider <Graham.Sider@amd.com>
+Date: Wed, 26 Oct 2022 15:08:24 -0400
+Subject: drm/amdgpu: disable GFXOFF during compute for GFX11
+
+From: Graham Sider <Graham.Sider@amd.com>
+
+commit a3e5ce56f3d260f2ec8e5242c33f57e60ae9eba7 upstream.
+
+Temporary workaround to fix issues observed in some compute applications
+when GFXOFF is enabled on GFX11.
+
+Signed-off-by: Graham Sider <Graham.Sider@amd.com>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org # 6.0.x
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+@@ -703,6 +703,13 @@ err:
+
+ void amdgpu_amdkfd_set_compute_idle(struct amdgpu_device *adev, bool idle)
+ {
++ /* Temporary workaround to fix issues observed in some
++ * compute applications when GFXOFF is enabled on GFX11.
++ */
++ if (IP_VERSION_MAJ(adev->ip_versions[GC_HWIP][0]) == 11) {
++ pr_debug("GFXOFF is %s\n", idle ? "enabled" : "disabled");
++ amdgpu_gfx_off_ctrl(adev, idle);
++ }
+ amdgpu_dpm_switch_power_profile(adev,
+ PP_SMC_POWER_PROFILE_COMPUTE,
+ !idle);
--- /dev/null
+From 3e206b6aa6df7eed4297577e0cf8403169b800a2 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Wed, 26 Oct 2022 13:11:27 +0300
+Subject: drm/i915/sdvo: Filter out invalid outputs more sensibly
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit 3e206b6aa6df7eed4297577e0cf8403169b800a2 upstream.
+
+We try to filter out the corresponding xxx1 output
+if the xxx0 output is not present. But the way that is
+being done is pretty awkward. Make it less so.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-2-ville.syrjala@linux.intel.com
+Reviewed-by: Jani Nikula <jani.nikula@intel.com>
+(cherry picked from commit cc1e66394daaa7e9f005e2487a84e34a39f9308b)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_sdvo.c | 27 ++++++++++++++++++++++-----
+ 1 file changed, 22 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
++++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
+@@ -2926,16 +2926,33 @@ err:
+ return false;
+ }
+
++static u16 intel_sdvo_filter_output_flags(u16 flags)
++{
++ flags &= SDVO_OUTPUT_MASK;
++
++ /* SDVO requires XXX1 function may not exist unless it has XXX0 function.*/
++ if (!(flags & SDVO_OUTPUT_TMDS0))
++ flags &= ~SDVO_OUTPUT_TMDS1;
++
++ if (!(flags & SDVO_OUTPUT_RGB0))
++ flags &= ~SDVO_OUTPUT_RGB1;
++
++ if (!(flags & SDVO_OUTPUT_LVDS0))
++ flags &= ~SDVO_OUTPUT_LVDS1;
++
++ return flags;
++}
++
+ static bool
+ intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
+ {
+- /* SDVO requires XXX1 function may not exist unless it has XXX0 function.*/
++ flags = intel_sdvo_filter_output_flags(flags);
+
+ if (flags & SDVO_OUTPUT_TMDS0)
+ if (!intel_sdvo_dvi_init(intel_sdvo, 0))
+ return false;
+
+- if ((flags & SDVO_TMDS_MASK) == SDVO_TMDS_MASK)
++ if (flags & SDVO_OUTPUT_TMDS1)
+ if (!intel_sdvo_dvi_init(intel_sdvo, 1))
+ return false;
+
+@@ -2956,7 +2973,7 @@ intel_sdvo_output_setup(struct intel_sdv
+ if (!intel_sdvo_analog_init(intel_sdvo, 0))
+ return false;
+
+- if ((flags & SDVO_RGB_MASK) == SDVO_RGB_MASK)
++ if (flags & SDVO_OUTPUT_RGB1)
+ if (!intel_sdvo_analog_init(intel_sdvo, 1))
+ return false;
+
+@@ -2964,11 +2981,11 @@ intel_sdvo_output_setup(struct intel_sdv
+ if (!intel_sdvo_lvds_init(intel_sdvo, 0))
+ return false;
+
+- if ((flags & SDVO_LVDS_MASK) == SDVO_LVDS_MASK)
++ if (flags & SDVO_OUTPUT_LVDS1)
+ if (!intel_sdvo_lvds_init(intel_sdvo, 1))
+ return false;
+
+- if ((flags & SDVO_OUTPUT_MASK) == 0) {
++ if (flags == 0) {
+ unsigned char bytes[2];
+
+ intel_sdvo->controlled_output = 0;
--- /dev/null
+From e79762512120f11c51317570519a1553c70805d8 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Wed, 26 Oct 2022 13:11:28 +0300
+Subject: drm/i915/sdvo: Setup DDC fully before output init
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit e79762512120f11c51317570519a1553c70805d8 upstream.
+
+Call intel_sdvo_select_ddc_bus() before initializing any
+of the outputs. And before that is functional (assuming no VBT)
+we have to set up the controlled_outputs thing. Otherwise DDC
+won't be functional during the output init but LVDS really
+needs it for the fixed mode setup.
+
+Note that the whole multi output support still looks very
+bogus, and more work will be needed to make it correct.
+But for now this should at least fix the LVDS EDID fixed mode
+setup.
+
+Cc: stable@vger.kernel.org
+Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
+Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-3-ville.syrjala@linux.intel.com
+Reviewed-by: Jani Nikula <jani.nikula@intel.com>
+(cherry picked from commit 64b7b557dc8a96d9cfed6aedbf81de2df80c025d)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_sdvo.c | 31 +++++++++++-------------------
+ 1 file changed, 12 insertions(+), 19 deletions(-)
+
+--- a/drivers/gpu/drm/i915/display/intel_sdvo.c
++++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
+@@ -2747,13 +2747,10 @@ intel_sdvo_dvi_init(struct intel_sdvo *i
+ if (!intel_sdvo_connector)
+ return false;
+
+- if (device == 0) {
+- intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
++ if (device == 0)
+ intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS0;
+- } else if (device == 1) {
+- intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
++ else if (device == 1)
+ intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS1;
+- }
+
+ intel_connector = &intel_sdvo_connector->base;
+ connector = &intel_connector->base;
+@@ -2808,7 +2805,6 @@ intel_sdvo_tv_init(struct intel_sdvo *in
+ encoder->encoder_type = DRM_MODE_ENCODER_TVDAC;
+ connector->connector_type = DRM_MODE_CONNECTOR_SVIDEO;
+
+- intel_sdvo->controlled_output |= type;
+ intel_sdvo_connector->output_flag = type;
+
+ if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
+@@ -2849,13 +2845,10 @@ intel_sdvo_analog_init(struct intel_sdvo
+ encoder->encoder_type = DRM_MODE_ENCODER_DAC;
+ connector->connector_type = DRM_MODE_CONNECTOR_VGA;
+
+- if (device == 0) {
+- intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
++ if (device == 0)
+ intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB0;
+- } else if (device == 1) {
+- intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
++ else if (device == 1)
+ intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB1;
+- }
+
+ if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
+ kfree(intel_sdvo_connector);
+@@ -2885,13 +2878,10 @@ intel_sdvo_lvds_init(struct intel_sdvo *
+ encoder->encoder_type = DRM_MODE_ENCODER_LVDS;
+ connector->connector_type = DRM_MODE_CONNECTOR_LVDS;
+
+- if (device == 0) {
+- intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
++ if (device == 0)
+ intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS0;
+- } else if (device == 1) {
+- intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
++ else if (device == 1)
+ intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS1;
+- }
+
+ if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
+ kfree(intel_sdvo_connector);
+@@ -2946,8 +2936,14 @@ static u16 intel_sdvo_filter_output_flag
+ static bool
+ intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
+ {
++ struct drm_i915_private *i915 = to_i915(intel_sdvo->base.base.dev);
++
+ flags = intel_sdvo_filter_output_flags(flags);
+
++ intel_sdvo->controlled_output = flags;
++
++ intel_sdvo_select_ddc_bus(i915, intel_sdvo);
++
+ if (flags & SDVO_OUTPUT_TMDS0)
+ if (!intel_sdvo_dvi_init(intel_sdvo, 0))
+ return false;
+@@ -2988,7 +2984,6 @@ intel_sdvo_output_setup(struct intel_sdv
+ if (flags == 0) {
+ unsigned char bytes[2];
+
+- intel_sdvo->controlled_output = 0;
+ memcpy(bytes, &intel_sdvo->caps.output_flags, 2);
+ DRM_DEBUG_KMS("%s: Unknown SDVO output type (0x%02x%02x)\n",
+ SDVO_NAME(intel_sdvo),
+@@ -3400,8 +3395,6 @@ bool intel_sdvo_init(struct drm_i915_pri
+ */
+ intel_sdvo->base.cloneable = 0;
+
+- intel_sdvo_select_ddc_bus(dev_priv, intel_sdvo);
+-
+ /* Set the input timing to the screen. Assume always input 0. */
+ if (!intel_sdvo_set_target_input(intel_sdvo))
+ goto err_output;
--- /dev/null
+From 0be67e0556e469c57100ffe3c90df90abc796f3b Mon Sep 17 00:00:00 2001
+From: Brian Norris <briannorris@chromium.org>
+Date: Wed, 19 Oct 2022 17:03:48 -0700
+Subject: drm/rockchip: dsi: Clean up 'usage_mode' when failing to attach
+
+From: Brian Norris <briannorris@chromium.org>
+
+commit 0be67e0556e469c57100ffe3c90df90abc796f3b upstream.
+
+If we fail to attach the first time (especially: EPROBE_DEFER), we fail
+to clean up 'usage_mode', and thus will fail to attach on any subsequent
+attempts, with "dsi controller already in use".
+
+Re-set to DW_DSI_USAGE_IDLE on attach failure.
+
+This is especially common to hit when enabling asynchronous probe on a
+duel-DSI system (such as RK3399 Gru/Scarlet), such that we're more
+likely to fail dw_mipi_dsi_rockchip_find_second() the first time.
+
+Fixes: 71f68fe7f121 ("drm/rockchip: dsi: add ability to work as a phy instead of full dsi")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221019170255.1.Ia68dfb27b835d31d22bfe23812baf366ee1c6eac@changeid
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
++++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+@@ -1031,23 +1031,31 @@ static int dw_mipi_dsi_rockchip_host_att
+ if (ret) {
+ DRM_DEV_ERROR(dsi->dev, "Failed to register component: %d\n",
+ ret);
+- return ret;
++ goto out;
+ }
+
+ second = dw_mipi_dsi_rockchip_find_second(dsi);
+- if (IS_ERR(second))
+- return PTR_ERR(second);
++ if (IS_ERR(second)) {
++ ret = PTR_ERR(second);
++ goto out;
++ }
+ if (second) {
+ ret = component_add(second, &dw_mipi_dsi_rockchip_ops);
+ if (ret) {
+ DRM_DEV_ERROR(second,
+ "Failed to register component: %d\n",
+ ret);
+- return ret;
++ goto out;
+ }
+ }
+
+ return 0;
++
++out:
++ mutex_lock(&dsi->usage_mutex);
++ dsi->usage_mode = DW_DSI_USAGE_IDLE;
++ mutex_unlock(&dsi->usage_mutex);
++ return ret;
+ }
+
+ static int dw_mipi_dsi_rockchip_host_detach(void *priv_data,
--- /dev/null
+From 81e592f86f7afdb76d655e7fbd7803d7b8f985d8 Mon Sep 17 00:00:00 2001
+From: Brian Norris <briannorris@chromium.org>
+Date: Wed, 19 Oct 2022 17:03:49 -0700
+Subject: drm/rockchip: dsi: Force synchronous probe
+
+From: Brian Norris <briannorris@chromium.org>
+
+commit 81e592f86f7afdb76d655e7fbd7803d7b8f985d8 upstream.
+
+We can't safely probe a dual-DSI display asynchronously
+(driver_async_probe='*' or driver_async_probe='dw-mipi-dsi-rockchip'
+cmdline), because dw_mipi_dsi_rockchip_find_second() pokes one DSI
+device's drvdata from the other device without any locking.
+
+Request synchronous probe, at least until this driver learns some
+appropriate locking for dual-DSI initialization.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20221019170255.2.I6b985b0ca372b7e35c6d9ea970b24bcb262d4fc1@changeid
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
++++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+@@ -1642,5 +1642,11 @@ struct platform_driver dw_mipi_dsi_rockc
+ .of_match_table = dw_mipi_dsi_rockchip_dt_ids,
+ .pm = &dw_mipi_dsi_rockchip_pm_ops,
+ .name = "dw-mipi-dsi-rockchip",
++ /*
++ * For dual-DSI display, one DSI pokes at the other DSI's
++ * drvdata in dw_mipi_dsi_rockchip_find_second(). This is not
++ * safe for asynchronous probe.
++ */
++ .probe_type = PROBE_FORCE_SYNCHRONOUS,
+ },
+ };
kvm-x86-emulator-update-the-emulation-mode-after-cr0-write.patch
ext4-f2fs-fix-readahead-of-verity-data.patch
cifs-fix-regression-in-very-old-smb1-mounts.patch
+drm-rockchip-dsi-clean-up-usage_mode-when-failing-to-attach.patch
+drm-rockchip-dsi-force-synchronous-probe.patch
+drm-amdgpu-disable-gfxoff-during-compute-for-gfx11.patch
+drm-amd-display-update-latencies-on-dcn321.patch
+drm-amd-display-update-dsc-capabilitie-for-dcn314.patch
+drm-i915-sdvo-filter-out-invalid-outputs-more-sensibly.patch
+drm-i915-sdvo-setup-ddc-fully-before-output-init.patch