Hi,

According to stm32f412zg datasheet, usart2_pin_c is actually supported on stm32f412zg, so I don't see issue to populate it in stm32f4-pinctrl.dtsi.
Besides, as mentioned by Andy, it's not a problem to be defined in a generic file.
Though you need to take care to enable only what is supported by your board in you project.

This being said, I know we didn't address yet the problem of different packages of a same SoC (64, 100, 144 pins).
In this case it is possible we'll have pins defined for a soc not supported on the smallest package of this SoC.
This does not trigger issues since what matters is the configurations you actually define on your board/project,
but maybe we could split -pinctrl files in -64.dsti, -100.dsti, -144.dtsi files to have a fully clean dts description.
We'll see if this is required.

Erwan


On 9 August 2017 at 19:14, Andy Gross <andy.gross@... <mailto:andy.gross@...>> wrote:

On 9 August 2017 at 11:01, massimiliano cialdi
<massimiliano.cialdi@...
<mailto:massimiliano.cialdi@...>> wrote:
> Fo the nucleo_f412zg there is the file
>
> zephyr/dts/arm/nucleo_f412zg.dts
>
> that includes st/stm32f412.dtsi and then
> #include <st/stm32f412-pinctrl.dtsi>
> #include <st/stm32f411.dtsi>
>
> stm32f411.dtsi indirectly includes stm32f4-pinctrl.dtsi
>
> file stm32f4-pinctrl.dtsi contains
>
> usart2_pins_a: usart2@0 {
> rx_tx {
> rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUPDR_NO_PULL)>;
> tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUSHPULL_NOPULL)>;
> };
> };
> usart2_pins_b: usart2@1 {
> rx_tx {
> rx = <STM32_PIN_PA15 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUPDR_NO_PULL)>;
> tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUSHPULL_NOPULL)>;
> };
> };
> usart2_pins_c: usart2@2 {
> rx_tx {
> rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUPDR_NO_PULL)>;
> tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUSHPULL_NOPULL)>;
> };
> };
>
> and if I want to use USART2 I have to add to stm32f412-pinctrl.dtsi
>
> usart2_pins_a: usart2@0 {
> rx_tx {
> rx = <STM32_PIN_PA3 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUSHPULL_PULLUP)>;
> tx = <STM32_PIN_PA2 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUSHPULL_PULLUP)>;
> };
> };
> usart2_pins_b: usart2@1 {
> rx_tx {
> rx = <STM32_PIN_PD6 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUSHPULL_PULLUP)>;
> tx = <STM32_PIN_PD5 (STM32_PINMUX_ALT_FUNC_7 |
STM32_PUSHPULL_PULLUP)>;
> };
> };
>
> because chip has only those two mux for USART2.
>
> In the compiled dts there is also usart2_pins_c that it doen't
actually
> exist in the chip, how to remove it?

So if there are pin differences between the two, then anything non
generic needs to be removed from the .dtsi and put inside a more
specific .dtsi file that is included. The intent of the definitions
was to allow reuse and make it easier to choose things without having
to consult the manual.

The pins_c should only be appearing if it is defined and someone
is using it.

>
> the file stm32f4-pinctrl.dtsi should be generic for stm32f4
family chips. So
> why it contains a specific multiplexing for the usart that has to be
> overridden by specific pinmux files?

If the f412 has differences in pinmuxing from the f4, then those
things needs to be separated out. The entries in the -pinctrl.dtsi
are used in the actual nodes in the board specific files. Just
because something is defined does not mean that it is used unless
there is a pinctrl-0/pinctrl-1/pinctrl-2 property in the node that
uses one of the definitions.
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
<mailto:Zephyr-devel@...>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
<https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>