Access GPIO from user space

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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


Re: Access GPIO from user space

Quoted text here. Click to load it

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


Re: Access GPIO from user space

Quoted text here. Click to load it

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.


Re: Access GPIO from user space
Quoted text here. Click to load it

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


Thanks,
Dave

Re: Access GPIO from user space

Quoted text here. Click to load it

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.

Re: Access GPIO from user space
Quoted text here. Click to load it

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

Re: Access GPIO from user space
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Access GPIO from user space

Quoted text here. Click to load it

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.

Re: Access GPIO from user space
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Access GPIO from user space

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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.

Re: Access GPIO from user space
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.
Re: Access GPIO from user space
On Sat, 11 Nov 2006 18:29:22 +0000, "Geronimo W. Christ Esq"

Quoted text here. Click to load it

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


Re: Access GPIO from user space

Quoted text here. Click to load it

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 ?

Quoted text here. Click to load it

See above.

Site Timeline