[PATCH v2] arm: gpio: Add set_flags callback to the Tegra gpio driver

[Svyatoslav Ryhel]

пн, 29 вер. 2025 р. о 10:23 Łukasz Majewski <lukma at nabladev.com> пише:
>
> Hi Svyatoslav,
>
> > пн, 22 вер. 2025 р. о 17:16 Lukasz Majewski <lukma at nabladev.com> пише:
> > >
> > > This patch adds support for the .set_flags callback.
> > > For now following flags are supported:
> > > - GPIOD_IS_AF (i.e. "alternate function").
> > > - GPIOD_IS_IN
> > > - GPIOD_IS_OUT
> > >
> > > Currently, the .set_flags in gpio-uclass.c (function
> > > dm_gpio_set_value()) is used before .set_value callback, so
> > > functionally replaces it. As a result the corresponding
> > > tegra_gpio_set_value() can be removed.
> > >
> > > Signed-off-by: Lukasz Majewski <lukma at nabladev.com>
> > > ---
> > >
> > > Changes for v2:
> > > - Fix the format specifier for flags in debug() function
> > > - Update commit message
> > > - Remove tegra_gpio_set_value() method (as it is functionally
> > > replaced by set_value()
> > > - Prevent from returning errors when flags = 0 (problem with e.g.
> > > I2C GPIO support)
> > > ---
> > >  drivers/gpio/tegra_gpio.c | 39
> > > +++++++++++++++++++++++---------------- 1 file changed, 23
> > > insertions(+), 16 deletions(-)
> >
> > Lukasz, thank you for this change I would really like to see it in
> > mainline. ATM I have no capabilities to debug
>
> You mean test if it works?
>
> > this and I will return
> > to it but that may not be soon unfortunately.
>
> This is a bit problematic for me, as:
>
> 1. Some future work depends on it (more details below).
> 2. The "set_flags()" callback seems like being now the one to be
> advised to being implemented and used.
>
>
>
> Can you predict when you will be able to come back to this task? Is
> this the matter of weeks or months?
>

Weeks maybe, I will try to look into this when I have some spare time

> > In case you really need
> > switch GPIO back to SFIO and Linux cannot handle this, you an use
> > dm_gpio_free to release gpios in board_preboot_os in the board as a
> > temporary measure.
>
> Yes, this is a temporary solution - i.e. dm_gpio_free() is supposed to
> "free" the pin. IMHO, the set_flags() shall be used, as I in fact do
> want to set the CFG_SFIO flag, not release the gpio.
>

dm_gpio_free in tegra case calls CFG_SFIO

> >
> > Overall issue you are describing is not u-boot's it is kernels, kernel
> > must reconfigure gpios for proper work regardless of their previous
> > state. If it is not the case, then kernel device configuration is
> > incomplete or wrong.
>
> This is how the pinmux in Linux for Tegra is written. You can setup the
> PAD parameters, but you cannot set the pin's function.
>

WDYM? Tegra30+ has per-pin configuration, this includes FUNCTION,
direction, tristate and pull for all pins

> In other words - you have to do it in bootloader (u-boot in this case).
>
> In my case - customer uses the pin in u-boot as GPIO to check carrier
> board version, then the same pin in Linux is going to be used as
> special function one.
>
> Unfortunately, above "reconfiguration" cannot be done in Linux.
>
> As other "rework" of gpio code depends on it (use dm) - I would like to
> postpone my work until this functionality is available in mainline (and
> hence avoid "temporal solutions").
>
> --
> Best regards,
>
> Lukasz Majewski
>
> --
> Nabla Software Engineering GmbH
> HRB 40522 Augsburg
> Phone: +49 821 45592596
> E-Mail: office at nabladev.com
> Geschftsfhrer : Stefano Babic