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

Tue Jul 30 06:40:38 UTC 2019

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.

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.