similar to: [PATCH] Add VirtIO Frame Buffer Support

CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton <wfp5p at virginia.edu> Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de> Cc: Jaya Kumar <jayalk at intworks.biz> Cc: Paul Mackerras <paulus at samba.org> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> Cc: Russell King <linux at

CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton <wfp5p at virginia.edu> Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de> Cc: Jaya Kumar <jayalk at intworks.biz> Cc: Paul Mackerras <paulus at samba.org> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> Cc: Russell King <linux at

CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton <wfp5p at virginia.edu> Cc: Florian Tobias Schandinat <FlorianSchandinat at gmx.de> Cc: Jaya Kumar <jayalk at intworks.biz> Cc: Paul Mackerras <paulus at samba.org> Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org> Cc: Russell King <linux at

let vga16fb claim 0xA0000+0x10000 region as its aperture; drm drivers don't use it, so we have to detect it and kick vga16fb manually - but only if drm is driving the primary card Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> Cc: James Simmons <jsimmons at infradead.org> Cc: Dave Airlie <airlied at redhat.com> Cc: Ben Skeggs <bskeggs at redhat.com> --- no

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.

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

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 ++++++++++++++++++++++++++++++++

It's mostly a cleanup, but in nv50_fbcon_accel_init gpu lockup message was printed, but HWACCEL_DISBALED flag was not set. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 15 +++++++++++---- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 2 ++ drivers/gpu/drm/nouveau/nv04_fbcon.c | 15 +++++----------

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,

At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. Read and write operations are implemented internally by DRM's fbdev helper. For drivers that employ a shadow

At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. Read and write operations are implemented internally by DRM's fbdev helper. For drivers that employ a shadow

Hi On 22.10.20 10:05, Daniel Vetter wrote: > On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote: >> At least sparc64 requires I/O-specific access to framebuffers. This >> patch updates the fbdev console accordingly. >> >> For drivers with direct access to the framebuffer memory, the callback >> functions in struct fb_ops test for the type of memory

At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. For drivers that employ a shadow buffer, fbdev's blit function retrieves the framebuffer address as struct

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>

Hi On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg <sam at ravnborg.org> wrote: > Hi Thomas. > > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > > At least sparc64 requires I/O-specific access to framebuffers. This > > patch updates the fbdev console accordingly. > > > > For drivers with direct access to the framebuffer memory, the

The vma field of struct nouveau_framebuffer is a special field for the the accelerated fbdev console. Hence there's at most one single instance for the active console. Moving it into struct nouveau_fbdev makes struct nouveau_framebuffer slightly smaller and brings it closer to struct drm_framebuffer. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> ---

Hi On Fri, 16 Oct 2020 12:58:54 +0200 Sam Ravnborg <sam at ravnborg.org> wrote: > Hi Thomas. > > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > > At least sparc64 requires I/O-specific access to framebuffers. This > > patch updates the fbdev console accordingly. > > > > For drivers with direct access to the framebuffer memory, the

At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. For drivers that employ a shadow buffer, fbdev's blit function retrieves the framebuffer address as struct

On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter <daniel at ffwll.ch> wrote: > > On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote: > > At least sparc64 requires I/O-specific access to framebuffers. This > > patch updates the fbdev console accordingly. > > > > For drivers with direct access to the framebuffer memory, the callback > > functions