How to handle pinmux in libbsd (was: Re: [PATCH 10/10] TI Pinmux : Port to RTEMS)

Tue Jul 30 15:59:12 UTC 2019

On Tue, Jul 30, 2019 at 12:40 AM Christian Mauderer
<christian.mauderer at embedded-brains.de> wrote:
>
> On 29/07/2019 22:11, Gedare Bloom wrote:
> > We had a GSoC project about GPIO API implemented for RPi.
> >
> > https://devel.rtems.org/wiki/GSoC/2013/Raspberry_Pi_BSP_Peripherals
>
> Hello Gedare,
>
> thanks for the hint. It seems that someone used at least the
> <bsp/gpio.h> for BBB too (in bsps/arm/beagle/gpio/bbb-gpio.c). But it
> seems that RPi and BBB are the only BSPs using the API.
>
> So it would be necessary to find out in what state the API is (is it
> general enough to theoretically support every BSP; is the support in BBB
> in a usable state) and if yes it would be worth to implement a fdt GPIO
> initialization based on that API.
>
> I'll try to take a look at that in the next few days (most likely more
> toward the weekend). Depending on the amount of work, it could be worth
> to just implement it or put it in a future GSoC project.
>
I'm sure it could be expanded to a full project by trying to
generalize it, and by mapping for example the arduino wiring APIs over
it.

> Best regards
>
> Christian
>
> >
> >
> > On Mon, Jul 29, 2019 at 4:10 AM Christian Mauderer
> > <christian.mauderer at embedded-brains.de> wrote:
> >>
> >> On 29/07/2019 10:54, Vijay Kumar Banerjee wrote:
> >>>
> >>>
> >>> On Sun, Jul 28, 2019 at 5:44 PM Christian Mauderer <list at c-mauderer.de
> >>> <mailto:list at c-mauderer.de>> wrote:
> >>>
> >>>     On 28/07/2019 12:42, Vijay Kumar Banerjee wrote:
> >>>     >
> >>>     >
> >>>     >
> >>>     > On Sat, Jul 27, 2019 at 7:35 PM Christian Mauderer
> >>>     <list at c-mauderer.de <mailto:list at c-mauderer.de>
> >>>     > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>> wrote:
> >>>     >
> >>>     >     Does this initialize only the pins for drivers that are
> >>>     registered in
> >>>     >     libbsd or all pins? I think you had an extended boot log where
> >>>     you might
> >>>     >     could see it.
> >>>     >
> >>>     >     If it is all pins, this might interfere with RTEMS drivers
> >>>     that are not
> >>>     >     libbsd based. In that case we need some kind of solution (not
> >>>     sure yet
> >>>     >     which one).
> >>>     >
> >>>     > It's muxing more pins than just the HDMI, including i2c pins.
> >>>     Please have
> >>>     > a look at the log that I got from RTEMS:
> >>>     > https://paste.ofcode.org/kVvrdYAfvC3G6kBtG5iaTb
> >>>     >
> >>>     > These pins to be initialized are being decided from the device
> >>>     tree nodes
> >>>     > with the pinctrl-single,pins property. If the initialized pins are not
> >>>     > all required,
> >>>     > then I would like to propose a solution of using an overlay to
> >>>     rename the
> >>>     > property to "rtems-pinctrl-single,pins" or something like this for the
> >>>     > pins that
> >>>     > we need to be initialized, like hdmi. And in the ti_pinmux.c
> >>>     modify the
> >>>     > code to
> >>>     > search for this property instead of the default.
> >>>     >
> >>>     > I haven't attempted doing it but before I attempt I would like to make
> >>>     > sure if
> >>>     > you think it's OK and not too hackish approach.
> >>>
> >>>     I'm not that happy with doing that in the device tree because it puts
> >>>     special requirements on the used one. From an application programmers
> >>>     perspective I wouldn't expect that there are two locations that can have
> >>>     an influence on my I2C pins. In this case: The i2c driver and the device
> >>>     tree. But I'm not yet sure how a good solution could look like.
> >>>
> >>>     From my point of view it would be optimal if libbsd only initializes the
> >>>     pins that are used by a libbsd driver and not for example the led pins.
> >>>     But that isn't how the pinmux driver is intended to work.
> >>>
> >>> Since the driver parses the device tree to decide what to initialize, I was
> >>> suggesting an overlay as a (temporary) solution.
> >>>
> >>>     An alternative could be to do the pin initialization in the BSP based on
> >>>     the device tree instead of importing the FreeBSD pinmux driver.
> >>>     Currently there is no clean consistent implementation how the pins are
> >>>     handled in the drivers. So a clean up wouldn't hurt. Depending on how
> >>>     much work that is, it could be a hack for now and for example a GSoC
> >>>     project for next year.
> >>>
> >>> Is this a blocker to merge the driver until we have a clean pinmux solution
> >>> in BSP or is it OK to merge it with a hack for now while we come up with
> >>> a better solution.
> >>
> >> For the pinmux patches that's a blocker. But I would be OK with a hack
> >> instead of the pinmux patches.
> >>
> >> There's still the problem with the lines (which I think could be a
> >> caching toppic). So it's not critical yet to find a solution. Let's
> >> first wait whether someone jumps in on the discussion.
> >>
> >>>
> >>>     I think we don't have a clean consistent API for GPIO for a lot of BSPs.
> >>>     So it wouldn't hurt to either find out whether we have one and implement
> >>>     a device tree parser for it or define one (most likely based on FreeBSD
> >>>     pinmux) and implement it for some existing and in future also for
> >>>     new BSPs.
> >>>
> >>> I don't know how much work that would be but I'm willing to take it up
> >>> and work
> >>> on it.
> >>
> >>
> >> I'm not even sure how the solution could look like yet (haven't had a
> >> look at it myself) so I'm not that keen on adding it to your project.
> >> Something like that should be planned and discussed with the community
> >> which needs more than two or three days.
> >>
> >> So we can discuss that as a possible next step for your project. But I
> >> think I would prefer if you would add a hack and followed the original
> >> plan to do a console or an graphics library. Exception would be that
> >> there is a totally convincing suggestion for the GPIO topic in the next
> >> days.
> >>
> >>>
> >>>     Let's wait for some other opinions here.
> >>>
> >>>     Best regards
> >>>
> >>>     Christian
> >>>
> >>
> >> --
> >> --------------------------------------------
> >> embedded brains GmbH
> >> Herr Christian Mauderer
> >> Dornierstr. 4
> >> D-82178 Puchheim
> >> Germany
> >> email: christian.mauderer at embedded-brains.de
> >> Phone: +49-89-18 94 741 - 18
> >> Fax:   +49-89-18 94 741 - 08
> >> PGP: Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.