**** BEGIN LOGGING AT Fri Dec 10 02:59:56 2021 Dec 10 03:00:00 No issue. Dec 10 03:00:39 I am over here thinking that if I memmap my clock and timer(s), I could then set up a script to handle an end result. Dec 10 03:00:59 you can't mmap pineapple juice Dec 10 03:01:03 W/ I/O specifically, I would then use these... Dec 10 03:01:05 Fine. Dec 10 03:01:12 Fine. Dec 10 03:01:13 Fine. Dec 10 03:01:16 Okay. You win. Dec 10 03:01:25 No description in here. Dec 10 03:02:08 I am not upset but my pina collada juice should get memmapped harshly. Dec 10 03:03:29 The only reason I bring it up this late in the set_-@zmatt conundrum is that I am learning a bunch again and trying to use it for the BBB (am335x) for an end product. Dec 10 03:03:45 That is all. Dec 10 03:04:05 I should not use the libs. for this reasoning is what I am thinking. Dec 10 03:04:20 ??? Dec 10 03:04:45 GenTooMan: Where in the world are you? @zmatt is not playing nice! Dec 10 03:04:58 I just can't make any sense of what you're trying to say or ask Dec 10 03:05:08 I understand. Dec 10 03:05:11 It is me. Dec 10 03:05:29 My issues, my problems, my understandings. I cannot just describe everything well enough yet. Dec 10 03:05:44 No issue. Dec 10 03:20:37 So, I can set the system clock, this 24MHz clock source, w/out the PLLs? Dec 10 03:20:45 zoom! Dec 10 03:21:42 Or...would I have to account for the PLL of each, separate clock source outside of the main oscillator (24MHz)? Dec 10 03:22:42 you have no reason to have any sort of direct interaction with the clocks or the PLLs Dec 10 03:22:54 all of that is dealt with by the bootloader and linux Dec 10 03:23:18 there's nothing to set, nothing to "account for" Dec 10 03:23:20 Are you being serious? So, using the timers would not rely on the clock sources? Dec 10 03:23:23 Okay. Dec 10 03:24:53 Even when memory mapping hexadecimal values from the TRM for the am335x setting up of peripherals? Dec 10 03:25:08 ??????? Dec 10 03:25:31 Let me try to better articulate that idea. Dec 10 03:26:37 i'm a beginner here. so many people logged in... Dec 10 03:26:39 So, the am335x TRM is a long doc. Okay, in that TRM is a bunch of values on how to set bits and some of them have to do w/ timers, clocks, and phase-lock-loops. Dec 10 03:27:17 set_: most of the TRM is not relevant for typical users but only for kernel developers Dec 10 03:27:24 I was thinking that managing the bits in this TRM would be... Dec 10 03:27:26 Okay. Dec 10 03:27:29 No issue. Dec 10 03:27:32 anything to do with power, clock, and reset management especially Dec 10 03:28:01 Guest43: it's not uncommon on IRC to leave clients connected 24/7 Dec 10 03:28:10 Okay. Okay. I will try to refrain from chatting about power, clock, and reset management. Dec 10 03:28:47 Guest43: so the number of people in an IRC channel is not necessarily indicative of activity Dec 10 03:29:55 i got it. but i'm developing driver, too. Dec 10 03:30:12 driver for what? Dec 10 03:30:18 and app. Dec 10 03:31:05 in my case, i am using am572x Dec 10 03:31:55 so i bought idkam572x and evm... Dec 10 03:32:25 and made my own board using am572x Dec 10 03:33:11 sounds like no small task Dec 10 03:33:26 ^^ Dec 10 03:34:25 after make my own am572x board, there is no app for gpmc. Dec 10 03:34:52 pretty sure the gpmc has a kernel driver but I've never worked with it Dec 10 03:35:50 so i read datasheet. and it works well. Dec 10 03:36:47 but i think my code is not good. it is just for using. Dec 10 03:37:17 drivers/memory/omap-gpmc.c is the standard kernel driver Dec 10 03:38:12 thx. Dec 10 03:39:10 i wander which environment is better between window and linux. Dec 10 03:39:44 i am working with windows. Dec 10 03:39:50 better for what Dec 10 03:40:30 now i am developing a PLC controller. Dec 10 03:41:41 dual arm is for managing and plc(like LD), and one dsp is for ethercat, and the other dsp is for motion. Dec 10 03:42:39 development state is on going... Dec 10 03:43:14 i heard that linux is good to develop. Dec 10 03:43:53 is it really good comparing to windows environments? Dec 10 03:45:53 i 'm considering to using linux environments... Dec 10 03:46:31 it's time to go to lunch. Dec 10 03:46:47 see you ... Dec 10 05:04:52 FSM! Dec 10 16:08:42 Hi all! Dec 10 16:32:45 Hello Konsgn Dec 10 20:04:15 zmatt: my code keeps aborting Dec 10 20:04:19 lol Dec 10 20:04:33 the ring buffer fails an assertion now for some reason Dec 10 20:04:46 i will put up a paste bin Dec 10 20:05:51 let me use your code Dec 10 20:05:53 hold um Dec 10 20:06:06 on.... i am getting ring buffer is full Dec 10 20:29:28 did you end up rate limiting the qt rendering? Dec 10 21:07:15 well i am still up in the air on that Dec 10 21:07:22 so the timestamp match up Dec 10 21:07:34 but the plots seem to lag a bit not as bad as before but there is a lag Dec 10 21:07:51 i can live with that. Now I just need to be able to run for more than 3 minutes without the ring buffer blowing up Dec 10 21:08:01 i am dropping zmatts pastebin in now Dec 10 21:08:16 hopefully that fixes it but it seems I cannot process data fast enough Dec 10 21:08:31 so there probably need some optimization still. Dec 10 23:30:23 hellow anyone knows how to bind a EHRPWM1A pin to backlight driver ? Dec 10 23:31:17 you create a backlight device that references the pwm output Dec 10 23:31:39 let me find an example Dec 10 23:32:18 i will send you my DTB Dec 10 23:32:29 I hope you mean dts, not dtb Dec 10 23:33:12 dts Dec 10 23:33:15 https://pastebin.com/UdBVAfqX Dec 10 23:34:29 seems okay at first glance, have you checked the kernel log for errors? Dec 10 23:35:24 status="okay"; is redundant when declaring a new device node btw, that's only needed if you're overriding a previously declared status="disabled"; Dec 10 23:35:38 [    2.329706] pwm-backlight: probe of ocp:backlight failed with error -22 Dec 10 23:35:48 nothing immediately before that? Dec 10 23:35:53 *nothing relevant Dec 10 23:36:15 no that's the only thing Dec 10 23:37:33 -22 is -EINVAL Dec 10 23:37:35 hmm Dec 10 23:38:19 from this Dec 10 23:38:22 https://elixir.bootlin.com/linux/v5.10.23/source/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.yaml Dec 10 23:38:33 required: Dec 10 23:38:33   - compatible Dec 10 23:38:34   - pwms Dec 10 23:38:34   - power-supply Dec 10 23:38:43 please don't copy/paste multi-line stuff into chat Dec 10 23:38:58 i think i need to add power-supply Dec 10 23:39:01 okay Dec 10 23:39:05 Is there a loopback test for the /dev/spidev1.1 instance on the BBAI? Dec 10 23:39:20 metgros: yeah I see in my own code I added a reference to a dummy power supply Dec 10 23:39:29 really annoying when drivers require this Dec 10 23:39:44 can you share your code please ? Dec 10 23:41:10 just reference any existing power supply... like power-supply = <&vmmcsd_fixed>; Dec 10 23:41:35 https://pastebin.com/wQsNWJDp Dec 10 23:42:12 power-supply, not vcc-supply Dec 10 23:45:23 no luck Dec 10 23:45:47 still same problem Dec 10 23:46:08 https://pastebin.com/vixJSPHn Dec 10 23:49:04 oh actually, your pinmux block is the problem Dec 10 23:50:01 how ? Dec 10 23:50:25 use the AM33XX_PADCONF macro, not a bunch of hex constants... the kernel devs in their infinite wisdom changed the format of the pinctrl-single,pins property, relying purely on the macro to maintain "backwards compatibility" (but only on source level, not on dtb level, nor for anyone who wasn't using the AM33XX_PADCONF macro) Dec 10 23:51:04 actually, that happened somewhere in 5.x, dunno if 5.10 is already affected Dec 10 23:51:23 i'm in 5.10.23 Dec 10 23:52:05 do you have the Correction with AM33XX_PADCONF ? Dec 10 23:52:34 i copy paste the pin config from an overlay i found on the internet Dec 10 23:56:15 https://goo.gl/Jkcg0w#gid=698174264&fvid=2017068390 shows that P9.14 is named "GPMC_A2", so that should be AM33XX_PADCONF(AM335X_PIN_GPMC_A2, PIN_OUTPUT_PULLDOWN, MUX_MODE6) Dec 10 23:57:03 (note that the PIN_OUTPUT_* and PIN_INPUT_* macro names are misleading: what they mean is "input disabled" and "input enabled", it has no control over the pin's output driver) Dec 10 23:58:13 okay Dec 10 23:58:14 (when in doubt use PIN_INPUT_* since it's always safe, PIN_OUTPUT_* is basically just a tiny power consumption optimization) Dec 10 23:59:17 https://pastebin.com/qEyn0KHa Dec 10 23:59:26 testing with this Dec 11 00:00:07 you'll obviously also need to fix your lcd_ctrl_pins ... hopefully from this example it should be clear to do so, just look up the pin names in the spreadsheet I linked Dec 11 00:00:28 yes i will Dec 11 00:01:22 also, remove that master@0 block in your &i2c1, it is complete nonsense Dec 11 00:02:07 nothing about that declaration makes sense Dec 11 00:02:53 do you have a good documentation on the syntax of DTS please ? Dec 11 00:03:40 https://pastebin.com/XC8vB33d is a summary of the syntax of DTS in general Dec 11 00:04:02 (but doesn't include anything specific to any binding) Dec 11 00:04:22 thanks Dec 11 00:13:26 don't know if it is working or not Dec 11 00:13:33 but now it is saying Dec 11 00:13:41 can't parse 'enable-gpios' property of node '/backlight Dec 11 00:14:41 that's rather odd since you didn't declare any (and it's not a required property) Dec 11 00:22:04 https://pastebin.com/EtR5dUUP Dec 11 00:22:19 i corrected the lcd_ctrl_pins Dec 11 01:04:09 Is there a simple script to handle the spidev_test file instead of compiling the entire kernel? Dec 11 01:19:54 I tried to just compile the script but it is not making "waves" so far. Dec 11 01:27:30 Yay! Dec 11 01:27:48 The source has changed to mean/differ a bit. Dec 11 01:46:59 Why would OCTAL not be okay but DUAL be okay in the spidev_test.c file for testing in a loopback interface? Dec 11 01:48:05 none of dual/quad/octal are supported Dec 11 01:48:10 b/c of it not being ASCII, 8-bit/1-byte? Or is that a short? Dec 11 01:48:25 Oh. Dec 11 01:48:36 I got DUAL to work. Dec 11 01:48:41 no you didn't Dec 11 01:48:44 Oh? Dec 11 01:48:55 the hardware doesn't support it Dec 11 01:48:56 The source compiled. Dec 11 01:49:00 Oh. Dec 11 01:49:03 Got you. Dec 11 01:49:07 Hmm. Dec 11 01:49:14 What should be in its place? Dec 11 01:49:23 QUAD is out too. Okay. Dec 11 01:49:35 nothing, just the defaults Dec 11 01:49:58 spidev_test is not particularly useful anyway Dec 11 01:50:06 I compiled the source w/ the defaults and it did not work. I got the errors about OCTAL...oh. Dec 11 01:50:09 Okay. Dec 11 01:50:23 ehm, these are all commandline options passed when you run it Dec 11 01:50:28 not when it's compiled Dec 11 01:50:39 Let me show you the source. Dec 11 01:51:20 why? I know what program you're referring to Dec 11 01:52:02 B/c...: https://elixir.bootlin.com/linux/v4.19.220/source/tools/spi/spidev_test.c is the test. Dec 11 01:52:10 But... Dec 11 01:53:46 In that file, the octal is not compiling while the dual is compiling. Dec 11 01:53:55 what do you even mean by that? Dec 11 01:53:55 What does this mean? Dec 11 01:54:02 Okay. Let me show you. Dec 11 01:54:08 this is a single program, it either compiles or it doesn't Dec 11 01:54:26 I changed the source to handle what compiles due to what is on the BBAI. Dec 11 01:55:36 oh I see, the SPI_TX_OCTAL and SPI_RX_OCTAL are fairly new and not in the older headers installed on the current image Dec 11 01:55:45 if (mode & SPI_TX_QUAD) is a line to handles modes. But, when I installed the source on the BBAI, it seemed that the, right. Dec 11 01:55:49 Right. Dec 11 01:55:56 Okay. Dec 11 01:56:31 So, SPI_TX_OCTAL was not working b/c of some header files that are "out-dated". Dec 11 01:57:20 well the mode itself won't work regardless since it's not supported, but to get the code to compile you'd need a small fix of the source code to provide those constants if missing from the header Dec 11 01:57:32 Right. Dec 11 01:57:35 That is all I did. Dec 11 01:58:01 So, I was moving back in time when I thought I was moving forward. Ha. Dec 11 01:58:54 I am trying to help this person handle their /dev/spidevX.X peripherals on their BBAI but it seems hopeless right now. Dec 11 01:59:37 Mine works but this person keeps trying to use two peripherals that cannot work for his/her /dev/spidevX.X instances. Dec 11 02:00:07 set_, I'm not going to try to debug a vague issue by someone else that's being paraphrased confusingly by you Dec 11 02:00:19 I know. Dec 11 02:00:24 I just wanted to discuss it. No issue. Dec 11 02:01:08 Off to try to debug someone else's issue(s). **** ENDING LOGGING AT Sat Dec 11 02:59:56 2021