**** BEGIN LOGGING AT Mon Aug 01 02:59:58 2016
Aug 01 04:38:55 <ZeekHuge> Wormo_: morning !
Aug 01 04:39:07 <ZeekHuge> ahh ... I mean .. morning (here)
Aug 01 04:40:14 <ZeekHuge> I was looking into spi.h and spi.c source ... and the definitions .. the buffer was mentioned as DMA safe
Aug 01 04:51:49 <ZeekHuge> Wormo: Hi !
Aug 01 05:08:55 <ZeekHuge> m_w: Hi !
Aug 01 06:02:01 <Wormo> hey ZeekHuge
Aug 01 06:02:18 <ZeekHuge> Hi !
Aug 01 06:02:28 <ZeekHuge> I tried to get larger buffers ..
Aug 01 06:02:40 <ZeekHuge> I made an example and it was working
Aug 01 06:02:48 <ZeekHuge> 440 bytes for a single interrupt
Aug 01 06:03:11 <ZeekHuge> but then I added that modified function in the main firmware source
Aug 01 06:03:25 <ZeekHuge> It was working, somewhat , but had errors .
Aug 01 06:03:34 <Wormo> what kind?
Aug 01 06:03:46 <ZeekHuge> okay so ..
Aug 01 06:04:24 <ZeekHuge> https://github.com/ZeekHuge/BeagleScope/blob/wip/firmware/main_pru0.c#L70
Aug 01 06:04:30 <ZeekHuge> this is the function
Aug 01 06:04:47 <ZeekHuge> now you see that 44 on 93rd line ?
Aug 01 06:05:03 <ZeekHuge> that is the size of data it should write to the kernel
Aug 01 06:05:28 <Wormo> yes
Aug 01 06:05:31 <ZeekHuge> when I am keeping it to be 44, it is actually writing 88 bytes for one interrupt
Aug 01 06:05:55 <ZeekHuge> and when I am keeping it 440, its writing 256 bytes for one interrupt
Aug 01 06:06:30 <ZeekHuge> while for the exact same function here https://github.com/ZeekHuge/BeagleScope/blob/wip/examples/firmware_exmples/large_buffer_example/main_pru1.c#L102
Aug 01 06:06:49 <ZeekHuge> it is writing exactly the number of bytes I am specifying
Aug 01 06:07:15 <ZeekHuge> the next thing that I want to ask is ..
Aug 01 06:07:20 <ZeekHuge> for #2
Aug 01 06:07:40 <ZeekHuge> while I was trying to play and find something to it the other day.
Aug 01 06:08:03 <ZeekHuge> After 2-3 freezes, when I rebooted the board
Aug 01 06:08:11 <ZeekHuge> It wasnt connecting through the USB
Aug 01 06:08:20 <ZeekHuge> I used ethernet
Aug 01 06:08:39 <ZeekHuge> and saw that none of the kernel modules were being loaded on boot
Aug 01 06:09:14 <ZeekHuge> so somehow I found that the dependency fikes
Aug 01 06:09:16 <ZeekHuge> *file
Aug 01 06:09:32 <ZeekHuge> something lile module.dep.bin ?
Aug 01 06:09:44 <ZeekHuge> was getting corrupted
Aug 01 06:10:05 <ZeekHuge> and executing depmod -a && reboot solved it
Aug 01 06:10:27 <Wormo> hard resets can be hard on fileytem
Aug 01 06:10:43 <ZeekHuge> It didnt just happened once, but 2-3 times
Aug 01 06:10:48 <ZeekHuge> *happen
Aug 01 06:11:04 <Wormo> same file?
Aug 01 06:11:28 <Wormo> did you sync after fixing with depmod
Aug 01 06:11:29 <ZeekHuge> dont know but the solution was same each time - depmod -a && reboot
Aug 01 06:11:37 <ZeekHuge> ahh .. sync ?
Aug 01 06:12:03 <Wormo> flush fixed file to storage
Aug 01 06:12:35 <Wormo> but if there was a good boot between, then that's not the explanation
Aug 01 06:12:39 <ZeekHuge> nope,. I just did exactly what i stated 'depmod -a && reboot'
Aug 01 06:13:09 <Wormo> did  it break again on next reboot I mean
Aug 01 06:13:20 <Wormo> so yu had to fix again
Aug 01 06:14:31 <Wormo> if so, the previous fix may not have "stuck" because file didn't get flushed ouot of memory before another lockup
Aug 01 06:14:40 <ZeekHuge> yes . it happened again after '2-3 freezes' caused by the #2
Aug 01 06:14:50 <ZeekHuge> sure ?
Aug 01 06:14:52 <ZeekHuge> ahh ..
Aug 01 06:15:02 <ZeekHuge> do you have a beaglebone black ?
Aug 01 06:15:06 <ZeekHuge> and some time
Aug 01 06:15:07 <ZeekHuge> ?
Aug 01 06:15:52 <ZeekHuge> can we infer that #2 is related to kernel and not the PRU fw ?
Aug 01 06:16:24 <Wormo> what would you like me to try? maybe I could do in morning if not nonw
Aug 01 06:16:26 <Wormo> now
Aug 01 06:16:57 <ZeekHuge> Further, I have, at this point in source, tagged it v0.1 and started working on parallel framework. Was reading the spi and i2c and other bus registrations and all those APIs
Aug 01 06:17:14 <Wormo> oh good
Aug 01 06:17:32 <Wormo> I have a beaglebone green btw
Aug 01 06:18:29 <ZeekHuge> sure ! whenever . Just try to reproduce #2, 2-3 times . And that may result in the module dependency error I told just about.
Aug 01 06:18:40 <ZeekHuge> Haan.. green would do.
Aug 01 06:18:52 <ZeekHuge> my kernel version is 4.4.12-ti-r31
Aug 01 06:18:58 <Wormo> I don't commit to #2 not being related to PRU fw btw, since PRU bugs have caused lockups
Aug 01 06:20:42 <ZeekHuge> and one more point, I observed that frequencies mentioned in #2 are behaving differently with and without the other terminal executing 'watch -n0.1 cat /proc/interrupts '
Aug 01 06:20:58 <Wormo> really? How so
Aug 01 06:21:28 <ZeekHuge> Well, in the 'with' case, they were not causing to freeze the board.
Aug 01 06:21:31 <ZeekHuge> ahh ..
Aug 01 06:21:34 <ZeekHuge> yeah I know
Aug 01 06:21:54 <ZeekHuge> that is weird
Aug 01 06:22:07 <ZeekHuge> and that is the reason I just stopped there ..
Aug 01 06:22:14 <Wormo> yeah
Aug 01 06:22:31 <ZeekHuge> and decided not to touch this issue again, without the help of a mentor.
Aug 01 06:22:57 <Wormo> races and corruption bugs can evidence in different ways, appear and disappear by making minor changes
Aug 01 06:23:22 <Wormo> they are a couple of hard classes of bugs because of that
Aug 01 06:23:53 <Wormo> "oh I fixed it symptom went away" when really things just didn't line up right to show the symptom
Aug 01 06:24:47 <ZeekHuge> yeah, and all this is way above my knowledge and experience. So I need help with this
Aug 01 06:24:57 <ZeekHuge> btw .. have you ever been to India ?
Aug 01 06:25:18 <ZeekHuge> and .. is this an okay point to create a release https://github.com/ZeekHuge/BeagleScope/releases
Aug 01 06:25:20 <ZeekHuge> ?
Aug 01 06:25:34 <Wormo> no, only out of my country one time, a couple weeks in europe
Aug 01 06:25:47 <Wormo> yes good idea for release
Aug 01 06:26:41 <Wormo> I'm looking at your latest comment about the callback...
Aug 01 06:27:13 <ZeekHuge> I thought that we have a complete chunk somewhat ready, and since was starting to work on parallel framework, so tag must be the right thing to mark this point .
Aug 01 06:27:30 <Wormo> agree
Aug 01 06:27:40 <Wormo> tag the release w/ iio
Aug 01 06:27:40 <ZeekHuge> link to commit message ?
Aug 01 06:27:59 <Wormo> hm?
Aug 01 06:28:32 <Wormo> are you asking about a tag commit, not sure what you're asking
Aug 01 06:28:40 <ZeekHuge> the callback commit you were saying about ..
Aug 01 06:29:12 <Wormo> I meant comment on n#2
Aug 01 06:29:20 <ZeekHuge> okay.
Aug 01 06:31:21 <Wormo> A couple months ago my other half figured out an oops that came and went during a board bootup
Aug 01 06:32:02 <ZeekHuge> bbb board ?
Aug 01 06:32:02 <Wormo> It turned out that somebody had set up the ethernet to use it during the bootloader, and didn't disable it again
Aug 01 06:32:06 <Wormo> no another TI
Aug 01 06:32:56 <Wormo> if a packet came in on the ethernet cable before kernel got around to reinitializing the ethernet, then the oops would happen
Aug 01 06:33:24 <Wormo> because the ethernet was pointed at a memory area that the kernel was using for something else
Aug 01 06:33:43 <Wormo> but no traffic during that particular window of time, no oops
Aug 01 06:33:55 <ZeekHuge> why is all this so buggy ? shouldnt it be fixed ?
Aug 01 06:34:14 <ZeekHuge> I mean .. this must be the problem in the main linux kernel
Aug 01 06:34:17 <ZeekHuge> isnt it ?
Aug 01 06:34:34 <Wormo> That was an example of something else coming in & messing with kernel memory
Aug 01 06:34:42 <Wormo> the kernel was an innocent victim, see?
Aug 01 06:35:00 <Wormo> The customized bootloader had left the ethernet running
Aug 01 06:35:11 <Wormo> and ethernet can do DMA to memory, like PRU can...
Aug 01 06:37:40 <Wormo> people were reporting occasional OOPS for weeks without seeming to do anything different for that boot, not realizing some packet had come in at just the wrong time
Aug 01 06:38:33 <Wormo> hindsight makes it so much more clear :)
Aug 01 06:39:26 <ZeekHuge> hmm ... okay.
Aug 01 06:45:10 <Wormo> It can be really hard to nail down the real culprit behind oddly behaving bugs
Aug 01 06:46:51 <Wormo> Basically don't rule things out altogether until you have really figured out the cause
Aug 01 06:47:55 <ZeekHuge> I am beginning to doubt myself. I mean I have written all this source code, and Its not been too long ... and i have bug, which ideally, I should have solution too, as I have written it.
Aug 01 06:48:19 <Wormo> There was another case where everybody was really suspicious of co-processor firmware that kept getting hung, and I finally figured out it was a bootloader problem
Aug 01 06:48:19 <ZeekHuge> but it is behaving so oddly, that I am not getting to any particular point
Aug 01 06:49:03 <Wormo> So don't blame yourself, this stuff is hard, bugs can lurk for a while
Aug 01 06:50:25 <ZeekHuge> hmm .. yeah . btw I am kind of happy too, its the first bug in the code, and it gives an impression to me that progress is going on .. :)
Aug 01 06:50:36 <Wormo> hehe
Aug 01 06:50:45 <ZeekHuge> anyway .. back to doing something ..  reading more spi and i2c code.
Aug 01 06:51:13 <ZeekHuge> So basically , i2c and spi are query-response kind of busses
Aug 01 06:51:14 <Wormo> at least that's stuff I'm familiar with, so you can ask questions
Aug 01 06:51:47 <Wormo> very asymmetric, master in control of bus
Aug 01 06:52:18 <ZeekHuge> and the parallel bus we are developing is kind of streamed of data bus ..
Aug 01 06:52:26 <ZeekHuge> like we could hook up camera
Aug 01 06:52:33 <Wormo> yes
Aug 01 06:52:35 <ZeekHuge> and then just register callback
Aug 01 06:52:54 <ZeekHuge> that will be invoked when there is data ready
Aug 01 06:53:37 <ZeekHuge> okay I had this question ..
Aug 01 06:53:50 <ZeekHuge> how should we ALIGN the data
Aug 01 06:54:00 <ZeekHuge> i mean the structures that we will use
Aug 01 06:54:20 <Wormo> Is it not just a buffer with N samples in it?
Aug 01 06:54:24 <ZeekHuge> we should Align them while allocating memory right ?
Aug 01 06:54:33 <ZeekHuge> nope
Aug 01 06:54:41 <Wormo> you mean the device struct?
Aug 01 06:54:44 <Wormo> or what struct
Aug 01 06:54:56 <ZeekHuge> it is a structure with info related to driver .. device and all that
Aug 01 06:59:18 <ZeekHuge> we can use the ALIGN macro ofc, but how to use them ?
Aug 01 07:01:18 <Wormo> I normally put the 4-byte types first, then 2-byte, then single-byte in the struct
Aug 01 07:01:54 <ZeekHuge> just like : size = sizeof(struct driver_structure) ; size = ALIGN(size, ALIGNMENT_LIMIT) ; driver = kzalloc(size, GFP_KERNEL) ;
Aug 01 07:02:09 <ZeekHuge> why 3 times with different limits ?
Aug 01 07:02:23 <Wormo> where is this from?
Aug 01 07:02:40 <ZeekHuge> no where .. just based on what i know.
Aug 01 07:03:39 <Wormo> so this a question about dynamic allocations, I thought you were asking about struct layout
Aug 01 07:04:43 <ZeekHuge> yeah dynamic allocation. All structures should be allocated memory dynamically ?
Aug 01 07:05:47 <Wormo> especially if there might be multiple instances
Aug 01 07:06:37 <Wormo> static structs are used some in drivers, usually if there can only be one
Aug 01 07:07:51 <ZeekHuge> okay.
Aug 01 07:08:20 <Wormo> grep -r "static struct" drivers/
Aug 01 07:08:21 <ZeekHuge> is that above example of ALIGN correct ?
Aug 01 07:10:43 <Wormo> I'm not familiar with ALIGNMENT_LIMIT, but ALIGN macro usage looks fine
Aug 01 07:13:50 <ZeekHuge> probably we can keep ALIGNMENT_LIMIT = 32 to optimize it for 32 bit systems
Aug 01 07:18:47 <Wormo> I think ARM compilers usually do ok with alignment except when you do something that a little odd, like using a packed struct or pointer arithmetic pointing to middle of a word for a longer-than-byte access
Aug 01 07:19:53 <Wormo> If you had examples of where you saw the ALIGN stuff, I might be able to explain why it's there
Aug 01 07:22:36 <ZeekHuge> http://lxr.free-electrons.com/source/drivers/iio/industrialio-core.c#L1090
Aug 01 07:22:56 <ZeekHuge> but its then adding IIO_ALIGN - 1
Aug 01 07:26:11 <Wormo> IIO_ALIGN is not just for long-word alignment
Aug 01 07:26:16 <Wormo> http://lxr.free-electrons.com/source/include/linux/iio/iio.h#L624
Aug 01 07:26:41 <Wormo> trying to get cache-line alignment apparently
Aug 01 07:27:05 <ZeekHuge> which is equal to 64
Aug 01 07:27:34 <Wormo> this would be performance stuff, not the avoiding alignment traps in packed structs that I was talking about
Aug 01 07:29:38 <ZeekHuge> what i know about ALIGN is only this http://www.spinics.net/lists/newbies/msg50742.html
Aug 01 07:29:54 <ZeekHuge> I will probably skip this thing in the early versions
Aug 01 07:30:25 <Wormo> yes it's fine, leave it out unless reviewer tells you to worry about alignment
Aug 01 07:31:00 <ZeekHuge> okay.
Aug 01 07:31:06 <Wormo> alignment in packed structs is important for correctness, but I don't think you need packed structs
Aug 01 07:31:14 <Wormo> let the compiler arrange yours
Aug 01 07:31:37 <Wormo> packed structs are when you try to match data structures defined by hardware for instance
Aug 01 07:31:44 <ZeekHuge> yeah. No need for packed structures, unless it is handling data at very low level i guess
Aug 01 07:31:56 <ZeekHuge> yeah .. thats what i meant
Aug 01 07:32:33 <ZeekHuge> I have started to make sense in some of my arguments ;)
Aug 01 07:32:40 <Wormo> also watch out for alignment when doing pointer arithmetic and a bigger-than-byte memory access
Aug 01 07:32:43 <Wormo> yup
Aug 01 07:33:01 <Wormo> but again I don't see that would apply to you
Aug 01 07:33:19 <ZeekHuge> bigger-than-byte memory ?
Aug 01 07:33:25 <Wormo> e.g. don't try to read a longword from an odd-numbered address
Aug 01 07:33:51 <Wormo> hm this would be easy to draw on a whiteboard...
Aug 01 07:34:29 <ZeekHuge> are you talking about un-ALIGN structures ? or ALIGN structures ?
Aug 01 07:34:35 <ZeekHuge> you on hangouts ?
Aug 01 07:34:43 <ZeekHuge> they have a whiteboard there ..
Aug 01 07:34:57 <Wormo> starting with an aligned struct, but doing pointer arithmetic into the middle of it
Aug 01 07:35:07 <Wormo> I do hangouts, but prob not right now
Aug 01 07:35:18 <Wormo> and I thought the "new" hangout took away the drawing?
Aug 01 07:35:35 <Wormo> I couldn't find how to enable it last time I looked...
Aug 01 07:35:55 <Wormo> if you know how to get it back, maybe you can show me another day
Aug 01 07:37:14 <ZeekHuge> ahh .. well, the panel where we type in the message, just hover over the image icon and a pencil-shaped button appears .... just click on it ..
Aug 01 07:37:15 <Wormo> u8 data[8]; ptr = (int *)&data[1]; // bad
Aug 01 07:37:39 <Wormo> oh the chat hangout, not the video one?
Aug 01 07:37:49 <ZeekHuge> yes chat hangout
Aug 01 07:39:22 <ZeekHuge> okay . and how about u16 data[8] = (char *)&data[1] ?
Aug 01 07:39:36 <Wormo> that's ok
Aug 01 07:39:43 <ZeekHuge> so basically, we cant assume that the memory is contiguous ..
Aug 01 07:40:16 <Wormo> no it's the cpu has aligment constraints depending on size of access
Aug 01 07:41:19 <Wormo> if access is 1-byte long, you can start the access anywhere
Aug 01 07:41:35 <Wormo> if access is 2-byte long, you better start on an even address
Aug 01 07:42:02 <Wormo> if access is 4-byte long, you better start address divisible by 4
Aug 01 07:42:31 <ZeekHuge> oh ... got it.
Aug 01 07:44:53 <Wormo> (you can see this is different from alignment for performance enhancement, this is mandatory on certain architectures including arm)
Aug 01 07:50:14 <Wormo> so question about your firmware, how are you reserving space for msg->data ?
Aug 01 07:52:25 <Wormo> actually I don't see where space is reserved for the header either
Aug 01 07:54:08 <Wormo> wait I see now
Aug 01 07:54:24 <Wormo> maybe it's time for me to get some sleep ;)
Aug 01 07:56:30 <ZeekHuge> oh .. sorry .. didnt see the msg, was on other workspace
Aug 01 07:56:45 <Wormo> np
Aug 01 07:56:49 <ZeekHuge> yeah so, that basically the pointer to the buffer in the main memory
Aug 01 07:57:12 <Wormo> it was allocated when counter==0, I see it now
Aug 01 07:57:22 <ZeekHuge> yes .
Aug 01 08:24:52 <Wormo> temp_sampled_data[] is the buffer you were switching between 44 bytes long and 440 in the real firmware?
Aug 01 08:26:56 <ZeekHuge> actually , I removed the loop that catches interrupts from the other PRU, and then was manually sending data using that temp_sampled_data[] buffer ..
Aug 01 08:27:38 <Wormo> but that's where you tried the 440 when it wasn't sending the whole thing?
Aug 01 08:29:22 <Wormo> seems to me like it's too big a buffer to fit in the stack
Aug 01 08:30:16 <Wormo> and buffers defined inside a function, including main(), need to fit in the stack
Aug 01 08:31:05 <ZeekHuge> the code thats up there is not the only one that i tried, though that i tried can be obtained out of it by removing different segments .. and then i just uploaded ..
Aug 01 08:31:27 <ZeekHuge> one case was using that temp buffer , and manually sending data
Aug 01 08:31:56 <ZeekHuge> then there were cases when the firmware was in its original form
Aug 01 08:32:41 <ZeekHuge> and it was sending data , after which I calculated data per interrupt and it was about 256
Aug 01 08:33:39 <ZeekHuge> there were cases with and without that if (ret != PRU_RPMSG_SUCCESS )
Aug 01 08:33:43 <Wormo> Did you know both your stack and heap are currently 256 bytes
Aug 01 08:34:29 <ZeekHuge> but I tried that temp_buffer[44] in this example too https://github.com/ZeekHuge/BeagleScope/blob/wip/examples/firmware_exmples/large_buffer_example/main_pru1.c#L102
Aug 01 08:34:48 <ZeekHuge> okay, I think I will give an hour to try it again ..
Aug 01 08:35:13 <ZeekHuge> though I didnt add that temp_buffer code in that example ...
Aug 01 08:35:28 <ZeekHuge> I did try it here ..
Aug 01 08:35:57 <Wormo> The example worked & the main didn't, right?
Aug 01 08:36:20 <Wormo> also note the heap is only set to 256
Aug 01 08:36:36 <ZeekHuge> yes .
Aug 01 08:37:12 <ZeekHuge> and the problem was it was sending 2*times the limit.
Aug 01 08:37:41 <Wormo> it might be challenging to get your buffer fitting safely
Aug 01 08:38:24 <Wormo> might note it down as something to work on when going back to the big buffer feature later
Aug 01 08:40:16 <Wormo> unlike in the kernel, there's no option for validating stack hasn't been exceeded...
Aug 01 08:40:55 <Wormo> or an informative OOM message for running out of heap
Aug 01 08:48:59 <Wormo> gnight
Aug 01 08:49:01 <ZeekHuge> yep, okay.
Aug 01 08:50:40 <ZeekHuge> Wormo:  Good night :) Thanks
Aug 01 10:10:24 <ZeekHuge> finally ..... hhhhhh.....
Aug 01 14:54:19 <bradfa> av500: mdp: I won't be able to make this weeks meeting, have a funeral which conflicts
Aug 01 14:54:28 <av500> ack
Aug 01 14:54:39 <av500> I'll be there
Aug 01 14:54:47 <av500> and not stranded without net like last week
Aug 01 16:16:30 <mdp> bradfa, ok, will be there
Aug 01 16:30:02 <ZeekHuge> Wormo_: there ?
Aug 01 16:30:18 <ZeekHuge> ds2: ?
Aug 01 16:52:53 <ds2> ZeekHuge: did you check to see if the version of rpmsg has a compiled in message size limit? older versions had that
Aug 01 16:53:41 <ZeekHuge> well, I got the 440 bytes buffer working .
Aug 01 16:53:51 <ZeekHuge> ds2: ^
Aug 01 16:53:59 <ZeekHuge> and #2 is also resolved
Aug 01 16:54:30 <ZeekHuge> btw yes it has that limit compiled in
Aug 01 16:55:25 <ZeekHuge> So now we have a new highest achievable sampling frequency limit
Aug 01 16:55:38 <ZeekHuge> ds2: ^
Aug 01 16:55:58 <ds2> what's the new limit?
Aug 01 16:56:22 <ZeekHuge> ahh .. was badly waiting for this question  ..
Aug 01 16:56:26 <ZeekHuge> its 20MHz
Aug 01 16:56:28 <ZeekHuge>  :)
Aug 01 16:57:18 <ZeekHuge> ds2: ^
Aug 01 16:57:40 <ds2> for how long?
Aug 01 16:58:24 <ZeekHuge> WOW !!! how did you know that ?.. not for more than a few seconds
Aug 01 16:59:13 <ds2> buffering issues :D
Aug 01 16:59:19 <ZeekHuge> tis usually getting stalled after this line in dmesg https://gist.github.com/ZeekHuge/0db365bbd1584e4b32673895ee38e2de#file-yet_another_dmesg-txt-L53
Aug 01 16:59:28 <ds2> 20MHz is not bad with rpmsg
Aug 01 16:59:31 <ZeekHuge> I dont think so ...
Aug 01 16:59:43 <ZeekHuge> its something with the CPU i guess
Aug 01 16:59:58 <ZeekHuge> buffer is just dropping the new meessages
Aug 01 17:00:22 <ds2> might be the UART driver screwing things up
Aug 01 17:00:46 <ds2> what are you writing to? thought all you are doing is reading data in?
Aug 01 17:00:58 <ZeekHuge> iio_buffer
Aug 01 17:01:05 <ds2> also, have you validated the data coming in?
Aug 01 17:01:21 <ds2> no no... what is causingthebroken pipe message...that only comes from a userland write()
Aug 01 17:02:05 <ds2> something like - drive ADC with a sine wave (say 1-2 MHz for a 20Msp rate) - gather the data and plot it
Aug 01 17:02:10 <ZeekHuge> oh that ... thats my host system. The bbb is getting stalled and disconnected to the host so .. that message
Aug 01 17:02:21 <ds2> ah gotit
Aug 01 17:02:57 <ZeekHuge> yeah ... but at that frequency I was not able to catch much data out of the /dev/iio\ device buffer
Aug 01 17:03:02 <ZeekHuge> i was using dd
Aug 01 17:03:19 <ZeekHuge> and it was able to catch very small mount of data
Aug 01 17:03:35 <ZeekHuge> iio subsystem has dam buffer support too ..
Aug 01 17:03:53 <ZeekHuge> probably will have to use that .. but as a later task
Aug 01 17:04:13 <ds2> oh... are you passing things byte by byte to the IIO subsystem?
Aug 01 17:04:34 <ds2> at what rate can you get data reliably?
Aug 01 17:04:55 <ds2> i have seen very odd drop outs from all over the place
Aug 01 17:06:07 <ZeekHuge> 16bit word at a time ..
Aug 01 17:07:17 <ZeekHuge> also, the message is first gets transfer to the rpmsg_buffer and then from rpmsg buffer to the iio buffer
Aug 01 17:08:54 <ZeekHuge> but this is temporary ... as jic23 was suggesting dma buffers
Aug 01 17:12:26 <ZeekHuge> ds2: also, while i was noting down the interrupts from the PRU using /proc/interrupts, the i2c interrupt counter was also incrementing .
Aug 01 17:12:28 <ZeekHuge> Is the I2 alwasy working by default ?
Aug 01 17:12:40 <ZeekHuge> probably for plug and play service of capes ?
Aug 01 17:13:05 <ZeekHuge> *I2C
Aug 01 17:13:32 <ds2> I don't think so
Aug 01 17:13:44 <ds2> wonder if it is the HDMI
Aug 01 17:13:48 <ZeekHuge> but the interrupt counter was incrementing
Aug 01 17:13:56 <ds2> or talking to the PMIC
Aug 01 17:15:11 <ZeekHuge> okay.
Aug 01 17:16:04 <ZeekHuge> btw 20MHz is the highest we can go with this fw maintaining a 50% duty cycle
Aug 01 17:16:36 <ds2> this is in C or assembly?
Aug 01 17:17:26 <ZeekHuge> this is using C, but it is configurable and therefore lower limit.
Aug 01 17:18:17 <ZeekHuge> we can add one more sampling function that will have no delays, and hence the highest limit of about 40MHz
Aug 01 17:19:06 <ds2> got it
Aug 01 17:19:23 <ds2> not bad... now to verify the data integerity overall
Aug 01 17:19:34 <ZeekHuge> ds2: while i was testing the highest limit with this setup , I got this dmesg , but only once https://gist.github.com/ZeekHuge/33cf0dacfa491abbe970f87069c7ab2d#file-2nd_time_dmesg_window_log-txt-L79
Aug 01 17:19:46 <ZeekHuge> you see that RT throttling activated ?
Aug 01 17:19:49 <ds2> <-- would be more impressed with a data verified speed number
Aug 01 17:20:27 <ZeekHuge> and this time (when this was the dmesg output) the board didnt stalled ..
Aug 01 17:20:27 <ZeekHuge> *stall
Aug 01 17:20:30 <ds2> yes I see that
Aug 01 17:20:33 <ZeekHuge> okay :)
Aug 01 17:20:56 <ds2> his this happening directly in your callback?
Aug 01 17:21:10 <ds2> I wonder if you need to locally queue and use a work_queue for processing
Aug 01 17:21:20 <ZeekHuge> Wormo: !
Aug 01 17:21:26 <Wormo> Hi ZeekHuge
Aug 01 17:21:43 <ZeekHuge> I got 440bytes working ! and #2 resolved
Aug 01 17:21:46 <ZeekHuge> Wormo: ^
Aug 01 17:21:47 <Wormo> wow!!!
Aug 01 17:21:54 <Wormo> congrats ZeekHuge !!
Aug 01 17:22:01 <ZeekHuge> and the highest sampling rate of 20MHz
Aug 01 17:22:08 <Wormo> :D
Aug 01 17:22:21 <Wormo> breakthrough?
Aug 01 17:22:56 <Wormo> was it buffer allocation or something entirely different?
Aug 01 17:22:57 <ZeekHuge> well, thats the highest limit at which this setup can go.
Aug 01 17:23:02 <ZeekHuge> this firmware with 50% duty cycle
Aug 01 17:23:26 <ZeekHuge> well, data wasnt being captured ...
Aug 01 17:23:57 <ZeekHuge> I even tried to increase the buffer size - echo 1000000 > buffer/length
Aug 01 17:25:27 <ZeekHuge> ds2: well, I dont know where that RT throttle is happening, but yeas that message appears after the PRU data is started (that is in the postenable function)
Aug 01 17:27:01 <ZeekHuge> Wormo: the dmesg whiile I was testing : https://gist.github.com/ZeekHuge/0db365bbd1584e4b32673895ee38e2de
Aug 01 17:27:34 <ZeekHuge> Wormo: and this one too . (its with RT throttling ) https://gist.github.com/ZeekHuge/33cf0dacfa491abbe970f87069c7ab2d#file-2nd_time_dmesg_window_log-txt-L79
Aug 01 17:27:43 <ds2> ZeekHuge: what is your flow? rpmsg callback -> for each sample( iio push); ?
Aug 01 17:29:22 <ZeekHuge> yes -> rpmsg_callback(buffer length 440 bytes) { push_to_iio_buffer_16bitWord_at_a_time; }
Aug 01 17:31:14 <ds2> that might be taking too long to keep the rt stuff happy
Aug 01 17:31:41 <ds2> maybe moving that to a tasklet would help
Aug 01 17:32:02 <ds2> OTH - if you are moving to the DMA bufs, that might be a waste of time
Aug 01 17:35:51 <ZeekHuge> nope .. what we can rather do is: the virtio_rpmsg_bus says that it can use a  given buffer . but do not supports that for now. So we are somehow able to do that, we can directly point the PRUs to the IIO buffers. as here PRU is already acting like a DMA that transfers data from the PRU to the ARM
Aug 01 17:36:07 <Wormo> ZeekHuge: which commits are the ones with latest fix?
Aug 01 17:36:53 <ds2> ZeekHuge: so give up rpmsg in otherwords?
Aug 01 17:37:01 <ZeekHuge> ahh .. none . just 5 minutes, I kind of messed with the commits,
Aug 01 17:37:05 <Wormo> ok
Aug 01 17:37:21 <ZeekHuge> ds2:  rpmsg is based on virtio_rpmsg_bus  isnt it ?
Aug 01 17:37:33 <ZeekHuge> thats the whole setup
Aug 01 17:37:52 <ZeekHuge> the repmsg device just sits on the virtio_rpmsg_bus
Aug 01 17:38:13 <ds2> ZeekHuge: yes....
Aug 01 17:38:20 <ZeekHuge> and gets its buffer of data from the virtio_rpmsg_bus
Aug 01 17:38:29 <ds2> so half way between a pure interrupt/read mem setup and rpmsg
Aug 01 17:39:38 <ZeekHuge> I would see it going with the standard and generic methods .. probably i am wrong ?
Aug 01 17:39:57 <ds2> it is your choice
Aug 01 17:41:27 <ZeekHuge> ds2: okay so, for now I cant actually check the data integrity at that frequency ..
Aug 01 17:45:30 <ZeekHuge> I will check the limit .. at which I will be able to get reliably and then check the integrity of that data ..
Aug 01 17:46:20 <ZeekHuge> ds2: ^
Aug 01 17:52:26 <ds2> *nod*
Aug 02 02:50:27 <ZeekHuge> Wormo_: ?
Aug 02 02:50:33 <ZeekHuge> Wormo_: https://github.com/ZeekHuge/BeagleScope/compare/eedcb35aa679642308a4fca84d9853743a6eb177...cfe0217ad3e89d59c4d7dff8f137740313760398
Aug 02 02:51:21 <ZeekHuge> Sorry ... I did push those commits in the wip branch
Aug 02 02:51:56 <ZeekHuge> but was asleep then while adding commits to the main branch
Aug 02 02:52:25 <ZeekHuge> and therefore late to submit this link to you
Aug 02 02:53:24 * ZeekHuge has this unique ability to get asleep anywhere, like while sitting, if he is really tired.
Aug 02 02:54:19 * ZeekHuge is further developing the ability to sleep even while he is standing  ;)
Aug 02 02:55:07 <ZeekHuge> Just woke up, need tea and something to eat. will be back
**** ENDING LOGGING AT Tue Aug 02 02:59:57 2016