| 11:44 | mk01_ | jnettlet: want to ask you for advice. |
| 11:44 | jnettlet | mk01_, sure |
| 11:45 | mk01_ | jnettlet: there are two trees of xbmc with a common starting point, but diverged (mine with mostly imx6 extra code, then popcornmix with mostly RBP extra code) |
| 11:46 | mk01_ | the question is, whether there is a way how to maintain ONE tree from all this |
| 11:47 | mk01_ | popcornmix is rebasing, I wasn't big fan of this, but started the same |
| 11:49 | mk01_ | maybe it would work in such process - mine tree (cleaned up from extra popcorn code) -> rebase to upstream xbmc, then take this and rebase on top of popcorns |
| 11:49 | jnettlet | are they mostly standalone patchsets, or are you patching on top of their work? |
| 11:49 | mk01_ | by definition they are standalone |
| 11:49 | mk01_ | but unfortunately they overlap |
| 11:50 | mk01_ | (sometimes) |
| 11:50 | mk01_ | so with each update - I go through the same process over and over |
| 11:50 | mk01_ | fixing rebasing conflicts |
| 11:51 | jnettlet | if they are rebasing constantly then that is going to usually be a problem. |
| 11:52 | mk01_ | I know, unfortunately he has got this bad habit .. .. doing rebase on everything already. xbmc, kernel. |
| 11:52 | mk01_ | kernel is not that bad as our extra patch set to RPI kernel is small |
| 11:53 | jnettlet | probably the best way to ease the pain is to manaage your branch on top of upstream xbmc. Then for each popcorn release that is rebased create a new branch. Use git to dump the differences between upstream and the popcorn mix into a patch series and then apply that on top of your baseline branch. |
| 11:53 | mk01_ | btw: the xbmc tree basically - one could say the changes we do to RBP could be without conflict applied ON TOP of his head |
| 11:53 | jnettlet | then if popcorn mix posts updates and hasn't rebased you should be able to merge them |
| 11:56 | mk01_ | jnettlet: applying his series is that what is making the most conflicts. for instance the EGL code, if I apply our changes to it before his code is applied , almost each commit from his branch changing those files is conflict as it expects the base be upstream/Isengard in this case |
| 11:56 | mk01_ | I was only reading the man pages |
| 11:56 | mk01_ | but |
| 11:57 | mk01_ | isn't "rebase -i --onto popcorn/isengard upstream/isengard" meant do deal with that ? |
| 11:57 | jnettlet | well you can do it the other way then, dumping your changes as a patchset and applying them |
| 11:57 | mk01_ | (if I understood it correctly) |
| 11:58 | jnettlet | mk01_, it is but the diff algorithm that git uses to patch with is very conservative and will fail merges that patch can handle just fine. |
| 11:58 | mk01_ | ok |
| 11:58 | jnettlet | of course you can tell git to be a bit more sloppy than the default but patch seems to handle these things better. |
| 11:59 | mk01_ | if I want to nicely keep all the "documentation" around (meaning proper change sets headers), can I use git am ? |
| 11:59 | mk01_ | ((to reuse the patch series?)) |
| 11:59 | jnettlet | so if you git am the patchset you can keep the commits intact and then when it fails it dumps the .diff file in the same location so you can usually just patch -p1 < /path/to/patch then re-add everything and git am --resolve it |
| 12:00 | mk01_ | ok |
| 12:00 | mk01_ | so |
| 12:00 | jnettlet | it isn't pretty, but I have found it most manageable. |
| 12:00 | mk01_ | basically I need to keep extra tree (our changes against upstream, right ? ) |
| 12:01 | jnettlet | yes |
| 12:01 | mk01_ | ok |
| 12:01 | jnettlet | or your patches against the last "head" which can be from popcornmix |
| 12:02 | jnettlet | you just need two branches with and without your patches applied so you can diff against them |
| 12:02 | mk01_ | right ... ok thanks, I will try that approach |
| 12:03 | jnettlet | good luck |
| 12:19 | mk01_ | and vanilla. but trying to reuse older chnages is just like opening a pandora box. |
| 13:11 | mk01_ | jnettlet: I rebased once again mine tree on top of popcorn's , now git log popcorn/xxx..HEAD should give me the diff I need to keep (and always put own commit into it), yes ? |
| 13:12 | jnettlet | hopefully |
| 13:13 | mk01_ | strictly at the level of pure theory |
| 13:13 | mk01_ | if |
| 13:14 | mk01_ | popcorns updates and rebase it's tree |
| 13:14 | mk01_ | if I checkout -b from it's new HEAD |
| 13:14 | mk01_ | then I do merge of the tree I just created |
| 13:15 | mk01_ | it should basically take the ones which git log popcorn/xxx..HEAD would output .. ? |
| 13:15 | jnettlet | it may work. I always try it and if it is too messy then go the patch/git am method |
| 13:16 | mk01_ | ok, but how you get this patch set ? you simply keep export from last time extra ? |
| 13:17 | jnettlet | oh I have a stupid perl script that uses git log and then rebuilds the patchset in reverse order. One sec. |
| 13:17 | jnettlet | sorry it is bash, and ugly but works. |
| 13:18 | mk01_ | doesn't matter. |
| 13:18 | mk01_ | give it to me |
| 13:18 | mk01_ | :) |
| 13:18 | mk01_ | please |
| 13:19 | mk01_ | I promise last boring question for today - can git keep something like just the diffs ? so there would be no base. |
| 13:19 | mk01_ | so I could store the popcorn/xxx..HEAD |
| 13:19 | mk01_ | and then just format-patch --stdout export it |
| 13:19 | mk01_ | and reuse |
| 13:19 | mk01_ | ? |
| 13:20 | jnettlet | well that is kind of what this does. |
| 13:20 | jnettlet | http://pastebin.com/2pQfDZza |
| 13:21 | jnettlet | This is my backporting one, so you see it adds the Upstream-commit: tag. You can just comment that out. |
| 13:23 | mk01_ | ok |
| 13:24 | mk01_ | GB is in my case popcornmix/blah_blah ,,, BB is branch which is the "output" the one I normally use ((which I now rebased on top of pop/blah_blah)), right ? |
| 13:25 | mk01_ | GITPATH is simply filter for path ? |
| 13:25 | jnettlet | yeah, BB is where you will apply the patches to, GB is where to get them from. |
| 13:25 | jnettlet | yeah |
| 13:25 | jnettlet | so leave it blank for everything |
| 13:26 | jnettlet | but sometimes if I just want a driver this will pull that out. You can't use git diff or git patch because it only shows you the changes for that file, or directory. |
| 13:26 | jnettlet | so you can lose includes etc. |
| 13:27 | mk01_ | yes, this I realised some time ago |
| 13:28 | jnettlet | this script keeps that intact because it pulls things out by commit |
| 13:29 | mk01_ | NICE ! |
| 13:29 | mk01_ | (just tried it) |
| 13:32 | mk01_ | ok - summary it up: each round of new tree preparation - I run this script, fetch --force popcorn and reset --hard to it, I checkout new from it, can try just merge from previous "final" tree, if fail I will run git am on that exported folder |
| 13:32 | mk01_ | ? |
| 13:52 | jnettlet | sounds good. I would always keep the last good branch with everything merged around just in case. Just because you are doing a force fetch. |
| 13:53 | jnettlet | it is nice to always have that reference |
| 17:01 | mk01_ | Jnettlet: |
| 17:01 | mk01_ | when we have fb0 and fb1 |
| 17:03 | mk01_ | ALL ioctls are routed (managing) configured IPU. so for powering gfx completely down, we have to blank both fb0 and fb1 as well? or does their mutual configuration affect this ? (fb1 overlaying fb0?) |
| 17:07 | mk01_ | but basically I want to ask if we should take care of this always for both or not in kodi |
| 17:40 | jnettlet | mk01_, just the main framebuffer object. |
| 17:41 | mk01_ | ok |
| 17:54 | jnettlet | mk01_, can you send your mxc_hdmi.c change as a pull request? |
| 17:55 | mk01_ | yes |
| 18:05 | mk01_ | jnettlet: just realised the whole time I was running the booting test (UHS story) it was running on kernel with revert of your revert of "mmc: core: Extend mmc_delay in mmc_power_cycle for UHS transition" |
| 18:05 | mk01_ | (everything as your HEAD) |
| 18:05 | mk01_ | ...everything else... |
| 18:05 | jnettlet | right you had that patch re-applied |
| 18:06 | jnettlet | that is how I understood it |
| 18:06 | mk01_ | ah ok, so I told you |
| 18:06 | mk01_ | forgot about that |
| 18:06 | jnettlet | yeah. but that is my conundrum. |
| 18:06 | jnettlet | that patch fixes your problem, but breaks another card. |
| 18:06 | jnettlet | also Sandisk |
| 18:07 | jnettlet | which is why I had to think about it some more. |
| 18:07 | jnettlet | maybe it should mmc_delay(2) |
| 18:07 | mk01_ | :) ok |
| 18:07 | jnettlet | if that works for everyone that would scare me |
| 18:07 | mk01_ | I can try that average |
| 18:07 | mk01_ | right away |
| 18:40 | mk01_ | jnettlet: with 2ms I get back the "never left busy state" and -110 error. But card is inited properly, there are no RD errors and voltage/speed is fine. |
| 18:41 | jnettlet | mk01_, okay leave it at 3 then and I will test with the other problem case |
| 18:52 | vpeter | mk01_: Which type of sd card is this? |
| 18:53 | vpeter | I read that regulator-enable-ramp-delay=<50000>; to regulator could help. |
| 18:54 | mk01_ | it is also SanDisk |
| 18:56 | mk01_ | Jnettlet: looks like this one is not just that easy like changing this sleep(). I changed 2 -> 3 (so back) and tried already 5 reboots, still getting -110 error and "never left busy" |
| 18:56 | mk01_ | it looks like the short sleep put something to "some" state |
| 18:56 | jnettlet | vpeter, our regulator isn't really a regulator per se, but more a reset. the 3.3V is always supplied to VDD, but we added the gpio control to cut power to reset the SDHC card when the 1.8V transition fails |
| 18:57 | jnettlet | mk01_, you have to pull the card |
| 18:57 | vpeter | I see. Just trying to help :) Seems unsuccessfuly |
| 18:57 | mk01_ | ok |
| 18:57 | jnettlet | it is a firmware thing that takes a full power down reset |
| 18:57 | jnettlet | vpeter, no worries. I will always take the suggestion. |
| 18:58 | jnettlet | but basically UHS support for mmc seems to be layer upon layer of black magic and voodoo. |
| 18:59 | jnettlet | a long time ago rmk did a series of patches and we reviewed them based strictly verbatim to the "standard" It basically broke just about every card |
| 19:00 | jnettlet | since all these cards basically run their own OS with their own ARM chip anything can be happening behind the curtains |
| 19:10 | vpeter | So the safest would be to cut power to the card at boot. |
| 19:18 | jnettlet | vpeter, well a POR already does that |
| 19:19 | jnettlet | and linux on shutdown will do that as well. but you have to be careful. We found when using the GPIO as a regulator for vmmc that linux will shut off the regulator on shutdown, but then it releases fast enough that it will also crash some cards. |
| 19:19 | jnettlet | which is why I moved it over to be a reset instead. |
| 19:20 | jnettlet | my guess as with most things this off spec and magically broken the firmware of the cards is written to work with however Microsoft has interpreted the spec |
| 19:20 | jnettlet | and we are basically throwing darts trying to figure out a best fit. |