On Mon, Jan 6, 2014 at 4:57 PM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi, > > > On 01/06/2014 10:09 PM, Josh Boyer wrote: >> >> On Wed, Dec 25, 2013 at 5:42 AM, Hans de Goede <hdegoede@xxxxxxxxxx> >> wrote: >>> >>> Hi All, >>> >> >> [ Apologies for the delayed reply. I actually turned off all my >> computers during PTO this time around. ] >> >>> As you probably know in my spare time I'm working on Linux Allwinner SoC >>> support. >>> >>> We (the linux-sunxi community) are currently making good progress on >>> getting >>> Allwinner SoCs supported in the upstream kernel. It looks like the >>> majority >>> of it will land in 3.14 and 3.15. As such I believe the time has come to >>> start supporting Allwinner SoCs with the official Fedora kernels ootb for >>> F-21. >>> >>> I've written a Feature page for this, which you can find here: >>> https://fedoraproject.org/wiki/Changes/AllwinnerSunxiSupport >>> >>> This will likely require carrying some kernel patches for 1-2 kernel >>> releases, >>> until all the necessary bits for headless operation have landed upstream. >>> >>> As always I'm willing to put my time were my work is, and I'll maintain >>> these >>> patches for as long as necessary. To give you an idea of where things are >>> going, here is a break down of the tree I'm currently using for testing >>> and development, see: >>> https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel >>> >>> This branch contains 3.13-rc5 >>> >>> + the following, which should all go upstream for 3.14: >>> >>> https://github.com/mripard/linux/commits/sunxi-clk-for-3.13 >>> https://github.com/mripard/linux/commits/sunxi-drivers-for-3.14 >>> https://github.com/mripard/linux/commits/sunxi-core-for-3.14 >>> https://github.com/mripard/linux/commits/sunxi-dt-for-3.14 >>> sunxi-bits of: >>> >>> >>> https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/clockevents/next >>> Emilio's "[PATCH v3 00/13] clk: sunxi: add PLL5 and PLL6 support" >>> series >> >> >> So rawhide (F21) just rolls along. It's at 3.13-rc7, and it will move >> to 3.14 merge window kernels roughly a week or so after 3.13 final is >> released. If we picked up patches for this, I'd rather just wait for >> all of that to be merged during the 3.14 merge window rather than pick >> it up right now. > > > Right, that actually is my plan too, I guess I should have been more > explicit about that. > > >> It's still well within the timeframe of F21 and I >> don't have to suffer through patches failing to apply during the 3.14 >> merge window. > > > Right. > > >>> + the following which is not quite ready for 3.14 yet, but people >>> are working hard to get it ready so hopefully we will see some of >>> it in 3.14, and the rest should make 3.15: >>> >>> Emilio's sunxi-clk branch: patches not part of the above set >>> David's and mine sunxi-mmc work >>> Chen's gmac work >>> Oliver's ahci work >>> Arokux' ehci work >>> mripard's "ARM: sunxi: Add A31 High Speed Timer Support" series >>> wens' "v2 of A20 external output clock support patch series" >>> hansg's resistive touchscreen controller driver (rtp) including temp >>> sensor >>> support >>> >>> Of the above list, we should at a minimum carry the mmc, gmac (gigabit >>> nic) >>> and >>> ahci patches if those don't get upstream in time. USB support would also >>> be >>> very nice, >>> but is not a must have. The last 3 patch-sets we don't need. >> >> >> The rest of those (and anything that didn't make 3.14) could be picked >> up after 3.14-rc1, since most of the merge fallout is dealt with by >> then. Do the above approaches seem reasonable? > > > Yes. > > >> I do have a broader question. I understand the importance and >> thoughts behind bringing device support in for a popular board before >> it's upstream. You want to attract users to Fedora ARM, etc. It >> makes some sense and lets people play with their shiny toys with a >> minimum amount of hassle. >> >> However, it's a double edge sword. As we've seen with BBB to a >> degree, sometimes things don't work after a kernel version bump and >> then their toys are broken and they go back to using vendor kernels or >> other distros. I worry that by bringing in these things before >> they're upstream ready to attract users, we're also setting them up >> for the very hassles we're trying to avoid. So, in your estimation, >> how possible are rebases and other changes likely to cause issues with >> AllWinner devices? > > > As long as people pair up the kernel version with the matching dts files > (which our recent uboot config scripts do automatically) I don't expect > any issues. Regressions can never be avoided 100%, but I don't expect > this to be more regression prone then say suspend/resume issues on > your average laptop after a rebase. > > Note I'm currently hashing out the dt bindings for usb + ahci in upstream > discussions (as well as getting the actual code upstream), so I expect those > to be more or less set in stone by the time we get to the F-21 betas. OK. I expect diligence will be the key. Maybe even testing against linux-next or something before rawhide does a major version rebase. Anyway, getting slightly ahead of ourselves. So I'll send out an email to the list when I start rebasing rawhide to 3.14 merge window. Shortly after that, we can plan on grabbing the patches you feel are necessary and we'll work from there. josh _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel
