**** BEGIN LOGGING AT Wed Mar 04 02:59:58 2015 Mar 04 04:37:32 jkridner: could you add me to the list of possible / support mentors for remote display ? As a reference would be fine too. Mar 04 04:38:23 I'm also planning to work on it out of GSoC scope. Mar 04 04:55:00 Updated. Mar 04 05:01:43 hi praveendath921: I tried installing kernel header from http://rcn-ee.net/deb/precise-armhf/v3.8.13-bone47/ Mar 04 05:02:19 ans when I trye to compile the adk module inside bone, it says "fatal error: mach/timex.h: no such file or directory Mar 04 05:02:47 Headers should be based on the version of your OS on Bone. Mar 04 05:03:28 I checked with "uname -r" which gave me 3.8.13-bone47 Mar 04 05:03:36 so I selected this header Mar 04 05:04:12 Okay. That's correct. Mar 04 05:04:24 I can't remember that error. Mar 04 05:05:05 okay, i'll do some more search Mar 04 05:05:37 https://groups.google.com/forum/#!topic/beagleboard/1IkTdkdUCLg Mar 04 05:11:15 great. able to compile. I'll do some test and let you know the result Mar 04 06:28:42 azizulhakim: Sure. I will be leaving in a few hours for an exam. Mar 04 08:09:17 anyone online Mar 04 08:28:46 GSOC 15 Interested in project : node-webkit based cross-platform getting-started app Mar 04 08:32:42 Abhishek_: sorry couldn't reply earlier. was out for 4 days Mar 04 08:40:22 who is the mentor assigned to the project "Library_of_Arduino-compatible_functions_for_StarterWare" Mar 04 08:40:32 with whom i can start with !!! Mar 04 12:15:24 karki: As I tested the blinkled program .. and it is working perfectly.. Mar 04 12:18:05 Also, jkridner suggested me to merge the starterware library for pru in the pruspeak repo OR create a new standalone repo for it. Which one is better ? Mar 04 12:22:19 Hi! I would like to work on node-webkit cross platform app as GSOC-15 project. Where can I start up with? Mar 04 12:56:52 karki: As I tested the blinkled program .. and it is working perfectly.. Mar 04 12:57:05 Also, jkridner suggested me to merge the starterware library for pru in the pruspeak repo OR create a new standalone repo for it. Which one is better ? Mar 04 13:12:36 I don't think thats what jason meant Mar 04 13:13:02 you just can't take someone's library and merge it where ever you like Mar 04 13:14:04 OK.. Then what would you like me to do ? Mar 04 13:15:42 well, this is proposal time Mar 04 13:16:37 now that you have some experience on various stuff, try to identify the area to work upon Mar 04 13:17:05 come up with a proposal and file it when application opens Mar 04 13:17:31 But right now I must also contribute...right ? Mar 04 13:19:50 For the last time! I WILL NOT ENTERTAIN ANY PMs. Mar 04 13:20:47 kiran4399 : did you run the code bare metal, or did you run it with linux Mar 04 13:22:01 I ran it with linux Mar 04 13:35:05 what device tree did you use? Mar 04 13:49:46 Can any1 explain how assessment of the real-time limitations and capabilities will be done for RTLinux project? Mar 04 14:07:57 hii Mar 04 14:12:04 karki: +1 to no PMs! Mar 04 14:13:06 kiran4399: I agree with Abhishek_ that what you want to focus on is your proposal. Early contribution is good to get your feet wet, build relationships and illustrate ability to use tools and work on code. Mar 04 14:13:58 jkridner: oh, wow, hi, jkridner. Mar 04 14:14:07 hi zoorg Mar 04 14:14:17 you looking to participate in gsoc this year? Mar 04 14:14:21 jkridner: yep Mar 04 14:14:45 jkridner: I'm interested, mostly, in Userspace Arduino project. Mar 04 14:14:47 * jkridner is happy to see #beagle-gsoc reasonably full. Mar 04 14:15:04 reminder: we have a meeting in 2.75 hours. Mar 04 14:15:17 but it seems like no one knows nothing about it. Mar 04 14:15:38 zoorg: cool. the mentor for that has moved on, so we'd need to find a new one for it. Mar 04 14:16:11 2.75. That's bad. I'm UTC +10, it's already too late for me. :/ Mar 04 14:16:25 * jkridner visits http://bit.ly/bbgsocideas to see what is the latest Mar 04 14:16:52 zoorg: ah, targeting Tre is what is up there! Mar 04 14:17:11 we should ping some of the Arduino guys to see if they are interested in helping to mentor that one. Mar 04 14:17:16 jkridner: hell yeah! finally some info. :) Mar 04 14:18:24 jkridner: so, can we somehow syncronize our timings, so I could speak with u later? Mar 04 14:18:36 we are both on-line now. Mar 04 14:19:45 I see, but I have no more than 20 minutes more now. Mar 04 14:19:51 jkridner: OK! I agree with you.. so should I start off with the plan and description of how I would want to do the project or should I focus on some other part in the proposal ? Mar 04 14:20:00 BTW: project is PRUduino Mar 04 14:20:27 Hello everyone! Mar 04 14:21:05 kiran4399: try a high-level set of milestones, say about 1 every 2 weeks... share the info in an e-mail on the list and then come here to ask it to be reviewed. Mar 04 14:21:53 would there be enough to pruduino for it to be a project by itself? Mar 04 14:21:57 jkridner: So, can you give me any details and further directions about UA? Mar 04 14:22:21 jkridner: As I see it's already 3rd time this (or similar) idea presented. Mar 04 14:22:22 do you have a BeagleBone Black by any chance already? (not needed if you don't have one) Mar 04 14:22:33 Or an Intel Galileio. Mar 04 14:22:48 jkridner: me? Nope. :/ Mar 04 14:22:57 k. Mar 04 14:23:04 zoorg: Do you have a Linux PC? Mar 04 14:23:34 jkridner: of course. Mar 04 14:23:42 great! Mar 04 14:23:49 jkridner: using linux as my main system for a long time. Mar 04 14:24:00 not sure on a typical Linux PC how many of the interfaces would actually be available. Mar 04 14:24:09 I have RPi. Mar 04 14:24:34 ah, that'll do! Mar 04 14:24:49 probably best to target your R-Pi... even add it to the supported list of board. Mar 04 14:25:14 i have a doubt. right time to ask ? Mar 04 14:25:20 *original model B* Mar 04 14:25:26 zoorg: go make a fork of https://github.com/prpplague/Userspace-Arduino and spend some time getting it running on your R-Pi. Mar 04 14:25:59 karki: do you think the pru-bridge project could cover a DMA option along with the serial like interface? Mar 04 14:26:51 seeing as the virtual serial port part isn't exactly new stuff Mar 04 14:26:52 jkridner: Ok. Thanx for the directions. A already looked through this repo, so, can't you clarify, what's actually already done and what's our main goals? Mar 04 14:27:27 Idea page says: "blah-blah... especially SPI, I2C, Wire, Serial, Servo, Stepper" Mar 04 14:27:39 jkridner: Is the High-level language API targeted towards the starterware for PRU in BBB ? Mar 04 14:27:44 And there is some code for most (or even all) of them. Mar 04 14:27:59 is an event loop necessary to check for a downcall in the pru ? the interrupt doesnt happen the conventional way of interrupting the program flow and servicing an ISR. am i right ? Mar 04 14:28:07 zoorg: only on BeagleBone, not Arduino Tre. Mar 04 14:28:27 shubhangi: correct Mar 04 14:28:33 thanks (y) Mar 04 14:28:40 i can proceed now Mar 04 14:29:27 shubhangi: which project are you looking at? Mar 04 14:29:37 shubhangi: yes, there are no ISRs in the PRU, you poll for interrupts Mar 04 14:29:38 PRU Bridge Mar 04 14:29:49 great! Mar 04 14:29:53 understood the interrupt controller and prussdrv Mar 04 14:30:00 nice (y) Mar 04 14:30:05 suggested rpmsg but was turned down Mar 04 14:30:12 oh right Mar 04 14:30:12 installed beaglelogic Mar 04 14:30:17 works gr8 Mar 04 14:30:22 going through code Mar 04 14:30:28 shubhangi: rpmsg wasn't turned down Mar 04 14:30:44 karki told it had latency issues Mar 04 14:31:01 I do like the idea of a message bus, but I think there were some concerns about rpmsg Mar 04 14:31:09 shall i look futher into it Mar 04 14:31:18 hmm, yes, quantifying the latency could be a good idea so we should know what we are missing Mar 04 14:31:42 as in identifying wht parts are causing the delay ? Mar 04 14:32:11 yes, you could say that Mar 04 14:32:13 jkridner: Ok, I got this. So actual goal is to PORT UA to other platform (Tre and/or RPi in our case). Mar 04 14:32:22 okay (y) Mar 04 14:32:38 rpmsg is the type of thing you could have running over top of the pru-bridge, so even if it has some extra latency it could be a good pru-bridge demo and would still be good for some tasks Mar 04 14:33:25 sounds good Mar 04 14:33:39 jkridner: what is your irc-active time? Mar 04 14:35:05 jkridner: I will be dead-sleeping for 6-7 hours from now on, and so, I want to know when I can contact you next time. Mar 04 14:35:12 Another aspect is to be able to port BeagleLogic and PRUSpeak to the new framework and the latest kernels (3.8.13 -> 3.14 -> 3.19+) Mar 04 14:35:54 a lot to read and think upon Mar 04 14:36:27 PRU Bridge is the groundwork for this Mar 04 14:36:44 the good news, if you get 3.14-ti working, mainline will be very easy. ;) Mar 04 14:37:32 hmm, isn't it working right now? Mar 04 14:38:30 i haven't seen anyone talk about beaglelogic on 3.14. yet ;) Mar 04 14:39:40 jkridner: Ok, anyway, please-please-please, post your time zone and time when you most likely will be here. I'll pick it from logs in the morning. Mar 04 14:39:53 zoorg: I'm EST. Mar 04 14:39:57 it is on the ideas page. Mar 04 14:40:10 my times on-line are unpredictable... Mar 04 14:40:16 don't wait for me to be here to post. Mar 04 14:40:35 you need to learn to put enough in an e-mail to the general group to get a useful response. Mar 04 14:40:37 jkridner: Is the High-level language API targeted towards the starterware for PRU in BBB ? Mar 04 14:40:51 and then come in here and ask people to reply to your e-mail and explain the nuances. Mar 04 14:40:59 jkridner: Got it. Will do. Mar 04 14:42:05 kiran4399: I believe it will used PRU Speak (BotSpeak for PRU), possibly a firmata implementation on PRU Speak, and likely use the Starterware code within PRU Speak to access the other peripherals. Mar 04 14:44:15 Abhishek_ I never turned down rpmsg, just said it would be unlikely that it will be done this gsoc Mar 04 14:44:26 shubhangi: another thing that could be implemented over pru-bridge is remote procedure calls, e.g. https://gist.github.com/alexanderhiam/e9237b835feae932d973 Mar 04 14:44:38 *but* I remember saying that keep it as an open option Mar 04 14:44:52 alexanderhaim : what DMA are we talking about here? Mar 04 14:45:06 alexanderhiam ^ Mar 04 14:45:14 shubhangi: if the pru-bridge data transfer part gets done quickly then you can work on implemented more cool stuff over it Mar 04 14:45:24 +1 Mar 04 14:45:54 alexanderhiam: This code is parsed by the C Compiler, correct? Mar 04 14:46:08 I mean, the PRU C Compiler? Mar 04 14:46:12 oops :P Mar 04 14:46:12 karki: dma vs. serialized, e.g. beaglelogic Mar 04 14:46:37 Abhishek_: yeah, that would be the pru firmware Mar 04 14:46:46 BeagleLogic is psuedo-DMA as I like to call it Mar 04 14:47:06 it's like a DMA controller software implementation Mar 04 14:47:09 * alexanderhiam hasn't actually looked into exactly how you're transferring all that data! Mar 04 14:47:15 ok Mar 04 14:47:49 Block diagram: https://cdn.hackaday.io/images/7233871424473941538.png Mar 04 14:48:01 shubhangi : are you working on pru bridge as such or towards upstreaming the kernel driver Mar 04 14:48:06 jkridner: Oh.. great !! So In the timeline in proposal do you want me to go from starterware to the high-level API (Bottom to top) or the opposite ? Mar 04 14:48:58 pru bridge Mar 04 14:49:08 hmm Mar 04 14:49:16 developing a generic comm between arm nd pru Mar 04 14:49:30 Abhishek_ , we need students to work on a pruss upstream Mar 04 14:50:10 there is no point of a pru bridge if it is going to be another glue code driver Mar 04 14:50:19 +1 Mar 04 14:50:48 I should speak with TI and confirm my work for the summer, was expecting to receive communication from them Mar 04 14:51:41 well, you *do* have an internship Mar 04 14:52:00 hmm Mar 04 14:52:06 so what other confirmation do you need Mar 04 14:52:21 about the projects I will be working on Mar 04 14:52:37 are you contemplating about participating in GSoC? Mar 04 14:52:41 :D Mar 04 14:52:57 kiran4399: whatever makes sense to you... then we'll critique. Mar 04 14:54:54 kiran4399 (and all students): it's best to give you proposal as early as possible so there's time to get feedback from mentors and revise it Mar 04 14:55:54 Sure.. I have started writing it... :-D Mar 04 14:56:07 make an online google doc where we can look Mar 04 14:56:14 vvu : +1 Mar 04 14:56:44 and post the link here or on the mailing list Mar 04 14:56:51 okay Mar 04 14:57:02 Abhishek_ : it'd be great if you'd work on the upstreaming yourself :) Mar 04 15:00:20 if there's no one to work on upstreaming then the first task for pru-bridge should be to at least put together a minimal rproc pruss driver to get the glue code out of pru-bridge Mar 04 15:00:47 then Abhishek_ can work on upstreaming it later ;) Mar 04 15:01:46 I thought that the GSoC wave could propel the upstreaming forward though :) Mar 04 15:08:12 I need to be convinced of a stable pruss driver architecture..... Mar 04 15:08:17 it's pinning me :( Mar 04 15:08:49 I don't want another pru-driver lying around Mar 04 15:10:29 pru-bridge can involve developing a stable pruss driver arch Mar 04 15:10:37 can it ? Mar 04 15:10:38 no Mar 04 15:10:48 what else is required ? Mar 04 15:10:54 pru-bridge goes over a stable driver Mar 04 15:10:58 ohk Mar 04 15:11:04 pru-bridge is like a plugin Mar 04 15:11:10 got it Mar 04 15:11:18 I don't want to mix them up. Mar 04 15:11:23 yes Mar 04 15:11:33 bad for the student, worse for the project! :p Mar 04 15:11:54 can the underlying arch be a gsoc proposal ? Mar 04 15:12:06 if framed and thought upon propely Mar 04 15:12:13 properly* Mar 04 15:12:14 the idea being that pru-bridge is developed over top of a temporary driver while someone else works on a stable driver framework, then pru-bridge gets ported over post-gsoc Mar 04 15:12:22 it's on the ideas page already Mar 04 15:12:36 "PRUSS Support for the newer kernels" Mar 04 15:13:10 hmm.. the two need close interaction Mar 04 15:13:59 or not if the stable driver turns out excellently Mar 04 15:14:01 they need to be done separately so they're not holding each other up Mar 04 15:14:33 the porting would just be replacing the glue code with calls to the new framework's API Mar 04 15:14:34 yes. the distance will probably ensure more generic behavious Mar 04 15:14:52 beahviour* Mar 04 15:14:59 damn Mar 04 15:15:36 yes alexanderhiam is spot on Mar 04 15:15:44 they are rather independent Mar 04 15:15:53 are they? Mar 04 15:16:00 but I'd put upstreaming on higher priority Mar 04 15:16:04 yes Mar 04 15:16:25 " the idea being that pru-bridge is developed over top of a temporary driver while someone else works on a stable driver framework, then pru-bridge gets ported over post-gsoc" Mar 04 15:16:33 thats the paln Mar 04 15:16:35 plan Mar 04 15:16:38 hmm Mar 04 15:17:13 so pru bridge is developed against the current driver, but keeping in mind the new arch Mar 04 15:17:36 i was away for a bit...read the logs so pruss support is creation of a new stable driver and pru bridge is a peice of code that sits on that and provides a standard com protocol?? Mar 04 15:17:45 i.e. the pru bridge should be ported to the new kernel driver with minimal effort Mar 04 15:17:56 apaar ,yes Mar 04 15:18:04 apaar: you could say that, yes Mar 04 15:18:42 Abhishek_ was focusing on LKML upstream and me on pru bridge Mar 04 15:19:03 but I really want a solid architecture for the base driver first Mar 04 15:19:19 so we need a student to focus on upstreaming Mar 04 15:20:19 shubhangi : yes, a stable pruss driver will be a gsoc proposal (and a high priority one IMO) Mar 04 15:20:25 ah ...ok Mar 04 15:20:43 ok. thanks a lot Mar 04 15:21:28 so pru-bridge will also include creation of a new protocol or will we be trying to mimic rmsg...what is the main issue with the current driver?/...i do not fully understand all the issues just parts of some of them Mar 04 15:21:57 we will most likely have our own shared memory protocol Mar 04 15:22:16 what issues are we taking about Mar 04 15:22:54 pru-bridge has to cover all possible use cases of the PRU application so far Mar 04 15:22:55 why are we looking for a new driver instead of just a stable port of the existing driver panto wrote?? Mar 04 15:23:42 same doubt Mar 04 15:23:45 apaar: pru-bridge is a shared memory based transport layer. Things like rpmsg could be built on top of it Mar 04 15:25:03 by shared memory we mean sysfs right? Mar 04 15:25:09 NO Mar 04 15:25:21 pru -arm share ddr memory Mar 04 15:25:32 thats what we are talking about Mar 04 15:25:53 * karki wonders where to start the explanation Mar 04 15:26:05 sysfs is a userspace-kernel interface based on file i/o, pru-bridge is a kernel-pruss interface based on shared physical memory Mar 04 15:26:18 Ok so all you pru guys, listen up Mar 04 15:26:37 different people want to use their pru for different things Mar 04 15:26:49 all ears Mar 04 15:26:51 one driver cant handle all niche situations Mar 04 15:27:15 we need a skeleton driver which takes care of the most basic stuff Mar 04 15:27:30 like uploading firmware Mar 04 15:27:36 upcall-downcall Mar 04 15:27:37 etc Mar 04 15:27:53 the skeleton driver also exposes an in kernel API Mar 04 15:28:01 or some kind of interface Mar 04 15:28:18 The skeleton driver is the core driver Mar 04 15:28:34 pru bridge is a plugin Mar 04 15:29:03 can anyone tell me how GPIO_INSTANCE_ADDRESS like (SOC_GPIO_1_REGS) and GPIO_INSTANCE_PIN_NUMBER like (23) are inter related ?? writing libraries in starterware.. Mar 04 15:29:10 now whenever we need to develop a application for the PRU, we need to write our own driver Mar 04 15:29:34 and also patch the core driver (panto's) with some glue code Mar 04 15:29:54 eg. me and abhishek did it for pruspeak and beagle-logic Mar 04 15:30:33 The main reason this is done is 1. to be able to move data between arm-pru Mar 04 15:30:48 2. to expose upcall-downcall to userspace Mar 04 15:31:02 now Mar 04 15:31:25 even the glue code we write is not standardized Mar 04 15:31:29 it's a hack Mar 04 15:31:48 so we need the core driver to expose a way to write plugin drivers Mar 04 15:32:34 and we need pru-bridge because everytime I develop a pru based project, I don't want to sit around writing a plugin driver Mar 04 15:33:18 so the most common features, such as cross communication between pru-arm; xpose upcall-downcall to linux user space Mar 04 15:33:26 will be bundled in pru-bridge Mar 04 15:33:45 pru-bridge plugin will handle most requirements Mar 04 15:34:06 but if I have a niche application which the pru bridge can't handle Mar 04 15:34:12 *then* Mar 04 15:34:21 I can write my own plugin driver Mar 04 15:34:44 pru bridge will sit over pru - core as the defacto plugin Mar 04 15:35:12 so even noob developers can write their PRU apps without busting their head Mar 04 15:35:30 the pru-bridge will come with a pru side api Mar 04 15:35:34 for firmware dev Mar 04 15:35:40 and a userspace api Mar 04 15:35:50 which can be in python, node, etc Mar 04 15:35:57 **done** Mar 04 15:36:01 any doubts ? Mar 04 15:36:03 thanks a lot (y) clears a lot of things. will the core driver work in conjunction with panto's drivers or replace it entirely from scratch ? Mar 04 15:36:20 refactor panto's driver Mar 04 15:36:26 okay Mar 04 15:36:33 panto is the one you need to talk to for this Mar 04 15:36:42 no one knows PRU better than him :) Mar 04 15:36:52 ok. thanks Mar 04 15:37:01 1 more question Mar 04 15:37:29 yes Mar 04 15:39:08 does 1 pru always need to be dedicated for arm-pru communication as seen till now ? Mar 04 15:39:32 not dedicated Mar 04 15:39:34 as such Mar 04 15:39:49 but *something* needs to talk to the ARM, right? Mar 04 15:40:00 we normally choose PRU0 for that Mar 04 15:40:16 ah i finally understood ...thanks :) Mar 04 15:40:31 but then again, there is no strict binding. so donno what you mean by dedicated Mar 04 15:40:35 let me put it other way. Mar 04 15:40:38 if you're pru firmware fits within the pru-bridge event loop it should support single pru mode Mar 04 15:40:41 sorry. couldnt explain Mar 04 15:41:00 if not it should also support dual pru firmware Mar 04 15:41:34 a c library for the pru where developer can call read/write functions in a block call Mar 04 15:41:40 it would be awesome if the driver could load and manage two separate pru-bridge based firmwares Mar 04 15:42:01 so the developer doesnt have to code the event loop Mar 04 15:42:11 do i make sense ? Mar 04 15:42:20 you do make sense... Mar 04 15:42:40 we could potentially have a non event loop mode Mar 04 15:42:52 yes Mar 04 15:43:18 although the mem_read call would block the pru until the write by arm is complete Mar 04 15:43:25 there could be a PRUBridge_update() routine that is up to the user to call to check for upcalls/downcalls Mar 04 15:44:04 https://github.com/deepakkarki/pru_serial/blob/master/README.md Mar 04 15:44:04 exaclty Mar 04 15:44:12 int set_blocking_read(int ch, int true_or_false); Mar 04 15:44:14 exactly* Mar 04 15:44:20 did anyone read this :'( Mar 04 15:44:45 who reads READMEs?! :P Mar 04 15:44:54 sorry Mar 04 15:44:55 reading now Mar 04 15:45:05 :p Mar 04 15:45:22 pru_serial would be implemented over the pru-bridge transport Mar 04 15:45:30 alexanderhiam : so blocking won't really work Mar 04 15:45:45 I found out after I wrote the readme Mar 04 15:45:50 how so? Mar 04 15:45:52 rather realized Mar 04 15:46:16 the kernel needs a upcall to an issued downcall within 100ms Mar 04 15:46:22 else it self destructs Mar 04 15:46:23 ah Mar 04 15:46:30 it can be implemented Mar 04 15:46:39 through shared memory flags though Mar 04 15:46:44 yeah Mar 04 15:46:48 but seems like a round about method Mar 04 15:46:52 we'll see Mar 04 15:47:07 blocking is definitely good to have Mar 04 15:47:36 though non-blocking is *much* more helpful Mar 04 15:48:04 the pru end lies under core-driver project or pru-bridge. Mar 04 15:48:22 pru-bridge Mar 04 15:48:28 ok Mar 04 15:48:43 actually both Mar 04 15:48:48 hard to say now Mar 04 15:48:52 k Mar 04 15:49:06 there has to be some standardized pru-side stuff Mar 04 15:49:11 you need some pru firmware func that talk to the core driver Mar 04 15:49:16 yes Mar 04 15:49:24 thts wht i thought Mar 04 15:49:35 which is the standardized stuff AH is talking about Mar 04 15:50:11 that should be the stuff that will always be present in any pru application Mar 04 15:50:16 and nothing more Mar 04 15:50:16 yes Mar 04 15:50:19 +1 Mar 04 15:50:33 then pru-bridge firmware will use that Mar 04 15:50:36 so makes it a part of core-driver more or less Mar 04 15:50:36 :) Mar 04 15:50:41 yes Mar 04 15:50:58 though wouldn't be upstreamed Mar 04 15:51:06 yes Mar 04 15:51:19 thanks a lot Mar 04 15:51:33 made things a lot more clearer Mar 04 15:51:55 oops, we're hogging this meeting Mar 04 15:51:59 my comp just hung :(...will catch up on the logs and comeback if i have any doubts Mar 04 15:52:45 (it is the meeting now, right?) Mar 04 15:53:50 karki: perhaps we should paste all that somewhere people can see it Mar 04 15:57:05 (oh nvm, the meeting's not for another hour) Mar 04 15:57:17 how does one ensure that the driver will be upstreamed. what coding practice one needs to follow ? Mar 04 15:57:57 shubhangi, follow the standard kernel coding practice, then submit and see the reviews. ;) Mar 04 15:58:23 okay (y) Mar 04 15:58:49 we can help you review it, but usually it's always up to the kernel maintainers in the end.. Mar 04 15:59:37 rcn-ee : which project are you planning to mentor :) Mar 04 16:00:16 i was just going to help out where needed, anything kernel related. ;) Mar 04 16:08:08 rcn-ee : the pru could use some love ;) Mar 04 16:08:57 karki, i've actually never touched the pru.. ;) Mar 04 16:09:20 theres a first time to everything :p Mar 04 16:09:39 and no one here knows upstreaming better Mar 04 16:10:59 We really need Suman from TI involved, he maintains remoteproc. ;) Mar 04 16:21:15 Yep Mar 04 16:21:32 that would be great Mar 04 16:33:14 Is there any specific template for writing a proposal ? Mar 04 16:34:32 you will get the template once student proposals open Mar 04 16:51:46 can we give our proposals well before the registration starts for verifying to the mentors ? Mar 04 16:52:01 is there any meeting today ? Mar 04 16:52:37 kiran4399: certainly, just put write it up in a goodle doc and post a link Mar 04 16:53:08 vvu: yes Mar 04 16:57:57 hello all Mar 04 16:58:03 _av500_: you around? Mar 04 16:58:15 <_av500_> jkridner: a bit Mar 04 16:58:24 <_av500_> im down with a flu (again) Mar 04 16:59:02 oh no. :( Mar 04 16:59:16 <_av500_> I slept al day yesterday Mar 04 16:59:22 <_av500_> better today Mar 04 16:59:33 rcn-ee: let's try to get Suman into here. Mar 04 17:00:24 <_av500_> jkridner: all these mentors you gang pressed at SCALE, are they here? Mar 04 17:00:31 I just got through shoveling a ton of snow.... waiting for the lights in my head to turn back on. ;-) Mar 04 17:00:44 don't see any of them. :( Mar 04 17:00:54 mdp here? Mar 04 17:01:27 * _av500_ kicks mdp awake Mar 04 17:01:33 I'm here..lurking Mar 04 17:01:42 multitasking meetings Mar 04 17:01:44 k Mar 04 17:02:24 any agenda items from anyone? Mar 04 17:02:33 * jkridner will go over the schedule. Mar 04 17:02:47 I have some queries about pru bridge project . Mar 04 17:03:13 jkridner: spoke to Andrew, he’s in for Android Mar 04 17:03:17 i will miss this meeting, going to look over the logs after Mar 04 17:03:18 Aman_singh: start by reading the irc logs, we just discussed it in some depth Mar 04 17:03:19 k. let's make sure we handle logistical questions first, then scatter into helping students put together proposals. Mar 04 17:03:52 timeline: https://www.google-melange.com/gsoc/events/google/gsoc2015 Mar 04 17:03:55 jkridner i think he’s already registered on melange, have pointed him towards irc and the mailing list too Mar 04 17:04:09 we are currently in a meet-and-greet phase. Mar 04 17:04:53 jkridner: do you think it will be possible to have a hangout with possible students on bone 101 and node-webkit based cross-platform getting-started app Mar 04 17:05:07 I need all mentors to apply to be mentors on melange. Mar 04 17:05:21 DiegoTc: If we can do it here, it would be better. Mar 04 17:05:29 that way many questions and doubts can be answer and will be useful for students who will like to propose on those project Mar 04 17:05:52 DiegoTc: we can certainly advertise a meet-up time for here to specifically discuss that project.... and I'd include the BBUI too. Mar 04 17:06:02 I thought it will be better one specific date, that way you upload it and it's on youtube Mar 04 17:06:06 but you decide Mar 04 17:06:48 * jkridner has been working on http://jadonk.github.io/bone101/Support/bone101/UI/, but still has a lot of re-write to do still. Mar 04 17:07:02 this Friday will be OK this same hour if is IRC? Mar 04 17:07:19 DiegoTc: I've been having problems with Google Hangouts-on-Air.... Mar 04 17:07:25 they simply haven't been working for me.... Mar 04 17:07:40 it isn't my idea of fun to debug someone's proprietary technology. Mar 04 17:08:07 Friday is bad for me unless a few hours earlier or later. Mar 04 17:08:28 any logistics questions before we dive into project ideas? Mar 04 17:09:44 Hi jkridner Mar 04 17:10:18 hi Abhishek_ Mar 04 17:10:31 DiegoTc: how about Friday, 3 hours earlier? Mar 04 17:10:44