**** BEGIN LOGGING AT Thu Mar 19 03:00:02 2020 Mar 19 18:28:53 AM5729 is the DRA7x-something.... not sure which one.... same chip, to different market. Mar 19 18:29:30 indeed the pin header shouldn't be part of that.... that is for the chip, not the board. Mar 19 18:30:19 are the pin headers really defined in there anywhere? just because the GPIO "chips" might be, we can add the labels at another place. Mar 19 18:30:27 lorforlinux: ^^^ Mar 19 18:40:39 those are the chip pins, not the board pins. Mar 19 18:41:04 In a device tree, you can reference those symbols and add data to those entries. Mar 19 18:44:31 * jkridner[m] tries to remember where gpio labels are defined. Mar 19 18:44:35 seems like they aren't. Mar 19 18:49:55 I don't know if it needs to go in -univ. Mar 19 18:50:09 * jkridner[m] looks around for a template. Mar 19 18:50:33 line-name.... Mar 19 18:52:26 where is it for PocketBeagle, which was done a bit cleaner after we knew about this. Mar 19 18:53:08 http://paste.debian.net/1135629/ Mar 19 18:55:26 gpio-name assignments: https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti/src/arm/am335x-pocketbeagle.dts#L1888-L2200 Mar 19 18:55:51 lorforlinux: yes, that one was for PocketBeagle, which I think is mostly done right.... you can find the GPIO using the pin header assignment. Mar 19 18:57:15 https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/a17997ebcf37843efc5a7f79eac13c6709f0be32 Mar 19 18:57:55 so, the line names on AM335x are there based on the SoC.... need the same for AM5729x. I suppose that's what you were talking about. Mar 19 18:58:45 For the gpio-names, those happen at the board level and those are where you get the header pin assignments.... and those seem to be mostly empty. Mar 19 18:58:55 seems like on PocketBeagle, they were assigned using gpio-helper. Mar 19 18:59:17 Although pinmux-helper won't work on am5729, I suppose gpio-helper should. Mar 19 18:59:32 jkridner (@jkridner:matrix.org): Regarding mikroBus project, would it be okay to divide it into two parts : Mar 19 18:59:32 1. Writing a parser for the data read from EEPROM Mar 19 18:59:32 2. Writing logic for that data to go into platform data structures Mar 19 19:00:32 hmmm.... gpio-of-helper..... might not work on am5729. :-/ Mar 19 19:01:19 I see where the assignments are now for BeagleBone: https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/4d447957cb8271920becf9d0025a2b10fa5965dd/src/arm/am335x-bone-common-univ.dtsi#L2453-L2948 Mar 19 19:01:24 er, am3358 beaglebone Mar 19 19:03:20 ymdatta: I don't know that it is the data structure in the EEPROM that should be directly used for the platform data. Rather, the data strucuture in the EEPROM identifies the Click board. If we make it a Manifest binary, we can use the Greybus tools to parse it and it has a structure for extending, so that might be good. Mar 19 19:09:21 that has mux assignments, but and some consumption of gpios for LEDs, but not gpio line-names. Mar 19 19:09:39 er, gpio-name Mar 19 19:10:11 ymdatta: look at how to define a bus in LInux. Mar 19 19:10:37 https://www.kernel.org/doc/html/latest/driver-api/driver-model/bus.html Mar 19 19:13:47 related: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.11-Serial-Bus-SERDEV Mar 19 19:15:29 The "helpers" are just drivers that Pantellis created to try to help solve gaps where there was no suitable driver. Mar 19 19:15:49 the "compatible" lines tell the device tree parsers what driver to load. Mar 19 19:16:21 https://patchwork.ozlabs.org/patch/401938/ <-- rejected in upstream Mar 19 19:25:06 jkridner: Ok, this makes a lot of sense. If we read manifest binary from EEPROM, then its the same as reading device tree from EEPROM of cape bus but without loading the tree, and using present tools to parse manifest to identify components on clickboard Mar 19 19:26:37 With the reference implementation of how this is done in greybus using manifests, i think this can be doable. Mar 19 19:38:17 jkridner (@jkridner:matrix.org): In the first half, we can work on reading mainfest blob and parsing it's information and in the second half we can test on various types of click boards (just like vaishnav had done) and make changes accordingly. Mar 19 19:39:12 Does that sound reasonable? Mar 19 20:50:29 shouldn't take that long to enable the parsing. Mar 19 20:51:31 More time would go into enabling the various device driver classes, iio, networking, drm, not sure where for GNSS/GPS, etc. **** ENDING LOGGING AT Fri Mar 20 02:59:57 2020