**** BEGIN LOGGING AT Wed Aug 15 03:00:00 2018 Aug 15 07:43:48 hi Aug 15 09:52:40 I am having trouble getting my sound to work on my custom board, it worked on my old kernel (3.13) but the new one (4.14) i took the old devicetree, but had to edit to get several things to work. the problem is i have 4 i2c devices. three of them show up the fourth (sound device) doesn't. and i can't figure out why Aug 15 09:59:14 this is my dmesg log: https://pastebin.com/gVKNJVu0 Aug 15 10:00:06 it does show a error could not find pctldev. not sure what is going wrong there. Aug 15 10:19:42 this is my devicetree currently https://pastebin.com/vrDdnwMh Aug 15 12:33:40 Hello Aug 15 13:01:09 hey all, I have some problems enabling pruss (ls /dev/uio* does not show anything) Aug 15 13:01:21 I have a question regarding EMC compliance with beaglebone. We recently found out that the beagle bone isn't complied with EMC regulations. Is that true? If yes, do you guys recommend something similar to the beagle bone, and complying with the regulations? Thank you Aug 15 13:02:30 I am able to load the pruss driver and have enable the it via uEnv.txt Aug 15 13:23:16 I have some problems enabling pruss, how can I best get help!? Aug 15 13:25:36 ask the question? Aug 15 13:28:00 @stanto thanks for the response... was able to fix it Aug 15 13:28:12 had to run sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10 Aug 15 13:28:40 My old bootloader in the eMMC is blocking u-boot overlays Aug 15 13:28:41 uhm now I'm confused how that enabled pruss when it looks like you're zeroing the sdcard :) Aug 15 13:28:47 ah ok Aug 15 13:29:00 https://github.com/beagleboard/bb.org-overlays/issues/76 Aug 15 13:29:55 there were two issues; had to add pruss to load via /etc/modules Aug 15 13:30:07 and change the bootloader ... Aug 15 16:49:46 I very much doubt the part about /etc/modules Aug 15 16:51:35 Duality: those "could not find pctldev" messages are usually harmless warnings Aug 15 16:54:54 Duality: so your problem is that your tas5727 device is not showing up in /sys/bus/i2c/devices ? Aug 15 16:57:48 or, no, probably it shows up but without a driver Aug 15 16:58:27 I'm not seeing any tas5727 driver in sound/soc/codecs/ Aug 15 17:01:31 it has tas5720 driver (which matches ti,tas5720) and a tas571x driver (which matches ti,tas5711 ti,tas5717 ti,tas5719 ti,tas5721) Aug 15 17:08:16 I'm not seeing any sound/soc/codecs/tas* driver in the latest 3.8-bone kernel though, did you perhaps add a custom driver for it and forgot about it? Aug 15 17:11:44 my suggestion would be to see if the tas5727 is similar enough to either the tas5720 or tas571x/tas5721 to allow adding support for it to one of those two existing drivers (and if it works, send a patch upstream) Aug 15 17:12:56 and then you'll need to fill in the details of your /sound node in DT to actually get working audio of course Aug 15 21:08:31 zmatt: hi there. have you continued to use the perf_event interface? I'm trying to measure performance while using the OpenMP interface and I'm getting wacky results. Aug 15 21:18:07 I've not encountered any issues with perf myself Aug 15 21:21:50 maybe I'm setting the event structure wrong or the omp pragma options. I've a FOR loop I want to measure with and w/o OpenMP. I measure the number of instructions and I get consistent results. When I turn on openMP, I get 10x the number of instructions. Aug 15 21:23:02 Here is the sample code I'm using: https://pastebin.com/DCVfaPyX Aug 15 21:25:05 I'm using perf_event in fmult() function. Aug 15 21:26:00 I used some of the code in https://github.com/deater/perf_event_tests for my sample code. Aug 15 21:29:30 when using pastebin, please set the syntax highlighting correctly for readability Aug 15 21:32:13 the measurement you're doing includes all openmp overhead. are you sure the result is actually wrong? try a few different values for the number of loop iterations in fmult() and see how the number of instructions scales with that Aug 15 21:33:19 but I have no experience with using perf in multithreaded applications myself, so I don't know the correct procedure for it Aug 15 21:39:20 btw, as a habit you should pass PERF_FLAG_FD_CLOEXEC as flag to perf_event_open() to ensure the close-on-exec flag gets set on the file descriptor Aug 15 21:40:48 sorry about that. I was following test code in the perf_events_tests repository (operf_event_tests/tests/openmp/penmp_test.c) and it starts the counter before the openmp threads fork. The results seem wrong, in the beagleboard x15 the for loop takes about 72k instructions w/o openmp and after turning it on it jumps to a range of 100k to 1000k instructions. On an Intel computer is about 64k without, and about 95k with openmp. Aug 15 21:42:25 that does sound like an excessively large number of instructions Aug 15 21:51:15 it's very puzzling. the counters give consistent results when single threaded, but it's wacky when I try to parallelize the FOR loop. Aug 15 21:58:54 isn't it wrong to use "nowait" here on the for-loop? Aug 15 21:59:13 or is it irrelevant in this case? Aug 15 22:00:19 I guess it doesn't matter because the end of the parallel-block will join anyway Aug 15 22:03:49 I don't think it does, since there is only one FOR loop. Aug 15 22:04:33 yeah, never mind me.. I'm just learning about openmp as I go :) Aug 15 22:08:42 the perf_event_tests/tests/openmp/openmp_test.c sample code, gives the supposedly correct result, but they don't split the FOR loop across the threads. They get their expected result. Aug 15 22:10:21 my code just gives numbers all over the place, something is wrong there. Aug 15 22:12:38 just to be clear, the monotonic time elapsed as measured using clock_gettime() does not yield spuriously large values? Aug 15 22:18:44 they correlate with the instruction count. The min/max intervals scale with the number of instructions, roughly, with openmp. In single thread the intervals are sensible. I don't see an odd behavior there. Aug 15 22:19:17 it that correlates with the instruction count then it sounds like perf is working perfectly fine, openmp is just being bizarrely slow Aug 15 22:19:21 *if that... Aug 15 22:31:21 good point. It may be an openmp issue in the beagleboard. On an intel computer, the counter values are not as wild. In fact the execution time is about half the single threaded version. It's not great, since I have 8 cores. Aug 16 00:50:49 raffo: the perf commandline utils may be able to help identify where it's spending so much time **** ENDING LOGGING AT Thu Aug 16 03:00:00 2018