Re: [Nouveau] [PATCH v2 8/9] acpi: Add support for Apple Gmux _DMS
Hi Lukas
- Mail original -
> Hi Pierre,
>
> On Thu, May 28, 2015 at 10:52:56AM +0200, Pierre Moreau wrote:
> > How is it supposed to work, by simply echo'ing ON or OFF to
> > vga_switcheroo/switch? Then I probably forgot some stuff as
> > it doesn't want to work on my laptop.
>
> What exactly doesn't work and which version of the MacBook Pro did
> you try this on? The expected behaviour when switching GPUs on the
> MBP is that the GPU that was inactive on bootup will only show a
> black screen because it was unable to read the EDID (and DPCD on
> retina MBPs) on bootup. In other words, it's broken.
I'm trying on a mid-2009 MBP, which has a double NVidia setup with a 9400M as
IGD and 9600M GT as DIS. Switching between both works (as long as do a
PCI-reset of the G96, but that's another story and I should have a patch soon,
hopefully).
It was also tested by another user on a retina MBP and we ran into the black
screen issue. I pointed him to your patches, but I don't know yet if it helped
or not.
>
> There have been attempts to solve this by multiple folks, the last
> one was submitted to dri-devel in April by yours truly:
> http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html
>
> That initial version of my patch set turned out to only work on
> pre-retina MBPs, and only if the active GPU on bootup is the
> discrete one. I'm currently working on a v2 to solve all that.
Cool! Looking forward to it!
>
> We need to get switching working before we can enable runtime PM on
> MBPs, otherwise the user will be greeted by a black screen when the
> Nvidia GPU goes to sleep and hands over to the integrated GPU.
> So your patch is a bit premature I'm afraid. :-(
It's power management++: we even save energy on the screen by "powering it off"
for better battery life! ;)
>
>
> As to the patch itself, you're checking for existence of the gmux
> but we can't make use of it unless its driver is loaded. Hence it
> may be easier to simply query for the existence of the driver,
> using something along the lines of find_module("apple-gmux").
> I imagine this is much less code than checking for the DMI IDs.
I didn't know there was such a function! Seems nice!
>
> Also, Dave Airlie and Matthew Garrett already wrote a patch set to
> enable runtime PM for nouveau on MBPs which is more generic: It works
> with any vga_switcheroo handler, not just gmux:
>
> http://lists.freedesktop.org/archives/dri-devel/2014-June/060927.html
> http://lists.freedesktop.org/archives/dri-devel/2014-June/060928.html
> http://lists.freedesktop.org/archives/dri-devel/2014-June/060942.html
> http://www.codon.org.uk/~mjg59/tmp/retina_patches/0027-nouveau-enable-runtime-pm-on-apple-gmux-machines.patch
> http://www.codon.org.uk/~mjg59/tmp/retina_patches/0028-nouveau-Enable-switcheroo-dynamic-PM-at-switcheroo-e.patch
>
> The fourth one in that list is by Dave Airlie and all the others are
> by Matthew Garrett. But, as I said, we can't apply these either until
> switching works. I'm working on it. ;-)
I had no idea these patches existed: I should have looked around before.
I'll drop the patches, apart probably from the *cleaning* ones, but I'll wait
for the previously mentioned ones to first land.
>
>
> As to your questions:
>
> > How is it supposed to work, by simply echo'ing ON or OFF to
> > vga_switcheroo/switch?
>
> Echoing ON/OFF to the "switch" file will power the inactive device
> up or down. If the currently active gpu is the discrete one (which
> is the default when booting a MacBook Pro)
Not on the mid-2009 MBP! ;) Which is great!
> , this will power up/down
> the integrated gpu. You can use the tool "gpu-switch" to force the
> MBP to the integrated GPU on next bootup, then you can echo ON/OFFI'ddd
> to change the power state of the Nvidia GPU:
> https://github.com/0xbb/gpu-switch
>
> > If I understand it correctly, if the laptop is an Optimus one or
> > has a mux, we are not "allowed" to opt-out of DynPwr/DynOff by
> > powering down the card?
>
> If we power the GPU down manually by echoing OFF to the "switch"
> file, the runtime PM code would probably get confused, I imagine
> that's the reason why ON/OFF is ignored if
> client->driver_power_control
> is set to true.
I would have guessed that runtime pm would then get disabled.
>
> Speaking of which, the external ports of the MBP are soldered to
> the discrete GPU and can't be switched. Only the panel can be
> switched. So if there are DP or HDMI connectors with status
> connected, we can't suspend. That's one of the MBP's numerous
> peculiarities that I haven't verified yet they're handled properly
> by the code.
I could check that on my MBP if you want.
Best regards,
Pierre
>
> Best regards,
>
> Lukas
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 8/9] acpi: Add support for Apple Gmux _DMS
Hi Pierre,
On Thu, May 28, 2015 at 10:52:56AM +0200, Pierre Moreau wrote:
> How is it supposed to work, by simply echo'ing ON or OFF to
> vga_switcheroo/switch? Then I probably forgot some stuff as
> it doesn't want to work on my laptop.
What exactly doesn't work and which version of the MacBook Pro did
you try this on? The expected behaviour when switching GPUs on the
MBP is that the GPU that was inactive on bootup will only show a
black screen because it was unable to read the EDID (and DPCD on
retina MBPs) on bootup. In other words, it's broken.
There have been attempts to solve this by multiple folks, the last
one was submitted to dri-devel in April by yours truly:
http://lists.freedesktop.org/archives/dri-devel/2015-April/081515.html
That initial version of my patch set turned out to only work on
pre-retina MBPs, and only if the active GPU on bootup is the
discrete one. I'm currently working on a v2 to solve all that.
We need to get switching working before we can enable runtime PM on
MBPs, otherwise the user will be greeted by a black screen when the
Nvidia GPU goes to sleep and hands over to the integrated GPU.
So your patch is a bit premature I'm afraid. :-(
As to the patch itself, you're checking for existence of the gmux
but we can't make use of it unless its driver is loaded. Hence it
may be easier to simply query for the existence of the driver,
using something along the lines of find_module("apple-gmux").
I imagine this is much less code than checking for the DMI IDs.
Also, Dave Airlie and Matthew Garrett already wrote a patch set to
enable runtime PM for nouveau on MBPs which is more generic: It works
with any vga_switcheroo handler, not just gmux:
http://lists.freedesktop.org/archives/dri-devel/2014-June/060927.html
http://lists.freedesktop.org/archives/dri-devel/2014-June/060928.html
http://lists.freedesktop.org/archives/dri-devel/2014-June/060942.html
http://www.codon.org.uk/~mjg59/tmp/retina_patches/0027-nouveau-enable-runtime-pm-on-apple-gmux-machines.patch
http://www.codon.org.uk/~mjg59/tmp/retina_patches/0028-nouveau-Enable-switcheroo-dynamic-PM-at-switcheroo-e.patch
The fourth one in that list is by Dave Airlie and all the others are
by Matthew Garrett. But, as I said, we can't apply these either until
switching works. I'm working on it. ;-)
As to your questions:
> How is it supposed to work, by simply echo'ing ON or OFF to
> vga_switcheroo/switch?
Echoing ON/OFF to the "switch" file will power the inactive device
up or down. If the currently active gpu is the discrete one (which
is the default when booting a MacBook Pro), this will power up/down
the integrated gpu. You can use the tool "gpu-switch" to force the
MBP to the integrated GPU on next bootup, then you can echo ON/OFF
to change the power state of the Nvidia GPU:
https://github.com/0xbb/gpu-switch
> If I understand it correctly, if the laptop is an Optimus one or
> has a mux, we are not "allowed" to opt-out of DynPwr/DynOff by
> powering down the card?
If we power the GPU down manually by echoing OFF to the "switch"
file, the runtime PM code would probably get confused, I imagine
that's the reason why ON/OFF is ignored if client->driver_power_control
is set to true.
Speaking of which, the external ports of the MBP are soldered to
the discrete GPU and can't be switched. Only the panel can be
switched. So if there are DP or HDMI connectors with status
connected, we can't suspend. That's one of the MBP's numerous
peculiarities that I haven't verified yet they're handled properly
by the code.
Best regards,
Lukas
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 82714] [G84] nouveau fails to properly initialize GPU
https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #18 from Bruno --- Created attachment 116185 --> https://bugs.freedesktop.org/attachment.cgi?id=116185&action=edit linux-4.1-rc5+ Same 4.1-rc5+ kernel but this time around performing nvapeek/nvapoke. Doing the peek/poke makes display get signal over DVI but does not prevent the system from freezing after X has started. The last lines of output from X were (the COPY failure coming some time after the rest): (--) Depth 24 pixmap format is 32 bpp (II) NOUVEAU(0): Channel setup complete. (EE) NOUVEAU(0): [COPY] failed to allocate class. The PGRAPH/VM FLUSH timeouts look like they could have something to do with the freeze and be cause of X COPY failure. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 82714] [G84] nouveau fails to properly initialize GPU
https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #17 from Bruno --- Created attachment 116184 --> https://bugs.freedesktop.org/attachment.cgi?id=116184&action=edit linux-4.1-rc5+ Same result as previous kernel (though screen never detected signal), this time with 4.1-rc5+, but not doing the nvapeek/nvapoke. System freeze some time after starting Xorg. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 82714] [G84] nouveau fails to properly initialize GPU
https://bugs.freedesktop.org/show_bug.cgi?id=82714 Pierre Moreau changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #16 from Pierre Moreau --- Hum... So the evo_wait error disappeared for some reason and you're back to the behaviour from 3.19. So, from the runpm=0: [ 91.530766] nouveau W[ PFIFO][:01:00.0] unknown intr 0x0020 [...] [ 101.568583] nouveau E[ PDISP][:01:00.0][0xc000827c] channel stalled [...] [ 183.835874] nouveau E[ PGR][:01:00.0] vm flush timeout I won't have time to have a look at the old behaviour before a few months sadly... -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 82714] [G84] nouveau fails to properly initialize GPU
https://bugs.freedesktop.org/show_bug.cgi?id=82714 --- Comment #15 from Bruno --- Created attachment 116181 --> https://bugs.freedesktop.org/attachment.cgi?id=116181&action=edit linux-4.0, + modprobe nouveau debug=debug runpm=0 (In reply to Pierre Moreau from comment #14) > Could you please run `nvapeek 8841c` and post the result here please? ./envytools/nva/nvapeek 8841c 0008841c: 0400 > If you get a non-zero value v, write value = (v & 0xff00) to 8841c using > `nvapoke 8841c value` **before** loading Nouveau. nvapeek and nvapoke are > found in the envytools repo: https://github.com/envytools/envytools modprobe nouveau [ 747.279238] nouveau [ DEVICE][:01:00.0] BOOT0 : 0x084000a2 [ 747.279252] nouveau [ DEVICE][:01:00.0] Chipset: G84 (NV84) [ 747.279257] nouveau [ DEVICE][:01:00.0] Family : NV50 [ 747.379554] nouveau [ VBIOS][:01:00.0] using image from PROM [ 747.379705] nouveau [ VBIOS][:01:00.0] BIT signature found [ 747.379710] nouveau [ VBIOS][:01:00.0] version 60.84.32.00.00 [ 747.381119] nouveau [ DEVINIT][:01:00.0] adaptor not initialised [ 747.381140] nouveau [ VBIOS][:01:00.0] running init tables [ 747.442531] nouveau [ PMC][:01:00.0] MSI interrupts enabled [ 747.442593] nouveau [ PFB][:01:00.0] RAM type: GDDR3 [ 747.442597] nouveau [ PFB][:01:00.0] RAM size: 512 MiB [ 747.442601] nouveau [ PFB][:01:00.0]ZCOMP: 1892 tags [ 747.445672] nouveau [VOLT][:01:00.0] GPU voltage: 130uv [ 747.474545] nouveau [ PTHERM][:01:00.0] FAN control: PWM [ 747.474597] nouveau [ PTHERM][:01:00.0] fan management: automatic [ 747.474644] nouveau [ PTHERM][:01:00.0] internal sensor: yes [ 747.494680] nouveau [ CLK][:01:00.0] 20: core 675 MHz shader 1450 MHz memory 1008 MHz [ 747.494743] nouveau [ CLK][:01:00.0] --: core 675 MHz shader 1458 MHz memory 900 MHz [ 747.495846] nouveau E[PBUS][:01:00.0] MMIO write of 0x FAULT at 0x103d94 [ 747.496017] nouveau [ DRM] VRAM: 512 MiB [ 747.496049] nouveau [ DRM] GART: 1048576 MiB [ 747.496067] nouveau [ DRM] TMDS table version 2.0 [ 747.496079] nouveau [ DRM] DCB version 4.0 [ 747.496096] nouveau [ DRM] DCB outp 00: 01000302 00020030 [ 747.496124] nouveau [ DRM] DCB outp 01: 02000300 0028 [ 747.496138] nouveau [ DRM] DCB outp 02: 04012310 0028 [ 747.496150] nouveau [ DRM] DCB outp 03: 02021322 00020010 [ 747.496161] nouveau [ DRM] DCB conn 00: 1030 [ 747.496184] nouveau [ DRM] DCB conn 01: 2161 [ 747.496202] nouveau [ DRM] DCB conn 02: 0200 [ 747.496218] nouveau [ DRM] DCB conn 03: 0362 [ 747.525704] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 747.525721] [drm] Driver supports precise vblank timestamp query. [ 747.973933] Clocksource tsc unstable (delta = -209664716 ns) [ 749.145223] nouveau W[ PFIFO][:01:00.0] unknown intr 0x0020 [ 749.145653] nouveau [ DRM] MM: using CRYPT for buffer copies [ 749.145754] Switched to clocksource hpet [ 750.783934] nouveau [ DRM] allocated 1280x1024 fb: 0x7, bo 8800beb1b538 [ 750.784312] nouveau :01:00.0: fb1: nouveaufb frame buffer device [ 750.784344] [drm] Initialized nouveau 1.2.1 20120801 for :01:00.0 on minor 1 After this X11 gets stuck in runtime-PM: [] rpm_resume+0x18c/0x5c0 [] __pm_runtime_resume+0x48/0x70 [] nouveau_drm_open+0x43/0x220 [nouveau] [] drm_open+0x1ad/0x4b0 [] drm_stub_open+0xb1/0x130 [] chrdev_open+0xb1/0x190 [] do_dentry_open.isra.19+0x101/0x330 [] vfs_open+0x41/0x50 [] do_last.isra.56+0x25b/0xf20 [] path_openat+0x89/0x5a0 [] do_filp_open+0x3e/0xa0 [] do_sys_open+0x12e/0x230 [] SyS_open+0x19/0x20 [] system_call_fastpath+0x12/0x17 [] 0x With runpm=0 things behave somewhat better (display lights up - tested on DVI output where earlier tests were with VGA). Though once X has started system gets sluggish (periods of "freeze" and continue) until it fully freezes. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
