On Dec 3, 2005, at 9:14 PM, David Vescovi wrote:
Here's how I solved this problem in my Windows CE BSP. It probably does apply to the Linux world but may help if only for background info. I went through and indexed all the GPIO used by all the Gumstix peripherals. I did this by studying all the schematics and the PXA255 documentation (I wish the Gumstix people published this info). I have a master hardware configuration DWORD that I set and store persistently in flash from the bootloader. Each bit in the DWORD represents a different peripheral i.e. Audiostix, netCF, USB etc. All the GPIO's and their alternate functions get allocated and set shortly after powerup. The individual drivers gets initialized later but don't do the GPIO allocation. This has two advantages:
1) All the GPIO's are set in one central location as opposed to being spread across a whole bunch of drivers.
2) GPIO normally consumed by a peripheral which is not present (bit not set in hardware DWORD) are free to use for other things.
I see two big disadvantages though:
1. GPIOs all being set in one location instead of in individual drivers means that you can't just write a driver for a new device -- you also have to go update the central location to tag the GPIOs that you want to use.
2. There are more than 32 possible peripheral devices, with differing GPIO uses for each. Presumably, not only official-gumstix peripherals, but *any* peripheral ought to have a "bit" in the "DWORD" for some definition of "bit" and "dword".
The scheme I had envisaged is more along the lines of the linux resource manager. Essentially, there's a pool of GPIO line resources, which can be acquired from or released back to the pool by individual drivers as and when they need or no longer need the GPIO lines for write-access. Write-access includes setting GPIO alt mode, changing GPIO line direction, or changing GPIO line level -- I don't think separate resources are needed for each of these functions though; one lock for all writing is enough. However, anyone can read alt mode, line direction, or level at any time from any GPIO line.
Drivers are then responsible for only acquiring the resources when needed, and releasing them when no longer needed. A driver which tries to acquire a line already in use should fail to load and error out with some suitable message.
Hardware detection, I've been planning on moving into u-boot -- have it probe a couple things to see which cards might be present, then pass that info to linux via either bootargs, or through a kernel param block. I actually like the bootargs option slightly better, because it's then easier for userspace startup scripts to decide which modules to load after the main kernel boots.
PS David, I agree having a master-list of GPIO#s used by each card would be useful. The info is kind-of published, but not in the form of a big table; it's scattered across driver initiation code and schematics where the info is in symbolic names rather than just the GPIO numbers.