**** BEGIN LOGGING AT Sat Apr 26 02:59:58 2014
Apr 26 04:16:15 <Abhishek_> morning
Apr 26 04:59:42 <karki> Abhishek_ : morning!
Apr 26 05:17:46 <karki> alexanderhiam : ping :)
Apr 26 15:10:05 <alexanderhiam> karki: hey
Apr 26 15:28:04 <_av500_> back
Apr 26 16:27:25 <karki> alexanderhiam : I just wanted to ask if you had used remote proc before...
Apr 26 16:27:43 <karki> sorry for the late reply!
Apr 26 16:27:46 <alexanderhiam> not yet, just uio
Apr 26 16:30:33 <alexanderhiam> looking through panto's example code now...
Apr 26 16:36:03 <karki> alexanderhiam : panto's code could use a readme. for a newbie like me, I have no clue whats going on!
Apr 26 16:36:46 <alexanderhiam> well technically it does have one :P
Apr 26 16:42:07 <alexanderhiam> it's a pretty big example, I'm looking for a smaller remoteproc demo
Apr 26 16:47:34 <alexanderhiam> karki: the docs in this one have some good info: https://github.com/pantoniou/testpru/blob/master/remoteproc.h
Apr 26 16:54:11 <alexanderhiam> hey mranostay
Apr 26 17:04:06 <alexanderhiam> karki: have you loaded a pru with uio?
Apr 26 18:03:53 * Abhishek_ wanders in
Apr 26 20:02:54 <mranostay> hi alexanderhiam
Apr 26 20:17:43 <karki> alexanderhiam : oops, sorry I was off! Yeah, I have tried the uio with pru before; but not nearly as much confusion there as I have with remote proc. UIO was more intuitive.
Apr 26 20:18:02 <karki> mranostay : hey!
Apr 26 20:18:05 <alexanderhiam> mranostay: why was it that your pru lighting code needs Koen's kernel again?
Apr 26 20:18:17 <karki> yep
Apr 26 20:18:42 <alexanderhiam> karki: a lot of the more complicated looking stuff with the remoteproc examples is the virtio code
Apr 26 20:19:18 <alexanderhiam> and setting up the vring buffer
Apr 26 20:19:42 <karki> alexanderhiam : oh yeah. I've been trying to figure how up calls and down calls take place for about two days now!
Apr 26 20:19:56 <karki> the whole package basically
Apr 26 20:20:52 <alexanderhiam> have you read up on the different components? (generally that is, not in terms of the PRU)
Apr 26 20:20:58 <karki> including virtio, sending signals etc. If i could study them separately rather in one big example, it'd be great
Apr 26 20:21:12 <alexanderhiam> gve this a read for starters: http://www.ibm.com/developerworks/library/l-virtio/
Apr 26 20:21:50 <karki> yeah! but I had a bit of confusion regarding how it was all implemented for the PRU.
Apr 26 20:21:52 <karki> http://omappedia.org/wiki/Design_Overview_-_RPMsg#remoteproc
Apr 26 20:23:17 <alexanderhiam> the kernel docs are good too: https://www.kernel.org/doc/Documentation/remoteproc.txt
Apr 26 20:24:08 <mranostay> alexanderhiam: uses remoteproc for the pru
Apr 26 20:24:26 <karki> mranostay : why remote proc and virtio, over UIO? what are the disadvantages for UIO?
Apr 26 20:24:57 <mranostay> idk sexier and more transparent
Apr 26 20:25:19 <mranostay> aka the LEDs are spidev device
Apr 26 20:25:27 <alexanderhiam> oh, is there no remoteproc PRU support in the mainline bb kernel yet?
Apr 26 20:27:04 <karki> alexanderhiam : the link I gave covers the kernel docs, actually it is based of the K docs
Apr 26 20:27:19 <alexanderhiam> without virtio you basically have to implement your on kernel <-> PRU communication scheme with the shared memory (afaik)
Apr 26 20:27:47 <alexanderhiam> own*
Apr 26 20:28:09 <mranostay> yeah not mainline at all
Apr 26 20:28:16 <karki> the UIO does give some sort of an interface, right? for shared memory?
Apr 26 20:28:28 <alexanderhiam> yeah
Apr 26 20:28:36 <alexanderhiam> and it passes some interrupts
Apr 26 20:28:42 <mranostay> yeah
Apr 26 20:28:48 <alexanderhiam> but virtio is much more robust
Apr 26 20:29:26 <alexanderhiam> karki: do you have the compiler?
Apr 26 20:31:53 <karki> yes
Apr 26 20:32:00 <karki> didn't use it though
Apr 26 20:32:02 <karki> not yet
Apr 26 20:35:31 <alexanderhiam> a good place to start would be to try compiling and running panto's and mranostay's code
Apr 26 20:37:01 <karki> mranostay : your code breaks with the new compiler, right ?
Apr 26 20:42:19 <karki> alexanderhiam, mranostay : how will passing around of interrupts work with virtio? how will the client side C program look?
Apr 26 20:49:27 <alexanderhiam> I'm not sure... if an interrupt fires in the PRU you may have to have a handler that catches it and puts a corresponding message in the vring buffer, afaik there's not a separate interrupt path of any sort
Apr 26 20:50:34 <karki> where will the handler be defined?
Apr 26 20:50:53 <alexanderhiam> in that case it would be in the PRU code
Apr 26 20:51:24 <alexanderhiam> so then on the kernel side you see the message in the vring buffer that X interrupt had fired
Apr 26 20:52:11 <alexanderhiam> of course I'm just making this up, that might be a terrible way to do it :P
Apr 26 20:54:23 <mranostay> karki: you don't want to use virtio for high data rates
Apr 26 20:55:01 <mranostay> aka driving 1024 LEDS at 80 fps :)
Apr 26 20:55:37 <karki> mranostay : I'm not looking at high data rates really, all I was wondering is what is the PRU wanted to give back some data to the client C program on ARM?
Apr 26 20:57:11 <karki> mranostay : say the ARM core had asked the PRU to do something, after doing the PRU had to signal the process and return a couple of bytes of memory.
Apr 26 20:59:41 <karki> alexanderhiam , mranostay : I will catch you guys tomorrow. It's 2:30AM,  have to get some sleep :P Thanks a lot for today!
Apr 26 21:01:11 <alexanderhiam> ok see you
**** ENDING LOGGING AT Sun Apr 27 03:00:01 2014