search for: pci_restore_bars

...PM status > + * always remain in D0 regardless of the runtime PM status. > + * But if its parent can go to D3cold, this device may have > + * been in D3cold as well and require restoration of its BARs. > */ > - if (!pci_dev->driver) > + if (!pci_dev->driver) { > + pci_restore_bars(pci_dev); If we do decide not to do a full-blown restore, how do we decide whether to use pci_restore_bars() or pci_restore_config_space()? I'm not sure why we have both. The pci_restore_bars() path looks a little smarter in that it is more careful when updating 64-bit BARs that can't be...

...ain in D0 regardless of the runtime PM status + * always remain in D0 regardless of the runtime PM status. + * But if its parent can go to D3cold, this device may have + * been in D3cold as well and require restoration of its BARs. */ - if (!pci_dev->driver) + if (!pci_dev->driver) { + pci_restore_bars(pci_dev); return 0; + } if (!pm || !pm->runtime_resume) return -ENOSYS; diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index f6a4dd10d9b0..f694650235f2 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -563,7 +563,7 @@ int pci_wait_for_pending(struct pci_dev *dev, int pos,...

...the runtime PM status. >> + * But if its parent can go to D3cold, this device may have >> + * been in D3cold as well and require restoration of its BARs. >> */ >> - if (!pci_dev->driver) >> + if (!pci_dev->driver) { >> + pci_restore_bars(pci_dev); > > If we do decide not to do a full-blown restore, how do we decide > whether to use pci_restore_bars() or pci_restore_config_space()? > > I'm not sure why we have both. Me neither. > The pci_restore_bars() path looks a > little smarter in that it is more caref...

...t;> + * But if its parent can go to D3cold, this device may have > >> + * been in D3cold as well and require restoration of its BARs. > >> */ > >> - if (!pci_dev->driver) > >> + if (!pci_dev->driver) { > >> + pci_restore_bars(pci_dev); > > > > If we do decide not to do a full-blown restore, how do we decide > > whether to use pci_restore_bars() or pci_restore_config_space()? > > > > I'm not sure why we have both. > > Me neither. > > > The pci_restore_bars() path looks a...

Modernize vga_switcheroo by using a "device link" to enforce a runtime PM dependency from an HDA controller to the GPU it's integrated into. Remove thereby obsoleted code and fix a bunch of bugs. Device links were introduced in v4.10. Users might see a small power saving if the discrete GPU is in use and its HDA controller is not, because the HDA controller is now allowed to runtime

...(&pdev->dev.kobj, &pci_config_attr); else diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 259eaff..400d3b3 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -356,25 +356,10 @@ pci_find_parent_resource(const struct pci_dev *dev, struct resource *res) static void pci_restore_bars(struct pci_dev *dev) { - int i, numres; - - switch (dev->hdr_type) { - case PCI_HEADER_TYPE_NORMAL: - numres = 6; - break; - case PCI_HEADER_TYPE_BRIDGE: - numres = 2; - break; - case PCI_HEADER_TYPE_CARDBUS:...

...(&pdev->dev.kobj, &pci_config_attr); else diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index 259eaff..400d3b3 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -356,25 +356,10 @@ pci_find_parent_resource(const struct pci_dev *dev, struct resource *res) static void pci_restore_bars(struct pci_dev *dev) { - int i, numres; - - switch (dev->hdr_type) { - case PCI_HEADER_TYPE_NORMAL: - numres = 6; - break; - case PCI_HEADER_TYPE_BRIDGE: - numres = 2; - break; - case PCI_HEADER_TYPE_CARDBUS:...

...the BARs on a D3hot/cold to D0 transition. There are some comments in this upstream cset about why that is: http://www.kernel.org/hg/linux-2.6/rev/8f33e29c89a7 However, we obviously can''t expect PCI devices to work without their BARs properly programmed. The patch below adds a call to pci_restore_bars() as a workaround until we can figure out why the PCI code doesn''t do this for us. Thanks, Alex Signed-off-by: Alex Williamson <alex.williamson@hp.com> --- diff -r 56caf0e37e6a linux-2.6-xen-sparse/drivers/xen/pciback/conf_space_capability_pm.c --- a/linux-2.6-xen-sparse/drivers...

...) { struct resource *res = &pci_dev->resource[i]; diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index c9884bb..c1108ed 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -356,25 +356,10 @@ pci_find_parent_resource(const struct pci_dev *dev, struct resource *res) static void pci_restore_bars(struct pci_dev *dev) { - int i, numres; - - switch (dev->hdr_type) { - case PCI_HEADER_TYPE_NORMAL: - numres = 6; - break; - case PCI_HEADER_TYPE_BRIDGE: - numres = 2; - break; - case PCI_HEADER_TYPE_CARDBUS: - numres = 1; - break; - default: - /* Should never get here, but just in case....

...) { struct resource *res = &pci_dev->resource[i]; diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index c9884bb..c1108ed 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -356,25 +356,10 @@ pci_find_parent_resource(const struct pci_dev *dev, struct resource *res) static void pci_restore_bars(struct pci_dev *dev) { - int i, numres; - - switch (dev->hdr_type) { - case PCI_HEADER_TYPE_NORMAL: - numres = 6; - break; - case PCI_HEADER_TYPE_BRIDGE: - numres = 2; - break; - case PCI_HEADER_TYPE_CARDBUS: - numres = 1; - break; - default: - /* Should never get here, but just in case....

...) { struct resource *res = &pci_dev->resource[i]; diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index c9884bb..c1108ed 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -356,25 +356,10 @@ pci_find_parent_resource(const struct pci_dev *dev, struct resource *res) static void pci_restore_bars(struct pci_dev *dev) { - int i, numres; - - switch (dev->hdr_type) { - case PCI_HEADER_TYPE_NORMAL: - numres = 6; - break; - case PCI_HEADER_TYPE_BRIDGE: - numres = 2; - break; - case PCI_HEADER_TYPE_CARDBUS: - numres = 1; - break; - default: - /* Should never get here, but just in case....

...remove unnecessary APIs (pci_iov_enable/disable). --- [PATCH 1/13 v7] PCI: enhance pci_ari_enabled() [PATCH 2/13 v7] PCI: remove unnecessary arg of pci_update_resource() [PATCH 3/13 v7] PCI: define PCI resource names in an 'enum' [PATCH 4/13 v7] PCI: remove unnecessary condition check in pci_restore_bars() [PATCH 5/13 v7] PCI: export __pci_read_base() [PATCH 6/13 v7] PCI: make pci_alloc_child_bus() be able to handle NULL bridge [PATCH 7/13 v7] PCI: add a new function to map BAR offset [PATCH 8/13 v7] PCI: cleanup pci_bus_add_devices() [PATCH 9/13 v7] PCI: split a new function from pci_bus_add_devic...

...remove unnecessary APIs (pci_iov_enable/disable). --- [PATCH 1/13 v7] PCI: enhance pci_ari_enabled() [PATCH 2/13 v7] PCI: remove unnecessary arg of pci_update_resource() [PATCH 3/13 v7] PCI: define PCI resource names in an 'enum' [PATCH 4/13 v7] PCI: remove unnecessary condition check in pci_restore_bars() [PATCH 5/13 v7] PCI: export __pci_read_base() [PATCH 6/13 v7] PCI: make pci_alloc_child_bus() be able to handle NULL bridge [PATCH 7/13 v7] PCI: add a new function to map BAR offset [PATCH 8/13 v7] PCI: cleanup pci_bus_add_devices() [PATCH 9/13 v7] PCI: split a new function from pci_bus_add_devic...

...remove unnecessary APIs (pci_iov_enable/disable). --- [PATCH 1/13 v7] PCI: enhance pci_ari_enabled() [PATCH 2/13 v7] PCI: remove unnecessary arg of pci_update_resource() [PATCH 3/13 v7] PCI: define PCI resource names in an 'enum' [PATCH 4/13 v7] PCI: remove unnecessary condition check in pci_restore_bars() [PATCH 5/13 v7] PCI: export __pci_read_base() [PATCH 6/13 v7] PCI: make pci_alloc_child_bus() be able to handle NULL bridge [PATCH 7/13 v7] PCI: add a new function to map BAR offset [PATCH 8/13 v7] PCI: cleanup pci_bus_add_devices() [PATCH 9/13 v7] PCI: split a new function from pci_bus_add_devic...

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Major changes between v4 -> v5: 1, remove interfaces for PF driver to create sysfs entries (Matthew

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Major changes between v4 -> v5: 1, remove interfaces for PF driver to create sysfs entries (Matthew

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Changes from v5 to v6: 1, update ABI document to include SR-IOV sysfs entries (Greg KH) 2, fix two coding

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Changes from v5 to v6: 1, update ABI document to include SR-IOV sysfs entries (Greg KH) 2, fix two coding

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. Changes from v5 to v6: 1, update ABI document to include SR-IOV sysfs entries (Greg KH) 2, fix two coding

Greetings, Following patches are intended to support SR-IOV capability in the Linux kernel. With these patches, people can turn a PCI device with the capability into multiple ones from software perspective, which will benefit KVM and achieve other purposes such as QoS, security, and etc. [PATCH 1/8 v4] PCI: define PCI resource names in a 'enum' [PATCH 2/8 v4] PCI: export __pci_read_base