On Wed, Mar 30 2011, Linus Torvalds wrote: > And most GPIO drivers I've ever seen are actually basically "turn this > bit on or off in this register to turn it into an Input or Output" > along with "read/write this other bit to actually see/set the value". > Repeat that for 'nr' bits, where 'nr' is just some small value, > usually in single digits. A few hundred is more typical. At least with the MSMs, it's even messier. The chip has a moderate number of pins, and a large number of peripherals, more than can actually be connected to these pins at a time. Multiple devices, and a general GPIO are frequently muxed. This has to be configured, in addition to input or output. Even for just GPIO, there may be multiple types of pullups, drive strengths. Different devices will need different configurations to handle low power, etc. Of the 145 files with 'gpio' in the name, 50 or so of them seem to actually be GPIO drivers. At least of the more common platforms, these are quite different, and seem to deal with fairly complex devices. Many at least use the gpiolib. The rest of the files seem to be more concerned with what the different GPIOs are connected to. This seems like the place to focus on generalizing. Maybe device tree. > Now, not all of them are that, by all means, and the details are often > slightly different. Sometimes the read register is the same as the > write register, sometimes it isn't. Sometimes you have a "clear > register" and a "set register" instead of a register you write the > value to. And I haven't checked what those 145 files do, but I bet a > _lot_ of them could be described by having a single generic gpio > driver, and then just using devicetree to give that common driver a > few values to describe where the IO ports are, which bits they are, > and which type of gpio it is. If we can come up with a general way to describe the diverse things a GPIO can be used for. Even something like drive strength can have widely differing possibilities, and may need different settings for low power modes (which means it can't just be the boot loader setting it). > And then when you have another ARM SoC, instead of writing yet another > mindless board driver for the gpio's on it, just add the <nr> entries > for the GPIO's to the device tree. NOT A SINGLE LINE OF CODE. Agree, at least in theory. > Yes, yes, there are always exceptions. Many GPIO's are actually behind > some i2c bus or something. Others can do pulsing or are just generally > more complex than an array of single bits. So I'm sure we couldn't > replace all those 145 gpio files under arch/arm with a single driver > and some devicetree entries, but maybe half of them match the simple > pattern. I bet the SoC case it's more than half, it would be silly to > do i2c on an SoC. But I dunno. I really didn't look. At least one MSM has GPIOs behind i2c. Too many pins, otherwise. > PowerPC does exactly the above, btw. So I'm not just talking about > some magical theoretical thing. I seriously think every ARM person who > has ever written any of those "gpio" files should look at powerpc. > Now, I suspect that most powerpc SoC's tend to share more IP blocks > than the crazy ARM situation, but even so, please just check it out. > Check out the device tree files (*.dts) and do that same > > git ls-files arch/arm/ | grep gpio > > except do it on powerpc. > > See the difference? Yeah, powerpc doesn't seem to have as complex of a use of gpios. David -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
