**** BEGIN LOGGING AT Sat Jul 30 02:59:58 2016 Jul 30 05:15:02 yeah I should be the one getting paid for this gsoc project Jul 30 05:15:24 :D Jul 30 05:15:57 https://plus.google.com/+MichaelWelling79/posts/aYer2fZ17TZ Jul 30 05:16:06 kidding Jul 30 06:49:10 Hi Wormo_ ds2 m_w ! Jul 30 06:49:19 Was busy for some time with college stuff Jul 30 06:49:28 so .. what i am going to do now is .. Jul 30 06:49:32 basically ... Jul 30 06:49:49 the PRU writes 44 bytes of data to the kernel and kicks it Jul 30 06:49:56 kicks == interrupts it Jul 30 06:50:07 and then the ARM knows that data is there ,... Jul 30 06:51:09 why i decided 44 bytes was .. because I was afraid that PRU0 will lag behind wrt to PRU1 if we use higher data to write Jul 30 06:53:06 but 1 kernel buffer i of 512 bytes .. appropx (probably 16 bytes of message header) Jul 30 06:53:07 So, its more than 10 times . Jul 30 06:53:07 Now I was looking into the pru-software source ... Jul 30 06:53:09 and for each rpmsg_send that we do use to transfer the message/data Jul 30 06:53:16 the source has one kick instruction Jul 30 06:53:44 what we can do is, write our own function to send this data Jul 30 06:53:55 and just use it Jul 30 06:55:07 so, this function of ours will write a total of about 512bytes of data ... with 44 bytes at once and only after ~512 bytes it will generate a kick Jul 30 06:55:29 . Jul 30 06:55:40 any comments on this ? Jul 30 06:59:51 the writing to the kernel by pru is just a memcpy ... Jul 30 07:00:51 http://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/lib/src/rpmsg_lib/pru_rpmsg.c#line111 Jul 30 07:01:22 ds2 Wormo_ m_w : aaa.... anyone ? ^^ Jul 30 07:02:31 on the side note, I did this experiment yesterday : https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/docs/interrupt_frequency_beaglescope_driver.txt Jul 30 07:03:32 it there enough time to copy the buffer over before, another round of samples comes in? Jul 30 07:04:25 is Jul 30 07:06:08 Basically there are 3 scratch pads. So, pru1 writes to bank_1 and then interrupts pru0 . pru0 transfers this to the kernel, while pru0 writes to 2nd_bank and so on.. Jul 30 07:06:12 so I think yes ... Jul 30 07:06:41 doing the pru shuffle Jul 30 07:06:45 and PRU writing speed should be pretty good, that is what beaglelogic uses Jul 30 07:07:20 though the pru uses only 44 bytes of a bank, but fw can be improved to use complete bank Jul 30 07:07:37 bank shuffle actually Jul 30 07:09:03 So the PRU copying memory will keep writing chunks until the 512 buffer is full, and then kick the main cpu? Jul 30 07:09:08 that sounds much better Jul 30 07:09:25 in anyway, even if the pru0 actually gets late, it will be like a ring buffer inside the pru, getting us the latest samples Jul 30 07:09:28 only 1/10 as many interrupts Jul 30 07:09:29 Wormo_: yes Jul 30 07:09:43 should go on with this ? Jul 30 07:09:43 that will be a good thing Jul 30 07:10:09 although, not sure it's more important than the parallel api design Jul 30 07:11:00 possible you should document this as "further improvements" and come back if you have time after more linux driver work Jul 30 07:11:01 I am confused about that too .. therefore need suggestion on this ...... worth spending one day on it ? Jul 30 07:11:26 1 day, I'd say yes... but if it's not quite done, then be brave & move on Jul 30 07:11:43 because sometimes "almost done" can take multiple days Jul 30 07:12:05 well, yes :) I remember my reports :) Jul 30 07:12:16 see that experiment ? Jul 30 07:12:19 monthes for some people Jul 30 07:12:42 and the driver is now in the main branch .. out of wip that is .. Jul 30 07:12:56 yes, good work, great to have comparison for when you do get around to the buffering improvement Jul 30 07:13:16 should i send it as an email for review ? Jul 30 07:13:51 put a link in the weekly report probably, jic23 being on vacation now right Jul 30 07:14:04 ~39 samples per interrupt at first, then it goes down at 900Ksps Jul 30 07:15:19 jic23 did review when it was in wip. and there are a few things not hindering the objective of the driver but really bad practices Jul 30 07:15:35 like freeing the resources when I am using manages allocation Jul 30 07:15:52 but that was because I saw some other drivers doing that too Jul 30 07:16:04 or probably I misunderstood those other driver Jul 30 07:16:23 m_w: the number of interrupts /second /KHz is consistent Jul 30 07:16:26 isnt it ? Jul 30 07:16:46 and honestly : I dont believe this experiment is accurate Jul 30 07:17:02 these number depend on a lot of factors Jul 30 07:17:46 I just noted down the one that were resulting in approximately equal /second /KHz rate Jul 30 07:18:57 should try with 'sleep 100' ? Jul 30 07:19:24 500000/12722 = 39.3, 800000/20486 = 39.0, 900900/25949 = 34.7 Jul 30 07:21:25 samples per interrupt is going down Jul 30 07:23:07 This should actually remain approx same. As I said these numbers are not very accurate Jul 30 07:23:22 should I try with sleep 100 ? Jul 30 07:24:48 it won't hurt, and shouldn't take too long Jul 30 07:25:11 interesting if the numbers are similar Jul 30 07:25:19 the longer the sleep the more acurate the results will be Jul 30 07:25:19 any more simple accurate way of doing this ? Jul 30 07:25:32 i tried to go with ftrace Jul 30 07:25:41 but it seemed to be bit more complex Jul 30 07:25:49 and just decided to use this .. Jul 30 07:25:56 okay .. going for sleep 100 Jul 30 07:26:09 I mean .. not me ... the test :P Jul 30 07:26:16 using a bash script to run the commands? Jul 30 07:26:19 yes, average over 100 sec is reasonable Jul 30 07:26:24 yes Jul 30 07:26:26 not ! Jul 30 07:26:33 not a bash script Jul 30 07:26:41 no? Jul 30 07:27:07 but, when I use watch -n0.1 cat /proc/interrupts .... the results look very different Jul 30 07:27:28 no = not using bash script Jul 30 07:28:11 then a one liner? Jul 30 07:29:23 cat /proc/interrupts; echo 1 > buffer/enable; sleep 100; echo 0 > buffer/enable; cat /proc/interrupts Jul 30 07:29:38 cat /proc/interrupts | tail -n 12 && echo 1 > buffer/enable && sleep 3 && echo 0 > buffer/ && cat /proc/interrupts -n 12 Jul 30 07:29:43 this exactly ^^ Jul 30 07:29:44 ues Jul 30 07:29:49 *yes Jul 30 07:30:11 *echo 0 > /buffer/enable Jul 30 07:30:32 ahh .. I think you get it .. the command there ^ Jul 30 07:30:38 okay then just bump the sleep to 100 Jul 30 07:31:32 then even longer perhaps Jul 30 07:31:51 should also direct buffer to null ? Jul 30 07:32:12 dd if=/dev/iio device of=/dev/null ? Jul 30 07:32:39 probably Jul 30 07:34:27 well I have to go to bed before I start giving out more bad advice Jul 30 07:34:39 later Jul 30 07:35:23 haha :) Jul 30 07:37:23 Wormo_: I think you must have a more interesting and elegant way of doing this ... but this is one very nice script I found and I love it Jul 30 07:37:25 https://github.com/mivanchenko/scripts/blob/master/acd_func.sh Jul 30 07:37:33 just add in bashrc Jul 30 07:37:35 and do Jul 30 07:37:37 cd -- Jul 30 07:37:53 it shows last 10 paths Jul 30 07:38:02 and choose one out of that Jul 30 07:38:53 I pushd a bunch of dirs onto my stack and use 'pushd -1' 'pushd -2' etc Jul 30 07:39:32 I think that is fancier, but 'pushd' support follows me to all the places where I work Jul 30 07:40:06 yours is fancier I mean Jul 30 07:42:12 I work on about 8 different computers for various projects, so I tend to keep relatively minimal dotfile collection, programmers who live on just one laptop tend to do more fun customizations :) Jul 30 07:44:19 Yeah .. I like fun customization ... I believe .. the a laptop should seduce you to work ;) and therefore I keep a lot of scripts and aliases and all that .. Jul 30 07:44:35 now to testing .. Jul 30 07:45:34 though I like to work anyway .. but I love my laptop . Jul 30 07:46:20 me too, not looking forward to replacing mine Jul 30 07:46:44 it may need it in the not so distant future though, getting kind of old... Jul 30 07:47:29 I run weird stuff on it, like gentoo with windowmaker and gkrellm with custom theme Jul 30 07:47:59 and xterms with screen instead of tabbed terminals Jul 30 07:50:40 Wormo_: when will the number of the interrupts will get reset to 0 ? Jul 30 07:50:53 when you reboot Jul 30 07:50:57 probably 32 bit number ? Jul 30 07:51:15 so it wont reset after too many interrupts ? Jul 30 07:51:16 I don't think you'll be running that long, right? Jul 30 07:51:31 there is a finite length yet Jul 30 07:51:33 yes Jul 30 07:51:35 100 sec ... for about 10 times .. so 10000 sec Jul 30 07:52:12 sounds far from wrapping Jul 30 07:52:22 good to think about such things though! Jul 30 08:55:31 ZeekHuge, feel free to post driver to linux-iio@vger.kernel.org once basic cleanup is done. Quiet a few active reviewers on their. Cc the ones listed in MAINTAINERS in particular Lars-Peter Clausen. Jul 30 08:55:58 really ! wow !! Jul 30 08:56:04 yes sure ! Jul 30 08:56:09 Post as an RFC though listing decencies on what is not mainlined. Jul 30 08:56:25 you leaving today ? Jul 30 08:56:37 Meh, post early, frequently is always best way. Jul 30 08:57:01 Yup though not until this afternoon. Jul 30 08:57:43 jic23: okay . Happy and safe journey ! Jul 30 08:58:32 I will be trying to get done with about 512 bytes of buffer instead of 44 bytes ... by changing the PRU code. Jul 30 08:58:40 but this will be just for today Jul 30 08:59:01 If i couldnt get it done today, it will be moved to post gsoc things Jul 30 08:59:39 and then will work on defining the APIs . Jul 30 08:59:41 Can, if it makes sense, merge monolithic driver then split up into layers later. It's less effort to only do 'final' version of driver. Jul 30 09:00:41 okay Jul 30 09:01:14 Cool on speed up attempt. Jul 30 09:01:40 Make a more impressive story if the speed up proves easy! Jul 30 09:02:04 :) yeah . Jul 30 09:15:19 Wormo_: the output 'cat /sys/kernel/debug/dynamic_debug/control ' is the kernel log related to dev_dgb() and pr_debug() ? Jul 30 09:16:41 yes shows up in dmesg when you enable them Jul 30 09:16:56 and how can i enable them in the debug ? Jul 30 09:17:06 without #define DEBUG 1 Jul 30 09:17:22 you echo things to the dynamic_debug area Jul 30 09:17:29 have to look up syntax Jul 30 09:17:44 okay. I will search that . Jul 30 09:18:00 I think the first part of what you dump is probably able to be fed in when enabling Jul 30 09:18:14 kernel/async.c:120 and so forth Jul 30 09:18:38 yep Jul 30 09:18:48 https://www.kernel.org/doc/Documentation/dynamic-debug-howto.txt Jul 30 09:19:21 right Jul 30 09:19:43 it's a very nice feature, much nicer than the #define stuff Jul 30 09:21:00 I recall you can turn on all the debug from a particular file too Jul 30 09:21:06 rather than line by line Jul 30 09:21:09 or a module Jul 30 09:21:25 echo 8 > /proc/debug/kernel/printk ? Jul 30 09:21:39 only if you want them to come out on your console Jul 30 09:22:05 sometimes it's just as well to have them go into the log buffer but not splat out all over your console Jul 30 09:22:57 (they still are captured, so you can dmesg or else use klogd to capture them to file) Jul 30 09:23:31 i tried echo 8 > /proc/debug/kernel/printk but that didnt work Jul 30 09:23:44 for pr_debug and dev_dbg Jul 30 09:24:03 * they didnt work for pr_debug and dev_dbg Jul 30 09:30:06 you're sure they got enabled with dynamic debug? Jul 30 09:30:39 the ones you're interested in Jul 30 09:36:25 okay .. so that is required too . Didnt know that .. Jul 30 09:40:37 found a bug https://github.com/ZeekHuge/BeagleScope/issues/2 Jul 30 09:42:00 what are the good freqs that were higher? Jul 30 09:43:18 892857 Hz Jul 30 09:43:25 should add this to the bug Jul 30 09:44:13 and 900900 Hz Jul 30 09:44:26 yes should Jul 30 09:44:54 should translate to number of delay instructions too Jul 30 09:48:27 that the first line of that dmesg output is the delay Jul 30 09:49:30 ok the x, y, y lines Jul 30 09:50:12 you're adding the corresponding dmesg for "good" freqs now right? Jul 30 09:52:35 yes . As it says : Frequencies higher that work Jul 30 09:53:45 you have 900000 in both not-work and work Jul 30 09:54:17 oops ... bug in the bug . Jul 30 09:54:27 heh Jul 30 09:54:44 late here (or early), bye for now Jul 30 09:55:50 Wormo_: bye ! Jul 30 17:06:21 jic23: m_w Wormo_ there ? I got the code working ! Jul 30 17:06:33 440 bytes for a single interrupt ! Jul 30 17:06:35 excellent Jul 30 17:06:43 :) Jul 30 17:06:47 nice Jul 30 17:07:28 what is the new max frequency sampling? Jul 30 17:07:43 10 times more the initial data speed ... Jul 30 17:07:45 ahh .. Jul 30 17:08:12 actually have'nt added the code into the main fw code . Jul 30 17:08:24 its in form of example Jul 30 17:11:40 m_w: Actually I found a bug in the code too Jul 30 17:12:04 which code? Jul 30 17:12:10 I was trying to resolve it, but then though that I will need a mentor for this .. Jul 30 17:12:29 main source code .. the repo Jul 30 17:12:45 https://github.com/ZeekHuge/BeagleScope/issues/2 Jul 30 17:14:41 I am getting this funny error.. Jul 30 17:14:51 #include not found Jul 30 17:15:04 compilation terminated.. Jul 30 17:15:06 any ideas? Jul 30 17:15:07 installed kernel headers ? Jul 30 17:15:33 or compiling it in the source ? Jul 30 17:15:44 kiran4399: is this building on the target? Jul 30 17:16:01 m_w: you mean kernel? Jul 30 17:16:03 no.. Jul 30 17:16:20 m_w: it was compiled on bb_blue Jul 30 17:16:23 *black Jul 30 17:16:32 kiran4399: then you probbably need kernel headers Jul 30 17:16:36 kernel 4.4.12 Jul 30 17:16:42 ZeekHuge: ok.. I'll try now.. Jul 30 17:16:54 kiran4399: https://www.zeekhuge.me/post/a_handfull_of_commands_and_scripts_to_get_started_with_beagleboneblack/ Jul 30 17:17:39 apt-get install -y linux-headers-$NEW Jul 30 17:17:42 kiran4399: ^^ Jul 30 17:18:36 apt-get install -y linux-headers-$(uname -r) Jul 30 17:19:36 m_w: any idea why that callback is behaving like this ? Jul 30 17:20:16 not sure Jul 30 17:22:24 ZeekHuge: how is your kernel driver thing going? Jul 30 17:22:50 lagging behind a lot. Jul 30 17:23:21 m_w: okay .. so the example code for increased buffer size is this https://github.com/ZeekHuge/BeagleScope/tree/wip/examples/firmware_exmples/large_buffer_example Jul 30 17:23:22 so does it stall if you comment out log_debug("callback - raw mode"); Jul 30 17:24:15 this is the callback that I have left uncommented - log_debug("callback"); Jul 30 17:24:35 and yes it does work when I comment out that log message Jul 30 17:44:11 perhaps the logging it taking too long and a subsequent call comes in before the last is finsihed Jul 30 17:47:01 m_w: and then higher frequencies ? Jul 30 17:49:12 yeah that is odd Jul 30 18:05:15 ZeekHuge, great on the larger buffers... No idea on the stall. Maybe try dropping code in callback till it works Jul 30 18:05:56 Airports are dull when with family so can't just pull out laptop and do something interesting... Jul 30 18:06:30 would want to see a proof ? that its working ? I can show it on tmate .. Jul 30 18:07:24 Any chance pru code is able to fire two interrupt handlers at once? Jul 30 18:07:48 Unlikely as that would cause all sorts of problems. Jul 30 18:07:55 yes . Jul 30 18:08:08 Nope on seeing it. On 3g on phone! Jul 30 18:08:10 and then higher frequencies shouldnt worl Jul 30 18:08:16 *work Jul 30 18:08:20 okay Jul 30 18:08:35 Maybe... Race conditions can be nasty like that. Jul 30 18:09:22 Could throw a spin lock around the push to buffer call. Jul 30 18:09:31 race condition with those particular frequencies ? Jul 30 18:10:23 Yes, interactions with scheduler can cause all sorts of ghosts when a real bug seems to go away. Jul 30 18:10:44 hmm okay, and how to chase it ? Jul 30 18:10:57 Spin lock around loop I mean not each push to buffer. Jul 30 18:10:59 spin locks that you saud ? Jul 30 18:11:03 okay Jul 30 18:11:20 Chase by first dropping push to buffer... Jul 30 18:11:33 but its not about the buffers Jul 30 18:11:37 wait a sec Jul 30 18:11:51 https://github.com/ZeekHuge/BeagleScope/issues/2#issuecomment-236364088 Jul 30 18:12:00 this is whats happening ^^ Jul 30 18:12:28 Ah I didn't read far enough. Jul 30 18:13:15 Hmm sounds like a pru related bug then. Jul 30 18:13:42 Not a clue I am afraid. Jul 30 18:13:56 okay. Jul 30 18:15:26 Maybe write a toy test case an ping the ti guys.. Jul 30 18:19:00 jic23: which mailing list? Jul 30 19:10:42 Wormo_ not sure on ml. Jul 30 19:11:09 Not done pru stuff and seems likely to be there... Jul 30 19:11:33 See how simple a toy case triggers it... Jul 30 19:11:46 ZeekHuge^ Jul 30 19:14:03 okay . Jul 30 19:14:17 I will look into it .. Jul 30 19:14:49 at present working on including that larger buffer thing in the main fw source Jul 30 19:15:21 I have only today for that . And my 'today' will end in some hours. Jul 30 19:26:47 Come back to this at later date! Jul 30 19:27:21 Will try and check in sometime in next few days. Want to know how fast it goes :) Jul 30 19:28:02 For buffer stuff pester Lars Peter Clausen if you need to. He's very friendly and very good! Jul 30 19:35:20 yep okay :) Jul 30 20:15:32 hey m_w There? **** BEGIN LOGGING AT Sun Jul 31 02:36:12 2016 **** ENDING LOGGING AT Sun Jul 31 02:59:58 2016