**** BEGIN LOGGING AT Tue Jun 23 02:59:58 2015
Jun 23 03:59:52 * ebadawy got the comments back yaaaay!
Jun 23 04:20:07 <nerdboy> um, if you nuke something locally and then force-push it back it is really gone...
Jun 23 04:20:38 <nerdboy> need another clone or branch if you want to recover it
Jun 23 04:20:48 <ebadawy> reflog fixed it
Jun 23 04:21:16 <ebadawy> I'm now cherry picking on a separated branch
Jun 23 04:26:07 <nerdboy> reflog is kindof a last resort
Jun 23 04:28:20 <ebadawy> not sure that I got u, but what i did is that used reflog to get the state before using rebase and push it to github with -f
Jun 23 04:28:46 <ebadawy> and it worked!
Jun 23 04:29:56 <ebadawy> nerdboy: do u know how to cherry-pick a range of commits?
Jun 23 04:32:37 <nerdboy> isn't there a <hash>..<hash> format?
Jun 23 04:32:47 <ebadawy> not working
Jun 23 04:33:35 <nerdboy> think it's only inclusive on the recent end
Jun 23 04:34:15 <nerdboy> man git-cherry-pick ?
Jun 23 04:39:24 <nerdboy> how many commits is it?
Jun 23 04:40:12 <ebadawy> 50+ :) ,, but I guess  <hash>..<hash> format works ,, it's another error
Jun 23 04:40:16 <nerdboy> format looks like <commit-ish> <commit-ish> ...
Jun 23 04:41:29 <nerdboy> if it's not discontinuous there are other ways
Jun 23 04:42:49 <nerdboy> ie, cherry-pick is best for specific commits,  HEAD~2, <hash_id>, etc
Jun 23 04:43:06 <nerdboy> er, <commit_id>
Jun 23 04:44:12 <nerdboy> if you want to grab a full range of commits there may be better ways
Jun 23 04:44:38 <ebadawy> yea, what the case is there is some commits that jkridner want some changes on them ,, so I'm cherry picking all the good commits on another branch and the edit any possible one
Jun 23 04:45:58 <nerdboy> are you editing the "good" commits or the not-sogood ones?
Jun 23 04:46:08 <ebadawy> not-sogood ones
Jun 23 05:44:39 <Abhishek_> nerdboy: Yes, this is 4.1-rc8-bone9
Jun 23 05:49:42 <nerdboy> with or without extra patches is what i meant...
Jun 23 05:53:18 <Abhishek_> had to pull in some remoteproc files from 3.14 version
Jun 23 05:53:26 <Abhishek_> the 3.14-ti branch
Jun 23 06:01:52 <Abhishek_> shubhangi: with reference to libpru, general practice in (any) library is to avoid the use of printf inside library functions, make them return error codes instead ( see errno.h ).
Jun 23 06:08:01 <nerdboy> there is also kernel trace framework...
Jun 23 06:08:48 <Abhishek_> yeah, this comment here was made in reference to the userspace library part, not the kernel
Jun 23 06:12:09 <nerdboy> same thing applies
Jun 23 06:12:26 <nerdboy> for certain values of $thing...
Jun 23 06:14:26 <nerdboy> as in write a trace log file instead
Jun 23 06:15:39 <Abhishek_> yep, also could add something like #define DEBUG_printf
Jun 23 06:16:58 <nerdboy> that gets a little cluttered
Jun 23 06:18:00 <nerdboy> more than just a few anyway
Jun 23 15:33:51 <alexanderhiam> it's so quiet in here
Jun 23 15:34:45 <alexanderhiam> surely because everyone is busy getting there weekly reports in today!
Jun 23 15:41:15 * ebadawy won't get the weekly report late this time.
Jun 23 16:07:26 <shubhangi> Abhishek_: i have tried to improve the error handling in library and user programs. Can you have a quick look at the repo to see if its fine for 2morows evaluation.
Jun 23 16:09:05 <Abhishek_> pruss_shutdown still seems to print something
Jun 23 16:20:31 <shubhangi> wht shall i return if its not a standard errno ? -1 ?
Jun 23 16:36:55 <shubhangi> Abhishek_: are you able to cross compile 4.1 on your host ? mine throws an error in between
Jun 23 16:37:28 <shubhangi> what config do you use
Jun 23 16:38:21 <Abhishek_> Pastebin it
Jun 23 16:42:37 <shubhangi> http://pastebin.com/i6LH15Q9
Jun 23 16:43:23 <shubhangi> i used make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
Jun 23 16:47:25 <karki_> alexanderhiam : This GSoC it's so much more quieter than the last GSoC in general
Jun 23 16:49:06 <alexanderhiam> karki_: it sure is
Jun 23 16:49:21 * alexanderhiam has also been a lot more distracted this year!
Jun 23 16:49:24 <nerdboy> moin
Jun 23 16:50:03 <nerdboy> hopefully that means they are too busy ...
Jun 23 16:53:33 <karki_> alexanderhiam : yep, even mentors are barely active
Jun 23 16:54:54 * nerdboy has no previous data points for reference value
Jun 23 16:55:19 * karki_ has barely been online compared to last year......... mainly because he is not a student anymore :)
Jun 23 16:57:25 <karki_> nerdboy : the amount of traffic we have during wednesday meetings now, we used to have on every other day last year.
Jun 23 16:58:33 <alexanderhiam> have other mentors been communicating with students off irc?
Jun 23 16:58:43 <karki_> I have
Jun 23 16:58:49 <karki_> mainly private chat
Jun 23 16:58:59 <karki_> and email
Jun 23 17:01:05 <alexanderhiam> karki_: ah. Could you try to direct more of that through here?
Jun 23 17:01:25 <karki_> sure :p
Jun 23 17:01:40 <karki_> apaar : alexanderhiam wants you to talk here :D
Jun 23 17:02:23 <alexanderhiam> we really want to encourage all communication to go through here or the ml
Jun 23 17:02:23 <apaar> alexanderhiam, karki_ :i will try :)
Jun 23 17:02:44 <alexanderhiam> apaar: thanks
Jun 23 17:02:48 <karki_> it's not hard, you just have to type stuff and hit enter ;)
Jun 23 17:04:32 <apaar> alexanderhiam :have been trying to get the userpace backend api's up and running to start testing should be done in a bit :)
Jun 23 17:05:20 <alexanderhiam> apaar: cool, you been keeping your repo up to date on github?
Jun 23 17:06:42 <apaar> the driver is up to date i did not put userspace stuff as it was quite broken i commit once something is working and basic testing is done
Jun 23 17:07:55 <alexanderhiam> apaar: ok cool. And the sysfs API is all tested and working?
Jun 23 17:08:26 <apaar> are you refering to the sysfs handlers?
Jun 23 17:09:35 <alexanderhiam> yeah. I'm assuming since you're working on the userspace API that the sysfs entries are all working as expected
Jun 23 17:09:44 * alexanderhiam needs to get caught up on project statuses
Jun 23 17:10:14 <apaar> yes they work perfectly only i have not tested for junk/messed up data
Jun 23 17:10:38 <apaar> i am working on userspace right now testing it :)
Jun 23 17:11:02 <alexanderhiam> do you have a plan for testing things like data integrity?
Jun 23 17:11:22 <alexanderhiam> would be nice to see some unit tests at this point
Jun 23 17:11:55 <alexanderhiam> e.g. have some PRU firmware to echo back what you send it
Jun 23 17:12:42 <apaar> i have tested that i have also been able to move data both ways
Jun 23 17:13:46 <apaar> but you have to echo/cat to interact with the files so i thought of getting userspace api's up before more extesive testing
Jun 23 17:14:53 <alexanderhiam> cool. It would be great if you could add some test programs to the repo so it's easy for others to test as well. I would say some bash script tests would be good to have so you know if a userspace API test failing means a problem with the driver or just with the API
Jun 23 17:16:06 <alexanderhiam> e.g. if the userspace C write() function fails, is that C function broken, or is it the kernel driver, or the PRU firmware?
Jun 23 17:17:34 <apaar> cool i will get to it in a bit i was thinking of getting the basic api up(i have been having some sticky issues with it but sould be done in a hour or two)
Jun 23 17:19:13 <shubhangi> alexanderhiam: please do have a quick look at my repo to see if things in order https://github.com/shubhi1407/PRU-framework
Jun 23 17:19:21 <shubhangi> if you got time :)
Jun 23 17:19:31 <shubhangi> are in*
Jun 23 17:19:48 <alexanderhiam> apaar: sounds good. And if the issues persist definitely do push it so we can take a look and help out
Jun 23 17:20:14 <alexanderhiam> shubhangi: looking now...
Jun 23 17:20:32 <apaar> alexanderhiam : sure :)
Jun 23 17:23:35 <alexanderhiam> shubhangi, apaap: have you been staying in sync about how the framework and pru-bridge will fit together?
Jun 23 17:24:06 <shubhangi> i think we need to discuss more
Jun 23 17:25:08 <alexanderhiam> yes, please do
Jun 23 17:26:02 <shubhangi> apaar: ping. we should carry this discussion forward
Jun 23 17:26:48 <apaar> shubhangi :sure :)
Jun 23 17:26:50 <alexanderhiam> and be sure to do so here or on the ml!
Jun 23 17:26:55 <alexanderhiam> ;)
Jun 23 17:27:10 <shubhangi> sure thing
Jun 23 17:27:35 <shubhangi> better start a thread on ml .. things here get lost
Jun 23 17:30:39 <apaar> shubhangi :+1
Jun 23 17:31:03 <Abhishek_> shubhangi: first make *** bb.org_defconfig
Jun 23 17:31:08 <Abhishek_> then start compiling
Jun 23 17:31:28 <Abhishek_> (*** = ARCH, CROSS_COMPILE)
Jun 23 17:31:54 <nerdboy> got a patch and working config now?
Jun 23 17:32:22 <alexanderhiam> shubhangi: make sure it's clear in the pruss_remoteproc.c docs that it's an updated version. Ideally it should have a copyright of your own, then say it's derived from the original remoteproc driver then give the original copyright
Jun 23 17:32:24 * nerdboy gets ready for another proposal mtg...
Jun 23 17:32:45 <shubhangi> Abhishek_: okay :)
Jun 23 17:32:52 <shubhangi> alexanderhiam: ok. thanks :)
Jun 23 17:33:59 <alexanderhiam> that goes for all you students! Make sure your copyrights and licenses are all in place and up to date. If anything it's good practice
Jun 23 17:34:40 <alexanderhiam> basically any code without a copyright and license that's on github or anywhere else public is in the public domain
Jun 23 17:34:42 <Abhishek_> alexanderhiam, shubhangi: In case of writing to PRU memory, I was also considering exposing the PRU memory into userspace via mmap through a device file, but I think that makes it close to UIO .
Jun 23 17:35:13 <Abhishek_> s/considering/thinking of
Jun 23 17:35:50 <alexanderhiam> Abhishek_: that could certainly be useful
Jun 23 17:36:12 <Abhishek_> but wouldn't it be doing the same thing that UIO does as well?
Jun 23 17:36:20 <Abhishek_> libprussdrv and all
Jun 23 17:36:33 <shubhangi> yes. that is how they work
Jun 23 17:37:11 <alexanderhiam> I don't see that as a reason to not also include some memory mapping in an remoteproc framework
Jun 23 17:37:16 <alexanderhiam> perhaps as an option
Jun 23 17:37:46 <alexanderhiam> though there may be other more compelling reasons not to
Jun 23 17:37:47 <Abhishek_> panto-cloud: RFC.
Jun 23 17:37:49 <Abhishek_> ^
Jun 23 17:38:56 <Abhishek_> shubhangi: planning to do something with rpmsg/mailbox next?
Jun 23 17:39:51 <shubhangi> Abhishek_: setting aside code space restrictions ?
Jun 23 17:40:41 <Abhishek_> code space restrictions on the PRU?
Jun 23 17:40:47 <shubhangi> yes
Jun 23 17:41:11 <shubhangi> some library code has to go in at pru side as well
Jun 23 17:41:20 <Abhishek_> yep
Jun 23 17:41:48 <Abhishek_> how much space does that lib occupy in PRU mem?
Jun 23 17:41:56 <shubhangi> although i see ti was trying to implement vrings .. seems it is imcomplete
Jun 23 17:42:14 <shubhangi> incomplete*
Jun 23 17:42:37 <Abhishek_> have a link to that code?
Jun 23 17:43:36 <shubhangi> https://github.com/shubhi1407/PRU-framework/blob/master/firmware/resource_table_0.h#L45-L56
Jun 23 17:45:12 <Abhishek_> I see, did Suman had any comment regarding this?
Jun 23 17:45:17 <Abhishek_> *have
Jun 23 17:46:13 <shubhangi> see this .. https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/lib/pru_vring.c
Jun 23 17:48:47 <shubhangi> Abhishek_: Suman "FYI, we also have plans to move away from mailbox as it means latencies
Jun 23 17:48:47 <shubhangi> on the PRU-side in going to a peripheral outside its subsystem."
Jun 23 17:52:13 <Abhishek_> was that mentioned in the mail you posted on the group?
Jun 23 17:53:02 <shubhangi> no, this came before i added ml to cc
Jun 23 17:55:15 <shubhangi> this vring library looks good. shall i try to get it running ?
Jun 23 18:04:11 <Abhishek_> posted your status update about this week yet?
Jun 23 18:06:21 <shubhangi> not yet
Jun 23 18:11:31 <Abhishek_> In tomorrow's meeting, it'd be your (shubhangi) and azizulhakim's turn
Jun 23 18:40:13 <azizulhakim> Abhishek_: you mean status update on mailing list or during meeting?
Jun 23 18:40:41 <Abhishek_> I suppose during meeting
Jun 23 18:41:08 <azizulhakim> Okay
Jun 23 21:12:05 <ebadawy> jkridner: got my PR?
**** ENDING LOGGING AT Wed Jun 24 02:59:58 2015