Hi Simon On 09/26/2018 07:41 AM, Simon Glass wrote: > Hi Patrice, > > On 20 September 2018 at 07:37, Patrice Chotard <patrice.chot...@st.com> wrote: >> pinmux_show allows to display the muxing of all pins >> belonging to pin-controller. >> >> Signed-off-by: Patrice Chotard <patrice.chot...@st.com> >> --- >> >> drivers/pinctrl/pinctrl_stm32.c | 79 >> +++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 79 insertions(+) >> > > The only thing I don't like about this is that it is quite > SoC-specific. I am hoping we can make it more generic.
I will rework it to make it more independant. > >> diff --git a/drivers/pinctrl/pinctrl_stm32.c >> b/drivers/pinctrl/pinctrl_stm32.c >> index 31285cdd5784..a477035bf420 100644 >> --- a/drivers/pinctrl/pinctrl_stm32.c >> +++ b/drivers/pinctrl/pinctrl_stm32.c >> @@ -14,6 +14,16 @@ DECLARE_GLOBAL_DATA_PTR; >> #define OTYPE_MSK 1 >> #define AFR_MASK 0xF >> >> +#define PINMUX_MODE_COUNT 5 >> + >> +static const char * const pinmux_mode[PINMUX_MODE_COUNT] = { >> + "gpio input", >> + "gpio output", >> + "analog", >> + "unknown", >> + "alt function", >> +}; >> + >> static int stm32_gpio_config(struct gpio_desc *desc, >> const struct stm32_gpio_ctl *ctl) >> { >> @@ -176,12 +186,81 @@ static int stm32_pinctrl_set_state_simple(struct >> udevice *dev, >> } >> #endif /* PINCTRL_FULL */ >> >> +static int stm32_pinctrl_get_af(struct udevice *dev, unsigned int offset) >> +{ >> + struct stm32_gpio_priv *priv = dev_get_priv(dev); >> + struct stm32_gpio_regs *regs = priv->regs; >> + u32 af; >> + u32 alt_shift = (offset % 8) * 4; >> + u32 alt_index = offset / 8; >> + >> + af = (readl(®s->afr[alt_index]) & >> + GENMASK(alt_shift + 3, alt_shift)) >> alt_shift; >> + >> + return af; >> +} >> + >> +static int stm32_pinmux_show(struct udevice *dev) >> +{ >> + struct udevice *child; >> + struct udevice *dev_gpio; >> + const char *bank_name; >> + const char *label; >> + int offset; >> + int ret; >> + int num_bits; >> + int mode; >> + int af_num; >> + >> + /* parse pin-controller sub-nodes, ie gpio bank nodes */ >> + list_for_each_entry(child, &dev->child_head, sibling_node) { >> + ret = uclass_get_device_by_name(UCLASS_GPIO, child->name, >> + &dev_gpio); > > I wonder to what extend this is actually different from 'gpio status'? I agree, currently, "pinmux show" and "gpio status" comments are overlapping.. At the end, as on kernel side, only pinmux should be used to know the pin state (configured as a GPIO or as alternate function). pinmux command indicates if pins is configured as an alternate function and indicates which one, what "gpio status" can't do. > >> + >> + if (ret < 0 && ret != -ENODEV) { >> + dev_err(dev, "Failed to find %s device ret = %d\n", >> + child->name, ret); >> + return ret; >> + } >> + >> + if (!ret) { >> + bank_name = gpio_get_bank_info(dev_gpio, &num_bits); >> + >> + printf("\nBank %s:\n", bank_name); >> + for (offset = 0; offset < num_bits; offset++) { >> + mode = gpio_get_raw_function(dev_gpio, >> + offset, &label); >> + printf("%s%d: %s", bank_name, offset, >> + pinmux_mode[mode]); >> + switch (mode) { >> + case GPIOF_FUNC: >> + af_num = >> stm32_pinctrl_get_af(dev_gpio, >> + >> offset); >> + printf(" %d", af_num); >> + break; >> + case STM32_GPIO_MODE_OUT: > > How come you cannot use GPIOF_OUTPUT here? Good catch, GPIOF_OUPUT/INPUT must be used instead of STM32_GPIO_MODE_OUT/IN. > >> + case STM32_GPIO_MODE_IN: >> + printf(" %s", label ? label : ""); >> + break; >> + } >> + printf("\n"); >> + } >> + } >> + >> + if (!child) >> + break; >> + } >> + >> + return 0; >> +} >> + >> static struct pinctrl_ops stm32_pinctrl_ops = { >> #if CONFIG_IS_ENABLED(PINCTRL_FULL) >> .set_state = stm32_pinctrl_set_state, >> #else /* PINCTRL_FULL */ >> .set_state_simple = stm32_pinctrl_set_state_simple, >> #endif /* PINCTRL_FULL */ >> + .pinmux_show = stm32_pinmux_show, >> }; >> >> static const struct udevice_id stm32_pinctrl_ids[] = { >> -- >> 1.9.1 >> > > Regards, > Simon > _______________________________________________ > Uboot-stm32 mailing list > uboot-st...@st-md-mailman.stormreply.com > https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot