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

[Christian Mauderer]

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>> 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.

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.

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.

Let's wait for some other opinions here.

Best regards

Christian