Access GPIO from user space - Embedded

This is a discussion on Access GPIO from user space - Embedded ; I am looking into a quickest and most efficient way to access GPIO (powerpc, ie. IMMAP) from user space. 1. Write driver and use ioctl - takes a few msec to get access. Too long and heavy on resources. 2. ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Access GPIO from user space

  1. Access GPIO from user space

    I am looking into a quickest and most efficient way to access GPIO
    (powerpc, ie. IMMAP) from user space.
    1. Write driver and use ioctl - takes a few msec to get access. Too
    long and heavy on resources.
    2. Use mmap to map immap (powerpc) to user space - should be very
    quick.

    Right now I am considering to use mmap for this purpose. Does anybody
    knows any better way of doing this.

    Thank you


  2. Re: Access GPIO from user space

    Dimitry wrote:

    > I am looking into a quickest and most efficient way to access GPIO
    > (powerpc, ie. IMMAP) from user space.
    > 1. Write driver and use ioctl - takes a few msec to get access. Too
    > long and heavy on resources.
    > 2. Use mmap to map immap (powerpc) to user space - should be very
    > quick.
    >
    > Right now I am considering to use mmap for this purpose. Does anybody
    > knows any better way of doing this.
    >
    > Thank you


    Probably 3. Write a dedicated driver to do the quick stuff in kernel space
    and the chardriver for non-critical things.

    Typically, you would have a hardware specific GPIO driver with a
    generic API which is then used by the generic chardriver and
    any other driver which need GPIO access.

    Kind regards,

    Iwo


  3. Re: Access GPIO from user space

    Dimitry wrote:

    > Right now I am considering to use mmap for this purpose. Does anybody
    > knows any better way of doing this.


    The two methods you listed are the only methods.

    mmap() should work perfectly fine, although there will be slightly more
    overhead. The overhead may become noticeable if you are doing something
    that requires tight timing.


  4. Re: Access GPIO from user space

    Geronimo W. Christ Esq wrote:
    > Dimitry wrote:
    >
    >> Right now I am considering to use mmap for this purpose. Does anybody
    >> knows any better way of doing this.

    >
    > The two methods you listed are the only methods.
    >
    > mmap() should work perfectly fine, although there will be slightly more
    > overhead. The overhead may become noticeable if you are doing something
    > that requires tight timing.
    >


    Could you please explain this? I would think that once the mapping is
    established there would be no overhead at all.


    Thanks,
    Dave

  5. Re: Access GPIO from user space

    Dave Littell wrote:

    >> mmap() should work perfectly fine, although there will be slightly more
    >> overhead. The overhead may become noticeable if you are doing something
    >> that requires tight timing.

    >
    > Could you please explain this? I would think that once the mapping is
    > established there would be no overhead at all.


    TLB activity. When you're in the kernel, there are ways (on most
    architectures) to access hardware directly without going through the
    MMU. You definitely cannot do this in user space.

  6. Re: Access GPIO from user space

    Geronimo W. Christ Esq wrote:
    > Dave Littell wrote:
    >
    >>> mmap() should work perfectly fine, although there will be slightly more
    >>> overhead. The overhead may become noticeable if you are doing something
    >>> that requires tight timing.

    >>
    >> Could you please explain this? I would think that once the mapping is
    >> established there would be no overhead at all.

    >
    > TLB activity. When you're in the kernel, there are ways (on most
    > architectures) to access hardware directly without going through the
    > MMU. You definitely cannot do this in user space.


    But even that would consume far fewer processor cycles than going
    through the I/O system for each and every device access, right?


    Thanks,
    Dave

  7. Re: Access GPIO from user space

    On Sat, 11 Nov 2006 18:29:22 +0000, "Geronimo W. Christ Esq"
    wrote:

    >Dave Littell wrote:
    >
    >>> mmap() should work perfectly fine, although there will be slightly more
    >>> overhead. The overhead may become noticeable if you are doing something
    >>> that requires tight timing.

    >>
    >> Could you please explain this? I would think that once the mapping is
    >> established there would be no overhead at all.

    >
    >TLB activity. When you're in the kernel, there are ways (on most
    >architectures) to access hardware directly without going through the
    >MMU. You definitely cannot do this in user space.


    Could you, specify in which systems the kernel mode does not use the
    MMU ?

    Apart from any boot code, any operating system is using the MMU to
    access the peripherals/system memory.

    Paul


  8. Re: Access GPIO from user space

    In article <8Bq5h.271$v93.228@trnddc06>,
    Dave Littell writes:
    > Geronimo W. Christ Esq wrote:
    >> Dave Littell wrote:
    >>
    >>>> mmap() should work perfectly fine, although there will be slightly more
    >>>> overhead. The overhead may become noticeable if you are doing something
    >>>> that requires tight timing.
    >>>
    >>> Could you please explain this? I would think that once the mapping is
    >>> established there would be no overhead at all.

    >>
    >> TLB activity. When you're in the kernel, there are ways (on most
    >> architectures) to access hardware directly without going through the
    >> MMU. You definitely cannot do this in user space.

    >
    > But even that would consume far fewer processor cycles than going
    > through the I/O system for each and every device access, right?
    >


    Yes. Plus, if it's on a PowerPC, I wouldn't worry too much about
    TLB overhead since the PPC features a "tagged TLB": the TLB
    doesn't need to be flushed on every address space switch.

    Greetings

    Rob

    --
    Robert Kaiser email: rkaiser AT sysgo DOT com
    SYSGO AG http://www.elinos.com
    Klein-Winternheim / Germany http://www.sysgo.com

  9. Re: Access GPIO from user space

    Robert Kaiser wrote:

    > Yes. Plus, if it's on a PowerPC, I wouldn't worry too much about
    > TLB overhead since the PPC features a "tagged TLB": the TLB
    > doesn't need to be flushed on every address space switch.


    How does this work ? Surely the address mapping for one process is
    completely independent of the address mapping for another process ?

    I know on MIPS you can use fixed TLB entries. But reducing the number of
    available TLB entries for normal activities will increase the frequency
    of TLB misses.

  10. Re: Access GPIO from user space

    Paul Keinanen wrote:

    > Could you, specify in which systems the kernel mode does not use the
    > MMU ?


    I'm pretty sure it's anywhere where memory is allocated by kmalloc(),
    and possibly ioremap().

    The architecture I'm most familiar with is MIPS. The memory map is laid
    out such that there is a 512MB fixed mapping available at all times
    which maps to the lowest 512MB of physical memory. There is a cached and
    uncached mapping. So when you're in supervisor mode, you can just hit
    the addresses here without requiring TLB entries. When you call
    ioremap() on MIPS, if the memory is in this range it just returns a
    pointer to the offset.

    I believe on PPC, the BAT registers achieve the same ?

    > Apart from any boot code, any operating system is using the MMU to
    > access the peripherals/system memory.


    See above.

  11. Re: Access GPIO from user space

    In article <1163354202.26602.1@proxy00.news.clara.net>,
    "Geronimo W. Christ Esq" writes:
    > Robert Kaiser wrote:
    >
    >> Yes. Plus, if it's on a PowerPC, I wouldn't worry too much about
    >> TLB overhead since the PPC features a "tagged TLB": the TLB
    >> doesn't need to be flushed on every address space switch.

    >
    > How does this work ? Surely the address mapping for one process is
    > completely independent of the address mapping for another process ?


    Yes. TLB entries have an additional tag field which is matched
    against an "address space ID" register. Switching address spaces
    is achieved by storing the new process's ID in that register.
    This way, TLB entries belonging to different address spaces
    can stay in the TLB at the same time.

    >
    > I know on MIPS you can use fixed TLB entries. But reducing the number of
    > available TLB entries for normal activities will increase the frequency
    > of TLB misses.


    MIPS also has a tagged TLB. It works exactly as described above.

    BTW, the "wired" TLB entries feature you are referring to is simply
    a matter of convention: whenever a new TLB entry needs to be stored
    following a TLB miss, the index of TLB entry to be kicked out is
    selected randomly by a "random" register. The contents of the "wired"
    register simply determines the lowest value the random register will
    ever assume, so setting it to a value N ensures that TLB entries
    0 ... N-1 will stay in the TLB forever. (IMHO, MIPS is a truly
    elegant design: achieving more with less....)

    Cheers

    Rob

    --
    Robert Kaiser email: rkaiser AT sysgo DOT com
    SYSGO AG http://www.elinos.com
    Klein-Winternheim / Germany http://www.sysgo.com

  12. Re: Access GPIO from user space

    Robert Kaiser wrote:

    >> I know on MIPS you can use fixed TLB entries. But reducing the number of
    >> available TLB entries for normal activities will increase the frequency
    >> of TLB misses.

    >
    > MIPS also has a tagged TLB. It works exactly as described above.


    I know about that. But the reason why using it is tricky is because the
    number of processes that the MMU can handle is much lower than the
    number of processes the OS can handle, isn't this correct ? (I can't
    remember, but I thought the process ID was only a 7-bit field or similar)

    > BTW, the "wired" TLB entries feature you are referring to is simply
    > a matter of convention: whenever a new TLB entry needs to be stored
    > following a TLB miss, the index of TLB entry to be kicked out is
    > selected randomly by a "random" register. The contents of the "wired"
    > register simply determines the lowest value the random register will
    > ever assume, so setting it to a value N ensures that TLB entries
    > 0 ... N-1 will stay in the TLB forever. (IMHO, MIPS is a truly
    > elegant design: achieving more with less....)


    Thanks for that, I wasn't sure exactly how it worked. Yes, I like the
    MIPS design It's the architecture I've worked with for most of my
    time, although these days it seems that PPC is much much more common.

  13. Re: Access GPIO from user space

    In article <1163372260.26964.0@despina.uk.clara.net>,
    "Geronimo W. Christ Esq" writes:
    > Robert Kaiser wrote:
    >
    >>> I know on MIPS you can use fixed TLB entries. But reducing the number of
    >>> available TLB entries for normal activities will increase the frequency
    >>> of TLB misses.

    >>
    >> MIPS also has a tagged TLB. It works exactly as described above.

    >
    > I know about that. But the reason why using it is tricky is because the
    > number of processes that the MMU can handle is much lower than the
    > number of processes the OS can handle, isn't this correct ? (I can't
    > remember, but I thought the process ID was only a 7-bit field or similar)


    I can't remember either, but I seem to recall that it was 7-bit on R3K
    and 8-bit on R4K. Anyway, yes, the range of ID values is generally
    smaller than the number of processes in e.g. Linux, so the OS can
    typically not use the process ID as address space ID (ASID) right away.
    Instead, it has to do some bookeeping so it can tell which process
    currently uses which of the 128 or 256 available ASIDs. If a new
    process arrives that needs a new ASID and all ASIDs are busy, the OS
    must choose a process (typically using an LRU strategy) to steal an
    ASID from (*That's* when you have to flush the TLB -- at least
    partially). But nevertheless, you can have up to 128/256
    different process's mappings in the TLB at the same time before
    this happens. Even on a busy Linux system, it rarely occurs that
    this many different processes are constantly being switched between.

    Cheers

    Rob

    --
    Robert Kaiser email: rkaiser AT sysgo DOT com
    SYSGO AG http://www.elinos.com
    Klein-Winternheim / Germany http://www.sysgo.com

+ Reply to Thread