Road from pinmux to pinctrl

[carlescufi]

Goals of the transition for each SoC family

• nRF
  • Allow users to continue using <signal>-pin properties during the transition period (when CONFIG_PINCTRL=n)
  • No pre-defined combinations since almost every pin can take any function
• NXP
  • i.MX
  • Kinetis
  • LPC
• STM32
  • Existing Devicetree representation will be kept
  • Pinmux driver will be kept in tree during the transition period, but will not be used by any driver

Timeline

• Grace period between 2.7.99 and 3.1 where both pinctrl and pinmux coexist, no deprecation
• By 3.1 all in-tree boards must've switched to pinctrl:
  • Pinctrl driver complete
  • All peripheral drivers for the SoC family supporting pinctrl
  • In-tree boards use the new pinctrl representation
• After 3.1 is released (3.1.99) we deprecate pinmux
• Zephyr 3.2 deprecates pinmux, Zephyr 3.4 removes pinmux

Porting status

• Telink B91
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_b91.c
  • Proposal: Telink b91 pinctrl #42773
  • Assignee: @yurvyn
• TI CC13xx/CC26xx
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_cc13xx_cc26xx.c
  • Note: uses <signal>-pin DT properties
  • Proposal: CC13XX CC26XX : transition from pinmux to pinctrl #44492
  • Assignee: @vaishnavachath
• ESP32
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_esp32.c
  • Notes: uses <signal>-pin DT properties
  • Proposal: pinctrl: esp32/s2/c3: initial support #43589
  • Assignee: @glaubermaroto
• HSDK
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_hsdk.c
  • Proposal: ARC: boards: HSDK: get rid of pinmux usage #45343
  • Assignee: @evgeniy-paltsev
• Intel S1000
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_intel_s1000.c
  • Proposal: drop intel_s1000_crb board #46496
  • Assignee: @nashif
• ITE IT8xxx2
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_ite_it8xxx2.c
  • Proposal: ITE: drviers/pinctrl: Add pinctrl driver for IT8XXX2 #44786
  • Assignee: @GTLin08
• NXP LPC11U6X
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_lpc11u6x.c
  • Proposal: Lpc 11u6x pinctrl #44843
  • Assignee: @danieldegrasse
• Microchip MCHP XEC
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_mchp_xec.c
  • Proposal: Mec172x pinctrl #43282
  • Assignee: @jvasanth1
  • Missing: MEC1501, e.g. https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/arm/mec1501modular_assy6885 MEC15xx/MEC1501: deprecate pinmux and move to pinctrl #48893
• NXP Kinetis
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_mcux.c
  • Proposal: Add initial pinctrl support for NXP kinetis #39743, Initial Kinetis pinctrl Implementation #43033 soc: kinetis: full pinctrl enablement for Kinetis boards #43560
  • Assignee: @danieldegrasse
• NXP iMX RT1xxx
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/mimxrt1060_evk/pinmux.c
  • Proposal: Alternative pin group based pinctrl implementation for RT1062 #42238 iMX RT full pinctrl enablement #44150
  • Assignee: @danieldegrasse
• NXP MCUX LPC
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_mcux_lpc.c
  • Proposal: soc: lpcxpresso: Initial pinctrl implementation for NXP LPC #43454, Full pin control enablement for LPC SOCs #44907
  • Assignee: @danieldegrasse
• NXP iMX RT6xx/5xx
  • Existing pinmux driver: N/A (custom implementation)
  • Proposal: RT500/RT600 pin control #44571
  • Assignee: @danieldegrasse
• NXP iMX8M
  • Existing pinmux driver: N/A (custom implementation)
  • Proposal: Pin control support for i.MX application cores #45126
  • Assignee: @danieldegrasse
• RV32M1
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_rv32m1.c
  • Proposal: soc: riscv: openisa: rv32m1: add pinctrl support #45274
  • Assignee: @henrikbrixandersen
• Atmel SAM/SAM0
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_sam0.c
  • Proposal: (pending: multiple device drivers, board conversion)
    • Add Atmel SAM0 pinctrl #35423
    • Add Atmel SAM0 pinctrl for SPI, I2C & TCC #42512
    • drivers: pinctrl: Update Atmel sam/sam0 pinctrl drivers #43731
  • Assignee: @nandojve
• SiFive
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_sifive.c
  • Proposal: FE310-based boards: transition from pinmux to pinctrl  #44068
  • Assignee: @tgorochowik
• nRF
  • Existing pinmux driver: N/A (done at device drivers)
  • Proposal: pinctrl: add nrf implementation #39429 boards: nrf: port to pinctrl #43926
  • Assignee: @anangl
• STM32
  • Existing pinmux driver: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/pinmux/pinmux_stm32.c
  • Proposal: pinctrl: add STM32 implementation #40194
• Nuvoton NPCX
  • Existing pinmux driver: N/A (custom implementation)
  • Proposal: pinctrl: add NPCX implementation. #43638
  • Assignee: @MulinChao @ChiHuaL @WealianLiao

Custom APIs

• SiLabs

  • Existing pinmux driver: N/A (custom implementation)
  • Proposal: Initial support for EFR32BG22 #50352
  • Assignee: @chrta

• Cypress psoc6

  • Existing pinmux driver: N/A (custom implementation, see e.g. dts/arm/cypress/psoc6-pinctrl.dtsi)
  • Assignee: @npal-cy (please confirm)
  • Enhancement issue: drivers: pinctrl: Use common pinctrl DTS bindings for Cypress psoc6 #52434

• armv8-m/armv7-m

  • Existing pinmux driver: N/A (board level C code)
  • Assignee: @ithinuel
  • https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/v2m_musca_b1/pinmux.c
  • https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/mps2_an385/pinmux.c
  • Enhancement issue: drivers: pinctrl: add pinctrl driver for armv7-m/armv8-m #52435

• ARC emsk

  • Existing pinmux driver: N/A (board level C code)
  • https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arc/em_starterkit/pmodmux.c
  • Assignee: @ruuddw (please confirm: tbd, see Pinctrl for applicable ARC boards #45771)
  • Enhancement issue: drivers: pinctrl: add pinctrl driver for ARC emsk #52436

• Xilinx ZynqMP

  • Existing pinmux driver: N/A (board level C code)
  • https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/arm/mercury_xu/board.c
  • Assignee: @wsipak (please confirm)
  • Enhancement issue: drivers: pinctrl: add pinctrl driver for the Xilinx ZynqMP platform #52437

New drivers

List of new driver proposals for SoCs that did not have an existing pinmux driver.

• GigaDevice
  • Proposal: pinctrl: initial support for GD32 #39974
• RaspberryPi Pico (RP2040)
  • Proposal: boards: Add support for the raspberrypi pico #34835
• Renesas R-Car
  • Proposal: Renesas R-Car: Add Pinmux driver version 2 #40550
• Bouffalo Lab
  • Proposal: riscv: Introduce Bouffalo Lab SoC and dt_bl10_devkit #37686
• Xilinx Zynq-7000
  • Proposal: soc: xilinx: zynq7000: add pinctrl driver + digilent zybo board #46648

[nashif]

pinctrl documentation and migration: https://docs.zephyrproject.org/latest/guides/pinctrl/index.html

[erwango]

Updated STM32 reference (#40194 takes place of #30430)

[henrikbrixandersen]

I have added assignees to the various conversions from pinmux to pinctrl drivers. Please confirm, comment, or reassign as needed.

[ifyall]

@carlescufi, for the Cypress part migration, can you confirm that this is the existing parts introduced by @nandojve? I believe he is the current code owner there.

What is the timeline for the 3.1 release?

Thank you,

Ian

[nandojve]

@carlescufi, for the Cypress part migration, can you confirm that this is the existing parts introduced by @nandojve? I believe he is the current code owner there.

What is the timeline for the 3.1 release?

Thank you,

Ian

Infineon have joined to Zephyr Project as a Silver Member and they have plans to improve PSoC-6 support.
Maybe @npal-cy can give a more accurate info about current pinctrl API migration plans.

[gmarull]

@jvasanth1 MEC1501 boards seem to depend on pinmux API, are they going to be ported?

[npal-cy]

@carlescufi, for the Cypress part migration, can you confirm that this is the existing parts introduced by @nandojve? I believe he is the current code owner there.
What is the timeline for the 3.1 release?
Thank you,
Ian

Infineon have joined to Zephyr Project as a Silver Member and they have plans to improve PSoC-6 support. Maybe @npal-cy can give a more accurate info about current pinctrl API migration plans.

Current PSoC 6 implementation is not using pinmux, so it is not block this migration. We will remove current PSoC 6 integration, once new one add (so we do not want add any updates here, if it is not real critical).

In new PSoC 6 we implemented pinctrl driver. It can be review in scope of #44211.

Regards,
Nazar

[ruuddw]

For ARC emsk, with a different custom API: I'm not sure yet, need to investigate (see #45771) is pinctl would be the right solution for our connector-level pmod muxing.

[fabiobaltieri]

@carlescufi do you think we can close this if the MEC1501 support gets merged? Thinking that the remaining 5 platforms that currently have no multiplexing driver at all should be covered separately (if at all).

[gmarull]

I think we should give at most a couple more releases for those platforms to move to pinctrl or be removed (these are likely platforms with poor maintenance). Many of the migrated platforms (e.g. Nordic or STM32) did not use pinmux API at all, but they were included in the migration list.

[fabiobaltieri]

Cool, was just thinking about this in the context of v3.2 and keeping as a target to remove the last pinmux users, and then track implementing new platforms separately for v3.3.

[cfriedt]

@carlescufi @cfriedt I will volunteer to transition TI CC32x, will try to get the PR ready by coming Monday.

@vaishnavachath - was this one already merged? I can't recall

[vaishnavachath]

@carlescufi @cfriedt I will volunteer to transition TI CC32x, will try to get the PR ready by coming Monday.

@vaishnavachath - was this one already merged? I can't recall

@cfriedt , No sorry I missed the CC32XX platforms I am working on this and will send a PR soon.

[cfriedt]

@carlescufi @cfriedt I will volunteer to transition TI CC32x, will try to get the PR ready by coming Monday.

@vaishnavachath - was this one already merged? I can't recall

@cfriedt , No sorry I missed the CC32XX platforms I am working on this and will send a PR soon.

@vaishnavachath - please ping me when you're ready. Release is scheduled very soon, and this needs to be in - otherwise, the board could be removed.

[henrikbrixandersen]

Closing this issue as I have opened enhancement issues for the remaining, custom implementations in-tree.

[nandojve]

Hi @henrikbrixandersen , @gmarull ,

Zephyr is moving to a LTS version using custom implementations in this topic (and maybe in others). I can be wrong but as far I remember it was agreed that they should be moved to the official API.

IMHO this is open a bad precedent in Zephyr were the rules/agreement are imposed for a few and for the others are just convenience. The project should enforce participants to be in sync with project roadmap and not the contrary.

This is clearly accumulating debit since after one year there are participants that not even have a plan.

Can you clarify what is going on?

[gmarull]

Hi @henrikbrixandersen , @gmarull ,

Zephyr is moving to a LTS version using custom implementations in this topic (and maybe in others). I can be wrong but as far I remember it was agreed that they should be moved to the official API.

IMHO this is open a bad precedent in Zephyr were the rules/agreement are imposed for a few and for the others are just convenience. The project should enforce participants to be in sync with project roadmap and not the contrary.

This is clearly accumulating debit since after one year there are participants that not even have a plan.

Can you clarify what is going on?

I don't know who can decide on this topic (TSC? A maintainer? A WG?). I'd be brave and drop all those who haven't migrated. If they care about Zephyr, they'll eventually come back with a PR adding the platform back with a proper driver.

[microbuilder]

For the two Arm parts that need updating, this is completely my bad that it fell off my radar. I've asked @ithinuel if he can have a look at those since both those platforms come from Arm itself and are a bit unusual, but if he doesn't have the free cycles to update these I'll try to remember the details of those two platforms myself. Thanks for calling this out.