[GIT PULL] Allwinner arm64 Defconfig Changes for 5.6

Olof Johansson olof at lixom.net
Sat Jan 11 14:58:20 PST 2020


On Sat, Jan 11, 2020 at 10:09:42AM +0100, Maxime Ripard wrote:
> Hi Olof,
> 
> On Fri, Jan 10, 2020 at 10:23:49PM -0800, Olof Johansson wrote:
> > On Fri, Jan 10, 2020 at 06:13:57PM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > Please pull the following changes for the next release.
> > >
> > > Thanks!
> > > Maxime
> > >
> > > The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a:
> > >
> > >   Linux 5.5-rc1 (2019-12-08 14:57:55 -0800)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git refs/tags/sunxi-config64-for-5.6
> > >
> > > for you to fetch changes up to cb4132672f76954ddc234aa343b4d2a1f1b8437a:
> > >
> > >   arm64: defconfig: Enable DRM_SUN6I_DSI (2020-01-02 10:30:35 +0100)
> > >
> > > ----------------------------------------------------------------
> > > Two patches to enable the new thermal sensor driver found on newer
> > > Allwinner SoCs and to enable the MIPI-DSI controller.
> >
> > This adds a SUN8I_THERMAL that I can't find in the tree? (this also goes for
> > the 32-bit branch)
> 
> This is a new driver that got merged through the thermal tree and
> should be in 5.6 as well:
> https://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git/commit/?h=thermal/linux-next&id=730a45ccd9322dd918a5dcaf8ae1482400fa5b23

The way we have been handling this is that we add the config options
after the merge window instead. Because right now, if someone runs
savedefconfig, they disappear.

So, please submit after -rc1 (but not too far after) to enable new
drivers merged in that window.

> > Also, is there a reason to have it =y, or would =m suffice? I see that RCAR is
> > =y, but we should revisit that as well.
> 
> That driver is used for thermal throttling which is pretty critical
> for us since the boards can get pretty hot, pretty fast (and they
> don't have a pretty wide temperature operating range either), so it
> felt natural to have it as y?

The problem with this is that all platforms now have to pay the price
of keeping this driver in memory even if it's not needed on that
hardware. This is why we're pushing back on drivers being statically
built in on the large shared defconfigs.

Loading it from ramdisk is usually done early enough that it works out for
these cases, or from rootfs if needed.


-Olof



More information about the linux-arm-kernel mailing list