--- /dev/null
+From da5fb9e1ad3fbf632dce735f1bdad257ca528499 Mon Sep 17 00:00:00 2001
+From: Robin Murphy <robin.murphy@arm.com>
+Date: Thu, 3 Feb 2022 19:31:24 +0000
+Subject: ACPI/IORT: Check node revision for PMCG resources
+
+From: Robin Murphy <robin.murphy@arm.com>
+
+commit da5fb9e1ad3fbf632dce735f1bdad257ca528499 upstream.
+
+The original version of the IORT PMCG definition had an oversight
+wherein there was no way to describe the second register page for an
+implementation using the recommended RELOC_CTRS feature. Although the
+spec was fixed, and the final patches merged to ACPICA and Linux written
+against the new version, it seems that some old firmware based on the
+original revision has survived and turned up in the wild.
+
+Add a check for the original PMCG definition, and avoid filling in the
+second memory resource with nonsense if so. Otherwise it is likely that
+something horrible will happen when the PMCG driver attempts to probe.
+
+Reported-by: Michael Petlan <mpetlan@redhat.com>
+Fixes: 24e516049360 ("ACPI/IORT: Add support for PMCG")
+Cc: <stable@vger.kernel.org> # 5.2.x
+Signed-off-by: Robin Murphy <robin.murphy@arm.com>
+Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Link: https://lore.kernel.org/r/75628ae41c257fb73588f7bf1c4459160e04be2b.1643916258.git.robin.murphy@arm.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/arm64/iort.c | 14 +++++++++++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+--- a/drivers/acpi/arm64/iort.c
++++ b/drivers/acpi/arm64/iort.c
+@@ -1361,9 +1361,17 @@ static void __init arm_smmu_v3_pmcg_init
+ res[0].start = pmcg->page0_base_address;
+ res[0].end = pmcg->page0_base_address + SZ_4K - 1;
+ res[0].flags = IORESOURCE_MEM;
+- res[1].start = pmcg->page1_base_address;
+- res[1].end = pmcg->page1_base_address + SZ_4K - 1;
+- res[1].flags = IORESOURCE_MEM;
++ /*
++ * The initial version in DEN0049C lacked a way to describe register
++ * page 1, which makes it broken for most PMCG implementations; in
++ * that case, just let the driver fail gracefully if it expects to
++ * find a second memory resource.
++ */
++ if (node->revision > 0) {
++ res[1].start = pmcg->page1_base_address;
++ res[1].end = pmcg->page1_base_address + SZ_4K - 1;
++ res[1].flags = IORESOURCE_MEM;
++ }
+
+ if (pmcg->overflow_gsiv)
+ acpi_iort_register_irq(pmcg->overflow_gsiv, "overflow",
--- /dev/null
+From d9058d6a0e92d8e4a00855f8fe204792f42794db Mon Sep 17 00:00:00 2001
+From: Linus Walleij <linus.walleij@linaro.org>
+Date: Sun, 6 Feb 2022 00:53:12 +0100
+Subject: ARM: dts: Fix boot regression on Skomer
+
+From: Linus Walleij <linus.walleij@linaro.org>
+
+commit d9058d6a0e92d8e4a00855f8fe204792f42794db upstream.
+
+The signal routing on the Skomer board was incorrect making
+it impossible to mount root from the SD card. Fix this up.
+
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Cc: stable@vger.kernel.org
+Cc: Stefan Hansson <newbyte@disroot.org>
+Link: https://lore.kernel.org/r/20220205235312.446730-1-linus.walleij@linaro.org'
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/ste-ux500-samsung-skomer.dts | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/arch/arm/boot/dts/ste-ux500-samsung-skomer.dts
++++ b/arch/arm/boot/dts/ste-ux500-samsung-skomer.dts
+@@ -185,10 +185,6 @@
+ cap-sd-highspeed;
+ cap-mmc-highspeed;
+ /* All direction control is used */
+- st,sig-dir-cmd;
+- st,sig-dir-dat0;
+- st,sig-dir-dat2;
+- st,sig-dir-dat31;
+ st,sig-pin-fbclk;
+ full-pwr-cycle;
+ vmmc-supply = <&ab8500_ldo_aux3_reg>;
--- /dev/null
+From 42c9b28e6862d16db82a56f5667cf4d1f6658cf6 Mon Sep 17 00:00:00 2001
+From: Fabio Estevam <festevam@gmail.com>
+Date: Mon, 27 Dec 2021 13:14:02 -0300
+Subject: ARM: dts: imx23-evk: Remove MX23_PAD_SSP1_DETECT from hog group
+
+From: Fabio Estevam <festevam@gmail.com>
+
+commit 42c9b28e6862d16db82a56f5667cf4d1f6658cf6 upstream.
+
+Currently, SD card fails to mount due to the following pinctrl error:
+
+[ 11.170000] imx23-pinctrl 80018000.pinctrl: pin SSP1_DETECT already requested by 80018000.pinctrl; cannot claim for 80010000.spi
+[ 11.180000] imx23-pinctrl 80018000.pinctrl: pin-65 (80010000.spi) status -22
+[ 11.190000] imx23-pinctrl 80018000.pinctrl: could not request pin 65 (SSP1_DETECT) from group mmc0-pins-fixup.0 on device 80018000.pinctrl
+[ 11.200000] mxs-mmc 80010000.spi: Error applying setting, reverse things back
+
+Fix it by removing the MX23_PAD_SSP1_DETECT pin from the hog group as it
+is already been used by the mmc0-pins-fixup pinctrl group.
+
+With this change the rootfs can be mounted and the imx23-evk board can
+boot successfully.
+
+Cc: <stable@vger.kernel.org>
+Fixes: bc3875f1a61e ("ARM: dts: mxs: modify mx23/mx28 dts files to use pinctrl headers")
+Signed-off-by: Fabio Estevam <festevam@gmail.com>
+Signed-off-by: Shawn Guo <shawnguo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/imx23-evk.dts | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/arm/boot/dts/imx23-evk.dts
++++ b/arch/arm/boot/dts/imx23-evk.dts
+@@ -79,7 +79,6 @@
+ MX23_PAD_LCD_RESET__GPIO_1_18
+ MX23_PAD_PWM3__GPIO_1_29
+ MX23_PAD_PWM4__GPIO_1_30
+- MX23_PAD_SSP1_DETECT__SSP1_DETECT
+ >;
+ fsl,drive-strength = <MXS_DRIVE_4mA>;
+ fsl,voltage = <MXS_VOLTAGE_HIGH>;
--- /dev/null
+From 3037b174b1876aae6b2d1a27a878c681c78ccadc Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+Date: Mon, 7 Feb 2022 09:44:04 +0100
+Subject: ARM: socfpga: fix missing RESET_CONTROLLER
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+
+commit 3037b174b1876aae6b2d1a27a878c681c78ccadc upstream.
+
+The SocFPGA machine since commit b3ca9888f35f ("reset: socfpga: add an
+early reset driver for SoCFPGA") uses reset controller, so it should
+select RESET_CONTROLLER explicitly. Selecting ARCH_HAS_RESET_CONTROLLER
+is not enough because it affects only default choice still allowing a
+non-buildable configuration:
+
+ /usr/bin/arm-linux-gnueabi-ld: arch/arm/mach-socfpga/socfpga.o: in function `socfpga_init_irq':
+ arch/arm/mach-socfpga/socfpga.c:56: undefined reference to `socfpga_reset_init'
+
+Reported-by: kernel test robot <lkp@intel.com>
+Cc: <stable@vger.kernel.org>
+Fixes: b3ca9888f35f ("reset: socfpga: add an early reset driver for SoCFPGA")
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
+Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/mach-socfpga/Kconfig | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm/mach-socfpga/Kconfig
++++ b/arch/arm/mach-socfpga/Kconfig
+@@ -2,6 +2,7 @@
+ menuconfig ARCH_INTEL_SOCFPGA
+ bool "Altera SOCFPGA family"
+ depends on ARCH_MULTI_V7
++ select ARCH_HAS_RESET_CONTROLLER
+ select ARCH_SUPPORTS_BIG_ENDIAN
+ select ARM_AMBA
+ select ARM_GIC
+@@ -18,6 +19,7 @@ menuconfig ARCH_INTEL_SOCFPGA
+ select PL310_ERRATA_727915
+ select PL310_ERRATA_753970 if PL310
+ select PL310_ERRATA_769419
++ select RESET_CONTROLLER
+
+ if ARCH_INTEL_SOCFPGA
+ config SOCFPGA_SUSPEND
--- /dev/null
+From 6e7545ddb13416fd200e0b91c0acfd0404e2e27b Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Thu, 3 Feb 2022 10:04:58 -0500
+Subject: drm/amdgpu/display: change pipe policy for DCN 2.0
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 6e7545ddb13416fd200e0b91c0acfd0404e2e27b upstream.
+
+Fixes hangs on driver load with multiple displays on
+DCN 2.0 parts.
+
+Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215511
+Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1877
+Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1886
+Fixes: ee2698cf79cc ("drm/amd/display: Changed pipe split policy to allow for multi-display pipe split")
+Reviewed-by: Harry Wentland <harry.wentland@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
++++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+@@ -1069,7 +1069,7 @@ static const struct dc_debug_options deb
+ .timing_trace = false,
+ .clock_trace = true,
+ .disable_pplib_clock_request = true,
+- .pipe_split_policy = MPC_SPLIT_DYNAMIC,
++ .pipe_split_policy = MPC_SPLIT_AVOID_MULT_DISP,
+ .force_single_disp_pipe_split = false,
+ .disable_dcc = DCC_ENABLE,
+ .vsr_support = true,
--- /dev/null
+From 8fd5a26e43859547790a7995494c952b708ab3b5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Fri, 4 Feb 2022 16:18:16 +0200
+Subject: drm/i915: Allow !join_mbus cases for adlp+ dbuf configuration
+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 8fd5a26e43859547790a7995494c952b708ab3b5 upstream.
+
+Reintroduce the !join_mbus single pipe cases for adlp+.
+
+Due to the mbus relative dbuf offsets in PLANE_BUF_CFG we
+need to know the actual slices used by the pipe when doing
+readout, even when mbus joining isn't enabled. Accurate
+readout will be needed to properly sanitize invalid BIOS
+dbuf configurations.
+
+This will also make it much easier to play around with the
+!join_mbus configs for testin/workaround purposes.
+
+Cc: <stable@vger.kernel.org> # v5.14+
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-1-ville.syrjala@linux.intel.com
+Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
+(cherry picked from commit eef173954432fe0612acb63421a95deb41155cdc)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/intel_pm.c | 66 +++++++++++++++++++++++++++-------------
+ 1 file changed, 46 insertions(+), 20 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -4707,6 +4707,10 @@ static const struct dbuf_slice_conf_entr
+ };
+
+ static const struct dbuf_slice_conf_entry adlp_allowed_dbufs[] = {
++ /*
++ * Keep the join_mbus cases first so check_mbus_joined()
++ * will prefer them over the !join_mbus cases.
++ */
+ {
+ .active_pipes = BIT(PIPE_A),
+ .dbuf_mask = {
+@@ -4722,6 +4726,20 @@ static const struct dbuf_slice_conf_entr
+ .join_mbus = true,
+ },
+ {
++ .active_pipes = BIT(PIPE_A),
++ .dbuf_mask = {
++ [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
++ },
++ .join_mbus = false,
++ },
++ {
++ .active_pipes = BIT(PIPE_B),
++ .dbuf_mask = {
++ [PIPE_B] = BIT(DBUF_S3) | BIT(DBUF_S4),
++ },
++ .join_mbus = false,
++ },
++ {
+ .active_pipes = BIT(PIPE_A) | BIT(PIPE_B),
+ .dbuf_mask = {
+ [PIPE_A] = BIT(DBUF_S1) | BIT(DBUF_S2),
+@@ -4837,13 +4855,14 @@ static bool adlp_check_mbus_joined(u8 ac
+ return check_mbus_joined(active_pipes, adlp_allowed_dbufs);
+ }
+
+-static u8 compute_dbuf_slices(enum pipe pipe, u8 active_pipes,
++static u8 compute_dbuf_slices(enum pipe pipe, u8 active_pipes, bool join_mbus,
+ const struct dbuf_slice_conf_entry *dbuf_slices)
+ {
+ int i;
+
+ for (i = 0; i < dbuf_slices[i].active_pipes; i++) {
+- if (dbuf_slices[i].active_pipes == active_pipes)
++ if (dbuf_slices[i].active_pipes == active_pipes &&
++ dbuf_slices[i].join_mbus == join_mbus)
+ return dbuf_slices[i].dbuf_mask[pipe];
+ }
+ return 0;
+@@ -4854,7 +4873,7 @@ static u8 compute_dbuf_slices(enum pipe
+ * returns correspondent DBuf slice mask as stated in BSpec for particular
+ * platform.
+ */
+-static u8 icl_compute_dbuf_slices(enum pipe pipe, u8 active_pipes)
++static u8 icl_compute_dbuf_slices(enum pipe pipe, u8 active_pipes, bool join_mbus)
+ {
+ /*
+ * FIXME: For ICL this is still a bit unclear as prev BSpec revision
+@@ -4868,37 +4887,41 @@ static u8 icl_compute_dbuf_slices(enum p
+ * still here - we will need it once those additional constraints
+ * pop up.
+ */
+- return compute_dbuf_slices(pipe, active_pipes, icl_allowed_dbufs);
++ return compute_dbuf_slices(pipe, active_pipes, join_mbus,
++ icl_allowed_dbufs);
+ }
+
+-static u8 tgl_compute_dbuf_slices(enum pipe pipe, u8 active_pipes)
++static u8 tgl_compute_dbuf_slices(enum pipe pipe, u8 active_pipes, bool join_mbus)
+ {
+- return compute_dbuf_slices(pipe, active_pipes, tgl_allowed_dbufs);
++ return compute_dbuf_slices(pipe, active_pipes, join_mbus,
++ tgl_allowed_dbufs);
+ }
+
+-static u32 adlp_compute_dbuf_slices(enum pipe pipe, u32 active_pipes)
++static u8 adlp_compute_dbuf_slices(enum pipe pipe, u8 active_pipes, bool join_mbus)
+ {
+- return compute_dbuf_slices(pipe, active_pipes, adlp_allowed_dbufs);
++ return compute_dbuf_slices(pipe, active_pipes, join_mbus,
++ adlp_allowed_dbufs);
+ }
+
+-static u32 dg2_compute_dbuf_slices(enum pipe pipe, u32 active_pipes)
++static u8 dg2_compute_dbuf_slices(enum pipe pipe, u8 active_pipes, bool join_mbus)
+ {
+- return compute_dbuf_slices(pipe, active_pipes, dg2_allowed_dbufs);
++ return compute_dbuf_slices(pipe, active_pipes, join_mbus,
++ dg2_allowed_dbufs);
+ }
+
+-static u8 skl_compute_dbuf_slices(struct intel_crtc *crtc, u8 active_pipes)
++static u8 skl_compute_dbuf_slices(struct intel_crtc *crtc, u8 active_pipes, bool join_mbus)
+ {
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ if (IS_DG2(dev_priv))
+- return dg2_compute_dbuf_slices(pipe, active_pipes);
++ return dg2_compute_dbuf_slices(pipe, active_pipes, join_mbus);
+ else if (IS_ALDERLAKE_P(dev_priv))
+- return adlp_compute_dbuf_slices(pipe, active_pipes);
++ return adlp_compute_dbuf_slices(pipe, active_pipes, join_mbus);
+ else if (DISPLAY_VER(dev_priv) == 12)
+- return tgl_compute_dbuf_slices(pipe, active_pipes);
++ return tgl_compute_dbuf_slices(pipe, active_pipes, join_mbus);
+ else if (DISPLAY_VER(dev_priv) == 11)
+- return icl_compute_dbuf_slices(pipe, active_pipes);
++ return icl_compute_dbuf_slices(pipe, active_pipes, join_mbus);
+ /*
+ * For anything else just return one slice yet.
+ * Should be extended for other platforms.
+@@ -6109,11 +6132,16 @@ skl_compute_ddb(struct intel_atomic_stat
+ return ret;
+ }
+
++ if (IS_ALDERLAKE_P(dev_priv))
++ new_dbuf_state->joined_mbus =
++ adlp_check_mbus_joined(new_dbuf_state->active_pipes);
++
+ for_each_intel_crtc(&dev_priv->drm, crtc) {
+ enum pipe pipe = crtc->pipe;
+
+ new_dbuf_state->slices[pipe] =
+- skl_compute_dbuf_slices(crtc, new_dbuf_state->active_pipes);
++ skl_compute_dbuf_slices(crtc, new_dbuf_state->active_pipes,
++ new_dbuf_state->joined_mbus);
+
+ if (old_dbuf_state->slices[pipe] == new_dbuf_state->slices[pipe])
+ continue;
+@@ -6125,9 +6153,6 @@ skl_compute_ddb(struct intel_atomic_stat
+
+ new_dbuf_state->enabled_slices = intel_dbuf_enabled_slices(new_dbuf_state);
+
+- if (IS_ALDERLAKE_P(dev_priv))
+- new_dbuf_state->joined_mbus = adlp_check_mbus_joined(new_dbuf_state->active_pipes);
+-
+ if (old_dbuf_state->enabled_slices != new_dbuf_state->enabled_slices ||
+ old_dbuf_state->joined_mbus != new_dbuf_state->joined_mbus) {
+ ret = intel_atomic_serialize_global_state(&new_dbuf_state->base);
+@@ -6628,7 +6653,8 @@ void skl_wm_get_hw_state(struct drm_i915
+ }
+
+ dbuf_state->slices[pipe] =
+- skl_compute_dbuf_slices(crtc, dbuf_state->active_pipes);
++ skl_compute_dbuf_slices(crtc, dbuf_state->active_pipes,
++ dbuf_state->joined_mbus);
+
+ dbuf_state->weight[pipe] = intel_crtc_ddb_weight(crtc_state);
+
--- /dev/null
+From ee59792c97176f12c1da31f29fc4c2aab187f06e Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Fri, 28 Jan 2022 12:37:50 +0200
+Subject: drm/i915: Disable DRRS on IVB/HSW port != A
+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 ee59792c97176f12c1da31f29fc4c2aab187f06e upstream.
+
+Currently we allow DRRS on IVB PCH ports, but we're missing a
+few programming steps meaning it is guaranteed to not work.
+And on HSW DRRS is not supported on anything but port A ever
+as only transcoder EDP has the M2/N2 registers (though I'm
+not sure if HSW ever has eDP on any other port).
+
+Starting from BDW all transcoders have the dynamically
+reprogrammable M/N registers so DRRS could work on any
+port.
+
+Stop initializing DRRS on ports where it cannot possibly work.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-11-ville.syrjala@linux.intel.com
+Reviewed-by: Jani Nikula <jani.nikula@intel.com>
+(cherry picked from commit f0d4ce59f4d48622044933054a0e0cefa91ba15e)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_drrs.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/gpu/drm/i915/display/intel_drrs.c
++++ b/drivers/gpu/drm/i915/display/intel_drrs.c
+@@ -405,6 +405,7 @@ intel_drrs_init(struct intel_connector *
+ struct drm_display_mode *fixed_mode)
+ {
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
++ struct intel_encoder *encoder = connector->encoder;
+ struct drm_display_mode *downclock_mode = NULL;
+
+ INIT_DELAYED_WORK(&dev_priv->drrs.work, intel_drrs_downclock_work);
+@@ -416,6 +417,13 @@ intel_drrs_init(struct intel_connector *
+ return NULL;
+ }
+
++ if ((DISPLAY_VER(dev_priv) < 8 && !HAS_GMCH(dev_priv)) &&
++ encoder->port != PORT_A) {
++ drm_dbg_kms(&dev_priv->drm,
++ "DRRS only supported on eDP port A\n");
++ return NULL;
++ }
++
+ if (dev_priv->vbt.drrs_type != SEAMLESS_DRRS_SUPPORT) {
+ drm_dbg_kms(&dev_priv->drm, "VBT doesn't support DRRS\n");
+ return NULL;
--- /dev/null
+From 85bb289215cf37e05e9581b39b114db1293f9ecd Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Fri, 4 Feb 2022 16:18:17 +0200
+Subject: drm/i915: Populate pipe dbuf slices more accurately during readout
+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 85bb289215cf37e05e9581b39b114db1293f9ecd upstream.
+
+During readout we cannot assume the planes are actually using the
+slices they are supposed to use. The BIOS may have misprogrammed
+things and put the planes onto the wrong dbuf slices. So let's
+do the readout more carefully to make sure we really know which
+dbuf slices are actually in use by the pipe at the time.
+
+Cc: <stable@vger.kernel.org> # v5.14+
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-2-ville.syrjala@linux.intel.com
+Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
+(cherry picked from commit b3dcc6dc0f32612d04839c2fb32e94d0ebf92c98)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/intel_pm.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -6633,6 +6633,7 @@ void skl_wm_get_hw_state(struct drm_i915
+ enum pipe pipe = crtc->pipe;
+ unsigned int mbus_offset;
+ enum plane_id plane_id;
++ u8 slices;
+
+ skl_pipe_wm_get_hw_state(crtc, &crtc_state->wm.skl.optimal);
+ crtc_state->wm.skl.raw = crtc_state->wm.skl.optimal;
+@@ -6652,20 +6653,22 @@ void skl_wm_get_hw_state(struct drm_i915
+ skl_ddb_entry_union(&dbuf_state->ddb[pipe], ddb_uv);
+ }
+
+- dbuf_state->slices[pipe] =
+- skl_compute_dbuf_slices(crtc, dbuf_state->active_pipes,
+- dbuf_state->joined_mbus);
+-
+ dbuf_state->weight[pipe] = intel_crtc_ddb_weight(crtc_state);
+
+ /*
+ * Used for checking overlaps, so we need absolute
+ * offsets instead of MBUS relative offsets.
+ */
+- mbus_offset = mbus_ddb_offset(dev_priv, dbuf_state->slices[pipe]);
++ slices = skl_compute_dbuf_slices(crtc, dbuf_state->active_pipes,
++ dbuf_state->joined_mbus);
++ mbus_offset = mbus_ddb_offset(dev_priv, slices);
+ crtc_state->wm.skl.ddb.start = mbus_offset + dbuf_state->ddb[pipe].start;
+ crtc_state->wm.skl.ddb.end = mbus_offset + dbuf_state->ddb[pipe].end;
+
++ /* The slices actually used by the planes on the pipe */
++ dbuf_state->slices[pipe] =
++ skl_ddb_dbuf_slice_mask(dev_priv, &crtc_state->wm.skl.ddb);
++
+ drm_dbg_kms(&dev_priv->drm,
+ "[CRTC:%d:%s] dbuf slices 0x%x, ddb (%d - %d), active pipes 0x%x, mbus joined: %s\n",
+ crtc->base.base.id, crtc->base.name,
--- /dev/null
+From 4e6f55120c7eccf6f9323bb681632e23cbcb3f3c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Fri, 4 Feb 2022 16:18:18 +0200
+Subject: drm/i915: Workaround broken BIOS DBUF configuration on TGL/RKL
+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 4e6f55120c7eccf6f9323bb681632e23cbcb3f3c upstream.
+
+On TGL/RKL the BIOS likes to use some kind of bogus DBUF layout
+that doesn't match what the spec recommends. With a single active
+pipe that is not going to be a problem, but with multiple pipes
+active skl_commit_modeset_enables() goes into an infinite loop
+since it can't figure out any order in which it can commit the
+pipes without causing DBUF overlaps between the planes.
+
+We'd need some kind of extra DBUF defrag stage in between to
+make the transition possible. But that is clearly way too complex
+a solution, so in the name of simplicity let's just sanitize the
+DBUF state by simply turning off all planes when we detect a
+pipe encroaching on its neighbours' DBUF slices. We only have
+to disable the primary planes as all other planes should have
+already been disabled (if they somehow were enabled) by
+earlier sanitization steps.
+
+And for good measure let's also sanitize in case the DBUF
+allocations of the pipes already seem to overlap each other.
+
+Cc: <stable@vger.kernel.org> # v5.14+
+Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4762
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-3-ville.syrjala@linux.intel.com
+Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
+(cherry picked from commit 15512021eb3975a8c2366e3883337e252bb0eee5)
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/display/intel_display.c | 1
+ drivers/gpu/drm/i915/intel_pm.c | 68 +++++++++++++++++++++++++++
+ drivers/gpu/drm/i915/intel_pm.h | 1
+ 3 files changed, 70 insertions(+)
+
+--- a/drivers/gpu/drm/i915/display/intel_display.c
++++ b/drivers/gpu/drm/i915/display/intel_display.c
+@@ -11901,6 +11901,7 @@ intel_modeset_setup_hw_state(struct drm_
+ vlv_wm_sanitize(dev_priv);
+ } else if (DISPLAY_VER(dev_priv) >= 9) {
+ skl_wm_get_hw_state(dev_priv);
++ skl_wm_sanitize(dev_priv);
+ } else if (HAS_PCH_SPLIT(dev_priv)) {
+ ilk_wm_get_hw_state(dev_priv);
+ }
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -6680,6 +6680,74 @@ void skl_wm_get_hw_state(struct drm_i915
+ dbuf_state->enabled_slices = dev_priv->dbuf.enabled_slices;
+ }
+
++static bool skl_dbuf_is_misconfigured(struct drm_i915_private *i915)
++{
++ const struct intel_dbuf_state *dbuf_state =
++ to_intel_dbuf_state(i915->dbuf.obj.state);
++ struct skl_ddb_entry entries[I915_MAX_PIPES] = {};
++ struct intel_crtc *crtc;
++
++ for_each_intel_crtc(&i915->drm, crtc) {
++ const struct intel_crtc_state *crtc_state =
++ to_intel_crtc_state(crtc->base.state);
++
++ entries[crtc->pipe] = crtc_state->wm.skl.ddb;
++ }
++
++ for_each_intel_crtc(&i915->drm, crtc) {
++ const struct intel_crtc_state *crtc_state =
++ to_intel_crtc_state(crtc->base.state);
++ u8 slices;
++
++ slices = skl_compute_dbuf_slices(crtc, dbuf_state->active_pipes,
++ dbuf_state->joined_mbus);
++ if (dbuf_state->slices[crtc->pipe] & ~slices)
++ return true;
++
++ if (skl_ddb_allocation_overlaps(&crtc_state->wm.skl.ddb, entries,
++ I915_MAX_PIPES, crtc->pipe))
++ return true;
++ }
++
++ return false;
++}
++
++void skl_wm_sanitize(struct drm_i915_private *i915)
++{
++ struct intel_crtc *crtc;
++
++ /*
++ * On TGL/RKL (at least) the BIOS likes to assign the planes
++ * to the wrong DBUF slices. This will cause an infinite loop
++ * in skl_commit_modeset_enables() as it can't find a way to
++ * transition between the old bogus DBUF layout to the new
++ * proper DBUF layout without DBUF allocation overlaps between
++ * the planes (which cannot be allowed or else the hardware
++ * may hang). If we detect a bogus DBUF layout just turn off
++ * all the planes so that skl_commit_modeset_enables() can
++ * simply ignore them.
++ */
++ if (!skl_dbuf_is_misconfigured(i915))
++ return;
++
++ drm_dbg_kms(&i915->drm, "BIOS has misprogrammed the DBUF, disabling all planes\n");
++
++ for_each_intel_crtc(&i915->drm, crtc) {
++ struct intel_plane *plane = to_intel_plane(crtc->base.primary);
++ const struct intel_plane_state *plane_state =
++ to_intel_plane_state(plane->base.state);
++ struct intel_crtc_state *crtc_state =
++ to_intel_crtc_state(crtc->base.state);
++
++ if (plane_state->uapi.visible)
++ intel_plane_disable_noatomic(crtc, plane);
++
++ drm_WARN_ON(&i915->drm, crtc_state->active_planes != 0);
++
++ memset(&crtc_state->wm.skl.ddb, 0, sizeof(crtc_state->wm.skl.ddb));
++ }
++}
++
+ static void ilk_pipe_wm_get_hw_state(struct intel_crtc *crtc)
+ {
+ struct drm_device *dev = crtc->base.dev;
+--- a/drivers/gpu/drm/i915/intel_pm.h
++++ b/drivers/gpu/drm/i915/intel_pm.h
+@@ -47,6 +47,7 @@ void skl_pipe_wm_get_hw_state(struct int
+ struct skl_pipe_wm *out);
+ void g4x_wm_sanitize(struct drm_i915_private *dev_priv);
+ void vlv_wm_sanitize(struct drm_i915_private *dev_priv);
++void skl_wm_sanitize(struct drm_i915_private *dev_priv);
+ bool intel_can_enable_sagv(struct drm_i915_private *dev_priv,
+ const struct intel_bw_state *bw_state);
+ void intel_sagv_pre_plane_update(struct intel_atomic_state *state);
--- /dev/null
+From 9da1e9ab82c92d0e89fe44cad2cd7c2d18d64070 Mon Sep 17 00:00:00 2001
+From: Brian Norris <briannorris@chromium.org>
+Date: Wed, 19 Jan 2022 16:11:22 -0800
+Subject: drm/rockchip: vop: Correct RK3399 VOP register fields
+
+From: Brian Norris <briannorris@chromium.org>
+
+commit 9da1e9ab82c92d0e89fe44cad2cd7c2d18d64070 upstream.
+
+Commit 7707f7227f09 ("drm/rockchip: Add support for afbc") switched up
+the rk3399_vop_big[] register windows, but it did so incorrectly.
+
+The biggest problem is in rk3288_win23_data[] vs.
+rk3368_win23_data[] .format field:
+
+ RK3288's format: VOP_REG(RK3288_WIN2_CTRL0, 0x7, 1)
+ RK3368's format: VOP_REG(RK3368_WIN2_CTRL0, 0x3, 5)
+
+Bits 5:6 (i.e., shift 5, mask 0x3) are correct for RK3399, according to
+the TRM.
+
+There are a few other small differences between the 3288 and 3368
+definitions that were swapped in commit 7707f7227f09. I reviewed them to
+the best of my ability according to the RK3399 TRM and fixed them up.
+
+This fixes IOMMU issues (and display errors) when testing with BG24
+color formats.
+
+Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc")
+Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Brian Norris <briannorris@chromium.org>
+Tested-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220119161104.1.I1d01436bef35165a8cdfe9308789c0badb5ff46a@changeid
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
++++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+@@ -902,6 +902,7 @@ static const struct vop_win_phy rk3399_w
+ .enable = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 0),
+ .format = VOP_REG(RK3288_WIN0_CTRL0, 0x7, 1),
+ .rb_swap = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 12),
++ .x_mir_en = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 21),
+ .y_mir_en = VOP_REG(RK3288_WIN0_CTRL0, 0x1, 22),
+ .act_info = VOP_REG(RK3288_WIN0_ACT_INFO, 0x1fff1fff, 0),
+ .dsp_info = VOP_REG(RK3288_WIN0_DSP_INFO, 0x0fff0fff, 0),
+@@ -912,6 +913,7 @@ static const struct vop_win_phy rk3399_w
+ .uv_vir = VOP_REG(RK3288_WIN0_VIR, 0x3fff, 16),
+ .src_alpha_ctl = VOP_REG(RK3288_WIN0_SRC_ALPHA_CTRL, 0xff, 0),
+ .dst_alpha_ctl = VOP_REG(RK3288_WIN0_DST_ALPHA_CTRL, 0xff, 0),
++ .channel = VOP_REG(RK3288_WIN0_CTRL2, 0xff, 0),
+ };
+
+ /*
+@@ -922,11 +924,11 @@ static const struct vop_win_phy rk3399_w
+ static const struct vop_win_data rk3399_vop_win_data[] = {
+ { .base = 0x00, .phy = &rk3399_win01_data,
+ .type = DRM_PLANE_TYPE_PRIMARY },
+- { .base = 0x40, .phy = &rk3288_win01_data,
++ { .base = 0x40, .phy = &rk3368_win01_data,
+ .type = DRM_PLANE_TYPE_OVERLAY },
+- { .base = 0x00, .phy = &rk3288_win23_data,
++ { .base = 0x00, .phy = &rk3368_win23_data,
+ .type = DRM_PLANE_TYPE_OVERLAY },
+- { .base = 0x50, .phy = &rk3288_win23_data,
++ { .base = 0x50, .phy = &rk3368_win23_data,
+ .type = DRM_PLANE_TYPE_CURSOR },
+ };
+
--- /dev/null
+From d3add1a9519dcacd6e644ecac741c56cf18b67f5 Mon Sep 17 00:00:00 2001
+From: Bob Peterson <rpeterso@redhat.com>
+Date: Tue, 18 Jan 2022 09:30:18 -0500
+Subject: gfs2: Fix gfs2_release for non-writers regression
+
+From: Bob Peterson <rpeterso@redhat.com>
+
+commit d3add1a9519dcacd6e644ecac741c56cf18b67f5 upstream.
+
+When a file is opened for writing, the vfs code (do_dentry_open)
+calls get_write_access for the inode, thus incrementing the inode's write
+count. That writer normally then creates a multi-block reservation for
+the inode (i_res) that can be re-used by other writers, which speeds up
+writes for applications that stupidly loop on open/write/close.
+When the writes are all done, the multi-block reservation should be
+deleted when the file is closed by the last "writer."
+
+Commit 0ec9b9ea4f83 broke that concept when it moved the call to
+gfs2_rs_delete before the check for FMODE_WRITE. Non-writers have no
+business removing the multi-block reservations of writers. In fact, if
+someone opens and closes the file for RO while a writer has a
+multi-block reservation, the RO closer will delete the reservation
+midway through the write, and this results in:
+
+kernel BUG at fs/gfs2/rgrp.c:677! (or thereabouts) which is:
+BUG_ON(rs->rs_requested); from function gfs2_rs_deltree.
+
+This patch moves the check back inside the check for FMODE_WRITE.
+
+Fixes: 0ec9b9ea4f83 ("gfs2: Check for active reservation in gfs2_release")
+Cc: stable@vger.kernel.org # v5.12+
+Signed-off-by: Bob Peterson <rpeterso@redhat.com>
+Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/gfs2/file.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/fs/gfs2/file.c
++++ b/fs/gfs2/file.c
+@@ -704,10 +704,11 @@ static int gfs2_release(struct inode *in
+ kfree(file->private_data);
+ file->private_data = NULL;
+
+- if (gfs2_rs_active(&ip->i_res))
+- gfs2_rs_delete(ip, &inode->i_writecount);
+- if (file->f_mode & FMODE_WRITE)
++ if (file->f_mode & FMODE_WRITE) {
++ if (gfs2_rs_active(&ip->i_res))
++ gfs2_rs_delete(ip, &inode->i_writecount);
+ gfs2_qa_put(ip);
++ }
+ return 0;
+ }
+
--- /dev/null
+From 63573807b27e0faf8065a28b1bbe1cbfb23c0130 Mon Sep 17 00:00:00 2001
+From: Sagi Grimberg <sagi@grimberg.me>
+Date: Mon, 7 Feb 2022 00:40:13 +0200
+Subject: nvme-tcp: fix bogus request completion when failing to send AER
+
+From: Sagi Grimberg <sagi@grimberg.me>
+
+commit 63573807b27e0faf8065a28b1bbe1cbfb23c0130 upstream.
+
+AER is not backed by a real request, hence we should not incorrectly
+assume that when failing to send a nvme command, it is a normal request
+but rather check if this is an aer and if so complete the aer (similar
+to the normal completion path).
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/host/tcp.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/nvme/host/tcp.c
++++ b/drivers/nvme/host/tcp.c
+@@ -913,7 +913,15 @@ static inline void nvme_tcp_done_send_re
+
+ static void nvme_tcp_fail_request(struct nvme_tcp_request *req)
+ {
+- nvme_tcp_end_request(blk_mq_rq_from_pdu(req), NVME_SC_HOST_PATH_ERROR);
++ if (nvme_tcp_async_req(req)) {
++ union nvme_result res = {};
++
++ nvme_complete_async_event(&req->queue->ctrl->ctrl,
++ cpu_to_le16(NVME_SC_HOST_PATH_ERROR), &res);
++ } else {
++ nvme_tcp_end_request(blk_mq_rq_from_pdu(req),
++ NVME_SC_HOST_PATH_ERROR);
++ }
+ }
+
+ static int nvme_tcp_try_send_data(struct nvme_tcp_request *req)
--- /dev/null
+From cb1f65c1e1424a4b5e4a86da8aa3b8fd8459c8ec Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Fri, 4 Feb 2022 18:35:22 +0100
+Subject: PM: s2idle: ACPI: Fix wakeup interrupts handling
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit cb1f65c1e1424a4b5e4a86da8aa3b8fd8459c8ec upstream.
+
+After commit e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race
+related to the EC GPE") wakeup interrupts occurring immediately after
+the one discarded by acpi_s2idle_wake() may be missed. Moreover, if
+the SCI triggers again immediately after the rearming in
+acpi_s2idle_wake(), that wakeup may be missed too.
+
+The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup()
+when pm_wakeup_irq is 0, but that's not the case any more after the
+interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is
+cleared by the pm_wakeup_clear() call in s2idle_loop(). However,
+there may be wakeup interrupts occurring in that time frame and if
+that happens, they will be missed.
+
+To address that issue first move the clearing of pm_wakeup_irq to
+the point at which it is known that the interrupt causing
+acpi_s2idle_wake() to tun will be discarded, before rearming the SCI
+for wakeup. Moreover, because that only reduces the size of the
+time window in which the issue may manifest itself, allow
+pm_system_irq_wakeup() to register two second wakeup interrupts in
+a row and, when discarding the first one, replace it with the second
+one. [Of course, this assumes that only one wakeup interrupt can be
+discarded in one go, but currently that is the case and I am not
+aware of any plans to change that.]
+
+Fixes: e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE")
+Cc: 5.4+ <stable@vger.kernel.org> # 5.4+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/sleep.c | 1 +
+ drivers/base/power/wakeup.c | 41 ++++++++++++++++++++++++++++++++++-------
+ include/linux/suspend.h | 4 ++--
+ kernel/power/main.c | 5 ++++-
+ kernel/power/process.c | 2 +-
+ kernel/power/suspend.c | 2 --
+ 6 files changed, 42 insertions(+), 13 deletions(-)
+
+--- a/drivers/acpi/sleep.c
++++ b/drivers/acpi/sleep.c
+@@ -767,6 +767,7 @@ bool acpi_s2idle_wake(void)
+ return true;
+ }
+
++ pm_wakeup_clear(acpi_sci_irq);
+ rearm_wake_irq(acpi_sci_irq);
+ }
+
+--- a/drivers/base/power/wakeup.c
++++ b/drivers/base/power/wakeup.c
+@@ -34,7 +34,8 @@ suspend_state_t pm_suspend_target_state;
+ bool events_check_enabled __read_mostly;
+
+ /* First wakeup IRQ seen by the kernel in the last cycle. */
+-unsigned int pm_wakeup_irq __read_mostly;
++static unsigned int wakeup_irq[2] __read_mostly;
++static DEFINE_RAW_SPINLOCK(wakeup_irq_lock);
+
+ /* If greater than 0 and the system is suspending, terminate the suspend. */
+ static atomic_t pm_abort_suspend __read_mostly;
+@@ -942,19 +943,45 @@ void pm_system_cancel_wakeup(void)
+ atomic_dec_if_positive(&pm_abort_suspend);
+ }
+
+-void pm_wakeup_clear(bool reset)
++void pm_wakeup_clear(unsigned int irq_number)
+ {
+- pm_wakeup_irq = 0;
+- if (reset)
++ raw_spin_lock_irq(&wakeup_irq_lock);
++
++ if (irq_number && wakeup_irq[0] == irq_number)
++ wakeup_irq[0] = wakeup_irq[1];
++ else
++ wakeup_irq[0] = 0;
++
++ wakeup_irq[1] = 0;
++
++ raw_spin_unlock_irq(&wakeup_irq_lock);
++
++ if (!irq_number)
+ atomic_set(&pm_abort_suspend, 0);
+ }
+
+ void pm_system_irq_wakeup(unsigned int irq_number)
+ {
+- if (pm_wakeup_irq == 0) {
+- pm_wakeup_irq = irq_number;
++ unsigned long flags;
++
++ raw_spin_lock_irqsave(&wakeup_irq_lock, flags);
++
++ if (wakeup_irq[0] == 0)
++ wakeup_irq[0] = irq_number;
++ else if (wakeup_irq[1] == 0)
++ wakeup_irq[1] = irq_number;
++ else
++ irq_number = 0;
++
++ raw_spin_unlock_irqrestore(&wakeup_irq_lock, flags);
++
++ if (irq_number)
+ pm_system_wakeup();
+- }
++}
++
++unsigned int pm_wakeup_irq(void)
++{
++ return wakeup_irq[0];
+ }
+
+ /**
+--- a/include/linux/suspend.h
++++ b/include/linux/suspend.h
+@@ -496,14 +496,14 @@ extern void ksys_sync_helper(void);
+
+ /* drivers/base/power/wakeup.c */
+ extern bool events_check_enabled;
+-extern unsigned int pm_wakeup_irq;
+ extern suspend_state_t pm_suspend_target_state;
+
+ extern bool pm_wakeup_pending(void);
+ extern void pm_system_wakeup(void);
+ extern void pm_system_cancel_wakeup(void);
+-extern void pm_wakeup_clear(bool reset);
++extern void pm_wakeup_clear(unsigned int irq_number);
+ extern void pm_system_irq_wakeup(unsigned int irq_number);
++extern unsigned int pm_wakeup_irq(void);
+ extern bool pm_get_wakeup_count(unsigned int *count, bool block);
+ extern bool pm_save_wakeup_count(unsigned int count);
+ extern void pm_wakep_autosleep_enabled(bool set);
+--- a/kernel/power/main.c
++++ b/kernel/power/main.c
+@@ -504,7 +504,10 @@ static ssize_t pm_wakeup_irq_show(struct
+ struct kobj_attribute *attr,
+ char *buf)
+ {
+- return pm_wakeup_irq ? sprintf(buf, "%u\n", pm_wakeup_irq) : -ENODATA;
++ if (!pm_wakeup_irq())
++ return -ENODATA;
++
++ return sprintf(buf, "%u\n", pm_wakeup_irq());
+ }
+
+ power_attr_ro(pm_wakeup_irq);
+--- a/kernel/power/process.c
++++ b/kernel/power/process.c
+@@ -134,7 +134,7 @@ int freeze_processes(void)
+ if (!pm_freezing)
+ atomic_inc(&system_freezing_cnt);
+
+- pm_wakeup_clear(true);
++ pm_wakeup_clear(0);
+ pr_info("Freezing user space processes ... ");
+ pm_freezing = true;
+ error = try_to_freeze_tasks(true);
+--- a/kernel/power/suspend.c
++++ b/kernel/power/suspend.c
+@@ -136,8 +136,6 @@ static void s2idle_loop(void)
+ break;
+ }
+
+- pm_wakeup_clear(false);
+-
+ s2idle_enter();
+ }
+
--- /dev/null
+From 356b8103d4c495d5440e3e687db9026ec2b76043 Mon Sep 17 00:00:00 2001
+From: Andreas Gruenbacher <agruenba@redhat.com>
+Date: Thu, 3 Feb 2022 14:06:56 +0100
+Subject: Revert "gfs2: check context in gfs2_glock_put"
+
+From: Andreas Gruenbacher <agruenba@redhat.com>
+
+commit 356b8103d4c495d5440e3e687db9026ec2b76043 upstream.
+
+It turns out that the might_sleep() call that commit 660a6126f8c3 adds
+is triggering occasional data corruption in testing. We're not sure
+about the root cause yet, but since this commit was added as a debugging
+aid only, revert it for now.
+
+This reverts commit 660a6126f8c3208f6df8d552039cda078a8426d1.
+
+Fixes: 660a6126f8c3 ("gfs2: check context in gfs2_glock_put")
+Cc: stable@vger.kernel.org # v5.16+
+Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/gfs2/glock.c | 3 ---
+ 1 file changed, 3 deletions(-)
+
+--- a/fs/gfs2/glock.c
++++ b/fs/gfs2/glock.c
+@@ -301,9 +301,6 @@ void gfs2_glock_queue_put(struct gfs2_gl
+
+ void gfs2_glock_put(struct gfs2_glock *gl)
+ {
+- /* last put could call sleepable dlm api */
+- might_sleep();
+-
+ if (lockref_put_or_lock(&gl->gl_lockref))
+ return;
+
--- /dev/null
+From 075b7d363c675ef7fa03918881caeca3458e2a96 Mon Sep 17 00:00:00 2001
+From: Bjorn Helgaas <bhelgaas@google.com>
+Date: Mon, 7 Feb 2022 16:33:30 -0600
+Subject: Revert "PCI/portdrv: Do not setup up IRQs if there are no users"
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+commit 075b7d363c675ef7fa03918881caeca3458e2a96 upstream.
+
+This reverts commit 0e8ae5a6ff5952253cd7cc0260df838ab4c21009.
+
+0e8ae5a6ff59 ("PCI/portdrv: Do not setup up IRQs if there are no users")
+reduced usage of IRQs when we don't think we need them. But Joey, Sergiu,
+and David reported choppy GUI rendering, systems that became unresponsive
+every few seconds, incorrect values reported by cpufreq, and high IRQ 16
+CPU usage.
+
+Joey bisected the issues to 0e8ae5a6ff59, so revert it until we figure out
+a better solution.
+
+Link: https://lore.kernel.org/r/20220210222717.GA658201@bhelgaas
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=215533
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=215546
+Reported-by: Joey Corleone <joey.corleone@mail.ru>
+Reported-by: Sergiu Deitsch <sergiu.deitsch@gmail.com>
+Reported-by: David Spencer <dspencer577@gmail.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: stable@vger.kernel.org # v5.16+
+Cc: Jan Kiszka <jan.kiszka@siemens.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pci/pcie/portdrv_core.c | 47 ++++++++++++++--------------------------
+ 1 file changed, 17 insertions(+), 30 deletions(-)
+
+--- a/drivers/pci/pcie/portdrv_core.c
++++ b/drivers/pci/pcie/portdrv_core.c
+@@ -166,6 +166,9 @@ static int pcie_init_service_irqs(struct
+ {
+ int ret, i;
+
++ for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
++ irqs[i] = -1;
++
+ /*
+ * If we support PME but can't use MSI/MSI-X for it, we have to
+ * fall back to INTx or other interrupts, e.g., a system shared
+@@ -314,10 +317,8 @@ static int pcie_device_init(struct pci_d
+ */
+ int pcie_port_device_register(struct pci_dev *dev)
+ {
+- int status, capabilities, irq_services, i, nr_service;
+- int irqs[PCIE_PORT_DEVICE_MAXSERVICES] = {
+- [0 ... PCIE_PORT_DEVICE_MAXSERVICES-1] = -1
+- };
++ int status, capabilities, i, nr_service;
++ int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
+
+ /* Enable PCI Express port device */
+ status = pci_enable_device(dev);
+@@ -330,32 +331,18 @@ int pcie_port_device_register(struct pci
+ return 0;
+
+ pci_set_master(dev);
+-
+- irq_services = 0;
+- if (IS_ENABLED(CONFIG_PCIE_PME))
+- irq_services |= PCIE_PORT_SERVICE_PME;
+- if (IS_ENABLED(CONFIG_PCIEAER))
+- irq_services |= PCIE_PORT_SERVICE_AER;
+- if (IS_ENABLED(CONFIG_HOTPLUG_PCI_PCIE))
+- irq_services |= PCIE_PORT_SERVICE_HP;
+- if (IS_ENABLED(CONFIG_PCIE_DPC))
+- irq_services |= PCIE_PORT_SERVICE_DPC;
+- irq_services &= capabilities;
+-
+- if (irq_services) {
+- /*
+- * Initialize service IRQs. Don't use service devices that
+- * require interrupts if there is no way to generate them.
+- * However, some drivers may have a polling mode (e.g.
+- * pciehp_poll_mode) that can be used in the absence of IRQs.
+- * Allow them to determine if that is to be used.
+- */
+- status = pcie_init_service_irqs(dev, irqs, irq_services);
+- if (status) {
+- irq_services &= PCIE_PORT_SERVICE_HP;
+- if (!irq_services)
+- goto error_disable;
+- }
++ /*
++ * Initialize service irqs. Don't use service devices that
++ * require interrupts if there is no way to generate them.
++ * However, some drivers may have a polling mode (e.g. pciehp_poll_mode)
++ * that can be used in the absence of irqs. Allow them to determine
++ * if that is to be used.
++ */
++ status = pcie_init_service_irqs(dev, irqs, capabilities);
++ if (status) {
++ capabilities &= PCIE_PORT_SERVICE_HP;
++ if (!capabilities)
++ goto error_disable;
+ }
+
+ /* Allocate child services if any */
--- /dev/null
+From f40fe31c01445f31253b15bef2412b33ae31093b Mon Sep 17 00:00:00 2001
+From: Pingfan Liu <kernelfans@gmail.com>
+Date: Sun, 23 Jan 2022 20:13:52 +0800
+Subject: riscv: cpu-hotplug: clear cpu from numa map when teardown
+
+From: Pingfan Liu <kernelfans@gmail.com>
+
+commit f40fe31c01445f31253b15bef2412b33ae31093b upstream.
+
+There is numa_add_cpu() when cpus online, accordingly, there should be
+numa_remove_cpu() when cpus offline.
+
+Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
+Fixes: 4f0e8eef772e ("riscv: Add numa support for riscv64 platform")
+Cc: stable@vger.kernel.org
+[Palmer: Add missing NUMA include]
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/kernel/cpu-hotplug.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/riscv/kernel/cpu-hotplug.c
++++ b/arch/riscv/kernel/cpu-hotplug.c
+@@ -12,6 +12,7 @@
+ #include <linux/sched/hotplug.h>
+ #include <asm/irq.h>
+ #include <asm/cpu_ops.h>
++#include <asm/numa.h>
+ #include <asm/sbi.h>
+
+ void cpu_stop(void);
+@@ -46,6 +47,7 @@ int __cpu_disable(void)
+ return ret;
+
+ remove_cpu_topology(cpu);
++ numa_remove_cpu(cpu);
+ set_cpu_online(cpu, false);
+ irq_migrate_all_off_this_cpu();
+
--- /dev/null
+From 6a00ef4493706a23120057fafbc62379bcde11ec Mon Sep 17 00:00:00 2001
+From: Changbin Du <changbin.du@gmail.com>
+Date: Mon, 17 Jan 2022 23:44:33 +0800
+Subject: riscv: eliminate unreliable __builtin_frame_address(1)
+
+From: Changbin Du <changbin.du@gmail.com>
+
+commit 6a00ef4493706a23120057fafbc62379bcde11ec upstream.
+
+I tried different pieces of code which uses __builtin_frame_address(1)
+(with both gcc version 7.5.0 and 10.3.0) to verify whether it works as
+expected on riscv64. The result is negative.
+
+What the compiler had generated is as below:
+31 fp = (unsigned long)__builtin_frame_address(1);
+ 0xffffffff80006024 <+200>: ld s1,0(s0)
+
+It takes '0(s0)' as the address of frame 1 (caller), but the actual address
+should be '-16(s0)'.
+
+ | ... | <-+
+ +-----------------+ |
+ | return address | |
+ | previous fp | |
+ | saved registers | |
+ | local variables | |
+ $fp --> | ... | |
+ +-----------------+ |
+ | return address | |
+ | previous fp --------+
+ | saved registers |
+ $sp --> | local variables |
+ +-----------------+
+
+This leads the kernel can not dump the full stack trace on riscv.
+
+[ 7.222126][ T1] Call Trace:
+[ 7.222804][ T1] [<ffffffff80006058>] dump_backtrace+0x2c/0x3a
+
+This problem is not exposed on most riscv builds just because the '0(s0)'
+occasionally is the address frame 2 (caller's caller), if only ra and fp
+are stored in frame 1 (caller).
+
+ | ... | <-+
+ +-----------------+ |
+ | return address | |
+ $fp --> | previous fp | |
+ +-----------------+ |
+ | return address | |
+ | previous fp --------+
+ | saved registers |
+ $sp --> | local variables |
+ +-----------------+
+
+This could be a *bug* of gcc that should be fixed. But as noted in gcc
+manual "Calling this function with a nonzero argument can have
+unpredictable effects, including crashing the calling program.", let's
+remove the '__builtin_frame_address(1)' in backtrace code.
+
+With this fix now it can show full stack trace:
+[ 10.444838][ T1] Call Trace:
+[ 10.446199][ T1] [<ffffffff8000606c>] dump_backtrace+0x2c/0x3a
+[ 10.447711][ T1] [<ffffffff800060ac>] show_stack+0x32/0x3e
+[ 10.448710][ T1] [<ffffffff80a005c0>] dump_stack_lvl+0x58/0x7a
+[ 10.449941][ T1] [<ffffffff80a005f6>] dump_stack+0x14/0x1c
+[ 10.450929][ T1] [<ffffffff804c04ee>] ubsan_epilogue+0x10/0x5a
+[ 10.451869][ T1] [<ffffffff804c092e>] __ubsan_handle_load_invalid_value+0x6c/0x78
+[ 10.453049][ T1] [<ffffffff8018f834>] __pagevec_release+0x62/0x64
+[ 10.455476][ T1] [<ffffffff80190830>] truncate_inode_pages_range+0x132/0x5be
+[ 10.456798][ T1] [<ffffffff80190ce0>] truncate_inode_pages+0x24/0x30
+[ 10.457853][ T1] [<ffffffff8045bb04>] kill_bdev+0x32/0x3c
+...
+
+Signed-off-by: Changbin Du <changbin.du@gmail.com>
+Fixes: eac2f3059e02 ("riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled")
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/kernel/stacktrace.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/arch/riscv/kernel/stacktrace.c
++++ b/arch/riscv/kernel/stacktrace.c
+@@ -22,15 +22,16 @@ void notrace walk_stackframe(struct task
+ bool (*fn)(void *, unsigned long), void *arg)
+ {
+ unsigned long fp, sp, pc;
++ int level = 0;
+
+ if (regs) {
+ fp = frame_pointer(regs);
+ sp = user_stack_pointer(regs);
+ pc = instruction_pointer(regs);
+ } else if (task == NULL || task == current) {
+- fp = (unsigned long)__builtin_frame_address(1);
+- sp = (unsigned long)__builtin_frame_address(0);
+- pc = (unsigned long)__builtin_return_address(0);
++ fp = (unsigned long)__builtin_frame_address(0);
++ sp = sp_in_global;
++ pc = (unsigned long)walk_stackframe;
+ } else {
+ /* task blocked in __switch_to */
+ fp = task->thread.s[0];
+@@ -42,7 +43,7 @@ void notrace walk_stackframe(struct task
+ unsigned long low, high;
+ struct stackframe *frame;
+
+- if (unlikely(!__kernel_text_address(pc) || !fn(arg, pc)))
++ if (unlikely(!__kernel_text_address(pc) || (level++ >= 1 && !fn(arg, pc))))
+ break;
+
+ /* Validate frame pointer */
--- /dev/null
+From 6df2a016c0c8a3d0933ef33dd192ea6606b115e3 Mon Sep 17 00:00:00 2001
+From: Aurelien Jarno <aurelien@aurel32.net>
+Date: Wed, 26 Jan 2022 18:14:42 +0100
+Subject: riscv: fix build with binutils 2.38
+
+From: Aurelien Jarno <aurelien@aurel32.net>
+
+commit 6df2a016c0c8a3d0933ef33dd192ea6606b115e3 upstream.
+
+From version 2.38, binutils default to ISA spec version 20191213. This
+means that the csr read/write (csrr*/csrw*) instructions and fence.i
+instruction has separated from the `I` extension, become two standalone
+extensions: Zicsr and Zifencei. As the kernel uses those instruction,
+this causes the following build failure:
+
+ CC arch/riscv/kernel/vdso/vgettimeofday.o
+ <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h: Assembler messages:
+ <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01'
+ <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01'
+ <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01'
+ <<BUILDDIR>>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01'
+
+The fix is to specify those extensions explicitely in -march. However as
+older binutils version do not support this, we first need to detect
+that.
+
+Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
+Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/Makefile | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/riscv/Makefile
++++ b/arch/riscv/Makefile
+@@ -50,6 +50,12 @@ riscv-march-$(CONFIG_ARCH_RV32I) := rv32
+ riscv-march-$(CONFIG_ARCH_RV64I) := rv64ima
+ riscv-march-$(CONFIG_FPU) := $(riscv-march-y)fd
+ riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c
++
++# Newer binutils versions default to ISA spec version 20191213 which moves some
++# instructions from the I extension to the Zicsr and Zifencei extensions.
++toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei)
++riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei
++
+ KBUILD_CFLAGS += -march=$(subst fd,,$(riscv-march-y))
+ KBUILD_AFLAGS += -march=$(riscv-march-y)
+
--- /dev/null
+From 3c04d84508b54fcf524093b0d4a718680ed67f0f Mon Sep 17 00:00:00 2001
+From: Myrtle Shah <gatecat@ds0.me>
+Date: Thu, 20 Jan 2022 15:33:37 +0000
+Subject: riscv: Fix XIP_FIXUP_FLASH_OFFSET
+
+From: Myrtle Shah <gatecat@ds0.me>
+
+commit 3c04d84508b54fcf524093b0d4a718680ed67f0f upstream.
+
+There were several problems with the calculation. Not only was an 'and'
+being computed into t1 but thrown away; but the 'and' itself would
+cause problems if the granularity of the XIP physical address was less
+than XIP_OFFSET - in my case I had the kernel image at 2MB in SPI flash.
+
+Fixes: f9ace4ede49b ("riscv: remove .text section size limitation for XIP")
+Cc: stable@vger.kernel.org
+Signed-off-by: Myrtle Shah <gatecat@ds0.me>
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/kernel/head.S | 11 +++++------
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+--- a/arch/riscv/kernel/head.S
++++ b/arch/riscv/kernel/head.S
+@@ -21,14 +21,13 @@
+ add \reg, \reg, t0
+ .endm
+ .macro XIP_FIXUP_FLASH_OFFSET reg
+- la t1, __data_loc
+- li t0, XIP_OFFSET_MASK
+- and t1, t1, t0
+- li t1, XIP_OFFSET
+- sub t0, t0, t1
+- sub \reg, \reg, t0
++ la t0, __data_loc
++ REG_L t1, _xip_phys_offset
++ sub \reg, \reg, t1
++ add \reg, \reg, t0
+ .endm
+ _xip_fixup: .dword CONFIG_PHYS_RAM_BASE - CONFIG_XIP_PHYS_ADDR - XIP_OFFSET
++_xip_phys_offset: .dword CONFIG_XIP_PHYS_ADDR + XIP_OFFSET
+ #else
+ .macro XIP_FIXUP_OFFSET reg
+ .endm
--- /dev/null
+From 4b1c70aa8ed8249608bb991380cb8ff423edf49e Mon Sep 17 00:00:00 2001
+From: Palmer Dabbelt <palmer@rivosinc.com>
+Date: Fri, 4 Feb 2022 13:13:37 -0800
+Subject: riscv/mm: Add XIP_FIXUP for phys_ram_base
+
+From: Palmer Dabbelt <palmer@rivosinc.com>
+
+commit 4b1c70aa8ed8249608bb991380cb8ff423edf49e upstream.
+
+This manifests as a crash early in boot on VexRiscv.
+
+Signed-off-by: Myrtle Shah <gatecat@ds0.me>
+[Palmer: split commit]
+Fixes: 6d7f91d914bc ("riscv: Get rid of CONFIG_PHYS_RAM_BASE in kernel physical address conversion")
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/mm/init.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/riscv/mm/init.c
++++ b/arch/riscv/mm/init.c
+@@ -41,6 +41,7 @@ phys_addr_t phys_ram_base __ro_after_ini
+ EXPORT_SYMBOL(phys_ram_base);
+
+ #ifdef CONFIG_XIP_KERNEL
++#define phys_ram_base (*(phys_addr_t *)XIP_FIXUP(&phys_ram_base))
+ extern char _xiprom[], _exiprom[], __data_loc;
+ #endif
+
kvm-svm-don-t-kill-sev-guest-if-smap-erratum-trigger.patch
kvm-vmx-set-vmcs.pending_dbg.bs-on-db-in-sti-movss-b.patch
kvm-x86-report-deprecated-x87-features-in-supported-.patch
+riscv-fix-build-with-binutils-2.38.patch
+riscv-fix-xip_fixup_flash_offset.patch
+riscv-cpu-hotplug-clear-cpu-from-numa-map-when-teardown.patch
+riscv-mm-add-xip_fixup-for-phys_ram_base.patch
+riscv-eliminate-unreliable-__builtin_frame_address-1.patch
+gfs2-fix-gfs2_release-for-non-writers-regression.patch
+revert-gfs2-check-context-in-gfs2_glock_put.patch
+revert-pci-portdrv-do-not-setup-up-irqs-if-there-are-no-users.patch
+arm-dts-imx23-evk-remove-mx23_pad_ssp1_detect-from-hog-group.patch
+arm-dts-fix-boot-regression-on-skomer.patch
+arm-socfpga-fix-missing-reset_controller.patch
+nvme-tcp-fix-bogus-request-completion-when-failing-to-send-aer.patch
+acpi-iort-check-node-revision-for-pmcg-resources.patch
+pm-s2idle-acpi-fix-wakeup-interrupts-handling.patch
+drm-amdgpu-display-change-pipe-policy-for-dcn-2.0.patch
+drm-rockchip-vop-correct-rk3399-vop-register-fields.patch
+drm-i915-disable-drrs-on-ivb-hsw-port-a.patch
+drm-i915-allow-join_mbus-cases-for-adlp-dbuf-configuration.patch
+drm-i915-populate-pipe-dbuf-slices-more-accurately-during-readout.patch
+drm-i915-workaround-broken-bios-dbuf-configuration-on-tgl-rkl.patch