Access GPIO from user space

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

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

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

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

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

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.

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 ?

See above.

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.

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

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)

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.

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