How to handle pinmux in libbsd (was: Re: [PATCH 10/10] TI Pinmux : Port to RTEMS)
Christian Mauderer
list at c-mauderer.de
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 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.
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:
https://lists.rtems.org/pipermail/devel/2019-July/026983.html
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 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.
>
More information about the devel
mailing list