search for: pci_bridge_d3_possible

...is meant to avoid issues when suspending ports on older chipsets. However if the port is used for an Optimus GPU and we can clearly identify that, and there's a _PR3 method provided, it's probably safe to say that the port is *intended* to be suspended. So you may want to consider amending pci_bridge_d3_possible() to allow D3 for such ports regardless of the BIOS date, as I've done for Thunderbolt in this commit: https://github.com/l1k/linux/commit/3cb8549cd4e5 Not sure how to uniquely identify such ports though. Perhaps check if there's a device in slot 0 below the port which has (pdev->class...

...when suspending ports > on older chipsets. However if the port is used for an Optimus GPU > and we can clearly identify that, and there's a _PR3 method provided, > it's probably safe to say that the port is *intended* to be suspended. > > So you may want to consider amending pci_bridge_d3_possible() to > allow D3 for such ports regardless of the BIOS date, as I've done > for Thunderbolt in this commit: > https://github.com/l1k/linux/commit/3cb8549cd4e5 Then we have heuristics based on BIOS year, on whether it is TB or not, and next to it whether it is an Optimus laptop? Maybe t...

...i_dev *dev) { int i; diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index fcd81911b127..29dc15bbe3bf 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -83,6 +83,7 @@ void pci_allocate_cap_save_buffers(struct pci_dev *dev); void pci_free_cap_save_buffers(struct pci_dev *dev); bool pci_bridge_d3_possible(struct pci_dev *dev); void pci_bridge_d3_update(struct pci_dev *dev); +void pci_restore_bars(struct pci_dev *dev); static inline void pci_wakeup_event(struct pci_dev *dev) { -- 2.15.1

...> + delay = 500; > > child = list_first_entry(&dev->subordinate->devices, struct pci_dev, > bus_list); > @@ -4715,7 +4710,7 @@ void pci_bridge_wait_for_secondary_bus(struct pci_dev *dev) > * management for them (see pci_bridge_d3_possible()). > */ > if (!pci_is_pcie(dev)) { > - pci_dbg(dev, "waiting %d ms for secondary bus\n", 1000 + delay); > + pci_info(dev, "waiting %d ms for secondary bus\n", 1000 + delay); > msleep(1000 + delay); >...

...bordinate); - if (!delay) { - up_read(&pci_bus_sem); - return; - } + delay = 500; child = list_first_entry(&dev->subordinate->devices, struct pci_dev, bus_list); @@ -4715,7 +4710,7 @@ void pci_bridge_wait_for_secondary_bus(struct pci_dev *dev) * management for them (see pci_bridge_d3_possible()). */ if (!pci_is_pcie(dev)) { - pci_dbg(dev, "waiting %d ms for secondary bus\n", 1000 + delay); + pci_info(dev, "waiting %d ms for secondary bus\n", 1000 + delay); msleep(1000 + delay); return; } @@ -4741,10 +4736,10 @@ void pci_bridge_wait_for_secondary_bus(st...

...Lukas' RPM refcounting patches should be included. A similar (open/new) RPM refcounting issue in snd-hda-intel should also be fixed. Otherwise the bridge will not really sleep. There is another minor patch for nouveau_pr3_present, but it is not included here because it depends on visibility of pci_bridge_d3_possible(). I'll send a separate mail for this to linux-pci. Kind regards, Peter [1]: https://lists.freedesktop.org/archives/nouveau/2016-May/025116.html [2]: https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/?h=pci/pm Peter Wu (4): drm/nouveau/acpi: ensure matching ACPI handle and sup...

On Wed, Nov 20, 2019 at 04:37:14PM +0100, Karol Herbst wrote: > On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > > > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > > > <mika.westerberg at intel.com> wrote: > > > > > >

On Mon, May 30, 2016 at 02:20:10PM +0200, Peter Wu wrote: > On Mon, May 30, 2016 at 12:57:09PM +0300, Mika Westerberg wrote: > > +Rafael > > > > On Fri, May 27, 2016 at 01:10:37PM +0200, Peter Wu wrote: > > > On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote: > > > > On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > > >

On Tue, May 31, 2016 at 01:02:31PM +0200, Peter Wu wrote: > On Tue, May 31, 2016 at 11:43:56AM +0300, Mika Westerberg wrote: > > On Mon, May 30, 2016 at 06:13:51PM +0200, Peter Wu wrote: > > > Do you have any suggestions for the case where the pcieport driver > > > refuses to put the bridge in D3 (because the BIOS is too old)? In that > > > case the nouveau

...--git a/drivers/pci/pci.h b/drivers/pci/pci.h > index fcd81911b127..29dc15bbe3bf 100644 > --- a/drivers/pci/pci.h > +++ b/drivers/pci/pci.h > @@ -83,6 +83,7 @@ void pci_allocate_cap_save_buffers(struct pci_dev *dev); > void pci_free_cap_save_buffers(struct pci_dev *dev); > bool pci_bridge_d3_possible(struct pci_dev *dev); > void pci_bridge_d3_update(struct pci_dev *dev); > +void pci_restore_bars(struct pci_dev *dev); > > static inline void pci_wakeup_event(struct pci_dev *dev) > { > -- > 2.15.1 >

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