[Buildroot] [PATCH] [RFC] platform: update galileo to 3.14 kernel

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Mon, 2016-08-29 at 10:20 +0000, Connolly, Padraig wrote:
> Hi Thomas,
> 
> Currently there is support for the Quark X1000 SoC itself in the
> upstream Linux Kernel?
> but support for the Galileo Gen 1/2 is not fully upstream, there is a
> Galileo platform driver that is not upstream.
> There is also some fixes that affect the USB behavior that are not
> upstream either.
> 
> This means anything supported by the platform driver will not work
> with the upstream kernel,?
> for example GPIO, I2C, and SPI.?

What is the "Galileo platform driver"? I'm pretty sure everything listed
above is working in upstream and you are actually talking about
_external_ (to Quark SoC) pinctrl driver which is indeed absent as any
means of pinmuxing run-time in upstream.

I have no idea if it goes to category "reasonable support", though mention issue is applied to all similar boards (UP, Edison/Arduino, ...).


Comments below are not exactly related to Buildroot.

> ?USB device support is also less reliable without the fix.

Is the fix going to be upstreamed?

> 
> You can find the platform driver in our GitHub repo here :?
> https://github.com/padraigconnolly/Linux-
> x1000/tree/master/drivers/platform/x86/intel-quark

Looking into this I can say the driver is not for upstream. The upstream
drivers should utilize ACPI as much as possible, besides that fact I
mentioned about pinctrl.


On Mon, 2016-08-29 at 12:15 +0100, Kinsella, Ray wrote:
> Specifically the use of the platform driver was a result of broken
> ACPI?
> support on the Galileo platforms. The DSDT table doesn't accurately?
> describe the platform devices on these platforms, breaking the GPIO
> etc.

I do understand that.

>?
> Once the platform was in the wild with the DSDT broken table, the
> only?
> way to be sure that any given platform would work correctly was to
> use?
> the platform driver.

Nope. There are two mechanisms now to override and upgrade the ACPI
table(s). Somewhere (Ostro?) I saw a direction to a right way.

> 
> 
> Thanks,
> Padraig Connolly
> 
> -----Original Message-----
> 
> Hello,
> 
> On Tue, 23 Aug 2016 08:05:15 +0000, Connolly, Padraig wrote:
> 
> > 
> > Could you elaborate on this preference please, in the previous
> > version?
> > for the Galileo the defconfig pulled the kernel in a similar way I?
> > have done.??The future plan is once everything is approved, we will?
> > update R. Kinsella's repo with the 3.14 kernel and the defconfig
> > will?
> > pull from there instead of mine as it did before.??I'm only using
> > my?
> > repo as a temp for working on.
> 
> It's pretty simple:
> 
> ?- If a platform has reasonable support in the mainline Linux kernel,
> ???then we prefer if our defconfigs use the mainline Linux kernel. By
> ???"reasonable" support, I mean support with sufficient features for
> ???the platform to actually be useful.
> 
> ?- If a platform doesn't have reasonable support in the mainline Linux
> ???kernel, then we accept defconfigs that use other Linux kernel trees
> ???(from vendors, or community maintained, etc.).


-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy