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.maude...@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 <l...@c-mauderer.de > > <mailto: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> > > > <mailto: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. > > 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.maude...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
