On Fri, Jul 21, 2017 at 07:08:23PM -0400, Rob Clark wrote:
On Fri, Jul 21, 2017 at 6:20 PM, Tom Rini trini@konsulko.com wrote:
On Fri, Jul 21, 2017 at 03:10:14PM -0400, Rob Clark wrote:
Signed-off-by: Rob Clark robdclark@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_BOARDconfig 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 :)