Closed
Conversation
Labgrid's existing GPIO implementation relies on the deprecated sysfs interface. Modern descriptor-based GPIO handling (via character devices) requires a process to maintain an active line request to keep the GPIO state stable. With libgpiod v2.x, the tools can now hold a GPIO state via a persistent DBUS implementation. By registering a "consumer", the GPIO remains claimed by the utility, shifting the daemon/persistence handling from Labgrid to the underlying GPIO tools. This allows Labgrid to support modern GPIO descriptors while maintaining its current architecture. This implementation runs in parallel to the existing sysfs support to ensure backward compatibility. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Adds description and documentation of GpiodGPIO and GpiodDigitalOutputDriver. The approach implements descriptor based GPIO handling aside of Sysfs based GPIO handling. In this way both won't interfere. Compatibility with the sysfs appraoch is there, and on platforms which are switching more and more towards modern descriptor based GPIO handling will be enabled. Starting with v2.0 the DBUS hold GPIO implementation of the GPIO tools is around. So the easiest approach is to rely on the GPIO utils process to be named as "labgrid_<offset>" and hold the IO line in a stable state. Also since python's GPIO libs do not implement directly means of holding the IO line stable. In case of labgrid where an agent / wrapper only is used for activation / deactivation an internal python implementation might require quite som arquitectural impact, basically for setting up a process as daemon. GPIO utils are external processes performing exactly the same, cross dependency is low and impact for labgrid is reasonable. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Add a pre-initialization for gpiod based gpios implementing DigitalOutputProtocol. By specifying the optional property `initval: bool` in the Place config of the client to the GpiodDigitalOutputDriver configuration, the GPIO line will be set accordingly at acquiring the place. This is supposed to help in situations where a pre-initialization is crucial to avoid damage or is simply convenient. This property is optional. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Document preinitialization argument "initval" for descriptor based GPIO handling. Signed-off-by: Lothar Rubusch <l.rubusch@gmail.com>
Member
|
gpiod is not the correct approach for labgrid, see #1715 (comment) and #1818 (comment). A PR implementing support for the new chip-based sysfs API would be more useful than another PR for gpiod support. :) It would need Resources, as the current SysfsGPIO only uses an |
Author
|
Thank you for the feedback and clarification. For the SysfsGPIO(chip+offset) thing, are you aware of currently active development on this topic? Another part of my commits was, for (my rather) simple and static case, I'd like to see something like a pre-initialization of GPIOs at acquire. Would such thing might have a chance to go upstream? Or, could you just briefly outline why definitely not? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add descriptor based GPIO support.
To be honest I did not exactly follow the discussion, but I'm pretty sure there is one. I'm probably not the first one asking for descriptor based GPIO handling (and probably this won't be the last patch set on it, to be honest).
I had several solutions in the past where the GPIO needed to be actively hold. At work, I implemented holding their state using systemd jobs and gpiod tools with the wait option for v1.x of the lib. With libgpiod v2.x around, Bartosz implemented some DBUS server solution, AFAIK. The tools changed a bit and since then, one can hold them in daemon mode with a registered "customer" tag. I tried implementing direct control using the python3 gpiod library, but unfortunately this would require an active daemon holding state. As I understand labgrid, an agent callling to activate/deactivate GPIO lines is a pretty stateless implementation (which I appreciate). I did not wanted to introduce a daemon implementation holding and owning the GPIO. I'm mainly here on RPi hardware for the Exporters, but also did not want to rely only on RPi libs.
The solution now - the perhaps ugly part of this series - I implemented holding GPIOs using the gpiod utils and registering "labgrid_" as customer. I capture the PID and signal the process at state transition. It allows this only for the owner of the process, which means if the GPIO was held by another process labgrid will complain already at claiming the GPIO initialy, which is good IMHO. To be honest I was not happy with any other approach I tried, and this is the one I ended up using since. It worked out pretty stable for us.
For compatibility I implemented it aside Sysfsgpio. Therefore pretty every class around for something with Sysfsgpio, is added with a brother for Gpiodgpio. One exception is MatchedGpios which I do not use, therefore did not test, therefore did not add to the implementation (I guess just few additional lines of code).
A second part of the patches is pre-initialization. I'm doing boot mode and boot media switching on some soldered IO lines. When powering the device in some cases this has to be in defined state, so I added a kind of optional pre-initialization support. The idea is, you can on the client side configure initially value, high or low. When acquiring the Place it will set the GPIOs accordingly.
If you think this could be somehow useful feel free to take it, or drop it or discuss it for further upstreaming.