**** BEGIN LOGGING AT Wed Feb 19 02:59:57 2020 Feb 19 03:01:01 I am asking b/c it used to work and now I cannot sign in via the touch screen any longer. Feb 19 03:23:03 check the change log to see if they broke the touch screen part. Does the LCD work? Feb 19 03:28:25 It turns on but I cannot sign in via the touch screen panel any longer. Feb 19 03:29:06 Where is the change log or what is the change log? Feb 19 03:29:49 On github? Feb 19 03:30:09 Or for Debian? Feb 19 03:30:54 for Overlays? Feb 19 03:48:59 Forget about it. Feb 19 03:49:04 Sorry to harass this room. Feb 19 03:49:21 I actually just remembered something that is needed. Please do not ask. Feb 19 03:52:04 set_ heh will to err is human :D Feb 19 03:52:52 Yep. I just remembered something about this cape. Feb 19 03:56:01 reminds me I need to find the "third LCD" ahem... Feb 19 03:56:10 Find and you shall seek! Feb 19 04:00:47 The servo is giving me troubles again. Gosh. Once it worked and now it chooses to make a light humming noise. Feb 19 04:03:53 set_ ask yourself "what changed?' Feb 19 04:19:23 It could be that I am using the USB connect for power right now instead of the battery. Feb 19 04:27:10 I also forgot this thing moves in the opposite direction from what you would "think." Feb 19 04:27:28 90 closed and 0 is open. Feb 19 04:29:10 and 45 is MOOving ;) Feb 19 04:32:41 Yep. I have 45 moving. Feb 19 04:33:21 I have all "normal" angles for the servo 2 and servo 6. Then, servo 1, handles the Gripper. Feb 19 04:34:26 I was going to put some flags on servo 2 and 6 but finding small flags is a task in itself. Feb 19 04:35:36 I have this small metal bender and a small brake for bending thin metals. I am going to make some funny stuff for my BBB. Feb 19 04:47:52 Well be patient, as you might guess people don't know everything. Reality is cruel that you can't look at a piece of paper and know enough to make a good decision. However knowing that's not possible probably is a good thing. Feb 19 05:00:28 Yeppers. Learning! Feb 19 09:47:05 Hi! Is there someway to change the behavior of the power button? I would like to force the user to hold it for 2 secs instead of the instant default behavior. Feb 19 11:01:50 Linus_SWE: short-pressing the power button just generates an input event that's interpreted by ... something, not sure what actually Feb 19 11:02:01 at least that's what I vaguely rememeber Feb 19 11:48:31 zmatt, thanks. Ive tracked it to an acpi event that runs a script that runs "shutdown -h -P now". Feb 19 11:49:28 I need to come up with a smart way to see it the button is pressed 2 sec. But Im not sure if I get more events than just the one when its clicked Feb 19 11:50:28 Linus_SWE: try tweaking the HandlePowerKey setting in /etc/systemd/loginctl.conf to prevent the shutdown, and use e.g. evtest to see if you can obtain down and up events from the relevant input device Feb 19 11:51:26 zmatt, Thanks! Feb 19 12:08:15 zmatt, It worked! :) I got this output: Feb 19 12:08:18 Event: time 1582114037.302821, type 1 (EV_KEY), code 116 (KEY_POWER), value 1Event: time 1582114037.302821, -------------- SYN_REPORT ------------Event: time 1582114037.705969, type 1 (EV_KEY), code 116 (KEY_POWER), value 0Event: time 1582114037.705969, -------------- SYN_REPORT ------------ Feb 19 12:08:40 Any hints on how to autorun a script on this? :) Feb 19 12:09:51 since what you want is more complicated than merely running something on keypress, it may require a custom daemon that monitors the device... but maybe there's something already out there you can use, you'd need to look around Feb 19 12:11:05 ok, thanks. I was hoping for something like udev for this but Ill have a look. Feb 19 12:11:33 udev isn't going to help you measure out a button being pressed for two seconds Feb 19 12:11:42 or do anything with button presses in the first place really ;) Feb 19 12:12:33 no, I know. But I wanted something similiar to udev :). But given the logic needed Ill probably need to write a daemon. Feb 19 12:13:15 I don't exclude the possibility that there are daemons designed to execute commands on input events in such a way, but like I said you'd need to look around Feb 19 12:13:26 will do Feb 19 12:14:53 a daemon for just your specific use case also wouldn't be very hard to write... it can probably a 10-line perl or python script Feb 19 12:16:29 see e.g. https://python-evdev.readthedocs.io/en/latest/usage.html Feb 19 12:26:10 Thanks! Feb 19 15:21:49 I am trying to debug gpio omap, so I changed it to a module in an attempt to be able to unload and load after I compiled new version. Very odd behavior resulted. The BBB booted from the new kernel on the SD card but the eMMC got mounted as the rootfs. Feb 19 15:22:01 Anyone ever see behavior like that? Thanks, Drew Feb 19 15:23:04 (the reason I am working on omap gpio driver is to add pull-up/down flags now that gpiolib has an ioctl() that supports that... this will allow userspace libraries to controll pull-up/down bias on gpio lines) Feb 19 15:28:21 the sd card device wasn't able to probe early because it needs the card detect gpio Feb 19 15:29:25 and the kernel lacks stable mmcblk device numbering because the maintainer is a jerk and decreed that because he doesn't have stable device numbering on his PC, nobody else is allowed to have stable device numbering either Feb 19 15:29:46 so eMMC ended up mmcblk0, and got mounted as rootfs Feb 19 15:29:48 that's my guess anyway Feb 19 15:33:42 I thought mmcblk stability had been fixed, but most likely it fixed only half the problem: i.e. it made sure mmc host N produces mmcblkN, but it doesn't ensure stable numbering of mmc hosts Feb 19 15:34:03 which you won't ever notice for platform devices, except when one gets an EPROBE_DEFER Feb 19 15:37:41 pdp7: one workaround might be to compile the omap_hsmmc driver as module as well. you'll be forced to use initramfs (but that's probably already true if you compile gpio support as module). hopefully the gpio module gets loaded before omap_hsmmc and the prpblem will go away Feb 19 15:38:04 pdp7: what you're doing sounds questionable though. on TI SoCs, pull-up/down is managed by pinctrl, not by the gpio module Feb 19 15:38:42 ah ok... thanks for the insights Feb 19 15:39:03 I was trying to add support for pup/down as libgpiod now supports it https://microhobby.com.br/blog/2020/02/02/new-linux-kernel-5-5-new-interfaces-in-gpiolib/?fbclid=IwAR2-dgxRRQN4R65MfL9RBHBphJH8nRNzqkUpf2BGa0ympG4v7NFntsDJ1nE Feb 19 15:39:13 ick, sorry for the fbclid Feb 19 15:39:16 it doesn't make sense on TI SoCs Feb 19 15:39:24 https://microhobby.com.br/blog/2020/02/02/new-linux-kernel-5-5-new-interfaces-in-gpiolib/ Feb 19 15:39:28 ah ok Feb 19 15:39:33 it makes sense on other devices where pull-up/down is managed by the gpio module, but Ti SoCs aren't among those Feb 19 15:40:11 good to know. I was looking at the https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/bcm/pinctrl-bcm2835.c which is a combined gpio+pinctrl driver Feb 19 15:40:14 userspace can already control pull-up/down via the pinmux helper devices if they want to (but that's almost never the case) Feb 19 15:41:55 that is a good point. I guess I was trying to figure an upstream way to support pull-up/down Feb 19 15:42:19 almost always you want pull-up/down to be configured statically as part of your pin configuration Feb 19 15:42:48 and misconfiguring them can cause hardware damage in the long term (if it results in IOs to be floating at intermediate levels between logic-low and logic-high) Feb 19 15:43:26 so the "upstream" way is simply by using DT Feb 19 15:45:13 that reminds me I should probably still try to explain to the guys responsible for the new gpio chardev that it sucks and isn't even remotely suitable as replacement for the sysfs interface Feb 19 15:45:52 you mean Linus W? Feb 19 15:46:03 I guess so Feb 19 15:49:06 like, until I can declare named gpios in DT, along with their initial state and usage constraints like https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi and get individually access-controllable devices or sysfs attributes with named symlinks (using an udev rule) like https://pastebin.com/raw/YKW7Wcqu ... it's not a good replacement Feb 19 15:51:04 what does gpio-demo.dtsi require in terms of drivers? Feb 19 15:51:50 gpio-of-helper, which is a tiny out-of-tree driver (part of every beaglebone kernel) that requests gpios based on DT declaration and exports them via sysfs Feb 19 15:52:21 (iirc that driver could use some cleanup, but eh it works) Feb 19 15:52:52 the sysfs-exporting is part of mainline, I think the driver just needs to ask for it Feb 19 15:53:33 also beaglebone kernels have a few minor patches (by me) that enhance the sysfs gpio interface sligtly, e.g. by adding a label attribute Feb 19 15:54:47 at least I assume it's still part of every beaglebone kernel, haven't used a -ti kernel in a while Feb 19 15:55:58 maybe they're even upstream? I'm honestly not sure, it's been a long time Feb 19 15:59:02 zmatt: I did manage to talk to Linus Walleij (gpio and pinctrl maintainer) at a conference last year about how we could ever handle thing like pinmux helper upstream. Feb 19 15:59:02 He said it might be acceptable to add debugfs to the pinctrl-single driver to allow user space to change pinmux settings. Feb 19 15:59:02 what do you think of that approach? Feb 19 15:59:34 ah found it, the gpio-sysfs improvements and gpio-of-helper driver are both part of patches/drivers/ti/gpio/0001-BeagleBone-pinmux-helper.patch ... even though they are three independent patches (sysfs-gpio improvements and gpio-of-helper are independent, and bone-pinmux-helper has nothing to do with gpio in the first place) Feb 19 16:00:36 debugfs is not really meant for normal application use... but I may be the wrong person to ask since I personally think pinmux-helper is an ugly hack Feb 19 16:00:50 I use proper DTs for all our products Feb 19 16:02:49 for pinmux-helper it *is* important that the helper devices are declared in DT, so you have a named device and a selection of states that are again declared in DT Feb 19 16:03:12 ok, yes, DT makes sense for using in a product... but what about rapid prototyping? I see a lot of people getting confused by DT on the Beagle and 'config-pin' which uses the pinmux helper is much easier for them to prototype Feb 19 16:03:26 allowing (let alone forcing) userspace to directly manipulate pinctrl sounds like a bad idea Feb 19 16:03:36 I understand why this hack is useful for new users Feb 19 16:04:03 I personally have no trouble making quick DTs for experiments, but I understand that's not true for everyone Feb 19 16:04:11 I've been thinking about if there is any way to get it supported upstream, especially in light of DT overlays probably never being supported upstream Feb 19 16:04:26 DT overlays are handled by u-boot nowadays Feb 19 16:04:29 Yeah, it is mostly a pain point for people new to embedded linux Feb 19 16:04:36 yeah, which is nice Feb 19 16:04:41 but does require reboot Feb 19 16:05:07 rebooting doesn't need to be painful... https://liktaanjeneus.nl/boot.svg Feb 19 16:05:07 :P Feb 19 16:05:08 so, for example, a python library can't change pinmux at runtime Feb 19 16:05:23 right, but when exactly do you need that? Feb 19 16:05:41 generally speaking, the hardware attached also doesn't change at runtime Feb 19 16:05:49 very nice bootup... that is the systemd analyze command? Feb 19 16:05:52 yes Feb 19 16:06:22 maybe it is a not a strong use case... I do see people breadboarding for example and using the python library Feb 19 16:06:29 this is solved by pinmux helper currently Feb 19 16:06:49 but it feels like there should be some upstream way of doing it Feb 19 16:06:52 that use case could be handled by tools that make it easy to customize your DT and a quick reboot Feb 19 16:07:01 thta is a good point Feb 19 16:07:18 I mean, not everything has to be upstream... rapid prototyping isn't really a concern for linux systems in general, just very very specific ones Feb 19 16:07:26 that is true Feb 19 16:07:40 so maybe it is ok to have a downstream "value add" Feb 19 16:07:55 for these use cases like breadboarding Feb 19 16:07:57 you know what would be a really nice way to handle switching though, including avoiding having every driver active at the same time (which is what happens currently) Feb 19 16:08:12 but you do give me the idea that an overlay config tool would be useful Feb 19 16:08:29 a special kind of platform bus that allows userspace to control which of its immediate children is attached to the bus Feb 19 16:08:38 > every driver active at the same time (which is what happens currently) Feb 19 16:08:38 yes, that is a good criticism Feb 19 16:08:52 so you effectively hotplug the platform devices, and then pinctrl will take care of the pinmux switching Feb 19 16:09:36 very interesting... maybe a way to acheive something similar to the capemanager Feb 19 16:09:54 through a different mechanism Feb 19 16:10:24 yes, it will mean those platform devices will have to learn to cope with being hotplugged (or, especially, hot-unplugged)... but that's definitely a more "correct" way to do things than change pinmux behind the driver's back and hope it doesn't notice Feb 19 16:10:29 this is a reason that jkridner[m] and a GSoC student had been looking at greybus at it can add devices at runtime Feb 19 16:10:38 which is what pinmux-helper currently does Feb 19 16:11:03 I think one case for "hotplug" is plugging sensors through these JST style connectors like seeed grove connector Feb 19 16:11:33 > change pinmux behind the driver's back and hope it doesn't notice Feb 19 16:11:33 yes, that does sound bad when you put it that way Feb 19 16:13:29 btw, re: the Linux 5.5 userspace ABI change for gpiolib Feb 19 16:13:29 https://github.com/torvalds/linux/blob/master/Documentation/driver-api/gpio/using-gpio.rst Feb 19 16:13:38 that was just added Feb 19 16:22:11 this doesn't really seem to say anything Feb 19 16:22:31 and I very much disagree with the "gpio is not for userspace" bullshit Feb 19 16:22:47 (although I agree that the gpio chardev interface isn't, but that's just because that API sucks) Feb 19 16:23:44 often enough in embedded applications you do have application-specific digital signals that need to be monitored or controlled by userspace Feb 19 16:23:56 with no particular kernel abstraction making sense Feb 19 16:25:04 I agree with "They should not have a natural fit to any existing kernel subsystem and not be a good fit for an operating system, because of not being reusable or abstract enough, or involving a lot of non computer hardware related policy." Feb 19 16:25:45 but the "one-off deployments" "specialized equipment that is not produced by the numbers, requiring operators to have a deep knowledge of the equipment" is nonsense Feb 19 16:26:05 the software using the gpios needs deep knowledge of the equipment Feb 19 16:26:10 not the operators of the device Feb 19 16:26:26 nor do increased production volumes mean that suddenly a different API makes esnse Feb 19 16:29:26 but this is why the sysfs gpio interface (enhanced by the patches in the beaglebone kernels, and in combination with the gpio-of-helper driver) is excellent: the kernel provides access control and usage limitation (i.e. making sure userspace can't change an input to be an output unless explicitly permitted by the declaration), the gpios themselves can be declared in DT (which is where board-specific ... Feb 19 16:29:32 ...knowledge belongs), and userspace doesn't nede to know what pin or gpio number the "enable-foo" signal is Feb 19 16:31:43 that last point has already proven very valuable for us: a recent revision of our PCB moved nearly every gpio to different pins (in some cases even from an i2c gpio expander to direct am335x gpios) since the pins they used to use were needed for other purposes (i.e. specific functionality offered only on those pins, as opposed to gpio which is available everywhere) ... I just updated the DT to reflect ... Feb 19 16:31:49 ...this, and userspace software didn't even need to know anything was moved at all Feb 19 16:41:42 > often enough in embedded applications you do have application-specific digital signals that need to be monitored or controlled by userspace Feb 19 16:41:53 what type of devices do that? Feb 19 16:42:13 trying to understand the use case better Feb 19 16:42:33 > that last point has already proven very valuable for us: a recent revision of our PCB Feb 19 16:42:33 curious, what type of product is it? Feb 19 16:44:03 most do... let's be real, the sysfs led interface is a dressed-up gpio interface. using gpio-keys is also just a different API (that mey be less convenient or more convenient depending on the situation) but doesn't inherently change what you're doing Feb 19 16:44:20 we also have things that need to enable/disable pumps, switch valves, etc Feb 19 16:44:35 reset external ICs Feb 19 16:44:43 or power them up/down Feb 19 16:44:59 control configuration inputs to external ICs Feb 19 16:45:16 based on runtime state known to a userspace daemon Feb 19 16:45:25 there are as many examples as there are applications Feb 19 16:45:46 interesting, so a kernel driver is not appropriate in those instances? Feb 19 16:46:07 (because the userspace app just need to set lines) Feb 19 16:46:32 there's always a kernel driver, but the sysfs gpio interface used in the way I explained/showed above provides the optimal abstraction in many cases in my opinion Feb 19 16:47:56 it lets the kernel enforce security and protect the hardware from damage, it lets DT declare the hardware to the kernel to the level of detail necessary to have it perform its task, and it gives userspace the abstraction of being able to produce or consume digital signals by name without having to know the physical details (including even whether they're active-low or active-high) Feb 19 16:49:55 > it gives userspace the abstraction of being able to produce or consume digital signals by name without having to know the physical details (including even whether they're active-low or active-high) Feb 19 16:49:55 is this because you have those labels created in /dev/gpio/ through udev? Feb 19 16:50:09 yes, which are obtained from DT Feb 19 16:50:52 those udev rules are very nice. I was not aware that could be done until Robert Nelson pointed me to it Feb 19 16:52:23 i was running into issues with spidev enumeration changing between kernel version, /dev/spidev0 becoming /dev/spidev1 Feb 19 16:52:23 he added rules based what you had done, to make it consistent /dev/spi/x.y Feb 19 16:52:33 so DT ultimately declares for each gpio: 1. the name 2. the associated gpio reference (including whether it's active-low or active-high) 3. whether they are (initially) input or output, and if output whether they are initially low or high 4. whether userspace is allowed to change the direction Feb 19 16:52:58 yep that was my suggestion, because fixing the spidev numbering was not an option due to breaking backwards compatibility Feb 19 16:53:44 in our applications I add named symlinks based on what device is actually attached, rather than information about the physical port Feb 19 16:53:59 again so we can move devices around on pcb revisions without userspace knowing or caring Feb 19 16:54:16 that's the benefit of making real DTs for your hardware :) Feb 19 16:54:30 very nice Feb 19 16:54:34 what type of hardware is it? Feb 19 16:55:32 https://dutchdutch.com/ (the stuff about valves and pumps was about https://www.hamwells.com/ for which I did some work a while back) Feb 19 16:56:15 (I think they're actually controlled by a PLC on those, not directly by the beaglebone, but the example still stands if they had been controlled by the beaglebone) Feb 19 16:57:14 ok, thanks, that is good to better understand the applications Feb 19 16:57:42 re: pull-up/down, about a year, this was added to allow DT to set pull-up/down on a gpio line Feb 19 16:57:42 https://lkml.org/lkml/2019/2/7/584 Feb 19 16:57:47 but obviously tons of "embedded" applications will have application-specific hardware interfaced to application-specific userspace software Feb 19 16:57:52 what do you think about that capability? Feb 19 16:58:04 you basically just want to connect a physical signal to your userspace application Feb 19 16:58:08 most of the time Feb 19 16:58:24 ah ok Feb 19 16:58:42 shoving application-specific code into the kernel does not improve anyone's life. it will just make your system less stable and harder to maintain. Feb 19 16:58:58 obscure drivers are often already most iffy and unstable parts of the kernel Feb 19 17:00:32 I think it would be a great idea to replace obscure poorly-tested platform drivers like the eqep drivers by the uio_pdrv_genirq driver (giving userspace access to the registers and irqs) and support the peripheral using userspace code Feb 19 17:02:05 as long as the peripheral is not privileged (not a bus master) and can't really be shared by multiple userspace applications, I don't see how using a kernel driver instead of a userspace driver improved anyone's quality of life Feb 19 17:02:45 pdp7: I'm not sure what you're linking to, but the commit seems to describe it quite well Feb 19 17:03:33 pdp7: like I said however, it doesn't apply to the gpio controllers on TI SoCs (at least omap-derived ones, I'm unfamiliar with the keystone gpio controller) Feb 19 17:04:06 right, because this is only for simple GPIO controllers Feb 19 17:04:21 no, it's for gpio controllers that have control over pull-up/down Feb 19 17:04:30 which is typically the case when the gpio controller is also the pinmux controller Feb 19 17:04:52 but on TI SoCs these are completely separate, and pull-up/down is part of the pinmux controller, not the gpio controllers Feb 19 17:05:00 ah ok Feb 19 17:05:32 the gpio controllers are just peripherals like any other, and gpio is just one possible function of a pin like any other Feb 19 17:05:40 some pins on some SoCs don't even have a gpio mode at all Feb 19 17:06:49 (in fact the fact that the AM335x has a 1:1 relation between gpios and reconfigurable digital pins is usual among TI SoCs, not the norm) Feb 19 17:07:32 * zmatt . o O ( ew... "in fact the fact..." ... I should have looked at that sentence for longer before pressing enter ) Feb 19 17:07:54 :) Feb 19 17:07:58 thank you for all the insights Feb 19 17:08:41 and I see now that only interaction between gpio-omap.c and pinctrl is in https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpio-omap.c#L895 which is for debounce Feb 19 17:10:16 maybe that's for some older chips? on current ones, debounce is part of the gpio controller, not the pinmux controller Feb 19 17:10:48 oh never mind, it's not using pinmux, it's just converting flags Feb 19 17:10:59 I think Feb 19 17:12:15 yeah, pinconf_to_config_param and pinconf_to_config_argument just splits an u32 into two fields: https://elixir.bootlin.com/linux/latest/source/include/linux/pinctrl/pinconf-generic.h#L151 Feb 19 17:12:21 yeah Feb 19 17:12:35 cus it lives here https://elixir.bootlin.com/linux/latest/source/include/linux/pinctrl/pinconf-generic.h#L123 Feb 19 17:12:43 PIN_CONFIG_INPUT_DEBOUNCE, Feb 19 17:12:51 we both found it at the same time I guess ;) Feb 19 17:13:38 this does the real work https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpio-omap.c#L178 Feb 19 17:13:45 static int omap2_set_gpio_debounce Feb 19 17:14:03 writes to gpio banks Feb 19 17:14:16 so yes, as you were saying, they are completing decoupled Feb 19 17:14:33 like I said, in general they can't be coupled since there's not always a 1:1 mapping Feb 19 17:14:34 I guess the Pi is either lucky or unlucky to have pinmux and gpio in the same driver Feb 19 17:15:30 it's somewhat common among microcontrollers I think... though I don't think the two tasks are really all that much related Feb 19 17:16:28 i think your point about it making easier to edit DT is much more important one, than me trying to make it possible to do pull-up/down from python library Feb 19 17:25:24 pdp7: just as example, here's the situation for gpios on another TI SoC: https://pastebin.com/raw/9dmy6TRL Feb 19 17:25:57 (it also has a bunch of pins with no gpio mode) Feb 19 17:37:49 pdp7: and definitely, DTs don't have to be a huge chore to customize if they're modularized, written cleanly, and use nice macros and constants Feb 19 17:38:01 it doesn't help that many of the examples available are in hideous overlays Feb 19 17:41:06 with magic hex constants all over the place Feb 19 17:42:30 ideally you'd have a gui tool where you can just click on beaglebone pins and select a function, as well as list functions and show available pin options Feb 19 17:42:40 s/function/signal/g Feb 19 17:43:07 or something like that... there's a bit more to DT than just pinmux obviously Feb 19 17:46:11 thanks... yes, I think a gui tool, or even a terminal ncurses like tool, would be useful Feb 19 17:51:46 maybe node app with web interface Feb 19 17:52:04 since the beaglebone already has a webserver running anyway on the default images Feb 19 18:08:30 e Feb 19 18:27:13 > since the beaglebone already has a webserver running anyway on the default images Feb 19 18:27:13 zmatt: that is a good idea Feb 19 18:27:13 jkridner[m]: what do you about having that be a GSoC? Feb 19 18:38:33 pdp7: just so you can see an example of a real-world application-specific DT, I'll msg you a link showing a (somewhat trimmed) version of a .dts of ours (with custom syntax highlighting for clarity)... be forewarned however that it uses custom includes hence macros, constants, and base definitions may deviate from what you're used to on mainline Feb 19 18:39:01 thanks Feb 19 18:39:02 (not sharing in chat since I'm not sure if I can make it public) Feb 19 19:06:40 pdp7: I guess the main downside to the sysfs gpio interface is that it lacks the ability to bundle multiple gpios into a single multi-valued signal (for "simultaneous" sampling / update), but that's not all that often important Feb 19 19:07:47 zmatt: is it an issue if one process exports gpio through sysfs and then dies and doesn't cleanup? Feb 19 19:07:51 and it's not very fast, but again... not really important for miscellaneous control signals Feb 19 19:07:55 I thought I had see nthat complaint Feb 19 19:08:47 if you want specific cleanup actions to be performed if your application dies, make it a systemd service with an ExecStopPost action Feb 19 19:08:58 that's a good point Feb 19 19:09:13 that works for every type of cleanup action, whether it involves gpios or not Feb 19 19:09:40 there's no generic way to bring hardware interfaces to a "safe" state after an application dies, since this is usually hardware-specific Feb 19 19:16:30 for some signals on our speakers, it would be very bad if the kernel were to reset them to their default value if the service that manages them dies, since specific sequencing is necessary to avoid the risk of getting a (potentially very loud) pop Feb 19 19:18:20 while just leaving them alone and restarting the service could be completely transparent to the user (it currently mutes the speaker for a bit, but I could avoid this if I put in some effort) Feb 19 19:20:18 good to know Feb 19 19:20:40 the speakers have an am335x? Feb 19 19:21:51 oh and before someone says we should make alsa manage this: the primary audio path goes *around* linux, not *through* it. plus, it would mean I'd still have custom code responsible for it, but instead of running in userspace where code is easy to maintain and bugs have limited impact, the code would run in kernelspace where bugs will often crash the whole system, and it would mean having to deal with ... Feb 19 19:21:57 ...alsa, which is a kernel subsystem I find more obtuse than DRM even Feb 19 19:22:00 yeah, for management mostly Feb 19 19:22:15 though also for network audio streaming (in beta) Feb 19 19:24:04 I'm actually also planning to ditch ALSA entirely and have PRU control the McASP and interface via userspace via shared-memory ringbuffers, because the kernel driver is kinda meh (and fixing that again requires having to deal with alsa) and the jitter on its audio timestamps is simply atrocious Feb 19 19:24:13 *interface to userspace Feb 19 19:25:38 (and accurate timestamps are needed for synchronization of audio devices on the network.. you really don't want your left and right speaker to be out of sync) Feb 19 19:27:00 replacing ALSA by PRU should reduce the timestamp jitter by a factor of 10000 or thereabouts :D Feb 19 19:28:46 s/should reduce/reduces/ ... not sure why I phrased it as if I don't already have the data Feb 19 19:36:20 that sounds exciting Feb 19 19:36:30 > I'm actually also planning to ditch ALSA entirely and have PRU control the McASP and interface via userspace via shared-memory ringbuffers, because the kernel driver is kinda meh (and fixing that again requires having to deal with alsa) and the jitter on its audio timestamps is simply atrocious Feb 19 19:36:30 this seems similar to Bela Feb 19 19:36:49 they do audio outside of ALSA Feb 19 19:37:31 yeah no surprise there Feb 19 19:38:27 in our case... PRU would basically just be a glorified DMA controller with timestamping support, it's not exactly a difficult piece of code Feb 19 19:39:02 and McASP configuration would be handled by the same userspace daemon that currently already configures the other side of that interface (the DSP) Feb 19 19:41:44 and in the future we may want to implement low-latency streaming using AVB, which will definitely require bypassing linux entirely (since it means the audio is streamed using iirc 4000 packets per second, each containing only 12 audio samples) Feb 19 19:47:27 so AVB is handled in hardware? Feb 19 19:48:25 no my plan would be to have the packets (which end up in a separate packet queue in hardware) be consumed by PRU instead of by linux Feb 19 19:48:52 ah ok Feb 19 19:49:19 and it could then just directly write them to the McASP transmit fifo Feb 19 19:49:55 the PRU is a better handler of such trivial things than Linux since there is latency between ARM and the hardware. Feb 19 19:50:01 while userspace still consumes the timestamps to fine-tune the audio master oscillator to ensure we stay locked on it Feb 19 19:51:35 yep, it's a very simple job, but one that has pretty strict real-time requirements Feb 19 19:51:46 which is a job description that screams "PRU" Feb 19 19:59:40 True the PRU's seem to be tailor made for such simplistic tasks. Sort of like using a PIC as a IO subprocessor minus the PIC ridiculous overhead. Feb 19 20:01:05 and with access to lots of memory with quite high bandwidth and low latency (especially for write, but still not bad for read) Feb 19 22:06:31 Although a PRU can handle input ADC's with excellence the rest of the AM335x kind of fails too meet needs for simple professional audio handling. Fortunately most ADC's have built in fade control, but just handling standard equalization the ARM7 would be over tasked. Even with reduced input rate to the minimum professional quality rate (48K, 192K actually normal), it's too much to ask for a general purpose processor which has Feb 19 22:06:31 other task (more suited to it) to do. Feb 19 22:07:21 the AM335x doesn't have an ARM7 :P Feb 19 22:07:40 and it sounds like they suck as implementing DSP code using Neon Feb 19 22:07:43 *at Feb 19 22:20:40 Sorry I obviously didn't paint a proper picture for you to see, that would my fault. Feb 19 22:23:21 https://pastebin.com/raw/h5KT4zqf Feb 19 22:24:40 these are some routines I implemented in moderately optimized C with neon intrinsics Feb 19 22:25:27 for equalization one would usually use IIR filters, which require less CPU load than these FIR filters Feb 19 22:25:50 they are a tad simpler to implement (LOL) Feb 19 22:26:42 the complicated part of making an equalizer is turning user-meaningful controls into filter coefficients... but that part is not performance-critical Feb 19 22:28:27 the filter itself wouldn't be significantly more complicated than FIR filtering.. Feb 19 22:28:49 also... lol, "professional quality rate (48K, 192K actually normal)" Feb 19 22:29:14 the only people who care about 192 kHz are the "audiophile" / "high-end" crowd, not professionals Feb 19 22:30:20 the only thing you should do with it is resample to 48 kHz and move on :P Feb 19 22:31:36 (which my code does with 3.6% cpu load for stereo) Feb 19 22:35:08 (with less than ±0.01 dB ripple in the 0..20 kHz passband and more than 120 dB attenuation in the 24..96 kHz stopband) Feb 19 22:37:58 of course the AM335x isn't *great* at signal processing, it wasn't really designed for it, but it can still do a non-trivial amount of DSP if necessary Feb 19 22:38:19 you just need to implement it in a way that is mindful of the strengths and limitations of the cortex-A8 and its NEON unit Feb 19 22:39:29 use integer arithmetic. if you really really must use floating-point, use single-precision float and suitable compiler flags that allow the compiler to use neon instructions rather than VFP ones Feb 19 22:39:48 (or use neon intrinsics for everything) Feb 19 22:40:24 if you use non-neon floating point, expect abysmal performance Feb 19 22:47:15 for comparison: NEON floating-point can do two additions or two multiplies per cycle, while non-NEON floating point is 9-10 cycles for one addition, 10-12 cycles for single-precision multiply, and 11-17 cycles for a double-precision multiply. Feb 19 22:48:52 (and additional penalties for denormals, while NEON doesn't use denormals) Feb 19 22:49:47 GenTooMan: so, what part of the proper picture am I missing? :) Feb 19 22:50:24 192K <-- is used for anti-aliasing on the sample input mostly Feb 19 22:51:50 you mean ADC oversampling? that's usually much higher than 192 kHz. and the only thing you'd normally do with that data is resample it (with anti-alias filtering) to 48 kHz, which normally the ADC will do for you Feb 19 22:52:55 or if you need to do it yourself... a few % cpu load on the cortex-a8 for a very high quality filter Feb 19 22:58:43 I prefer to use AA combined with cubic for smoothing then use a decimation filter to reduce the sample rate. Bit of a digression. So nominally I was thinking 8 inputs each with a graphic equalization (IE fixed frequency points) then you have parametrics for high low and swept. 32bit samples 192K each. I thought that was quite a bit of data. Feb 19 23:00:22 at least you are talking something I can follow more :D Feb 19 23:00:56 not sure what you mean by "AA combined with cubic for smoothing" Feb 19 23:02:30 the number of sliders on a graphic equalizer doesn't really say much about computational load, that depends on the filter implementation Feb 19 23:10:00 didn't think it would but a series of filters with a lot of data slows things down. It has to be done in real time. Although I probably wasn't thinking about the neon that might have been the issue (heh). Feb 19 23:10:36 for a parametric equalizer (i.e. a biquad stack) you're looking at 5-8 multiplies per sample depending on how you implement it and whether you want 32-bit or 64-bit feedback. cortex-a8 neon can do two 32-bit multiply-accumulates (with 64-bit accumulation) per cycle, so if you manage to keep the neon pipeline busy you could do IIR filtering with 5200-8300 biquad sections for single-channel 48 kHz or ... Feb 19 23:10:42 ...650-1000 biquads for 192 kHz stereo. of course it might be tricky to keep the pipeline busy, I wouldn't be surprised if memory bandwidth is a bigger issue than cpu power Feb 19 23:12:00 Yes with 16bits that probably is the issue. Feb 19 23:12:35 I was assuming 32-bit here Feb 19 23:12:45 I don't really have numbers for 16-bit Feb 19 23:13:21 16bit wide memory LOL Feb 19 23:13:24 ohh Feb 19 23:13:26 right Feb 19 23:13:36 sorry obfuscated again :D Feb 19 23:14:21 well the filtering can obviously run mostly from cache Feb 19 23:22:14 so, I just did the math to see how close my SSRCs (which are essentially just FIR filters) manage to get to squeezing the maximum performance from the NEON unit... Feb 19 23:22:17 https://pastebin.com/raw/iEX3Tf8S Feb 19 23:22:39 they're kinda meh, but I guess okayish for C code Feb 19 23:23:25 FIR filters however are more memory-heavy than IIR filters Feb 19 23:23:37 point Feb 19 23:23:59 for every multiply I need to load 2 words from memory Feb 19 23:24:13 for the mono case Feb 19 23:24:27 for stereo it's 3 loads per 2 multiplies Feb 19 23:24:46 for octereo ... LOL Feb 19 23:24:57 so looking at those performance-numbers... I suspect neon is just waiting for data Feb 19 23:25:58 perhaps better scheduling could improve things... the performance I got was more than adequate so I didn't put in any more effort Feb 19 23:27:34 but if it can do a 224-coefficient stereo 48 kHz FIR with only 3.7% cpu load, I really don't think your 8-channel equalizer should be even remotely a problem Feb 19 23:27:54 it should barely show up in top Feb 19 23:29:30 btw you haven't clarified yet what you meant by "AA combined with cubic for smoothing then use a decimation filter" ... I'm still mystified by it Feb 19 23:31:24 AA <-- IIR filter to remove spurious cubic spline to fit the data after that (up sampling from 192K). Feb 19 23:31:25 how much latency? Feb 19 23:31:40 (is acceptable) Feb 19 23:34:10 audio applications are kind of quirky. A nominal person can detect a few ms phase error I've noticed. Feb 19 23:34:16 GenTooMan: that sentence looks like a word salad to me. the use of the words "cubic spline" in an audio context make me very nervous. and up sampling? _from_ 192 kHz? to what, for what purpose? Feb 19 23:35:07 ds2: yes that's a useful question, but more as part of the trade-offs in the filter design Feb 19 23:35:43 GenTooMan: my filters are linear phase Feb 19 23:37:36 phase error isn't measured in ms, do you mean group delay? frequency-dependent variation thereof presumably? (not an issue with linear-phase FIR, but definitely a potential concern with IIR filters) Feb 19 23:42:19 I'm still somewhat amused by the fact that the combined IIR filters in our speaker (used to equalize the natural response of the drivers and such) has a few ms negative group delay in a few places (but the magnitude is negligible at those frequencies on those channels. the group delay is pretty flat where it matters) Feb 19 23:42:22 you can get phase error a number of ways. Most common to audio is you hear the same source from two places with a propagation delay from one. Most people can detect that. Outputting a sounds that are pre recording or only inputting a sound is different. Feb 19 23:42:59 ehh hmm need to write better English (sigh) Feb 19 23:43:01 that's not called phase error though, and we were discussing filters Feb 19 23:43:43 phase error is measured in degrees Feb 19 23:44:18 filters cause delay, in a real time system it will be perceived as a phase discrepancy. Feb 19 23:44:44 okay so you're talking about the group delay of the overall system Feb 19 23:45:11 that can definitely be a concern, depending on the application. we let the use select between low-latency and linear-phase Feb 19 23:45:14 *the user Feb 19 23:45:43 :D user defined error? :D sorry that just seemed funny at the time. Feb 19 23:46:00 it just depends on the situation what matters more Feb 19 23:46:29 if you're listening to music, the overall group delay of your speakers is not very relevant, as long as it's the same for left and right Feb 19 23:46:59 in that case, getting the best quality is more important than minimizing latency Feb 19 23:47:50 If live sound it's a different mess... Feb 19 23:49:03 but indeed for some applications, minimizing latency is more important, and not being linear-phase is an acceptable sacrifice Feb 19 23:51:11 not sure how we got here though Feb 19 23:51:53 note that low-latency requires (considerably) less computation than linear-phase Feb 19 23:55:49 zmatt: FIR filters are pretty easy to do in the SGX but latency is... painful there Feb 19 23:56:12 I can believe that Feb 19 23:56:33 I think I have all the SGX stuff figured out Feb 19 23:57:23 (for data processing) Feb 19 23:58:06 does it support double-precision float, or integer FIR with 32-bit operands and 64-bit output? Feb 19 23:59:12 cool, you've been working on using SGX for general-purpose computation? Feb 20 00:00:33 no doubles Feb 20 00:00:35 zmtt: yes Feb 20 00:00:38 zmatt: yes Feb 20 00:02:00 data seen from the ARM side has to be ints, 8 bit Feb 20 00:02:18 but you are free to stack them to make 32bit inputs Feb 20 00:02:58 but everything in the SGX is mapped to a float... so 0 is 0, 255 is 1.0 Feb 20 00:03:07 oof Feb 20 00:03:15 not even 32-bit integer available? Feb 20 00:03:44 not natively but you can do A0 + A1 * 255 for 16 bits and so forth Feb 20 00:03:54 and how would you split those again? Feb 20 00:04:04 (also you mean 256, not 255 :P ) Feb 20 00:04:12 yes Feb 20 00:05:00 I guess you could use the tricks I've seen djb use for using the FPU on modern intel cpus for doing public-key crypto, but... yuck.... Feb 20 00:05:25 yes yuck but the SGX is another processor available Feb 20 00:05:32 true Feb 20 00:05:42 I personally see it as only slightly yuckier then PRU :D Feb 20 00:05:47 so how many FLOPS does it get it practice? Feb 20 00:05:55 that's the next thing to figure out Feb 20 00:06:14 DSP on PRU? that'll be great Feb 20 00:06:27 I been sorting out the GL to GLES 2.0 mapping Feb 20 00:07:03 it would be easier if the CL stuff wasn't so locked up Feb 20 00:08:35 each output pixel can be an instance of convolution Feb 20 00:08:53 and IF (needs to be measure), I can do a complete set of pixels in 1/30sec... Feb 20 00:11:03 well for long convolutions you could do the first few thousand terms on the cortex-a8 and the remainder in batches on the sgx Feb 20 00:11:38 that way you could utilize it without increasing audio latency Feb 20 00:13:27 there is room for a lot of tricks Feb 20 00:14:41 yeah the actual smart way of doing long convolutions involves using FFTs of increasingly large size for the later parts of the impulse response, but that's another story Feb 20 00:15:53 I suspect FFTs won't work well on the SGX Feb 20 00:16:06 why? Feb 20 00:16:42 not the best explanation but - Feb 20 00:17:00 each output can only depend on the inputs... the outputs can't communicate with each other Feb 20 00:17:14 fft's are a lot of data shuffling Feb 20 00:17:29 a classic DFT may work though Feb 20 00:18:16 a classic DFT is useless at large sizes, especially with single-precision float Feb 20 00:18:42 why? (let's ignore the precision issue for the time being) Feb 20 00:18:51 because of precision issues Feb 20 00:19:02 oh Feb 20 00:19:41 classic DFT has terrible accuracy when implemented with limited-precision arithmetic Feb 20 00:20:59 I suspect FFTs are best handled in a FPGA where all the datashuffling are just interconnects Feb 20 00:21:10 FFT requires no significant "shuffling" Feb 20 00:21:21 hmm? Feb 20 00:21:28 it's mostly arithmetic and highly parallelizable Feb 20 00:22:03 well I guess it depends on what you mean by shuffling Feb 20 00:22:26 let me use the term from wikipedia... my shuffling is what wipedia calls decomposition Feb 20 00:25:53 hmmm shader code to do DSP work? Feb 20 00:27:11 GenTooMan: yep Feb 20 00:27:41 almost the inverse of the OpenCL on DSP stuff ;) Feb 20 00:34:00 ds2: so, this is basically what a simple radix-2 non-recursive complex FFT looks like: https://pastebin.com/nwpJY2Di Feb 20 00:35:12 oh sorry, I renamed "x" to "data" in the argument but forgot to fix it in the actual code, lol Feb 20 00:35:22 so eh, #define x data Feb 20 00:35:23 ;) Feb 20 00:37:30 there, better: https://pastebin.com/wi3FW0cG Feb 20 00:37:41 (cfloat is complex float) Feb 20 00:41:10 anyway, I guess the indexing I do (implicitly as part of interpreting the data as multidimensional array) is the "shuffling" Feb 20 00:42:05 That might be a better use of the SGX core Feb 20 00:42:46 but surely you can have a shader render into an FBO and then use that as input to another shader without having to wait for the next vsync? I don't know much about opengl programming but I'm pretty sure that's something games do all the time Feb 20 00:43:06 multiple passes of shader effects Feb 20 00:54:56 I can't remember opengl rendering loop specifics so I can't say that's right or wrong Feb 20 00:59:16 just for completeness, here's the corresponding inverse FFT (written in the same style meant to make it easy to see what the structure is): https://pastebin.com/J21h6quS Feb 20 01:30:23 as long as you don't have to access the frame buffer in terms of pixels the FFT should work fine. Feb 20 01:50:07 you could do that but that is slow from what I have found Feb 20 01:52:51 really? that seems odd Feb 20 01:53:15 and unfortunate Feb 20 01:57:02 if it was GLES 3.x, then there are other things you can do Feb 20 02:06:28 hmm I think one could take the openGL code and test it on a PC (linux or otherwise) as long as it supported shaders and was the right shader level correct? Feb 20 02:08:22 sorry just thinking "aloud" Feb 20 02:08:32 you are forgiven Feb 20 02:11:46 GLES code, not GL **** ENDING LOGGING AT Thu Feb 20 02:59:57 2020