RE: [PATCH] fdt: Enhance dts/Makefile to be all things to all men
Simon, -Original Message- From: Simon Glass [mailto:s...@chromium.org] Sent: Tuesday, May 28, 2013 12:36 PM To: U-Boot Mailing List Cc: Tom Rini; Stephen Warren; Devicetree Discuss; u-boot- rev...@google.com; Simon Glass; Tom Warren; Jerry Van Baren Subject: [PATCH] fdt: Enhance dts/Makefile to be all things to all men There are a few partially conflicting requirements in compiling the device tree, since U-Boot relies on whatever is installed on the build machine. Some versions of dtc support -i, and this is often better than using #include since you get correct line number information in errors. Unfortunately this version must be installed manually in current Linux distributions. Some device tree files use the word 'linux' which gets replaced with '1' by many version of gcc, including version 4.7. So undefine this. When an device tree file has an error we want to direct the user to the right file and line number. So instead of piping the file into dts through stdin, put it in a real file so that we get a fairly sensible error message from dts. Then print out the original file details to help further. This is based on a commit from Tom Warren. It would help if people can test it in different environments. Signed-off-by: Tom Warren twar...@nvidia.com Signed-off-by: Simon Glass s...@chromium.org Works for me for all Tegra builds, so: Tested-by: Tom Warren twar...@nvidia.com Tom --- dts/Makefile | 34 +- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/dts/Makefile b/dts/Makefile index 03e163e..1f6fabb 100644 --- a/dts/Makefile +++ b/dts/Makefile @@ -37,11 +37,29 @@ $(if $(CONFIG_ARCH_DEVICE_TREE),,\ $(error Your architecture does not have device tree support enabled. \ Please define CONFIG_ARCH_DEVICE_TREE)) +# Provide a list of include directories for dtc DTS_INCS-y := -i +$(SRCTREE)/arch/$(ARCH)/dts + +DTS_INCS-y += -i $(SRCTREE)/board/$(VENDOR)/dts + +DTS_INCS-$(CONFIG_CHROMEOS) += -i $(SRCTREE)/cros/dts + +# Check if our dtc includes the -i option DTS_FLAGS := $(shell if ! dtc +-i 21 | grep -q invalid option; then \ + echo $(DTS_INCS-y); fi) + # We preprocess the device tree file provide a useful define -DTS_CPPFLAGS := -x assembler-with-cpp \ +# Undefine 'linux' since it might be used in device tree files +DTS_CPPFLAGS := -x assembler-with-cpp -Ulinux \ - DARCH_CPU_DTS=\$(SRCTREE)/arch/$(ARCH)/dts/$(CONFIG_ARCH_DEVIC E_TREE).dtsi\ \ - DBOARD_DTS=\$(SRCTREE)/board/$(VENDOR)/$(BOARD)/dts/$(DEVICE_TR EE).dts\ \ - -I$(SRCTREE)/board/$(VENDOR)/dts - I$(SRCTREE)/arch/$(ARCH)/dts + -D__ASSEMBLY__ -I$(OBJTREE)/include -I$(SRCTREE)/include \ + -I$(OBJTREE)/include2 \ + -I$(SRCTREE)/board/$(VENDOR)/dts - I$(SRCTREE)/arch/$(ARCH)/dts \ + -include $(OBJTREE)/include/config.h + +DTS_TMP := $(OBJTREE)/include/generated/$(DEVICE_TREE).dts.in +DTS_SRC := board/$(VENDOR)/dts/$(DEVICE_TREE).dts all: $(obj).depend $(LIB) @@ -50,13 +68,19 @@ all: $(obj).depend $(LIB) # the filename. DT_BIN := $(obj)dt.dtb -$(DT_BIN): $(TOPDIR)/board/$(VENDOR)/dts/$(DEVICE_TREE).dts +DTC_CMD := $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} $(DTS_FLAGS) +$(DTS_TMP) + +$(DT_BIN): $(TOPDIR)/$(DTS_SRC) rc=$$( \ - cat $ | $(CPP) -P $(DTS_CPPFLAGS) - | \ - { { $(DTC) -R 4 -p 0x1000 -O dtb -o ${DT_BIN} - 21 ; \ + cat $ | $(CPP) -P $(DTS_CPPFLAGS) - $(DTS_TMP); \ + { { $(DTC_CMD) 21 ; \ echo $$? 3 ; } | \ grep -v '^DTC: dts-dtb on file' ; \ } 31 12 ) ; \ + if [ $$rc != 0 ]; then \ + echo Source file is $(DTS_SRC); \ + echo Compiler: $(DTC_CMD); \ + fi; \ exit $$rc process_lds = \ -- 1.8.2.1 -- nvpublic ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 1/2] fdt: Avoid early panic() when there is no FDT present
Simon, -Original Message- From: Simon Glass [mailto:s...@chromium.org] Sent: Wednesday, March 28, 2012 1:08 PM To: U-Boot Mailing List Cc: Tom Warren; Stephen Warren; Albert Aribaud; Simon Glass; Jerry Van Baren; Devicetree Discuss Subject: [PATCH 1/2] fdt: Avoid early panic() when there is no FDT present CONFIG_OF_CONTROL requires a valid device tree. However, we cannot call panic() before the console is set up since the message does not appear, and we get a silent failure. Remove the panic from fdtdec_check_fdt() and provide a new function to prepare the fdt for use. This will be called after the console is ready. Signed-off-by: Simon Glass s...@chromium.org Tested-by: Tom Warren twar...@nvidia.com Acked-by: Tom Warren twar...@nvidia.com --- include/fdtdec.h | 17 +++-- lib/fdtdec.c | 24 +++- 2 files changed, 34 insertions(+), 7 deletions(-) diff --git a/include/fdtdec.h b/include/fdtdec.h index 766e0bd..d45acbe 100644 --- a/include/fdtdec.h +++ b/include/fdtdec.h @@ -157,8 +157,21 @@ s32 fdtdec_get_int(const void *blob, int node, const char *prop_name, int fdtdec_get_is_enabled(const void *blob, int node); /** - * Checks whether we have a valid fdt available to control U-Boot, and panic - * if not. + * Make sure we have a valid fdt available to control U-Boot. + * + * If not, a message is printed to the console if the console is ready. + * + * @return 0 if all ok, -1 if not + */ +int fdtdec_prepare_fdt(void); + +/** + * Checks that we have a valid fdt available to control U-Boot. + + * However, if not then for the moment nothing is done, since this + function + * is called too early to panic(). + * + * @returns 0 */ int fdtdec_check_fdt(void); diff --git a/lib/fdtdec.c b/lib/fdtdec.c index 9241d13..0fb6d17 100644 --- a/lib/fdtdec.c +++ b/lib/fdtdec.c @@ -276,17 +276,31 @@ int fdtdec_add_aliases_for_id(const void *blob, const char *name, return num_found; } +int fdtdec_check_fdt(void) +{ + /* + * We must have an FDT, but we cannot panic() yet since the console + * is not ready. So for now, just assert(). Boards which need an early + * FDT (prior to console ready) will need to make their own + * arrangements and do their own checks. + */ + assert(!fdtdec_prepare_fdt()); + return 0; +} + /* * This function is a little odd in that it accesses global data. At some * point if the architecture board.c files merge this will make more sense. * Even now, it is common code. */ -int fdtdec_check_fdt(void) +int fdtdec_prepare_fdt(void) { - /* We must have an fdt */ - if (((uintptr_t)gd-fdt_blob 3) || fdt_check_header(gd-fdt_blob)) - panic(No valid fdt found - please append one to U-Boot\n - binary or define CONFIG_OF_EMBED\n); + if (((uintptr_t)gd-fdt_blob 3) || fdt_check_header(gd-fdt_blob)) { + printf(No valid FDT found - please append one to U-Boot + binary, use u-boot-dtb.bin or define + CONFIG_OF_EMBED\n); + return -1; + } return 0; } -- 1.7.7.3 -- nvpublic ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v8 21/21] tegra: fdt: Enable FDT support for Ventana
Simon/Stephen, -Original Message- From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass Sent: Wednesday, March 07, 2012 10:15 AM To: Stephen Warren Cc: U-Boot Mailing List; Tom Warren; linux-te...@vger.kernel.org; Jerry Van Baren; Devicetree Discuss Subject: Re: [PATCH v8 21/21] tegra: fdt: Enable FDT support for Ventana Hi Stephen, On Wed, Mar 7, 2012 at 9:10 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 03/06/2012 08:10 PM, Simon Glass wrote: From: Tom Warren twar...@nvidia.com This switches Ventana over to use FDT for run-time config instead of CONFIG options. At present Ventana does not have its own device tree file - it just uses the Seaboard one. But there's a Ventana-specific tegra-ventana.dts in the kernel... Yes, that's right. Perhaps we should drop this patch for now? Ventana will still build, just not have USB support. Signed-off-by: Tom Warren twar...@nvidia.com Signed-off-by: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org Have you tested this on Ventana in mainline U-Boot? I have not, but I think Tom has - maybe Tom you can reply Tested-by here if so? I haven't tested on Ventana yet (just got my board last week), but I will when I apply these patches and report back. If you want to drop the patch for now until you can get a tegra-ventana.dts prepped, that's fine by me, too. Tom -- nvpublic Regards, Simon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v7 15/20] tegra: fdt: Add function to return peripheral/clock ID
Simon, -Original Message- From: Simon Glass [mailto:s...@chromium.org] Sent: Tuesday, February 28, 2012 11:08 AM To: U-Boot Mailing List Cc: Tom Warren; Stephen Warren; Simon Glass; linux-te...@vger.kernel.org; Jerry Van Baren; Devicetree Discuss Subject: [PATCH v7 15/20] tegra: fdt: Add function to return peripheral/clock ID A common requirement is to find the clock ID for a peripheral. This is the second cell of the 'clocks' property (the first being the phandle itself). Signed-off-by: Simon Glass s...@chromium.org --- Changes in v4: - Add fdtdec function to return peripheral ID Changes in v6: - Move peripheral decode function into Tegra's clock.c Changes in v7: - Add belts and braces checking of device tree clock ID arch/arm/cpu/armv7/tegra2/clock.c| 56 ++ arch/arm/include/asm/arch-tegra2/clock.h | 13 +++ 2 files changed, 69 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/armv7/tegra2/clock.c b/arch/arm/cpu/armv7/tegra2/clock.c index 11d2346..959322b 100644 --- a/arch/arm/cpu/armv7/tegra2/clock.c +++ b/arch/arm/cpu/armv7/tegra2/clock.c @@ -28,6 +28,7 @@ #include asm/arch/tegra2.h #include common.h #include div64.h +#include fdtdec.h /* * This is our record of the current clock rate of each clock. We don't @@ -918,6 +919,61 @@ void clock_ll_start_uart(enum periph_id periph_id) reset_set_enable(periph_id, 0); } +/* + * Convert a device tree clock ID to our peripheral ID. They are mostly + * the same but we are very cautious so we check that a valid clock ID +is + * provided. + * + * @param clk_id Clock ID according to tegra2 device tree binding + * @return peripheral ID, or PERIPH_ID_NONE if the clock ID is invalid +*/ static enum periph_id clk_id_to_periph_id(int clk_id) { + if (clk_id 95) + return PERIPH_ID_NONE; + + switch (clk_id) { + case 1: + case 2: + case 7: + case 10: + case 20: + case 30: + case 35: + case 49: + case 56: + case 74: + case 76: + case 77: + case 78: + case 79: + case 80: + case 81: + case 82: + case 83: + case 91: + case 95: + return PERIPH_ID_NONE; + default: + return clk_id; + } +} + +int clock_decode_periph_id(const void *blob, int node) { + enum periph_id id; + u32 cell[2]; + int err; + + err = fdtdec_get_int_array(blob, node, clocks, cell, +ARRAY_SIZE(cell)); This call to fdtdec_get_int_array() breaks Harmony and Ventana builds, since they're not yet DT-enabled (CONFIG_OF_CONTROL isn't #defined). I'd fix this myself, but I'm not sure what the correct fix is to keep Harmony/Ventana building booting. Please fix, test on all Tegra2 builds (MAKEALL -s tegra2) and resend. Thanks. Tom + if (err) + return -1; + id = clk_id_to_periph_id(cell[1]); + assert(clock_periph_id_isvalid(id)); + return id; +} + int clock_verify(void) { struct clk_pll *pll = get_pll(CLOCK_ID_PERIPH); diff --git a/arch/arm/include/asm/arch-tegra2/clock.h b/arch/arm/include/asm/arch- tegra2/clock.h index 080ef18..6b12c76 100644 --- a/arch/arm/include/asm/arch-tegra2/clock.h +++ b/arch/arm/include/asm/arch-tegra2/clock.h @@ -177,6 +177,7 @@ enum periph_id { PERIPH_ID_CRAM2, PERIPH_ID_COUNT, + PERIPH_ID_NONE = -1, }; /* Converts a clock number to a clock register: 0=L, 1=H, 2=U */ @@ -355,6 +356,18 @@ unsigned clock_get_rate(enum clock_id clkid); */ void clock_ll_start_uart(enum periph_id periph_id); +/** + * Decode a peripheral ID from a device tree node. + * + * This works by looking up the peripheral's 'clocks' node and reading +out + * the second cell, which is the clock number / peripheral ID. + * + * @param blob FDT blob to use + * @param node Node to look at + * @return peripheral ID, or PERIPH_ID_NONE if none */ enum periph_id +clock_decode_periph_id(const void *blob, int node); + /* * Checks that clocks are valid and prints a warning if not * -- 1.7.7.3 -- nvpublic ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: Need some advice on LCD driver in Chrome u-boot
Stephen beat me to it. Look at how our other drivers do HW manipulation w/o bitfields and mimic them if you get stuck (SPI, MMC, etc.). My take is that we'd be better off pushing a Harmony dts file first, since that seems to be the most used/available Tegra2 board out there AFAIK. And getting a dts file reviewed by U-Boot denizens isn't much help, since fdt/dts is new to U-Boot upstream. Better to have it looked over by Linux and/or devicetree experts first, as Stephen says. Tom _ From: Stephen Warren Sent: Friday, November 18, 2011 9:15 AM To: Mayuresh Kulkarni; Uboot-dev Cc: Pritesh Raithatha; Varun Wadekar; devicetree-discuss@lists.ozlabs.org Subject: RE: Need some advice on LCD driver in Chrome u-boot AIUI, yes you'll need to rewrite the LCD driver, but this should just be a manual replacement of the bit-twiddling macros with manually coded manipulations. I don't see much point upstreaming a .dts file that's completely untested; having it upstream before we're able to use it won't benefit us in any way, will it? Now, if we started initializing a bunch of stuff besides LCD from it, then it'd make sense. Please make sure you have the LCD bindings (and whole .dts file) reviewed on devicetree-discuss@lists.ozlabs.orgmailto:devicetree-discuss@lists.ozlabs.org, since that's the main .dts review list. The .dts needs to be co-ordinated with other users such as the Linux kernel. _ From: Mayuresh Kulkarni Sent: Thursday, November 17, 2011 11:27 PM To: Uboot-dev Cc: Pritesh Raithatha; Varun Wadekar Subject: Need some advice on LCD driver in Chrome u-boot Hi All, I need advice on following points about up-streaming the LCD driver: - Chrome's u-boot implementation uses special bit-fields macros to implement the core display driver (for register read/writes). You can check this implementation in u-boot/arch/arm/cpu/armv7/tegra2/display.c. - As you might be aware, Pritesh is working on getting I2C driver up-stream which also uses bit-field macros in Chrome's u-boot. He has been given a comment that, this needs to be removed before up-streaming, as these macros are not accepted by Denx. - As I understand, this means that the display driver needs to be rewritten to use standard readl/writel APIs. Is this correct understanding? - If it needs to be rewritten, it is going to take some time. So is it OK if we push a reviewed copy of tegra2-ventana.dts (name could be decided upon) to Denx's master branch at this point of time? This commit will not be tested as there is no driver in master which would use this. Are such commits accepted? In general, how are such issues handled by the u-boot community? Mayuresh Kulkarni NVIDIA Graphics Pvt Ltd --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss