henrikbrixandersen
commented
1 year ago There is a difference between GPIO and other peripherals when it comes to pinctrl. GPIO drivers are responsible for setting up pins (including pin multiplexing) for GPIO usage without devicetree pinctrl nodes, whereas other peripherals rely on devicetree pinctrl nodes for describing the required multiplexing, pull-ups, -downs, etc.
This is what the paragraph quoted above tries to convey.
Is your enhancement proposal related to a problem? Please describe.
The Pin control vs. GPIO says that:
Some functionality covered by a pin controller driver overlaps with GPIO drivers. For example, pull-up/down resistors can usually be enabled by both the pin control driver and the GPIO driver. In Zephyr context, the pin control driver purpose is to perform peripheral signal multiplexing and configuration of other pin parameters required for the correct operation of that peripheral. Therefore, the main users of the pin control driver are SoC peripherals. In contrast, GPIO drivers are for general purpose control of a pin, that is, when its logic level is read or controlled manually.Feel like this is a little missleading as overlapping might not be so important. Describe the solution you'd like
I am wondering if we can say that GPIO is just another type of peripheral like those I2C or SPI or UART controllers. They all compete for pins to reach external of the chip. From this regard, Zephyr pinctrl model captures the multiplexing and pin config functions. GPIO controller should do their own job like I/O direction or interrupt triggering etc.
In general, the high level overview of pinctrl is excellant documentation practice. Zephyr probably should encourage all driver documents have conceptual high level overview so that users can quickly learn if a driver is of interest or not, especially for complex bus peripherals.