Add pinctrl driver for imx8-based platforms

[dreamliner787-9]

This PR adds implmentation and documentations of the pinctrl subsystem and driver for imx8-based platforms.

Limitations:

• Dynamic configuration of pinctrl registers at runtime is unsupported as the client interface are being worked out. Currently, the driver will only set the default configuration.
• "Quirky" select input values on imx8 platforms are unsupported (https://github.com/torvalds/linux/blob/c94d59a126cb9a8d1f71e3e044363d654dcd7af8/drivers/pinctrl/freescale/pinctrl-imx.c#L198C1-L199C1). Though as far as I can tell, these values only exists in some vendor specific kernels and never made it to mainline Linux.

Checklist before we can merge this:

• Merge Add Pinctrl device class microkit_sdf_gen#14
• Add pinctrl example to hardware CI

[dreamliner787-9]

@dreamliner787-9 sort out once au-ts/microkit_sdf_gen#14 is merged

[Courtney3141]

Looks like a good first implementation. Needs to be rebased and ensure all docs files have line length < 100 chars.

[Courtney3141]

The only remaining change not mentioned (that I think we should do something about) is the Python devicetree module.

[omeh-a]

I see this is approved already, but is this example meant to have been replaced with something new? This doesn't appear to do anything with pinctrl just yet.

[dreamliner787-9]

I just copied the serial example to demonstrate how you can compile the pinctrl driver as we don't have any drivers for the IMX platform that requires pinctrl configuration yet (afaik).

[omeh-a]

That's fair enough, although it would definitely be good to somehow have an example that specifically shows that the pinctrl driver works so we can use it for CI. Is it possible to write an example that does something like assign a constant value to an output pin? E.g. connect a voltage line -> GPIO pin. (contrived, ik).

It would be strongly preferable if something like that can happen so that we can always narrow the failing example back to pinctrl instead of also needing to wonder if the associated driver class is the issue.

[dreamliner787-9]

I did thought of that when I cloned the serial example. But since this driver doesn't support dynamic pinctrl configuration (yet). We would have to bundle an edited device tree with the example then explain where things differ. Which I thought was more complicated than necessary when serial is the most basic of devices that should work. Plus if the pinctrl driver is broken, it would break the "pinctrl" example rather than the "serial" example so we can always narrow down any failures.

We can revisit implementing your idea once the driver supports dynamic pinctrl reconfiguration?

[omeh-a]

@dreamliner787-9 So it seems like this PR died due to the revlock on sdfgen (argh!) ... This is a fairly important driver for work such as the LionsOS robot however, so we should consider freshening this up soonish. Once we have merged in the new sdfgen version for the current sDDF examples I will ping you and we can look at picking this up maybe?

[dreamliner787-9]

@dreamliner787-9 So it seems like this PR died due to the revlock on sdfgen (argh!) ... This is a fairly important driver for work such as the LionsOS robot however, so we should consider freshening this up soonish. Once we have merged in the new sdfgen version for the current sDDF examples I will ping you and we can look at picking this up maybe?

Sounds good.

[Courtney3141]

Converted to a draft for now - to return to after the new sdfgen is more developed.