Iot: LibGpiod: Input Pull Down / Pull Up Support

[BWalti]

The LibGpiodDriver currently only supports "PinMode.Input" as input variant. InputPullDown and InputPullUp are not supported: https://github.com/dotnet/iot/blob/733296b63311104122b49bf1e2c247c7bd690391/src/System.Device.Gpio/System/Device/Gpio/Drivers/LibGpiodDriver.Linux.cs#L100-L104

Wouldn't it be possible to use the corresponding flags and pass them through?

Offending code:
https://github.com/dotnet/iot/blob/733296b63311104122b49bf1e2c247c7bd690391/src/Native/System.Device.Gpio.Native/libgpiod.c#L53-L56

A test in another library showing, that it could be possible:
https://github.com/brgl/libgpiod/blob/2e2ca25d49c2e1b263009ae8f970871dd45af369/tests/tests-line.c#L472-L473
?

EDIT: as @buyaa-n pointed out, the above referenced code was not about pulling up / down. But there is a corresponding ticket indeed: brgl/libgpiod#31. END EDIT

I had to switch back to Windows 10 IoT as there PullDown is supported (active high). Otherwise I would have to do some soldering :)

PS: I guess the original library now lies in git.kernel.org:
https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/include/gpiod.h?h=v1.2.x#n870

[shaggygi]

I think there are other checks that would also need to be changed if/when #135 is added, as well.

[BWalti]

I'm not an expert on that field, but in my understanding #135 is about output lines?
Maybe I'm wrong, but I guessed that passing the flag would cause the internal resistors to be correctly applied. I would not expect other side effects. But I'm probably naive :)

[shaggygi]

No, you are correct. My point is more about we will need to check for the different types of inputs and outputs. This includes for both dev boards and device bindings that implement GpioController (e.g. Mcp23xxxx, etc.).

[BWalti]

I did not think about other boards. My bad! I guess not all boards/chips with libgpiod support have PullUp / PullDown internal resistors?
I see, maybe its bigger to cleanly solve than I first thought..

[shaggygi]

Yeah, there are probably some devices that don't support input pull up/down, just as there are some that don't support open-drain outputs. I'd keep this issue open so a discussion can occur on how to approach this since there we'll eventually need to be checks/logic added to core API and possibly an update to doc somewhere for a checklist on related type of devices (when creating new ones).

Thanks

[joperezr]

cc @buyaa-n since she looked into the Libgpiod implementation.

My point is more about we will need to check for the different types of inputs and outputs. This includes for both dev boards and device bindings that implement GpioController (e.g. Mcp23xxxx, etc.).

I'm not sure how that would be applicable here though. I though this question was very specifically to the Libgpiod Driver, which is different than a IGpioController. If Libgpio driver should support these Input modes, then I agree that this should be done.

[shaggygi]

@joperezr yeah, you’re right. I guess I was thinking more in general. Although, I’m not sure if it would need to change based on the different board the driver was running. I haven’t looked at the specifics to that level yet.

[buyaa-n]

@BWalti seems the test you are referencing is for testing is ACTIVE_LOW is set not pull up/down. I have checked if pull up/down mode is available in libgpiod before but it was not, but seems the author is going to add that mode, there is an issue for tracking https://github.com/brgl/libgpiod/issues/31. For now seems it still not done.

[joperezr]

Although, I’m not sure if it would need to change based on the different board the driver was running. I haven’t looked at the specifics to that level yet.

That is a very good point, as the LibGpiod driver is supposed to be able to run in multiple boards, not just the Pi. That said, if Libgpiod library supports these modes, I imagine that they should be able to handle specific cases where the board doesn't natively support those pin modes. @buyaa-n thanks for investigating, once this mode is activated, we should definitely activate it in our driver as well. We can leave this issue open to tract that work being added in the future once libgpiod supports it.

[BWalti]

@buyaa-n I updated the original post to keep it easier for new readers. Thanks for investigating and pointing it out!