[question] Does gpiod_set_value have a "guarantee"?

[question] Does gpiod_set_value have a "guarantee"?

[Vincent Fazio]

Is there any implicit or expected guarantee that after having returned from
gpiod_set_value that the GPIO will reflect the new value externally?

Some drivers that leverage GPIO to emulate buses, like i2c-gpio, may be relying
on this to be true in order to make a "stable" clock.

I was glancing at https://github.com/raspberrypi/linux/issues/5554 where
someone ran into an issue and it looks like, at least on the RPi 4 platform,
that there may need to be some "flush" mechanism to guarantee that a GPIO has
been written out.

If it's the responsibility of gpio_chip->set to do this, then I'm guessing the
pinctrl driver may need to be updated, but that does incur a performance hit
for every GPIO write.

If it's up to the bus emulator to do this, short of sampling the pin, should
there be some API or mechanism to assist with flushing writes out? Is there
already a mechanism to do this?

Thanks,
-Vincent

Re: [question] Does gpiod_set_value have a "guarantee"?

[Bartosz Golaszewski]

On Mon, Mar 18, 2024 at 6:13 PM Vincent Fazio <vfazio@gmail.com> wrote:
>
> Is there any implicit or expected guarantee that after having returned from
> gpiod_set_value that the GPIO will reflect the new value externally?
>

No, this is driver-specific behavior.

> Some drivers that leverage GPIO to emulate buses, like i2c-gpio, may be relying
> on this to be true in order to make a "stable" clock.
>

Well, they shouldn't rely on it because it's not enforced unless the
underlying driver enforces it.

> I was glancing at https://github.com/raspberrypi/linux/issues/5554 where
> someone ran into an issue and it looks like, at least on the RPi 4 platform,
> that there may need to be some "flush" mechanism to guarantee that a GPIO has
> been written out.
>
> If it's the responsibility of gpio_chip->set to do this, then I'm guessing the
> pinctrl driver may need to be updated, but that does incur a performance hit
> for every GPIO write.
>
> If it's up to the bus emulator to do this, short of sampling the pin, should
> there be some API or mechanism to assist with flushing writes out? Is there
> already a mechanism to do this?
>

That's an interesting use case. We could extend both the in-kernel and
user-space API for this quite easily. We could add a new flag to
gpiod_get() like GPIOD_SYNC or similar and maybe provide a callback
for GPIO drivers for flushing the state? Then do the same with
user-space request flags.

In any case, I don't think we can make it entirely generic.

Bart