Messages in this thread |  | | Date | Tue, 8 Apr 2008 12:44:46 +0200 (CEST) | From | Guennadi Liakhovetski <> | Subject | Re: gpio patches in mmotm |
| |
On Tue, 8 Apr 2008, Uwe Kleine-König wrote:
> arch/arm/mach-ns9xxx. It's not (yet) fully supported in vanilla, but it > includes support for different SOCs that have a different handling of > their GPIOs. E.g. the ns9360 has one gpio configuration register per 8 > gpios, the ns9215 has one per 4 gpios. Or another thing: ns9215 has > 108 gpios, ns9210 has only 54 where the first 50 gpios are identical to > the first 50 of ns9215, and the last 4 gpios are identical to gpios > 105-108 on ns9215. So gpio_is_valid for ns9xxx has to look like: > > int gpio_is_valid(int gpio) > { > ... > if (processor_is_ns9210()) > return gpio >= 0 && gpio < 108 && !(gpio >= 50 && gpio < 105); > ... > } > > (In my eyes that hole is ugly, but with it can calculate the address of > the configuration register without case splitting and can handle ns9215 > and ns9210 identically---apart from the is-valid check.)
Ok, I thought it would be something like that. I think, these are two different things: GPIO valid and GPIO currently physically existing. gpio_is_valid() is a test whether the number being tested at all stands a chance to be a GPIO number on this architecture. As you see in include/asm-generic/gpio.h it only compares against ARCH_NR_GPIOS, which is just the theoretically highest GPIO number. It says nothing about whether or not all valid GPIOs are actually present on the system. Think about GPIO expanders, there might or might not be one currently available on the system. Still gpio_is_valid() will return the same result for any given number. PXA CPUs have the same "feature" as ns9xxx - different models have differeng GPIOs, and platform add their own GPIO controllers, which are often placed at a fixed start number, which means, on some CPUs there will be holes too. And gpio_is_valid is not (and should not be) checking for those - this is already the task for request_gpio().
> So you reason that the alternative approach allows only a slight > simplification and so is not worth considering? But obviously > yes, I have a different opinion. :-)
No, my reason is that I didn't want to put "intimate knowledge" of GPIO interna, like "-1 is not a valid GPIO" in the driver but use an abstraction instead. My original proposal was to introduce just one NO_GPIO macro to test against, however, David nicely managed to persuade me, that the gpio_is_valid approach is better. Unfortunately, I cannot argument as nicely as he did, maybe looking through his emails in LKML archives will help you:-)
Thanks Guennadi --- Guennadi Liakhovetski -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |