Need community suggestions for a new generic GPIO API

[Gedare Bloom]

On Tue, Jul 11, 2023 at 7:05 AM Christian MAUDERER
<christian.mauderer at embedded-brains.de> wrote:
>
> Hello Utkarsh,
>
> please be a bit careful with GPIO and pin functions. That's a quite
> difficult topic.
>
> Some controller manufacturers mix these functions. One such example is
> the STM32 family. I'll take the STM32F410 as an example. That chip has a
> GPIO register block with one GPIOx_MODER where you can select whether a
> pin is a Input, GPIO, alternate function or analog mode. There is also a
> GPIOx_OSPEEDR that defines speed and some others that define pull ups /
> downs and so on.
>
> Other controllers - like a lot of the NXP ones - have two completely
> independent modules for that. I'll take the i.MXRT1050 series as an
> example: That chip has an IOMUXC where you can set a pin function for a
> pad. For example, there is a register IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_26.
> In that register, you can set a pin function of GPIO4_IO26. There is a
> related PAD_CTL register in the IOMUXC where you can set up pull ups /
> downs, drive strength and so on. The GPIO controller where you set up
> levels and interrupts for that pin is a completely unrelated module. On
> the i.MXRT1166 you can even assign some pins to two different GPIO
> controllers. So it's not possible to have a 1:1 mapping between pin and
> GPIO.
>
> If you ask me GPIO and pin function are two separate things and need two
> APIs. That should make it possible to support controllers like the STM32
> (where some of the GPIO registers would be controlled by the GPIO API
> and some by the pin function API) and for controllers like the i.MXRT
> where the two APIs would handle different hardware modules.
>
> If you take a look at Linux or FreeBSD, they usually split that up just
> like that. If you want to dig deeper into that, maybe it would be worth
> to take a look at some other embedded operating systems. For example
> Zephyr or Contiki or any of the ones in Wikipedia "Comparison of
> real-time operating systems". It can even be a good idea to create a
> compatible interface.
>
This reminds me that I think the pinmux was lifted out of libbsd and
put into RTEMS for the BBB.
* shared/freebsd/sys/arm/ti/ti_pinmux.c

This may be the right direction to go for other targets, where they
have support in FreeBSD. And where they don't, compliance to that
pinmux API may be preferable.

> Best regards
>
> Christian
>
> On 2023-07-07 21:48, Utkarsh Verma wrote:
> > Dear all,
> >
> > While working on the Raspberry Pi 4 BSP, I realized that the GPIO API
> > could be improved. It seems that last year, a GSoC student worked on
> > introducing a new GPIO API, called GPIO2 to RTEMS. However, it did not
> > get merged. Discussing this topic with my mentor and on RTEMS Discord
> > revealed that it would be a good idea to get it merged. For that, I
> > would like to ask the community the following:
> >
> > - Moving forward, will GPIO2 API be the community-preferred GPIO API?
> > - What would be the recommended way in this new API to select
> > alternate pin functions? Will that be left for the BSP to decide?
> >
> > Here are the links associated with GPIO2:
> > Git Repo: https://github.com/dtbpkmte/GSoC-2022-RTEMS
> > GPIO2 commit: https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/0aec268f1209c
> > Blog post about the API:
> > https://medium.com/@dtbpkmte/gsoc-2022-rtems-coding-period-week-4-gpio-wiki-1f10e5c4458
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
> --
> --------------------------------------------
> embedded brains GmbH & Co. KG
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email:  christian.mauderer at embedded-brains.de
> phone:  +49-89-18 94 741 - 18
> mobile: +49-176-152 206 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRA 117265
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel