| Message ID | 20230428092711.406-6-tzimmermann@suse.de |
|---|---|
| State | New |
| Headers | show |
| Series | fbdev: Use regular I/O function for framebuffers | expand |
On 2023-04-28 10:27, 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. > */ > - > -// This will go away > -#define fb_readb sbus_readb > -#define fb_readw sbus_readw > -#define fb_readl sbus_readl > -#define fb_readq sbus_readq > -#define fb_writeb sbus_writeb > -#define fb_writew sbus_writew > -#define fb_writel sbus_writel > -#define fb_writeq sbus_writeq > -#define fb_memset sbus_memset_io > -#define fb_memcpy_fromfb sbus_memcpy_fromio > -#define fb_memcpy_tofb sbus_memcpy_toio > - > -#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || \ > - defined(__hppa__) || defined(__sh__) || defined(__powerpc__) || \ > - defined(__arm__) || defined(__aarch64__) || defined(__mips__) > - > -#define fb_readb __raw_readb > -#define fb_readw __raw_readw > -#define fb_readl __raw_readl > -#define fb_readq __raw_readq > -#define fb_writeb __raw_writeb > -#define fb_writew __raw_writew > -#define fb_writel __raw_writel > -#define fb_writeq __raw_writeq Note that on at least some architectures, the __raw variants are native-endian, whereas the regular accessors are explicitly little-endian, so there is a slight risk of inadvertently changing behaviour on big-endian systems (MIPS most likely, but a few old ARM platforms run BE as well). > +#define fb_readb readb > +#define fb_readw readw > +#define fb_readl readl > +#if defined(CONFIG_64BIT) > +#define fb_readq readq > +#endif You probably don't need to bother making these conditional - 32-bit architectures aren't forbidden from providing readq/writeq if they really want to, and drivers can also use the io-64-nonatomic headers for portability. The build will still fail in a sufficiently obvious manner if neither is true. Thanks, Robin. > +#define fb_writeb writeb > +#define fb_writew writew > +#define fb_writel writel > +#if defined(CONFIG_64BIT) > +#define fb_writeq writeq > +#endif > #define fb_memset memset_io > #define fb_memcpy_fromfb memcpy_fromio > #define fb_memcpy_tofb memcpy_toio > > -#else > - > -#define fb_readb(addr) (*(volatile u8 *) (addr)) > -#define fb_readw(addr) (*(volatile u16 *) (addr)) > -#define fb_readl(addr) (*(volatile u32 *) (addr)) > -#define fb_readq(addr) (*(volatile u64 *) (addr)) > -#define fb_writeb(b,addr) (*(volatile u8 *) (addr) = (b)) > -#define fb_writew(b,addr) (*(volatile u16 *) (addr) = (b)) > -#define fb_writel(b,addr) (*(volatile u32 *) (addr) = (b)) > -#define fb_writeq(b,addr) (*(volatile u64 *) (addr) = (b)) > -#define fb_memset memset > -#define fb_memcpy_fromfb memcpy > -#define fb_memcpy_tofb memcpy > - > -#endif > - > #define FB_LEFT_POS(p, bpp) (fb_be_math(p) ? (32 - (bpp)) : 0) > #define FB_SHIFT_HIGH(p, val, bits) (fb_be_math(p) ? (val) >> (bits) : \ > (val) << (bits))
On Fri, Apr 28, 2023 at 2:18 PM Robin Murphy <robin.murphy@arm.com> wrote: > On 2023-04-28 10:27, 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. > > */ > > - > > -// This will go away > > -#define fb_readb sbus_readb > > -#define fb_readw sbus_readw > > -#define fb_readl sbus_readl > > -#define fb_readq sbus_readq > > -#define fb_writeb sbus_writeb > > -#define fb_writew sbus_writew > > -#define fb_writel sbus_writel > > -#define fb_writeq sbus_writeq > > -#define fb_memset sbus_memset_io > > -#define fb_memcpy_fromfb sbus_memcpy_fromio > > -#define fb_memcpy_tofb sbus_memcpy_toio > > - > > -#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || \ > > - defined(__hppa__) || defined(__sh__) || defined(__powerpc__) || \ > > - defined(__arm__) || defined(__aarch64__) || defined(__mips__) > > - > > -#define fb_readb __raw_readb > > -#define fb_readw __raw_readw > > -#define fb_readl __raw_readl > > -#define fb_readq __raw_readq > > -#define fb_writeb __raw_writeb > > -#define fb_writew __raw_writew > > -#define fb_writel __raw_writel > > -#define fb_writeq __raw_writeq > > Note that on at least some architectures, the __raw variants are > native-endian, whereas the regular accessors are explicitly > little-endian, so there is a slight risk of inadvertently changing > behaviour on big-endian systems (MIPS most likely, but a few old ARM > platforms run BE as well). Also on m68k, when ISA or PCI are enabled. In addition, the non-raw variants may do some extras to guarantee ordering, which you do not need on a frame buffer. So I'd go for the __raw_*() variants everywhere. Gr{oetje,eeting}s, Geert
Hi Robin, Geert Am 28.04.23 um 14:27 schrieb Geert Uytterhoeven: > On Fri, Apr 28, 2023 at 2:18 PM Robin Murphy <robin.murphy@arm.com> wrote: >> On 2023-04-28 10:27, 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. >>> */ >>> - >>> -// This will go away >>> -#define fb_readb sbus_readb >>> -#define fb_readw sbus_readw >>> -#define fb_readl sbus_readl >>> -#define fb_readq sbus_readq >>> -#define fb_writeb sbus_writeb >>> -#define fb_writew sbus_writew >>> -#define fb_writel sbus_writel >>> -#define fb_writeq sbus_writeq >>> -#define fb_memset sbus_memset_io >>> -#define fb_memcpy_fromfb sbus_memcpy_fromio >>> -#define fb_memcpy_tofb sbus_memcpy_toio >>> - >>> -#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || \ >>> - defined(__hppa__) || defined(__sh__) || defined(__powerpc__) || \ >>> - defined(__arm__) || defined(__aarch64__) || defined(__mips__) >>> - >>> -#define fb_readb __raw_readb >>> -#define fb_readw __raw_readw >>> -#define fb_readl __raw_readl >>> -#define fb_readq __raw_readq >>> -#define fb_writeb __raw_writeb >>> -#define fb_writew __raw_writew >>> -#define fb_writel __raw_writel >>> -#define fb_writeq __raw_writeq >> >> Note that on at least some architectures, the __raw variants are >> native-endian, whereas the regular accessors are explicitly >> little-endian, so there is a slight risk of inadvertently changing >> behaviour on big-endian systems (MIPS most likely, but a few old ARM >> platforms run BE as well). > > Also on m68k, when ISA or PCI are enabled. > > In addition, the non-raw variants may do some extras to guarantee > ordering, which you do not need on a frame buffer. > > So I'd go for the __raw_*() variants everywhere. Ok, makes sense. But it also means that we won't be able to remove the fb_() helpers. If we go with this proposal, I'll add your comments to the header file, so it's clear why they're still there. Best regards Thomas > > Gr{oetje,eeting}s, > > Geert >
Hi Am 28.04.23 um 14:27 schrieb Geert Uytterhoeven: [...] > > In addition, the non-raw variants may do some extras to guarantee > ordering, which you do not need on a frame buffer. Given this comment, should we declare the fb_() helpers in <asm-generic/io.h> or <linux/io.h>? I still don't like the idea of having the functions in <linux/fb.h>. We have code in DRM that also accesses framebuffer memory (via memcpy_toio()). It would make sense to use the fb_() helpers, if they are tailored towards this usecase. Best regards Thomas > > So I'd go for the __raw_*() variants everywhere. > > Gr{oetje,eeting}s, > > Geert >
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. 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
On Fri, Apr 28, 2023, at 13:27, Geert Uytterhoeven wrote: > On Fri, Apr 28, 2023 at 2:18 PM Robin Murphy <robin.murphy@arm.com> wrote: >> On 2023-04-28 10:27, Thomas Zimmermann wrote: >> > - >> > -#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || \ >> > - defined(__hppa__) || defined(__sh__) || defined(__powerpc__) || \ >> > - defined(__arm__) || defined(__aarch64__) || defined(__mips__) >> > - >> > -#define fb_readb __raw_readb >> > -#define fb_readw __raw_readw >> > -#define fb_readl __raw_readl >> > -#define fb_readq __raw_readq >> > -#define fb_writeb __raw_writeb >> > -#define fb_writew __raw_writew >> > -#define fb_writel __raw_writel >> > -#define fb_writeq __raw_writeq >> >> Note that on at least some architectures, the __raw variants are >> native-endian, whereas the regular accessors are explicitly >> little-endian, so there is a slight risk of inadvertently changing >> behaviour on big-endian systems (MIPS most likely, but a few old ARM >> platforms run BE as well). > > Also on m68k, when ISA or PCI are enabled. > > In addition, the non-raw variants may do some extras to guarantee > ordering, which you do not need on a frame buffer. > > So I'd go for the __raw_*() variants everywhere. The only implementations in fbdev are 1) sparc sbus 2) __raw_writel 3) direct pointer dereference But none use the byte-swapping writel() implementations, and the only ones that use the direct pointer dereference or sbus are the ones on which these are defined the same as __raw_writel Arnd
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
Hi Thomas, On Fri, Apr 28, 2023 at 04:18:38PM +0200, Thomas Zimmermann wrote: > 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> How about throwing them into a new drm_fb.h header file. This header file could be the home for all the fb stuff that is shared between drm and the legacy fbdev. Then we may slowly migrate more fbdev stuff to drm and let the legacy fbdev stuff use the maintained drm stuff. Dunno, the pain may not be worth it. Sam
Hi Am 28.04.23 um 15:17 schrieb Arnd Bergmann: > On Fri, Apr 28, 2023, at 13:27, Geert Uytterhoeven wrote: >> On Fri, Apr 28, 2023 at 2:18 PM Robin Murphy <robin.murphy@arm.com> wrote: >>> On 2023-04-28 10:27, Thomas Zimmermann wrote: > >>>> - >>>> -#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || \ >>>> - defined(__hppa__) || defined(__sh__) || defined(__powerpc__) || \ >>>> - defined(__arm__) || defined(__aarch64__) || defined(__mips__) >>>> - >>>> -#define fb_readb __raw_readb >>>> -#define fb_readw __raw_readw >>>> -#define fb_readl __raw_readl >>>> -#define fb_readq __raw_readq >>>> -#define fb_writeb __raw_writeb >>>> -#define fb_writew __raw_writew >>>> -#define fb_writel __raw_writel >>>> -#define fb_writeq __raw_writeq >>> >>> Note that on at least some architectures, the __raw variants are >>> native-endian, whereas the regular accessors are explicitly >>> little-endian, so there is a slight risk of inadvertently changing >>> behaviour on big-endian systems (MIPS most likely, but a few old ARM >>> platforms run BE as well). >> >> Also on m68k, when ISA or PCI are enabled. >> >> In addition, the non-raw variants may do some extras to guarantee >> ordering, which you do not need on a frame buffer. >> >> So I'd go for the __raw_*() variants everywhere. > > The only implementations in fbdev are > > 1) sparc sbus > 2) __raw_writel > 3) direct pointer dereference > > But none use the byte-swapping writel() implementations, and > the only ones that use the direct pointer dereference or sbus > are the ones on which these are defined the same as __raw_writel After thinking a bit more about the requirements, I'd like to got back to v1, but with a different spin. We want to avoid ordering guarantees, so I looked at the _relaxed() helpers, but they seem to swap bytes to little endian. I guess we can remove the fb_mem*() functions entirely. They are the same as the non-fb_ counterparts. For the fb read/write helpers, I'd like to add them to <asm-generic/fb.h> in a platform-neutral way. They'd be wrappers around __raw_(), as I wouldn't want invocations of __raw_() functions in the fbdev drivers. Best regards Thomas > > Arnd
Hi Sam Am 28.04.23 um 18:54 schrieb Sam Ravnborg: > Hi Thomas, > > On Fri, Apr 28, 2023 at 04:18:38PM +0200, Thomas Zimmermann wrote: >> 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> > > How about throwing them into a new drm_fb.h header file. > This header file could be the home for all the fb stuff that is > shared between drm and the legacy fbdev. > > Then we may slowly migrate more fbdev stuff to drm and let the legacy > fbdev stuff use the maintained drm stuff. > Dunno, the pain may not be worth it. DRM might not be relevant if we can remove fb_mem*(). So I'd like to go back to something closer to v1 of these patches. See my reply to Arnd. Best regards Thomas > > Sam
On Sat, Apr 29, 2023, at 14:26, Thomas Zimmermann wrote: > Am 28.04.23 um 15:17 schrieb Arnd Bergmann: >> The only implementations in fbdev are >> >> 1) sparc sbus >> 2) __raw_writel >> 3) direct pointer dereference >> >> But none use the byte-swapping writel() implementations, and >> the only ones that use the direct pointer dereference or sbus >> are the ones on which these are defined the same as __raw_writel > > After thinking a bit more about the requirements, I'd like to got back > to v1, but with a different spin. We want to avoid ordering guarantees, > so I looked at the _relaxed() helpers, but they seem to swap bytes to > little endian. Right, the _relaxed() oens are clearly wrong, aside from the byteswap they also include barriers on some architectures where the __raw_* version is more relaxed than the required semantics for relaxed. > I guess we can remove the fb_mem*() functions entirely. They are the > same as the non-fb_ counterparts. These might actually be different in some cases, or sub-optimal at the moment. memcpy()/memset() don't take __iomem pointers, so they cause sparse warnings, while the memset_io()/memcpy_fromio()/ memcpy_toio() sometimes fall back to bytewise access that is slower than word-sized copy. I only looked at the readl/writel style functions earlier, no idea what we want here. > For the fb read/write helpers, I'd > like to add them to <asm-generic/fb.h> in a platform-neutral way. They'd > be wrappers around __raw_(), as I wouldn't want invocations of __raw_() > functions in the fbdev drivers. That sounds good to me. Arnd
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. */ - -// This will go away -#define fb_readb sbus_readb -#define fb_readw sbus_readw -#define fb_readl sbus_readl -#define fb_readq sbus_readq -#define fb_writeb sbus_writeb -#define fb_writew sbus_writew -#define fb_writel sbus_writel -#define fb_writeq sbus_writeq -#define fb_memset sbus_memset_io -#define fb_memcpy_fromfb sbus_memcpy_fromio -#define fb_memcpy_tofb sbus_memcpy_toio - -#elif defined(__i386__) || defined(__alpha__) || defined(__x86_64__) || \ - defined(__hppa__) || defined(__sh__) || defined(__powerpc__) || \ - defined(__arm__) || defined(__aarch64__) || defined(__mips__) - -#define fb_readb __raw_readb -#define fb_readw __raw_readw -#define fb_readl __raw_readl -#define fb_readq __raw_readq -#define fb_writeb __raw_writeb -#define fb_writew __raw_writew -#define fb_writel __raw_writel -#define fb_writeq __raw_writeq +#define fb_readb readb +#define fb_readw readw +#define fb_readl readl +#if defined(CONFIG_64BIT) +#define fb_readq readq +#endif +#define fb_writeb writeb +#define fb_writew writew +#define fb_writel writel +#if defined(CONFIG_64BIT) +#define fb_writeq writeq +#endif #define fb_memset memset_io #define fb_memcpy_fromfb memcpy_fromio #define fb_memcpy_tofb memcpy_toio -#else - -#define fb_readb(addr) (*(volatile u8 *) (addr)) -#define fb_readw(addr) (*(volatile u16 *) (addr)) -#define fb_readl(addr) (*(volatile u32 *) (addr)) -#define fb_readq(addr) (*(volatile u64 *) (addr)) -#define fb_writeb(b,addr) (*(volatile u8 *) (addr) = (b)) -#define fb_writew(b,addr) (*(volatile u16 *) (addr) = (b)) -#define fb_writel(b,addr) (*(volatile u32 *) (addr) = (b)) -#define fb_writeq(b,addr) (*(volatile u64 *) (addr) = (b)) -#define fb_memset memset -#define fb_memcpy_fromfb memcpy -#define fb_memcpy_tofb memcpy - -#endif - #define FB_LEFT_POS(p, bpp) (fb_be_math(p) ? (32 - (bpp)) : 0) #define FB_SHIFT_HIGH(p, val, bits) (fb_be_math(p) ? (val) >> (bits) : \ (val) << (bits))
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(-)