[Nouveau] [Bug 98677] [NVAC] iMac9, 1 effective backlight brightness range changes after S3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #8 from Jeffery Miller  ---
I patched as suggested having it use the nva3_bl_ops. The backlight remained
dark in this case. I was able to get the backlight to turn on by setting values
with nvapoke to match values I had seen earlier:

nvapoke 0x0061c080 0x1
nvapoke 0x0061c084 0x8401

I noticed from the mmiotrace of the binary driver that it seems to set these
two registers when the brightness changes.
I'm away from the machine at the moment to post the details that seemed
relevant to me. 

I am not sure which registers might be important to check before and after. 

I'll look at the trace again and pop into it for some questions

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98677] [NVAC] iMac9, 1 effective backlight brightness range changes after S3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #7 from Jeffery Miller  ---
I will patch and attempt to use the nva routines and report back.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98677] [NVAC] iMac9, 1 effective backlight brightness range changes after S3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #6 from Jeffery Miller  ---
Created attachment 127905
  --> https://bugs.freedesktop.org/attachment.cgi?id=127905=edit
mmiotrace of nvidia driver performing brightness changes

mmio trace of the nvidia driver 340.96
I set the brightness with the nvidia-settings command following the steps:

   modprobe nvidia-uvm
   Xorg &
   DISPLAY=:0 nvidia-settings -n -a BacklightBrightness=50
   DISPLAY=:0 nvidia-settings -n -a BacklightBrightness=70
   DISPLAY=:0 nvidia-settings -n -a BacklightBrightness=100

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98677] [NVAC] iMac9, 1 effective backlight brightness range changes after S3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #5 from Ilia Mirkin  ---
An observation is that the nouveau code in nva3_get/set_intensity takes the
existing divider into account. However we only use that for nva3/5/8/f, not
nvaa/nvac.

Could you try changing nouveau_backlight.c:nv50_backlight_init to use
nva3_bl_ops for your chipset and seeing whether that fixes everything?

(Let me know if you're not sure how to do that, and I can put a patch
together.)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98677] [NVAC] iMac9, 1 effective backlight brightness range changes after S3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #4 from Jeffery Miller  ---
Created attachment 127904
  --> https://bugs.freedesktop.org/attachment.cgi?id=127904=edit
VBIOS retrieved with nvagetbios

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98677] [NVAC] iMac9, 1 effective backlight brightness range changes after S3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #3 from Jeffery Miller  ---
Created attachment 127903
  --> https://bugs.freedesktop.org/attachment.cgi?id=127903=edit
lspci output for the machine

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98677] [NVAC] iMac9, 1 effective backlight brightness range changes after S3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #2 from Jeffery Miller  ---
Created attachment 127902
  --> https://bugs.freedesktop.org/attachment.cgi?id=127902=edit
dmidecode binary output

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98677] [NVAC] iMac9, 1 effective backlight brightness range changes after S3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98677

--- Comment #1 from Jeffery Miller  ---
Created attachment 127901
  --> https://bugs.freedesktop.org/attachment.cgi?id=127901=edit
ACPI dump of the system

acpidump of the system

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98677] New: [NVAC] iMac9, 1 effective backlight brightness range changes after S3

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98677

Bug ID: 98677
   Summary: [NVAC] iMac9,1 effective backlight brightness range
changes after S3
   Product: xorg
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: jeffe...@gmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 127900
  --> https://bugs.freedesktop.org/attachment.cgi?id=127900=edit
dmesg output after the resume with some nouveau trace options

I have an iMac 9,1 where the behaviour of the backlight of the built in screen
works differently between the first boot and after a suspend to ram.
It appears to be darker at lower values before a suspend than after.

kernel: 4.8.6-300.fc25.x86_64
lspci adapter: VGA adapter NVIDIA Corporation C79 [GeForce 9400] [10de:0867]
DMI: Apple Inc. iMac9,1/Mac-F2218EA9
I've been booting in EFI mode.
I do not know of a regression. I've only tried 4.4 and this 4.8 kernels.
I've observed this with X running but I've been testing this without starting a
graphical environment.

I've been testing by setting setting backlight values via the
/sys/backlight/nv_backlight/brightness interface.
Before a suspend I can set values such as 40, 70, 100 and the brightness seems
to be reasonable on the screen.

I then suspend to ram via the /sys/power/state interface.
Upon resuming the backlight appears to be at 100 percent. If I set the
brightness to values such as 30 and 60 the screen remains dark. It is barely
visible as a flicker at 70. At 100 it is visible.

I've observed that the value of NV50_PDISP_SOR_PWM_DIV (0x0061c080) is 0x1
after a boot but is set to 0x84 after a resume.
It appears there's an init script in the bios dump which sets it to the value
of 0x84. I have confirmed if I use the nouveau option
nouveau.config=NvForcePost=1 that the behavior after booting is the same as
after a resume. The value of 0x61c080 is 0x84.

If I `nvapoke 0x061c080 0x1` after a resume the backlight seems to work fairly
well. I created patch to test this. I expect it isn't the proper solution.

I'm attaching the dmesg which includes a resume with the nouveau driver.
I'll also attach the vbios dump, acpidump, dmidecode, lspci, 

I've gathered an mmiotrace of the binary driver as it sets a few brightness
values as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 94725] Nouveau driver fails to poweron GPU on GM204 after dynamic poweroff

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94725

Peter Wu  changed:

   What|Removed |Added

   See Also||https://bugzilla.kernel.org
   ||/show_bug.cgi?id=156341

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 94990] [GM204] GTX 970 + 4GB VRAM fails at secboot (v4.6+)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94990

--- Comment #89 from Karol Herbst  ---
(In reply to Gabriel Amadej from comment #88)
> Hi. I've noticed that the liquorix kernel [ https://liquorix.net ] works
> with my GTX970. It worked with version 4.6, 4.7, and now 4.8. I don't know
> what it does differently to make it work, but maybe a solution to the
> problem can be found there.

does your GTX 970 have 4GB or 2GB? The 2GB version should work.
Otherwise, maybe the firmware files are missing so that not all GPU features
are available. Anyway, check with glxinfo if nouveau is actually used

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 94990] [GM204] GTX 970 + 4GB VRAM fails at secboot (v4.6+)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=94990

--- Comment #88 from Gabriel Amadej  ---
Hi. I've noticed that the liquorix kernel [ https://liquorix.net ] works with
my GTX970. It worked with version 4.6, 4.7, and now 4.8. I don't know what it
does differently to make it work, but maybe a solution to the problem can be
found there.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE

[Hans de Goede]

Hi,

On 10-11-16 11:58, Peter Wu wrote:

On Wed, Nov 09, 2016 at 06:17:44PM +0100, Hans de Goede wrote:

Various notebooks with nvidia GPUs generate an ACPI_VIDEO_NOTIFY_PROBE
acpi-video event when an external device gets plugged in (and again on
modesets on that connector), the default behavior in the acpi-video
driver for this is to send a KEY_SWITCHVIDEOMODE evdev event, which
causes e.g. gnome-settings-daemon to ask us to rescan the connectors
(good), but also causes g-s-d to switch to mirror mode on a newly plugged
monitor rather then using the monitor to extend the desktop (bad)
as KEY_SWITCHVIDEOMODE is supposed to switch between extend the desktop
vs mirror mode.


Can confirm this behavior on my Clevo P651RA laptop with GTX 965M, it
shows a weird keystroke on console on inserting a monitor. On the Plasma
desktop, it shows a notification "no outputs detected". Only after
running "xrandr", the external monitor would be picked up.


Good, thank you for testing.


More troublesome are the repeated ACPI_VIDEO_NOTIFY_PROBE events on
changing the mode on the connector, which cause g-s-d to switch
between mirror/extend mode, which causes a new ACPI_VIDEO_NOTIFY_PROBE
event and we end up with an endless loop.

This commit fixes this by adding an acpi notifier block handler to
nouveau_display.c to intercept ACPI_VIDEO_NOTIFY_PROBE and:

1) Wake-up runtime suspended GPUs and call drm_helper_hpd_irq_event()
   on them, this is necessary in some cases for the GPU to detect connector
   hotplug events while runtime suspended
2) Return NOTIFY_BAD to stop acpi-video from emitting a bogus
   KEY_SWITCHVIDEOMODE key-press event

There already is another acpi notifier block handler registered in
drivers/gpu/drm/nouveau/nvkm/engine/device/acpi.c, but that is not
suitable since that one gets unregistered on runtime suspend, and
we also want to intercept ACPI_VIDEO_NOTIFY_PROBE when runtime suspended.


From a quick look, it looks like a suitable mechanism except for the
removal on runtime suspend.


That is not the only problem, there also is no way to get to the
drm_device pointer that deep in the nvkm object tree.



Based on commit logs for core/core/event.c, the event system seems
initially used for communication between drm and nouveau, later this was
extended to userspace notifications. For some reason, nvkm_acpi_init is
called through this user.c path:

  lspci-14658 [001] d..1 35887.344592: p_nvkm_acpi_init_0: 
(nvkm_acpi_init+0x0/0x20 [nouveau])
   lspci-14658 [001] d..1 35887.344597: 
 => nvkm_udevice_init
 => nvkm_object_init
 => nvkm_object_init
 => nvkm_client_init
 => nvkm_client_resume
 => nvif_client_resume
 => nouveau_do_resume
 => nouveau_pmops_runtime_resume
 => pci_pm_runtime_resume

runtime suspend follows similar code path with resume -> suspend and
init -> fini, but somehow I also see this weird path just before resume:

   lspci-14658 [001] d..1 35887.176959: p_nvkm_acpi_fini_0: 
(nvkm_acpi_fini+0x0/0x20 [nouveau])
   lspci-14658 [001] d..1 35887.176974: 
 => nvkm_device_init
 => nvkm_udevice_init

This was observed on kernel 4.8.6-1-ARCH using kprobe tracing.


Yes I noticed that too, this is indeed weird.


> Hopefully

Ben can clarify this situation. One other comment below.


Signed-off-by: Hans de Goede 
---
Note that ACPI_VIDEO_NOTIFY_PROBE currently is a private define in
drivers/acpi/acpi_video.c, since it is passed to acpi_notifier_call_chain()
it really should be in a public header, so I've submitted a patch to
the acpi subsys to move it to include/acpi/video.h . In the mean time
this patch defines it with a #ifndef guard to allow merging without
introducing inter subsys dependencies. I will submit a follow up patch
removing the #ifndef block once both patches are in Linus' tree.
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 61 +++
 drivers/gpu/drm/nouveau/nouveau_drv.h |  6 +++
 2 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index afbf557..6cd6723 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -24,6 +24,7 @@
  *
  */

+#include 
 #include 
 #include 

@@ -42,6 +43,8 @@
 #include 
 #include 

+
+
 static int
 nouveau_display_vblank_handler(struct nvif_notify *notify)
 {
@@ -358,6 +361,55 @@ static struct nouveau_drm_prop_enum_list dither_depth[] = {
}  \
 } while(0)

+#ifdef CONFIG_ACPI
+
+/*
+ * Hans de Goede: This define belongs in acpi/video.h, I've submitted a patch
+ * to the acpi subsys to move it there from drivers/acpi/acpi_video.c .
+ * This should be dropped once that is merged.
+ */
+#ifndef ACPI_VIDEO_NOTIFY_PROBE
+#define ACPI_VIDEO_NOTIFY_PROBE0x81
+#endif
+
+static void

Re: [Nouveau] [PATCH] drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE

[Peter Wu]

On Wed, Nov 09, 2016 at 06:17:44PM +0100, Hans de Goede wrote:
> Various notebooks with nvidia GPUs generate an ACPI_VIDEO_NOTIFY_PROBE
> acpi-video event when an external device gets plugged in (and again on
> modesets on that connector), the default behavior in the acpi-video
> driver for this is to send a KEY_SWITCHVIDEOMODE evdev event, which
> causes e.g. gnome-settings-daemon to ask us to rescan the connectors
> (good), but also causes g-s-d to switch to mirror mode on a newly plugged
> monitor rather then using the monitor to extend the desktop (bad)
> as KEY_SWITCHVIDEOMODE is supposed to switch between extend the desktop
> vs mirror mode.

Can confirm this behavior on my Clevo P651RA laptop with GTX 965M, it
shows a weird keystroke on console on inserting a monitor. On the Plasma
desktop, it shows a notification "no outputs detected". Only after
running "xrandr", the external monitor would be picked up.

> More troublesome are the repeated ACPI_VIDEO_NOTIFY_PROBE events on
> changing the mode on the connector, which cause g-s-d to switch
> between mirror/extend mode, which causes a new ACPI_VIDEO_NOTIFY_PROBE
> event and we end up with an endless loop.
> 
> This commit fixes this by adding an acpi notifier block handler to
> nouveau_display.c to intercept ACPI_VIDEO_NOTIFY_PROBE and:
> 
> 1) Wake-up runtime suspended GPUs and call drm_helper_hpd_irq_event()
>on them, this is necessary in some cases for the GPU to detect connector
>hotplug events while runtime suspended
> 2) Return NOTIFY_BAD to stop acpi-video from emitting a bogus
>KEY_SWITCHVIDEOMODE key-press event
> 
> There already is another acpi notifier block handler registered in
> drivers/gpu/drm/nouveau/nvkm/engine/device/acpi.c, but that is not
> suitable since that one gets unregistered on runtime suspend, and
> we also want to intercept ACPI_VIDEO_NOTIFY_PROBE when runtime suspended.

From a quick look, it looks like a suitable mechanism except for the
removal on runtime suspend.

Based on commit logs for core/core/event.c, the event system seems
initially used for communication between drm and nouveau, later this was
extended to userspace notifications. For some reason, nvkm_acpi_init is
called through this user.c path:

  lspci-14658 [001] d..1 35887.344592: p_nvkm_acpi_init_0: 
(nvkm_acpi_init+0x0/0x20 [nouveau])
   lspci-14658 [001] d..1 35887.344597: 
 => nvkm_udevice_init
 => nvkm_object_init
 => nvkm_object_init
 => nvkm_client_init
 => nvkm_client_resume
 => nvif_client_resume
 => nouveau_do_resume
 => nouveau_pmops_runtime_resume
 => pci_pm_runtime_resume

runtime suspend follows similar code path with resume -> suspend and
init -> fini, but somehow I also see this weird path just before resume:

   lspci-14658 [001] d..1 35887.176959: p_nvkm_acpi_fini_0: 
(nvkm_acpi_fini+0x0/0x20 [nouveau])
   lspci-14658 [001] d..1 35887.176974: 
 => nvkm_device_init
 => nvkm_udevice_init

This was observed on kernel 4.8.6-1-ARCH using kprobe tracing. Hopefully
Ben can clarify this situation. One other comment below.

> Signed-off-by: Hans de Goede 
> ---
> Note that ACPI_VIDEO_NOTIFY_PROBE currently is a private define in
> drivers/acpi/acpi_video.c, since it is passed to acpi_notifier_call_chain()
> it really should be in a public header, so I've submitted a patch to
> the acpi subsys to move it to include/acpi/video.h . In the mean time
> this patch defines it with a #ifndef guard to allow merging without
> introducing inter subsys dependencies. I will submit a follow up patch
> removing the #ifndef block once both patches are in Linus' tree.
> ---
>  drivers/gpu/drm/nouveau/nouveau_display.c | 61 
> +++
>  drivers/gpu/drm/nouveau/nouveau_drv.h |  6 +++
>  2 files changed, 67 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index afbf557..6cd6723 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -24,6 +24,7 @@
>   *
>   */
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -42,6 +43,8 @@
>  #include 
>  #include 
>  
> +
> +
>  static int
>  nouveau_display_vblank_handler(struct nvif_notify *notify)
>  {
> @@ -358,6 +361,55 @@ static struct nouveau_drm_prop_enum_list dither_depth[] 
> = {
>   }  \
>  } while(0)
>  
> +#ifdef CONFIG_ACPI
> +
> +/*
> + * Hans de Goede: This define belongs in acpi/video.h, I've submitted a patch
> + * to the acpi subsys to move it there from drivers/acpi/acpi_video.c .
> + * This should be dropped once that is merged.
> + */
> +#ifndef ACPI_VIDEO_NOTIFY_PROBE
> +#define ACPI_VIDEO_NOTIFY_PROBE  0x81
> +#endif
> +
> +static void
> +nouveau_display_acpi_work(struct work_struct *work)
> +{
> + struct nouveau_drm *drm = 

[Nouveau] [Bug 98457] [NVD9] GPU lockup after resume from hibernation with Nouveau driver and firmware-nonfree

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98457

--- Comment #5 from wa...@mailbox.hu ---
(In reply to Pierre Moreau from comment #3)
> latest patches, but is not an out-of-tree version. Or the latest image from
> https://nouveau.pmoreau.org/ (though it is not as recent as the previous
> link, as the image was generated on Monday).

Thanks, I'm trying that now, and will report back.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98457] [NVD9] GPU lockup after resume from hibernation with Nouveau driver and firmware-nonfree

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98457

wa...@mailbox.hu changed:

   What|Removed |Added

Version|unspecified |10.3

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 98457] [NVD9] GPU lockup after resume from hibernation with Nouveau driver and firmware-nonfree

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=98457

wa...@mailbox.hu changed:

   What|Removed |Added

 QA Contact|xorg-t...@lists.x.org   |nouveau@lists.freedesktop.o
   ||rg
  Component|Driver/nouveau  |Drivers/DRI/nouveau
Product|xorg|Mesa

--- Comment #4 from wa...@mailbox.hu ---
Moving this to Mesa since it seems that's where it belongs.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 97462] Graphics deadlock "ILLEGAL_MTHD" in nouveau with mesa version 11.2.2 when visiting Google Maps with firefox 49.0b5

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=97462

wa...@mailbox.hu changed:

   What|Removed |Added

Version|unspecified |11.2
Product|xorg|Mesa
 QA Contact|xorg-t...@lists.x.org   |nouveau@lists.freedesktop.o
   ||rg
  Component|Driver/nouveau  |Drivers/DRI/nouveau

--- Comment #17 from wa...@mailbox.hu ---
Wow, thanks, I couldn't have guessed that. :D
Changed now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau