On Friday 01 January 2010, Andreas Mohr wrote: > Hi, > > On Fri, Jan 01, 2010 at 07:55:27PM +0100, Rafael J. Wysocki wrote: > > On Friday 01 January 2010, Andreas Mohr wrote: > > > Hi, > > > > > > While the bug report mentions "So it's just quirky hardware.", > > > the implementation of your patch makes it seem like this delay attribute is > > > totally "norm"al behaviour - I'm missing some more aggressive wording. > > > > That's because it works both ways (please look at the changelog). > > Ah, ok. > > > I know of a few devices that don't need the PCI-prescribed 10 ms wait when > > going from D3 to D0 and their drivers may use the d3_delay field to actually > > set a _shorter_ delay. > > Then why is the value lower-bounded by pci_pm_d3_delay > (which, puzzlingly, was initialized to PCI_PM_D3_WAIT and thus 10 > before, which the patch now removes!), That's because dev->d3_delay is initialized to PCI_PM_D3_WAIT for all devices. > in pci_dev_d3_sleep()? (and pci_pm_d3_delay is being quirked in > drivers/pci/quirks.c only, to 120) Exactly because pci_pm_d3_delay is only necessary for some quirky chipsets that require longer delays for _all_ devices (note that this cannot be handled at the driver level). So, we use dev->d3_delay (that the driver gave us), unless the chipset is known to be quirky and requires a longer delay for all devices (the driver has no chance to know about that). Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
