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?