search for: screen_base

...f: ttm_bo_unref((struct ttm_buffer_object **)&par->vmw_bo); diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c index ecf4055..4a56f46 100644 --- a/drivers/video/efifb.c +++ b/drivers/video/efifb.c @@ -168,7 +168,7 @@ static void efifb_destroy(struct fb_info *info) { if (info->screen_base) iounmap(info->screen_base); - release_mem_region(info->aperture_base, info->aperture_size); + release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size); framebuffer_release(info); } @@ -292,8 +292,13 @@ static int __devinit efifb_probe(struct...

...f: ttm_bo_unref((struct ttm_buffer_object **)&par->vmw_bo); diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c index 581d2db..3b98656 100644 --- a/drivers/video/efifb.c +++ b/drivers/video/efifb.c @@ -165,7 +165,7 @@ static void efifb_destroy(struct fb_info *info) { if (info->screen_base) iounmap(info->screen_base); - release_mem_region(info->aperture_base, info->aperture_size); + release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size); framebuffer_release(info); } @@ -289,8 +289,13 @@ static int __devinit efifb_probe(struct...

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

virtio uses normal ram as backing storage for the framebuffer, so we should assign the address to new screen_buffer (added by commit 17a7b0b4d9749f80d365d7baff5dec2f54b0e992) instead of screen_base. Reported-by: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c b/drivers/gpu/drm/virtio/virtgpu_fb....

virtio uses normal ram as backing storage for the framebuffer, so we should assign the address to new screen_buffer (added by commit 17a7b0b4d9749f80d365d7baff5dec2f54b0e992) instead of screen_base. Reported-by: Michael S. Tsirkin <mst at redhat.com> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_fb.c b/drivers/gpu/drm/virtio/virtgpu_fb....

...nt __devinit broadsheetfb_probe(struct platform_device *dev) videomemorysize = roundup((dpyw*dpyh), PAGE_SIZE); - videomemory = vmalloc(videomemorysize); + videomemory = vzalloc(videomemorysize); if (!videomemory) goto err_fb_rel; - memset(videomemory, 0, videomemorysize); - info->screen_base = (char *)videomemory; info->fbops = &broadsheetfb_ops; diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c index c77bcc6..a941e6f 100644 --- a/drivers/video/hecubafb.c +++ b/drivers/video/hecubafb.c @@ -231,11 +231,10 @@ static int __devinit hecubafb_probe(struct platform_d...

...nt __devinit broadsheetfb_probe(struct platform_device *dev) videomemorysize = roundup((dpyw*dpyh), PAGE_SIZE); - videomemory = vmalloc(videomemorysize); + videomemory = vzalloc(videomemorysize); if (!videomemory) goto err_fb_rel; - memset(videomemory, 0, videomemorysize); - info->screen_base = (char *)videomemory; info->fbops = &broadsheetfb_ops; diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c index c77bcc6..a941e6f 100644 --- a/drivers/video/hecubafb.c +++ b/drivers/video/hecubafb.c @@ -231,11 +231,10 @@ static int __devinit hecubafb_probe(struct platform_d...

On Fr, 2016-11-11 at 17:28 +0100, Jiri Slaby wrote: > On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote: > > On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > >> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > >>> Hi, > >>> > >>> I can relatively easily reproduce this bug: > > > > How? > > Run dmesg -w

On Fr, 2016-11-11 at 17:28 +0100, Jiri Slaby wrote: > On 11/09/2016, 09:01 AM, Gerd Hoffmann wrote: > > On Di, 2016-11-08 at 22:37 +0200, Michael S. Tsirkin wrote: > >> On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > >>> Hi, > >>> > >>> I can relatively easily reproduce this bug: > > > > How? > > Run dmesg -w

...dev_use_iomem(struct fb_info *info) > +{ > + struct drm_fb_helper *fb_helper = info->par; > + struct drm_client_buffer *buffer = fb_helper->buffer; > + > + return !drm_fbdev_use_shadow_fb(fb_helper) && buffer->map.is_iomem; > +} > + > +static ssize_t fb_read_screen_base(struct fb_info *info, char __user *buf, size_t count, > + loff_t pos) > +{ > + const char __iomem *src = info->screen_base + pos; Maybe a bit much a bikeshed, but I'd write this in terms of drm objects, like the dirty_blit function, using the dma_buf_map (instead of the fb_i...

...8a4..149c47a 100644 --- a/drivers/video/vga16fb.c +++ b/drivers/video/vga16fb.c @@ -1263,10 +1263,19 @@ static void vga16fb_imageblit(struct fb_info *info, const struct fb_image *image vga_imageblit_color(info, image); } +static void vga16fb_destroy(struct fb_info *info) +{ + iounmap(info->screen_base); + fb_dealloc_cmap(&info->cmap); + /* XXX unshare VGA regions */ + framebuffer_release(info); +} + static struct fb_ops vga16fb_ops = { .owner = THIS_MODULE, .fb_open = vga16fb_open, .fb_release = vga16fb_release, + .fb_destroy = vga16fb_destroy, .fb_check_var = vga16fb...

...fo) >> +{ >> + struct drm_fb_helper *fb_helper = info->par; >> + struct drm_client_buffer *buffer = fb_helper->buffer; >> + >> + return !drm_fbdev_use_shadow_fb(fb_helper) && buffer->map.is_iomem; >> +} >> + >> +static ssize_t fb_read_screen_base(struct fb_info *info, char __user *buf, size_t count, >> + loff_t pos) >> +{ >> + const char __iomem *src = info->screen_base + pos; > > Maybe a bit much a bikeshed, but I'd write this in terms of drm objects, > like the dirty_blit function, using the dma_b...

...dev_use_iomem(struct fb_info *info) > +{ > + struct drm_fb_helper *fb_helper = info->par; > + struct drm_client_buffer *buffer = fb_helper->buffer; > + > + return !drm_fbdev_use_shadow_fb(fb_helper) && buffer->map.is_iomem; > +} > + > +static ssize_t fb_read_screen_base(struct fb_info *info, char __user *buf, size_t count, > + loff_t pos) The naming here confused me - a name like: fb_read_iomem() would have helped me more. With the current naming I shall remember that the screen_base member is the iomem pointer. > +{ > + const char __iomem *src =...

...ze == 0) > + total_size = info->fix.smem_len; > + > + if (p >= total_size) > + return 0; > + > + if (count >= total_size) > + count = total_size; > + > + if (count + p > total_size) > + count = total_size - p; > + > + src = (u8 __iomem *)(info->screen_base + p); screen_base is a char __iomem * - so this cast looks semi redundant. > + > + alloc_size = min(count, PAGE_SIZE); > + > + dst = kmalloc(alloc_size, GFP_KERNEL); > + if (!dst) > + return -ENOMEM; > + Same comment as below about fb_sync. > + while (count) { > + c...

...nt __devinit broadsheetfb_probe(struct platform_device *dev) videomemorysize = roundup((dpyw*dpyh), PAGE_SIZE); - videomemory = vmalloc(videomemorysize); + videomemory = vzalloc(videomemorysize); if (!videomemory) goto err_fb_rel; - memset(videomemory, 0, videomemorysize); - info->screen_base = (char *)videomemory; info->fbops = &broadsheetfb_ops; diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c index c77bcc6..a941e6f 100644 --- a/drivers/video/hecubafb.c +++ b/drivers/video/hecubafb.c @@ -231,11 +231,10 @@ static int __devinit hecubafb_probe(struct platform_d...

...nt __devinit broadsheetfb_probe(struct platform_device *dev) videomemorysize = roundup((dpyw*dpyh), PAGE_SIZE); - videomemory = vmalloc(videomemorysize); + videomemory = vzalloc(videomemorysize); if (!videomemory) goto err_fb_rel; - memset(videomemory, 0, videomemorysize); - info->screen_base = (char *)videomemory; info->fbops = &broadsheetfb_ops; diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c index c77bcc6..a941e6f 100644 --- a/drivers/video/hecubafb.c +++ b/drivers/video/hecubafb.c @@ -231,11 +231,10 @@ static int __devinit hecubafb_probe(struct platform_d...

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. Differences since last post: * Required patch fixing 32-on-64 xen-blkfront included. * Cleanup when xenkbd_probe() fails fixed. * Don't store event channel in device info. I started