Hi Thomas,
> > But I am missing something somewhere as I cannot see how this builds.
> > asm-generic now provide the fb_read/fb_write helpers.
> > But for example sparc has an architecture specifc fb.h so it will not
> > use the asm-generic variant. So I wonder how sparc get hold of the
> >
On Wed, May 3, 2023, at 16:55, Thomas Zimmermann wrote:
> Am 02.05.23 um 22:06 schrieb Arnd Bergmann:
>> It's probably safe to deal with all the above by either adding
>> architecture specific overrides to the current version, or
>> by doing the semantic changes before the move to asm/fb.h, but
Hi
Am 02.05.23 um 22:06 schrieb Arnd Bergmann:
On Tue, May 2, 2023, at 15:02, Thomas Zimmermann wrote:
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
in the architecture's header file or the generic one.
The common case has been the use of regular I/O functions, such
Hi Sam
Am 02.05.23 um 22:03 schrieb Sam Ravnborg:
Hi Thomas,
On Tue, May 02, 2023 at 03:02:22PM +0200, Thomas Zimmermann wrote:
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
in the architecture's header file or the generic one.
In reality they are now all
On Tue, May 2, 2023, at 15:02, Thomas Zimmermann wrote:
> Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
> in the architecture's header file or the generic one.
>
> The common case has been the use of regular I/O functions, such as
> __raw_readb() or memset_io(). A few
Hi Thomas,
On Tue, May 02, 2023 at 03:02:22PM +0200, Thomas Zimmermann wrote:
> Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
> in the architecture's header file or the generic one.
In reality they are now all implemented in the generic one.
>
> The common case has
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
in the architecture's header file or the generic one.
The common case has been the use of regular I/O functions, such as
__raw_readb() or memset_io(). A few architectures used plain system-
memory reads and writes. Sparc used
