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

[Vijay Kumar Banerjee]

On Sun, Jul 28, 2019 at 5:44 PM Christian Mauderer <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>> 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.

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

> Let's wait for some other opinions here.
>
> Best regards
>
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190729/61cb2839/attachment-0002.html>