Messages in this thread | | | Date | Tue, 15 Feb 2011 23:55:18 +0000 | From | Mark Brown <> | Subject | Re: [PATCH 1/3] gpiolib: Add ability to get GPIO pin direction |
| |
On Mon, Feb 14, 2011 at 05:35:02PM -0600, Peter Tyser wrote:
> Also, in most cases I'd think that the BIOS/U-Boot/firmware should have > configured the GPIO pins appropriately, which Linux should inherit in > general. Linux currently inherits GPIO states that were set in firmware > when a GPIO is requested, but it doesn't properly report those values > via sysfs - that's the only bug I'm trying to fix.
That's one model for these things but it's *far* from universal. Another model which is at least as common is that the bootloader does the minimum possible to transfer control to Linux which then does the actual configuration for the system.
> Are there many cases where people need to swap a pin from GPIO to alt > functionality, and back again in Linux? I have never seen them used > like that; generally they are either wired up to an alt_func device (I2C > pins, serial pins, etc), or as a GPIO - not both dynamically. If some > hardware does need to do that, isn't it very chipset/board specific? I
No, it's very rare. One example we have in the kernel is the PXA27x AC'97 driver - the controller doesn't generate one of the resets correctly so the driver puts the signals into GPIO mode and manually generates the reset on the bus for the CODEC when it needs to do so.
> guess I'm just not really grasping the big advantage of the alt_func > feature, or how it'd be implemented as common code. It looks like there > was a thread about it back in 2009 that didn't go anywhere: > http://thread.gmane.org/gmane.linux.kernel/851818
I tend to agree; I strongly expect that any alternate function code would just wind up feeding at best device specific if not system specific constants through and give us no more generality than we have now.
| |