Message ID | CACPK8XehxPjTuAq70ofmom9_DJ7LBR2C0ehO+2jGJUANTXod+A@mail.gmail.com |
---|---|
State | New |
Headers | show |
On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote: > Hi Arnd and Olof, > > Here's two Aspeed defconifg changes for 4.14. > > This is a bit later than I planned, sorry about that. These changes > have been kicking around for a while now so they areb well tested. Ok. > for you to fetch changes up to 652213cd1081017e2139d57b6c7871670e41bf0b: > > ARM: config: aspeed: Add I2C, VUART, LPC Snoop (2017-08-23 16:04:42 +0930) > > ---------------------------------------------------------------- > Aspeed defconfig updates for 4.14 > > - Enable new Aspeed drivers for i2c, lpc snoop and vuart > - Set VMSPLIT_2G for ast2400 platforms, required for mtd driver Pulled into next/defconfig. What's the state of the platform now? If it's basically working now, we should probably enable the config options in multi_v5_defconfig as well for improved testing. For some reason, we never added a multi_v6_defconfig, but we could do that now, and add the other common v6 platforms as well: bcm2835, oxnas, omap2, imx3, s3c64xx and realview. (cns3xxxx, picoxcell and vt8500 are pretty much dead as far as I can tell) Arnd
On Thu, Aug 24, 2017 at 8:39 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote: >> - Enable new Aspeed drivers for i2c, lpc snoop and vuart >> - Set VMSPLIT_2G for ast2400 platforms, required for mtd driver > > Pulled into next/defconfig. What's the state of the platform now? If > it's basically > working now, we should probably enable the config options in multi_v5_defconfig > as well for improved testing. It's close. We can boot upstream on hardware these days. The final "core" driver is the clk driver that I've taken a stab at for the ast2500. Some review of that would be appreciated: https://patchwork.kernel.org/patch/9916635/ > > For some reason, we never added a multi_v6_defconfig, but we could do that now, > and add the other common v6 platforms as well: bcm2835, oxnas, omap2, imx3, > s3c64xx and realview. (cns3xxxx, picoxcell and vt8500 are pretty much dead > as far as I can tell) I assumed this was because the V7 and V6 platforms can be built into the same kernel. We could get the same coverage by making sure all of our V6 platforms are enabled in multi_v7_defconfig. Cheers, Joel
On Fri, Sep 8, 2017 at 5:10 AM, Joel Stanley <joel@jms.id.au> wrote: > On Thu, Aug 24, 2017 at 8:39 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote: >> For some reason, we never added a multi_v6_defconfig, but we could do that now, >> and add the other common v6 platforms as well: bcm2835, oxnas, omap2, imx3, >> s3c64xx and realview. (cns3xxxx, picoxcell and vt8500 are pretty much dead >> as far as I can tell) > > I assumed this was because the V7 and V6 platforms can be built into > the same kernel. > > We could get the same coverage by making sure all of our V6 platforms > are enabled in multi_v7_defconfig. Enabling CONFIG_CPU_V6 there may have noticeable overhead on v7 platforms, and it would be a bit confusing, so I'm not sure about doing that by itself. However, a related question would be whether we want to add options for ARMv7VE (adding IDIV and LPAE) and ARMv8 and then using config fragments to specialize what is currently the multi_v7_defconfig to give us four separate configurations (v6/v7/v7ve/v8.0) with an increasing feature set but decreasing platform support. Arnd