<aholler>
hmm, I wonder on what linux-linaro-lsk-v3.14 is based on and why I'm getting so many conflicts when rebasing onto v3.14.18
<aholler>
are there cherry-picked patches in that kernel? I would prefer if it would be regulary rebased. That's usually easy to do (inside a stable tree)
<dv__>
what conflicts?
<dv__>
its based on 3.14.14
<dv__>
well, linaro 3.14.14
<dv__>
also, aholler, I am really amazed at how sorely lacking that ov5640 driver is
<dv__>
I really didnt expect that
<dv__>
no exposure controls, no focus controls , in fact, no controls whatsoever!
<aholler>
hmm, I have checked out -drm, which was based on .14.8. don't know the difference to the one without -drm.
<dv__>
oh dont use -drm
<dv__>
-drm is a pure development branch
<aholler>
dv__: on the wandboard list (googlegroups), there was a mail about autofocus and some patches
<dv__>
yeah, but its still not in the kernel
<dv__>
and I am surprised somebody releases a driver that is such incomplete in the first place
<dv__>
s/such/so/
<aholler>
git should have a mechanism to add a description to branches
<aholler>
there is a lot broken stuff around. many just want to sell hw and providing a driver is just some unwanted waste of time for them
<dv__>
that is common with many embedded hw makers
<dv__>
though freescale is one of the better ones
<aholler>
it's because EEs do EE, not SW.
<dv__>
just try something from mediatek once..
<dv__>
I had to once, and I *desperately* wanted to go back to fsl stuff :)
<aholler>
and these EEs like it to have disappeared when someone from the SW side starts evaluating the HW. ;)
<dv__>
heh
<dv__>
what about your quest for hw accelerated kde?
<aholler>
hmm, not sure about freescale. A kernel with 2000+ pathches doesn't look like they are eager to work with upstream
<dv__>
well, first of all, the 2000+ patches thing is mostly true about the ancient 3.0.35 kernel, which is deprecated
<dv__>
second, they are upstreaming
<dv__>
pengutronix is doing it for them
<aholler>
dv__: Nothing new about kde. Not played anything there till my last tries.
<dv__>
also, a few patches are being upstreamed by fsl folks directly
<dv__>
when I had to do stuff with mediatek, I had to use a 2.6 kernel, and one 16 MB (!) .patch file on top
<dv__>
oh and it had to be built by a very specific (and fragile) set of shell scripts, which only ran in ubuntu 10.04
<dv__>
the code in the patch was beyond awful. race conditions everywhere. memleaks everywhere. hacks to cover other hacks.etc.
<aholler>
don't look at the fw for the Lego EV3 ;)
<aholler>
Looks in parts like written by those people for which the EV3 is designed ;)
<dv__>
heh
<aholler>
and many driver used on android-tablets are awfull too.
<aholler>
looks like many stuff is done by people which seem to be new to C and Linux and don't know how a real OS does work.
<aholler>
linux-linaro-lsk-v3.14-mx6 is 2202 patches above 3.14.14
<aholler>
doesn't seem to have changed since 3.0. 3.10.17 was around 1500 patches above upstream, so it looks like becoming wors, not better ;)
<jnettlet>
aholler, you can't compare like that. My kernels replace FSL patches with backported upstream patches.
<jnettlet>
it also back ports many drivers needed for the machines it is intended for.
<aholler>
isn't that more work than forward porting the i.mx-stuff?
<jnettlet>
last time I counted I think I was at 730 something FSL patches, down from 1300 in 3.10.xxx meaning that 600 went upstream in that time frame
<jnettlet>
no because then you are constantly maintaining 700+ patches against a moving target
<jnettlet>
and really more than that.
<aholler>
that's why mainlining makes sense. ;)
<jnettlet>
well that is happening, but it doesn't happen overnight
<jnettlet>
like I said about 600+ patches have made it into mainline.
<aholler>
and I'm aware of how cumbersome it is to mainline patches.
<jnettlet>
but some of them have taken months to get through the red tape
<jnettlet>
and also just negligence of the various maintainers
<jnettlet>
luckily we have rmk working for the cause so he garners a bit more attention.
<aholler>
I've stopped posting patches to lkml too. Of course, I'm no company, so I don't have many reasons trying to fight with maintainers. ;)
<jnettlet>
but as far as rebasing to the latest .xx release of lts. I evaluate each update and I will only rebase once there are patches are are relevant to mx6 / ARM that I haven't backported
<jnettlet>
if there is nothing pending then I will rebase once we finish full driver functionality which should be soon.
<jnettlet>
In general people using the hardware to build products need a kernel they can rely on. So following mainline is nothing but a waste of time while we need to maintain non-mainline MX6 patchsets, and accompanying user-space.
<jnettlet>
We also need to support Android which is not very mainline friendly
<aholler>
hmm, people which build products will want most patches in the stable-kernels too
<dv__>
well they cant have everything
<aholler>
e.g. I've enabled modsign and the box crashed with 3.10.17 because of a bug I explained to mainline a year ago.
<aholler>
;)
<dv__>
sure, but sticking to mainline will also potentially create new bugs
<jnettlet>
aholler, that is why I updated from 3.10.xx to the latest LTS kernel
<aholler>
jnettlet: yes, thanks for your work.
<dv__>
people which build products usually want an entire working BSP, not just a kernel
<aholler>
they want everything as long as it doesn't cost anything
<jnettlet>
yes but I think FSL's BSP is still based on 3.0.35
<dv__>
uh, no
<dv__>
they are now firmly 3.10.17 based
<dv__>
some vendors still use 3.0.35 , but they are being urged to switch
<jnettlet>
The last BSP tarball I downloaded was 3.0.35, but that was a few months ago.
<dv__>
ah, I dont know about the tarballs. but fsl makes its own yocto based releases
<aholler>
they just are entering beta-phase for 3.10.31 and want to end that somewhere next year