пн, 29 вер. 2025 р. о 10:23 Łukasz Majewski <[email protected]> пише: > > Hi Svyatoslav, > > > пн, 22 вер. 2025 р. о 17:16 Lukasz Majewski <[email protected]> пише: > > > > > > 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 <[email protected]> > > > --- > > > > > > 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: [email protected] > Geschftsfhrer : Stefano Babic
