**** BEGIN LOGGING AT Thu Jul 28 02:59:58 2016
Jul 28 06:20:08 <ZeekHuge> Morning jic23b !
Jul 28 06:20:37 <ZeekHuge> you were asking for email id, did you mail something ?
Jul 28 06:57:53 <jic23> Yeah sent a review email yesterday. Will check later zeekhuge
Jul 28 06:58:39 <ZeekHuge> jic23: okay. There wasnt any email in my inbox.
Jul 28 15:01:26 <ZeekHuge> Wormo_ ds2 jic23 : I was able to get to 600KHz sampling frequency without getting bbb freezed..
Jul 28 15:01:44 <ZeekHuge> root@beaglebone:~# dd if=/dev/iio\:device0 of=/dev/null
Jul 28 15:01:45 <ZeekHuge> ^C0+186694 records in
Jul 28 15:01:45 <ZeekHuge> 33488+0 records out
Jul 28 15:01:45 <ZeekHuge> 17145856 bytes (17 MB) copied, 20.258 s, 846 kB/s
Jul 28 15:02:53 <ZeekHuge> with the current driver ..
Jul 28 15:03:26 <ZeekHuge> the next step that i tried was 700 and the board freezed
Jul 28 15:11:40 <amr_ragaey> jkridner, when I did git pull upstream I got some updates, Is it right to push it to my branch ?
Jul 28 15:12:01 <amr_ragaey> 'git pull upstream gh-pages'
Jul 28 16:10:49 <ZeekHuge> wow ! rcn-ee is here !
Jul 28 16:18:20 <jkridner> amr_ragaey: yes.
Jul 28 16:21:00 <amr_ragaey> jkridner, done, thanks
Jul 28 17:08:13 <Wormo_> ZeekHuge: when you get real lockups a JTAG hardware debugger is often a big help but I haven't yet gotten my beaglebone set up for that, which doesn't come with a JTAG connector installed
Jul 28 17:10:22 <Wormo_> perhaps another mentor does have a bbb with a JTAG connector and a debugger... but in the meantime try sysrq with serial port to see how badly the system is hung
Jul 28 17:12:18 <ZeekHuge> ahh .. but Wormo_ , is there a need to debug it ? I mean, how would that help ? .. isnt it about the throughput  using rpmsg ?
Jul 28 17:13:32 <Wormo_> Why would bump in speed cause a lockup rather than just dropping messages?
Jul 28 17:13:58 <Wormo_> it's a bug being triggered
Jul 28 17:14:52 <ZeekHuge> probably because of so many and fast interrupts that PRU generates for each kick to the buffer ? no ?
Jul 28 17:14:59 <Wormo_> No
Jul 28 17:15:07 <Wormo_> Well yes that's the trigger
Jul 28 17:16:00 <Wormo_> But it's triggering some race that corrupts memory perhaps
Jul 28 17:16:28 <Wormo_> it's probably not just busy handling all the additional interrupts
Jul 28 17:16:53 <Wormo_> it could be that code to drop messages is buggy and resulting in the lockup
Jul 28 17:17:07 <Wormo_> not as well exercised path
Jul 28 17:17:42 <Wormo_> like henrix ran into for a dsp recovery path
Jul 28 17:18:17 <ZeekHuge> aa.. okay.
Jul 28 17:19:19 <Wormo_> it's not out of the question that there's a bug in your fw that makes it corrupt memory under certain specific circumstances
Jul 28 17:20:10 <Wormo_> certainly PRU executing buggy code leads to memory corruption that locks up main cpu, visaoni certainly saw enough instances of that when he smashed his stack
Jul 28 17:22:30 <Wormo_> (and then changing silly things that should have no effect caused the hang to go away, because compiler/linker arranged things a little different)
Jul 28 17:23:18 <Wormo_> I'm not saying you need to go on a big hunt for the bug right now, since you can make API progress at the lower speed
Jul 28 17:23:41 <ZeekHuge> okay.
Jul 28 17:24:20 <ZeekHuge> btw, PRU does no such that has to do something with ARM, except sending a rpmsg message
Jul 28 17:25:03 <ZeekHuge> so, I dont think that PRU would have a bug. But yeah, not sure ofc.
Jul 28 17:25:31 <Wormo_> I think it is on it's own good behaviour to write only to it's own queue in the rpmsg area
Jul 28 17:26:42 <Wormo_> if it keeps writing too far, it could corrupt kernel memory, which hopefully results in oops... but not always
Jul 28 17:28:19 <Wormo_> trying to prevent other cpus from clobbering random memory is the work of an iommu
Jul 28 17:29:53 <Wormo_> honestly I haven't found if am35xx has one or not, I know that the beagleboard-x15 has one, from henrix' experiences
Jul 28 17:33:05 <ZeekHuge> okay.
Jul 28 17:33:32 <ZeekHuge> did you know about 'git checkout HEAD -- file.name' ?
Jul 28 17:33:46 <Wormo_> yes :)
Jul 28 17:33:48 <ZeekHuge> it resets a single file ..
Jul 28 17:33:56 <Wormo_> or directory
Jul 28 17:34:08 <ZeekHuge> wow ... I thought checkout was for a branch
Jul 28 17:34:16 <ZeekHuge> yes directory too..
Jul 28 17:34:38 <Wormo_> yes it's a little weird terminology
Jul 28 17:35:08 <Wormo_> git is advertised as powerful, not intuitive
Jul 28 17:36:30 <Wormo_> and commands you use all the time have these huge man pages where other useful features can lurk
Jul 28 17:39:45 <ZeekHuge> true ..
Jul 28 20:46:26 <chanakya_vc> m_w, I am just compiling my driver to see whether it is compiling or not
Jul 28 20:47:08 <chanakya_vc> m_w, I have pushed the changes to the firmware code
Jul 28 20:47:28 <chanakya_vc> Ihave checked the firmware code, it is compiling correctly
Jul 28 20:54:57 <chanakya_vc> m_w, There?
Jul 28 20:55:08 <m_w> yes
Jul 28 20:55:24 <chanakya_vc> I have changed the firmware. Please take a look
Jul 28 20:55:44 <chanakya_vc> m_w, Working on removing errors from the driver now
Jul 28 20:56:11 <chanakya_vc> Firmware is compiling w/o any errors
Jul 28 20:56:35 <m_w> that is good
Jul 28 21:00:36 <chanakya_vc> m_w, Do you think the firmware looks fine now
Jul 28 21:00:40 <chanakya_vc> ?
Jul 28 21:02:20 <m_w> i will check it
Jul 28 21:03:37 <chanakya_vc> okay m_w
Jul 28 21:06:47 <m_w> will it is certainly more code
Jul 28 21:08:48 <chanakya_vc> Okay m_w . You don't need to worry about the mosi bits for LSB , those are definitely correct.
Jul 28 21:14:14 <m_w> did you test the firmware?
Jul 28 21:15:08 <chanakya_vc> Ah no the driver is not ready
Jul 28 21:15:12 <chanakya_vc> But it is loading
Jul 28 21:15:18 <m_w> okay
Jul 28 21:15:41 <m_w> keep at it and I can test it when the driver is ready
Jul 28 21:15:57 <chanakya_vc> Might need with the driver, m_w
Jul 28 21:15:59 <chanakya_vc> help
Jul 28 21:16:45 <chanakya_vc> Will you online like for an hour or two? m_w ?
Jul 28 21:16:54 <chanakya_vc> *be
Jul 28 21:17:09 <m_w> at least 4 more hours
Jul 28 21:17:35 <chanakya_vc> Okay that's great. I am going to finish this today at any rate
Jul 28 21:46:51 * chanakya_vc back in just a bit
Jul 28 23:35:24 <chanakya_vc> mdp, There?
Jul 28 23:51:37 <chanakya_vc> m_w, There?
Jul 28 23:51:59 <chanakya_vc> Driver compiled without any error
Jul 28 23:52:03 <m_w> yup had to reboot
Jul 28 23:52:15 <chanakya_vc> There are some warnings but seem to be harmless
Jul 28 23:52:18 <chanakya_vc> Free right now?
Jul 28 23:52:22 <m_w> yes
Jul 28 23:52:30 <chanakya_vc> Could you test right now?
Jul 28 23:52:36 <m_w> the latest code posted?
Jul 28 23:52:40 <chanakya_vc> yup
Jul 28 23:53:07 <m_w> okay then lets give it a try
Jul 28 23:53:15 <chanakya_vc> m_w, You still have the kernel source or you deleted it?
Jul 28 23:53:54 <m_w> I should have it
Jul 28 23:55:37 <chanakya_vc> Okay for compiling the firmware you would also need ti-pru code generation tools m_w
Jul 28 23:56:10 <m_w> of course
Jul 28 23:56:51 <m_w> looks like I updated my kernel on the kernel to 4.4.12-ti-r31 for another student
Jul 28 23:57:10 <m_w> does your code work with this version?
Jul 28 23:58:21 <chanakya_vc> It should work with all kernel versions
Jul 28 23:58:35 <chanakya_vc> as long as you would have the correctsource
Jul 28 23:59:08 <chanakya_vc> And that is the kernel version Zeekhuge is using :P
Jul 28 23:59:32 <m_w> yeah I was helping him
Jul 29 00:00:02 <m_w> his project was able to compile on the target
Jul 29 00:02:07 <m_w> can your project do that?
Jul 29 00:06:06 <m_w> okay I got your firmware to compile and install
Jul 29 00:06:24 <m_w> ut oh where did he go?
Jul 29 00:11:13 <m_w> okay got the driver to compile
Jul 29 00:20:02 <chanakya_vc> m_w, I got disconnected. Logs don't seem to be working
Jul 29 00:20:22 <m_w> well I got the driver and firmware to compile
Jul 29 00:20:28 <chanakya_vc> Okay
Jul 29 00:20:57 <chanakya_vc> It's a bit tricky after that, because the rproc has to be modified
Jul 29 00:21:00 <m_w> pru0_spi_subsystem loads but say nothing
Jul 29 00:21:20 <chanakya_vc> Is it supposed to say something?
Jul 29 00:21:34 <chanakya_vc> The probe will only be called after the rproc calls
Jul 29 00:21:36 <chanakya_vc> it
Jul 29 00:21:42 <m_w> okay
Jul 29 00:21:50 <m_w> so how do I do that?
Jul 29 00:21:57 <m_w> :)
Jul 29 00:22:23 <chanakya_vc> Hmmn, well m_w , the probe function has to be simply be called from the probe function of the rproc
Jul 29 00:23:11 <chanakya_vc> okay m_w I actually didn't think this through
Jul 29 00:23:33 <m_w> okay at least it compiles
Jul 29 00:23:44 <chanakya_vc> ah rproc would have to modified and then recompiled
Jul 29 00:24:15 <chanakya_vc> hmmn seems to be a difficult task. any idea how to do that?
Jul 29 00:24:19 <m_w> that seems a strange way to do it
Jul 29 00:24:28 <chanakya_vc> well it is the shortest
Jul 29 00:24:43 <chanakya_vc> time constraints weighing down my decisions now m_w :P
Jul 29 00:26:50 <m_w> can you use register_rpmsg_driver like Beaglescope?
Jul 29 00:28:20 <m_w> or was there some other method in mind?
Jul 29 00:28:54 <chanakya_vc> m_w, https://github.com/beagleboard/linux/blob/4.4/drivers/remoteproc/pru_rproc.c#L859
Jul 29 00:29:17 <chanakya_vc> At this place we just have to add pru0_spi_probe(pdev)
Jul 29 00:29:34 <chanakya_vc> and then recompile pru_rproc
Jul 29 00:29:43 <m_w> that sounds really hackish
Jul 29 00:31:38 <chanakya_vc> yup both ds2, mdp were of the opinion that is the method to be followed if I have to have any hope of completing the project:P
Jul 29 00:32:27 <chanakya_vc> And in any case mdp was suggesting that the ideal way was to get the firmware tobe virtio compliant and then advertise its functionality
Jul 29 00:32:38 <m_w> :-/
Jul 29 00:32:48 <m_w> okay
Jul 29 00:32:55 <chanakya_vc> and then let the virtio subsytem call the probe function
Jul 29 00:33:10 <m_w> so that part still needs to be coded is what I am guessing
Jul 29 00:33:28 <chanakya_vc> that is  a post GSOC goal nw
Jul 29 00:33:38 <m_w> yikes
Jul 29 00:33:48 <chanakya_vc> Wouldn't be able to do that in the given time
Jul 29 00:34:06 <chanakya_vc> and information on virtio is sodifficult to find as it is
Jul 29 00:34:41 <chanakya_vc> so ds2 and mdp were both of the opinion that this is the way to go
Jul 29 00:35:57 <chanakya_vc> m_w, Any idea on how to recompile the pru_rproc?I can see a makefile there
Jul 29 00:36:09 <chanakya_vc> https://github.com/beagleboard/linux/tree/4.4/drivers/remoteproc
Jul 29 00:37:03 <m_w> I would imagine you would have to recompile the whole kernel
Jul 29 00:38:09 <ds2> Hmmm?
Jul 29 00:38:19 <ds2> what's with all these compiles?
Jul 29 00:38:42 <chanakya_vc> How to get the function call in remoteproc ds2?
Jul 29 00:38:58 <chanakya_vc> pru_rproc
Jul 29 00:39:11 <chanakya_vc> I mean wouldn't we have to recompile it?
Jul 29 00:39:37 <chanakya_vc> And I am not sure how to do that exactly
Jul 29 00:41:00 <chanakya_vc> ds2 ^^
Jul 29 00:41:17 <ds2> you modify the files and compile it once
Jul 29 00:41:56 <m_w> the whole kernel
Jul 29 00:42:01 <m_w> and install it
Jul 29 00:42:45 <m_w> am not sure why we are hacking remoteproc though
Jul 29 00:42:52 <chanakya_vc> Why we can't unload the original pru_rproc and then simply just install our modified pru_rproc
Jul 29 00:43:12 <m_w> I missed part of this discussion
Jul 29 00:43:38 <chanakya_vc> insmod our modified pru_rproc
Jul 29 00:43:45 <chanakya_vc> ds2^^
Jul 29 00:45:30 <ds2> if you want to use modules, someone else needs to help
Jul 29 00:45:38 <ds2> modules == trouble, IMO
Jul 29 00:47:38 <m_w> what exactly was the plan?
Jul 29 00:49:04 <chanakya_vc> m_w, Here is the exact discussion : http://logs.nslu2-linux.org/livelogs/beagle-gsoc/beagle-gsoc.20160720.txt
Jul 29 00:49:53 <chanakya_vc> ds2, what do you suggest that I do?
Jul 29 00:50:14 <ds2> listen to your assigned mentors? ;)
Jul 29 00:50:31 <chanakya_vc> :p
Jul 29 00:51:02 <m_w> well then get to mentoring
Jul 29 00:51:39 * ds2 defers to the assigned mentors
Jul 29 00:52:07 <chanakya_vc> ds2, But I am not able to understand what is the way that you are suggesting.Can you please explain as to what's your way?
Jul 29 00:52:16 <m_w> well I am not a primary either
Jul 29 00:52:24 <ds2> in this case, it is a style/perference...hence the reason I am not getting involved
Jul 29 00:52:30 <ds2> if you are instructed to use modules, so be it
Jul 29 00:52:38 <chanakya_vc> No I am not ds2
Jul 29 00:53:08 <chanakya_vc> mdp agreed to what your way was that day.
Jul 29 00:53:13 <m_w> "instructed" is a very loose term for what he has been
Jul 29 00:54:47 <chanakya_vc> ds2, Please tell as to what you are suggesting. I am not able to understand what you are suggesting
Jul 29 00:55:03 <ds2> m_w: some folks like to develop with modules; I perfer monolithic kernels...it is almost a religious thing...hence not getting involved
Jul 29 00:55:18 <ds2> it is the same old crap with DT vs non DT
Jul 29 00:55:33 <ds2> none of the arguments for modules (or DT) really hold water if you look at it in detail
Jul 29 00:56:14 <chanakya_vc> Okay ds2, so you were suggesting to modify files for a monolithic files...ohhh
Jul 29 00:56:45 <chanakya_vc> *kernel
Jul 29 00:56:46 <chanakya_vc> oops
Jul 29 00:57:29 <m_w> chanakya_vc: he means having your driver built into the kernel
Jul 29 00:57:54 <chanakya_vc> Okay m_w .
Jul 29 00:57:59 <chanakya_vc> Hmmnn
Jul 29 00:58:11 <m_w> you driver is built as a module now
Jul 29 00:58:47 <chanakya_vc> Okay so tell me m_w is pru_rproc built into the kernel
Jul 29 00:58:49 <m_w> doesn't really change the driver much just when it is loaded
Jul 29 00:58:59 <chanakya_vc> ?
Jul 29 00:59:13 <m_w> you send me a link earlier to the code
Jul 29 00:59:13 <chanakya_vc> But we can insmod and rmmod pru_rproc
Jul 29 00:59:23 <m_w> that is in the linux kernel tree
Jul 29 00:59:42 <chanakya_vc> Yeah
Jul 29 01:00:20 <chanakya_vc> m_w, I am not able to understand that why can't we just rmmod pru_rproc, then insmod our version of pru_rproc
Jul 29 01:00:52 <chanakya_vc> Like it will do all the things that the original pru_rproc does
Jul 29 01:01:09 <m_w> well if pru_rproc is a module by default
Jul 29 01:01:42 <chanakya_vc> The only thing is we would have to compile the modified pru_rproc
Jul 29 01:01:54 <chanakya_vc> It is right? m_w ?
Jul 29 01:02:12 <m_w> sure
Jul 29 01:02:24 <chanakya_vc> So why can't this be done?
Jul 29 01:02:41 <m_w> it can
Jul 29 01:03:05 <chanakya_vc> I can for the  time being maybe upload the modified version on my github account and put instructions as to how to compile it
Jul 29 01:03:21 <chanakya_vc> The only thing is how to compile it
Jul 29 01:03:55 <chanakya_vc> m_w, ^^
Jul 29 01:04:49 <chanakya_vc> I think it would be pretty much the way I have cross compiled my spi driver
Jul 29 01:05:22 <m_w> make SUBDIRS=drivers/remoteproc modules
Jul 29 01:06:00 <chanakya_vc> This is compiling on target?
Jul 29 01:06:18 <m_w> either way
Jul 29 01:07:05 <m_w> you are changing a kernel driver in the kernel tree
Jul 29 01:07:50 <chanakya_vc> Can't do that m_w ?
Jul 29 01:07:56 <m_w> you can
Jul 29 01:08:18 <chanakya_vc> Both my primary mentors were okay with this
Jul 29 01:08:38 <m_w> but you will have to compile it in tree
Jul 29 01:09:20 <chanakya_vc> I have been compiling outof tree modules till now
Jul 29 01:09:30 <m_w> just change the file
Jul 29 01:09:37 <m_w> compile the kernel
Jul 29 01:09:39 <chanakya_vc> which file?
Jul 29 01:09:51 <m_w> https://github.com/beagleboard/linux/blob/4.4/drivers/remoteproc/pru_rproc.c#L859
Jul 29 01:10:02 <chanakya_vc> But wouldn't that like make it a non standard kernel
Jul 29 01:10:38 <chanakya_vc> Like if people use it later, I think it would be easier to just insmod a driver than compile the entirekernel
Jul 29 01:10:49 <chanakya_vc> I am not siure
Jul 29 01:12:23 <chanakya_vc> Okay any way you want m_w . I can cross compile the kernel maybe. Then we would also have to modify the kernel on BBB
Jul 29 01:13:44 <m_w> it is a module currently
Jul 29 01:13:53 <m_w> pru_rproc              12632  0
Jul 29 01:13:53 <m_w> pruss_intc              7223  1 pru_rproc
Jul 29 01:13:53 <m_w> pruss                   9408  0
Jul 29 01:14:25 <chanakya_vc> m_w, Okay what do you suggest then?
Jul 29 01:14:59 <m_w> so when you compile the kernel with this configuration the pru_rproc will be compiled as a module again
Jul 29 01:18:14 <chanakya_vc> Okay m_w Whatever you think is the best
Jul 29 01:18:22 <chanakya_vc> Can you do it now?
Jul 29 01:18:50 <chanakya_vc> Or maybe later,if you aren't free right now.
Jul 29 01:19:47 <m_w> I will think about the best way for you to proceed
Jul 29 01:20:09 <chanakya_vc> I just want to know whether the driver+firmware is working or not :P
Jul 29 01:20:37 <m_w> the driver is not working it does not probe
Jul 29 01:20:46 <chanakya_vc> :(
Jul 29 01:21:20 <chanakya_vc> Can you check the dmesg?
Jul 29 01:21:42 <chanakya_vc> It would give an error
Jul 29 01:21:54 <m_w> it won't probe
Jul 29 01:22:01 <m_w> so it won't print anything
Jul 29 01:22:39 <chanakya_vc> Ahh I know the problem
Jul 29 01:22:50 <chanakya_vc> pru_rproc is gpl v2
Jul 29 01:22:57 <m_w> no
Jul 29 01:23:23 <chanakya_vc> It's written at the botto,
Jul 29 01:23:25 <chanakya_vc> bottom
Jul 29 01:23:34 <m_w> that is not the problem
Jul 29 01:23:56 <m_w> platform driver need a registration in order to be probed
Jul 29 01:25:04 <chanakya_vc> Doesn't module platform driver() does that?
Jul 29 01:25:07 <chanakya_vc> Macro
Jul 29 01:25:19 <chanakya_vc> m_w, ^^
Jul 29 01:25:19 <m_w> it registers it with the system
Jul 29 01:25:43 <chanakya_vc> Okay
Jul 29 01:26:07 <m_w> something has to call the probe
Jul 29 01:26:46 <chanakya_vc> Hmmn so calling it from rproc won't work
Jul 29 01:27:01 <chanakya_vc> :(
Jul 29 01:27:45 <m_w> I could if you changed it
Jul 29 01:28:04 <m_w> I can't write the code for you
Jul 29 01:28:05 <chanakya_vc> Change what m_w ?
Jul 29 01:28:38 <chanakya_vc> Yeah I know that m_w :P
Jul 29 01:30:29 <chanakya_vc> I am confused m_w . Right now you didn't change pru_rproc right?
Jul 29 01:30:55 <chanakya_vc> I mean that's what you mean when you say that if I changed it?
Jul 29 01:30:56 <m_w> I did not
Jul 29 01:31:10 <chanakya_vc> Yeah for I moment I thought
Jul 29 01:31:19 <chanakya_vc> that you had and it wasn't working
Jul 29 01:31:25 <chanakya_vc> Okay I will change it
Jul 29 01:31:27 <m_w> oh
Jul 29 01:31:30 <m_w> I did not
Jul 29 01:31:40 <m_w> I am only testing not coding
Jul 29 01:31:51 <chanakya_vc> How do you propose that I do that.
Jul 29 01:32:00 <chanakya_vc> I can change the pru_rproc
Jul 29 01:32:17 <chanakya_vc> and then load back the source to my git?
Jul 29 01:32:19 <chanakya_vc> repo
Jul 29 01:33:52 <m_w> you could do that
Jul 29 01:34:55 <m_w> but it will be more dificult to compile that way
Jul 29 01:35:19 <chanakya_vc> I can upload the entire modified kernel if you would want
Jul 29 01:35:23 <chanakya_vc> source that is
Jul 29 01:35:35 <chanakya_vc> But it will take me time
Jul 29 01:35:58 <m_w> how about a patch?
Jul 29 01:36:30 <m_w> do you know how to create a patch?
Jul 29 01:37:30 <chanakya_vc> Yeah you had shown me how to make it. Wait let me just read through it
Jul 29 01:39:35 <chanakya_vc> m_w, You had sent me a patch file and told me steps to apply patch to my file. Not really how to create a patch file
Jul 29 01:39:49 <m_w> okay
Jul 29 01:39:52 <chanakya_vc> Wait let me just read on the net. 5 minutes
Jul 29 01:39:54 <m_w> git diff
Jul 29 01:40:29 <m_w> git diff > ../mypatch.patch
Jul 29 01:46:48 <chanakya_vc> Okay m_w , I go to my folder where the kernel source files are.
Jul 29 01:47:05 <m_w> yup
Jul 29 01:47:26 <chanakya_vc> Then I just have to do two commits
Jul 29 01:47:43 <chanakya_vc> one without the change and one with the change
Jul 29 01:47:50 <m_w> no commits are required
Jul 29 01:48:01 <m_w> change the file
Jul 29 01:48:10 <m_w> run git diff
Jul 29 01:48:38 <chanakya_vc> Okay and then the second command
Jul 29 01:48:50 <chanakya_vc> after that do I need to also do format patch?
Jul 29 01:50:03 <chanakya_vc> m_w, ^^
Jul 29 01:50:09 <m_w> not for this one
Jul 29 01:50:21 <m_w> it is not going upstream
Jul 29 01:52:42 <m_w> I guess you could create a formal patch if you want
Jul 29 01:53:17 <m_w> it is good practice if you every want to be a mainline contributer
Jul 29 01:53:28 <m_w> ever
Jul 29 01:55:08 <chanakya_vc> Okay m_w . So mainline contribution is through patches and not through pull requests?
Jul 29 01:55:50 <m_w> well it happens in layers
Jul 29 01:56:08 <m_w> individuals sent properly formed patches to mailinglists
Jul 29 01:57:00 <m_w> the patch is reviewed and if accepted it get merge into a maintainer git tree
Jul 29 01:57:37 <chanakya_vc> Okay m_w
Jul 29 01:57:38 <m_w> the maintainers do pull request to get the code into the torvalds tree
Jul 29 01:57:51 <m_w> which is essentially mainline
Jul 29 01:57:59 <chanakya_vc> One more thing, I have ti-r25
Jul 29 01:58:07 <m_w> okay
Jul 29 01:58:13 <chanakya_vc> While you have ti-r31
Jul 29 01:58:22 <chanakya_vc> will that cause a problem
Jul 29 01:58:35 <m_w> actually yes it can
Jul 29 01:59:15 <chanakya_vc> oh no
Jul 29 01:59:42 <chanakya_vc> hmmn remoteproc is same in all 4.4 's though
Jul 29 02:00:03 <m_w> not sure
Jul 29 02:00:12 <chanakya_vc> Yes it is
Jul 29 02:01:32 <chanakya_vc> Ahh then I will send you the patch m_w . If it doesn't work perhaps tomorrow you could download 4.4.9 ti-r25 and apply the patch
Jul 29 02:01:41 <chanakya_vc> I could also do it
Jul 29 02:02:00 <m_w> okay I will try it out when I get back home
Jul 29 02:02:05 <m_w> going out for a while
Jul 29 02:02:05 <chanakya_vc> But in my case it will take a lot of time because of my pathetic net speed
Jul 29 02:02:19 <chanakya_vc> Okay m_w Iwill send you a mail.
Jul 29 02:02:25 <m_w> it is a small patch
Jul 29 02:02:27 <chanakya_vc> Please do mail me if it works
Jul 29 02:02:31 <m_w> okay
Jul 29 02:02:43 <m_w> sorry for not communicating well
Jul 29 02:02:49 * chanakya_vc won't be able to sleep thinking about this
Jul 29 02:02:49 <m_w> later
Jul 29 02:02:54 <chanakya_vc> Np m_w
Jul 29 02:02:57 <ds2> Okay... I see an issue
Jul 29 02:03:04 <ds2> are you keeping only patches on github?!
Jul 29 02:03:14 <chanakya_vc> Ah no ds2
Jul 29 02:03:30 <ds2> then why does m_w need to download a tree?
Jul 29 02:03:40 <ds2> normal convention is to maintain an entire tree
Jul 29 02:03:46 <ds2> so all someone would need to do is:
Jul 29 02:03:49 <ds2> git clone FOOBAR
Jul 29 02:03:55 <ds2> git checkout appropriateBranch
Jul 29 02:04:11 <ds2> make ARCH=arm blah_config (or copy a file into .config)
Jul 29 02:04:35 <ds2> make ARCH=arm CROSS_COMPILE=bogus_tool_chain_prefix-
Jul 29 02:04:35 <chanakya_vc> Ah yes ds2 that is what I am going to do finally
Jul 29 02:04:43 <chanakya_vc> Right now this is just for testing
Jul 29 02:04:44 <ds2> copy out dtb, zImage, and modules (if needed)
Jul 29 02:05:10 <chanakya_vc> You would want me to maintain an entire tree for my project though ds2
Jul 29 02:05:14 <ds2> yes but no reason to do it differently for testing
Jul 29 02:05:18 <ds2> yes
Jul 29 02:05:28 <ds2> just clone a working tree (so you keep the old history)
Jul 29 02:05:33 <ds2> make your changes to a branch
Jul 29 02:05:34 <chanakya_vc> I mean my repo would look impressive with anentire kernel tree on it :D
Jul 29 02:05:44 <ds2> not really unless you do it wrong
Jul 29 02:05:56 <chanakya_vc> lol :P
Jul 29 02:06:05 <ds2> within your own branch, make logical commits (logical as in grouped according to functionality)
Jul 29 02:06:21 <chanakya_vc> okay so I clone 4.4.9
Jul 29 02:06:22 <ds2> branches are cheap... you can have testing_for_m_w as a branch name
Jul 29 02:06:30 <chanakya_vc> make my branch
Jul 29 02:06:31 <ds2> if it works, merge it into your official branch
Jul 29 02:06:43 <ds2> (or cherry-pick it if history got messy
Jul 29 02:06:44 <ds2> )
Jul 29 02:06:52 <chanakya_vc> and then make whatever changes I want to it
Jul 29 02:06:56 <chanakya_vc> Sounds nice
Jul 29 02:06:56 <ds2> yes!
Jul 29 02:07:16 <ds2> so say 2 years down the road, I need to your user stuff. My work flow becomes simple:
Jul 29 02:07:23 <ds2> pull in your repo as a remote branch
Jul 29 02:07:36 <ds2> cherry-pick/merge in your changes (resolving as needed for my tree)
Jul 29 02:07:49 <ds2> that way I get your commits info documented into my tree
Jul 29 02:08:01 <ds2> none of this copying and passing things around. that is unmanageable after a while
Jul 29 02:08:18 <chanakya_vc> Nice idea ds2.
Jul 29 02:08:23 <ds2> this is part of why I don't really care what version someone wants
Jul 29 02:08:41 <ds2> a little of git magic and you can move it around easily
Jul 29 02:09:26 <chanakya_vc> Okay ds2. Will do so.
Jul 29 02:09:45 <ds2> it would make other mentor's life easier
Jul 29 02:09:58 <chanakya_vc> Okay ds2
Jul 29 02:10:05 <ds2> if I really want to know how your rproc stuff is different then say up stream, git diff will tell me that right away
Jul 29 02:10:40 <ds2> (this is pretty generic stuff, shouldn't conflict with anyone else's views/philosophy)
Jul 29 02:10:42 <chanakya_vc> Okay got it
Jul 29 02:12:04 <chanakya_vc> Yeah I think so too that it wouldn't
Jul 29 02:12:16 <chanakya_vc> Thanks ds2 for your help.
Jul 29 02:12:30 <chanakya_vc> Got to go to sleep now
Jul 29 02:12:42 <ds2> good luck
Jul 29 02:12:45 <ds2> and good night
**** ENDING LOGGING AT Fri Jul 29 02:59:58 2016