Re: [PATCH] Debobs and ETK padconf implementation

[David Brownell <david-b@pacbell.net>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html