Posted Nov 24, 2011 14:04 UTC (Thu) by dougg (subscriber, #1894)
Parent article: The pin control subsystem
PARALLEL Input Output controller (PIO) is what Atmel call the silicon subsystem in their AT91 family of SOCs that control gpio lines. I'm familiar with the AT91SAM9G20 and the G20 has 3 controllers while the G45 has 5 of them. Each is 32 bits wide (so the G20 has 3*32=96 GPIO lines).
Now the kernel's existing approach based on gpiolib is a sick joke, as it is based on abstracting all the complexity (explained in your article) out of the gpio architecture, so what is left is lame.
So the bit I wanted to stress in this post is that gpio lines in the same controller bank (i.e. 32 lines) can be used as a parallel bus. In the hardware I use PC16-PC31 are used as the top 16 bits of the data bus. Now not many users should be fiddling with the data bus but there are other uses of the parallel nature of some gpio lines. A step too far for a pin control system?
If so then mmap() is your friend. As the SCSI storage subsystem has taught me: the kernel isn't necessarily the way, it often is in the way.
Posted Nov 24, 2011 14:43 UTC (Thu) by linusw (subscriber, #40300)
[Link]
So the bit I wanted to stress in this post is that gpio lines in the same controller bank (i.e. 32 lines) can be used as a parallel bus. In the hardware I use PC16-PC31 are used as the top 16 bits of the data bus. Now not many users should be fiddling with the data bus but there are other uses of the parallel nature of some gpio lines.
Actually pin control is partitioned apart from users of the pins, say GPIO or I2C or SPI, it just does pin control. As for gpiolib, it's designed to only handle single-bit GPIOs. I think a new MMIO-port abstraction is needed to handle a register range as a memory-mapped parallel port of some kind, if one does not already exist, I haven't seen one.
Parallel Input Output Controller (PIO)
Posted Dec 1, 2011 13:06 UTC (Thu) by jpfrancois (subscriber, #65948)
[Link]
I think you are making a confusion here, between the gpiolib framework which control gpio pin, and pin multiplexing.
Having a common pin multiplexing scheme doesn't mean all your pin will be declared as GPIO.
Now, regarding your GPIO, the gpiolib code is not pefect, but I think there was an attempt to do gpio gouping, so that they can act as a parallel bus.
In many cases, the gpiolib is a clear win, and when using SoC from different vendor, playing with individual gpio is now the same, wether you are playing with an atmel or a texas chip. I don't miss old days when you add to figure out what code to use to move a particular gpio.