similar to: [PATCH v2 3/3] vga16fb, drm: vga16fb->drm handoff

We don't want vga16fb to mess with hardware initialized by other driver. Detect it and refuse to load. It fixes nouveau interrupt storm on some machines. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/video/vga16fb.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c index

Currently vesafb/efifb/... is kicked when hardware driver is registering framebuffer. To do it hardware must be fully functional, so there's a short window between start of initialisation and framebuffer registration when two drivers touch the hardware. Unfortunately sometimes it breaks nouveau initialisation. Fix it by kicking firmware driver(s) before we start touching the hardware.

It simplifies nouveau code by removal of detection which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc:

It removes a hack from nouveau code which had to detect which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Eric Anholt <eric at anholt.net> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: Thomas Hellstrom <thellstrom at vmware.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com>

fb_do_apertures_overlap is returning wrong value when one aperture is completely whithin the other. Add generic ranges_overlap macro (probably kernel.h candidate) and use it here. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: Dave Airlie <airlied at redhat.com> Cc: Peter Jones <pjones at redhat.com> Cc: Andrew Morton <akpm at linux-foundation.org> ---

Almost all PCI drivers using remove_conflicting_framebuffers() wrap it with the same code. --- v2: add kerneldoc for DRM helper v3: propagate remove_conflicting_framebuffers() return value + move kerneldoc to where function is implemented Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> --- drivers/video/fbdev/core/fbmem.c | 35 ++++++++++++++++++++++++++++++++

This series cleans up duplicated code for replacing firmware FB driver with proper DRI driver and adds handover support to Tegra driver. This is a sligtly updated version of a series sent on 24 Nov 2017. --- v2: - rebased on current drm-next - dropped staging/sm750fb changes - added kernel docs for DRM helpers v3: - move kerneldoc to fbdev, where functions are implemented - split kerneldoc

This series cleans up duplicated code for replacing firmware FB driver with proper DRI driver and adds handover support to Tegra driver. This is a sligtly updated version of a series sent on 24 Nov 2017. --- v2: - rebased on current drm-next - dropped staging/sm750fb changes - added kernel docs for DRM helpers v3: - move kerneldoc to fbdev, where functions are implemented - split kerneldoc

Almost all drivers using remove_conflicting_framebuffers() wrap it with the same code. Extract common part from PCI drivers into separate remove_conflicting_pci_framebuffers(). Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> --- drivers/video/fbdev/core/fbmem.c | 22 ++++++++++++++++++++++ include/drm/drm_fb_helper.h | 12 ++++++++++++ include/linux/fb.h | 2

On Fri, Nov 24, 2017 at 06:53:31PM +0100, Micha? Miros?aw wrote: > Almost all drivers using remove_conflicting_framebuffers() wrap it with > the same code. Extract common part from PCI drivers into separate > remove_conflicting_pci_framebuffers(). > > Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> Since the only driver that seems to use this is the staging one,

On Fri, Nov 24, 2017 at 06:53:31PM +0100, Micha? Miros?aw wrote: > Almost all drivers using remove_conflicting_framebuffers() wrap it with > the same code. Extract common part from PCI drivers into separate > remove_conflicting_pci_framebuffers(). > > Signed-off-by: Micha? Miros?aw <mirq-linux at rere.qmqm.pl> Since the only driver that seems to use this is the staging one,

Hello I have an active-active DRBD cluster using OCFS2 as the filesystem on the drbd devices. I started getting a "general protection fault error" when trying to mount any one of the ocfs2 volumes I have, even when running mount on a single node, with no mounted FSs on the other node. The kernel trace follows at the bottom of this message. Does anyone know what could have been

--- drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 32 ++++++++++++++++++++++++++++++-- drivers/virtio/virtio_pci_common.c | 7 ++++++- 2 files changed, 36 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c index 56bd4ed..33d12d5 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c +++

--- drivers/gpu/drm/virtio/virtgpu_drm_bus.c | 32 ++++++++++++++++++++++++++++++-- drivers/virtio/virtio_pci_common.c | 7 ++++++- 2 files changed, 36 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c b/drivers/gpu/drm/virtio/virtgpu_drm_bus.c index 56bd4ed..33d12d5 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drm_bus.c +++

Hi everyone I have a Digium card TE110P and after plug it, turn on the computer and configure, the LEDs don't light up in spite of what Digium FAQ says about the LEDs: When will the LED's light up on my TDM400P/TE110P/TE2XXP/TE4XXP? ... The TE110P LED's will light up RED when the span is configured and kernel module is loaded. If configured correctly and a circuit or channel bank is

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

On Fri, Aug 31, 2018 at 10:07:42AM +0100, Chris Wilson wrote: [...] > Ahah, someone is looking at remove_conflicting_framebuffers(). May I > interest you in a use-after-free? > [ 378.423513] stack segment: 0000 [#1] PREEMPT SMP PTI > [ 378.423530] CPU: 1 PID: 4338 Comm: pm_rpm Tainted: G U 4.19.0-rc1-CI-CI_DRM_4746+ #1 > [ 378.423548] Hardware name: To Be Filled

uhhhhhhhhhhhhh didn't we fix this weeks ago? with "drm/nouveau: tegra: Call nouveau_drm_device_init()" On Fri, 2018-12-07 at 23:31 +0000, Guillaume Tucker wrote: > Please find below an automated bisection report for a kernel Oops > seen during the initialisation of the nouveau GPU driver on > jetson-tk1. > > > All the LAVA test jobs for this bisection can be