Re: [patch 5/6] PARISC: move PERR SERR enables out of pcibios_enable_resources()
On Thursday, February 28, 2008 9:31 am Grant Grundler wrote: In general, I'm wondering if the check for device class would be sufficient here to NOT enable PERR/SERR for graphics automatically. While disabling PERR was the right thing for older mostly write devices of the 1990's and early 2000, it might not be correct for current 3-D graphics devices which use host mem to buffer processed results. I'm thinking of Intel graphics controllers in particular but I don't know any details of how they actually work. Well, in general chipset devices aren't required to support parity checking, AIUI; Intel gfx devices don't bother (PERR enable is hardwired to 0). I'm also a bit concerned about this now becuase (IIRC) AGP didn't implement parity though it looked like PCI protocol. PCI-e certainly does but it's possible BIOS/Firmware disable parity generation on the host bridge when connected to a gfx device. We wouldn't want to enable parity checking on a PCI-e gfx device in this case and I hope someone (perhaps at Intel) could double check this. I'd have to ping our BIOS folks to see if that's the case, but I doubt it. It would be a bad idea to disable any PCIe error reporting (including legacy error mapping) just because a gfx device was attached. Apparently the AMD PCIe parts include PERR generation, so disabling upstream reporting at boot time seems like it would be an outright bug; it should be left up to driver OS software. Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] PARISC: move PERR SERR enables out of pcibios_enable_resources()
On Wed, Feb 27, 2008 at 05:04:42PM -0700, Bjorn Helgaas wrote: Move PERR and SERR enables from pcibios_enable_resources() to platform_pci_enable_device() so the former matches other architectures and can be shared. Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Ack-By: Grant Grundler [EMAIL PROTECTED] This patch sequence is heading in the right direction. I've not tested this particular one yet but I'm pretty sure it's ok. I'll fixup any breakage for parisc. ... +/* + * A driver is enabling the device. We enable the PERR and SERR bits + * unconditionally. Drivers that do not need parity (eg graphics and + * possibly networking) can clear these bits if they want. + */ +static int platform_pci_enable_device(struct pci_dev *dev) Thanks for preserving this comment. In general, I'm wondering if the check for device class would be sufficient here to NOT enable PERR/SERR for graphics automatically. While disabling PERR was the right thing for older mostly write devices of the 1990's and early 2000, it might not be correct for current 3-D graphics devices which use host mem to buffer processed results. I'm thinking of Intel graphics controllers in particular but I don't know any details of how they actually work. I'm also a bit concerned about this now becuase (IIRC) AGP didn't implement parity though it looked like PCI protocol. PCI-e certainly does but it's possible BIOS/Firmware disable parity generation on the host bridge when connected to a gfx device. We wouldn't want to enable parity checking on a PCI-e gfx device in this case and I hope someone (perhaps at Intel) could double check this. thanks, grant ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 5/6] PARISC: move PERR SERR enables out of pcibios_enable_resources()
On Wed, Feb 27, 2008 at 05:04:42PM -0700, Bjorn Helgaas wrote: Move PERR and SERR enables from pcibios_enable_resources() to platform_pci_enable_device() so the former matches other architectures and can be shared. I don't have any problems with this, but I think the naming needs to change. pcibios_* namespace should probably remain arch dependent. Renaming the unified implementation to pci_enable_resources, and adding a weak function pcibios_enable_resources that can be overridden by parisc and arm to enable PERR/SERR after calling the generic pci_enable_resources function. No? regards, Kyle ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 5/6] PARISC: move PERR SERR enables out of pcibios_enable_resources()
Move PERR and SERR enables from pcibios_enable_resources() to
platform_pci_enable_device() so the former matches other
architectures and can be shared.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: work6/arch/parisc/kernel/pci.c
===
--- work6.orig/arch/parisc/kernel/pci.c 2008-02-27 11:30:02.0 -0700
+++ work6/arch/parisc/kernel/pci.c 2008-02-27 11:38:11.0 -0700
@@ -281,9 +281,7 @@
* A driver is enabling the device. We make sure that all the appropriate
* bits are set to allow the device to operate as the driver is expecting.
* We enable the port IO and memory IO bits if the device has any BARs of
- * that type, and we enable the PERR and SERR bits unconditionally.
- * Drivers that do not need parity (eg graphics and possibly networking)
- * can clear these bits if they want.
+ * that type.
*/
int pcibios_enable_resources(struct pci_dev *dev, int mask)
{
@@ -305,8 +303,6 @@
cmd |= PCI_COMMAND_MEMORY;
}
- cmd |= (PCI_COMMAND_SERR | PCI_COMMAND_PARITY);
-
#if 0
/* If bridge/bus controller has FBB enabled, child must too. */
if (dev-bus-bridge_ctl PCI_BRIDGE_CTL_FAST_BACK)
@@ -317,9 +313,38 @@
return 0;
}
+/*
+ * A driver is enabling the device. We enable the PERR and SERR bits
+ * unconditionally. Drivers that do not need parity (eg graphics and
+ * possibly networking) can clear these bits if they want.
+ */
+static int platform_pci_enable_device(struct pci_dev *dev)
+{
+ u16 cmd, old_cmd;
+ int idx;
+
+ pci_read_config_word(dev, PCI_COMMAND, cmd);
+ old_cmd = cmd;
+
+ cmd |= (PCI_COMMAND_SERR | PCI_COMMAND_PARITY);
+
+ if (cmd != old_cmd) {
+ dev_info(dev-dev, enabling SERR and PARITY (%04x - %04x)\n,
+ old_cmd, cmd);
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
+ }
+
+ return 0;
+}
+
int pcibios_enable_device(struct pci_dev *dev, int mask)
{
- return pcibios_enable_resources(dev, mask);
+ int err;
+
+ if ((err = pcibios_enable_resources(dev, mask)) 0)
+ return err;
+
+ return platform_pci_enable_device(dev);
}
/* PA-RISC specific */
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
