On Tue, Jul 30, 2019 at 12:40 AM Christian Mauderer <christian.maude...@embedded-brains.de> wrote: > > On 29/07/2019 22:11, Gedare Bloom wrote: > > We had a GSoC project about GPIO API implemented for RPi. > > > > https://devel.rtems.org/wiki/GSoC/2013/Raspberry_Pi_BSP_Peripherals > > Hello Gedare, > > thanks for the hint. It seems that someone used at least the > <bsp/gpio.h> for BBB too (in bsps/arm/beagle/gpio/bbb-gpio.c). But it > seems that RPi and BBB are the only BSPs using the API. > > So it would be necessary to find out in what state the API is (is it > general enough to theoretically support every BSP; is the support in BBB > in a usable state) and if yes it would be worth to implement a fdt GPIO > initialization based on that API. > > I'll try to take a look at that in the next few days (most likely more > toward the weekend). Depending on the amount of work, it could be worth > to just implement it or put it in a future GSoC project. > I'm sure it could be expanded to a full project by trying to generalize it, and by mapping for example the arduino wiring APIs over it.
> Best regards > > Christian > > > > > > > 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 > > -- > -------------------------------------------- > 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
