Microchip Device Organization and Driver Grouping

[NhMchp]

Problem Description

Microchip is adding SoC support for multiple device families within Zephyr, including devices based on various architectures such as ARM, MIPS, and other proprietary platforms. Our goal is to deliver unified architecture for all Microchip-related content.

To achieve this, we recognize the need to standardize SoC and driver support, establishing a scalable foundation for integrating additional devices in the future. This approach will also help minimize redundant source code.

Proposed Change (Summary)

By standardizing the following areas, we aim to ensure alignment among all contributors.

• Organization of Microchip SoCs
• Peripheral Driver Grouping
• Device Header files

Proposed Change (Detailed)

1 Organization of Microchip SoCs

1.1 Problem description

Currently, Microchip devices are distributed across both the atmel and microchip directories. The existing directory structure is as follows:

soc/atmel
├── sam
│   ├── sam3x
│   ├── sam4e
│   ├── samv71
│   └── same70
└─── sam0
    ├── samc20
    ├── samd21
    ├── samd51
    └─── same54

The current grouping of SoCs and drivers under 'sam' and 'sam0' does not align with Microchip/Atmel’s official device naming conventions. Additionally, this structure can be confusing, as it may be mistaken for the supported architecture (e.g., Cortex-M0+).

Introducing new device families—from SAM, PIC32C, PIC32M, WBZ, and dsPIC—into the current hierarchy would likely increase confusion for end users. A more standardized and intuitive directory structure is needed to improve clarity and maintainability as support for additional device families is added.

1.2 Proposed Change

We recommend grouping devices according to their respective families, as reflected in the Microchip portal. We propose adopting the following organizational structure for device support.

SoC Organization

soc/microchip
├── sam
│   ├── sam_d5x_e5x
│   │   ├── samd51
│   │   └── same53
│   ├── sam_e7x_s7x_v7x
│   │   ├── same70
│   │   └── samv71
│   └── sam_c2x
│
├── pic32c
│   ├── pic32cx_bz
│   ├── pic32cx_sg
│   ├── pic32cm_jh
│   └── pic32cz_ca
│ 
├── pic32m
│   ├── pic32mx
│   ├── pic32mz_ef
│   └── pic32mz_w
│
├── dspic33
│   ├── dspic33a
│   └── dspic33c
│
└─── wbz
    ├── wbz35x
    │   ├── wbz350
    │   └── wbz351
    └─── wbz45x

Boards Organization

boards/microchip
├── sam
│   ├── sam_e54_xpro
│   ├── sam_e54_cult
│   └── sam_v71_xult
│
├── pic32c
│   ├── pic32cx_sg41_cult
│   ├── pic32cz_ca80_cult
│   ├── pic32cm_jh01_cpro
│ 
├── pic32m
│   ├── pic32mz_ef_sk
│   ├── pic32mz_ef_curiosity
│
├── dspic33
│   ├── dspic33a_curiosity
│   └── dspic33ch_curiosity
│
└─── wbz
    ├── wbz451_curiosity

2 Peripheral Driver Grouping

2.1 Problem description

Currently, Microchip peripheral drivers are grouped under sam and sam0. However, Microchip offers a wide range of variants for peripherals, many of which differ significantly and share few commonalities.

Organizing peripheral drivers solely by device name (e.g., sam, sam0, pic32) is not scalable, as many peripheral variants are shared across multiple SoC platforms, including PIC32C, PIC32M, SAM, and wireless devices. A more flexible and scalable approach is needed to accommodate the diverse and overlapping nature of peripherals across Microchip’s product families.

2.2 Proposed Change

Peripheral drivers should be created for each specific peripheral variant following the Zephyr driver structure. We recommend using the following naming convention for clarity, since multiples drivers can be available for same peripheral type:
<zephyr peripheral name>_mchp_<device peripheral variant name>_<ip_version_id>.c

Examples : pinctrl_mchp_pps_u148.c, adc_mchp_u2500.c

• Peripheral drivers should be reused across all devices that utilize the same peripheral variant. This will be achieved using the well defined devicetree bindings.
• Additionally, similar peripheral variants should be grouped together to minimize redundant code and improve maintainability.

3 Usage of ASF Header files

3.1 Problem description

Currently, peripheral drivers for Microchip devices in Zephyr rely on header files from ASF. This approach presents the following challenges:

• Not all ASF header files are licensed under Apache 2.0, which may cause licensing conflicts.
• ASF does not support newer devices, limiting driver reusability and compatibility with the latest hardware.
• Creates the need for fixup files

3.2 Proposed Change

Start to use the Microchip Device Family Packs (DFPs). The DFPs are licensed under Apache 2.0 and provide comprehensive support for all new Microchip devices. This approach ensures both license compliance and compatibility with the latest hardware. The DFPs code will reside inside Microchip specific HAL.

The fixups entries should be avoided from now on. The current fixups entries should be reworked inside Microchip HAL and Zephyr mainline if existent. The Atmel fixups still an exception and should be migrated on a second opportunity. New entries on Atmel should follow this new proposal. With this new directive it is expected that code will be cleaner, less confuse and decrease the maintenance.

Dependencies

Impact

• All newly added SoC, board, and driver files will adhere to the new organizational structure, driver grouping methodology, and will utilize DFP header files.
• SAME5x/D5x SoCs currently under the Atmel directory will be migrated to the new organization, adopt the updated driver grouping, and transition to using DFP header files.
• Support for all other Microchip and Atmel devices will remain unchanged at this time.

Concerns and Unresolved Questions

No response

Alternatives Considered

No response

[github-actions]

Hi @NhMchp! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[robertperkel]

I agree with this change, especially as new device families or hardware variants are released.

[AzharMCHP]

This change will indeed be helpful. However, what about the boards section? Are there any plans to change the hierarchy or standardize the naming?

[parthitce]

Peripheral drivers should be created for each specific peripheral variant following the Zephyr driver structure. We recommend using the following naming convention for clarity, since multiples drivers can be available for same peripheral type: <zephyr peripheral name>_mchp_<device peripheral variant name>_<ip_version_id>.c

Examples : pinctrl_mchp_pps_u148.c, adc_mchp_u2500.c

* Peripheral drivers should be reused across all devices that utilize the same peripheral variant. This will be achieved using the well defined devicetree bindings.

* Additionally, similar peripheral variants should be grouped together to minimize redundant code and improve maintainability.

@NhMchp Thanks for this putting this together.

• How to handle the devicetree bindings? i.e for example, microchip,pps-pinctrl will be generic, instead it shall also carry the IP variant / version details?
• modules/hal/microchip/dts/microchip/ will be the good placeholder for all the pinmuxing for the upcoming families. Do we have a way to generate the pinmux files from the include / header files? This way it doesn't need to be manual effort to create all the pinmux for each SoC.

[ghostMan-pac]

This looks good for peripherals with the ip-specific ids. But how do we handle the naming, if the said peripheral does not have an ip specific name, for example hwinfo? Shall we go ahead with the family name for that?

[NhMchp]

This change will indeed be helpful. However, what about the boards section? Are there any plans to change the hierarchy or standardize the naming?

Updated the RFC with board hierarchy.