<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 11, 2023 at 12:50 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 11, 2023 at 7:05 AM Christian MAUDERER<br>
<<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br>
><br>
> Hello Utkarsh,<br>
><br>
> please be a bit careful with GPIO and pin functions. That's a quite<br>
> difficult topic.<br>
><br>
> Some controller manufacturers mix these functions. One such example is<br>
> the STM32 family. I'll take the STM32F410 as an example. That chip has a<br>
> GPIO register block with one GPIOx_MODER where you can select whether a<br>
> pin is a Input, GPIO, alternate function or analog mode. There is also a<br>
> GPIOx_OSPEEDR that defines speed and some others that define pull ups /<br>
> downs and so on.<br>
><br>
> Other controllers - like a lot of the NXP ones - have two completely<br>
> independent modules for that. I'll take the i.MXRT1050 series as an<br>
> example: That chip has an IOMUXC where you can set a pin function for a<br>
> pad. For example, there is a register IOMUXC_SW_MUX_CTL_PAD_GPIO_EMC_26.<br>
> In that register, you can set a pin function of GPIO4_IO26. There is a<br>
> related PAD_CTL register in the IOMUXC where you can set up pull ups /<br>
> downs, drive strength and so on. The GPIO controller where you set up<br>
> levels and interrupts for that pin is a completely unrelated module. On<br>
> the i.MXRT1166 you can even assign some pins to two different GPIO<br>
> controllers. So it's not possible to have a 1:1 mapping between pin and<br>
> GPIO.<br>
><br>
> If you ask me GPIO and pin function are two separate things and need two<br>
> APIs. That should make it possible to support controllers like the STM32<br>
> (where some of the GPIO registers would be controlled by the GPIO API<br>
> and some by the pin function API) and for controllers like the i.MXRT<br>
> where the two APIs would handle different hardware modules.<br>
><br>
> If you take a look at Linux or FreeBSD, they usually split that up just<br>
> like that. If you want to dig deeper into that, maybe it would be worth<br>
> to take a look at some other embedded operating systems. For example<br>
> Zephyr or Contiki or any of the ones in Wikipedia "Comparison of<br>
> real-time operating systems". It can even be a good idea to create a<br>
> compatible interface.<br>
><br>
This reminds me that I think the pinmux was lifted out of libbsd and<br>
put into RTEMS for the BBB.<br>
* shared/freebsd/sys/arm/ti/ti_pinmux.c<br>
<br>
This may be the right direction to go for other targets, where they<br>
have support in FreeBSD. And where they don't, compliance to that<br>
pinmux API may be preferable.<br></blockquote><div><br></div><div>Not directly an API but the Virtio standard includes a GPIO device. </div><div>Assuming it was well thought out (I would assume it is), that is probably</div><div>the easiest device you want this API to interface with.</div><div><br></div><div><a href="https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html">https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html</a></div><div><br></div><div>FWIW I would like to see RTEMS support the full complement of virtio</div><div>device drivers.This should make it easiest to have RTEMS as a guest </div><div>under a variety of hypervisors, etc. including Xen.</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Best regards<br>
><br>
> Christian<br>
><br>
> On 2023-07-07 21:48, Utkarsh Verma wrote:<br>
> > Dear all,<br>
> ><br>
> > While working on the Raspberry Pi 4 BSP, I realized that the GPIO API<br>
> > could be improved. It seems that last year, a GSoC student worked on<br>
> > introducing a new GPIO API, called GPIO2 to RTEMS. However, it did not<br>
> > get merged. Discussing this topic with my mentor and on RTEMS Discord<br>
> > revealed that it would be a good idea to get it merged. For that, I<br>
> > would like to ask the community the following:<br>
> ><br>
> > - Moving forward, will GPIO2 API be the community-preferred GPIO API?<br>
> > - What would be the recommended way in this new API to select<br>
> > alternate pin functions? Will that be left for the BSP to decide?<br>
> ><br>
> > Here are the links associated with GPIO2:<br>
> > Git Repo: <a href="https://github.com/dtbpkmte/GSoC-2022-RTEMS" rel="noreferrer" target="_blank">https://github.com/dtbpkmte/GSoC-2022-RTEMS</a><br>
> > GPIO2 commit: <a href="https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/0aec268f1209c" rel="noreferrer" target="_blank">https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/0aec268f1209c</a><br>
> > Blog post about the API:<br>
> > <a href="https://medium.com/@dtbpkmte/gsoc-2022-rtems-coding-period-week-4-gpio-wiki-1f10e5c4458" rel="noreferrer" target="_blank">https://medium.com/@dtbpkmte/gsoc-2022-rtems-coding-period-week-4-gpio-wiki-1f10e5c4458</a><br>
> > _______________________________________________<br>
> > devel mailing list<br>
> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
> --<br>
> --------------------------------------------<br>
> embedded brains GmbH & Co. KG<br>
> Herr Christian MAUDERER<br>
> Dornierstr. 4<br>
> 82178 Puchheim<br>
> Germany<br>
> email:  <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> phone:  +49-89-18 94 741 - 18<br>
> mobile: +49-176-152 206 08<br>
><br>
> Registergericht: Amtsgericht München<br>
> Registernummer: HRA 117265<br>
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
> Unsere Datenschutzerklärung finden Sie hier:<br>
> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>