search for: dirty_lock

Hi, When I tested pvfb, I got the following warnings. It seems to be caused by checking/setting info->dirty without dirty_lock. We need to check/set info->dirty safely. xenfb_update_screen bogus rect 2147483647 0 2147483647 0 BUG: warning at /root/linux-2.6.18-xen.hg/drivers/xen/fbfront/xenfb.c:240/xenfb_update_screen() Call Trace: [<ffffffff8036920e>] xenfb_thread+0x19b/0x2be [<ffffffff8022730a>] tr...

...pu_drv.h index 5faccf92aa15..9e2d3062b01d 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -142,9 +142,6 @@ struct virtio_gpu_output { struct virtio_gpu_framebuffer { struct drm_framebuffer base; - int x1, y1, x2, y2; /* dirty rect */ - spinlock_t dirty_lock; - uint32_t hw_res_handle; struct virtio_gpu_fence *fence; }; #define to_virtio_gpu_framebuffer(x) \ @@ -254,10 +251,6 @@ int virtio_gpu_mode_dumb_mmap(struct drm_file *file_priv, struct drm_device *dev, uint32_t handle, uint64_t *offset_p); -/* virtio_fb */ -int virtio_gp...

...6 @@ #define to_mga_encoder(x) container_of(x, struct mga_encoder, base) #define to_mga_connector(x) container_of(x, struct mga_connector, base) -struct mga_fbdev { - struct drm_fb_helper helper; /* must be first */ - void *sysram; - int size; - int x1, y1, x2, y2; /* dirty rect */ - spinlock_t dirty_lock; -}; - struct mga_crtc { struct drm_crtc base; u8 lut_r[256], lut_g[256], lut_b[256]; @@ -180,7 +172,6 @@ struct mga_device { struct mga_mc mc; struct mga_mode_info mode_info; - struct mga_fbdev *mfbdev; struct mga_cursor cursor; bool suspended; @@ -201,19 +192,9 @@ struct mg...

...t_fbdev *fbdev; - int fb_mtrr; struct drm_gem_object *cursor_cache; @@ -239,14 +235,6 @@ struct ast_encoder { struct drm_encoder base; }; -struct ast_fbdev { - struct drm_fb_helper helper; /* must be first */ - void *sysram; - int size; - int x1, y1, x2, y2; /* dirty rect */ - spinlock_t dirty_lock; -}; - #define to_ast_crtc(x) container_of(x, struct ast_crtc, base) #define to_ast_connector(x) container_of(x, struct ast_connector, base) #define to_ast_encoder(x) container_of(x, struct ast_encoder, base) @@ -289,11 +277,6 @@ struct ast_vbios_mode_info { extern int ast_mode_init(struct drm_...

DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enough space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer

DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enough space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer

DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enougth space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer

DRM client buffers are permanently mapped throughout their lifetime. This prevents us from using generic framebuffer emulation for devices with small dedicated video memory, such as ast or mgag200. With fb buffers permanently mapped, such devices often won't have enougth space left to display other content (e.g., X11). This patch set introduces unmappable DRM client buffers for framebuffer

...metronomefb_ops; diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c index 428d273..81fcaea 100644 --- a/drivers/video/xen-fbfront.c +++ b/drivers/video/xen-fbfront.c @@ -395,10 +395,9 @@ static int __devinit xenfb_probe(struct xenbus_device *dev, spin_lock_init(&info->dirty_lock); spin_lock_init(&info->resize_lock); - info->fb = vmalloc(fb_size); + info->fb = vzalloc(fb_size); if (info->fb == NULL) goto error_nomem; - memset(info->fb, 0, fb_size); info->nr_pages = (fb_size + PAGE_SIZE - 1) >> PAGE_SHIFT; -- 1.7.3.1.g432b3.dirty

...metronomefb_ops; diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c index 428d273..81fcaea 100644 --- a/drivers/video/xen-fbfront.c +++ b/drivers/video/xen-fbfront.c @@ -395,10 +395,9 @@ static int __devinit xenfb_probe(struct xenbus_device *dev, spin_lock_init(&info->dirty_lock); spin_lock_init(&info->resize_lock); - info->fb = vmalloc(fb_size); + info->fb = vzalloc(fb_size); if (info->fb == NULL) goto error_nomem; - memset(info->fb, 0, fb_size); info->nr_pages = (fb_size + PAGE_SIZE - 1) >> PAGE_SHIFT; -- 1.7.3.1.g432b3.dirty

...b338dce..6180acbca7ca 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.h +++ b/drivers/gpu/drm/mgag200/mgag200_drv.h @@ -115,7 +115,6 @@ struct mga_fbdev { struct mga_framebuffer mfb; void *sysram; int size; - struct ttm_bo_kmap_obj mapping; int x1, y1, x2, y2; /* dirty rect */ spinlock_t dirty_lock; }; diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c b/drivers/gpu/drm/mgag200/mgag200_fb.c index 508ec2dddbba..7c457dad5d9e 100644 --- a/drivers/gpu/drm/mgag200/mgag200_fb.c +++ b/drivers/gpu/drm/mgag200/mgag200_fb.c @@ -27,6 +27,7 @@ static void mga_dirty_update(struct mga_fbdev *mfbdev, int...

...rty_clip; > unsigned long flags; > > - if (!helper->fb->funcs->dirty) > - return; drm_fb_helper_dirty() is called unconditionally by drm_fb_helper_sys_imageblit() et al, so we need check with drm_fbdev_use_shadow_fb() here. > - > spin_lock_irqsave(&helper->dirty_lock, flags); > clip->x1 = min_t(u32, clip->x1, x); > clip->y1 = min_t(u32, clip->y1, y); > @@ -2166,6 +2165,16 @@ static struct fb_deferred_io drm_fbdev_defio = { > .deferred_io = drm_fb_helper_deferred_io, > }; > > +static bool drm_fbdev_use_shadow_fb(struct d...

...rty_clip; > unsigned long flags; > > - if (!helper->fb->funcs->dirty) > - return; drm_fb_helper_dirty() is called unconditionally by drm_fb_helper_sys_imageblit() et al, so we need check with drm_fbdev_use_shadow_fb() here. > - > spin_lock_irqsave(&helper->dirty_lock, flags); > clip->x1 = min_t(u32, clip->x1, x); > clip->y1 = min_t(u32, clip->y1, y); > @@ -2166,6 +2165,16 @@ static struct fb_deferred_io drm_fbdev_defio = { > .deferred_io = drm_fb_helper_deferred_io, > }; > > +static bool drm_fbdev_use_shadow_fb(struct 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

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

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

...id drm_fb_helper_dirty_work(struct work_struct *work) > struct drm_clip_rect *clip = &helper->dirty_clip; > struct drm_clip_rect clip_copy; > unsigned long flags; > - void *vaddr; > + struct dma_buf_map map; > + int ret; > > spin_lock_irqsave(&helper->dirty_lock, flags); > clip_copy = *clip; > @@ -413,8 +414,8 @@ static void drm_fb_helper_dirty_work(struct work_struct *work) > > /* Generic fbdev uses a shadow buffer */ > if (helper->buffer) { > - vaddr = drm_client_buffer_vmap(helper->buffer); > - if (IS_ERR(vaddr))...