Supporting Allwinner ARM SoCs in Fedora 21+ kernels

[Josh Boyer]

On Mon, Jan 6, 2014 at 4:57 PM, Hans de Goede <hdegoede at redhat.com> 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 at redhat.com>
>> 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