Messages in this thread | | | Date | Fri, 28 Apr 2023 16:18:38 +0200 | Subject | Re: [PATCH v2 5/5] fbdev: Define framebuffer I/O from Linux' I/O functions | From | Thomas Zimmermann <> |
| |
Hi
Am 28.04.23 um 15:12 schrieb Sam Ravnborg: > Hi Thomas, > > On Fri, Apr 28, 2023 at 11:27:11AM +0200, Thomas Zimmermann wrote: >> Implement framebuffer I/O helpers, such as fb_read*() and fb_write*() >> with Linux' regular I/O functions. Remove all ifdef cases for the >> various architectures. >> >> Most of the supported architectures use __raw_() I/O functions or treat >> framebuffer memory like regular memory. This is also implemented by the >> architectures' I/O function, so we can use them instead. >> >> Sparc uses SBus to connect to framebuffer devices. It provides respective >> implementations of the framebuffer I/O helpers. The involved sbus_() >> I/O helpers map to the same code as Sparc's regular I/O functions. As >> with other platforms, we can use those instead. >> >> We leave a TODO item to replace all fb_() functions with their regular >> I/O counterparts throughout the fbdev drivers. >> >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> >> --- >> include/linux/fb.h | 63 +++++++++++----------------------------------- >> 1 file changed, 15 insertions(+), 48 deletions(-) >> >> diff --git a/include/linux/fb.h b/include/linux/fb.h >> index 08cb47da71f8..4aa9e90edd17 100644 >> --- a/include/linux/fb.h >> +++ b/include/linux/fb.h >> @@ -15,7 +15,6 @@ >> #include <linux/list.h> >> #include <linux/backlight.h> >> #include <linux/slab.h> >> -#include <asm/io.h> >> >> struct vm_area_struct; >> struct fb_info; >> @@ -511,58 +510,26 @@ struct fb_info { >> */ >> #define STUPID_ACCELF_TEXT_SHIT >> >> -// This will go away >> -#if defined(__sparc__) >> - >> -/* We map all of our framebuffers such that big-endian accesses >> - * are what we want, so the following is sufficient. >> +/* >> + * TODO: Update fbdev drivers to call the I/O helpers directly and >> + * remove the fb_() tokens. >> */ > When the __raw_* variants are used, as Geert points out, then I think > the memcpy / memset can be replaced, but the rest seems fine to keep.
I'd either want the regular I/O functions or the fb_() wrappers, but not the __raw_() function. I'd also prefer to keep fb_ in front of memset and memcpy. I'd be happy to have fb_() wrappers that are I/O helpers without ordering guarantees. I'd just wouldn't want them in <linux/fb.h>
Best regards Thomas
> > My personal opinion is that __raw_* is for macro use etc, and not > something to use everywhere. So I like the fb_read/fb_write macros. > But that is just my color of the bikeshed. > > Sam
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) [unhandled content-type:application/pgp-signature] | |