**** BEGIN LOGGING AT Sun May 11 03:00:00 2014 May 11 10:24:00 av500: vvu|Log Uploaded the video. May 11 10:24:27 https://www.youtube.com/watch?v=gWzg2dJ0tfA May 11 19:22:39 panto: Hi. Wanted to know how my logic analyzer firmware can benefit from remoteproc. Had been reading your and mranostay's lighting ex. today, understood a a few parts but I needed a little help with understanding vrings May 11 19:23:30 Abhishek_, May 11 19:24:33 vrings is the native kernel high-speed interface between processors that are part of the same memory address space May 11 19:25:12 their regular use is as the data transport interface for communication between vm instances May 11 19:25:34 i.e. kvm's serial/network and block device implementations use them May 11 19:30:42 What would be the benefits in case of the logic analyzer if it uses vrings instead of UIO mmap to send data to the libsigrok bindings? May 11 19:33:46 UIO mmap is not coherent May 11 19:34:13 I mentioned that before May 11 19:34:35 so everytime you communicate with the PRU you'll have to flush/invalidate caches as appropriate May 11 19:38:58 Where can I find a linux application for the BB (like the pru fw package) that communicates with PRU through vrings? The example PRU firmware are communicating through minicom on the BB side May 11 19:42:21 Also, a few things have changed on the new CLPRU 2.0that lead to issues with code compilation. This was being discussed yesterday too. May 11 19:43:00 *CLPRU 2.0.0B2 May 11 19:43:00 there is no user-space application that uses vrings ATM May 11 19:43:17 well, you have the sources, first order of business is to fix it May 11 19:44:43 Okay, could you direct me to something I could start fiddlling with to create a userspace vring app? May 11 19:46:08 there is nothing more that what the testpru example application and the kernel driver does May 11 19:46:26 you won't find something already there May 11 19:46:36 all this stuff is brand new May 11 19:47:42 define your requirements May 11 19:47:48 1) user-space application May 11 19:47:56 2) PRU application May 11 19:48:06 3) mappings for the shared memory area May 11 19:48:36 4) transfer method (where are the data located and how each end figures out how to get them) May 11 19:49:15 5) signaling method (how to let each end know that new data are available. buffer space has been consumed) May 11 19:53:51 ok, got to take off May 11 19:54:15 Okay May 11 20:14:59 Abhishek_ : you will have to develop your own device driver if you want to use remote proc May 11 20:15:14 and in your case I assume the driver will be quite complex May 11 20:16:02 There is a lot to be considered to infact expose a userspace interface for remoteproc and virtio May 11 20:16:40 over that communication of data is another pain. May 11 20:16:54 plus not to mention upcalls and downcalls May 11 20:17:50 The ONLY problem with all this is that its really new and there are barely any resources. (and rightly so, it is my main cause of worry :( ) May 11 20:43:59 mranostay : Is there an alternative to vrings? In the case of my project I need to transfer code fragments/data to and fro : ARM <--> PRU May 11 20:44:31 is there some way I can handle the memory myself rather than use vrings? May 11 20:48:47 karki: yes what i do for the pru transfre for led data May 11 20:48:59 syscalls + ioctls May 11 20:49:14 you can't use vrings for such a high data rate May 11 20:58:30 mranostay : Thanks! which is the driver you are using for this purpose? May 11 21:02:37 look at the changes to pru-remoteproc.c May 11 21:07:16 mranostay : is this the one? 3.8/drivers/remoteproc/pru_rproc.c May 11 21:07:41 it's the only one that seems close to what you mentioned! May 11 21:08:18 yes May 11 21:08:39 have fun with the old kernel... May 11 21:09:17 old kernel? May 11 21:25:33 mranostay : is there a new one? **** ENDING LOGGING AT Mon May 12 02:59:59 2014