Displaying 6 results from an estimated 6 matches for "8b71f565".
2016 May 30
2
[PATCH 1/9] drm/nouveau: Don't leak runtime pm ref on driver unload
...2. Verify in the kernel logs that the devices are sleeping:
pcieport 0000:00:01.0: power state changed by ACPI to D3cold
3. (Optional, to rule out issues with delays:) Disable rpm for the
Nvidia device (control = on).
4. modprobe nouveau.
The above test with v4.6 + 4 pci/pm patches (8b71f565) gives:
50.245795 MXM: GUID detected in BIOS
50.245948 nseval-0227 ns_evaluate : **** Execute method [\_SB.PCI0.GFX0._DSM] at AML address ffffc90000013b11 length 492
50.246016 ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Pac...
2016 May 31
2
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
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 driver needs to fallback to the DSM method (but not
> when runtime PM is deliberately disabled by writing control=on).
Do you know what Windows does then? I think we
2016 Jun 01
1
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
...x kernel claims support for Windows 8, but does not
> use PR3, then we are probably approaching an untested area. So far
> firmware seems fine with using *only* DSM *or* PR3, but at least my
> laptop gets confused when you use both at the same time.
>
> The latter happens on pci/pm (8b71f565) without other patches:
>
> 1. nouveau invokes _DSM and _PS3, device is put in D3cold.
> 2. pcieport driver calls PG00._OFF (PG00 is returned by _PR3).
> 3. Wake up Nvidia device (e.g. by power=on).
> 4. This will trigger PG00._ON (via pcieport) and _PS0 (via nouveau).
> 5....
2016 May 31
0
[PATCH 1/9] drm/nouveau: Don't leak runtime pm ref on driver unload
...that the devices are sleeping:
> pcieport 0000:00:01.0: power state changed by ACPI to D3cold
> 3. (Optional, to rule out issues with delays:) Disable rpm for the
> Nvidia device (control = on).
> 4. modprobe nouveau.
>
> The above test with v4.6 + 4 pci/pm patches (8b71f565) gives:
>
> 50.245795 MXM: GUID detected in BIOS
> 50.245948 nseval-0227 ns_evaluate : **** Execute method [\_SB.PCI0.GFX0._DSM] at AML address ffffc90000013b11 length 492
> 50.246016 ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer]...
2016 May 31
0
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
...used
anyway. If the Linux kernel claims support for Windows 8, but does not
use PR3, then we are probably approaching an untested area. So far
firmware seems fine with using *only* DSM *or* PR3, but at least my
laptop gets confused when you use both at the same time.
The latter happens on pci/pm (8b71f565) without other patches:
1. nouveau invokes _DSM and _PS3, device is put in D3cold.
2. pcieport driver calls PG00._OFF (PG00 is returned by _PR3).
3. Wake up Nvidia device (e.g. by power=on).
4. This will trigger PG00._ON (via pcieport) and _PS0 (via nouveau).
5. Nvidia card is not really read...
2016 May 27
2
[PATCH 1/9] drm/nouveau: Don't leak runtime pm ref on driver unload
On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0,
> but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally.
> We therefore leak a runtime pm ref whenever nouveau is loaded with
> runpm=0 and then unloaded. The GPU will subsequently never runtime
> suspend even if nouveau is loaded again