Thread (4 messages) 4 messages, 2 authors, 2014-02-06

Re: [RFC 1/2] gpio: make the GPIOs shareable

From: Alexandre Courbot <hidden>
Date: 2014-02-06 13:27:41

On Thu, Feb 6, 2014 at 10:23 PM, Alexandre Courbot [off-list ref] wrote:
quoted
There's another feature that I didn't post because its use case is probably
not very common. I wanted to be able to share output gpios. My use case is
the gpio tracing mechanism I posted a few weeks ago.
Yes, I remember that patch.
quoted
To reduce the complexity of tracking the gpio used by the probes, I thought
that maybe this task could be delegated to the gpiolib. Implementation could
be very straightforward there:
* in gpiod_request (or equivalent) pass an ownership tag (NULL would be a
special default value)
* in the case were the ouput is already owned, check if the ownership tag
are the same and not NULL. If so the request succeeds otherwise it fails.
So the two drivers would need to communicate that ownership tag so the
second can "hijack" the GPIO with permission from the first? You could
also pass a handle directly, like PRIME does for buffers (then we
could plug kdbus in and have user processes exchange GPIO handles
securely. Now I'm scared).

I would be even more cautious about sharing output GPIOs. If possible
at all, I'd really prefer to see a scheme where the two consuming
drivers yield the GPIO when they don't need it. After all, if you
enter a situation where both drivers want to drive the GPIO output,
you are obviously going to have a problem.
To elaborate on my thoughts, wouldn't be possible for you to have a
custom DT with the "hijacked" GPIO unmapped from its initial function
and reassigned to the node that represents your probe? I mean, if you
install such a probe you will need to twiddle the hardware anyway, so
while you are at it can't you also represent that change in the DT?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help