On Sun, Jul 28, 2019 at 5:44 PM Christian Mauderer <l...@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 <l...@c-mauderer.de > > <mailto:l...@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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel