| Message ID | 20141121182414.26669.48397.stgit@gimli.home (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
> -----Original Message----- > From: Alex Williamson [mailto:alex.williamson@redhat.com] > Sent: Friday, November 21, 2014 1:24 PM > To: bhelgaas@google.com > Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; Alex > Williamson; Deucher, Alexander > Subject: [PATCH 2/4] PCI: quirk AMD/ATI VGA cards to avoid PM reset > > Some AMD/ATI GPUs report that they support PM reset (NoSoftRst-) but > initiating such a reset has no apparent affect on the device. The > monitor remains sync'd, the framebuffer contents are retained, etc. > Callers of pci_reset_function() don't necessarily have a way to > validate whether a reset was effective, so we really want to avoid > making use of a known non-effective reset. Returning an error in > such cases appears to be the better option. For users like vfio-pci, > this allows the driver to escalate to the bus reset interfaces. > > If a device lives on the root bus, there's really no further > escalation path, so we exempt PM reset as potentially better than > nothing. > > Signed-off-by: Alex Williamson <alex.williamson@redhat.com> > Cc: Alex Deucher <alexander.deucher@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> > --- > > drivers/pci/quirks.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index 90acb32..561e10d 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -3008,6 +3008,27 @@ > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_REALTEK, 0x8169, > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, PCI_ANY_ID, > quirk_broken_intx_masking); > > +static void quirk_no_pm_reset(struct pci_dev *dev) > +{ > + /* > + * A non-effective PM reset may be better than nothing > + * if we can't do a bus reset > + */ > + if (!pci_is_root_bus(dev->bus)) > + dev->dev_flags |= PCI_DEV_FLAGS_NO_PM_RESET; > +} > + > +/* > + * Some AMD/ATI GPUS (HD8570 - Oland) report supporting PM reset via > D3->D0 > + * transition (NoSoftRst-). This reset mechanims seems to have no effect > + * whatsoever on the device, even retaining the framebuffer contents and > + * monitor sync. Advertising this support makes other layers, like VFIO > + * assume pci_reset_function() is viable for this device. Mark it as > + * unavailable to skip it when testing reset methods. > + */ > +DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID, > + PCI_CLASS_DISPLAY_VGA, 8, > quirk_no_pm_reset); > + > #ifdef CONFIG_ACPI > /* > * Apple: Shutdown Cactus Ridge Thunderbolt controller.
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 90acb32..561e10d 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -3008,6 +3008,27 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_REALTEK, 0x8169, DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, PCI_ANY_ID, quirk_broken_intx_masking); +static void quirk_no_pm_reset(struct pci_dev *dev) +{ + /* + * A non-effective PM reset may be better than nothing + * if we can't do a bus reset + */ + if (!pci_is_root_bus(dev->bus)) + dev->dev_flags |= PCI_DEV_FLAGS_NO_PM_RESET; +} + +/* + * Some AMD/ATI GPUS (HD8570 - Oland) report supporting PM reset via D3->D0 + * transition (NoSoftRst-). This reset mechanims seems to have no effect + * whatsoever on the device, even retaining the framebuffer contents and + * monitor sync. Advertising this support makes other layers, like VFIO + * assume pci_reset_function() is viable for this device. Mark it as + * unavailable to skip it when testing reset methods. + */ +DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID, + PCI_CLASS_DISPLAY_VGA, 8, quirk_no_pm_reset); + #ifdef CONFIG_ACPI /* * Apple: Shutdown Cactus Ridge Thunderbolt controller.
Some AMD/ATI GPUs report that they support PM reset (NoSoftRst-) but initiating such a reset has no apparent affect on the device. The monitor remains sync'd, the framebuffer contents are retained, etc. Callers of pci_reset_function() don't necessarily have a way to validate whether a reset was effective, so we really want to avoid making use of a known non-effective reset. Returning an error in such cases appears to be the better option. For users like vfio-pci, this allows the driver to escalate to the bus reset interfaces. If a device lives on the root bus, there's really no further escalation path, so we exempt PM reset as potentially better than nothing. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> --- drivers/pci/quirks.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html