On Fri, Jun 14, 2019 at 4:03 AM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > Is it possible that this works on Windows but not Linux because they > handle ACPI hotplug slightly differently? > > Martin did some nice debug [1] and found that _DSM, _PS0, and _PS3 > functions write the config bit at 0x488. The dmesg log [2] from > zigarrre seems to show that _OSC failed (which I *think* means we > won't use pciehp) and that there's a slot registered by acpiphp. > > Maybe this works on Windows via an ACPI hotplug event that runs AML to > flip the 0x488 bit and rescans the bus? That would make more sense to > me than the idea that the Nvidia driver does it. I could imagine the > driver flipping the bit, but the bus rescan seems like it would be out > of the driver's purview. Oh, I had missed that part of the conversation. I checked on the Acer Predator G3-572 and I was able to find ACPI code to manipulate the magic bit, however I can't see any linkage to _DSM methods, and the code looks like it would only be run on power-up. I modified the DSDT to avoid the codepaths that tweak the bit, booted Windows and confirmed that change had taken effect. Then I installed the nvidia driver and observed that the magic bit was being manipulated according to HDMI cable status. So I believe the nvidia Windows driver does not rely on ACPI for this to work. It presumably does it directly and causes rescans, as evil as that sounds. I added more details to the bug report. > The dmesg log also shows some _DSM warnings; are these correlated with > cable plug/unplug? Is there some acpiphp debug we can turn on to get > more visibility into hotplug events and how we handle them? I scattered a load of debug messages around the ACPI & PCIe hotplug code but nothing gets hit. I don't think this is architected to be handled by existing PCI hotplug mechanisms. I don't have any _DSM warnings on this product, even after connecting and disconnecting the HDMI cable. Thanks Daniel
