[RFC][TRUSTY] X-Gene platform support

[Dann Frazier]

On Thu, Mar 20, 2014 at 5:48 PM, Tim Gardner <tim.gardner at canonical.com> wrote:
> On 03/18/2014 01:15 AM, Dann Frazier wrote:
>>
>> On Fri, Mar 14, 2014 at 1:12 PM, Dann Frazier
>> <dann.frazier at canonical.com> wrote:
>>>
>>> On Thu, Mar 13, 2014 at 8:22 AM, Tim Gardner <tim.gardner at canonical.com>
>>> wrote:
>>>>
>>>> On 03/11/2014 12:15 PM, Dann Frazier wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>    I've assembled a git tree with support for the X-Gene platform:
>>>>>
>>>>> git://kernel.ubuntu.com/dannf/trusty-xgene.git for-ubuntu-20140310
>>>>>
>>>>> The PCI changes in the above are fairly significant and still under
>>>>> upstream review. I've therefore provided a separate branch with these
>>>>> changes backed out and replaced with an earlier version of the host
>>>>> controller driver, with fewer dependencies:
>>>>>
>>>>> git://kernel.ubuntu.com/dannf/trusty-xgene.git
>>>>> for-ubuntu-20140310-oldpci
>>>>>
>>>>
>>>> Ugh! Even with the PCI reverts there are some questionable patches wrt
>>>> to
>>>> maintenance and stability.
>>>
>>>
>>> Though, other than SATA and PCI, I think the drivers are pretty well
>>> self-contained,
>>> so hopefully are low risk for other platforms. And we're certainly
>>> down for tracking
>>> upstream progress and updating them over time.
>>>
>>>> I could _probably_ accept the ahci_platform patches since they are
>>>> already
>>>> in linux-next and will likely make it into 3.15 (though I'll remind you
>>>> that
>>>> I _really_ like to just cherry-pick the final patch from Linus' repo).
>>>> Are
>>>> the "Library-ise" patches necessary ?
>>>>
>>>> My knee jerk reaction is a NAK to all of the KVM patches. They appear to
>>>> be
>>>> a work in progress and likely won't even make the 3.15 merge window.
>>>>
>>>> Likewise with "arm64: PCI(e) arch support". A work in progress that is
>>>> unlikely to make 3.15.
>>>>
>>>> Instead of removing the X-Gene reboot driver, can't we just disable the
>>>> config ? Its a bit less churn and we won't have to resolve the conflict
>>>> in
>>>> future kernels.
>>>
>>>
>>> Seems like that should work, but it didn't in my testing - system hangs
>>> on reset
>>> even though:
>>>    # CONFIG_POWER_RESET_XGENE is not set
>>>    CONFIG_POWER_RESET_SYSCON=y
>>> I'll investigate why, but probably not until Monday.
>>>
>>>> What is the current state of the X-gene SOC ? I see that we already have
>>>> DTB
>>>> files for mustang and storm. Do they already boot and have networking ?
>>>
>>>
>>> With the current Ubuntu kernel, they can boot, but not into userspace
>>> (no disk, no networking).
>>>
>>> fyi, I've updated my branch:
>>>
>>> git://kernel.ubuntu.com/dannf/trusty-xgene.git for-ubuntu-20140314
>>>
>>> This pulls in the KVM changes from linux-next (I assume its no
>>> different than what
>>> you have), and also updates to the latest submitted version of the SATA
>>> driver.
>>>
>>> There's a few other experiments in it - no longer reverting the
>>> RESET_XGENE driver
>>> (as mentioned above), and making QMTM & NET_XGENE both modules. Neither
>>> seems to be working well.
>>
>>
>> Whups, I was apparently testing with the wrong .dtb. I've verified
>> that it *is* safe to keep
>> xgene_qmtm and xgene_enet as modules, so I recommend:
>>
>> CONFIG_AHCI_XGENE=m
>> CONFIG_NET_XGENE=m
>> CONFIG_PCI_XGENE=y
>> CONFIG_PHY_XGENE=y
>> CONFIG_RTC_DRV_XGENE=y
>> CONFIG_XGENE_QMTM=m
>>
>> Also, it is safe to disable CONFIG_POWER_RESET_XGENE and keep the
>> driver in place.
>>
>> Sorry for the confusion.
>>
>
> I think I've got everything merged to master-next with the following config
> settings:
>
> CONFIG_AHCI_XGENE=m
> CONFIG_ARCH_XGENE=y
> CONFIG_COMMON_CLK_XGENE=y
> CONFIG_NET_XGENE=m
> CONFIG_PCI_XGENE=y
> CONFIG_PHY_XGENE=m
>
> # CONFIG_POWER_RESET_XGENE is not set
> CONFIG_RTC_DRV_XGENE=m
> CONFIG_XGENE_QMTM=m

Thanks Tim!

For config, I think we need both PHY and RTC statically linked.
PHY isn't automatically loaded by udev, causing the SATA module
to fail. As for RTC, I believe this is normally statically linked for
all platforms,
so that the system clock can be set early in boot by the hctosys driver.
Otherwise hctosys bails with:

[    1.258714] /tmpfs/linux-3.13.0/drivers/rtc/hctosys.c: unable to
open rtc device (rtc0)

This is needed in early boot to compare mount times of the root
device, etc - and
also needed for MAAS to be able to validate certificates (though it has some
approximation code these days). You might say, well why not put it in
the initramfs?
I think there's a reason that is insufficient, but I don't remember
what it is. For right
now I'll just wave my hands and say it doesn't work today
(initramfs-tools doesn't
include the rtc driver by default), and rest on precedent for other platforms:

armhf/highbank: CONFIG_RTC_DRV_PL031=y
x86: CONFIG_RTC_DRV_CMOS=y

And the note in "annotations" that says the latter is "boot essential".

I'll test the other functionality once the PHY issue is resolved
(can't boot w/o it).

fyi, I think ab8d0329067ae97e0d7fb22727a8a9070eb09bd3 is good - Tanmay
submitted a new rev of his upstream-targeted driver today, and it had the same
change versus the previous. Feel free to squash this into the
xgene-pci commit if
you like.

Oh, and while you're at it, mind adding these modules to the udebs?

ahxi_xgene.ko ? -> sata-modules
xgene-enet ? -> nic-modules

qmtm will be automatically picked up by kernel-wedge.