On 30/07/2019 17:59, Gedare Bloom wrote: > 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.
I had a look at the GPIO stuff that we have. To be honest: From a quick look the API defined in bsps/include/bsp/gpio.h looks very complex for something like GPIO. It's a 1000 line file and I think it's necessary to read the documentation quite thoroughly before the API can be used. But I didn't found anything that looks like a generic pin mux setting. The only part that would have to do anything with a pin mux in the Beagle implementation of that API are two static objects in bsps/arm/beagle/gpio/bbb-gpio.c which are never used. These objects are dead code and I created a patch to remove them: https://lists.rtems.org/pipermail/devel/2019-July/026983.html So to summarize it: We don't have any pin mux handling yet. It would be worth implementing one that can parse FreeBSD / Linux device tree files. I'll have to have a look at FreeBSD how non-device-tree targets do the initialization. Maybe it would be an API that can be cloned. In that case - depending on the effort - it will be possible to decide whether that can be a future GSoC project or not. > >> 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
