| Message ID | 20230428122452.4856-1-tzimmermann@suse.de |
|---|---|
| Headers | show |
| Series | drm,fbdev: Use fbdev's I/O helpers | expand |
Thomas Zimmermann <tzimmermann@suse.de> writes: > Use info->screen_buffer when reading and writing framebuffers in > system memory. It's the correct pointer for this address space. > > The struct fb_info has a union to store the framebuffer memory. This can > either be info->screen_base if the framebuffer is stored in I/O memory, > or info->screen_buffer if the framebuffer is stored in system memory. > > As the driver operates on the latter address space, it is wrong to use > .screen_base and .screen_buffer must be used instead. This also gets > rid of casting needed due to not using the correct data type. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thomas Zimmermann <tzimmermann@suse.de> writes: > Use info->screen_buffer when reading and writing framebuffers in > system memory. It's the correct pointer for this address space. > > The struct fb_info has a union to store the framebuffer memory. This can > either be info->screen_base if the framebuffer is stored in I/O memory, > or info->screen_buffer if the framebuffer is stored in system memory. > > As the driver operates on the latter address space, it is wrong to use > .screen_base and .screen_buffer must be used instead. This also gets > rid of casting needed due to not using the correct data type. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thomas Zimmermann <tzimmermann@suse.de> writes: > Use info->screen_buffer when reading and writing framebuffers in > system memory. It's the correct pointer for this address space. > > The struct fb_info has a union to store the framebuffer memory. This can > either be info->screen_base if the framebuffer is stored in I/O memory, > or info->screen_buffer if the framebuffer is stored in system memory. > > As the driver operates on the latter address space, it is wrong to use > .screen_base and .screen_buffer must be used instead. This also gets > rid of casting needed due to not using the correct data type. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thomas Zimmermann <tzimmermann@suse.de> writes: > Use info->screen_buffer when reading and writing framebuffers in > system memory. It's the correct pointer for this address space. > > The struct fb_info has a union to store the framebuffer memory. This can > either be info->screen_base if the framebuffer is stored in I/O memory, > or info->screen_buffer if the framebuffer is stored in system memory. > > As the driver operates on the latter address space, it is wrong to use > .screen_base and .screen_buffer must be used instead. This also gets > rid of casting needed due to not using the correct data type. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thomas Zimmermann <tzimmermann@suse.de> writes: > Use info->screen_buffer when reading and writing framebuffers in > system memory. It's the correct pointer for this address space. > > The struct fb_info has a union to store the framebuffer memory. This can > either be info->screen_base if the framebuffer is stored in I/O memory, > or info->screen_buffer if the framebuffer is stored in system memory. > > As the driver operates on the latter address space, it is wrong to use > .screen_base and .screen_buffer must be used instead. This also gets > rid of casting needed due to not using the correct data type. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thomas Zimmermann <tzimmermann@suse.de> writes: > Use info->screen_buffer when reading and writing framebuffers in > system memory. It's the correct pointer for this address space. > > The struct fb_info has a union to store the framebuffer memory. This can > either be info->screen_base if the framebuffer is stored in I/O memory, > or info->screen_buffer if the framebuffer is stored in system memory. > > As the driver operates on the latter address space, it is wrong to use > .screen_base and .screen_buffer must be used instead. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thomas Zimmermann <tzimmermann@suse.de> writes: > Use info->screen_buffer when reading and writing framebuffers in > system memory. It's the correct pointer for this address space. > > The struct fb_info has a union to store the framebuffer memory. This can > either be info->screen_base if the framebuffer is stored in I/O memory, > or info->screen_buffer if the framebuffer is stored in system memory. > > As the driver operates on the latter address space, it is wrong to use > .screen_base and .screen_buffer must be used instead. This also gets > rid of casting needed due to not using the correct data type. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Thomas Zimmermann <tzimmermann@suse.de> writes: > Use info->screen_buffer when reading and writing framebuffers in > system memory. It's the correct pointer for this address space. > > The struct fb_info has a union to store the framebuffer memory. This can > either be info->screen_base if the framebuffer is stored in I/O memory, > or info->screen_buffer if the framebuffer is stored in system memory. > > As the driver operates on the latter address space, it is wrong to use > .screen_base and .screen_buffer must be used instead. This also gets > rid of casting needed due to not using the correct data type. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > --- Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Make fbdev's built-in helpers for reading and writing I/O and system memory available to DRM. Replace DRM's internal helpers. The first 13 patches and patch 15 fix the use of screen_base and screen_buffer. A number of drivers mix them up. Patch 14 resolves a bug that's been in the fbdev code for more than 15 years. Makes the read/write helpers work successfully with the IGT tests. Patches 16 and 17 streamline fbdev's file-I/O code and remove a few duplicate checks. Patch 18 moves the default-I/O code into the new helpers fb_io_read() and fb_io_write(); patch 19 uses them in DRM. This allows us to remove quite a bit of code from DRM's internal fbdev helpers. Tested with i915 and simpledrm. The next step here is to remove the drm_fb_helper_{cfb,sys}_*() entirely. They where mostly introduced because fbdev doesn't protect it's public interfaces with an CONFIG_FB preprocessor guards. But all of DRM driver's fbdev emulation won't be build without CONFIG_FB, so this is not an issue in practice. Removing the DRM wrappers will further simplify the DRM code. v2: * fix screen_base vs. screen_buffer usage * fix copy_{from,to}_user() return value (Geert) * use fb_io_() prefix (Geert) * improved commit messages Thomas Zimmermann (19): auxdisplay/cfag12864bfb: Use struct fb_info.screen_buffer auxdisplay/ht16k33: Use struct fb_info.screen_buffer hid/hid-picolcd_fb: Use struct fb_info.screen_buffer fbdev/arcfb: Use struct fb_info.screen_buffer fbdev/au1200fb: Use struct fb_info.screen_buffer fbdev/broadsheetfb: Use struct fb_info.screen_buffer fbdev/hecubafb: Use struct fb_info.screen_buffer fbdev/metronomefb: Use struct fb_info.screen_buffer fbdev/ps3fb: Use struct fb_info.screen_buffer fbdev/smscufx: Use struct fb_info.screen_buffer fbdev/udlfb: Use struct fb_info.screen_buffer fbdev/vfb: Use struct fb_info.screen_buffer fbdev/xen-fbfront: Use struct fb_info.screen_buffer fbdev: Return number of bytes read or written fbdev: Use screen_buffer in fb_sys_{read,write}() fbdev: Don't re-validate info->state in fb_ops implementations fbdev: Validate info->screen_{base,buffer} in fb_ops implementations fbdev: Move I/O read and write code into helper functions drm/fb-helper: Use fb_{cfb,sys}_{read, write}() drivers/auxdisplay/cfag12864bfb.c | 2 +- drivers/auxdisplay/ht16k33.c | 2 +- drivers/gpu/drm/drm_fb_helper.c | 174 +------------------------ drivers/hid/hid-picolcd_fb.c | 4 +- drivers/media/pci/ivtv/ivtvfb.c | 4 +- drivers/video/fbdev/arcfb.c | 11 +- drivers/video/fbdev/au1200fb.c | 2 +- drivers/video/fbdev/broadsheetfb.c | 16 +-- drivers/video/fbdev/cobalt_lcdfb.c | 6 + drivers/video/fbdev/core/Makefile | 2 +- drivers/video/fbdev/core/fb_io_fops.c | 133 +++++++++++++++++++ drivers/video/fbdev/core/fb_sys_fops.c | 36 ++--- drivers/video/fbdev/core/fbmem.c | 111 +--------------- drivers/video/fbdev/hecubafb.c | 12 +- drivers/video/fbdev/metronomefb.c | 16 +-- drivers/video/fbdev/ps3fb.c | 4 +- drivers/video/fbdev/pvr2fb.c | 3 + drivers/video/fbdev/sm712fb.c | 10 +- drivers/video/fbdev/smscufx.c | 14 +- drivers/video/fbdev/ssd1307fb.c | 3 + drivers/video/fbdev/udlfb.c | 12 +- drivers/video/fbdev/vfb.c | 2 +- drivers/video/fbdev/xen-fbfront.c | 2 +- include/linux/fb.h | 10 ++ 24 files changed, 239 insertions(+), 352 deletions(-) create mode 100644 drivers/video/fbdev/core/fb_io_fops.c