LoongArch: fix some pci problems（Pull request again） #192
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
added 9 commits
May 23, 2024 14:43
Signed-off-by: Baoqi Zhang <zhangbaoqi@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Fix patch "LoongArch: Add PCI controller support" Signed-off-by: Tianli Xiong <xiongtianli@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
…ccess configuration space Fix patch "PCI: loongson: Use generic 8/16/32-bit config ops on LS2K/LS7A" Signed-off-by: Tianli Xiong <xiongtianli@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Don't limit mrrs during resume, so that saved value can be restored. Fix patch "PCI: loongson: Improve the MRRS quirk for LS7A" Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
fix kabi error caused by pm_suspend_target_state,used only by loongson devices. Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Fix some pcie card not scanning properly when bus number is inconsistent during firmware and kernel scan phases. Signed-off-by: liuyun <liuyun@loongson.cn> Signed-off-by: Tianli Xiong <xiongtianli@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Add window to solve GPU access error Signed-off-by: Baoqi Zhang <zhangbaoqi@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
According to PCI-to-PCI bridge spec, bit 3 of Bridge Control Register
is VGA Enable bit which modifies the response by the bridge to VGA
compatible addresses.
The Bridge Control register provides extensions to the Command register
that are specific to a bridge. The Bridge Control register provides
many of the same controls for the secondary interface that are provided
by the Command register for the primary interface. There are some bits
that affect the operation of both interfaces of the bridge.
If the VGA Enable bit is set, the bridge will positively decode
and forward the following accesses on the primary interface to
the secondary interface (and, conversely, block the forwarding
of these addresses from the secondary to primary interface)
Forwarding of these accesses is qualified by the I/O Enable and
Memory Enable bits in the Command register.) The default state of
this bit after reset must be 0.
Bit 3 of Bridge Control Register is VGA Enable bit which modifies the
response by the bridge to VGA compatible addresses.
when 0: do not forward VGA compatible memory and I/O addresses from
the primary to secondary interface (addresses defined below)
unless they are enabled for forwarding by the defined I/O
when 1: forward VGA compatible memory and I/O addresses (addresses
defined below) from the primary interface to the secondary
interface (if the I/O Enable and Memory Enable bits are set)
independent of the I/O and memory address ranges and
independent of the ISA Enable bit
* memory accesses in the range 000A 0000h to 000B FFFFh
* I/O addresses in the first 64 KB of the I/O address space
(AD[31:16] are 0000h) where AD[9:: 0] are in the ranges
3B0h to 3BBh and 3C0h to 3DFh (inclusive of ISA address
aliases - AD[15::10] are not decoded)
If the VGA Enable bit is set, forwarding of these accesses is
independent of the I/O address range and memory address ranges
defined by the I/O Base and Limit registers, the Memory Base
and Limit registers, and the Prefetchable Memory Base and Limit
registers of the bridge.
Forwarding of these accesses is also independent of the settings
of the ISA Enable bit (in the Bridge Control register) or VGA
Palette Snoop bits (in the Command register).
The AST2500 hardware we are using do not set the VGA Enable bit on
its bridge control reg, this cause vgaarb subsystem don't think the
VGA card behind this pridge as a valid boot vga device which made
X server choose wrong video card to use when multiple video card
present in the system.
Its seems more vgaarb's fault than the ast2500 bmc itself.
even through bit 3 of Bridge Control Register is 0, it should still
allow to forward the accesses when the addresses is in the range of
IO/MEM Base and Limit registers.
Nevertheless, in order to support loongson CPU product line, we
provide a workaround to this bug for the Sugon L620-G30 and Sugon
L820-G30 server.
see similar bug:
https://patchwork.kernel.org/project/linux-pci/patch/20170619023528.11532-1-dja@axtens.net/
Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @sterling-teng. Thanks for your PR. I'm waiting for a deepin-community member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Member
|
/ok-to-test |
deepin pr auto review关键摘要:
是否建议立即修改:
|
opsiff
pushed a commit
to opsiff/UOS-kernel
that referenced
this pull request
Dec 22, 2025
…ccess configuration space Fix patch "PCI: loongson: Use generic 8/16/32-bit config ops on LS2K/LS7A" Signed-off-by: Tianli Xiong <xiongtianli@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: deepin-community#192 (cherry picked from commit d6d5fd4) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
opsiff
pushed a commit
to opsiff/UOS-kernel
that referenced
this pull request
Dec 22, 2025
Don't limit mrrs during resume, so that saved value can be restored. Fix patch "PCI: loongson: Improve the MRRS quirk for LS7A" Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: deepin-community#192 (cherry picked from commit 051e311) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
opsiff
pushed a commit
to opsiff/UOS-kernel
that referenced
this pull request
Dec 22, 2025
fix kabi error caused by pm_suspend_target_state,used only by loongson devices. Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: deepin-community#192 (cherry picked from commit 00097a0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Conflicts: drivers/pci/pci.c
opsiff
pushed a commit
to opsiff/UOS-kernel
that referenced
this pull request
Dec 22, 2025
Fix some pcie card not scanning properly when bus number is inconsistent during firmware and kernel scan phases. Signed-off-by: liuyun <liuyun@loongson.cn> Signed-off-by: Tianli Xiong <xiongtianli@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: deepin-community#192 (cherry picked from commit f8f6e3b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
opsiff
pushed a commit
to opsiff/UOS-kernel
that referenced
this pull request
Dec 22, 2025
Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: deepin-community#192 (cherry picked from commit e709255) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
opsiff
pushed a commit
to opsiff/UOS-kernel
that referenced
this pull request
Dec 22, 2025
Add window to solve GPU access error Signed-off-by: Baoqi Zhang <zhangbaoqi@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: deepin-community#192 (cherry picked from commit dd93b14) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
opsiff
pushed a commit
to opsiff/UOS-kernel
that referenced
this pull request
Dec 22, 2025
According to PCI-to-PCI bridge spec, bit 3 of Bridge Control Register
is VGA Enable bit which modifies the response by the bridge to VGA
compatible addresses.
The Bridge Control register provides extensions to the Command register
that are specific to a bridge. The Bridge Control register provides
many of the same controls for the secondary interface that are provided
by the Command register for the primary interface. There are some bits
that affect the operation of both interfaces of the bridge.
If the VGA Enable bit is set, the bridge will positively decode
and forward the following accesses on the primary interface to
the secondary interface (and, conversely, block the forwarding
of these addresses from the secondary to primary interface)
Forwarding of these accesses is qualified by the I/O Enable and
Memory Enable bits in the Command register.) The default state of
this bit after reset must be 0.
Bit 3 of Bridge Control Register is VGA Enable bit which modifies the
response by the bridge to VGA compatible addresses.
when 0: do not forward VGA compatible memory and I/O addresses from
the primary to secondary interface (addresses defined below)
unless they are enabled for forwarding by the defined I/O
when 1: forward VGA compatible memory and I/O addresses (addresses
defined below) from the primary interface to the secondary
interface (if the I/O Enable and Memory Enable bits are set)
independent of the I/O and memory address ranges and
independent of the ISA Enable bit
* memory accesses in the range 000A 0000h to 000B FFFFh
* I/O addresses in the first 64 KB of the I/O address space
(AD[31:16] are 0000h) where AD[9:: 0] are in the ranges
3B0h to 3BBh and 3C0h to 3DFh (inclusive of ISA address
aliases - AD[15::10] are not decoded)
If the VGA Enable bit is set, forwarding of these accesses is
independent of the I/O address range and memory address ranges
defined by the I/O Base and Limit registers, the Memory Base
and Limit registers, and the Prefetchable Memory Base and Limit
registers of the bridge.
Forwarding of these accesses is also independent of the settings
of the ISA Enable bit (in the Bridge Control register) or VGA
Palette Snoop bits (in the Command register).
The AST2500 hardware we are using do not set the VGA Enable bit on
its bridge control reg, this cause vgaarb subsystem don't think the
VGA card behind this pridge as a valid boot vga device which made
X server choose wrong video card to use when multiple video card
present in the system.
Its seems more vgaarb's fault than the ast2500 bmc itself.
even through bit 3 of Bridge Control Register is 0, it should still
allow to forward the accesses when the addresses is in the range of
IO/MEM Base and Limit registers.
Nevertheless, in order to support loongson CPU product line, we
provide a workaround to this bug for the Sugon L620-G30 and Sugon
L820-G30 server.
see similar bug:
https://patchwork.kernel.org/project/linux-pci/patch/20170619023528.11532-1-dja@axtens.net/
Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Link: deepin-community#192
(cherry picked from commit 9594c78)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
lanlanxiyiji
pushed a commit
that referenced
this pull request
Dec 26, 2025
…ccess configuration space Fix patch "PCI: loongson: Use generic 8/16/32-bit config ops on LS2K/LS7A" Signed-off-by: Tianli Xiong <xiongtianli@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: #192 (cherry picked from commit d6d5fd4) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
lanlanxiyiji
pushed a commit
that referenced
this pull request
Dec 26, 2025
Don't limit mrrs during resume, so that saved value can be restored. Fix patch "PCI: loongson: Improve the MRRS quirk for LS7A" Signed-off-by: Jianmin Lv <lvjianmin@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: #192 (cherry picked from commit 051e311) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
lanlanxiyiji
pushed a commit
that referenced
this pull request
Dec 26, 2025
fix kabi error caused by pm_suspend_target_state,used only by loongson devices. Signed-off-by: Hongchen Zhang <zhanghongchen@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: #192 (cherry picked from commit 00097a0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com> Conflicts: drivers/pci/pci.c
lanlanxiyiji
pushed a commit
that referenced
this pull request
Dec 26, 2025
Fix some pcie card not scanning properly when bus number is inconsistent during firmware and kernel scan phases. Signed-off-by: liuyun <liuyun@loongson.cn> Signed-off-by: Tianli Xiong <xiongtianli@loongson.cn> Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: #192 (cherry picked from commit f8f6e3b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
lanlanxiyiji
pushed a commit
that referenced
this pull request
Dec 26, 2025
According to PCI-to-PCI bridge spec, bit 3 of Bridge Control Register
is VGA Enable bit which modifies the response by the bridge to VGA
compatible addresses.
The Bridge Control register provides extensions to the Command register
that are specific to a bridge. The Bridge Control register provides
many of the same controls for the secondary interface that are provided
by the Command register for the primary interface. There are some bits
that affect the operation of both interfaces of the bridge.
If the VGA Enable bit is set, the bridge will positively decode
and forward the following accesses on the primary interface to
the secondary interface (and, conversely, block the forwarding
of these addresses from the secondary to primary interface)
Forwarding of these accesses is qualified by the I/O Enable and
Memory Enable bits in the Command register.) The default state of
this bit after reset must be 0.
Bit 3 of Bridge Control Register is VGA Enable bit which modifies the
response by the bridge to VGA compatible addresses.
when 0: do not forward VGA compatible memory and I/O addresses from
the primary to secondary interface (addresses defined below)
unless they are enabled for forwarding by the defined I/O
when 1: forward VGA compatible memory and I/O addresses (addresses
defined below) from the primary interface to the secondary
interface (if the I/O Enable and Memory Enable bits are set)
independent of the I/O and memory address ranges and
independent of the ISA Enable bit
* memory accesses in the range 000A 0000h to 000B FFFFh
* I/O addresses in the first 64 KB of the I/O address space
(AD[31:16] are 0000h) where AD[9:: 0] are in the ranges
3B0h to 3BBh and 3C0h to 3DFh (inclusive of ISA address
aliases - AD[15::10] are not decoded)
If the VGA Enable bit is set, forwarding of these accesses is
independent of the I/O address range and memory address ranges
defined by the I/O Base and Limit registers, the Memory Base
and Limit registers, and the Prefetchable Memory Base and Limit
registers of the bridge.
Forwarding of these accesses is also independent of the settings
of the ISA Enable bit (in the Bridge Control register) or VGA
Palette Snoop bits (in the Command register).
The AST2500 hardware we are using do not set the VGA Enable bit on
its bridge control reg, this cause vgaarb subsystem don't think the
VGA card behind this pridge as a valid boot vga device which made
X server choose wrong video card to use when multiple video card
present in the system.
Its seems more vgaarb's fault than the ast2500 bmc itself.
even through bit 3 of Bridge Control Register is 0, it should still
allow to forward the accesses when the addresses is in the range of
IO/MEM Base and Limit registers.
Nevertheless, in order to support loongson CPU product line, we
provide a workaround to this bug for the Sugon L620-G30 and Sugon
L820-G30 server.
see similar bug:
https://patchwork.kernel.org/project/linux-pci/patch/20170619023528.11532-1-dja@axtens.net/
Signed-off-by: suijingfeng <suijingfeng@loongson.cn>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Link: #192
(cherry picked from commit 9594c78)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
opsiff
added a commit
to opsiff/UOS-kernel
that referenced
this pull request
Dec 29, 2025
Per last commit, change phytium irq-gic-phytium-2500.c: From 18fdb63 Mon Sep 17 00:00:00 2001 From: Mark Rutland <mark.rutland@arm.com> Date: Mon, 17 Jun 2024 12:18:41 +0100 Subject: [PATCH] arm64: irqchip/gic-v3: Select priorities at boot time The distributor and PMR/RPR can present different views of the interrupt priority space dependent upon the values of GICD_CTLR.DS and SCR_EL3.FIQ. Currently we treat the distributor's view of the priority space as canonical, and when the two differ we change the way we handle values in the PMR/RPR, using the `gic_nonsecure_priorities` static key to decide what to do. This approach works, but it's sub-optimal. When using pseudo-NMI we manipulate the distributor rarely, and we manipulate the PMR/RPR registers very frequently in code spread out throughout the kernel (e.g. local_irq_{save,restore}()). It would be nicer if we could use fixed values for the PMR/RPR, and dynamically choose the values programmed into the distributor. This patch changes the GICv3 driver and arm64 code accordingly. PMR values are chosen at compile time, and the GICv3 driver determines the appropriate values to program into the distributor at boot time. This removes the need for the `gic_nonsecure_priorities` static key and results in smaller and better generated code for saving/restoring the irqflags. Before this patch, local_irq_disable() compiles to: | 0000000000000000 <outlined_local_irq_disable>: | 0: d503201f nop | 4: d50343df msr daifset, #0x3 | 8: d65f03c0 ret | c: d503201f nop | 10: d2800c00 mov x0, #0x60 // deepin-community#96 | 14: d5184600 msr icc_pmr_el1, x0 | 18: d65f03c0 ret | 1c: d2801400 mov x0, #0xa0 // deepin-community#160 | 20: 17fffffd b 14 <outlined_local_irq_disable+0x14> After this patch, local_irq_disable() compiles to: | 0000000000000000 <outlined_local_irq_disable>: | 0: d503201f nop | 4: d50343df msr daifset, #0x3 | 8: d65f03c0 ret | c: d2801800 mov x0, #0xc0 // deepin-community#192 | 10: d5184600 msr icc_pmr_el1, x0 | 14: d65f03c0 ret ... with 3 fewer instructions per call. For defconfig + CONFIG_PSEUDO_NMI=y, this results in a minor saving of ~4K of text, and will make it easier to make further improvements to the way we manipulate irqflags and DAIF bits. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240617111841.2529370-6-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
opsiff
added a commit
to opsiff/UOS-kernel
that referenced
this pull request
Dec 29, 2025
Per last commit, change phytium irq-gic-phytium-2500.c: From 18fdb63 Mon Sep 17 00:00:00 2001 From: Mark Rutland <mark.rutland@arm.com> Date: Mon, 17 Jun 2024 12:18:41 +0100 Subject: [PATCH] arm64: irqchip/gic-v3: Select priorities at boot time The distributor and PMR/RPR can present different views of the interrupt priority space dependent upon the values of GICD_CTLR.DS and SCR_EL3.FIQ. Currently we treat the distributor's view of the priority space as canonical, and when the two differ we change the way we handle values in the PMR/RPR, using the `gic_nonsecure_priorities` static key to decide what to do. This approach works, but it's sub-optimal. When using pseudo-NMI we manipulate the distributor rarely, and we manipulate the PMR/RPR registers very frequently in code spread out throughout the kernel (e.g. local_irq_{save,restore}()). It would be nicer if we could use fixed values for the PMR/RPR, and dynamically choose the values programmed into the distributor. This patch changes the GICv3 driver and arm64 code accordingly. PMR values are chosen at compile time, and the GICv3 driver determines the appropriate values to program into the distributor at boot time. This removes the need for the `gic_nonsecure_priorities` static key and results in smaller and better generated code for saving/restoring the irqflags. Before this patch, local_irq_disable() compiles to: | 0000000000000000 <outlined_local_irq_disable>: | 0: d503201f nop | 4: d50343df msr daifset, #0x3 | 8: d65f03c0 ret | c: d503201f nop | 10: d2800c00 mov x0, #0x60 // deepin-community#96 | 14: d5184600 msr icc_pmr_el1, x0 | 18: d65f03c0 ret | 1c: d2801400 mov x0, #0xa0 // deepin-community#160 | 20: 17fffffd b 14 <outlined_local_irq_disable+0x14> After this patch, local_irq_disable() compiles to: | 0000000000000000 <outlined_local_irq_disable>: | 0: d503201f nop | 4: d50343df msr daifset, #0x3 | 8: d65f03c0 ret | c: d2801800 mov x0, #0xc0 // deepin-community#192 | 10: d5184600 msr icc_pmr_el1, x0 | 14: d65f03c0 ret ... with 3 fewer instructions per call. For defconfig + CONFIG_PSEUDO_NMI=y, this results in a minor saving of ~4K of text, and will make it easier to make further improvements to the way we manipulate irqflags and DAIF bits. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Alexandru Elisei <alexandru.elisei@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Reviewed-by: Marc Zyngier <maz@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20240617111841.2529370-6-mark.rutland@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 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.
Drop a patch: