fix SG2042 using AMD R5 220/230 graphics cards & PCI/ASPM: Avoid L0s and L1 on Sophgo 2042/4 PCIe #18
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The MediaTek MT7921 card frequently disappears, especially on cold boots, reboots, and on S3 wakeup. Adding pci=nocrs resolves this issue. Also reported elsewhere before and confirming that pci=nocrs was indeed a working workaround. See link below. Cc: stable@vger.kernel.org Reported-by: Yu Chen <zerominute@163.com> Link: https://bbs.archlinux.org/viewtopic.php?id=291793 Signed-off-by: Mingcong Bai <jeffbai@aosc.io>
RevySR
changed the title
HWR $30 (Loongson64 constant timer) is 64 bits wide. However, some hardware doesn't properly sign-extend its value before copying it into a GPR in o32 mode (Status.UX==1). This "shadow" on the higher half breaks most subsequent instructions relying on the GPR. Aside from the HW bug, it is never possible to retrieve the higher half of the constant timer in o32 mode, which implies that the masks of timer cycles differentiate in o32 versus n32/n64 modes. Considering that a clocksource can only have a single mask, we are unable to make the o32 vDSO parse the timer delta properly anyway. Moreover, the timer frequency is simply too high that 32-bit timer cycles wrap crazily -- it's fundamentally unreliable without the higher half. Fix this by preventing o32 vDSO from using the constant timer. Fixes: "AOSCOS: MIPS: Loongson: Add constant timer support" Signed-off-by: Rong Zhang <i@rong.moe>
Loongarch64 is marked ARCH_HAS_SET_DIRECT_MAP by Chen Huacai. So we can use memfd_secret for this architecture. This commit has enabled it, and it is kselftest passed. Signed-off-by: Lain "Fearyncess" Yang <fsf@live.com>
…dr_mask Some PCI devices have PCI_MSI_FLAGS_64BIT in the MSI capability, but implement less than 64 address bits. This breaks on platforms where such a device is assigned an MSI address higher than what's reachable. Currently, we deal with this with a single no_64bit_msi flag, and (notably on powerpc) use 32-bit MSI address for these devices. However, on some platforms the MSI doorbell address is above 32-bit but within device ability. As a first step, conservatively generalize the single-bit flag no_64bit_msi into msi_addr_mask. (The name msi_addr_mask is chosen to avoid confusion with msi_mask.) The translation is essentially: - no_64bit_msi = 1 -> msi_addr_mask = DMA_BIT_MASK(32) - no_64bit_msi = 0 -> msi_addr_mask = DMA_BIT_MASK(64) - if (no_64bit_msi) -> if (msi_addr_mask < DMA_BIT_MASK(64)) Since no values other than DMA_BIT_MASK(32) and DMA_BIT_MASK(64) is used, no functional change is intended. Future patches that make use of intermediate values of msi_addr_mask will follow, allowing devices that cannot use full 64-bit addresses for MSI to work on platforms with MSI doorbell above 32-bit address space. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20251224-pci-msi-addr-mask-v1-1-05a6fcb4b4c0@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
Instead of a 32-bit/64-bit dichotomy, check the MSI address against msi_addr_mask. This allows platforms with MSI doorbell above 32-bit address space to work with devices without full 64-bit MSI address support, as long as the doorbell is within addressable range of MSI of the device. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20251224-pci-msi-addr-mask-v1-2-05a6fcb4b4c0@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
The code was originally written using no_64bit_msi, which restricts the device to 32-bit MSI addresses. Since msi_addr_mask is introduced, use DMA_BIT_MASK(40) instead of DMA_BIT_MASK(32) here for msi_addr_mask, describing the restriction more precisely and allowing these devices to work on platforms with MSI doorbell address above 32-bit space, as long as it is within the hardware restriction of 40-bit space. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20251224-pci-msi-addr-mask-v1-3-05a6fcb4b4c0@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
The code was originally written using no_64bit_msi, which restricts the device to 32-bit MSI addresses. Since msi_addr_mask is introduced, use DMA_BIT_MASK(dma_bits) instead of DMA_BIT_MASK(32) here for msi_addr_mask, describing the restriction more precisely and allowing these devices to work on platforms with MSI doorbell address above 32-bit space, as long as it is within the hardware's addressable space. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://lore.kernel.org/r/20251224-pci-msi-addr-mask-v1-4-05a6fcb4b4c0@iscas.ac.cn Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
…Root Ports Since commit f3ac2ff ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") force enable ASPM on all device tree platform, the SG2042 root port breaks as it advertises L0s and L1 capabilities without supporting it. Override the L0s and L1 Support advertised in Link Capabilities by the SG2042 Root Ports ([1f1c:2042]), so we don't try to enable those states. Fixes: 4e27aca ("riscv: sophgo: dts: add PCIe controllers for SG2042") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Tested-by: Han Gao <gaohan@iscas.ac.cn> Link: https://lore.kernel.org/r/20251225100530.1301625-2-inochiama@gmail.com Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
…Root Ports Since commit f3ac2ff ("PCI/ASPM: Enable all ClockPM and ASPM states for devicetree platforms") force enable ASPM on all device tree platform, the SG2044 root port breaks as it advertises L0s and L1 capabilities without supporting it. Override the L0s and L1 Support advertised in Link Capabilities by the SG2044 Root Ports ([1f1c:2044]), so we don't try to enable those states. Fixes: 3309df4 ("riscv: dts: sophgo: sg2044: add PCIe device support for SG2044") Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Tested-by: Han Gao <gaohan@iscas.ac.cn> Link: https://lore.kernel.org/r/20251225100530.1301625-3-inochiama@gmail.com Signed-off-by: Han Gao <gaohan@iscas.ac.cn>
RevySR
force-pushed
the
aosc/rv/v6.18.y
branch
from
3682631 to
23ef9b5
Compare
RevySR
changed the title
MingcongBai
force-pushed
the
aosc/v6.18.2
branch
2 times, most recently
from
cbe8777 to
44f4027
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.