> + * probably caused by not meeting the expectation the involved AML code has> + * when the GPU is put into D3hot state before invoking it.> + *> + * This leads to various manifestations of this issue:> + * - AML code execution to power on the GPU hits an infinite loop (as the> + * code waits on device memory to change).> + * - kernel crashes, as all PCI reads return -1, which most code isn't able> + * to handle well enough.> + *> + * In all cases dmesg will contain at least one line like this:> + * 'nouveau 0000:01:00.0: Refused to change power state, currently in D3'> + * followed by a lot of nouveau timeouts.> + *> + * In the \_SB.PCI0.PEG0.PG00._OFF code deeper down writes bit 0x80 to the not> + * documented PCI config space register 0x248 of the Intel PCIe bridge> + * controller (0x1901) in order to change the state of the PCIe link between> + * the PCIe port and the GPU. There are alternative code paths using other> + * registers, which seem to work fine (executed pre Windows 8):> + * - 0xbc bit 0x20 (publicly available documentation claims 'reserved')> + * - 0xb0 bit 0x10 (link disable)> + * Changing the conditions inside the firmware by poking into the relevant> + * addresses does resolve the issue, but it seemed to be ACPI private memory> + * and not any device accessible memory at all, so there is no portable way of> + * changing the conditions.> + * On a XPS 9560 that means bits [0,3] on \CPEX need to be cleared.> + *> + * The only systems where this behavior can be seen are hybrid graphics laptops> + * with a secondary Nvidia Maxwell, Pascal or Turing GPU. Its unclear wheather ^^^ ^^^^^^^^Its -> It'swheather -> whether