From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Shevchenko Date: Mon, 29 Aug 2016 15:48:18 +0300 Subject: [Buildroot] [PATCH] [RFC] platform: update galileo to 3.14 kernel In-Reply-To: References: <1471868735-13766-1-git-send-email-padraig.connolly@intel.com> <20160822163337.484cb311@free-electrons.com> <20160823112531.13f75bab@free-electrons.com> Message-ID: <1472474898.4887.366.camel@linux.intel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net 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 Intel Finland Oy