similar to: [PATCH] drm/nouveau: fix early vram corruption originating from vgacon

Problem: qxl switches from native mode back into vga compatibility mode when it notices someone is accessing vga registers. And vgacon does exactly that before fbcon takes over. Before qxl switched to the generic fbdev emulation that didn't cause any problems. With the generic fbdev emulation the switch to vga mode happens now and then, probably caused by a initialization order change and

Problem: qxl switches from native mode back into vga compatibility mode when it notices someone is accessing vga registers. And vgacon does exactly that before fbcon takes over. Before qxl switched to the generic fbdev emulation that didn't cause any problems. With the generic fbdev emulation the switch to vga mode happens now and then, probably caused by a initialization order change and

On Wed, Feb 20, 2019 at 03:36:40PM +0100, Gerd Hoffmann wrote: > Problem: qxl switches from native mode back into vga compatibility mode > when it notices someone is accessing vga registers. And vgacon does > exactly that before fbcon takes over. > > Before qxl switched to the generic fbdev emulation that didn't cause any > problems. With the generic fbdev emulation the

the -rt patches change the console_semaphore to console_mutex. so a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() this commit makes things use more neutral function names which dont make implications about the underlying lock. the only real change is the return value of console_trylock which is inverted from

the -rt patches change the console_semaphore to console_mutex. so a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() this commit makes things use more neutral function names which dont make implications about the underlying lock. the only real change is the return value of console_trylock which is inverted from

the -rt patches change the console_semaphore to console_mutex. so a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() this commit makes things use more neutral function names which dont make implications about the underlying lock. the only real change is the return value of console_trylock which is inverted from

fbcon makes the (reasonable) assumption that it only needs to program the hardware once, when fbcon_init() is called for the foreground console. This doesn't always play well with vgacon because vgacon_deinit() is only doing its job when the last console it owns is closed (in most cases, that is *after* fbcon_init() has set the new mode). Depending on the hardware this can cause the wrong

Hi, The much easier fix is this one ;) cheers, Gerd -- = Gerd Hoffmann <kraxel@suse.de> -------------- next part -------------- --- drivers/video/console/vgacon.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: paravirt-2.6.20-hg749/drivers/video/console/vgacon.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

Hi, The much easier fix is this one ;) cheers, Gerd -- = Gerd Hoffmann <kraxel@suse.de> -------------- next part -------------- --- drivers/video/console/vgacon.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Index: paravirt-2.6.20-hg749/drivers/video/console/vgacon.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote: > Problem: qxl switches from native mode back into vga compatibility mode > when it notices someone is accessing vga registers. And vgacon does > exactly that before fbcon takes over. So make sure we kick out vgacon > early enough that it wouldn't disturb us. > > Signed-off-by: Gerd Hoffmann <kraxel at

Problem: qxl switches from native mode back into vga compatibility mode when it notices someone is accessing vga registers. And vgacon does exactly that before fbcon takes over. So make sure we kick out vgacon early enough that it wouldn't disturb us. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.c | 1 + 1 file changed, 1 insertion(+) diff

Problem: qxl switches from native mode back into vga compatibility mode when it notices someone is accessing vga registers. And vgacon does exactly that before fbcon takes over. So make sure we kick out vgacon early enough that it wouldn't disturb us. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.c | 1 + 1 file changed, 1 insertion(+) diff

On Thu, Feb 21, 2019 at 01:20:11PM +0100, Daniel Vetter wrote: > On Thu, Feb 21, 2019 at 12:35:34PM +0100, Gerd Hoffmann wrote: > > Problem: qxl switches from native mode back into vga compatibility mode > > when it notices someone is accessing vga registers. And vgacon does > > exactly that before fbcon takes over. So make sure we kick out vgacon > > early enough

Hi, > I was thinking of checking whether pdev is a VGA class device and whether > it decodes vga access, and in that case automatically calling How can I figure that? Ok, class is easy, but decode? pci.h offers functions to set vga decode but not to get that info ... thanks, Gerd

On Thu, Feb 21, 2019 at 4:11 PM Gerd Hoffmann <kraxel at redhat.com> wrote: > > Hi, > > > I was thinking of checking whether pdev is a VGA class device and whether > > it decodes vga access, and in that case automatically calling > > How can I figure that? Ok, class is easy, but decode? pci.h offers > functions to set vga decode but not to get that info ...

Hi, > I was thinking of checking whether pdev is a VGA class device and whether > it decodes vga access, and in that case automatically calling How can I figure that? Ok, class is easy, but decode? pci.h offers functions to set vga decode but not to get that info ... thanks, Gerd

After a full device powerdown via the optimus power switch, we seem to lose the HDMI device completely on power on, this keep track of whether we had a hdmi audio sub function device at power on, and pokes a magic register to make it reappear after the optimus power switch is thrown. This at least works on my NVC4 machine, probably needs testing on a few other laptops with other nvidia GPUs.

The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called while nouveau was runtime suspended, a deadlock would occur due to nouveau_fbcon_set_suspend also trying to obtain console_lock(). Fix this by delaying the drm_fb_helper_set_suspend call. Based on the i915 code (which was done for performance reasons though). Cc: Chris Wilson <chris at chris-wilson.co.uk> Cc: Daniel

Op 24-07-13 09:13, Dave Airlie schreef: > After a full device powerdown via the optimus power switch, we seem > to lose the HDMI device completely on power on, this keep track of > whether we had a hdmi audio sub function device at power on, and > pokes a magic register to make it reappear after the optimus power > switch is thrown. > > This at least works on my NVC4 machine,

On Tue, Sep 04, 2018 at 10:27:47PM +0200, Peter Wu wrote: > "crtc->helper_private" is not initialized by the QXL driver and thus the This is still initialized, it's the ->disable that goes boom. At least the call to drm_crtc_helper_add is still there. The ->disable was removed in: commit 64581714b58bc3e16ede8dc37a025c3aa0e0eef1 Author: Laurent Pinchart