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