Re: [PATCH] Debobs and ETK padconf implementation

[Kevin Hilman <khilman@deeprootsystems.com>]

David Brownell wrote:
> On Thursday 25 September 2008, Kevin Hilman wrote:
>>>> In that case, what is the proposed method for other kernel code to use
>>>> the debobs lines?
>>> Hmm, good point :) My idea was to use the gpiolib calls on GPIO12 -
>>> GPIO29, but then there is no way for a user to know if the GPIO was
>>> assigned to debobs or not... Maybe debobs should register as gpiolib
>>> 'chip' and reexport those lines ? Would that make sense ?
 >>
>> I think debobs should simply 'gpio_export' each pin.  It does not need
>> to hold them.
> 
> Peter said the right abstraction here was pads (pins/balls?) not
> GPIOs, so I'm not sure this is relevant any more, but ...
> 
> You can't gpio_export() to userspace, via sysfs, without having
> first done a gpio_request().  And then later a gpio_free() will
> release that export.  So that won't work.

Thanks Dave, I was kind of hoping you would chime in on this one :)

OK, then I guess Peter's idea of a gpio_chip type abstraction makes more 
sense.

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.  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...

Kevin