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

Mon Jul 29 20:11:08 UTC 2019

We had a GSoC project about GPIO API implemented for RPi.

https://devel.rtems.org/wiki/GSoC/2013/Raspberry_Pi_BSP_Peripherals

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