From: Greg Kroah-Hartman Date: Thu, 15 Jul 2021 12:40:30 +0000 (+0200) Subject: 5.12-stable patches X-Git-Tag: v5.4.133~38 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e3fb5ce61eb98edbad1d58747a6690ee3d80165b;p=thirdparty%2Fkernel%2Fstable-queue.git 5.12-stable patches added patches: arm64-tlb-fix-the-ttl-value-of-tlb_get_level.patch ata-ahci_sunxi-disable-dipm.patch clocksource-arm_arch_timer-improve-allwinner-a64-timer-workaround.patch cpu-hotplug-cure-the-cpusets-trainwreck.patch docs-makefile-use-config_shell-not-shell.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-add-new-dimgrey-cavefish-did.patch drm-amdgpu-enable-sdma0-tmz-for-raven-renoir-v2.patch drm-amdgpu-fix-nak-g-generation-during-pci-e-link-width-switch.patch drm-amdgpu-fix-the-hang-caused-by-pcie-link-width-switch.patch drm-amdgpu-update-nv-simd-per-cu-to-2.patch drm-arm-malidp-always-list-modifiers.patch drm-dp-handle-zeroed-port-counts-in-drm_dp_read_downstream_info.patch drm-dp_mst-do-not-set-proposed-vcpi-directly.patch drm-i915-display-do-not-zero-past-infoframes.vsc.patch drm-ingenic-fix-pixclock-rate-for-24-bit-serial-panels.patch drm-ingenic-switch-ipu-plane-to-type-overlay.patch drm-msm-mdp4-fix-modifier-support-enabling.patch drm-nouveau-don-t-set-allow_fb_modifiers-explicitly.patch drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch drm-radeon-call-radeon_suspend_kms-in-radeon_pci_shutdown-for-loongson64.patch drm-rockchip-dsi-remove-extra-component_del-call.patch drm-tegra-don-t-set-allow_fb_modifiers-explicitly.patch drm-vc4-crtc-skip-the-txp.patch drm-vc4-hdmi-prevent-clock-unbalance.patch drm-vc4-txp-properly-set-the-possible_crtcs-mask.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-acpi-disable-write-protect-detection-on-toshiba-encore-2-wt8-b.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.12/arm64-tlb-fix-the-ttl-value-of-tlb_get_level.patch b/queue-5.12/arm64-tlb-fix-the-ttl-value-of-tlb_get_level.patch new file mode 100644 index 00000000000..ac8634ab346 --- /dev/null +++ b/queue-5.12/arm64-tlb-fix-the-ttl-value-of-tlb_get_level.patch @@ -0,0 +1,54 @@ +From 52218fcd61cb42bde0d301db4acb3ffdf3463cc7 Mon Sep 17 00:00:00 2001 +From: Zhenyu Ye +Date: Wed, 23 Jun 2021 15:05:22 +0800 +Subject: arm64: tlb: fix the TTL value of tlb_get_level + +From: Zhenyu Ye + +commit 52218fcd61cb42bde0d301db4acb3ffdf3463cc7 upstream. + +The TTL field indicates the level of page table walk holding the *leaf* +entry for the address being invalidated. But currently, the TTL field +may be set to an incorrent value in the following stack: + +pte_free_tlb + __pte_free_tlb + tlb_remove_table + tlb_table_invalidate + tlb_flush_mmu_tlbonly + tlb_flush + +In this case, we just want to flush a PTE page, but the tlb->cleared_pmds +is set and we get tlb_level = 2 in the tlb_get_level() function. This may +cause some unexpected problems. + +This patch set the TTL field to 0 if tlb->freed_tables is set. The +tlb->freed_tables indicates page table pages are freed, not the leaf +entry. + +Cc: # 5.9.x +Fixes: c4ab2cbc1d87 ("arm64: tlb: Set the TTL field in flush_tlb_range") +Acked-by: Catalin Marinas +Reported-by: ZhuRui +Signed-off-by: Zhenyu Ye +Link: https://lore.kernel.org/r/b80ead47-1f88-3a00-18e1-cacc22f54cc4@huawei.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/include/asm/tlb.h | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/arm64/include/asm/tlb.h ++++ b/arch/arm64/include/asm/tlb.h +@@ -28,6 +28,10 @@ static void tlb_flush(struct mmu_gather + */ + static inline int tlb_get_level(struct mmu_gather *tlb) + { ++ /* The TTL field is only valid for the leaf entry. */ ++ if (tlb->freed_tables) ++ return 0; ++ + if (tlb->cleared_ptes && !(tlb->cleared_pmds || + tlb->cleared_puds || + tlb->cleared_p4ds)) diff --git a/queue-5.12/ata-ahci_sunxi-disable-dipm.patch b/queue-5.12/ata-ahci_sunxi-disable-dipm.patch new file mode 100644 index 00000000000..fcc827c0f07 --- /dev/null +++ b/queue-5.12/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.12/clocksource-arm_arch_timer-improve-allwinner-a64-timer-workaround.patch b/queue-5.12/clocksource-arm_arch_timer-improve-allwinner-a64-timer-workaround.patch new file mode 100644 index 00000000000..a9da49d42a8 --- /dev/null +++ b/queue-5.12/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 +@@ -352,7 +352,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.12/cpu-hotplug-cure-the-cpusets-trainwreck.patch b/queue-5.12/cpu-hotplug-cure-the-cpusets-trainwreck.patch new file mode 100644 index 00000000000..04fb5e4b907 --- /dev/null +++ b/queue-5.12/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 +@@ -821,6 +822,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)) +@@ -1058,6 +1105,7 @@ out: + */ + lockup_detector_cleanup(); + arch_smt_update(); ++ cpu_up_down_serialize_trainwrecks(tasks_frozen); + return ret; + } + +@@ -1254,6 +1302,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.12/docs-makefile-use-config_shell-not-shell.patch b/queue-5.12/docs-makefile-use-config_shell-not-shell.patch new file mode 100644 index 00000000000..ad556965c12 --- /dev/null +++ b/queue-5.12/docs-makefile-use-config_shell-not-shell.patch @@ -0,0 +1,35 @@ +From 222a28edce38b62074a950fb243df621c602b4d3 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Thu, 17 Jun 2021 15:58:08 -0700 +Subject: docs: Makefile: Use CONFIG_SHELL not SHELL + +From: Kees Cook + +commit 222a28edce38b62074a950fb243df621c602b4d3 upstream. + +Fix think-o about which variable to find the Kbuild-configured shell. +This has accidentally worked due to most shells setting $SHELL by +default. + +Fixes: 51e46c7a4007 ("docs, parallelism: Rearrange how jobserver reservations are made") +Cc: stable@vger.kernel.org +Signed-off-by: Kees Cook +Link: https://lore.kernel.org/r/20210617225808.3907377-1-keescook@chromium.org +Signed-off-by: Jonathan Corbet +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/Makefile | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/Documentation/Makefile ++++ b/Documentation/Makefile +@@ -76,7 +76,7 @@ quiet_cmd_sphinx = SPHINX $@ --> file:/ + PYTHONDONTWRITEBYTECODE=1 \ + BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \ + $(PYTHON3) $(srctree)/scripts/jobserver-exec \ +- $(SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \ ++ $(CONFIG_SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \ + $(SPHINXBUILD) \ + -b $2 \ + -c $(abspath $(srctree)/$(src)) \ diff --git a/queue-5.12/drm-amd-display-fix-incorrrect-valid-irq-check.patch b/queue-5.12/drm-amd-display-fix-incorrrect-valid-irq-check.patch new file mode 100644 index 00000000000..c029bf0d677 --- /dev/null +++ b/queue-5.12/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 +@@ -164,7 +164,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.12/drm-amd-display-reject-non-zero-src_y-and-src_x-for-video-planes.patch b/queue-5.12/drm-amd-display-reject-non-zero-src_y-and-src_x-for-video-planes.patch new file mode 100644 index 00000000000..26b7f34318a --- /dev/null +++ b/queue-5.12/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 +@@ -3884,6 +3884,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.12/drm-amdgpu-add-new-dimgrey-cavefish-did.patch b/queue-5.12/drm-amdgpu-add-new-dimgrey-cavefish-did.patch new file mode 100644 index 00000000000..70163651ec2 --- /dev/null +++ b/queue-5.12/drm-amdgpu-add-new-dimgrey-cavefish-did.patch @@ -0,0 +1,30 @@ +From 06ac9b6c736ac9da600b1782d7ac6d6e746286c4 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 28 Jun 2021 15:56:01 -0400 +Subject: drm/amdgpu: add new dimgrey cavefish DID + +From: Alex Deucher + +commit 06ac9b6c736ac9da600b1782d7ac6d6e746286c4 upstream. + +Add new PCI device id. + +Reviewed-by: Guchun Chen +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +@@ -1123,6 +1123,7 @@ static const struct pci_device_id pciidl + {0x1002, 0x73E0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH}, + {0x1002, 0x73E1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH}, + {0x1002, 0x73E2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH}, ++ {0x1002, 0x73E3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH}, + {0x1002, 0x73FF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH}, + + {0, 0, 0} diff --git a/queue-5.12/drm-amdgpu-enable-sdma0-tmz-for-raven-renoir-v2.patch b/queue-5.12/drm-amdgpu-enable-sdma0-tmz-for-raven-renoir-v2.patch new file mode 100644 index 00000000000..227b540e5be --- /dev/null +++ b/queue-5.12/drm-amdgpu-enable-sdma0-tmz-for-raven-renoir-v2.patch @@ -0,0 +1,45 @@ +From e2329e74a615cc58b25c42b7aa1477a5e3f6a435 Mon Sep 17 00:00:00 2001 +From: Aaron Liu +Date: Fri, 25 Jun 2021 13:50:19 +0800 +Subject: drm/amdgpu: enable sdma0 tmz for Raven/Renoir(V2) + +From: Aaron Liu + +commit e2329e74a615cc58b25c42b7aa1477a5e3f6a435 upstream. + +Without driver loaded, SDMA0_UTCL1_PAGE.TMZ_ENABLE is set to 1 +by default for all asic. On Raven/Renoir, the sdma goldsetting +changes SDMA0_UTCL1_PAGE.TMZ_ENABLE to 0. +This patch restores SDMA0_UTCL1_PAGE.TMZ_ENABLE to 1. + +Signed-off-by: Aaron Liu +Acked-by: Luben Tuikov +Acked-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c +@@ -142,7 +142,7 @@ static const struct soc15_reg_golden gol + SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC0_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000), + SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_IB_CNTL, 0x800f0111, 0x00000100), + SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000), +- SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x000003ff, 0x000003c0), ++ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x000003ff, 0x000003e0), + SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_WATERMK, 0xfc000000, 0x00000000) + }; + +@@ -268,7 +268,7 @@ static const struct soc15_reg_golden gol + SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_POWER_CNTL, 0x003fff07, 0x40000051), + SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC0_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000), + SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_RB_WPTR_POLL_CNTL, 0xfffffff7, 0x00403000), +- SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x000003ff, 0x000003c0), ++ SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x000003ff, 0x000003e0), + SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_WATERMK, 0xfc000000, 0x03fbe1fe) + }; + diff --git a/queue-5.12/drm-amdgpu-fix-nak-g-generation-during-pci-e-link-width-switch.patch b/queue-5.12/drm-amdgpu-fix-nak-g-generation-during-pci-e-link-width-switch.patch new file mode 100644 index 00000000000..d2bf48c8891 --- /dev/null +++ b/queue-5.12/drm-amdgpu-fix-nak-g-generation-during-pci-e-link-width-switch.patch @@ -0,0 +1,96 @@ +From 5a5da8ae9546031e43efd4fa5aa8baa481e83dfb Mon Sep 17 00:00:00 2001 +From: Evan Quan +Date: Tue, 25 May 2021 12:08:53 +0800 +Subject: drm/amdgpu: fix NAK-G generation during PCI-e link width switch + +From: Evan Quan + +commit 5a5da8ae9546031e43efd4fa5aa8baa481e83dfb upstream. + +A lot of NAK-G being generated when link widht switching is happening. +WA for this issue is to program the SPC to 4 symbols per clock during +bootup when the native PCIE width is x4. + +Signed-off-by: Evan Quan +Reviewed-by: Lijo Lazar +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h | 1 + + drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 28 ++++++++++++++++++++++++++++ + drivers/gpu/drm/amd/amdgpu/nv.c | 3 +++ + 3 files changed, 32 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h +@@ -89,6 +89,7 @@ struct amdgpu_nbio_funcs { + void (*enable_aspm)(struct amdgpu_device *adev, + bool enable); + void (*program_aspm)(struct amdgpu_device *adev); ++ void (*apply_lc_spc_mode_wa)(struct amdgpu_device *adev); + }; + + struct amdgpu_nbio { +--- a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c ++++ b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c +@@ -51,6 +51,8 @@ + #define mmBIF_MMSCH1_DOORBELL_RANGE 0x01d8 + #define mmBIF_MMSCH1_DOORBELL_RANGE_BASE_IDX 2 + ++#define smnPCIE_LC_LINK_WIDTH_CNTL 0x11140288 ++ + static void nbio_v2_3_remap_hdp_registers(struct amdgpu_device *adev) + { + WREG32_SOC15(NBIO, 0, mmREMAP_HDP_MEM_FLUSH_CNTL, +@@ -463,6 +465,31 @@ static void nbio_v2_3_program_aspm(struc + WREG32_PCIE(smnPCIE_LC_CNTL3, data); + } + ++static void nbio_v2_3_apply_lc_spc_mode_wa(struct amdgpu_device *adev) ++{ ++ uint32_t reg_data = 0; ++ uint32_t link_width = 0; ++ ++ if (!((adev->asic_type >= CHIP_NAVI10) && ++ (adev->asic_type <= CHIP_NAVI12))) ++ return; ++ ++ reg_data = RREG32_PCIE(smnPCIE_LC_LINK_WIDTH_CNTL); ++ link_width = (reg_data & PCIE_LC_LINK_WIDTH_CNTL__LC_LINK_WIDTH_RD_MASK) ++ >> PCIE_LC_LINK_WIDTH_CNTL__LC_LINK_WIDTH_RD__SHIFT; ++ ++ /* ++ * Program PCIE_LC_CNTL6.LC_SPC_MODE_8GT to 0x2 (4 symbols per clock data) ++ * if link_width is 0x3 (x4) ++ */ ++ if (0x3 == link_width) { ++ reg_data = RREG32_PCIE(smnPCIE_LC_CNTL6); ++ reg_data &= ~PCIE_LC_CNTL6__LC_SPC_MODE_8GT_MASK; ++ reg_data |= (0x2 << PCIE_LC_CNTL6__LC_SPC_MODE_8GT__SHIFT); ++ WREG32_PCIE(smnPCIE_LC_CNTL6, reg_data); ++ } ++} ++ + const struct amdgpu_nbio_funcs nbio_v2_3_funcs = { + .get_hdp_flush_req_offset = nbio_v2_3_get_hdp_flush_req_offset, + .get_hdp_flush_done_offset = nbio_v2_3_get_hdp_flush_done_offset, +@@ -484,4 +511,5 @@ const struct amdgpu_nbio_funcs nbio_v2_3 + .remap_hdp_registers = nbio_v2_3_remap_hdp_registers, + .enable_aspm = nbio_v2_3_enable_aspm, + .program_aspm = nbio_v2_3_program_aspm, ++ .apply_lc_spc_mode_wa = nbio_v2_3_apply_lc_spc_mode_wa, + }; +--- a/drivers/gpu/drm/amd/amdgpu/nv.c ++++ b/drivers/gpu/drm/amd/amdgpu/nv.c +@@ -1073,6 +1073,9 @@ static int nv_common_hw_init(void *handl + { + struct amdgpu_device *adev = (struct amdgpu_device *)handle; + ++ if (adev->nbio.funcs->apply_lc_spc_mode_wa) ++ adev->nbio.funcs->apply_lc_spc_mode_wa(adev); ++ + /* enable pcie gen2/3 link */ + nv_pcie_gen3_enable(adev); + /* enable aspm */ diff --git a/queue-5.12/drm-amdgpu-fix-the-hang-caused-by-pcie-link-width-switch.patch b/queue-5.12/drm-amdgpu-fix-the-hang-caused-by-pcie-link-width-switch.patch new file mode 100644 index 00000000000..847ef3f522a --- /dev/null +++ b/queue-5.12/drm-amdgpu-fix-the-hang-caused-by-pcie-link-width-switch.patch @@ -0,0 +1,76 @@ +From adcf949e664a8b04df2fb8aa916892e58561653c Mon Sep 17 00:00:00 2001 +From: Evan Quan +Date: Tue, 25 May 2021 14:36:29 +0800 +Subject: drm/amdgpu: fix the hang caused by PCIe link width switch + +From: Evan Quan + +commit adcf949e664a8b04df2fb8aa916892e58561653c upstream. + +SMU had set all the necessary fields for a link width switch +but the width switch wasn't occurring because the link was idle +in the L1 state. Setting LC_L1_RECONFIG_EN=0x1 will allow width +switches to also be initiated while in L1 instead of waiting until +the link is back in L0. + +Signed-off-by: Evan Quan +Reviewed-by: Lijo Lazar +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h | 1 + + drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 13 +++++++++++++ + drivers/gpu/drm/amd/amdgpu/nv.c | 3 +++ + 3 files changed, 17 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_nbio.h +@@ -90,6 +90,7 @@ struct amdgpu_nbio_funcs { + bool enable); + void (*program_aspm)(struct amdgpu_device *adev); + void (*apply_lc_spc_mode_wa)(struct amdgpu_device *adev); ++ void (*apply_l1_link_width_reconfig_wa)(struct amdgpu_device *adev); + }; + + struct amdgpu_nbio { +--- a/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c ++++ b/drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c +@@ -490,6 +490,18 @@ static void nbio_v2_3_apply_lc_spc_mode_ + } + } + ++static void nbio_v2_3_apply_l1_link_width_reconfig_wa(struct amdgpu_device *adev) ++{ ++ uint32_t reg_data = 0; ++ ++ if (adev->asic_type != CHIP_NAVI10) ++ return; ++ ++ reg_data = RREG32_PCIE(smnPCIE_LC_LINK_WIDTH_CNTL); ++ reg_data |= PCIE_LC_LINK_WIDTH_CNTL__LC_L1_RECONFIG_EN_MASK; ++ WREG32_PCIE(smnPCIE_LC_LINK_WIDTH_CNTL, reg_data); ++} ++ + const struct amdgpu_nbio_funcs nbio_v2_3_funcs = { + .get_hdp_flush_req_offset = nbio_v2_3_get_hdp_flush_req_offset, + .get_hdp_flush_done_offset = nbio_v2_3_get_hdp_flush_done_offset, +@@ -512,4 +524,5 @@ const struct amdgpu_nbio_funcs nbio_v2_3 + .enable_aspm = nbio_v2_3_enable_aspm, + .program_aspm = nbio_v2_3_program_aspm, + .apply_lc_spc_mode_wa = nbio_v2_3_apply_lc_spc_mode_wa, ++ .apply_l1_link_width_reconfig_wa = nbio_v2_3_apply_l1_link_width_reconfig_wa, + }; +--- a/drivers/gpu/drm/amd/amdgpu/nv.c ++++ b/drivers/gpu/drm/amd/amdgpu/nv.c +@@ -1076,6 +1076,9 @@ static int nv_common_hw_init(void *handl + if (adev->nbio.funcs->apply_lc_spc_mode_wa) + adev->nbio.funcs->apply_lc_spc_mode_wa(adev); + ++ if (adev->nbio.funcs->apply_l1_link_width_reconfig_wa) ++ adev->nbio.funcs->apply_l1_link_width_reconfig_wa(adev); ++ + /* enable pcie gen2/3 link */ + nv_pcie_gen3_enable(adev); + /* enable aspm */ diff --git a/queue-5.12/drm-amdgpu-update-nv-simd-per-cu-to-2.patch b/queue-5.12/drm-amdgpu-update-nv-simd-per-cu-to-2.patch new file mode 100644 index 00000000000..bb5817830b9 --- /dev/null +++ b/queue-5.12/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.12/drm-arm-malidp-always-list-modifiers.patch b/queue-5.12/drm-arm-malidp-always-list-modifiers.patch new file mode 100644 index 00000000000..f03a992206c --- /dev/null +++ b/queue-5.12/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.12/drm-dp-handle-zeroed-port-counts-in-drm_dp_read_downstream_info.patch b/queue-5.12/drm-dp-handle-zeroed-port-counts-in-drm_dp_read_downstream_info.patch new file mode 100644 index 00000000000..8b47edd1ba1 --- /dev/null +++ b/queue-5.12/drm-dp-handle-zeroed-port-counts-in-drm_dp_read_downstream_info.patch @@ -0,0 +1,50 @@ +From 205bb69a90363541a634a662a599fddb95956524 Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Fri, 30 Apr 2021 18:34:27 -0400 +Subject: drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Lyude Paul + +commit 205bb69a90363541a634a662a599fddb95956524 upstream. + +While the DP specification isn't entirely clear on if this should be +allowed or not, some branch devices report having downstream ports present +while also reporting a downstream port count of 0. So to avoid breaking +those devices, we need to handle this in drm_dp_read_downstream_info(). + +So, to do this we assume there's no downstream port info when the +downstream port count is 0. + +Signed-off-by: Lyude Paul +Tested-by: Jérôme de Bretagne +Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3416 +Fixes: 3d3721ccb18a ("drm/i915/dp: Extract drm_dp_read_downstream_info()") +Cc: # v5.10+ +Reviewed-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20210430223428.10514-1-lyude@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_dp_helper.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/gpu/drm/drm_dp_helper.c ++++ b/drivers/gpu/drm/drm_dp_helper.c +@@ -679,7 +679,14 @@ int drm_dp_read_downstream_info(struct d + !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT)) + return 0; + ++ /* Some branches advertise having 0 downstream ports, despite also advertising they have a ++ * downstream port present. The DP spec isn't clear on if this is allowed or not, but since ++ * some branches do it we need to handle it regardless. ++ */ + len = drm_dp_downstream_port_count(dpcd); ++ if (!len) ++ return 0; ++ + if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE) + len *= 4; + diff --git a/queue-5.12/drm-dp_mst-do-not-set-proposed-vcpi-directly.patch b/queue-5.12/drm-dp_mst-do-not-set-proposed-vcpi-directly.patch new file mode 100644 index 00000000000..376f26f3f35 --- /dev/null +++ b/queue-5.12/drm-dp_mst-do-not-set-proposed-vcpi-directly.patch @@ -0,0 +1,127 @@ +From 35d3e8cb35e75450f87f87e3d314e2d418b6954b Mon Sep 17 00:00:00 2001 +From: Wayne Lin +Date: Wed, 16 Jun 2021 11:55:00 +0800 +Subject: drm/dp_mst: Do not set proposed vcpi directly + +From: Wayne Lin + +commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream. + +[Why] +When we receive CSN message to notify one port is disconnected, we will +implicitly set its corresponding num_slots to 0. Later on, we will +eventually call drm_dp_update_payload_part1() to arrange down streams. + +In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[] +to do the update. Not specific to a target sink only. For example, if we +light up 2 monitors, Monitor_A and Monitor_B, and then we unplug +Monitor_B. Later on, when we call drm_dp_update_payload_part1() to try +to update payload for Monitor_A, we'll also implicitly clean payload for +Monitor_B at the same time. And finally, when we try to call +drm_dp_update_payload_part1() to clean payload for Monitor_B, we will do +nothing at this time since payload for Monitor_B has been cleaned up +previously. + +For StarTech 1to3 DP hub, it seems like if we didn't update DPCD payload +ID table then polling for "ACT Handled"(BIT_1 of DPCD 002C0h) will fail +and this polling will last for 3 seconds. + +Therefore, guess the best way is we don't set the proposed_vcpi[] +diretly. Let user of these herlper functions to set the proposed_vcpi +directly. + +[How] +1. Revert commit 7617e9621bf2 ("drm/dp_mst: clear time slots for ports +invalid") +2. Tackle the issue in previous commit by skipping those trasient +proposed VCPIs. These stale VCPIs shoulde be explicitly cleared by +user later on. + +Changes since v1: +* Change debug macro to use drm_dbg_kms() instead +* Amend the commit message to add Fixed & Cc tags + +Signed-off-by: Wayne Lin +Fixes: 7617e9621bf2 ("drm/dp_mst: clear time slots for ports invalid") +Cc: Lyude Paul +Cc: Wayne Lin +Cc: Maarten Lankhorst +Cc: Maxime Ripard +Cc: Thomas Zimmermann +Cc: dri-devel@lists.freedesktop.org +Cc: # v5.5+ +Signed-off-by: Lyude Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20210616035501.3776-2-Wayne.Lin@amd.com +Reviewed-by: Lyude Paul +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++++++++------------------------- + 1 file changed, 10 insertions(+), 26 deletions(-) + +--- a/drivers/gpu/drm/drm_dp_mst_topology.c ++++ b/drivers/gpu/drm/drm_dp_mst_topology.c +@@ -2499,7 +2499,7 @@ drm_dp_mst_handle_conn_stat(struct drm_d + { + struct drm_dp_mst_topology_mgr *mgr = mstb->mgr; + struct drm_dp_mst_port *port; +- int old_ddps, old_input, ret, i; ++ int old_ddps, ret; + u8 new_pdt; + bool new_mcs; + bool dowork = false, create_connector = false; +@@ -2531,7 +2531,6 @@ drm_dp_mst_handle_conn_stat(struct drm_d + } + + old_ddps = port->ddps; +- old_input = port->input; + port->input = conn_stat->input_port; + port->ldps = conn_stat->legacy_device_plug_status; + port->ddps = conn_stat->displayport_device_plug_status; +@@ -2554,28 +2553,6 @@ drm_dp_mst_handle_conn_stat(struct drm_d + dowork = false; + } + +- if (!old_input && old_ddps != port->ddps && !port->ddps) { +- for (i = 0; i < mgr->max_payloads; i++) { +- struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i]; +- struct drm_dp_mst_port *port_validated; +- +- if (!vcpi) +- continue; +- +- port_validated = +- container_of(vcpi, struct drm_dp_mst_port, vcpi); +- port_validated = +- drm_dp_mst_topology_get_port_validated(mgr, port_validated); +- if (!port_validated) { +- mutex_lock(&mgr->payload_lock); +- vcpi->num_slots = 0; +- mutex_unlock(&mgr->payload_lock); +- } else { +- drm_dp_mst_topology_put_port(port_validated); +- } +- } +- } +- + if (port->connector) + drm_modeset_unlock(&mgr->base.lock); + else if (create_connector) +@@ -3406,8 +3383,15 @@ int drm_dp_update_payload_part1(struct d + port = drm_dp_mst_topology_get_port_validated( + mgr, port); + if (!port) { +- mutex_unlock(&mgr->payload_lock); +- return -EINVAL; ++ if (vcpi->num_slots == payload->num_slots) { ++ cur_slots += vcpi->num_slots; ++ payload->start_slot = req_payload.start_slot; ++ continue; ++ } else { ++ drm_dbg_kms("Fail:set payload to invalid sink"); ++ mutex_unlock(&mgr->payload_lock); ++ return -EINVAL; ++ } + } + put_port = true; + } diff --git a/queue-5.12/drm-i915-display-do-not-zero-past-infoframes.vsc.patch b/queue-5.12/drm-i915-display-do-not-zero-past-infoframes.vsc.patch new file mode 100644 index 00000000000..3bef330d3c1 --- /dev/null +++ b/queue-5.12/drm-i915-display-do-not-zero-past-infoframes.vsc.patch @@ -0,0 +1,42 @@ +From 07b72960d2b4a087ff2445e286159e69742069cc Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Thu, 17 Jun 2021 14:33:01 -0700 +Subject: drm/i915/display: Do not zero past infoframes.vsc +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Kees Cook + +commit 07b72960d2b4a087ff2445e286159e69742069cc upstream. + +intel_dp_vsc_sdp_unpack() was using a memset() size (36, struct dp_sdp) +larger than the destination (24, struct drm_dp_vsc_sdp), clobbering +fields in struct intel_crtc_state after infoframes.vsc. Use the actual +target size for the memset(). + +Fixes: 1b404b7dbb10 ("drm/i915/dp: Read out DP SDPs") +Cc: stable@vger.kernel.org +Signed-off-by: Kees Cook +Reviewed-by: José Roberto de Souza +Signed-off-by: José Roberto de Souza +Link: https://patchwork.freedesktop.org/patch/msgid/20210617213301.1824728-1-keescook@chromium.org +(cherry picked from commit c88e2647c5bb45d04dc4302018ebe6ebbf331823) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/display/intel_dp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/display/intel_dp.c ++++ b/drivers/gpu/drm/i915/display/intel_dp.c +@@ -3913,7 +3913,7 @@ static int intel_dp_vsc_sdp_unpack(struc + if (size < sizeof(struct dp_sdp)) + return -EINVAL; + +- memset(vsc, 0, size); ++ memset(vsc, 0, sizeof(*vsc)); + + if (sdp->sdp_header.HB0 != 0) + return -EINVAL; diff --git a/queue-5.12/drm-ingenic-fix-pixclock-rate-for-24-bit-serial-panels.patch b/queue-5.12/drm-ingenic-fix-pixclock-rate-for-24-bit-serial-panels.patch new file mode 100644 index 00000000000..9585262a6d2 --- /dev/null +++ b/queue-5.12/drm-ingenic-fix-pixclock-rate-for-24-bit-serial-panels.patch @@ -0,0 +1,40 @@ +From 60a6b73dd821e98fe958b2a83393ccd724b306b1 Mon Sep 17 00:00:00 2001 +From: Paul Cercueil +Date: Tue, 23 Mar 2021 14:40:08 +0000 +Subject: drm/ingenic: Fix pixclock rate for 24-bit serial panels + +From: Paul Cercueil + +commit 60a6b73dd821e98fe958b2a83393ccd724b306b1 upstream. + +When using a 24-bit panel on a 8-bit serial bus, the pixel clock +requested by the panel has to be multiplied by 3, since the subpixels +are shifted sequentially. + +The code (in ingenic_drm_encoder_atomic_check) already computed +crtc_state->adjusted_mode->crtc_clock accordingly, but clk_set_rate() +used crtc_state->adjusted_mode->clock instead. + +Fixes: 28ab7d35b6e0 ("drm/ingenic: Properly compute timings when using a 3x8-bit panel") +Cc: stable@vger.kernel.org # v5.10 +Signed-off-by: Paul Cercueil +Tested-by: H. Nikolaus Schaller # CI20/jz4780 (HDMI) and Alpha400/jz4730 (LCD) +Acked-by: Thomas Zimmermann +Link: https://patchwork.freedesktop.org/patch/msgid/20210323144008.166248-1-paul@crapouillou.net +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c ++++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +@@ -341,7 +341,7 @@ static void ingenic_drm_crtc_atomic_flus + if (priv->update_clk_rate) { + mutex_lock(&priv->clk_mutex); + clk_set_rate(priv->pix_clk, +- crtc_state->adjusted_mode.clock * 1000); ++ crtc_state->adjusted_mode.crtc_clock * 1000); + priv->update_clk_rate = false; + mutex_unlock(&priv->clk_mutex); + } diff --git a/queue-5.12/drm-ingenic-switch-ipu-plane-to-type-overlay.patch b/queue-5.12/drm-ingenic-switch-ipu-plane-to-type-overlay.patch new file mode 100644 index 00000000000..e46c6321640 --- /dev/null +++ b/queue-5.12/drm-ingenic-switch-ipu-plane-to-type-overlay.patch @@ -0,0 +1,83 @@ +From 68b433fe6937cfa3f8975d18643d5956254edd6a Mon Sep 17 00:00:00 2001 +From: Paul Cercueil +Date: Mon, 29 Mar 2021 18:50:45 +0100 +Subject: drm/ingenic: Switch IPU plane to type OVERLAY + +From: Paul Cercueil + +commit 68b433fe6937cfa3f8975d18643d5956254edd6a upstream. + +It should have been an OVERLAY from the beginning. The documentation +stipulates that there should be an unique PRIMARY plane per CRTC. + +Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU") +Cc: # 5.8+ +Signed-off-by: Paul Cercueil +Acked-by: Simon Ser +Link: https://patchwork.freedesktop.org/patch/msgid/20210329175046.214629-2-paul@crapouillou.net +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +++++------ + drivers/gpu/drm/ingenic/ingenic-ipu.c | 2 +- + 2 files changed, 6 insertions(+), 7 deletions(-) + +--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c ++++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +@@ -413,7 +413,7 @@ static void ingenic_drm_plane_enable(str + unsigned int en_bit; + + if (priv->soc_info->has_osd) { +- if (plane->type == DRM_PLANE_TYPE_PRIMARY) ++ if (plane != &priv->f0) + en_bit = JZ_LCD_OSDC_F1EN; + else + en_bit = JZ_LCD_OSDC_F0EN; +@@ -428,7 +428,7 @@ void ingenic_drm_plane_disable(struct de + unsigned int en_bit; + + if (priv->soc_info->has_osd) { +- if (plane->type == DRM_PLANE_TYPE_PRIMARY) ++ if (plane != &priv->f0) + en_bit = JZ_LCD_OSDC_F1EN; + else + en_bit = JZ_LCD_OSDC_F0EN; +@@ -455,8 +455,7 @@ void ingenic_drm_plane_config(struct dev + + ingenic_drm_plane_enable(priv, plane); + +- if (priv->soc_info->has_osd && +- plane->type == DRM_PLANE_TYPE_PRIMARY) { ++ if (priv->soc_info->has_osd && plane != &priv->f0) { + switch (fourcc) { + case DRM_FORMAT_XRGB1555: + ctrl |= JZ_LCD_OSDCTRL_RGB555; +@@ -504,7 +503,7 @@ void ingenic_drm_plane_config(struct dev + } + + if (priv->soc_info->has_osd) { +- if (plane->type == DRM_PLANE_TYPE_PRIMARY) { ++ if (plane != &priv->f0) { + xy_reg = JZ_REG_LCD_XYP1; + size_reg = JZ_REG_LCD_SIZE1; + } else { +@@ -554,7 +553,7 @@ static void ingenic_drm_plane_atomic_upd + height = state->src_h >> 16; + cpp = state->fb->format->cpp[0]; + +- if (!priv->soc_info->has_osd || plane->type == DRM_PLANE_TYPE_OVERLAY) ++ if (!priv->soc_info->has_osd || plane == &priv->f0) + hwdesc = &priv->dma_hwdescs->hwdesc_f0; + else + hwdesc = &priv->dma_hwdescs->hwdesc_f1; +--- a/drivers/gpu/drm/ingenic/ingenic-ipu.c ++++ b/drivers/gpu/drm/ingenic/ingenic-ipu.c +@@ -760,7 +760,7 @@ static int ingenic_ipu_bind(struct devic + + err = drm_universal_plane_init(drm, plane, 1, &ingenic_ipu_plane_funcs, + soc_info->formats, soc_info->num_formats, +- NULL, DRM_PLANE_TYPE_PRIMARY, NULL); ++ NULL, DRM_PLANE_TYPE_OVERLAY, NULL); + if (err) { + dev_err(dev, "Failed to init plane: %i\n", err); + return err; diff --git a/queue-5.12/drm-msm-mdp4-fix-modifier-support-enabling.patch b/queue-5.12/drm-msm-mdp4-fix-modifier-support-enabling.patch new file mode 100644 index 00000000000..5fed146cac0 --- /dev/null +++ b/queue-5.12/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.12/drm-nouveau-don-t-set-allow_fb_modifiers-explicitly.patch b/queue-5.12/drm-nouveau-don-t-set-allow_fb_modifiers-explicitly.patch new file mode 100644 index 00000000000..b4de99072d5 --- /dev/null +++ b/queue-5.12/drm-nouveau-don-t-set-allow_fb_modifiers-explicitly.patch @@ -0,0 +1,47 @@ +From cee93c028288b9af02919f3bd8593ba61d1e610d Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Tue, 27 Apr 2021 11:20:16 +0200 +Subject: drm/nouveau: Don't set allow_fb_modifiers explicitly + +From: Daniel Vetter + +commit cee93c028288b9af02919f3bd8593ba61d1e610d 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. + +Note that this fixes an inconsistency: We've set the cap everywhere, +but only nv50+ supports modifiers. Hence cc stable, but not further +back then the patch from Paul. + +Reviewed-by: Lyude Paul +Cc: stable@vger.kernel.org # v5.1 + +Cc: Pekka Paalanen +Signed-off-by: Daniel Vetter +Cc: Ben Skeggs +Cc: nouveau@lists.freedesktop.org +Link: https://patchwork.freedesktop.org/patch/msgid/20210427092018.832258-6-daniel.vetter@ffwll.ch +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/nouveau_display.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/gpu/drm/nouveau/nouveau_display.c ++++ b/drivers/gpu/drm/nouveau/nouveau_display.c +@@ -700,7 +700,6 @@ nouveau_display_create(struct drm_device + + dev->mode_config.preferred_depth = 24; + dev->mode_config.prefer_shadow = 1; +- dev->mode_config.allow_fb_modifiers = true; + + if (drm->client.device.info.chipset < 0x11) + dev->mode_config.async_page_flip = false; diff --git a/queue-5.12/drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch b/queue-5.12/drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch new file mode 100644 index 00000000000..a10d2a2fb6e --- /dev/null +++ b/queue-5.12/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 +@@ -1325,6 +1325,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.12/drm-radeon-call-radeon_suspend_kms-in-radeon_pci_shutdown-for-loongson64.patch b/queue-5.12/drm-radeon-call-radeon_suspend_kms-in-radeon_pci_shutdown-for-loongson64.patch new file mode 100644 index 00000000000..9083ba79ba5 --- /dev/null +++ b/queue-5.12/drm-radeon-call-radeon_suspend_kms-in-radeon_pci_shutdown-for-loongson64.patch @@ -0,0 +1,60 @@ +From c1bfd74bfef77bcefc88d12eaf8996c0dfd51331 Mon Sep 17 00:00:00 2001 +From: Tiezhu Yang +Date: Mon, 28 Jun 2021 10:53:06 -0400 +Subject: drm/radeon: Call radeon_suspend_kms() in radeon_pci_shutdown() for Loongson64 + +From: Tiezhu Yang + +commit c1bfd74bfef77bcefc88d12eaf8996c0dfd51331 upstream. + +On the Loongson64 platform used with Radeon GPU, shutdown or reboot failed +when console=tty is in the boot cmdline. + +radeon_suspend_kms() puts the hw in the suspend state, especially set fb +state as FBINFO_STATE_SUSPENDED: + + if (fbcon) { + console_lock(); + radeon_fbdev_set_suspend(rdev, 1); + console_unlock(); + } + +Then avoid to do any more fb operations in the related functions: + + if (p->state != FBINFO_STATE_RUNNING) + return; + +So call radeon_suspend_kms() in radeon_pci_shutdown() for Loongson64 to fix +this issue, it looks like some kind of workaround like powerpc. + +Co-developed-by: Jianmin Lv +Signed-off-by: Jianmin Lv +Signed-off-by: Tiezhu Yang +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_drv.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/radeon/radeon_drv.c ++++ b/drivers/gpu/drm/radeon/radeon_drv.c +@@ -386,13 +386,13 @@ radeon_pci_shutdown(struct pci_dev *pdev + if (radeon_device_is_virtual()) + radeon_pci_remove(pdev); + +-#ifdef CONFIG_PPC64 ++#if defined(CONFIG_PPC64) || defined(CONFIG_MACH_LOONGSON64) + /* + * Some adapters need to be suspended before a + * shutdown occurs in order to prevent an error +- * during kexec. +- * Make this power specific becauase it breaks +- * some non-power boards. ++ * during kexec, shutdown or reboot. ++ * Make this power and Loongson specific because ++ * it breaks some other boards. + */ + radeon_suspend_kms(pci_get_drvdata(pdev), true, true, false); + #endif diff --git a/queue-5.12/drm-rockchip-dsi-remove-extra-component_del-call.patch b/queue-5.12/drm-rockchip-dsi-remove-extra-component_del-call.patch new file mode 100644 index 00000000000..1050fc0ea7a --- /dev/null +++ b/queue-5.12/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 +@@ -243,7 +243,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 { +@@ -1141,9 +1140,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.12/drm-tegra-don-t-set-allow_fb_modifiers-explicitly.patch b/queue-5.12/drm-tegra-don-t-set-allow_fb_modifiers-explicitly.patch new file mode 100644 index 00000000000..d32690ce33c --- /dev/null +++ b/queue-5.12/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 +@@ -947,6 +947,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) + { +@@ -975,7 +980,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); +@@ -1094,7 +1099,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 +@@ -1122,8 +1122,6 @@ static int host1x_drm_probe(struct host1 + 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.12/drm-vc4-crtc-skip-the-txp.patch b/queue-5.12/drm-vc4-crtc-skip-the-txp.patch new file mode 100644 index 00000000000..583bcaefdeb --- /dev/null +++ b/queue-5.12/drm-vc4-crtc-skip-the-txp.patch @@ -0,0 +1,44 @@ +From 47a50743031ad4138050ae6d266ddd3dfe845ead Mon Sep 17 00:00:00 2001 +From: Maxime Ripard +Date: Fri, 7 May 2021 17:05:05 +0200 +Subject: drm/vc4: crtc: Skip the TXP + +From: Maxime Ripard + +commit 47a50743031ad4138050ae6d266ddd3dfe845ead upstream. + +The vc4_set_crtc_possible_masks is meant to run over all the encoders +and then set their possible_crtcs mask to their associated pixelvalve. + +However, since the commit 39fcb2808376 ("drm/vc4: txp: Turn the TXP into +a CRTC of its own"), the TXP has been turned to a CRTC and encoder of +its own, and while it does indeed register an encoder, it no longer has +an associated pixelvalve. The code will thus run over the TXP encoder +and set a bogus possible_crtcs mask, overriding the one set in the TXP +bind function. + +In order to fix this, let's skip any virtual encoder. + +Cc: # v5.9+ +Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") +Acked-by: Thomas Zimmermann +Signed-off-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-3-maxime@cerno.tech +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/vc4/vc4_crtc.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/vc4/vc4_crtc.c ++++ b/drivers/gpu/drm/vc4/vc4_crtc.c +@@ -1076,6 +1076,9 @@ static void vc4_set_crtc_possible_masks( + struct vc4_encoder *vc4_encoder; + int i; + ++ if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL) ++ continue; ++ + vc4_encoder = to_vc4_encoder(encoder); + for (i = 0; i < ARRAY_SIZE(pv_data->encoder_types); i++) { + if (vc4_encoder->type == encoder_types[i]) { diff --git a/queue-5.12/drm-vc4-hdmi-prevent-clock-unbalance.patch b/queue-5.12/drm-vc4-hdmi-prevent-clock-unbalance.patch new file mode 100644 index 00000000000..3fa9bd11796 --- /dev/null +++ b/queue-5.12/drm-vc4-hdmi-prevent-clock-unbalance.patch @@ -0,0 +1,44 @@ +From 5b006000423667ef0f55721fc93e477b31f22d28 Mon Sep 17 00:00:00 2001 +From: Maxime Ripard +Date: Fri, 7 May 2021 17:05:09 +0200 +Subject: drm/vc4: hdmi: Prevent clock unbalance + +From: Maxime Ripard + +commit 5b006000423667ef0f55721fc93e477b31f22d28 upstream. + +Since we fixed the hooks to disable the encoder at boot, we now have an +unbalanced clk_disable call at boot since we never enabled them in the +first place. + +Let's mimic the state of the hardware and enable the clocks at boot if +the controller is enabled to get the use-count right. + +Cc: # v5.10+ +Fixes: 09c438139b8f ("drm/vc4: hdmi: Implement finer-grained hooks") +Signed-off-by: Maxime Ripard +Reviewed-by: Dave Stevenson +Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-7-maxime@cerno.tech +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/vc4/vc4_hdmi.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/gpu/drm/vc4/vc4_hdmi.c ++++ b/drivers/gpu/drm/vc4/vc4_hdmi.c +@@ -2012,6 +2012,14 @@ static int vc4_hdmi_bind(struct device * + if (vc4_hdmi->variant->reset) + vc4_hdmi->variant->reset(vc4_hdmi); + ++ if ((of_device_is_compatible(dev->of_node, "brcm,bcm2711-hdmi0") || ++ of_device_is_compatible(dev->of_node, "brcm,bcm2711-hdmi1")) && ++ HDMI_READ(HDMI_VID_CTL) & VC4_HD_VID_CTL_ENABLE) { ++ clk_prepare_enable(vc4_hdmi->pixel_clock); ++ clk_prepare_enable(vc4_hdmi->hsm_clock); ++ clk_prepare_enable(vc4_hdmi->pixel_bvb_clock); ++ } ++ + pm_runtime_enable(dev); + + drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS); diff --git a/queue-5.12/drm-vc4-txp-properly-set-the-possible_crtcs-mask.patch b/queue-5.12/drm-vc4-txp-properly-set-the-possible_crtcs-mask.patch new file mode 100644 index 00000000000..2cb2d58834c --- /dev/null +++ b/queue-5.12/drm-vc4-txp-properly-set-the-possible_crtcs-mask.patch @@ -0,0 +1,34 @@ +From bf6de8e61509f3c957d7f75f017b18d40a18a950 Mon Sep 17 00:00:00 2001 +From: Maxime Ripard +Date: Fri, 7 May 2021 17:05:04 +0200 +Subject: drm/vc4: txp: Properly set the possible_crtcs mask + +From: Maxime Ripard + +commit bf6de8e61509f3c957d7f75f017b18d40a18a950 upstream. + +The current code does a binary OR on the possible_crtcs variable of the +TXP encoder, while we want to set it to that value instead. + +Cc: # v5.9+ +Fixes: 39fcb2808376 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") +Acked-by: Thomas Zimmermann +Signed-off-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20210507150515.257424-2-maxime@cerno.tech +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/vc4/vc4_txp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/vc4/vc4_txp.c ++++ b/drivers/gpu/drm/vc4/vc4_txp.c +@@ -507,7 +507,7 @@ static int vc4_txp_bind(struct device *d + return ret; + + encoder = &txp->connector.encoder; +- encoder->possible_crtcs |= drm_crtc_mask(crtc); ++ encoder->possible_crtcs = drm_crtc_mask(crtc); + + ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0, + dev_name(dev), txp); diff --git a/queue-5.12/fpga-stratix10-soc-add-missing-fpga_mgr_free-call.patch b/queue-5.12/fpga-stratix10-soc-add-missing-fpga_mgr_free-call.patch new file mode 100644 index 00000000000..5431c2ca7e7 --- /dev/null +++ b/queue-5.12/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 +@@ -454,6 +454,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.12/mmc-core-allow-uhs-i-voltage-switch-for-sdsc-cards-if-supported.patch b/queue-5.12/mmc-core-allow-uhs-i-voltage-switch-for-sdsc-cards-if-supported.patch new file mode 100644 index 00000000000..77ed2f9b240 --- /dev/null +++ b/queue-5.12/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 +@@ -847,11 +847,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.12/mmc-core-clear-flags-before-allowing-to-retune.patch b/queue-5.12/mmc-core-clear-flags-before-allowing-to-retune.patch new file mode 100644 index 00000000000..815adf9119d --- /dev/null +++ b/queue-5.12/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 +@@ -937,11 +937,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.12/mmc-sdhci-acpi-disable-write-protect-detection-on-toshiba-encore-2-wt8-b.patch b/queue-5.12/mmc-sdhci-acpi-disable-write-protect-detection-on-toshiba-encore-2-wt8-b.patch new file mode 100644 index 00000000000..bf48e7c9441 --- /dev/null +++ b/queue-5.12/mmc-sdhci-acpi-disable-write-protect-detection-on-toshiba-encore-2-wt8-b.patch @@ -0,0 +1,47 @@ +From 94ee6782e045645abd9180ab9369b01293d862bd Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Mon, 3 May 2021 11:21:57 +0200 +Subject: mmc: sdhci-acpi: Disable write protect detection on Toshiba Encore 2 WT8-B + +From: Hans de Goede + +commit 94ee6782e045645abd9180ab9369b01293d862bd upstream. + +On the Toshiba Encore 2 WT8-B the microSD slot always reports the card +being write-protected even though microSD cards do not have a write-protect +switch at all. + +Add a new DMI_QUIRK_SD_NO_WRITE_PROTECT quirk entry to sdhci-acpi.c's +DMI quirk table for this. + +Signed-off-by: Hans de Goede +Acked-by: Adrian Hunter +Link: https://lore.kernel.org/r/20210503092157.5689-1-hdegoede@redhat.com +Signed-off-by: Ulf Hansson +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-acpi.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/drivers/mmc/host/sdhci-acpi.c ++++ b/drivers/mmc/host/sdhci-acpi.c +@@ -820,6 +820,17 @@ static const struct dmi_system_id sdhci_ + }, + .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT, + }, ++ { ++ /* ++ * The Toshiba WT8-B's microSD slot always reports the card being ++ * write-protected. ++ */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "TOSHIBA ENCORE 2 WT8-B"), ++ }, ++ .driver_data = (void *)DMI_QUIRK_SD_NO_WRITE_PROTECT, ++ }, + {} /* Terminating entry */ + }; + diff --git a/queue-5.12/mmc-sdhci-fix-warning-message-when-accessing-rpmb-in-hs400-mode.patch b/queue-5.12/mmc-sdhci-fix-warning-message-when-accessing-rpmb-in-hs400-mode.patch new file mode 100644 index 00000000000..149e65d862a --- /dev/null +++ b/queue-5.12/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 +@@ -1812,6 +1812,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 +@@ -253,6 +253,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.12/pinctrl-amd-add-device-hid-for-new-amd-gpio-controller.patch b/queue-5.12/pinctrl-amd-add-device-hid-for-new-amd-gpio-controller.patch new file mode 100644 index 00000000000..6c022c191ac --- /dev/null +++ b/queue-5.12/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 +@@ -991,6 +991,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.12/series b/queue-5.12/series index da56d9c4e2f..8d055f9ae75 100644 --- a/queue-5.12/series +++ b/queue-5.12/series @@ -158,3 +158,36 @@ mm-mremap-hold-the-rmap-lock-in-write-mode-when-moving-page-table-entries.patch powerpc-mm-fix-lockup-on-kernel-exec-fault.patch powerpc-barrier-avoid-collision-with-clang-s-__lwsync-macro.patch powerpc-powernv-vas-release-reference-to-tgid-during-window-close.patch +drm-amdgpu-add-new-dimgrey-cavefish-did.patch +drm-amdgpu-update-nv-simd-per-cu-to-2.patch +drm-amdgpu-enable-sdma0-tmz-for-raven-renoir-v2.patch +drm-amdgpu-fix-nak-g-generation-during-pci-e-link-width-switch.patch +drm-amdgpu-fix-the-hang-caused-by-pcie-link-width-switch.patch +drm-radeon-add-the-missed-drm_gem_object_put-in-radeon_user_framebuffer_create.patch +drm-radeon-call-radeon_suspend_kms-in-radeon_pci_shutdown-for-loongson64.patch +drm-vc4-txp-properly-set-the-possible_crtcs-mask.patch +drm-vc4-crtc-skip-the-txp.patch +drm-vc4-hdmi-prevent-clock-unbalance.patch +drm-dp-handle-zeroed-port-counts-in-drm_dp_read_downstream_info.patch +drm-dp_mst-do-not-set-proposed-vcpi-directly.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-ingenic-fix-pixclock-rate-for-24-bit-serial-panels.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 +drm-nouveau-don-t-set-allow_fb_modifiers-explicitly.patch +drm-ingenic-switch-ipu-plane-to-type-overlay.patch +drm-i915-display-do-not-zero-past-infoframes.vsc.patch +mmc-sdhci-acpi-disable-write-protect-detection-on-toshiba-encore-2-wt8-b.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 +docs-makefile-use-config_shell-not-shell.patch +ata-ahci_sunxi-disable-dipm.patch +arm64-tlb-fix-the-ttl-value-of-tlb_get_level.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