On Fri, Jul 21, 2017 at 07:08:23PM -0400, Rob Clark wrote: > On Fri, Jul 21, 2017 at 6:20 PM, Tom Rini <tr...@konsulko.com> wrote: > > On Fri, Jul 21, 2017 at 03:10:14PM -0400, Rob Clark wrote: > >> Signed-off-by: Rob Clark <robdcl...@gmail.com> > >> --- > >> arch/arm/Kconfig | 2 +- > >> configs/dragonboard410c_defconfig | 8 +++++++- > >> 2 files changed, 8 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >> index f7b44392ac..db6a325ee1 100644 > >> --- a/arch/arm/Kconfig > >> +++ b/arch/arm/Kconfig > >> @@ -633,7 +633,7 @@ config ARCH_SNAPDRAGON > >> select DM_SERIAL > >> select SPMI > >> select OF_CONTROL > >> - select OF_SEPARATE > >> + select OF_BOARD > >> > >> config ARCH_SOCFPGA > >> bool "Altera SOCFPGA family" > >> diff --git a/configs/dragonboard410c_defconfig > >> b/configs/dragonboard410c_defconfig > >> index d992c2adda..45a121822f 100644 > >> --- a/configs/dragonboard410c_defconfig > >> +++ b/configs/dragonboard410c_defconfig > >> @@ -37,4 +37,10 @@ CONFIG_USB_EHCI_MSM=y > >> CONFIG_USB_ULPI_VIEWPORT=y > >> CONFIG_USB_ULPI=y > >> CONFIG_USB_STORAGE=y > >> -CONFIG_OF_LIBFDT_OVERLAY=y > >> +CONFIG_DM_VIDEO=y > >> +# CONFIG_VIDEO_BPP8 is not set > >> +CONFIG_VIDEO_BPP16=y > >> +CONFIG_VIDEO_BPP32=y > >> +CONFIG_CONSOLE_NORMAL=y > >> +CONFIG_VIDEO_SIMPLE=y > >> +CONFIG_OF_BOARD=y > > > > This doesn't look like you updated it with savedefconfig, did you? > > No, probably not.. tbh this is the first time I've done a defconfig > update (u-boot or kernel), board level stuff is a bit outside what I > normally work on (ie. mesa and gpu/drm), so pls forgive cluelessness > in this regard..
Ah, yeah. It's the handy-dandy way to keep things in sync and sometimes even avoid patch conflicts with others. > > Also, we don't want to nuke the overlay support I assume. Thanks! > > probably not.. although it is still an open question, I think, from > distro standpoint how to eventually pass the right fdt to kernel. As > it stands, the stage before u-boot patches the fdt bundled with > u-boot.img with useful things like wifi/bt mac addresses. But the fdt > in u-boot.img (at least if built from u-boot tree) is highly > insufficient to enabled all of the upstream drivers. And requiring > the end user to flash a new u-boot.img w/ bundled fdt as new features > (where there is not yet any clue how dt bindings should look, like > bus-scaling), isn't super friendly. > > We might eventually want some optional board hook to let board > specific code patch an fdt loaded from OS media by u-boot (or grub?) > based on fields in fdt passed from previous stage to u-boot. Maybe > overlays are a way to do that.. idk, I still need to look into how > they work.. Yeah, overlays are the standard DT way to deal with things like add-on boards for 96boards/CHIP/beaglebone/etc, along with similar but non-dev board cases. We want to keep the 'overlay' option enabled for Dragonboard I think :) -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
