**** BEGIN LOGGING AT Mon Jun 02 02:59:59 2014
Jun 02 03:44:15 <mranostay> karki: fixed my pru lighting example this weekend
Jun 02 03:44:29 <karki> :D
Jun 02 03:44:57 <mranostay> rahter simple
Jun 02 03:45:08 <mranostay> a few kernel changes needed though
Jun 02 03:46:16 <karki> mranostay : I'm looking at it now
Jun 02 03:46:30 <karki> mranostay : what kind of kernel changes?
Jun 02 03:47:47 <mranostay> forwarding
Jun 02 03:48:23 <mranostay> karki: do i have your email?
Jun 02 03:48:40 <karki> deepak6k@gmail.com
Jun 02 03:49:10 <karki> got it :)
Jun 02 03:49:38 * mranostay needs to bike
Jun 02 04:33:07 <karki> mranostay : were you a gsoc student once upon a time?
Jun 02 04:34:47 <av500> no
Jun 02 04:38:34 <mranostay> barely a student even.. but no
Jun 02 04:42:40 <av500> mranostay: you did finish pre-school though, no?
Jun 02 04:44:10 <mranostay> av500: bite me :)
Jun 02 04:44:34 <mranostay> ok off to bike 9.9 miles
Jun 02 04:44:41 <av500> make it 10
Jun 02 04:45:22 * mranostay gives 101% 
Jun 02 04:46:49 <av500> attaboy
Jun 02 04:51:55 * karki needs to get out of the house more often :/
Jun 02 05:19:08 * vvu needs to buy a bike also
Jun 02 05:22:31 * karki thinks it has been a long time since he last used his fire fox.... 
Jun 02 05:47:40 <Abhishek_> mranostay: back after biking?
Jun 02 06:56:39 <Abhishek_> panto: Is there a way I can get 8 discontinuous DMA-coherent buffers map to a contiguous VM region?
Jun 02 06:57:54 <panto> back
Jun 02 06:58:19 <panto> not without messing with the page tables
Jun 02 07:19:27 <Abhishek_> panto: any other changes to be done apart from changing pru_rproc from 'y' to 'm' to make it a loadable module?
Jun 02 07:20:48 <panto> not in theory
Jun 02 07:21:38 <Abhishek_> a few days back I had attempted the same, but got an error. I'm building the kernel again, will let you know if the error occurs again
Jun 02 07:25:22 <panto> bb in a few hours
Jun 02 07:57:12 <Abhishek_> panto: This error I get while attempting to build as a kernel module: https://gist.github.com/abhishek-kakkar/f01102d84d2ad91d24f9
Jun 02 08:02:20 <Abhishek_> panto: the error got fixed, copied pruss_dt_ids from uio_pruss.c into the rproc module. This was ignored when the module was compiled in, but resolved to an unfound symbol when built as a module
Jun 02 08:11:51 <karki> I just commented that line out ;)
Jun 02 08:23:45 <Abhishek_> it is infact commented out while being compiled in (as I wrote above) :), only comes into effect when compiling as a module
Jun 02 08:31:19 <karki> I always used it as a module, much easier :)
Jun 02 08:39:39 <karki> It's not commented out in the source is it? By ignored did you mean no error shows up, or something else?
Jun 02 08:39:54 <Abhishek_> it's a blank #define
Jun 02 08:46:52 <karki> lol!
Jun 02 15:33:16 <Abhishek_> panto: how can capemgr-loaded cape configs be unloaded?
Jun 02 15:34:00 <panto> configs?
Jun 02 15:35:16 <Abhishek_> nope, not exactly configs, but if a resource is being used by one cape, then is it possible for another cape to be loaded through capemgr that will override the previous settings?
Jun 02 15:35:27 <Abhishek_> (the PRUs in this case)
Jun 02 15:35:57 <Abhishek_> rephrasing, can capes be unloaded on-the-fly?
Jun 02 15:37:05 <panto> no it can't
Jun 02 15:37:20 <panto> there's resource conflict resolution for capes
Jun 02 15:37:35 <panto> and capes can be indeed unloaded
Jun 02 15:37:47 <panto> but whether the drivers support unloading is another matter
Jun 02 15:38:26 <Abhishek_> okay, to unload a cape, I would have to?
Jun 02 15:41:32 <Abhishek_> nvm, got it
Jun 02 15:45:51 <vvu> how is it going ?
Jun 02 15:55:13 <karki> Hello vvu :)
Jun 02 15:55:24 * karki just fought with a king cobra.
Jun 02 15:55:44 <Abhishek_> with a cape ;)
Jun 02 15:55:59 <vvu> hello karki
Jun 02 15:56:27 * vvu now switched from vim, i3, mutt to notepad++, Windows, outlook :( so sad
Jun 02 15:56:43 <karki> terrible storms in bangalore ;) huge snake in my house
Jun 02 15:56:59 <vvu> put the beagle to the rescue
Jun 02 15:57:03 <karki> it ran away now, terrible internet too.
Jun 02 15:57:05 <karki> :(
Jun 02 15:58:27 <karki> If I finish this project successfully, I'll feel like a black belt  expert. (I'll be called pru-ce lee ;) )
Jun 02 16:00:07 <vvu> so nice here, need to bypass all firewalls to access smth via ssh
Jun 02 16:02:21 <karki> where are you placed right now vvu?
Jun 02 16:05:07 <vvu> somewhere in Munich, Germany
Jun 02 17:34:14 <Abhishek_> panto: Once I have allocated a chunk of mem using dma_alloc_coherent and mmap'ed it, what do I have to it to take care of cache coherency now?
Jun 02 17:35:08 <mranostay> panto: hmm i wonder if the pru capes can be unloaded?
Jun 02 17:35:11 <mranostay> i suspect not
Jun 02 17:35:53 <Abhishek_> I did not have quite luck in unloading the UIO cape and inserting a remoteproc cape. Had to reboot
Jun 02 17:36:51 <karki> pru capes can't be unloaded
Jun 02 17:36:57 <karki> CAN'T
Jun 02 17:37:12 <karki> damn system keeps crashing :'(
Jun 02 17:37:18 <karki> every time I try
Jun 02 17:37:23 <mranostay> Abhishek_: well that for sure wouldn't work
Jun 02 17:37:43 <mranostay> then again i never have a reason to change the firmware
Jun 02 17:37:53 <karki> like Abhishek_ I had to reboot
Jun 02 17:39:10 <Abhishek_> mranostay: if the device tree contains no virtio mentions, then I wouldn't be troubled by that, correct?
Jun 02 17:39:29 <karki> It's some problem with to do with the driver I believe
Jun 02 17:39:55 <karki> I'll see whats wrong. Its giving me way too much trouble.
Jun 02 17:42:52 <mranostay> ah not sure
Jun 02 17:43:10 <mranostay> check the driver probe()
Jun 02 17:44:50 <karki> I think the problem is with the remove
Jun 02 17:45:35 <panto> dma_alloc_coherent is supposed to be non-cached
Jun 02 17:47:00 <Abhishek_> panto: could this stackov question be relevant here? http://stackoverflow.com/questions/21700236/strange-behaviour-using-mmap
Jun 02 17:47:33 <Abhishek_> the kernel and toolchain are quite old though
Jun 02 17:48:14 <karki> maranostay panto : I got my own program PRU program loaded with my driver (custom version of rproc and DTS). + bin attribute sysfs entries are also created. I will work on upcalls and down calls + shared memory tomorrow.
Jun 02 17:49:12 <karki> dma_alloc_coherent looks non cached as far as a remote precessor is not involved.
Jun 02 17:49:20 <karki> *processor
Jun 02 17:49:54 <karki> If you are working across processors, explicit flushing is reqd.
Jun 02 17:50:50 <panto> Abhishek_, Documentation/DMA-API-HOWTO.txt
Jun 02 17:55:18 <panto> cool
Jun 02 17:59:00 <karki> panto : are you available tomorrow?
Jun 02 18:00:33 <panto> probably
Jun 02 18:02:50 <Abhishek_> panto: From the docs, does it mean that I would have to do dma_sync_single_for_cpu from the ISRs to ensure the bytes are readable?
Jun 02 18:03:04 <Abhishek_> *I mean, caches are sync'd
Jun 02 18:03:29 <panto> I don't think so
Jun 02 18:03:50 <panto> the way I read it is that alloc_coherent will return a dma-able region of memory
Jun 02 18:05:25 <karki> panto : is the memory block consistent across processors too?
Jun 02 18:05:29 <panto> the whole 'remote processor bit' is about when you have somekind of IOMMU
Jun 02 18:05:40 <panto> and a coherent interconnect
Jun 02 18:05:48 <panto> in our context
Jun 02 18:05:56 <panto> there is no such thing
Jun 02 18:06:12 <panto> so the memory must be uncached
Jun 02 18:07:29 <karki> Hmm... looks like I understood things a bit wrong.
Jun 02 18:08:28 <Abhishek_> panto: to disable virtio, is it sufficient to remove it from the dts, what all would I have to clean up (not, as in removing any part of the code, but to ensure that vrings do not disturb stuff)?
Jun 02 18:09:01 <panto> karki, don't trust me, verify :)
Jun 02 18:09:11 <panto> follow the code around and find out what mapping are installed
Jun 02 18:09:38 <panto> Abhishek_, can't remember exactly
Jun 02 18:09:43 <panto> remove it and see what goes on
Jun 02 18:12:25 <panto> hmm, I think the problem is that when you mmap the dma_alloc_coherent area you are creating duplicate mappings, hence error
Jun 02 18:12:46 <panto> Abhishek_, http://lwn.net/Articles/486301/
Jun 02 18:13:32 <karki> wait, which error are we talking about?
Jun 02 18:13:42 <panto> the stack overflow link
Jun 02 18:13:51 <karki> oh!
Jun 02 18:13:52 <karki> ok
Jun 02 18:16:06 * karki shuts down. long day.
Jun 02 18:16:49 <Abhishek_> g'night karki
Jun 02 18:17:13 <panto> and one thing you can use, is that you can override the default dma mapping functions
Jun 02 18:17:44 <panto> so the PRU driver can make sure that the dma memory returned is correct and with the right cache access flags
Jun 02 19:44:36 <Abhishek_> panto: any suggested reading on custom dma mapping functions?
**** ENDING LOGGING AT Tue Jun 03 02:59:58 2014