PCI / PCIe: Ask BIOS for control of all native services simultaneously
in [Kernel]
|
Prev: bdi: Use parent filesystem BDI for inodes not capable of writeback
Next: [PATCH] checkpatch: Add warnings for use of mdelay()
From: Matthew Garrett on 27 Jul 2010 13:20 On Tue, Jul 27, 2010 at 09:43:41AM +0900, Kenji Kaneshige wrote: > I think this will break PCIe services currently working. For example, > firmware doesn't grant PCIe AER control on my hardware. On the other > hand, firmware grants PCIe native hot-plug control on the same machine. > So I think PCIe hot-plug will not work with your patch. Another example, > what would happen on the platform that doesn't have any PCIe hot-plug > slot? I guess firmware doesn't grant PCIe native hot-plug control on > that environment. So I think all the other PCIe port services would > not work on such platform. I've done some more testing of this and found that my intial belief (supported by Microsoft's documentation...) that all PCIe support had to be handed over for any to be used is incorrect. It turns out that the firmware must support native hotplug, native power management and PCI express capability structure control - ie, SHPC and AER aren't required. However, if any of the other flags are missing then Windows doesn't use any PCIe functionality on the system. That's the behaviour we wish to duplicate. > (1) Query all controls for PCIe port services and see what controls > will be granted to OS by firmware. > (2) Request all the controls acquired in step (1) at the same time. > (3) Create PCIe port services for those controls. > > What do you think about this? I think we need to do: (1) Query all controls and see what will be granted (2) If any of bits 0, 2 and 4 are unsupported, disable all PCIe support via _OSC (3) Ask for the set of supported bits & 0x1d > I think there is still a problem that needs to be addressed. The > problem is that if ACPIPHP (ACPI based hot-plug driver) is required > for PCIe hot- plug, all the PCIe port services needs to be disabled. I > don't think it is acceptable for ACPIPHP users. I believe that that's the only way Windows will work on their system, which generally implies that that's how the machine was intended to run. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 27 Jul 2010 15:00 On Tue, Jul 27, 2010 at 08:42:39PM +0200, Rafael J. Wysocki wrote: > On Tuesday, July 27, 2010, Matthew Garrett wrote: > > I've done some more testing of this and found that my intial belief > > (supported by Microsoft's documentation...) that all PCIe support had to > > be handed over for any to be used is incorrect. It turns out that the > > firmware must support native hotplug, native power management and PCI > > express capability structure control - ie, SHPC and AER aren't required. > > But the ACPI spec says quite explicitly that PCIe capability control is > necessary for AER as well. I may not have been clear. If the firmware doesn't report AER, Windows will use PME and hotplug. If the firmware doesn't support hotplug, Windows will *not* use PME or AER, and ditto if it doesn't support PME. > > (2) If any of bits 0, 2 and 4 are unsupported, disable all PCIe support > > via _OSC > > I guess you mean "don't request control of that services at all"? I mean pass 0 as the third dword in our _OSC call. > > (3) Ask for the set of supported bits & 0x1d > > Really, if we try to treat native PME, native hot-plug and AER separately > (which is our current approach), we fall into a Catch 22 situation where > each of them needs PCIe capability control and once we've received the > control of that, we have no choice but to use the other native sevices as well. It seems that it's valid to have hotplug and PME without AER. The behaviour of Windows for each bit is: 0 Hotplug Required 1 SHPHC Will never request 2 PME Required 3 AER Optional 4 capability control Required So firmware can refuse to support SHPHC and AER and still get PCIe support, but if any of the required bits aren't available Windows won't use *any* of the _OSC-provided functions. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on 28 Jul 2010 08:00
On Wed, Jul 28, 2010 at 12:39:15PM +0900, Hidetoshi Seto wrote: > Hi, > > (2010/07/25 8:05), Rafael J. Wysocki wrote: > > It turns out that asking ACPI BIOS, through _OSC, for control of each > > PCIe port native service individually sometimes confuses the BIOS if > > one sevice is requested while the others are not (eg. requesting > > control of the native PCIe PME without requesting control of the > > native PCIe hot-plug at the same time leads to interrupt storms on > > some systems). > > Then why not invent quirks or something for such systems? Because we'll have a quirk table with dozens of entries and it won't be comprehensive. > IMHO it sounds like a BIOS bug since it should grant PME control to > OS only when both of PME and pciehp (plus PCIe caps) are requested > at same time. We're in the business of writing an operating system that's able to drive the hardware that exists, not just the hardware that follows the specs completely. It's implausible that we'll get every broken BIOS fixed, and it's implausible that we'll be able to work out a list of every broken computer. -- Matthew Garrett | mjg59(a)srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |