PCI bridges integrated in new VIA chipset/SoC have no DAC issue.
Enable DAC for the platforms with these chipset/SoC can improve DMA performance about
20% when DRAM size > 4GB.
Signed-off-by: David Wang <[email protected]>
---
arch/x86/kernel/pci-dma.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index cb9c1fa..6e37b0e 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -47,6 +47,10 @@
extern struct iommu_table_entry __iommu_table[], __iommu_table_end[];
+#ifdef CONFIG_PCI
+static int override_via_dac __read_mostly;
+#endif
+
/* Dummy device used for NULL arguments (normally ISA). */
struct device x86_dma_fallback_dev = {
.init_name = "fallback device",
@@ -279,6 +283,9 @@ static int __init pci_iommu_init(void)
static void via_no_dac(struct pci_dev *dev)
{
+ if (override_via_dac)
+ return;
+
if (forbid_dac == 0) {
dev_info(&dev->dev, "disabling DAC on VIA PCI bridge\n");
forbid_dac = 1;
@@ -286,4 +293,19 @@ static void via_no_dac(struct pci_dev *dev)
}
DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
PCI_CLASS_BRIDGE_PCI, 8, via_no_dac);
+
+static void via_can_dac(struct pci_dev *dev)
+{
+ /*
+ * New VIA bridges have no issues for DAC.
+ * Disable the "via_no_dac" fixup code for these new VIA bridges.
+ */
+ override_via_dac = 1;
+}
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, 0x345B,
+ PCI_CLASS_BRIDGE_ISA, 8, via_can_dac);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, 0x1001,
+ PCI_CLASS_BRIDGE_ISA, 8, via_can_dac);
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, 0x300A,
+ PCI_CLASS_BRIDGE_ISA, 8, via_can_dac);
#endif
--
1.9.1
On Mon, Apr 16, 2018 at 05:26:56PM +0800, David Wang wrote:
> PCI bridges integrated in new VIA chipset/SoC have no DAC issue.
> Enable DAC for the platforms with these chipset/SoC can improve DMA performance about
> 20% when DRAM size > 4GB.
>
So we get an exception to an exception? Is there any way to figure
out the PCI IDs actually affected?
> -----?ʼ?ԭ??-----
> ??????: Christoph Hellwig [mailto:[email protected]]
> ????ʱ??: 2018??4??16?? 20:34
> ?ռ???: David Wang <[email protected]>
> ????: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected];
> [email protected]; [email protected];
> [email protected]; [email protected]; [email protected]
> ????: Re: [PATCH] x86/dma-mapping: override via_no_dac for new VIA PCI
> bridges
>
> On Mon, Apr 16, 2018 at 05:26:56PM +0800, David Wang wrote:
> > PCI bridges integrated in new VIA chipset/SoC have no DAC issue.
> > Enable DAC for the platforms with these chipset/SoC can improve DMA
> > performance about 20% when DRAM size > 4GB.
> >
>
> So we get an exception to an exception? Is there any way to figure out
the
> PCI IDs actually affected?
Yes.
Do you mean we should list the PCI IDs of the PCI bridges which have no DAC
issue?
There are lots of PCI bridges(PCIE root ports) in our new chipsets/SoCs. And
no DMA issues found.
So, we only want to recognize the chipset/SoC by reading VID/DID of Bus 0,
Device 17, function 0.
Thx.
---
David
On Tue, 17 Apr 2018, David Wang wrote:
> > On Mon, Apr 16, 2018 at 05:26:56PM +0800, David Wang wrote:
> > > PCI bridges integrated in new VIA chipset/SoC have no DAC issue.
> > > Enable DAC for the platforms with these chipset/SoC can improve DMA
> > > performance about 20% when DRAM size > 4GB.
> > >
> >
> > So we get an exception to an exception? Is there any way to figure out
> the
> > PCI IDs actually affected?
> Yes.
>
> Do you mean we should list the PCI IDs of the PCI bridges which have no DAC
> issue?
The question was rather to have a list of PCI IDs for those chipsets which
have the problem and set the 'disable' flag only for those. That makes a lot
more sense than making a list of new chips which disable the disable flag.
Thanks,
tglx
On Tue, Apr 17, 2018 at 10:54:37AM +0200, Thomas Gleixner wrote:
> The question was rather to have a list of PCI IDs for those chipsets which
> have the problem and set the 'disable' flag only for those. That makes a lot
> more sense than making a list of new chips which disable the disable flag.
Agreed.
There are a few other things I'd like to do in this area while we're
at it (I'm happy to do the work, not trying to offload it to David
or Thomas):
(1) make the nodac flag a per-device flag. Set for every device
under one of the affected VIA bridges, or for all PCI devices
if the nodac command line option is used
(2) move that flag into the common struct device (or the to be
designed dma struct hanging off it in the future) and make that
bit handled in common code as there is a common Xilinx host
bridge with a 32-bit dma limitation
(3) kill of the forcesac option, which was a strange performance
tweak back in plain PCI days, which probably didn't even work
as expected to start with.
On Tue, 17 Apr 2018, 'Christoph Hellwig' wrote:
> On Tue, Apr 17, 2018 at 10:54:37AM +0200, Thomas Gleixner wrote:
> > The question was rather to have a list of PCI IDs for those chipsets which
> > have the problem and set the 'disable' flag only for those. That makes a lot
> > more sense than making a list of new chips which disable the disable flag.
>
> Agreed.
>
> There are a few other things I'd like to do in this area while we're
> at it (I'm happy to do the work, not trying to offload it to David
> or Thomas):
>
> (1) make the nodac flag a per-device flag. Set for every device
> under one of the affected VIA bridges, or for all PCI devices
> if the nodac command line option is used
> (2) move that flag into the common struct device (or the to be
> designed dma struct hanging off it in the future) and make that
> bit handled in common code as there is a common Xilinx host
> bridge with a 32-bit dma limitation
> (3) kill of the forcesac option, which was a strange performance
> tweak back in plain PCI days, which probably didn't even work
> as expected to start with.
Sounds good.