**** BEGIN LOGGING AT Wed Jun 11 02:59:59 2014
Jun 11 03:09:13 <karki> Abhishek_ : morning!
Jun 11 03:10:14 * Abhishek_ yawns
Jun 11 03:10:53 <Abhishek_> it's sleep time for me now
Jun 11 05:20:07 <karki> panto : the number and amount of shared memory segments for each PRU, should it be part of the DTS? [ It's a constant 8K anyway...... idk if it makes sense putting it in the dts]
Jun 11 05:20:18 <karki> panto_ : ^
Jun 11 06:57:34 <panto> morn
Jun 11 07:09:39 <vvu_backup> morning panto
Jun 11 07:43:22 <karki> panto : the number and amount of shared memory segments for each PRU, should it be part of the DTS? [ It's a constant 8K anyway...... idk if it makes sense putting it in the dts]
Jun 11 08:14:26 <panto> karki, yeah, it should
Jun 11 08:14:45 <panto> IIRC there are a few new parts with PRUs coming up that might have different memory sizes
Jun 11 08:15:12 <karki> new parts?
Jun 11 08:20:09 <panto> new processors
Jun 11 08:20:22 <karki> ah
Jun 11 08:20:40 <karki> will they power the BBB?
Jun 11 08:23:15 <panto> no idea
Jun 11 08:23:32 <panto> I don't think they are either pin compatible, or cheap enough
Jun 11 09:14:21 <karki> panto : I'm a bit confused about the DTS part. It makes sense to have the size of the shared area in the DTS, but the number of segments *has* to be fixed. I need 2 shared memory segments per PRU and that is fixed for my driver. So do I mention that too in the DTS?
Jun 11 09:16:13 <karki> even if the DTS says 1 shared memory segments, I'd still need 2 segments! (I could make it part of the DTS anyway no big deal, but why is it needed at part of DTS? )
Jun 11 09:59:21 <panto> cause it describes your driver requirement in a higher level
Jun 11 09:59:31 <panto> you can verify that the DTS is correct before proceeding
Jun 11 09:59:36 <panto> and spewing warning messages
Jun 11 10:10:08 <Abhishek_> panto: you would have noticed that copytouser memory reserved with dma_alloc_coherent is slow (26 MB/s around)
Jun 11 10:10:50 <panto> that's because dma_alloc_coherent allocated non-cachable memory
Jun 11 10:11:25 <Abhishek_> Can this mem be made lookahead cacheable?
Jun 11 10:11:36 <panto> probably
Jun 11 10:12:08 <panto> but that's why I mentioned that the on-the-fly dma mapping is superior
Jun 11 10:12:36 <panto> ARM is dependent on cacheable memory for performance
Jun 11 10:12:48 <Abhishek_> On-the-fly as in?
Jun 11 10:12:58 <panto> scatter gather dma
Jun 11 10:13:17 <panto> you need performance for data transfer right?
Jun 11 10:13:33 <Abhishek_> Yep
Jun 11 10:13:35 <panto> not for the control interface
Jun 11 10:13:57 <Abhishek_> Downcalls are good enough for control
Jun 11 10:14:14 <panto> so, in that case, ARM gets a buffer, invalidates cache on it, and then passes it to the PRU
Jun 11 10:14:28 <panto> PRU does it's thing and then passes the buffer back to ARM
Jun 11 10:14:45 <panto> arm accesses it, and since it's cacheable, things go as fast as possible
Jun 11 10:14:51 <Abhishek_> Something like PRU interrupts triggering cache invalidation
Jun 11 10:14:56 <panto> no
Jun 11 10:15:19 <panto> got nothing to do with interrupts, more with buffer management
Jun 11 10:15:36 <panto> you get an interrupt to signal something needs attention
Jun 11 10:17:04 <Abhishek_> I see, currently reusing the vring interrupts for signalling (that might not be the right way but works)
Jun 11 10:18:44 <Abhishek_> Should I do mem allocation directly with __get_free_pages then?
Jun 11 10:18:58 <panto> that won't help
Jun 11 10:20:06 <Abhishek_> Hmm, do you have anything off-hand I could refer to do this cache magic?
Jun 11 10:20:16 <panto> DMA-API-HOWTO.txt
Jun 11 10:22:09 <Abhishek_> Also another observation, that I didn't seem to get a "allocation done" log message, just a warning that dma_coherent_mask is unset when I didn't set those masks
Jun 11 11:50:44 <Abhishek_> panto: So the approach seems to be something like: allocate buffers using kmalloc and then do dma_map_single on top of that?
Jun 11 11:56:21 <panto> kmalloc might work, but it's not recommended
Jun 11 11:56:29 <panto> any kind of memory though would work
Jun 11 12:04:41 <av500> vvu: ping
Jun 11 12:09:42 <av500> Abhishek_: it is similar to how you handle e.g a DSP
Jun 11 12:09:47 <av500> that shares memory with ARM
Jun 11 12:09:52 <vvu_backup> av500: pong
Jun 11 12:10:42 <Abhishek_> av500: Memory allocation is OK so far, what I need is to somehow cache it appropriately to get a performance boost
Jun 11 12:12:59 <av500> so decalre it cached
Jun 11 12:13:15 <av500> and due the cache invalidate thing
Jun 11 12:15:16 <Abhishek_> but dma_alloc_coherent memory is noncached, how could I declare this memory cached?
Jun 11 12:16:09 <Abhishek_> I would need to change allocation strategy, is it?
Jun 11 12:18:10 <av500> is that not some flag?
Jun 11 12:18:39 <Abhishek_> dma_set_coherent_mask to 0?
Jun 11 12:19:34 <Abhishek_> but I don't know, in that case I get a warning in my kernel logs "dma coherent mask" not set
Jun 11 12:19:50 <Abhishek_> and memory reservation doesn't show up in free
Jun 11 12:20:09 <panto> dma_alloc_coherent memory returns uncached memory
Jun 11 12:20:33 <panto> use standard memory and do the invalidation
Jun 11 12:20:43 <panto> look at dma_map_single()
Jun 11 12:21:29 <av500> remap_pfn_range()?
Jun 11 12:21:42 <Abhishek_> yes, so kmalloc the buffer and do dma_map_single on that? [and then manually invalidate the caches]
Jun 11 12:21:56 <Abhishek_> with dma_sync_single_for_cpu
Jun 11 12:22:05 <av500> panto: but you need it contigous, no?
Jun 11 12:22:16 <panto> yes
Jun 11 12:22:24 <panto> kmalloc returns contiguous memory
Jun 11 12:22:48 <panto> do not allocate it each time you need it
Jun 11 12:22:50 <panto> pre-allocate
Jun 11 12:23:08 * Abhishek_ wonders if he can 256MB of memory in one go with kmalloc
Jun 11 12:23:10 <av500> yes
Jun 11 12:23:15 <av500> Abhishek_: no need
Jun 11 12:23:18 <av500> do your 8x allocs
Jun 11 12:23:22 <av500> keep a list of chunks
Jun 11 12:23:26 <av500> etc..
Jun 11 12:23:35 * av500 wonders if CMEM could help here
Jun 11 12:23:46 <av500> its the same thing actually
Jun 11 12:23:48 <panto> yeah
Jun 11 12:23:57 <panto> don't get bogged down by details at this point
Jun 11 12:23:59 <Abhishek_> I don't think I would need that if this 32x thing can work
Jun 11 12:24:10 <panto> get your performance numbers first
Jun 11 12:24:27 <panto> then we'll think about how to do it best
Jun 11 12:25:34 <panto> lunch
Jun 11 12:25:49 <av500> GOGOGO!
Jun 11 12:47:20 <Abhishek_> panto av500:74 MB/s in first run, 170 MB/s in subsequent runs (cached).
Jun 11 12:51:50 <Abhishek_> Testing with dma_sync_buffers now
Jun 11 12:55:19 <karki> Abhishek_ : how exactly are you checking the speeds?
Jun 11 12:56:04 <Abhishek_> dd
Jun 11 13:06:09 <Abhishek_> panto av500: sync'ing buffers before read now: dd if=/dev/beaglelogic of=/dev/null bs=8M count=8 iflag=fullblock gives 150 MB/s
Jun 11 13:32:37 <panto> Abhishek_, pastebin your code plz
Jun 11 13:35:47 <Abhishek_> panto: from here: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/pru_rproc_bl.c#L2709
Jun 11 13:36:25 <panto> Abhishek_, err, you're not doing it right
Jun 11 13:36:35 <panto> don't map the buffers at the point of allocation
Jun 11 13:36:58 <panto> you need to call dma_map_single/dma_unmap on each buffer usage
Jun 11 13:37:24 <Abhishek_> panto: what if I sync the buffers at the time of read?
Jun 11 13:38:00 <panto> since you're doing transfers (dma) from the PRU you should dma_map_single at the time you submit the buffer
Jun 11 13:38:39 <Abhishek_> I do it like: give the PRU a complete list of 32 buffers to DMA into before it starts
Jun 11 13:39:29 <Abhishek_> what is the flaw in this approach?
Jun 11 13:39:29 <panto> yes, you should do the dma_map_single call before it starts
Jun 11 13:39:51 <Abhishek_> not at the time of allocation itself?
Jun 11 13:39:51 <panto> there is no flaw, the flaw in your current approach is that you map at the moment of allocation
Jun 11 13:40:00 <panto> not at the time of allocation
Jun 11 13:40:09 <Abhishek_> which is conventionally wrong?
Jun 11 13:40:20 <panto> mapping at the time of allocation is wrong
Jun 11 13:40:28 <panto> mapping is done a the moment of buffer submission
Jun 11 13:41:13 <Abhishek_> I see, I will refactor this out.
Jun 11 13:42:10 <Abhishek_> panto: are the sync before the reads ok?
Jun 11 13:43:00 <panto> you don't need them if you use dma_map_single/dma_unmap_single
Jun 11 13:43:36 <Abhishek_> I see
Jun 11 13:47:13 <Abhishek_> I'll amend the stuff accordingly and pass it on for review again
Jun 11 13:53:04 <panto> I would also try to sneak in some kind of data consistency check
Jun 11 13:53:30 <panto> have the PRU fill the buffers with increasing numbers would be OK
Jun 11 14:02:37 <Abhishek_> Yeah I was thinking of the same thing :)
Jun 11 14:29:55 <Abhishek_> panto: I'm putting the dma mapping stuff in fopen and fclose, that's approporiate for the purpose?
Jun 11 14:30:16 <panto> no
Jun 11 14:30:36 <panto> are you doing a single transfer and then close?
Jun 11 14:30:48 <panto> then it's passable, but not quite correct
Jun 11 14:31:19 <av500> ideally you map after the PRU returned the buffer
Jun 11 14:31:32 <av500> and you unmap before you give it back to the PRU
Jun 11 14:32:03 <Abhishek_> no, open "arms" the analyzer, close releases it. The first read triggers the PRU firmware (I want this to be as fast as possible)
Jun 11 14:32:16 <Abhishek_> then the PRU fires ISR every 8 MB
Jun 11 14:32:29 <av500> yes
Jun 11 14:32:45 <Abhishek_> read blocks till the first 8 MB buffer is filled up
Jun 11 14:32:51 <av500> right
Jun 11 14:32:54 <av500> then you map
Jun 11 14:32:56 <av500> so you can read
Jun 11 14:33:41 <Abhishek_> oh wait, I use the virt_to_phys macro to get the backing physical memory area to give to the PRUs ?
Jun 11 14:33:50 <panto> no
Jun 11 14:34:07 <panto> dma_map_single returns the physical address that's valid for the device (PRU)
Jun 11 14:34:14 <panto> in this case it's the same
Jun 11 14:34:31 <av500> PRU needs iommu
Jun 11 14:34:34 <panto> heh
Jun 11 14:34:45 <Abhishek_> that's the issue
Jun 11 14:34:51 <av500> and a 4k decoder...
Jun 11 14:34:56 * panto kicks av500 
Jun 11 14:34:59 <av500> :)
Jun 11 14:37:09 <Abhishek_> so that means I need to do dma_map_single just before giving the PRUs the physical addresses of the buffers.
Jun 11 14:38:05 <panto> yes
Jun 11 14:38:10 <Abhishek_> wait, do I also need to unmap previous buffers from the ISR and map new ones?
Jun 11 14:54:38 <Abhishek_> Now preparing the status updates for today's meeting, will take care of the code cleanup after the meeting.
Jun 11 14:58:44 <panto> of course
Jun 11 14:59:16 <panto> you're having data incoming from a device
Jun 11 14:59:32 <panto> you map the buffer, perform the transfer, and then unmap
Jun 11 14:59:46 <panto> only after the unmap is safe to access the data from the ARM
Jun 11 15:01:03 <Abhishek_> how much time should it take (milliseconds or some microseconds)?
Jun 11 15:02:19 <panto> it will perform cache management
Jun 11 15:02:27 <panto> if the area is large it could take a while
Jun 11 15:02:35 <panto> but, there's no way around it
Jun 11 15:02:49 <panto> you have to have your memory consistent
Jun 11 15:03:07 <panto> mapping for input (to the arm) should be fast
Jun 11 15:03:18 <panto> cause you're invalidating the cache, not flushing
Jun 11 15:03:34 <panto> the other way around, output, is slower since you're going to flush
Jun 11 15:04:54 <Abhishek_> I see, the timestamp in printk is the moment that message is submitted, or is it the timestamp after the data goes into the log buffer?
Jun 11 15:09:25 <panto> message is submitted
Jun 11 15:09:30 <panto> but you should not rely on that
Jun 11 15:13:56 <Abhishek_> nope I was considering timing the dma mapping between two printk's
Jun 11 15:14:08 <panto> that's fine
Jun 11 15:14:14 <panto> you only care about relative timings
Jun 11 15:14:21 <panto> but printk has overhead too
Jun 11 15:15:00 <Abhishek_> hmm, yes so probably know the overhead before the actual printk and then correct it
Jun 11 15:15:15 <Abhishek_> but then there should be a better way
Jun 11 15:25:00 <_av500_> panto: there is a trick
Jun 11 15:25:15 <_av500_> for large invalidates, you invalidate the whole cache
Jun 11 15:25:19 <_av500_> we did that one omap3
Jun 11 15:25:35 <_av500_> on*
Jun 11 15:28:20 <panto> _av500_, yes :)
Jun 11 15:28:30 <panto> sneaky you
Jun 11 15:30:14 <_av500_> :-P
Jun 11 15:31:00 <karki> panto : where to from here. I need to fill in my goals for the coming week!
Jun 11 15:31:41 <panto> I need all you PRU guys to come together and come up with a way to merge your work
Jun 11 15:31:50 <panto> any beaglepilot people here?
Jun 11 15:32:05 <karki> nope
Jun 11 15:32:07 <panto> we have to come up with a PRU subsystem
Jun 11 15:32:30 <karki> like the current UIO?
Jun 11 15:32:49 <panto> hopefully no :)
Jun 11 15:33:07 <Abhishek_> export necessary symbols from the remoteproc and add IRQ hooks, so that other drivers can attach and remove
Jun 11 15:33:08 <panto> and we need to start moving to mainline
Jun 11 15:33:33 <panto> Abhishek_, not so easy as a simple export
Jun 11 15:33:55 <panto> what we need to do is turn this pru driver on it's head
Jun 11 15:33:56 <Abhishek_> yup, there are subtleties
Jun 11 15:34:02 <karki> panto : what are the main challenges we'd face here?
Jun 11 15:34:28 <panto> at the moment there is no separation of different workloads
Jun 11 15:34:32 <panto> everything is in the same driver
Jun 11 15:34:35 <panto> which is not correct
Jun 11 15:34:41 <Abhishek_> karki: main challenge is to make it to the mainline :)
Jun 11 15:35:16 <karki> I meant design wise ;)
Jun 11 15:35:26 <panto> what you need is to move the PRU boilerplate in a PRU subsystem that other drivers utilize
Jun 11 15:35:35 <panto> one of the drivers will be the user-space bridge
Jun 11 15:36:03 <Abhishek_> I was thinking of moving some of the PRU remoteproc stuff to my own driver
Jun 11 15:36:22 <panto> no
Jun 11 15:36:34 <panto> we don't want to diverge and waste resources
Jun 11 15:36:46 <karki> panto : didn't we discuss about this sometime ago?
Jun 11 15:36:49 <panto> yeah
Jun 11 15:36:55 <panto> everything runs in circles
Jun 11 15:37:16 <karki> so all this PRU work, during or after GSoC?
Jun 11 15:37:38 <panto> so for this week concentrate on getting your specific apps working
Jun 11 15:38:40 <panto> then we need to move to mainline
Jun 11 15:39:23 <karki> panto : I wonder what I should be doing...... I don't want to waste too much time on the pru firmware if we are going to go JIT at the end.
Jun 11 15:40:10 <panto> karki, there's no difference
Jun 11 15:40:18 <panto> you still need to do PRU firmware for JIT
Jun 11 15:41:09 <karki> how come, I thought I'd be converting botspeak -> pru assembly -> elf -> load on PRU
Jun 11 15:42:22 <panto> no
Jun 11 15:42:32 <panto> you still need the bootstrap firmware
Jun 11 15:42:57 <panto> the botspeak jit fragments willt need to be updated
Jun 11 15:43:00 <panto> *will
Jun 11 15:43:15 <panto> I don't think they will be ELF
Jun 11 15:43:26 <panto> binary will do
Jun 11 15:45:25 <karki> but the bootstrap code won't do much of logic execution right? i.e. it wont control digital IO, PWM etc
Jun 11 15:45:37 <panto> no
Jun 11 15:46:05 <panto> don't worry about JIT yet
Jun 11 15:46:10 <karki> ok :)
Jun 11 15:49:26 <disdi_> hi all
Jun 11 15:49:33 <vvu> hello disdi_
Jun 11 15:49:39 <Abhishek_> hi disdi_
Jun 11 15:49:58 <disdi_> hi Abhishek, vvu
Jun 11 15:50:18 <Abhishek_> We are 5 projects building on kernel drivers now :)
Jun 11 15:50:45 <disdi_> jkridner: hi
Jun 11 15:51:22 <disdi_> Abhishek: thats remarkable....hope everyone of us sees it through
Jun 11 15:56:32 <jkridner> hi disdi_
Jun 11 15:57:13 <vmayoral|pc> greetings!
Jun 11 15:57:26 <Abhishek_> hey vmayoral|pc
Jun 11 15:58:41 <vmayoral|pc> hi Abhishek_, how is it going with the sysfs interface? that sounded really nice ;)
Jun 11 15:59:04 <Abhishek_> wait a few more moments :)
Jun 11 15:59:23 <joel_> hey everyone
Jun 11 15:59:38 <_av500_> hello guys
Jun 11 15:59:42 <VoltVisionFrench> hello all!
Jun 11 16:00:01 <rseethamraju> hello!
Jun 11 16:00:08 <jkridner> hi all. welcome back VoltVisionFrench
Jun 11 16:00:25 <jkridner> want to keep this meeting under 30 minutes today.
Jun 11 16:00:32 <_av500_> hello jkridner, sorry for AWOL last week, family matters
Jun 11 16:00:44 <jkridner> First, I want to say sorry for not putting together any of the tutorial sessions I discussed from last week.
Jun 11 16:00:49 <jkridner> :'(
Jun 11 16:01:44 <jkridner> I'm getting panicked about the state of some of the projects and that was my "Big Idea" (tm) to try to get some moving forward.
Jun 11 16:02:03 <jkridner> I'm on travel again tonight and through this week, but that isn't a good excuse.
Jun 11 16:02:36 <vvu> jkridner: if u need help i`m around here all day
Jun 11 16:02:37 <jkridner> I've also not scheduled additional meeting times.
Jun 11 16:02:45 <jkridner> thanks vvu
Jun 11 16:02:54 <jkridner> I need help. :-)
Jun 11 16:03:22 <jkridner> I especially want to setup a meeting time suitable with the #beaglepilot folks.
Jun 11 16:03:32 <jkridner> vmayoral|pc: what time do you typically meet with tridge, etc.?
Jun 11 16:04:03 <vmayoral|pc> we usually have meetings on Fridays at 7:30 GMT+1
Jun 11 16:04:22 <jkridner> VoltVisionFrench (aside): have you had any luck bringing in a designer to engage with DiegoTc?
Jun 11 16:04:34 * jkridner wonders where DiegoTc is today.
Jun 11 16:04:35 <vmayoral|pc> jkridner: we usually use mumble and a remote screen session
Jun 11 16:04:35 <Abhishek_> @Everyone: http://www.theembeddedkitchen.net/misc/beaglelogic-goes-kernel-mode-with-pru-remoteprocweek-2-3/
Jun 11 16:05:16 <VoltVisionFrench> jkridner, yes I have arranged some options, but I havent been able to get ahold of DiegoTC for a couple of days now.
Jun 11 16:05:31 <jkridner> disdi_, vmayoral|pc: thank you for your status updates.
Jun 11 16:05:52 <joel_> jkridner, count me in for beaglepilot meetings, thx
Jun 11 16:06:02 <Abhishek_> jkridner: Drafting the mail now, but my update is the blog post itself
Jun 11 16:06:06 <vmayoral|pc> jkridner: i haven't seen praveendath92 around lately. Has he dropped his project?
Jun 11 16:06:12 <disdi_> jkrinder: :)
Jun 11 16:06:16 <jkridner> Abhishek_: can you add a status report to the list in addition to your blog post?
Jun 11 16:06:17 <_av500_> he was a way for a week in the US
Jun 11 16:06:21 <vvu> vmayoral|pc: he was absent one week for a conference
Jun 11 16:06:39 <vmayoral|pc> vvu: thanks :)!
Jun 11 16:06:54 <karki> jkridner : just posted my updates
Jun 11 16:06:59 <jkridner> thanks karki
Jun 11 16:07:26 <jkridner> rseethamraju: are you sending a status update?
Jun 11 16:07:32 <jkridner> anyone seen praveen?
Jun 11 16:07:39 <VoltVisionFrench> all: what is the link to see the chat log from last week?  Thx!
Jun 11 16:08:09 <VoltVisionFrench> (the meeting)
Jun 11 16:08:13 <vmayoral|pc> jkridner, joel_: we use 3DR mumble server. If you want to join the meetings please write me add me on skype (v.mayoral) and i will include you in a private BeaglePilot dev. group. From there you can get into our internal conversations
Jun 11 16:08:36 <vmayoral|pc> s/please write me add me on skype/please add me on skype/
Jun 11 16:08:43 <joel_> vmayoral|pc, aye
Jun 11 16:08:55 <rseethamraju> I have a meeting with alexanderhiam and VoltVisionFrench after this so can I put it up after that?
Jun 11 16:09:10 <karki> jkridner : wondering about my BBB ;)
Jun 11 16:09:19 <rseethamraju> sorry I was going to ask
Jun 11 16:09:20 <jkridner> VoltVisionFrench: http://logs.nslu2-linux.org/livelogs/beagle-gsoc/beagle-gsoc.20140605.txt
Jun 11 16:09:20 <_av500_> jkridner: praveen has not reported back after his us trip
Jun 11 16:09:29 <_av500_> jkridner: I mailed him as well
Jun 11 16:09:42 <jkridner> _av500_: I saw your mail.
Jun 11 16:10:14 <VoltVisionFrench> jkridner, thx!
Jun 11 16:10:17 <jkridner> we are at serious risk of having some fails at the midterms within 2 weeks. this is bad.
Jun 11 16:10:53 <karki> jkridner : working API https://gist.github.com/deepakkarki/6223ccd116456c3e4d26 :)
Jun 11 16:11:02 <vvu> that is not really nice
Jun 11 16:11:08 <rseethamraju> jkridner: I didnt go anything this week - exams. I’ll male up for it this week.
Jun 11 16:11:49 <rseethamraju> *make
Jun 11 16:11:57 <karki> ^ :')
Jun 11 16:12:00 <jkridner> karki: I just sent Cathy a ping.
Jun 11 16:12:14 <jkridner> karki: I meet with her face-to-face on Friday, but I will call her today.
Jun 11 16:12:23 <karki> jkridner : Thanks :) have a look at how the API is coming up!
Jun 11 16:12:46 <Abhishek_> jkridner: please do ask about the status of my board ship with her too
Jun 11 16:12:58 <alexanderhiam> jkridner: rseethamraju has had to deal with some unfortunate exam rescheduling, but we're meeting after this and we'll revise our game plan to make sure we get back on track
Jun 11 16:14:59 <jkridner> karki, panto, alexanderhiam: can we meet on Skype this Friday at this same time to discuss PRUSpeak?
Jun 11 16:15:09 <jkridner> Abhishek_: will do.
Jun 11 16:15:19 <jkridner> thanks alexanderhiam
Jun 11 16:15:24 <karki> jkridner : how about google hangouts ?
Jun 11 16:15:34 <jkridner> karki: k, google hangout.
Jun 11 16:15:36 <karki> :)
Jun 11 16:15:40 <jkridner> alexanderhiam, panto: ?
Jun 11 16:15:52 <alexanderhiam> problem with hangout is you lose the chat log once you close the window
Jun 11 16:16:07 <alexanderhiam> yeah, I could do this time
Jun 11 16:16:07 <_av500_> chat logs are archived
Jun 11 16:16:16 <_av500_> they are in your gmail
Jun 11 16:16:24 <karki> I have never used skype before :/
Jun 11 16:16:30 <ds2> Abhishek_: from a scheduling point of view, it might be useful to start looking at the UI using a 1 shot capture mode and revisit streaming later
Jun 11 16:16:32 <alexanderhiam> _av500_: what?!
Jun 11 16:16:38 <ds2> maybe add triggering in PRU
Jun 11 16:16:53 <_av500_> alexanderhiam: unless you set the "off the record flag"
Jun 11 16:17:21 <alexanderhiam> _av500_: hmm, that does sound like something I would do :P
Jun 11 16:18:02 <Abhishek_> ds2: streaming issues are almost started out, see screenshot. 33 MB/s with lzop compression on the received data
Jun 11 16:18:07 <Abhishek_> *sorted out
Jun 11 16:18:20 <panto> jkridner, probably
Jun 11 16:18:32 <_av500_> alexanderhiam: well, then its not logged
Jun 11 16:18:36 <ds2> k
Jun 11 16:19:06 <ds2> 'k
Jun 11 16:19:22 <jkridner> vmayoral|pc: that seems like it is 1:30 AM here, yes?
Jun 11 16:19:27 <jkridner> here = Eastern
Jun 11 16:19:56 <jkridner> panto: ok, thanks. it'll mostly be discussing the user-facing api.
Jun 11 16:20:49 <ds2> vmayoral|pc: Can you guys (for GSoC purposes), please use a stdnard open source system?
Jun 11 16:21:25 <jkridner> karki: the issue with the API you've created is it doesn't allow for immediate interpretation. the current BotSpeak uses STARTSCRIPT and ENDSCRIPT to create a routine, rather than assuming they are there.
Jun 11 16:21:26 <vvu> FOSS!
Jun 11 16:21:29 <_av500_> alexanderhiam: maybe I am wrong and that is only for gchat
Jun 11 16:21:38 <_av500_> I have old gtalk logs
Jun 11 16:21:38 <vmayoral|pc> jkridner: yeap. The schedule is not the most convenient but unfortunately we have to find a slot where people from Australia, India and Italy can have a meeting. Our meetings usually last around 2-3 hours
Jun 11 16:21:40 <jkridner> karki: we'll see what Chris feels about the usabilty.
Jun 11 16:21:43 <Abhishek_> jkridner: Done
Jun 11 16:21:50 <jkridner> thanks Abhishek_
Jun 11 16:21:57 <karki> hmm...
Jun 11 16:22:02 <alexanderhiam> _av500_: yeah, that's what it looks like to me
Jun 11 16:22:19 <_av500_> https://support.google.com/hangouts/answer/3115403?hl=en
Jun 11 16:22:34 <vmayoral|pc> jkridner: with "standard open source system" time you refer to the #beagle-gsoc meeting time?
Jun 11 16:23:02 <vmayoral|pc> jkridner: i could try proposing but i'm afraid it will not work for Andrew and the others
Jun 11 16:23:03 <jkridner> vmayoral|pc: would setting up a similar meeting time on Monday be tolerable? I don't see a way around adding an additional meeting and perhaps tool to try to push actions forward.
Jun 11 16:23:12 <rseethamraju> _av500_: thanks!
Jun 11 16:23:37 <jkridner> vmayoral|pc: did you mean to direct that to ds2?
Jun 11 16:24:07 <jkridner> ds2: isn't mumble open source?
Jun 11 16:24:24 <vmayoral|pc> jkridner: yes apologies, @ds2 it was answering your question
Jun 11 16:24:26 * ds2 google...
Jun 11 16:24:37 <ds2> maybe I am mixing up protocol...bb
Jun 11 16:25:01 <ds2> but that was more of referring to tunneling with skype, etc
Jun 11 16:25:14 <jkridner> ds2: ah. the google hangout would only be for the meeting with Chris Rogers, if that is your concern.
Jun 11 16:25:38 <ds2> okay, sorry, my bad... I definitely mixed it up with something else
Jun 11 16:26:19 <vmayoral|pc> jkridner: unfortunately i don't think that the Monday's meeting will work for the others (needless to say i am available for it). Still i could ask if you believe it's necessary.
Jun 11 16:26:31 <ds2> my concern is too many dman protocols when all we need to do is talk in an open fashion and make sure things are on track :D
Jun 11 16:26:59 <_av500_> like irc
Jun 11 16:27:10 <jkridner> ds2: for the additional meeting that I'm trying to have at a #beaglepilot friendly time, shall we stick to IRC?
Jun 11 16:28:10 <vmayoral|pc> jkridner, ds2: i'd suggest to use skype because of the logging capabilities. Take in account the time differences (i don't want to sound boring but this is a bit of an issue with beaglepilot)
Jun 11 16:28:47 <cdsteinkuehler> Signing off...
Jun 11 16:28:48 <jkridner> ds2, av500, Abhishek_, alexanderhiam, bradfa, panto, disdi_, joel_, karki, rseethamraju, vmayoral|pc, VoltVisionFrench, vvu: can we get a quorum on Mondays at 7:30 UTC+1 (1:30AM US Eastern Time) to try to make sure we are all getting together more often?
Jun 11 16:29:08 <disdi_> sure
Jun 11 16:29:13 <vmayoral|pc> count on me
Jun 11 16:29:30 <karki> ok
Jun 11 16:29:35 <_av500_> no problem
Jun 11 16:29:36 <panto> jkridner, my schedule is a bit hectic
Jun 11 16:29:37 <ds2> jkridner: yes, IMO -
Jun 11 16:29:38 <bradfa> jkridner, Mondays at 1:30am EDT works for me only if my younger daughter wakes up to eat at that time, otherwise that doesn't work for me, sorry
Jun 11 16:29:38 <Abhishek_> sure
Jun 11 16:29:39 <alexanderhiam> ok
Jun 11 16:29:40 <panto> I try to be on IRC
Jun 11 16:29:40 <rseethamraju> ok
Jun 11 16:29:42 <vvu> perfect
Jun 11 16:29:46 <panto> if I'm there, that's fine
Jun 11 16:29:57 <ds2> Oh btw - I am out hte next 2 weeks
Jun 11 16:30:08 <vvu> jkridner: can you send out a google invite ? or too much hassel?
Jun 11 16:30:12 <ds2> can't do 0430 PT :(
Jun 11 16:30:26 * jkridner sends out google invite.
Jun 11 16:30:44 <vvu> puurfect
Jun 11 16:30:44 <jkridner> ds2: sorry about that.
Jun 11 16:31:25 <Abhishek_> was the google invite meant for everyone?
Jun 11 16:31:28 <bradfa> jkridner, I think 7:30 UTC+1 is 2:30 EDT, but still, unlikely to work for me
Jun 11 16:31:51 <bradfa> sorry
Jun 11 16:32:20 <alexanderhiam> oh yeah, EDT is UTC-4 atm right?
Jun 11 16:32:27 <ds2> but with IRC, I can scroll and read logs :D
Jun 11 16:34:07 <karki> Abhishek_ : I doubt so.
Jun 11 16:34:31 <jkridner> I should also have resent the invite to this meeting.
Jun 11 16:34:55 <jkridner> bradfa: is it? :(
Jun 11 16:35:44 <jkridner> well, sent the invite for 1:30AM US Eastern.... hopefully Google calendar will do the right conversions and it is a useful time to get some extra cycles. perhaps more of a working meeting.
Jun 11 16:36:11 * jkridner sounds gavel of business, since I don't think anybody had any other organizational business.
Jun 11 16:36:33 <jkridner> all.... please continue to discuss any blocking issues.
Jun 11 16:37:04 <jkridner> rseethamraju: have you gotten people to run your code yet?
Jun 11 16:37:42 <rseethamraju> I’m not sure. alexanderhiam was going to do that
Jun 11 16:38:09 <vvu> if you need help for testing just shout, i have 2 beagles standing alone in my room
Jun 11 16:38:27 <alexanderhiam> jkridner: I've been testing her stuff as we go
Jun 11 16:38:34 <jkridner> VoltVisionFrench: thanks for the follow-up email with DiegoTc. I will try to call him if we don't hear from him in the next 24 hours.
Jun 11 16:39:02 <alexanderhiam> jkridner: helping her test it I should say
Jun 11 16:39:16 <VoltVisionFrench> jkridner, sounds good.  Ping me anytime.  Meanwhile I will keep trying to get him with the Guatemalan designers.
Jun 11 16:40:07 <alexanderhiam> rseethamraju, VoltVisionFrench: shall we hop over to skype now?
Jun 11 16:40:14 <rseethamraju> ok
Jun 11 16:40:20 <VoltVisionFrench> alexanderhiam, see you there!
Jun 11 16:41:46 <Abhishek_> jkridner: Things should be cleared up by this weekend, I did have to get a little off schedule with the kernel driver but it has given something good in the long run - control via sysfs attrs and reading captured data simply via character devices, so data can be captured through a very simple interface.
Jun 11 16:42:08 <Abhishek_> simpler than messing with libprussdrv
Jun 11 16:43:47 <ds2> Abhishek_: looks like btwn pantos and mranostay, things should be undercontrol for midterms?
Jun 11 16:45:03 <Abhishek_> yes, if the remoteproc driver cleanup does not break the interface, then it should be underway
Jun 11 16:46:09 <ds2> Abhishek_: if there is something specific to me that you need in the next 2 weeks, send me a email
Jun 11 16:46:50 <Abhishek_> k
Jun 11 16:47:00 <ds2> think that is the only project I am somewhat close to being a primary on
Jun 11 16:47:09 <karki> panto : I'm wondering about the concurrency issues alexanderhiam brought up. Like how to make sure 2 processes aren't going to use the PRU Speak at once etc. all the solutions I came up with were too complex :/
Jun 11 16:47:34 <panto> don't worry about it too much
Jun 11 16:47:51 <panto> you don't need to handle concurrency, only to return an error to the second one that tries to use it
Jun 11 16:48:07 <Abhishek_> mranostay: RFC on the driver screenshot when you are here :)
Jun 11 16:48:53 <ds2> karki: busy flag in kernel driver
Jun 11 16:49:03 <ds2> set on open, clear on close
Jun 11 16:49:09 <panto> right
Jun 11 16:49:20 <ds2> you are using a kernel driver, right? :D
Jun 11 16:49:22 <karki> ds2 : thanks, will look it up
Jun 11 16:49:28 <karki> ds2 : yes remote proc
Jun 11 16:49:31 <karki> base
Jun 11 16:49:32 <panto> atomic test and set/clear on flags
Jun 11 16:49:40 <panto> it's a non-issue then
Jun 11 16:56:07 <mranostay> Abhishek_: what screenshot?
Jun 11 16:56:21 <Abhishek_> the status update
Jun 11 16:56:36 <Abhishek_> mranostay: http://www.theembeddedkitchen.net/wp/wp-content/uploads/2014/06/Screenshot-from-2014-06-11-230119.png
Jun 11 17:04:56 <vvu> Abhishek_: you have full HD monitor ?
Jun 11 17:05:05 <Abhishek_> yep
Jun 11 17:05:17 <vvu> was wandering why the ss is so sharp
Jun 11 17:05:41 <vvu> the guys here at work gave a 19" :(
Jun 11 17:10:21 <_av500_> 19" phone?
Jun 11 17:10:40 <vvu> that would be nice :))
Jun 11 17:11:26 <Abhishek_> with a 16K UUHD screen
Jun 11 17:23:34 * karki wrote some more BS code........
Jun 11 17:24:54 <karki> *bot speak
Jun 11 17:30:02 <DiegoTc> hi jkridner, sorry for not being on todays meeting. I just answer to your email
Jun 11 19:18:52 <Abhishek_> hi pdp7
**** ENDING LOGGING AT Thu Jun 12 02:59:59 2014