From: Greg Kroah-Hartman Date: Thu, 15 Jul 2021 12:39:47 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v5.4.133~40 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=60aa311e6c3b237a65b4030646241e932c729ac1;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: ata-ahci_sunxi-disable-dipm.patch clocksource-arm_arch_timer-improve-allwinner-a64-timer-workaround.patch cpu-hotplug-cure-the-cpusets-trainwreck.patch drm-amd-display-fix-incorrrect-valid-irq-check.patch drm-amd-display-reject-non-zero-src_y-and-src_x-for-video-planes.patch drm-amdgpu-update-nv-simd-per-cu-to-2.patch drm-arm-malidp-always-list-modifiers.patch drm-msm-mdp4-fix-modifier-support-enabling.patch drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch drm-rockchip-dsi-remove-extra-component_del-call.patch drm-tegra-don-t-set-allow_fb_modifiers-explicitly.patch fpga-stratix10-soc-add-missing-fpga_mgr_free-call.patch mmc-core-allow-uhs-i-voltage-switch-for-sdsc-cards-if-supported.patch mmc-core-clear-flags-before-allowing-to-retune.patch mmc-sdhci-fix-warning-message-when-accessing-rpmb-in-hs400-mode.patch pinctrl-amd-add-device-hid-for-new-amd-gpio-controller.patch --- diff --git a/queue-5.4/ata-ahci_sunxi-disable-dipm.patch b/queue-5.4/ata-ahci_sunxi-disable-dipm.patch new file mode 100644 index 00000000000..fcc827c0f07 --- /dev/null +++ b/queue-5.4/ata-ahci_sunxi-disable-dipm.patch @@ -0,0 +1,43 @@ +From f6bca4d91b2ea052e917cca3f9d866b5cc1d500a Mon Sep 17 00:00:00 2001 +From: Timo Sigurdsson +Date: Mon, 14 Jun 2021 09:25:39 +0200 +Subject: ata: ahci_sunxi: Disable DIPM + +From: Timo Sigurdsson + +commit f6bca4d91b2ea052e917cca3f9d866b5cc1d500a upstream. + +DIPM is unsupported or broken on sunxi. Trying to enable the power +management policy med_power_with_dipm on an Allwinner A20 SoC based board +leads to immediate I/O errors and the attached SATA disk disappears from +the /dev filesystem. A reset (power cycle) is required to make the SATA +controller or disk work again. The A10 and A20 SoC data sheets and manuals +don't mention DIPM at all [1], so it's fair to assume that it's simply not +supported. But even if it was, it should be considered broken and best be +disabled in the ahci_sunxi driver. + +[1] https://github.com/allwinner-zh/documents/tree/master/ + +Fixes: c5754b5220f0 ("ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform") +Cc: stable@vger.kernel.org +Signed-off-by: Timo Sigurdsson +Tested-by: Timo Sigurdsson +Link: https://lore.kernel.org/r/20210614072539.3307-1-public_timo.s@silentcreek.de +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ata/ahci_sunxi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/ata/ahci_sunxi.c ++++ b/drivers/ata/ahci_sunxi.c +@@ -200,7 +200,7 @@ static void ahci_sunxi_start_engine(stru + } + + static const struct ata_port_info ahci_sunxi_port_info = { +- .flags = AHCI_FLAG_COMMON | ATA_FLAG_NCQ, ++ .flags = AHCI_FLAG_COMMON | ATA_FLAG_NCQ | ATA_FLAG_NO_DIPM, + .pio_mask = ATA_PIO4, + .udma_mask = ATA_UDMA6, + .port_ops = &ahci_platform_ops, diff --git a/queue-5.4/clocksource-arm_arch_timer-improve-allwinner-a64-timer-workaround.patch b/queue-5.4/clocksource-arm_arch_timer-improve-allwinner-a64-timer-workaround.patch new file mode 100644 index 00000000000..281bd7fd588 --- /dev/null +++ b/queue-5.4/clocksource-arm_arch_timer-improve-allwinner-a64-timer-workaround.patch @@ -0,0 +1,43 @@ +From 8b33dfe0ba1c84c1aab2456590b38195837f1e6e Mon Sep 17 00:00:00 2001 +From: Samuel Holland +Date: Fri, 14 May 2021 21:14:39 -0500 +Subject: clocksource/arm_arch_timer: Improve Allwinner A64 timer workaround + +From: Samuel Holland + +commit 8b33dfe0ba1c84c1aab2456590b38195837f1e6e upstream. + +Bad counter reads are experienced sometimes when bit 10 or greater rolls +over. Originally, testing showed that at least 10 lower bits would be +set to the same value during these bad reads. However, some users still +reported time skips. + +Wider testing revealed that on some chips, occasionally only the lowest +9 bits would read as the anomalous value. During these reads (which +still happen only when bit 10), bit 9 would read as the correct value. + +Reduce the mask by one bit to cover these cases as well. + +Cc: stable@vger.kernel.org +Fixes: c950ca8c35ee ("clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer instability") +Reported-by: Roman Stratiienko +Signed-off-by: Samuel Holland +Signed-off-by: Daniel Lezcano +Link: https://lore.kernel.org/r/20210515021439.55316-1-samuel@sholland.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/clocksource/arm_arch_timer.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/clocksource/arm_arch_timer.c ++++ b/drivers/clocksource/arm_arch_timer.c +@@ -348,7 +348,7 @@ static u64 notrace arm64_858921_read_cnt + do { \ + _val = read_sysreg(reg); \ + _retries--; \ +- } while (((_val + 1) & GENMASK(9, 0)) <= 1 && _retries); \ ++ } while (((_val + 1) & GENMASK(8, 0)) <= 1 && _retries); \ + \ + WARN_ON_ONCE(!_retries); \ + _val; \ diff --git a/queue-5.4/cpu-hotplug-cure-the-cpusets-trainwreck.patch b/queue-5.4/cpu-hotplug-cure-the-cpusets-trainwreck.patch new file mode 100644 index 00000000000..9a7c0ce282c --- /dev/null +++ b/queue-5.4/cpu-hotplug-cure-the-cpusets-trainwreck.patch @@ -0,0 +1,157 @@ +From b22afcdf04c96ca58327784e280e10288cfd3303 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Sat, 27 Mar 2021 22:01:36 +0100 +Subject: cpu/hotplug: Cure the cpusets trainwreck + +From: Thomas Gleixner + +commit b22afcdf04c96ca58327784e280e10288cfd3303 upstream. + +Alexey and Joshua tried to solve a cpusets related hotplug problem which is +user space visible and results in unexpected behaviour for some time after +a CPU has been plugged in and the corresponding uevent was delivered. + +cpusets delegate the hotplug work (rebuilding cpumasks etc.) to a +workqueue. This is done because the cpusets code has already a lock +nesting of cgroups_mutex -> cpu_hotplug_lock. A synchronous callback or +waiting for the work to finish with cpu_hotplug_lock held can and will +deadlock because that results in the reverse lock order. + +As a consequence the uevent can be delivered before cpusets have consistent +state which means that a user space invocation of sched_setaffinity() to +move a task to the plugged CPU fails up to the point where the scheduled +work has been processed. + +The same is true for CPU unplug, but that does not create user observable +failure (yet). + +It's still inconsistent to claim that an operation is finished before it +actually is and that's the real issue at hand. uevents just make it +reliably observable. + +Obviously the problem should be fixed in cpusets/cgroups, but untangling +that is pretty much impossible because according to the changelog of the +commit which introduced this 8 years ago: + + 3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()") + +the lock order cgroups_mutex -> cpu_hotplug_lock is a design decision and +the whole code is built around that. + +So bite the bullet and invoke the relevant cpuset function, which waits for +the work to finish, in _cpu_up/down() after dropping cpu_hotplug_lock and +only when tasks are not frozen by suspend/hibernate because that would +obviously wait forever. + +Waiting there with cpu_add_remove_lock, which is protecting the present +and possible CPU maps, held is not a problem at all because neither work +queues nor cpusets/cgroups have any lockchains related to that lock. + +Waiting in the hotplug machinery is not problematic either because there +are already state callbacks which wait for hardware queues to drain. It +makes the operations slightly slower, but hotplug is slow anyway. + +This ensures that state is consistent before returning from a hotplug +up/down operation. It's still inconsistent during the operation, but that's +a different story. + +Add a large comment which explains why this is done and why this is not a +dump ground for the hack of the day to work around half thought out locking +schemes. Document also the implications vs. hotplug operations and +serialization or the lack of it. + +Thanks to Alexy and Joshua for analyzing why this temporary +sched_setaffinity() failure happened. + +Fixes: 3a5a6d0c2b03("cpuset: don't nest cgroup_mutex inside get_online_cpus()") +Reported-by: Alexey Klimov +Reported-by: Joshua Baker +Signed-off-by: Thomas Gleixner +Tested-by: Alexey Klimov +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/87tuowcnv3.ffs@nanos.tec.linutronix.de +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/cpu.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 49 insertions(+) + +--- a/kernel/cpu.c ++++ b/kernel/cpu.c +@@ -32,6 +32,7 @@ + #include + #include + #include ++#include + + #include + #define CREATE_TRACE_POINTS +@@ -814,6 +815,52 @@ void __init cpuhp_threads_init(void) + kthread_unpark(this_cpu_read(cpuhp_state.thread)); + } + ++/* ++ * ++ * Serialize hotplug trainwrecks outside of the cpu_hotplug_lock ++ * protected region. ++ * ++ * The operation is still serialized against concurrent CPU hotplug via ++ * cpu_add_remove_lock, i.e. CPU map protection. But it is _not_ ++ * serialized against other hotplug related activity like adding or ++ * removing of state callbacks and state instances, which invoke either the ++ * startup or the teardown callback of the affected state. ++ * ++ * This is required for subsystems which are unfixable vs. CPU hotplug and ++ * evade lock inversion problems by scheduling work which has to be ++ * completed _before_ cpu_up()/_cpu_down() returns. ++ * ++ * Don't even think about adding anything to this for any new code or even ++ * drivers. It's only purpose is to keep existing lock order trainwrecks ++ * working. ++ * ++ * For cpu_down() there might be valid reasons to finish cleanups which are ++ * not required to be done under cpu_hotplug_lock, but that's a different ++ * story and would be not invoked via this. ++ */ ++static void cpu_up_down_serialize_trainwrecks(bool tasks_frozen) ++{ ++ /* ++ * cpusets delegate hotplug operations to a worker to "solve" the ++ * lock order problems. Wait for the worker, but only if tasks are ++ * _not_ frozen (suspend, hibernate) as that would wait forever. ++ * ++ * The wait is required because otherwise the hotplug operation ++ * returns with inconsistent state, which could even be observed in ++ * user space when a new CPU is brought up. The CPU plug uevent ++ * would be delivered and user space reacting on it would fail to ++ * move tasks to the newly plugged CPU up to the point where the ++ * work has finished because up to that point the newly plugged CPU ++ * is not assignable in cpusets/cgroups. On unplug that's not ++ * necessarily a visible issue, but it is still inconsistent state, ++ * which is the real problem which needs to be "fixed". This can't ++ * prevent the transient state between scheduling the work and ++ * returning from waiting for it. ++ */ ++ if (!tasks_frozen) ++ cpuset_wait_for_hotplug(); ++} ++ + #ifdef CONFIG_HOTPLUG_CPU + #ifndef arch_clear_mm_cpumask_cpu + #define arch_clear_mm_cpumask_cpu(cpu, mm) cpumask_clear_cpu(cpu, mm_cpumask(mm)) +@@ -1051,6 +1098,7 @@ out: + */ + lockup_detector_cleanup(); + arch_smt_update(); ++ cpu_up_down_serialize_trainwrecks(tasks_frozen); + return ret; + } + +@@ -1186,6 +1234,7 @@ static int _cpu_up(unsigned int cpu, int + out: + cpus_write_unlock(); + arch_smt_update(); ++ cpu_up_down_serialize_trainwrecks(tasks_frozen); + return ret; + } + diff --git a/queue-5.4/drm-amd-display-fix-incorrrect-valid-irq-check.patch b/queue-5.4/drm-amd-display-fix-incorrrect-valid-irq-check.patch new file mode 100644 index 00000000000..a835d69853d --- /dev/null +++ b/queue-5.4/drm-amd-display-fix-incorrrect-valid-irq-check.patch @@ -0,0 +1,33 @@ +From e38ca7e422791a4d1c01e56dbf7f9982db0ed365 Mon Sep 17 00:00:00 2001 +From: Guchun Chen +Date: Mon, 28 Jun 2021 17:03:48 +0800 +Subject: drm/amd/display: fix incorrrect valid irq check + +From: Guchun Chen + +commit e38ca7e422791a4d1c01e56dbf7f9982db0ed365 upstream. + +valid DAL irq should be < DAL_IRQ_SOURCES_NUMBER. + +Signed-off-by: Guchun Chen +Reviewed-and-tested-by: Evan Quan +Reviewed-by: Harry Wentland +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/display/dc/irq_types.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/display/dc/irq_types.h ++++ b/drivers/gpu/drm/amd/display/dc/irq_types.h +@@ -163,7 +163,7 @@ enum irq_type + }; + + #define DAL_VALID_IRQ_SRC_NUM(src) \ +- ((src) <= DAL_IRQ_SOURCES_NUMBER && (src) > DC_IRQ_SOURCE_INVALID) ++ ((src) < DAL_IRQ_SOURCES_NUMBER && (src) > DC_IRQ_SOURCE_INVALID) + + /* Number of Page Flip IRQ Sources. */ + #define DAL_PFLIP_IRQ_SRC_NUM \ diff --git a/queue-5.4/drm-amd-display-reject-non-zero-src_y-and-src_x-for-video-planes.patch b/queue-5.4/drm-amd-display-reject-non-zero-src_y-and-src_x-for-video-planes.patch new file mode 100644 index 00000000000..f9e9f64d05f --- /dev/null +++ b/queue-5.4/drm-amd-display-reject-non-zero-src_y-and-src_x-for-video-planes.patch @@ -0,0 +1,75 @@ +From c6c6a712199ab355ce333fa5764a59506bb107c1 Mon Sep 17 00:00:00 2001 +From: Harry Wentland +Date: Thu, 22 Apr 2021 19:10:52 -0400 +Subject: drm/amd/display: Reject non-zero src_y and src_x for video planes +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Harry Wentland + +commit c6c6a712199ab355ce333fa5764a59506bb107c1 upstream. + +[Why] +This hasn't been well tested and leads to complete system hangs on DCN1 +based systems, possibly others. + +The system hang can be reproduced by gesturing the video on the YouTube +Android app on ChromeOS into full screen. + +[How] +Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. + +v2: + - Add code comment describing the reason we're rejecting non-zero + src_x and src_y + - Drop gerrit Change-Id + - Add stable CC + - Based on amd-staging-drm-next + +v3: removed trailing whitespace + +Signed-off-by: Harry Wentland +Cc: stable@vger.kernel.org +Cc: nicholas.kazlauskas@amd.com +Cc: amd-gfx@lists.freedesktop.org +Cc: alexander.deucher@amd.com +Cc: Roman.Li@amd.com +Cc: hersenxs.wu@amd.com +Cc: danny.wang@amd.com +Reviewed-by: Nicholas Kazlauskas +Acked-by: Christian König +Reviewed-by: Hersen Wu +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 +++++++++++++++++ + 1 file changed, 17 insertions(+) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -2649,6 +2649,23 @@ static int fill_dc_scaling_info(const st + scaling_info->src_rect.y != 0)) + return -EINVAL; + ++ /* ++ * For reasons we don't (yet) fully understand a non-zero ++ * src_y coordinate into an NV12 buffer can cause a ++ * system hang. To avoid hangs (and maybe be overly cautious) ++ * let's reject both non-zero src_x and src_y. ++ * ++ * We currently know of only one use-case to reproduce a ++ * scenario with non-zero src_x and src_y for NV12, which ++ * is to gesture the YouTube Android app into full screen ++ * on ChromeOS. ++ */ ++ if (state->fb && ++ state->fb->format->format == DRM_FORMAT_NV12 && ++ (scaling_info->src_rect.x != 0 || ++ scaling_info->src_rect.y != 0)) ++ return -EINVAL; ++ + scaling_info->src_rect.width = state->src_w >> 16; + if (scaling_info->src_rect.width == 0) + return -EINVAL; diff --git a/queue-5.4/drm-amdgpu-update-nv-simd-per-cu-to-2.patch b/queue-5.4/drm-amdgpu-update-nv-simd-per-cu-to-2.patch new file mode 100644 index 00000000000..bb5817830b9 --- /dev/null +++ b/queue-5.4/drm-amdgpu-update-nv-simd-per-cu-to-2.patch @@ -0,0 +1,38 @@ +From aa6158112645aae514982ad8d56df64428fcf203 Mon Sep 17 00:00:00 2001 +From: Joseph Greathouse +Date: Tue, 29 Jun 2021 21:08:52 -0500 +Subject: drm/amdgpu: Update NV SIMD-per-CU to 2 + +From: Joseph Greathouse + +commit aa6158112645aae514982ad8d56df64428fcf203 upstream. + +Navi series GPUs have 2 SIMDs per CU (and then 2 CUs per WGP). +The NV enum headers incorrectly listed this as 4, which later meant +we were incorrectly reporting the number of SIMDs in the HSA +topology. This could cause problems down the line for user-space +applications that want to launch a fixed amount of work to each +SIMD. + +Signed-off-by: Joseph Greathouse +Reviewed-by: Alex Deucher +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/include/navi10_enum.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/include/navi10_enum.h ++++ b/drivers/gpu/drm/amd/include/navi10_enum.h +@@ -430,7 +430,7 @@ ARRAY_2D_DEPTH + */ + + typedef enum ENUM_NUM_SIMD_PER_CU { +-NUM_SIMD_PER_CU = 0x00000004, ++NUM_SIMD_PER_CU = 0x00000002, + } ENUM_NUM_SIMD_PER_CU; + + /* diff --git a/queue-5.4/drm-arm-malidp-always-list-modifiers.patch b/queue-5.4/drm-arm-malidp-always-list-modifiers.patch new file mode 100644 index 00000000000..f03a992206c --- /dev/null +++ b/queue-5.4/drm-arm-malidp-always-list-modifiers.patch @@ -0,0 +1,52 @@ +From 26c3e7fd5a3499e408915dadae5d5360790aae9a Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Tue, 27 Apr 2021 11:20:12 +0200 +Subject: drm/arm/malidp: Always list modifiers + +From: Daniel Vetter + +commit 26c3e7fd5a3499e408915dadae5d5360790aae9a upstream. + +Even when all we support is linear, make that explicit. Otherwise the +uapi is rather confusing. + +Acked-by: Liviu Dudau +Acked-by: Pekka Paalanen +Reviewed-by: Lyude Paul +Cc: stable@vger.kernel.org +Cc: Pekka Paalanen +Cc: Liviu Dudau +Cc: Brian Starkey +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-2-daniel.vetter@ffwll.ch +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/arm/malidp_planes.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/arm/malidp_planes.c ++++ b/drivers/gpu/drm/arm/malidp_planes.c +@@ -922,6 +922,11 @@ static const struct drm_plane_helper_fun + .atomic_disable = malidp_de_plane_disable, + }; + ++static const uint64_t linear_only_modifiers[] = { ++ DRM_FORMAT_MOD_LINEAR, ++ DRM_FORMAT_MOD_INVALID ++}; ++ + int malidp_de_planes_init(struct drm_device *drm) + { + struct malidp_drm *malidp = drm->dev_private; +@@ -985,8 +990,8 @@ int malidp_de_planes_init(struct drm_dev + */ + ret = drm_universal_plane_init(drm, &plane->base, crtcs, + &malidp_de_plane_funcs, formats, n, +- (id == DE_SMART) ? NULL : modifiers, plane_type, +- NULL); ++ (id == DE_SMART) ? linear_only_modifiers : modifiers, ++ plane_type, NULL); + + if (ret < 0) + goto cleanup; diff --git a/queue-5.4/drm-msm-mdp4-fix-modifier-support-enabling.patch b/queue-5.4/drm-msm-mdp4-fix-modifier-support-enabling.patch new file mode 100644 index 00000000000..5fed146cac0 --- /dev/null +++ b/queue-5.4/drm-msm-mdp4-fix-modifier-support-enabling.patch @@ -0,0 +1,67 @@ +From 35cbb8c91e9cf310277d3dfb4d046df8edf2df33 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Tue, 27 Apr 2021 11:20:15 +0200 +Subject: drm/msm/mdp4: Fix modifier support enabling + +From: Daniel Vetter + +commit 35cbb8c91e9cf310277d3dfb4d046df8edf2df33 upstream. + +Setting the cap without the modifier list is very confusing to +userspace. Fix that by listing the ones we support explicitly. + +Stable backport so that userspace can rely on this working in a +reasonable way, i.e. that the cap set implies IN_FORMATS is available. + +Acked-by: Pekka Paalanen +Reviewed-by: Lyude Paul +Cc: stable@vger.kernel.org +Cc: Pekka Paalanen +Cc: Rob Clark +Cc: Jordan Crouse +Cc: Emil Velikov +Cc: Sam Ravnborg +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-5-daniel.vetter@ffwll.ch +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 -- + drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 8 +++++++- + 2 files changed, 7 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c ++++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c +@@ -88,8 +88,6 @@ static int mdp4_hw_init(struct msm_kms * + if (mdp4_kms->rev > 1) + mdp4_write(mdp4_kms, REG_MDP4_RESET_STATUS, 1); + +- dev->mode_config.allow_fb_modifiers = true; +- + out: + pm_runtime_put_sync(dev->dev); + +--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c ++++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c +@@ -347,6 +347,12 @@ enum mdp4_pipe mdp4_plane_pipe(struct dr + return mdp4_plane->pipe; + } + ++static const uint64_t supported_format_modifiers[] = { ++ DRM_FORMAT_MOD_SAMSUNG_64_32_TILE, ++ DRM_FORMAT_MOD_LINEAR, ++ DRM_FORMAT_MOD_INVALID ++}; ++ + /* initialize plane */ + struct drm_plane *mdp4_plane_init(struct drm_device *dev, + enum mdp4_pipe pipe_id, bool private_plane) +@@ -375,7 +381,7 @@ struct drm_plane *mdp4_plane_init(struct + type = private_plane ? DRM_PLANE_TYPE_PRIMARY : DRM_PLANE_TYPE_OVERLAY; + ret = drm_universal_plane_init(dev, plane, 0xff, &mdp4_plane_funcs, + mdp4_plane->formats, mdp4_plane->nformats, +- NULL, type, NULL); ++ supported_format_modifiers, type, NULL); + if (ret) + goto fail; + diff --git a/queue-5.4/drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch b/queue-5.4/drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch new file mode 100644 index 00000000000..787b85a3787 --- /dev/null +++ b/queue-5.4/drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch @@ -0,0 +1,35 @@ +From 9ba85914c36c8fed9bf3e8b69c0782908c1247b7 Mon Sep 17 00:00:00 2001 +From: Jing Xiangfeng +Date: Tue, 29 Jun 2021 19:44:55 +0800 +Subject: drm/radeon: Add the missed drm_gem_object_put() in radeon_user_framebuffer_create() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jing Xiangfeng + +commit 9ba85914c36c8fed9bf3e8b69c0782908c1247b7 upstream. + +radeon_user_framebuffer_create() misses to call drm_gem_object_put() in +an error path. Add the missed function call to fix it. + +Reviewed-by: Christian König +Signed-off-by: Jing Xiangfeng +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_display.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/radeon/radeon_display.c ++++ b/drivers/gpu/drm/radeon/radeon_display.c +@@ -1333,6 +1333,7 @@ radeon_user_framebuffer_create(struct dr + /* Handle is imported dma-buf, so cannot be migrated to VRAM for scanout */ + if (obj->import_attach) { + DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n"); ++ drm_gem_object_put(obj); + return ERR_PTR(-EINVAL); + } + diff --git a/queue-5.4/drm-rockchip-dsi-remove-extra-component_del-call.patch b/queue-5.4/drm-rockchip-dsi-remove-extra-component_del-call.patch new file mode 100644 index 00000000000..4e4a25ffe7f --- /dev/null +++ b/queue-5.4/drm-rockchip-dsi-remove-extra-component_del-call.patch @@ -0,0 +1,55 @@ +From b354498bbe65c917d521b3b56317ddc9ab217425 Mon Sep 17 00:00:00 2001 +From: Thomas Hebb +Date: Sun, 18 Apr 2021 19:03:04 -0700 +Subject: drm/rockchip: dsi: remove extra component_del() call + +From: Thomas Hebb + +commit b354498bbe65c917d521b3b56317ddc9ab217425 upstream. + +commit cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support") added +this devcnt field and call to component_del(). However, these both +appear to be erroneous changes left over from an earlier version of the +patch. In the version merged, nothing ever modifies devcnt, meaning +component_del() runs unconditionally and in addition to the +component_del() calls in dw_mipi_dsi_rockchip_host_detach(). The second +call fails to delete anything and produces a warning in dmesg. + +If we look at the previous version of the patch[1], however, we see that +it had logic to calculate devcnt and call component_add() in certain +situations. This was removed in v6, and the fact that the deletion code +was not appears to have been an oversight. + +[1] https://patchwork.kernel.org/project/dri-devel/patch/20180821140515.22246-8-heiko@sntech.de/ + +Fixes: cf6d100dd238 ("drm/rockchip: dsi: add dual mipi support") +Cc: stable@vger.kernel.org +Signed-off-by: Thomas Hebb +Signed-off-by: Heiko Stuebner +Link: https://patchwork.freedesktop.org/patch/msgid/201385acb0eeb5dfb037afdc6a94bfbcdab97f99.1618797778.git.tommyhebb@gmail.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c ++++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c +@@ -231,7 +231,6 @@ struct dw_mipi_dsi_rockchip { + struct dw_mipi_dsi *dmd; + const struct rockchip_dw_dsi_chip_data *cdata; + struct dw_mipi_dsi_plat_data pdata; +- int devcnt; + }; + + struct dphy_pll_parameter_map { +@@ -1001,9 +1000,6 @@ static int dw_mipi_dsi_rockchip_remove(s + { + struct dw_mipi_dsi_rockchip *dsi = platform_get_drvdata(pdev); + +- if (dsi->devcnt == 0) +- component_del(dsi->dev, &dw_mipi_dsi_rockchip_ops); +- + dw_mipi_dsi_remove(dsi->dmd); + + return 0; diff --git a/queue-5.4/drm-tegra-don-t-set-allow_fb_modifiers-explicitly.patch b/queue-5.4/drm-tegra-don-t-set-allow_fb_modifiers-explicitly.patch new file mode 100644 index 00000000000..7d8eb0c32fd --- /dev/null +++ b/queue-5.4/drm-tegra-don-t-set-allow_fb_modifiers-explicitly.patch @@ -0,0 +1,84 @@ +From be4306ad928fcf736cbe2616b6dd19d91f1bc083 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Tue, 13 Apr 2021 11:49:01 +0200 +Subject: drm/tegra: Don't set allow_fb_modifiers explicitly + +From: Daniel Vetter + +commit be4306ad928fcf736cbe2616b6dd19d91f1bc083 upstream. + +Since + +commit 890880ddfdbe256083170866e49c87618b706ac7 +Author: Paul Kocialkowski +Date: Fri Jan 4 09:56:10 2019 +0100 + + drm: Auto-set allow_fb_modifiers when given modifiers at plane init + +this is done automatically as part of plane init, if drivers set the +modifier list correctly. Which is the case here. + +It was slightly inconsistently though, since planes with only linear +modifier support haven't listed that explicitly. Fix that, and cc: +stable to allow userspace to rely on this. Again don't backport +further than where Paul's patch got added. + +Cc: stable@vger.kernel.org # v5.1 + +Cc: Pekka Paalanen +Acked-by: Thierry Reding +Signed-off-by: Daniel Vetter +Cc: Thierry Reding +Cc: Jonathan Hunter +Cc: linux-tegra@vger.kernel.org +Link: https://patchwork.freedesktop.org/patch/msgid/20210413094904.3736372-10-daniel.vetter@ffwll.ch +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/tegra/dc.c | 10 ++++++++-- + drivers/gpu/drm/tegra/drm.c | 2 -- + 2 files changed, 8 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/tegra/dc.c ++++ b/drivers/gpu/drm/tegra/dc.c +@@ -919,6 +919,11 @@ static const struct drm_plane_helper_fun + .atomic_disable = tegra_cursor_atomic_disable, + }; + ++static const uint64_t linear_modifiers[] = { ++ DRM_FORMAT_MOD_LINEAR, ++ DRM_FORMAT_MOD_INVALID ++}; ++ + static struct drm_plane *tegra_dc_cursor_plane_create(struct drm_device *drm, + struct tegra_dc *dc) + { +@@ -947,7 +952,7 @@ static struct drm_plane *tegra_dc_cursor + + err = drm_universal_plane_init(drm, &plane->base, possible_crtcs, + &tegra_plane_funcs, formats, +- num_formats, NULL, ++ num_formats, linear_modifiers, + DRM_PLANE_TYPE_CURSOR, NULL); + if (err < 0) { + kfree(plane); +@@ -1065,7 +1070,8 @@ static struct drm_plane *tegra_dc_overla + + err = drm_universal_plane_init(drm, &plane->base, possible_crtcs, + &tegra_plane_funcs, formats, +- num_formats, NULL, type, NULL); ++ num_formats, linear_modifiers, ++ type, NULL); + if (err < 0) { + kfree(plane); + return ERR_PTR(err); +--- a/drivers/gpu/drm/tegra/drm.c ++++ b/drivers/gpu/drm/tegra/drm.c +@@ -122,8 +122,6 @@ static int tegra_drm_load(struct drm_dev + drm->mode_config.max_width = 4096; + drm->mode_config.max_height = 4096; + +- drm->mode_config.allow_fb_modifiers = true; +- + drm->mode_config.normalize_zpos = true; + + drm->mode_config.funcs = &tegra_drm_mode_config_funcs; diff --git a/queue-5.4/fpga-stratix10-soc-add-missing-fpga_mgr_free-call.patch b/queue-5.4/fpga-stratix10-soc-add-missing-fpga_mgr_free-call.patch new file mode 100644 index 00000000000..52d3a8b4f96 --- /dev/null +++ b/queue-5.4/fpga-stratix10-soc-add-missing-fpga_mgr_free-call.patch @@ -0,0 +1,35 @@ +From d9ec9daa20eb8de1efe6abae78c9835ec8ed86f9 Mon Sep 17 00:00:00 2001 +From: Russ Weight +Date: Mon, 14 Jun 2021 10:09:03 -0700 +Subject: fpga: stratix10-soc: Add missing fpga_mgr_free() call + +From: Russ Weight + +commit d9ec9daa20eb8de1efe6abae78c9835ec8ed86f9 upstream. + +The stratix10-soc driver uses fpga_mgr_create() function and is therefore +responsible to call fpga_mgr_free() to release the class driver resources. +Add a missing call to fpga_mgr_free in the s10_remove() function. + +Signed-off-by: Russ Weight +Reviewed-by: Xu Yilun +Signed-off-by: Moritz Fischer +Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver") +Cc: stable +Link: https://lore.kernel.org/r/20210614170909.232415-3-mdf@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/fpga/stratix10-soc.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/fpga/stratix10-soc.c ++++ b/drivers/fpga/stratix10-soc.c +@@ -476,6 +476,7 @@ static int s10_remove(struct platform_de + struct s10_priv *priv = mgr->priv; + + fpga_mgr_unregister(mgr); ++ fpga_mgr_free(mgr); + stratix10_svc_free_channel(priv->chan); + + return 0; diff --git a/queue-5.4/mmc-core-allow-uhs-i-voltage-switch-for-sdsc-cards-if-supported.patch b/queue-5.4/mmc-core-allow-uhs-i-voltage-switch-for-sdsc-cards-if-supported.patch new file mode 100644 index 00000000000..6da0d392d60 --- /dev/null +++ b/queue-5.4/mmc-core-allow-uhs-i-voltage-switch-for-sdsc-cards-if-supported.patch @@ -0,0 +1,57 @@ +From 09247e110b2efce3a104e57e887c373e0a57a412 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20L=C3=B6hle?= +Date: Wed, 12 May 2021 16:03:24 +0000 +Subject: mmc: core: Allow UHS-I voltage switch for SDSC cards if supported + +From: Christian Löhle + +commit 09247e110b2efce3a104e57e887c373e0a57a412 upstream. + +While initializing an UHS-I SD card, the mmc core first tries to switch to +1.8V I/O voltage, before it continues to change the settings for the bus +speed mode. + +However, the current behaviour in the mmc core is inconsistent and doesn't +conform to the SD spec. More precisely, an SD card that supports UHS-I must +set both the SD_OCR_CCS bit and the SD_OCR_S18R bit in the OCR register +response. When switching to 1.8V I/O the mmc core correctly checks both of +the bits, but only the SD_OCR_S18R bit when changing the settings for bus +speed mode. + +Rather than actually fixing the code to confirm to the SD spec, let's +deliberately deviate from it by requiring only the SD_OCR_S18R bit for both +parts. This enables us to support UHS-I for SDSC cards (outside spec), +which is actually being supported by some existing SDSC cards. Moreover, +this fixes the inconsistent behaviour. + +Signed-off-by: Christian Loehle +Link: https://lore.kernel.org/r/CWXP265MB26803AE79E0AD5ED083BF2A6C4529@CWXP265MB2680.GBRP265.PROD.OUTLOOK.COM +Cc: stable@vger.kernel.org +[Ulf: Rewrote commit message and comments to clarify the changes] +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/sd.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/drivers/mmc/core/sd.c ++++ b/drivers/mmc/core/sd.c +@@ -793,11 +793,13 @@ try_again: + return err; + + /* +- * In case CCS and S18A in the response is set, start Signal Voltage +- * Switch procedure. SPI mode doesn't support CMD11. ++ * In case the S18A bit is set in the response, let's start the signal ++ * voltage switch procedure. SPI mode doesn't support CMD11. ++ * Note that, according to the spec, the S18A bit is not valid unless ++ * the CCS bit is set as well. We deliberately deviate from the spec in ++ * regards to this, which allows UHS-I to be supported for SDSC cards. + */ +- if (!mmc_host_is_spi(host) && rocr && +- ((*rocr & 0x41000000) == 0x41000000)) { ++ if (!mmc_host_is_spi(host) && rocr && (*rocr & 0x01000000)) { + err = mmc_set_uhs_voltage(host, pocr); + if (err == -EAGAIN) { + retries--; diff --git a/queue-5.4/mmc-core-clear-flags-before-allowing-to-retune.patch b/queue-5.4/mmc-core-clear-flags-before-allowing-to-retune.patch new file mode 100644 index 00000000000..1165d9c427c --- /dev/null +++ b/queue-5.4/mmc-core-clear-flags-before-allowing-to-retune.patch @@ -0,0 +1,56 @@ +From 77347eda64ed5c9383961d1de9165f9d0b7d8df6 Mon Sep 17 00:00:00 2001 +From: Wolfram Sang +Date: Thu, 24 Jun 2021 17:16:14 +0200 +Subject: mmc: core: clear flags before allowing to retune + +From: Wolfram Sang + +commit 77347eda64ed5c9383961d1de9165f9d0b7d8df6 upstream. + +It might be that something goes wrong during tuning so the MMC core will +immediately trigger a retune. In our case it was: + + - we sent a tuning block + - there was an error so we need to send an abort cmd to the eMMC + - the abort cmd had a CRC error + - retune was set by the MMC core + +This lead to a vicious circle causing a performance regression of 75%. +So, clear retuning flags before we enable retuning to start with a known +cleared state. + +Reported-by Yoshihiro Shimoda +Suggested-by: Adrian Hunter +Signed-off-by: Wolfram Sang +Acked-by: Adrian Hunter +Reviewed-by: Yoshihiro Shimoda +Tested-by: Yoshihiro Shimoda +Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210624151616.38770-2-wsa+renesas@sang-engineering.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/core.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/core/core.c ++++ b/drivers/mmc/core/core.c +@@ -953,11 +953,14 @@ int mmc_execute_tuning(struct mmc_card * + + err = host->ops->execute_tuning(host, opcode); + +- if (err) ++ if (err) { + pr_err("%s: tuning execution failed: %d\n", + mmc_hostname(host), err); +- else ++ } else { ++ host->retune_now = 0; ++ host->need_retune = 0; + mmc_retune_enable(host); ++ } + + return err; + } diff --git a/queue-5.4/mmc-sdhci-fix-warning-message-when-accessing-rpmb-in-hs400-mode.patch b/queue-5.4/mmc-sdhci-fix-warning-message-when-accessing-rpmb-in-hs400-mode.patch new file mode 100644 index 00000000000..e58bc4b81a3 --- /dev/null +++ b/queue-5.4/mmc-sdhci-fix-warning-message-when-accessing-rpmb-in-hs400-mode.patch @@ -0,0 +1,61 @@ +From d0244847f9fc5e20df8b7483c8a4717fe0432d38 Mon Sep 17 00:00:00 2001 +From: Al Cooper +Date: Thu, 24 Jun 2021 12:30:45 -0400 +Subject: mmc: sdhci: Fix warning message when accessing RPMB in HS400 mode + +From: Al Cooper + +commit d0244847f9fc5e20df8b7483c8a4717fe0432d38 upstream. + +When an eMMC device is being run in HS400 mode, any access to the +RPMB device will cause the error message "mmc1: Invalid UHS-I mode +selected". This happens as a result of tuning being disabled before +RPMB access and then re-enabled after the RPMB access is complete. +When tuning is re-enabled, the system has to switch from HS400 +to HS200 to do the tuning and then back to HS400. As part of +sequence to switch from HS400 to HS200 the system is temporarily +put into HS mode. When switching to HS mode, sdhci_get_preset_value() +is called and does not have support for HS mode and prints the warning +message and returns the preset for SDR12. The fix is to add support +for MMC and SD HS modes to sdhci_get_preset_value(). + +This can be reproduced on any system running eMMC in HS400 mode +(not HS400ES) by using the "mmc" utility to run the following +command: "mmc rpmb read-counter /dev/mmcblk0rpmb". + +Signed-off-by: Al Cooper +Acked-by: Adrian Hunter +Fixes: 52983382c74f ("mmc: sdhci: enhance preset value function") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210624163045.33651-1-alcooperx@gmail.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci.c | 4 ++++ + drivers/mmc/host/sdhci.h | 1 + + 2 files changed, 5 insertions(+) + +--- a/drivers/mmc/host/sdhci.c ++++ b/drivers/mmc/host/sdhci.c +@@ -1511,6 +1511,10 @@ static u16 sdhci_get_preset_value(struct + u16 preset = 0; + + switch (host->timing) { ++ case MMC_TIMING_MMC_HS: ++ case MMC_TIMING_SD_HS: ++ preset = sdhci_readw(host, SDHCI_PRESET_FOR_HIGH_SPEED); ++ break; + case MMC_TIMING_UHS_SDR12: + preset = sdhci_readw(host, SDHCI_PRESET_FOR_SDR12); + break; +--- a/drivers/mmc/host/sdhci.h ++++ b/drivers/mmc/host/sdhci.h +@@ -261,6 +261,7 @@ + + /* 60-FB reserved */ + ++#define SDHCI_PRESET_FOR_HIGH_SPEED 0x64 + #define SDHCI_PRESET_FOR_SDR12 0x66 + #define SDHCI_PRESET_FOR_SDR25 0x68 + #define SDHCI_PRESET_FOR_SDR50 0x6A diff --git a/queue-5.4/pinctrl-amd-add-device-hid-for-new-amd-gpio-controller.patch b/queue-5.4/pinctrl-amd-add-device-hid-for-new-amd-gpio-controller.patch new file mode 100644 index 00000000000..fc8c8f681eb --- /dev/null +++ b/queue-5.4/pinctrl-amd-add-device-hid-for-new-amd-gpio-controller.patch @@ -0,0 +1,34 @@ +From 1ca46d3e43569186bd1decfb02a6b4c4ddb4304b Mon Sep 17 00:00:00 2001 +From: Maximilian Luz +Date: Wed, 12 May 2021 23:03:16 +0200 +Subject: pinctrl/amd: Add device HID for new AMD GPIO controller + +From: Maximilian Luz + +commit 1ca46d3e43569186bd1decfb02a6b4c4ddb4304b upstream. + +Add device HID AMDI0031 to the AMD GPIO controller driver match table. +This controller can be found on Microsoft Surface Laptop 4 devices and +seems similar enough that we can just copy the existing AMDI0030 entry. + +Cc: # 5.10+ +Tested-by: Sachi King +Signed-off-by: Maximilian Luz +Link: https://lore.kernel.org/r/20210512210316.1982416-1-luzmaximilian@gmail.com +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pinctrl/pinctrl-amd.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/pinctrl/pinctrl-amd.c ++++ b/drivers/pinctrl/pinctrl-amd.c +@@ -958,6 +958,7 @@ static int amd_gpio_remove(struct platfo + static const struct acpi_device_id amd_gpio_acpi_match[] = { + { "AMD0030", 0 }, + { "AMDI0030", 0}, ++ { "AMDI0031", 0}, + { }, + }; + MODULE_DEVICE_TABLE(acpi, amd_gpio_acpi_match); diff --git a/queue-5.4/series b/queue-5.4/series index cb14e4991e9..02b7ad0d349 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -74,3 +74,19 @@ crypto-ccp-annotate-sev-firmware-file-names.patch perf-bench-fix-2-memory-sanitizer-warnings.patch powerpc-mm-fix-lockup-on-kernel-exec-fault.patch powerpc-barrier-avoid-collision-with-clang-s-__lwsync-macro.patch +drm-amdgpu-update-nv-simd-per-cu-to-2.patch +drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch +drm-rockchip-dsi-remove-extra-component_del-call.patch +drm-amd-display-fix-incorrrect-valid-irq-check.patch +pinctrl-amd-add-device-hid-for-new-amd-gpio-controller.patch +drm-amd-display-reject-non-zero-src_y-and-src_x-for-video-planes.patch +drm-tegra-don-t-set-allow_fb_modifiers-explicitly.patch +drm-msm-mdp4-fix-modifier-support-enabling.patch +drm-arm-malidp-always-list-modifiers.patch +mmc-sdhci-fix-warning-message-when-accessing-rpmb-in-hs400-mode.patch +mmc-core-clear-flags-before-allowing-to-retune.patch +mmc-core-allow-uhs-i-voltage-switch-for-sdsc-cards-if-supported.patch +ata-ahci_sunxi-disable-dipm.patch +cpu-hotplug-cure-the-cpusets-trainwreck.patch +clocksource-arm_arch_timer-improve-allwinner-a64-timer-workaround.patch +fpga-stratix10-soc-add-missing-fpga_mgr_free-call.patch