New class for software-defined peripherals

[josuah]

Problem Description

There is a number of software-defined peripherals present through Zephyr RTOS and not yet an API class for them:

Some with a custom instruction set and custom assembly stored as an array:

• Raspberry Pi PIO (see list of PRs for PIO-based peripherals).

Some with a plain C and assembly implementation (i.e. can use GCC):

• Nordic's FLPR

Some that are purely configuration based via structs and settings:

• NXP FlexIO.
• Intel's Time-aware GPIO.
• WCH CH417 (many, like SERDES, PIOC... not supported by Zephyr yet).
• NXP's SmartDMA (exposed through the HAL)
• Bouffalolab WO (and PEC, not supported by Zephyr yet)

If you know more through Zephyr sources or present in a Zephyr-supported SoC or PR, glad to learn about it.

Proposed Change (Summary)

Start incremental integration of everything under a same API with flexibility in how these are implemented, as a way to progressively bring uniformity in how software-defined peripherals can be used.

Proposed Change (Detailed)

• As a first step, no migration, only relocating the custom peripherals into a new dedicated include, preserving the custom API

• Define a new driver class to allow const struct device *, and move all init code into the device's init(), moving instantiation to devicetree

• Incrementally introduce new APIs to cover the common parts.

• Add an associated documentation page with guidelines for how to name the custom functions and structs and presentation of the area.

• Invite interested collaborators to take part in future reviews

Dependencies

None

Concerns and Unresolved Questions

• How to further reduce the difference between the implementations once introduced.

• How to help downstream code migrate to new APIs in case function are renamed.

• Being partly software and hardware, should it have a presence on devicetree?

Alternatives Considered

A "one size fits all" API, difficult to implement, overly generic (i.e. Linux's IOCTL challenge), breaking everyone's source and involving a very slow integration process with a big breaking merge.

[josuah]

Bonus: this moves at least 3 custom driver APIs out of misc/, helping with #91373 hopefully :)