Zephyr: pinmux: stm32: port remaining pinctrl DT serial definitions for STM32 based boards

Created on 5 Oct 2020  路  11Comments  路  Source: zephyrproject-rtos/zephyr

Is your enhancement proposal related to a problem? Please describe.
The new pinmux configuration method introduced in #25996 means all of the STM32 based boards need to be updated to the new method.

For this we need to remove the USART/LPUART/UART definitions from pinmux.c file and add the corresponding pinctrl nodes to the boards' device tree.

Describe the solution you'd like
An ideal solution would be a script that executes the change automatically. Else we'll have to do it by and.
Difficult parts are to identify the correct pinctrl dtsi to use and then extracting the pin configuration from current pinmux.c.

Describe alternatives you've considered
For now, I have made a script that identifies every stm32 based boards and if it has defined pinmux for lpuart/uart/usart DT nodes. In which case, we'll need to update them manually.

Here is the script:

#!/bin/bash

pinmuxes=`find boards/arm/ -name "pinmux.c"`

#use Perl regex here to match with grep
#match for specific STM32 pinmux header, only used
#with ST based boards
match_stm32_pinmux="pinmux/stm32/pinmux_stm32.h"
match_peripheral_mux="(lp)*u(s)*art\d+"

for pinmux in $pinmuxes; do

    is_stm32_pinmux=`cat $pinmux | grep -cP $match_stm32_pinmux`
    if [ $is_stm32_pinmux -eq 0 ]
    then
        continue
    fi

    periph_mux_count=`cat $pinmux | grep -cP $match_peripheral_mux`
    periph_matches=`cat $pinmux | grep -oP $match_peripheral_mux`
    if [ $periph_mux_count -ne 0 ]
    then
        board=`dirname $pinmux`
        echo $board : $periph_matches
    fi
done

To this date, here are the boards that still need to upgrade to the new paradigm:

* boards/arm/nucleo_f302r8 : usart1 usart2 usart3
* boards/arm/nucleo_l552ze_q : lpuart1
* boards/arm/stm32f746g_disco : usart1 usart6
* boards/arm/stm32f723e_disco : usart2 usart6
* boards/arm/nucleo_f756zg : usart2 usart3 usart6
* boards/arm/nucleo_f334r8 : usart1 usart2 usart3
* boards/arm/black_f407zg_pro : usart1 usart2
* boards/arm/nucleo_f091rc : usart1 usart2
* boards/arm/dragino_lsn50 : usart1 usart2
* boards/arm/olimexino_stm32 : usart1 usart2 usart3
* boards/arm/stm32vl_disco : usart1 usart2 usart3
* boards/arm/96b_stm32_sensor_mez : usart1 usart2 usart3 uart4
* boards/arm/nucleo_f401re : usart1 usart2
* boards/arm/google_kukui : usart1
* boards/arm/nucleo_l4r5zi : usart1 lpuart1 usart2 usart3
* boards/arm/nucleo_f767zi : usart2 usart3 usart6
* boards/arm/nucleo_f413zh : usart3 usart6
* boards/arm/nucleo_g431rb : usart1 lpuart1
* boards/arm/nucleo_l073rz : usart1 usart2
* boards/arm/stm32f411e_disco : usart2
* boards/arm/stm32l476g_disco : usart2
* boards/arm/waveshare_open103z : usart1 usart2
* boards/arm/olimex_stm32_h407 : usart2 usart3 usart6
* boards/arm/nucleo_f207zg : usart3 usart6
* boards/arm/stm32f072_eval : usart2
* boards/arm/stm32l496g_disco : usart1 usart2 lpuart1
* boards/arm/black_f407ve : usart1 usart2
* boards/arm/96b_neonkey : usart1
* boards/arm/nucleo_l053r8 : usart1 usart2
* boards/arm/96b_aerocore2 : usart1 usart2 usart3 uart7 uart8
* boards/arm/nucleo_f070rb : usart1 usart2
* boards/arm/nucleo_h745zi_q : usart3 uart8
* boards/arm/stm32_min_dev : usart1 usart2 usart3
* boards/arm/stm32f030_demo : usart1
* boards/arm/stm32f429i_disc1 : usart1 usart2
* boards/arm/olimex_stm32_p405 : usart2
* boards/arm/stm32f412g_disco : usart2
* boards/arm/stm32f072b_disco : usart1
* boards/arm/olimex_stm32_h103 : usart1 usart2 usart3
* boards/arm/nucleo_g474re : usart1 lpuart1
* boards/arm/96b_wistrio : usart1 usart2
* boards/arm/stm3210c_eval : usart2
* boards/arm/stm32h747i_disco : usart1 uart8
* boards/arm/nucleo_l452re : usart1 usart2
* boards/arm/nucleo_l476rg : usart1 usart2 usart3
* boards/arm/blackpill_f411ce : usart1
* boards/arm/disco_l475_iot1 : uart4
* boards/arm/nucleo_f746zg : usart2 usart3 usart6
* boards/arm/nucleo_g071rb : usart2
* boards/arm/nucleo_f103rb : usart1 usart3
* boards/arm/stm32f4_disco : usart1 usart2
* boards/arm/96b_argonkey : usart1
* boards/arm/b_l4s5i_iot01a : usart1 uart4
* boards/arm/sensortile_box : usart1 usart2
* boards/arm/stm32f3_disco : usart1 usart2
* boards/arm/stm32f769i_disco : usart1 usart6
* boards/arm/stm32f469i_disco : usart3 usart6
* boards/arm/b_l072z_lrwan1 : usart1 usart2
* boards/arm/stm32f0_disco : usart1 usart2
* boards/arm/stm32l1_disco : usart1 usart2 usart3
* boards/arm/mikroe_mini_m4_for_stm32 : usart2
* boards/arm/stm32mp157c_dk2 : usart3 uart7
* boards/arm/steval_fcu001v1 : usart1
* boards/arm/nucleo_f030r8 : usart1 usart2
* boards/arm/stm32373c_eval : usart2
* boards/arm/adafruit_feather_stm32f405 : usart3
* boards/arm/nucleo_f429zi : usart3 usart6
* boards/arm/96b_avenger96 : uart4 uart7
* boards/arm/olimex_stm32_e407 : usart1 usart3 usart6
* boards/arm/stm32g0316_disco : usart1 usart1
* boards/arm/nucleo_f412zg : usart3 usart6
* boards/arm/nucleo_wb55rg : usart1 lpuart1
* boards/arm/nucleo_f446re : usart1 usart2
* boards/arm/nucleo_l496zg : usart2 lpuart1
* boards/arm/nucleo_f303re : usart2
* boards/arm/96b_carbon : usart1 usart2 usart6
* boards/arm/nucleo_l152re : usart2
* boards/arm/nucleo_l432kc : usart1 usart2
* boards/arm/nucleo_f411re : usart1 usart2

'*' PR providing new configuration is ready for these boards

28851 should bring support for nucleo_l432kc ->closed moved to #28954

28954 ports all of the remaining boards

28940 brings support for nucleo_h745zi_q

Enhancement Boards Devicetree STM32

Most helpful comment

Looks like the rough list of devices is:

  • UART/LPUART/USART
  • PWM
  • I2C
  • ETH
  • SPI
  • CAN
  • ADC
  • USB/OTG
  • DAC
  • I2S
  • SDMMC

All 11 comments

@erwango @gmarull Looks like we have some job to do to port all of these boards. I can help you of course for review and porting.

@lochej Thanks for you help and interest. And besides serial and PWM, I'd like all the existing peripheral drivers (not only serial) to be converted so pinmux.c files could be removed before V2.5.0 code freeze (next January).
Before starting this task myself, I was letting some time to see if there was some activity on on community to help. But for now, aside from you 2, this is calm....

@lochej Thanks for you help and interest. And besides serial and PWM, I'd like all the existing peripheral drivers (not only serial) to be converted so pinmux.c files could be removed before V2.5.0 code freeze (next January).

Agreed, that would be great ! USART and PWM are almost done.
That leaves, I2C, SPI, ADC, DAC, CAN, USB, SDIO and ETH to be done.

Before starting this task myself, I was letting some time to see if there was some activity on on community to help. But for now, aside from you 2, this is calm....

True, seeing the amount of work remaining, some help would help a lot.

I think #28858 will help on introducing a substantial amount of pinctrl includes, a work that only needs to be done once per board. It is the most tedious part IMO. We can probably can come up with a script to semi-automate the rest, even though I have found some small problems when porting PWM (missing or wrong entries), so manual inspection will be required.

@erwango @lochej From my side until the end of the week I will bring my board nucleo_h745zi_q to pinctrl approach and remove pinmux.c. I will also intensively test each my PR on this way. Currently only u(s)art part is moved to pinctrl. In the next PR the whole board will be moved to it.

P.S. ST just provides too much dev boards 馃 ;)

@erwango @lochej From my side until the end of the week I will bring my board nucleo_h745zi_q to pinctrl approach and remove pinmux.c. I will also intensively test each my PR on this way. Currently only u(s)art part is moved to pinctrl. In the next PR the whole board will be moved to it.

P.S. ST just provides too much dev boards 馃 ;)

Great to hear ! I've ported the rest of the ST based boards to the pinctrl DT definitions. For now, only PWM and SERIAL are ready for pinctrl DT.
But once I2C/SPI and stuff get ported (the driver code is the base so that dt-binding are found) then we'll be able to port all other boards to it.

Though I don't know if we should wait until all drivers have been ported to DT and then do a full upgrade of each board to the new DT method or else we do like I did, one peripheral at a time. (that's time consuming 馃槀, having done it for serial already)

The first way takes time but is more gradual and could have enough time to test each module, but the second might be faster but risky in case of a bugs.

Great to hear ! I've ported the rest of the ST based boards to the pinctrl DT definitions. For now, only PWM and SERIAL are ready for pinctrl DT.
But once I2C/SPI and stuff get ported (the driver code is the base so that dt-binding are found) then we'll be able to port all other boards to it.

Though I don't know if we should wait until all drivers have been ported to DT and then do a full upgrade of each board to the new DT method or else we do like I did, one peripheral at a time. (that's time consuming 馃槀, having done it for serial already)

The first way takes time but is more gradual and could have enough time to test each module, but the second might be faster but risky in case of a bugs.

I was wondering if we can convert the dts's over and use the defines in pinmux.c until the drivers are changed to support DTS.

I was wondering if we can convert the dts's over and use the defines in pinmux.c until the drivers are changed to support DTS.

That might actually be possible, but we need to provide the dts-bindings for each peripheral right ?

That might actually be possible, but we need to provide the dts-bindings for each peripheral right ?

The binding on the peripheral side is just:

    pinctrl-0:
      type: phandles
      required: false
...

Would be good to add proper description.

Looks like the rough list of devices is:

  • UART/LPUART/USART
  • PWM
  • I2C
  • ETH
  • SPI
  • CAN
  • ADC
  • USB/OTG
  • DAC
  • I2S
  • SDMMC

if we can convert the dts's over and use the defines in pinmux.c u

I'm not quite in favor of this approach. Converting is one thing, but testing and reviewing is also required.
Having small PRs is indeed more tracking effort but easier to review.

Was this page helpful?
0 / 5 - 0 ratings