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

[Christian Mauderer]

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.