**** BEGIN LOGGING AT Sun May 17 02:59:58 2015
May 17 05:18:55 <shubhangi> panto, karki_ :ping
May 17 05:19:09 <karki_> shubhangi : pong
May 17 05:19:46 <shubhangi> karki_ : https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-kernel-driver/BB-BEAGLELOGIC-00A0.dts#L216-L244
May 17 05:19:59 <shubhangi> in line 223
May 17 05:20:23 <shubhangi> the address for dram of other PRU is taken to be address of shared dram
May 17 05:20:49 <shubhangi> in line 243 as well
May 17 05:21:50 <karki_> hmm
May 17 05:21:55 <karki_> I'll have a look
May 17 05:22:09 <shubhangi> karki_: k .. thanks
May 17 05:38:06 <vvu> morning!
May 17 05:55:57 <karki_> shubhangi : nope, it's correct
May 17 05:56:13 <shubhangi> could you please explain
May 17 05:56:24 <karki_> I didn't get what your doubt was
May 17 05:56:30 <karki_> It's pretty much as expected
May 17 05:57:16 <shubhangi> karki_: i'll try to explain
May 17 05:57:47 <shubhangi> https://github.com/beagleboard/linux/blob/3.8/drivers/remoteproc/pru_rproc.c#L2764-L2768
May 17 05:58:07 <shubhangi> ppc->dram_oda = tmparr[3];
May 17 05:58:20 <shubhangi> ppc is the individual PRUs struct
May 17 05:58:49 <karki_> oh I get it
May 17 05:58:54 <shubhangi> and dram_oda ie other PRUs dram address must be stored here
May 17 05:59:55 <shubhangi> ie ppc->dram_oda =  0x0000_0000 if its PRU 1's struct
May 17 06:00:24 <shubhangi> and ppc->dram_oda = 0x0000_2000 for PRU 0's struct
May 17 06:01:11 <shubhangi> but as of now it takes ppc->dram_oda = 0x0001_0000 for either structures from the device tree
May 17 06:04:00 <karki_> I see
May 17 06:14:28 <ds2> there is the dram and there is the shared mem
May 17 06:14:48 <ds2> shared mem is at 10000h
May 17 06:15:29 <ds2> dram is at 00000 for the current running pru and 02000h for the other pru
May 17 06:23:11 <shubhangi> ds2: yes. thats where the device tree's wrong . it gives the address for other PRU's dram as shared mem address
May 17 06:23:40 <shubhangi> ds2: https://github.com/deepakkarki/pruspeak/blob/master/src/dts/BB-PRUSPEAK-00A0.dts#L298-L306
May 17 06:24:23 <shubhangi> https://github.com/deepakkarki/pruspeak/blob/master/src/dts/BB-PRUSPEAK-00A0.dts#L298-L306
May 17 10:46:40 <Abhishek_> Gm
May 17 11:52:55 <shubhangi> Abhishek_: ping
May 17 11:53:16 <Abhishek_> shubhangi: pong
May 17 11:53:57 <shubhangi> Abhishek_:  can you please clear my doubt
May 17 11:54:10 <shubhangi> Abhishek_: discussed above
May 17 11:54:30 <shubhangi> http://logs.nslu2-linux.org/livelogs/beagle-gsoc.txt
May 17 11:58:15 <Abhishek_> shubhangi: So the PRU subsystem has 3 data RAMs
May 17 11:58:27 <shubhangi> Abhishek_: yes, i get that
May 17 11:58:37 <Abhishek_> One 8 KB block for each PRU, and a shared 12KB area
May 17 11:58:42 <shubhangi> yes
May 17 11:59:09 <shubhangi> when i say other PRUs dram it is taking shared mem address
May 17 11:59:18 <shubhangi> thts the issue
May 17 11:59:32 <shubhangi> https://github.com/deepakkarki/pruspeak/blob/master/src/dts/BB-PRUSPEAK-00A0.dts#L243-L251
May 17 11:59:44 <shubhangi> line 250
May 17 12:00:22 <Abhishek_> https://github.com/beagleboard/linux/blob/3.8/drivers/remoteproc/pru_rproc.c#L2764-L2768
May 17 12:00:51 <shubhangi> Abhishek_: yes, ppc->dram_oda = tmparr[3];
May 17 12:01:03 <shubhangi> other_device_address
May 17 12:01:16 <shubhangi> not the shared mem as it gets from the dts as of now
May 17 12:01:31 <shubhangi> dram = <0x00000 0x02000 0x00000 0x10000>
May 17 12:03:14 <shubhangi> 0x10000 is the address of shared mem
May 17 12:04:08 <shubhangi> where as for pru0 node in dts this last entry should have been 0x02000 ie pru1's dram
May 17 12:05:15 <shubhangi> can be validated here https://github.com/beagleboard/linux/blob/3.8/drivers/remoteproc/pru_rproc.c#L368-L373
May 17 12:05:46 <Abhishek_> also: https://github.com/beagleboard/linux/blob/3.8/drivers/remoteproc/pru_rproc.c#L359
May 17 12:06:03 <Abhishek_> ah
May 17 12:06:40 <shubhangi> i may be completely wrong here... just couldnt get the anomally
May 17 12:06:57 <Abhishek_> look at the pdram values as well
May 17 12:07:03 <shubhangi> thts correct
May 17 12:07:05 <shubhangi> checked
May 17 12:07:26 <shubhangi> the pruss struct takes the shared meme address correctly into pdram
May 17 12:07:32 <shubhangi> ie 0x10000
May 17 12:08:15 <Abhishek_> Could you make a test case and verify this?
May 17 12:08:29 <Abhishek_> where the data is getting written?
May 17 12:09:03 <shubhangi> can be done .. have to think upon it
May 17 12:36:09 <shubhangi> Abhishek_: which memory did beaglelogic write all data to ? the main ddr mem ?
May 17 12:36:29 <shubhangi> during continuous capture
May 17 12:38:34 <Abhishek_> shubhangi: yes, it always wrote to the DDR Mem
May 17 12:38:47 <Abhishek_> However the addresses were in the PRU SRAM
May 17 12:38:58 <Abhishek_> the 8 KB RAM
May 17 12:39:09 <shubhangi> the driver put the addresses there
May 17 12:39:10 <shubhangi> ?
May 17 12:39:25 <Abhishek_> yeah, the kernel driver
May 17 12:39:28 <shubhangi> okay
May 17 13:17:45 <shubhangi> Abhishek_: all the data is written and after that ARM is signaled right ?
May 17 13:18:15 <Abhishek_> shubhangi: No, usually in units of 4 MB
May 17 13:18:27 <shubhangi> via syscalls ?
May 17 13:19:44 <Abhishek_> no
May 17 13:20:22 <shubhangi> then how is arm informed abt the write operation completion
May 17 13:21:21 <Abhishek_> it's an interrupt, but not a syscall. Look at the interrupt being handled in the kernel module
May 17 13:21:27 <shubhangi> okay
May 17 13:21:32 <shubhangi> thanks
May 17 13:28:11 <shubhangi> Abhishek_: how's the internship going ?
May 17 13:28:30 <Abhishek_> good, the office is nice
May 17 13:28:49 <Abhishek_> and the work env as well
May 17 13:29:36 <shubhangi> does TI offer PPO ?
May 17 13:29:43 <Abhishek_> I pass by the Oracle India office everyday on the way, it's two buildings away  :)
May 17 13:30:06 <shubhangi> kalyani magnum ?
May 17 13:30:56 <shubhangi> bannerghta smthing
May 17 13:31:50 <Abhishek_> no, my office is at Bagmane tech park
May 17 13:33:31 <Abhishek_> it seems they have multiple offices
May 17 13:36:45 <shubhangi> yes
**** ENDING LOGGING AT Mon May 18 02:59:59 2015