On Thursday 25 September 2008, Kevin Hilman wrote: > But I'm still not sure how to best deal with the possibiltity that the > pin might not always be a GPIO, but might be reconfigured/re-mux'd by > this debobs interface as a debug observability pin. Some platforms have interfaces to reserve and unreserve pins. Normally used to ensure drivers can't do things like remux address bus pins, but I suppose it could also be used for this sort of thing too. > My initial thought > was to have the debobs interface gpio_request() the line if it was in > observability mode so that nobody else could use it as a GPIO line, then > gpio_free() it when it was put back into GPIO mode thus making it > available to other users as a GPIO. While that may work, it seems > counter-intuitive and rather kludgy. Not sure what the best way is.. GPIOs are all that get managed with GPIO calls. The pinmux calls use enums for pins, which could be used as identifiers with some reservation scheme that copes with other non-GPIO usages. The worst case, design wise, is OMAP1 chips where many GPIOs can come out on several pins ... and conversely, many pins could be connected to any of several GPIOs (or MPUIOs). - Dave -- 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
