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

Christian Mauderer list at
Tue Jul 30 19:31:06 UTC 2019

On 30/07/2019 17:59, Gedare Bloom wrote:
> On Tue, Jul 30, 2019 at 12:40 AM Christian Mauderer
> <christian.mauderer at> wrote:
>> On 29/07/2019 22:11, Gedare Bloom wrote:
>>> We had a GSoC project about GPIO API implemented for RPi.
>> 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.

I had a look at the GPIO stuff that we have. To be honest: From a quick
look the API defined in bsps/include/bsp/gpio.h looks very complex for
something like GPIO. It's a 1000 line file and I think it's necessary to
read the documentation quite thoroughly before the API can be used. But
I didn't found anything that looks like a generic pin mux setting.

The only part that would have to do anything with a pin mux in the
Beagle implementation of that API are two static objects in
bsps/arm/beagle/gpio/bbb-gpio.c which are never used. These objects are
dead code and I created a patch to remove them:

So to summarize it: We don't have any pin mux handling yet. It would be
worth implementing one that can parse FreeBSD / Linux device tree files.
I'll have to have a look at FreeBSD how non-device-tree targets do the
initialization. Maybe it would be an API that can be cloned. In that
case - depending on the effort - it will be possible to decide whether
that can be a future GSoC project or not.

>> Best regards
>> Christian
>>> On Mon, Jul 29, 2019 at 4:10 AM Christian Mauderer
>>> <christian.mauderer at> wrote:
>>>> On 29/07/2019 10:54, Vijay Kumar Banerjee wrote:
>>>>> On Sun, Jul 28, 2019 at 5:44 PM Christian Mauderer <list at
>>>>> <mailto:list at>> wrote:
>>>>>     On 28/07/2019 12:42, Vijay Kumar Banerjee wrote:
>>>>>     >
>>>>>     >
>>>>>     >
>>>>>     > On Sat, Jul 27, 2019 at 7:35 PM Christian Mauderer
>>>>>     <list at <mailto:list at>
>>>>>     > <mailto:list at <mailto:list at>>> 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:
>>>>>     >
>>>>>     >
>>>>>     > 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
>>>> 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
>> --
>> --------------------------------------------
>> embedded brains GmbH
>> Herr Christian Mauderer
>> Dornierstr. 4
>> D-82178 Puchheim
>> Germany
>> email: christian.mauderer at
>> 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.

More information about the devel mailing list