**** BEGIN LOGGING AT Thu Oct 17 02:59:57 2019 Oct 17 09:34:48 rcn-ee[m]: I personally prefer having only non-suffixed when there's only one choice, and only suffixed versions when there are multiple. it makes sure that I know there are multiple pins when there are, since an overlay that uses one of them should probably reserve all of them (muxing the unused ones to safe) Oct 17 09:35:51 ehh, this isn't just true for overlays of course but custom DTs as well (but even more so for overlays) Oct 17 12:02:15 rcn-ee[m]: So is this https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/pinctrl/dra.h#L469-L471 the pinmux file that config-pin complains I don't have? Oct 17 12:03:26 What does DRA stand for? Oct 17 12:11:36 Oh wait, it refers to the DRA7xx SOC with the same dual core A-15s that the AM5729 in the Beaglebone AI has. Oct 17 12:17:24 yeah, the "vayu" die and close derivatives are given part numbers AM57xx for general-purpose, DRA7xx (except DRA78x) for automotive, and TDA2 for ADAS Oct 17 12:18:33 with slightly different feature sets enabled via eFUSE Oct 17 12:19:46 confusingly, DRA78x is a part in the TDA3 / DM50x family rather than one in the DRA7xx / AM57xx / TDA2 family Oct 17 12:21:58 Gotcha, so is the bb.org-overlays/include/dt-bindings/pinctrl/dra.h file that rcn-ee[m] linked to what you were calling the pinmux helper nodes that I would need to make? Oct 17 12:22:44 it just defines some constants/macros useful for pin configuration (on the DRA7xx/AM57xx/TDA2 SoC) Oct 17 12:23:05 Sorry, I'm still trying to wrap my head around how the base device tree, device tree overlays, and the universal cape manager are related Oct 17 12:23:47 I never had to dive into the details with the BBB Oct 17 12:29:19 So it's my understanding that config-pin uses the beaglebone-universal-io which is the same thing as the universal cape overlay Oct 17 12:31:06 This overlay is loaded into a cape manager slot. However, the universal cape overlay and the cape manager only work on the BBB. Oct 17 12:32:09 For the X15/BBAI you can use overlays (not the universal overlay), but they aren't loaded using the cape manager. They are instead loaded by modifying uEnv.txt? I'm not sure... Oct 17 12:36:02 But I also see that the cape manager slots are going away to be replaced by the U-Boot overlays. Oct 17 12:41:14 hunter2018: I don't know if overlays are supported yet on the X15, I doubt it since there's no config variables for them yet in /boot/uEnv.txt Oct 17 12:42:24 but I see no obstacle to support them, it should be a simple matter of applying the relevant patches for supporting overlays (if they're not in mainline u-boot yet, not sure) and adding some code to the bootscript that loads and applies overlays based on config variables in /boot/uEnv.txt Oct 17 12:43:12 the cape manager (in the kernel) is no longer in use on beaglebones either, runtime overlays in the kernel have always been buggy, never reached mainline interest, are deprecated and will eventually go away entirely Oct 17 12:44:27 hoever they're still enabled for now, and I think you should be able to use them on the X15/AI via the configfs mechanism (with the same bugs and limitations as on the BBB) Oct 17 12:45:39 Here is the BBAI uEnv.txt after I added the dtb=am5729-beagleboneai-uio.dtb line which has your py-uio dra7-uio-pruss.dtsi file included in it. Oct 17 12:45:49 https://pastebin.com/raw/T7UTi2qj Oct 17 12:46:07 (the cape manager was a mechanism on top of that that would scan for and identify capes based on their eeprom and load their associated overlays) Oct 17 12:46:51 looks good, make sure am5729-beagleboneai-uio.dtb exists in /boot/dtbs or /boot/dtbs/$(uname -r) Oct 17 12:47:44 Yeah it does and I'm able to get the basic basic-test.py in py-uio to work so it must be configured correctly Oct 17 12:48:11 Once I can understand setting up pin modes I'll be golden :) Oct 17 12:56:23 yeah, so thanks to the erratum the only way to do pinmux setup without risk of glitches is currently in u-boot SPL, and changing that setup currently requires recompiling u-boot. I have an idea for allowing u-boot to do glitch-free pinmux setup at a later time, after it has loaded the dtb specified in /boot/uEnv.txt (and applied overlays, once supported) but that's currently just that: an idea. Oct 17 12:57:25 if the risk of glitches is not expected to be a problem for your application then you can do pinmux configuration in the DT (including overlays, once supported), which is the typical place to do pinmux Oct 17 12:58:18 if you want runtime pin configuration, you need to create appropriate pinmux helper devices (one per configurable setting) Oct 17 12:58:35 on the BBB those are created by the "universal overlay", when enabled Oct 17 13:03:17 hunter2018: for examples on how to do pinmux, there are plenty of them in am5729-beagleboneai.dts and here's a small self-contained example (to setup an spi port on the x15) I wrote: https://github.com/mvduin/dtb-rebuilder/blob/4.14-ti/x15-custom/src/arm/bbx15-spi-test.dtsi Oct 17 13:04:47 rcn-ee[m] is apparently working on making a header file with constants for the pinmux register addresses named after the beaglebone expansion header pins (which would obviously be a lot more readable than magic hex values), but until those are available you'll just have to look up the correct hex values Oct 17 13:07:08 btw, when configuring pins to pru-out mode, beware that the registers of all pru cores (both on the am335x and am572x), including R30, are never reset by hardware hence contain random values at power-on, which will get driven onto pads once you configure them to pru-out mode Oct 17 15:42:53 Thanks! Is it correct that a .dts file is a base device tree file and the .dtsi is an overlay? Or can an overlay be a .dts file too? Oct 17 16:08:52 zmatt: How would you use your py-uio/bbx15-spi-test.py? Specifically, I know it has the associated bbx15-spi-test.dtsi file, but what do you do with this file? Oct 17 16:09:37 Say I want to run the bbx15-spi-test.py on my BBAI right now, what are the steps I need to take to load bbx15-spi-test.dtsi? Oct 17 16:35:44 hunter2018: .dts is the file suffix for a file that is to be compiled by dtc, dtsi is the file suffix for a file that's included (directly or indirectly) into a dts file using the /include/ directive or the #include CPP directive Oct 17 16:36:04 so a dtsi is not a whole DT but some fragments thereof Oct 17 16:36:34 as for overlays, ideally you'd want to be able to convert a dtsi directly into an overlay, which is exactly what my overlay-utils does Oct 17 16:37:36 but in reality, overlays require the fragments to be encoded in a hideous way into another device-tree structure and this is then compiled with dtc. this is the format you see in the bb.org-overlays repository Oct 17 16:38:31 hunter2018: well my bbx15-spi-test is specifically for the bbx15, I don't know whether the same pins are available on the bbai expansion headers, I'd need to look that up Oct 17 16:39:45 That makes sense. Well, what would the steps be for the bbx15 then. I just don't understand how to "load" the .dtsi file to make pin changes during runtime. Oct 17 16:39:55 you don't Oct 17 16:40:07 you #include it into your main .dts Oct 17 16:40:48 or you'd use an overlay to have u-boot apply it to your DT, once overlays are supported in the x15/ai u-boot Oct 17 16:40:49 Ahh, I see. The same way the .dtsi file in py-uio that sets up the pru uio works Oct 17 16:41:02 yes Oct 17 16:41:37 So currently, is there a way to change a pin (say from gpio input to spi) at runtime? I think I am ok with glitches occuring. Oct 17 16:42:09 I feel like you already told me, but I didn't understand Oct 17 16:42:19 correct Oct 17 16:44:15 oh actually I guess you could use a runtime overlay, you could compile the .dtsi into an overlay with my overlay-utils (you'd just have to make sure to #include any headers that contain definitions it needs) and load it via the configfs mechanism (overlay-utils has scripts for that in the bin/ directory) but I don't recommend doing this, like I said it is and always has been buggy Oct 17 16:45:18 the better solution for runtime pinmux switching is creating pinmux-helper devices, which is also what cape-universal does on the BBB (it creates a pinmux helper for each reconfigurable pin) Oct 17 16:46:51 I have to be able to tri-state (make input) a pin while startup that later needs to become a spi pin (actively driven). So runtime configuration is necessary. I think the glitch is not a big problem. Oct 17 16:47:12 actually I have a nicer solution for that Oct 17 16:47:14 I had the same problem Oct 17 16:47:30 but unfortunately it requires a kernel patch since I've been too lazy to try to get my changes into mainline linux Oct 17 16:47:57 but it allows userspace to select the pinmux state of an uio device via an ioctl Oct 17 16:48:11 So for a linux noob like me, my best bet is probably to try and create pinmux-helper devices Oct 17 16:49:10 I guess :) or maybe rcn is willing to apply my patches, they are of generic use... I'm not sure if I've pushed the patch to github yet Oct 17 16:49:20 you'd need only one pinmux helper I think Oct 17 16:50:09 I have already added support for my patch to py-uio, just not in the master branch yet => https://github.com/mvduin/py-uio/commit/d9f1b32f03a Oct 17 16:51:39 in either case you'd define two pinmux states (on the pinmux helper device you create, or on the uio device when using my patch), 'default' and 'active' Oct 17 16:51:58 Cool! So if I figure out what a pinmux helper node is and I make one, how do I use it? Oct 17 16:51:58 where 'default' is the one selected at boot, which uses safe settings, and 'active' is the one you select later Oct 17 16:52:38 I know I gave an example of a pinmux helper already, lemme see if I can find the paste Oct 17 16:52:56 https://pastebin.com/8dwZKQei Oct 17 16:53:19 it's literally just a device with nothing but a compatible-string and pinctrl states Oct 17 16:53:55 Gotcha, and these are in the base am5729-beagleboneai.dts Oct 17 16:53:56 it's a virtual device hence / is a fine place to put it Oct 17 16:54:12 what do you mean? there are currently no pinmux helpers in the base dts Oct 17 16:54:13 I mean, they use them there right? Oct 17 16:54:43 they use pinmux obviously... pretty much anything you do in dts (other than merely switching a driver around like my uio-pruss snippet) will need to declare pinmux Oct 17 16:54:59 pinmux.. pinctrl... whatever :P Oct 17 16:55:14 it is more than just mux so I guess pinctrl is the correct word to use Oct 17 16:55:40 my spi test has two pinmux nodes as well Oct 17 16:55:43 pinctrl Oct 17 16:56:34 So the difference is that the pinmux helper has this line: Oct 17 16:56:34 compatible = "bone-pinmux-helper"; Oct 17 16:56:46 And then several profiles to switch between? Oct 17 16:57:04 Like these profiles pinctrl-names = "default", "foo", "bar"; Oct 17 16:57:23 yes, a pinmux helper is a device that just exists for pinctrl... the actual pinctrl properties are the same as those you'd put in any other device (normally you attach pinctrl nodes to the device for which they're needed) Oct 17 16:58:04 multiple pinctrl states are also supported anywhere, but usually only the "default" state is used Oct 17 16:59:07 Gotcha, so I put the pinmux helper node like this one https://pastebin.com/8dwZKQei into my base device tree Oct 17 16:59:41 Then the bone-pinmux-helper driver reads through the dts and looks for the helper node Oct 17 16:59:48 yep... the name of the node doesn't matter as long as it doesn't conflict with any other top-level nodes.. and it'll show up in the sysfs path Oct 17 16:59:54 labelled by the compatible = "bone-pinmux-helper"; line Oct 17 16:59:54 no Oct 17 17:00:28 other way around: the kernel finds the node in DT, reads the compatible-string(s), and tries to find a matching driver for it Oct 17 17:00:54 Ok it's starting to make sense :) Oct 17 17:01:20 So assuming I put a pinmux helper node in my device tree. How do I "activate it" Oct 17 17:01:34 That is, at runtime how do I change between different profiles? Oct 17 17:01:51 In your example "default", "foo", "bar"; Oct 17 17:02:31 write it to /sys/bus/platform/devices/my-pinmux-switch/state Oct 17 17:03:08 So echo foo > /sys/bus/platform/devices/my-pinmux-switch/state Oct 17 17:03:19 would change the pins to the foo profile? Oct 17 17:05:43 yes Oct 17 17:06:09 Wow, that actually makes sense. Thanks! Oct 17 17:06:33 Where is the documentation on this process? I've never come across this Oct 17 17:07:43 btw here's the list of predefined states: https://elixir.bootlin.com/linux/latest/source/include/linux/pinctrl/pinctrl-state.h Oct 17 17:08:38 which process? Oct 17 17:08:49 there are probably bits and pieces of documentation here and there, but I dunno Oct 17 17:09:01 Just how the bone-pinmux-helper driver works Oct 17 17:09:04 it's mostly just stuff I absorbed from various places over the years I guess :) Oct 17 17:10:35 I don't think that driver has any real documentation, other than its source code... it's easy to conclude how it works from knowing its purpose, seeing the associated device tree node (e.g. in the cape-universal overlay), and seeing how it used (by config-pin) or just noticing the sysfs entries on a BBB and wondering what they are ;) Oct 17 17:14:36 Haha, ok makes sense. So to recap, why did you make kernel patches instead of using the bone-pinmux-helper? Was it to avoid the glitch? Oct 17 17:17:33 i wanna study bbb programming. Is there any beginner tutorials that i can start with? Oct 17 17:19:17 Here is a good book for starting out and there is some info on the book's website: Oct 17 17:19:17 https://www.amazon.com/Exploring-BeagleBone-Techniques-Building-Embedded/dp/1119533163/ref=pd_sbs_14_t_0/146-7458846-8357034?_encoding=UTF8&pd_rd_i=1119533163&pd_rd_r=77ad230b-e2b9-4001-bb7e-605cb3f14966&pd_rd_w=MAsd3&pd_rd_wg=ytA6n&pf_rd_p=5cfcfe89-300f-47d2-b1ad-a4e27203a02a&pf_rd_r=0PA3YQ0B78QZ531PJVQW&psc=1&refRID=0PA3YQ0B78QZ531PJVQW Oct 17 17:20:17 hunter2018: no because bone-pinmux-helper is a hideous hack in general :) the correct thing to do in this case is to use multiple pinctrl states on the device itself. normally with a kernel driver you'd just use the "init" and "default" states, but with uio devices the real driver lives in userspace, so userspace needs a way to select the pinctrl state of uio devices, which is exactly what I ... Oct 17 17:20:23 ...implemented Oct 17 17:21:22 https://github.com/dutchanddutch/bb-kernel/blob/am33x-v4.14/patches/drivers/uio/0001-UIO-support-pinctrl-state-selection.patch Oct 17 17:22:08 rcn-ee[m]: you interesting in picking up this patch? I should probably even try to get it into mainline... I feel like it should be accepted Oct 17 17:22:13 *interested Oct 17 17:23:51 hmm I should split it into two patches, one that adds support for ioctls to uio devices, and one that implements the pinctrl ioctls Oct 17 17:24:21 also, why the bleep did I do this in uio-pdrv-genirq... it belongs in the uio core code so it can be used by all uio devices Oct 17 17:24:31 silly me Oct 17 17:25:43 hmm, I just noticed the /* XXX locking */ comments I left in the code Oct 17 17:26:22 okay forget about picking up the patch yet, I clearly never properly finished it ;) Oct 17 17:29:37 zmatt yeah, i'll gladly add it.. ;) even with bugs/issues.. Oct 17 17:30:16 well I should at least move it to the uio core so that uio-pruss can use it as well Oct 17 17:33:03 I don't think it has any bugs other than the missing locking, assuming locking is required... I think the vfs layer actually grabs a lock on the file around ioctl calls Oct 17 17:33:15 oh never mind, I use .unlocked_ioctl Oct 17 17:34:39 oh the old one is deprecated Oct 17 17:35:08 never mind, it got removed Oct 17 17:35:15 it grabbed the Big Kernel Lock, hah Oct 17 17:35:57 okay so I should definitely grab a mutex myself then Oct 17 17:37:23 hmm Oct 17 17:41:05 some existing uio code also doesn't seem to protect against races when multiple threads use the same file descriptor **** ENDING LOGGING AT Fri Oct 18 02:59:58 2019