**** BEGIN LOGGING AT Tue Feb 03 02:59:58 2015
Feb 03 03:01:10 <karki> alexanderhiam : the PRU bridge is generic, has nothing to do with pruspeak as such!
Feb 03 03:01:47 <karki> look at the link I posted in my idea
Feb 03 03:02:52 <karki> There is a PRU side API which will enable users to develop their own firmware and communicate with the linux userspace.
Feb 03 03:04:23 <alexanderhiam> karki: yeah, on the same page there. I'm thinking the target should be an API that covers all the bridge stuff, including rpc and shared memory
Feb 03 03:05:08 <alexanderhiam> something like pruspeak could then be implemented with it
Feb 03 03:05:28 <karki> alexanderhiam : Thats how the project currently stands, right?
Feb 03 03:05:49 <karki> or did you understand it differently?
Feb 03 03:06:26 <alexanderhiam> right
Feb 03 03:07:25 <karki> alexanderhiam : (i) A easy way to have multi channel communication
Feb 03 03:07:38 <karki> (ii) have higher level API's for RPCs etc
Feb 03 03:07:56 <karki> what I have explained in the pru_serial readme page is only (i)
Feb 03 03:08:14 <karki> alexanderhiam : I'd love a pull request with your addons :)
Feb 03 03:09:09 <alexanderhiam> yeah, I need to gather and write down my thoughts on this
Feb 03 03:09:37 <karki> Once you do that, I will update the ideas page to
Feb 03 03:09:52 <karki> as of now both the ideas on a new driver seems vague
Feb 03 03:10:18 <karki> I don't think I have managed to give a good high level view
Feb 03 03:10:25 <karki> have to change that
Feb 03 03:10:33 <alexanderhiam> I'll work on that tomorrow (EST tomorrow that is)
Feb 03 03:11:17 <karki> and abhisheks does not explain much on how the implementation should be, or rather along what lines the student should think along
Feb 03 03:11:29 <karki> We have to merge this idea at some point of time
Feb 03 03:11:46 <karki> that can be done based on how many students apply
Feb 03 03:12:07 <karki> I already got mails from 2 students who were interested to work on pruspeak
Feb 03 03:12:17 <alexanderhiam> great
Feb 03 03:12:17 <karki> but redirected them to pru bridge
Feb 03 03:12:39 <alexanderhiam> we should get jkridner up to speed on this plan soon
Feb 03 03:13:21 <karki> so (i) figure out what we want the driver to do. (ii) an effective way to get to LKML ( I guess this is what Abhishek is mainly interested in ;) )
Feb 03 03:13:43 <karki> Then we can split it properly into 2 projects if reqd.
Feb 03 03:13:59 <karki> or minimize the work to be done for one student, etc
Feb 03 03:14:08 <karki> as of now, let both the projects stand
Feb 03 03:14:50 <alexanderhiam> sounds good
Feb 03 03:14:56 <alexanderhiam> ok I gotta run
Feb 03 03:15:06 <alexanderhiam> talk soon
Feb 03 15:22:41 <Abhishek_> evening
Feb 03 15:30:02 <Abhishek_> karki__: Implementation is up to the student to work out details. I just gave high level design guidelines for them to think on.
Feb 03 15:37:26 <karki_> yeah, the problem is that no new comer will know what we need and how to go about it.
Feb 03 15:37:47 <karki_> My only concern is ending up with something no one can use
Feb 03 16:39:21 <Abhishek_> which is also a valid concern
Feb 03 17:58:16 <karki_> Abhishek_ : any ideas on how to accommodate a plugin system in the kernel for the new pruss driver?
Feb 03 17:58:39 <karki_> I didn't like what I did for pruspeak.....
Feb 04 00:16:08 <Abhishek_> karki: It's better to put it down in code than just speculate
Feb 04 00:16:44 <ds2> how's our idea lists coming along?
Feb 04 00:19:16 <Abhishek_> there are two PRU design ideas, I guess you saw the thread
Feb 04 00:23:00 <ds2> wonder if there are any interest in a project to figure out the EDMA stuff for the PRU
Feb 04 00:24:21 <Abhishek_> I personally think that if a framework for PRU based drivers evolves then any kind of driver can be written out easily.
Feb 04 00:24:48 <ds2> that has kind of been done
Feb 04 00:25:09 <ds2> but there doesn't seem to be any docs for EDMA so any large xfers has to burn the other PRU
Feb 04 00:25:37 <Abhishek_> I see
Feb 04 00:25:52 <ds2> you did your xfers to DDR using the other PRU, right?
Feb 04 00:25:58 <Abhishek_> yeah
Feb 04 00:27:24 <ds2> the EDMA should be able to do that for you. EDMA is more or less a processor that knows how to do memcpy's
Feb 04 00:28:00 <Abhishek_> is EDMA supported by the kernel. I mean, do the other devices or periphs use it?
Feb 04 00:29:55 <ds2> i think so
Feb 04 02:09:30 <vvu_> ds2: any idea for android based projects or so ?
**** ENDING LOGGING AT Wed Feb 04 02:59:58 2015