On Thu, Feb 6, 2014 at 10:23 PM, Alexandre Courbot <[email protected]> wrote: >> 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. > >> 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? -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
