lkml.org 
[lkml]   [2009]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Do cpu-endian MMIO accessors exist?
    Date
    On Tuesday 21 July 2009, Christoph Hellwig wrote:
    > Why would you want to do that? That just means a useless byteswap.
    > We really should have a generic native-endian MMIO-access API as there
    > is quite a bit of hardware with features like that, and currently we
    > have a miriad of hacks using __raw_* and manual barriers, the ppc
    > specific accessors and god knows what.

    The byte swap on powerpc I/O instructions is practically free
    on all the interesting CPUs, and on the others it is still
    swamped by the overhead of the synchronization. If you care
    about the latency of MMIO instructions, going to explicit
    synchronization would help much more, saving hundreds of
    cycles per I/O rather than one cycle for a saved byte swap.

    The powerpc in_le32 style functions are a completely different
    story, they are basically defined to operate only on on-chip
    components, while ioread32 and readl do work on PCI devices.

    No portable code should ever use the __raw_* functions and
    architecture specific barriers.

    It would of course be easy to just define an API extension
    to ioread along the lines of

    #ifdef __BIG_ENDIAN
    #define ioread16_native ioread16be
    #define ioread32_native ioread32be
    #define iowrite16_native iowrite16be
    #define iowrite32_native iowrite32be
    #else
    #define ioread16_native ioread16
    #define ioread32_native ioread32
    #define iowrite16_native iowrite16
    #define iowrite32_native iowrite32
    #endif

    but I'm not yet convinced that there is a potential user that
    should not just be fixed in a different way.

    Arnd <><


    \
     
     \ /
      Last update: 2009-07-22 00:05    [W:0.050 / U:0.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site