Padring

[jwnrt]

Currently the GPIO modules handle pin behaviour (pull-ups, inverting, etc.) and have a chardev interface. For correct pin modelling, we will need the chardev interface to connect to a padring representing the pads/pins of the chip rather than the GPIO block directly.

The pads should be routed through the pinmux which should handle attributes like opendrain, inverting, etc. then routed to a block, i.e. GPIO. We can consider adding special-purpose pins to the padring such as reset and possibly SPI CS.

[jwnrt]

Note: having a reset pin would help with bootstrapping flows.

Currently I assert bootstrap pins via the chardev to the GPIO and then reset over the monitor, but I'm getting a lot of races here where the pins have not been applied by the time the reset is sent.

If both the GPIO and the reset went via the padring, we would have a chance to flush all the state (potentially even with other chardevs like the SPI) before doing the reset.