lkml.org 
[lkml]   [2023]   [Apr]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v2 5/5] fbdev: Define framebuffer I/O from Linux' I/O functions
    From
    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

    --
    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]
    \
     
     \ /
      Last update: 2023-04-29 14:27    [W:3.726 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site