On Mon, Jan 6, 2014 at 4:57 PM, Hans de Goede <hdegoede(a)redhat.com> wrote:
On 01/06/2014 10:09 PM, Josh Boyer wrote:
> On Wed, Dec 25, 2013 at 5:42 AM, Hans de Goede <hdegoede(a)redhat.com>
>> 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
>> We (the linux-sunxi community) are currently making good progress on
>> Allwinner SoCs supported in the upstream kernel. It looks like the
>> 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
>> I've written a Feature page for this, which you can find here:
>> This will likely require carrying some kernel patches for 1-2 kernel
>> 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
>> 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:
>> This branch contains 3.13-rc5
>> + the following, which should all go upstream for 3.14:
>> sunxi-bits of:
>> Emilio's "[PATCH v3 00/13] clk: sunxi: add PLL5 and PLL6
> 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.
>> + 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
>> Of the above list, we should at a minimum carry the mmc, gmac (gigabit
>> ahci patches if those don't get upstream in time. USB support would also
>> 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?
> 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.