RE: Need some advice on LCD driver in Chrome u-boot

2012-01-12 Thread Tom Warren
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


RE: [PATCH v7 15/20] tegra: fdt: Add function to return peripheral/clock ID

2012-03-01 Thread Tom Warren
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: [PATCH v8 21/21] tegra: fdt: Enable FDT support for Ventana

2012-03-07 Thread Tom Warren
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 1/2] fdt: Avoid early panic() when there is no FDT present

2012-03-28 Thread Tom Warren
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] fdt: Enhance dts/Makefile to be all things to all men

2013-05-28 Thread Tom Warren
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