Add EOS S3 GPIO driver

[kowalewskijan]

This PR introduces the GPIO driver for EOS S3 SoC and enables the driver for the QuickFeather board.

Note: This PR can be merged after hal_quicklogic PR to avoid conflicts between Zephyr API and HAL.

[pabigot]

Some initial comments. The architecture of this peripheral is not clear to me.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[kowalewskijan]

@pabigot I resolved some of your comments and provided a short explanation how the peripheral handles GPIOs.
@pabigot @galak Could you remove the stale label from this PR?
Thanks.

[pabigot]

While I'm looking at this could somebody please do something about #29283? I have no idea what this board is, and neither will anybody else.

[pabigot]

I'm pulling out my response to #28765 (comment) a direct comment because this is a design-level point:

Let me explain. There are total 16 physical pads/pins which can be configured as GPIOs. EOS S3 has only 8 GPIOs, each GPIO has a corresponding pair of physical pins and only one pin can be picked from a pair and used as GPIO. So it is possible to configure only 8 GPIOs connected to 8 pins. Controller needs only information about GPIO number (0-7) which should be read or written, beacuse the corresponding pin is assigned on the configure step.

OK, so that's a little more clear.

It looks like this driver is mixing pinmux configuration with GPIO configuration, by giving each of the 8 actual GPIO pins two pin indexes, which encode the pin to use in bit 3 with the true GPIO ordinal in bits 0..2.

So you can configure pin 1 and pin 2 and you'd have two GPIOs active, but if you configure pin 1 and pin 9 then you've got one GPIO (GPIO1 on pad 26) working and have quietly broken subsequent use of pin 1 (GPIO1 on pad 9).

Do I have that right?

If so, this seems way too fragile.

Would you expect to have an application switch between pads at runtime? If not then I think the GPIO controller devicetree binding should have a bitset property that indicates for the 8 gpios whether they should be connected to the primary (0) or secondary (1) pad for that GPIO. Then the controller ngpios should only claim to have eight pins, and all is good. In the future when Zephyr has a pinmux API we can add support for changing which pad is the connection for a specific GPIO at runtime if that's useful.

If you do expect to need to move GPIOs between pads right now, we need to figure out another solution, because having two pin ordinals that refer to the same GPIO signal is going to confuse the stuffing out of everybody.

[kowalewskijan]

Link to the TRM just in case: https://www.quicklogic.com/wp-content/uploads/2020/06/QL-S3-Technical-Reference-Manual-Vol-1.pdf#page=154

Generally there are two peripherals in EOS S3 which controls GPIOs: IOMux and Misc peripherals. IOMux is used to setup pins as GPIOs and driving a pin can be done from Misc.

Do I have that right?

Yep that's right. Well it seems that it is possible to switch between pads in runtime, but currently we can go with non-runtime version of the driver to keep it simple. Also it is noted in the TRM that the IOMux pad functions must be determined for a system design, so I believe non-runtime version is a way to go.

[pabigot]

Turning #28765 (comment) into a real review:

Rework this so the pads associated with the GPIO are determined at build time, rather than encoding a pad selection into the GPIO ordinal.

[kowalewskijan]

I've added pin-cfgs property to EOS S3 devicetree. It is now possible to setup either primary or secondary pin for each GPIO in the build time. @pabigot please take a look

[mnkp]

Let's test the driver with tests/drivers/gpio/gpio_api_1pin/ testcase.

[mnkp]

The "Add GPIO support for QuickLogic EOS S3 SoCs." commit relies on GPIO_EOS_S3 symbol defined in "Add GPIO driver for QuickLogic EOS S3 SoC." commit. We need to squash the two commits.

[pabigot]

Thanks, the things I was concerned about have been addressed.

Does this pass the tests in tests/drivers/gpio?

[kowalewskijan]

@pabigot I've just checked and there are still some adjustments that have to be done to make GPIO tests pass on hardware. I'll notify here when I'll have them green.

[mnkp]

LGTM, though I still have some comments. If you address the comments and let us know that the testcases are passing I will be happy to approve this PR.

[kowalewskijan]

@pabigot @mnkp I pushed some changes regarding handling interrupts which was the main problem to pass GPIO tests on hardware. Currently with the recent changes all tests are green on the device.

Additionally, I also updated the QuickFeather doc to point that the GPIO feature is supported.

[mnkp]

I propose to squash all the "boards: arm: quick_feather:" commits into one, or at least the following two

• "boards: quick_feather: enable GPIO driver"
• "boards: arm: quick_feather: add GPIO feature to docs"

[kowalewskijan]

I propose to squash all the "boards: arm: quick_feather:" commits into one, or at least the following two

• "boards: quick_feather: enable GPIO driver"
• "boards: arm: quick_feather: add GPIO feature to docs"

@mnkp I squashed all the boards commits