v1.6: Change requested line direction without releasing & reacquiring the line

[KWolfe81]

A recent change in linux kernel from 6.8 to 6.9 makes releasing a gpio fd take a consequential amount of time (depending on what core your app vs. your kernel is using). I need to switch a pin's direction rapidly, which was traditionally done by releasing and requesting the line again - however this now taking way too long.

Following up on this stackoverflow post, there is hopefully another way to do this in newer kernel revisions. Can you provide any guidance on how to proceed?

[KWolfe81]

@brgl Looks like your kernel commit 1f2bcb8 is what causes the additional delay (milliseconds vs. microseconds). Specifically, reverting desc_set_label() back resolves the issue for me.

Context: openocd uses gpiod to bitbang swdio configurations over a pin.

[brgl]

This may be possible (SRCU write synchronization is known to be slower that spinlocks or mutexes) although running the libgpiod test-suite takes the same time between v6.8 and v6.9-rc5 (if anything, the latter is even slightly faster). My concern is that you're probably using the API wrong if you need to request/release GPIO lines in quick succession.

Changing the direction without releasing the line has been possible for over a year with libgpiod v2. Could you consider switching to the new version? Please take a look at gpiod_line_request_reconfigure().

[mhei]

FYI: there is ongoing work for openocd to switch to libgpiod v2.x, it would be great if you could test this latest branch: https://github.com/mhei/openocd/tree/linuxgpiodv2-emulate-v2-for-v1

[KWolfe81]

@brgl I'll try to those test suites on my hardware and see the #s. Can you confirm those test multicore systems? (If I pin the user worker thread to the same core as the kernel, problems go away).

@mhei Oh, nice. I tested and it unfortunately exits out without error or completion. I don't want to turn the thread into an openocd ticket, but the program out put is below. I'll dig in more on Monday and possibly follow up through another channel.

Attempting flash preverify and program...
openocd -f openocd.cfg -c init; nrf52_recover; program contr_dongle_poc_merged.hex verify reset exit
Open On-Chip Debugger 0.12.0+dev-g64fb747da (2024-04-27-06:37)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : Linux GPIOD JTAG/SWD bitbang driver
Info : Note: The adapter "linuxgpiod" doesn't support configurable speed
root@dut621:~/contr#

[mhei]

I'm no openocd expert, or maybe it's just a copy & paste mistake here, but maybe you forget to put the command sequence in quotes, e.g. openocd -f openocd.cfg -c "init; nrf52_recover; program contr_dongle_poc_merged.hex verify reset exit"
Beside this, since I have only a limited test environment for my branch, I'd really appreciate working with you to get the change into good shape. So just private mail me, if you could help out here.

[brgl]

@brgl I'll try to those test suites on my hardware and see the #s. Can you confirm those test multicore systems? (If I pin the user worker thread to the same core as the kernel, problems go away).

Yes, the test suite is running on a multicore system but the tests themselves are single-threaded. Do you use pthread_setaffinity_np()? I'm on vacation this week but when I'm back I'll contact the linux kernel SRCU maintainer about it.

[brgl]

This was fixed with commit a86d27693066 gpiolib: fix the speed of descriptor label setting with SRCU in the kernel.