[PATCH v4 01/20] fdt: Tidy up a few fdtdec problems

[PATCH v4 01/20] fdt: Tidy up a few fdtdec problems

[Simon Glass]

This fixes five trivial issues in fdtdec.c:
1. fdtdec_get_is_enabled() doesn't really need a default value
2. The fdt must be word-aligned, since otherwise it will fail on ARM
3. The compat_names[] array is missing its first element. This is needed
only because the first fdt_compat_id is defined to be invalid.
4. Added a header prototype for fdtdec_next_compatible()
5. Change fdtdec_next_alias() to only increment its 'upto' parameter
on success, to make the display error messages in the caller easier.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 include/fdtdec.h |   23 +++++++++++++++++++----
 lib/fdtdec.c     |   22 ++++++++++++++++------
 2 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 3a15f55..01badd4 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -82,6 +82,21 @@ int fdtdec_next_alias(const void *blob, const char *name,
 		enum fdt_compat_id id, int *upto);
 
 /**
+ * Find the next compatible node for a peripheral.
+ *
+ * Do the first call with node = 0. This function will return a pointer to
+ * the next compatible node. Next time you call this function, pass the
+ * value returned, and the next node will be provided.
+ *
+ * @param blob		FDT blob to use
+ * @param node		Start node for search
+ * @param id		Compatible ID to look for (enum fdt_compat_id)
+ * @return offset of next compatible node, or -FDT_ERR_NOTFOUND if no more
+ */
+int fdtdec_next_compatible(const void *blob, int node,
+		enum fdt_compat_id id);
+
+/**
  * Look up an address property in a node and return it as an address.
  * The property must hold either one address with no trailing data or
  * one address with a length. This is only tested on 32-bit machines.
@@ -112,14 +127,14 @@ s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,
  * Checks whether a node is enabled.
  * This looks for a 'status' property. If this exists, then returns 1 if
  * the status is 'ok' and 0 otherwise. If there is no status property,
- * it returns the default value.
+ * it returns 1 on the assumption that anything mentioned should be enabled
+ * by default.
  *
  * @param blob	FDT blob
  * @param node	node to examine
- * @param default_val	default value to return if no 'status' property exists
- * @return integer value 0/1, if found, or default_val if not
+ * @return integer value 0 (not enabled) or 1 (enabled)
  */
-int fdtdec_get_is_enabled(const void *blob, int node, int default_val);
+int fdtdec_get_is_enabled(const void *blob, int node);
 
 /**
  * Checks whether we have a valid fdt available to control U-Boot, and panic
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 3852038..846ec3f 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -33,6 +33,7 @@ DECLARE_GLOBAL_DATA_PTR;
  */
 #define COMPAT(id, name) name
 static const char * const compat_names[COMPAT_COUNT] = {
+	COMPAT(UNKNOWN, "<none>"),
 };
 
 const char *fdtdec_get_compatible(enum fdt_compat_id id)
@@ -89,14 +90,21 @@ s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,
 	return default_val;
 }
 
-int fdtdec_get_is_enabled(const void *blob, int node, int default_val)
+int fdtdec_get_is_enabled(const void *blob, int node)
 {
 	const char *cell;
 
+	/*
+	 * It should say "okay", so only allow that. Some fdts use "ok" but
+	 * this is a bug. Please fix your device tree source file. See here
+	 * for discussion:
+	 *
+	 * http://www.mail-archive.com/u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org/msg71598.html
+	 */
 	cell = fdt_getprop(blob, node, "status", NULL);
 	if (cell)
-		return 0 == strcmp(cell, "ok");
-	return default_val;
+		return 0 == strcmp(cell, "okay");
+	return 1;
 }
 
 enum fdt_compat_id fd_dec_lookup(const void *blob, int node)
@@ -127,14 +135,16 @@ int fdtdec_next_alias(const void *blob, const char *name,
 	/* snprintf() is not available */
 	assert(strlen(name) < MAX_STR_LEN);
 	sprintf(str, "%.*s%d", MAX_STR_LEN, name, *upto);
-	(*upto)++;
 	node = find_alias_node(blob, str);
 	if (node < 0)
 		return node;
 	err = fdt_node_check_compatible(blob, node, compat_names[id]);
 	if (err < 0)
 		return err;
-	return err ? -FDT_ERR_NOTFOUND : node;
+	if (err)
+		return -FDT_ERR_NOTFOUND;
+	(*upto)++;
+	return node;
 }
 
 /* TODO: Can we tighten this code up a little? */
@@ -254,7 +264,7 @@ int fdtdec_find_aliases_for_id(const void *blob, const char *name,
 int fdtdec_check_fdt(void)
 {
 	/* We must have an fdt */
-	if (fdt_check_header(gd->fdt_blob))
+	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");
 	return 0;
-- 
1.7.7.3

Re: [PATCH v4 01/20] fdt: Tidy up a few fdtdec problems

[Stephen Warren]

On 01/11/2012 09:32 PM, Simon Glass wrote:
> This fixes five trivial issues in fdtdec.c:
> 1. fdtdec_get_is_enabled() doesn't really need a default value
> 2. The fdt must be word-aligned, since otherwise it will fail on ARM
> 3. The compat_names[] array is missing its first element. This is needed
> only because the first fdt_compat_id is defined to be invalid.
> 4. Added a header prototype for fdtdec_next_compatible()
> 5. Change fdtdec_next_alias() to only increment its 'upto' parameter
> on success, to make the display error messages in the caller easier.
> 
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
(only because I commented on this before; I'm not an FDT maintainer here)

-- 
nvpublic

Re: [U-Boot] [PATCH v4 01/20] fdt: Tidy up a few fdtdec problems

[Jerry Van Baren]

On 01/11/2012 11:32 PM, Simon Glass wrote:
> This fixes five trivial issues in fdtdec.c:
> 1. fdtdec_get_is_enabled() doesn't really need a default value
> 2. The fdt must be word-aligned, since otherwise it will fail on ARM
> 3. The compat_names[] array is missing its first element. This is needed
> only because the first fdt_compat_id is defined to be invalid.
> 4. Added a header prototype for fdtdec_next_compatible()
> 5. Change fdtdec_next_alias() to only increment its 'upto' parameter
> on success, to make the display error messages in the caller easier.
> 
> Signed-off-by: Simon Glass<sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Acked-by: Gerald Van Baren <vanbaren-He//nVnquyzQT0dZR+AlfA@public.gmane.org>

Thanks,
gvb

[PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions

[Simon Glass]

This adds some support into fdtdec for reading GPIO definitions from
the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
is of the form:

gpio-function-name = <phandle gpio_num flags>;

where:

phandle is a pointer to the GPIO node
gpio_num is the number of the GPIO (0 to 223)
flags is a flag, as follows:

   bit    meaning
   0      0=polarity normal, 1=active low (inverted)

An example is:

gpio-enable-propounder = <&gpio 43 0>;

which means that GPIO 43 is used to enable the propounder (setting the
GPIO high), or that you can detect that the propounder is enabled by
checking if the GPIO is high (the fdt does not indicate input/output).

Two main functions are provided:

fdtdec_decode_gpio() reads a GPIO property from an fdt node and decodes it
into a structure.

fdtdec_setup_gpio() sets up the GPIO by calling gpio_request for you.

Both functions can cope with the property being missing, which is taken to
mean that that GPIO function is not available or is not needed.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 include/fdtdec.h |   45 +++++++++++++++++++++++++++++++
 lib/fdtdec.c     |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 123 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 047f603..6c0a2d1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -61,6 +61,23 @@ enum fdt_compat_id {
 	COMPAT_COUNT,
 };
 
+/* GPIOs are numbered from 0 */
+enum {
+	FDT_GPIO_NONE = -1U,	/* an invalid GPIO used to end our list */
+
+	FDT_GPIO_ACTIVE_LOW = 1 << 0,	/* input is active low (else high) */
+};
+
+/* This is the state of a GPIO pin as defined by the fdt */
+struct fdt_gpio_state {
+	const char *name;	/* name of the fdt property defining this */
+	uint gpio;		/* GPIO number, or FDT_GPIO_NONE if none */
+	u8 flags;		/* FDT_GPIO_... flags */
+};
+
+/* This tells us whether a fdt_gpio_state record is valid or not */
+#define fdt_gpio_isvalid(x) ((x)->gpio != FDT_GPIO_NONE)
+
 /**
  * Find the next numbered alias for a peripheral. This is used to enumerate
  * all the peripherals of a certain type.
@@ -227,3 +244,31 @@ int fdtdec_get_int_array(const void *blob, int node, const char *prop_name,
  * @return 1 if the properly is present; 0 if it isn't present
  */
 int fdtdec_get_bool(const void *blob, int node, const char *prop_name);
+
+/**
+ * Decode a single GPIOs from an FDT.
+ *
+ * If the property is not found, then the GPIO structure will still be
+ * initialised, with gpio set to FDT_GPIO_NONE. This makes it easy to
+ * provide optional GPIOs.
+ *
+ * @param blob		FDT blob to use
+ * @param node		Node to look at
+ * @param prop_name	Node property name
+ * @param gpio		gpio elements to fill from FDT
+ * @return 0 if ok, -FDT_ERR_NOTFOUND if the property is missing.
+ */
+int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
+		struct fdt_gpio_state *gpio);
+
+/**
+ * Set up a GPIO pin according to the provided gpio information. At present this
+ * just requests the GPIO.
+ *
+ * If the gpio is FDT_GPIO_NONE, no action is taken. This makes it easy to
+ * deal with optional GPIOs.
+ *
+ * @param gpio		GPIO info to use for set up
+ * @return 0 if all ok or gpio was FDT_GPIO_NONE; -1 on error
+ */
+int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 977528b..f0b2196 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -24,6 +24,9 @@
 #include <libfdt.h>
 #include <fdtdec.h>
 
+/* we need the generic GPIO interface here */
+#include <asm-generic/gpio.h>
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /*
@@ -336,3 +339,78 @@ int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
 	cell = fdt_getprop(blob, node, prop_name, &len);
 	return cell != NULL;
 }
+
+/**
+ * Decode a list of GPIOs from an FDT. This creates a list of GPIOs with no
+ * terminating item.
+ *
+ * @param blob		FDT blob to use
+ * @param node		Node to look at
+ * @param prop_name	Node property name
+ * @param gpio		Array of gpio elements to fill from FDT. This will be
+ *			untouched if either 0 or an error is returned
+ * @param max_count	Maximum number of elements allowed
+ * @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
+ * be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
+ */
+static int fdtdec_decode_gpios(const void *blob, int node,
+		const char *prop_name, struct fdt_gpio_state *gpio,
+		int max_count)
+{
+	const struct fdt_property *prop;
+	const u32 *cell;
+	const char *name;
+	int len, i;
+
+	debug("%s: %s\n", __func__, prop_name);
+	assert(max_count > 0);
+	prop = fdt_get_property(blob, node, prop_name, &len);
+	if (!prop) {
+		debug("FDT: %s: property '%s' missing\n", __func__, prop_name);
+		return -FDT_ERR_NOTFOUND;
+	}
+
+	/* We will use the name to tag the GPIO */
+	name = fdt_string(blob, prop->nameoff);
+	cell = (u32 *)prop->data;
+	len /= sizeof(u32) * 3;		/* 3 cells per GPIO record */
+	if (len > max_count) {
+		debug("FDT: %s: too many GPIOs / cells for "
+			"property '%s'\n", __func__, prop_name);
+		return -FDT_ERR_BADLAYOUT;
+	}
+
+	/* Read out the GPIO data from the cells */
+	for (i = 0; i < len; i++, cell += 3) {
+		gpio[i].gpio = fdt32_to_cpu(cell[1]);
+		gpio[i].flags = fdt32_to_cpu(cell[2]);
+		gpio[i].name = name;
+	}
+
+	return len;
+}
+
+int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
+		struct fdt_gpio_state *gpio)
+{
+	int err;
+
+	debug("%s: %s\n", __func__, prop_name);
+	gpio->gpio = FDT_GPIO_NONE;
+	err = fdtdec_decode_gpios(blob, node, prop_name, gpio, 1);
+	return err == 1 ? 0 : err;
+}
+
+int fdtdec_setup_gpio(struct fdt_gpio_state *gpio)
+{
+	/*
+	 * Return success if there is no GPIO defined. This is used for
+	 * optional GPIOs)
+	 */
+	if (!fdt_gpio_isvalid(gpio))
+		return 0;
+
+	if (gpio_request(gpio->gpio, gpio->name))
+		return -1;
+	return 0;
+}
-- 
1.7.7.3

Re: [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions

[Stephen Warren]

On 01/11/2012 09:32 PM, Simon Glass wrote:
> This adds some support into fdtdec for reading GPIO definitions from
> the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
> is of the form:
> 
> gpio-function-name = <phandle gpio_num flags>;

That's not true in general.

The binding definition for the GPIO controller that provides the GPIO in
question defines the number and meaning of all cells after the phandle
cell. In practice, this usually does mean two cells with the meanings
above, but there's no need for this to be true in general.

For reference, the correct way to parse such a property is:

* Read the first cell.
* Find the node referenced by the phandle.
* Ensure property gpio-controller is present in the controller node.
* Read property #gpio-cells from the controller node.
* Extract #gpio-cells from the original property.
* Keep processing more cells from the original property; there may be
multiple GPIOs listed.

Still, I'll review this patch under the assumption that it's understood
that its applicability is limited to the subset of controllers that use
the same GPIO specifier as Tegra, i.e. that which you documented.

> where:
> 
> phandle is a pointer to the GPIO node
> gpio_num is the number of the GPIO (0 to 223)
> flags is a flag, as follows:
> 
>    bit    meaning
>    0      0=polarity normal, 1=active low (inverted)

For reference, according to the binding documentation in the Linux
kernel, Samsung Exynos4 doesn't use this format, and while all other
chips do have a flags cell, about 50% of the controllers indicate the
cell is unused.

> An example is:
> 
> gpio-enable-propounder = <&gpio 43 0>;

It appears to be idiomatic to name GPIO-related properties as plural
even when only one GPIO is expected, so e.g. "wp-gpios" for an SDHCI
controller's write-proptect GPIO, rather than simply "wp-gpio.

...
> diff --git a/include/fdtdec.h b/include/fdtdec.h
...
> +/* GPIOs are numbered from 0 */
> +enum {
> +	FDT_GPIO_NONE = -1U,	/* an invalid GPIO used to end our list */

Is this due to the way U-Boot works right now, or something defined by
this patch? It's been pointed out that the kernel's choice to use -1 as
"invalid GPIO" rather than 0 was a mistake, since that prevents GPIO
fields being easily added to platform data structures, since you then
have to go and initialize every new instance to -1, rather than relying
on BSS initializing it to 0. I assume this is just the way U-Boot works,
so solving this is outside the scope of this patch.

Ignoring all the above, the code looks correct to perform as documented.

-- 
nvpublic

Re: [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions

[Simon Glass]

Hi Stephen,

On Wed, Jan 18, 2012 at 2:17 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 01/11/2012 09:32 PM, Simon Glass wrote:
>> This adds some support into fdtdec for reading GPIO definitions from
>> the fdt. We permit up to FDT_GPIO_MAX GPIOs in the system. Each GPIO
>> is of the form:
>>
>> gpio-function-name = <phandle gpio_num flags>;
>
> That's not true in general.
>
> The binding definition for the GPIO controller that provides the GPIO in
> question defines the number and meaning of all cells after the phandle
> cell. In practice, this usually does mean two cells with the meanings
> above, but there's no need for this to be true in general.
>
> For reference, the correct way to parse such a property is:
>
> * Read the first cell.
> * Find the node referenced by the phandle.
> * Ensure property gpio-controller is present in the controller node.
> * Read property #gpio-cells from the controller node.
> * Extract #gpio-cells from the original property.
> * Keep processing more cells from the original property; there may be
> multiple GPIOs listed.
>
> Still, I'll review this patch under the assumption that it's understood
> that its applicability is limited to the subset of controllers that use
> the same GPIO specifier as Tegra, i.e. that which you documented.
>
>> where:
>>
>> phandle is a pointer to the GPIO node
>> gpio_num is the number of the GPIO (0 to 223)
>> flags is a flag, as follows:
>>
>>    bit    meaning
>>    0      0=polarity normal, 1=active low (inverted)
>
> For reference, according to the binding documentation in the Linux
> kernel, Samsung Exynos4 doesn't use this format, and while all other
> chips do have a flags cell, about 50% of the controllers indicate the
> cell is unused.
>
>> An example is:
>>
>> gpio-enable-propounder = <&gpio 43 0>;
>
> It appears to be idiomatic to name GPIO-related properties as plural
> even when only one GPIO is expected, so e.g. "wp-gpios" for an SDHCI
> controller's write-proptect GPIO, rather than simply "wp-gpio.

OK, for both of those I will update the commit message. I have so far
been avoiding having the fdtdec library keep any state around. Looking
up a phandle and properties every time we need to decode a GPIO might
push me towards adding some sort of structure to speed decoding of the
device tree. For now we don't need it, and these functions only do
what they say they do, but it looks like at some point in the future
we might need more complexity here.

Regarding multiple GPIOs - there is a static function
fdtdec_decode_gpios() for decoding such a list which we can export as
needed later. But not everything is required to be a list. For many
GPIOs it makes no sense to have more than one, so a single GPIO is
convenient and conceptually simple for people, and easy to code.

>
> ...
>> diff --git a/include/fdtdec.h b/include/fdtdec.h
> ...
>> +/* GPIOs are numbered from 0 */
>> +enum {
>> +     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */
>
> Is this due to the way U-Boot works right now, or something defined by
> this patch? It's been pointed out that the kernel's choice to use -1 as
> "invalid GPIO" rather than 0 was a mistake, since that prevents GPIO
> fields being easily added to platform data structures, since you then
> have to go and initialize every new instance to -1, rather than relying
> on BSS initializing it to 0. I assume this is just the way U-Boot works,
> so solving this is outside the scope of this patch.

It is nothing to do with U-Boot itself - we can choose any number.
What is Linux using now / planning to use?

The number -1U is convenient because it allows us to number GPIOs from
0, which is natural for people and easier to see what is going on when
debugging. Off-by-one situations can be very confusing for people.

At present you must call fdtdec_decode_gpio() to decode a gpio
property in the node. If you don't then you can't know if anything was
there. U-Boot doesn't really have a device model yet, but if it did,
and if you wanted to add a GPIO to a core structure that the driver
used, then indeed the driver (or the code that owns the structure)
would need to call fdtdec_decode_gpio() to set it up. If it did not
then the GPIO number would be 0, which is valid.

A few things do come to mind though. First ->name is set to the
property name - if that is NULL then fdtdec_decode_gpio() has not been
called. Also we could add a 'valid' flag to the flags byte perhaps.
Perhaps in Linux a GPIO is represented just with a number, but here we
are using a structure and can fairly easily add something else to
indicate validity.

Should we try to do something about this now, or later? I am
especially interested in what Linux plans to do here.

>
> Ignoring all the above, the code looks correct to perform as documented.

Thanks for looking at it.

Regards,
Simon

>
> --
> nvpublic

Re: [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions

[Stephen Warren]

On 01/21/2012 10:08 AM, Simon Glass wrote:
> Hi Stephen,
> 
> On Wed, Jan 18, 2012 at 2:17 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 01/11/2012 09:32 PM, Simon Glass wrote:
>>> This adds some support into fdtdec for reading GPIO definitions from
>>> the fdt. ...
...
>>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>> ...
>>> +/* GPIOs are numbered from 0 */
>>> +enum {
>>> +     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */
>>
>> Is this due to the way U-Boot works right now, or something defined by
>> this patch? It's been pointed out that the kernel's choice to use -1 as
>> "invalid GPIO" rather than 0 was a mistake, since that prevents GPIO
>> fields being easily added to platform data structures, since you then
>> have to go and initialize every new instance to -1, rather than relying
>> on BSS initializing it to 0. I assume this is just the way U-Boot works,
>> so solving this is outside the scope of this patch.
> 
> It is nothing to do with U-Boot itself - we can choose any number.

Surely the value you choose for DT parsing has to align with the value
that U-Boot's GPIO API chooses, so you can't just choose any number.

> What is Linux using now / planning to use?

Linux uses -1 right now, but should really have used 0. I don't think
there's an actual plan to change this now, since the numbering scheme is
entrenched.

What Linux does isn't relevant; the numbering scheme I'm talking about
is the internal numbering scheme within U-Boot or Linux, which are
independent from each-other and the values in the device tree.

So that said, I was wondering if U-Boot's GPIO support (covering both
non-DT and DT cases) was new enough that it could use 0 to represent
"invalid GPIO" rather than -1, and hence FDT_GPIO_NONE be 0 not -1. It
probably isn't though; I guess U-Boot's GPIO numbering scheme is also
already entrenched?

-- 
nvpublic

Re: [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions

[Simon Glass]

Hi Stephen,

On Mon, Jan 23, 2012 at 10:18 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> On 01/21/2012 10:08 AM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Wed, Jan 18, 2012 at 2:17 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>> On 01/11/2012 09:32 PM, Simon Glass wrote:
>>>> This adds some support into fdtdec for reading GPIO definitions from
>>>> the fdt. ...
> ...
>>>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>>> ...
>>>> +/* GPIOs are numbered from 0 */
>>>> +enum {
>>>> +     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */
>>>
>>> Is this due to the way U-Boot works right now, or something defined by
>>> this patch? It's been pointed out that the kernel's choice to use -1 as
>>> "invalid GPIO" rather than 0 was a mistake, since that prevents GPIO
>>> fields being easily added to platform data structures, since you then
>>> have to go and initialize every new instance to -1, rather than relying
>>> on BSS initializing it to 0. I assume this is just the way U-Boot works,
>>> so solving this is outside the scope of this patch.
>>
>> It is nothing to do with U-Boot itself - we can choose any number.
>
> Surely the value you choose for DT parsing has to align with the value
> that U-Boot's GPIO API chooses, so you can't just choose any number.

No, in the fdt we just leave out the gpio if it is not required. The
FDT_GPIO_NONE is purely internal to U-Boot.

>
>> What is Linux using now / planning to use?
>
> Linux uses -1 right now, but should really have used 0. I don't think
> there's an actual plan to change this now, since the numbering scheme is
> entrenched.
>
> What Linux does isn't relevant; the numbering scheme I'm talking about
> is the internal numbering scheme within U-Boot or Linux, which are
> independent from each-other and the values in the device tree.
>
> So that said, I was wondering if U-Boot's GPIO support (covering both
> non-DT and DT cases) was new enough that it could use 0 to represent
> "invalid GPIO" rather than -1, and hence FDT_GPIO_NONE be 0 not -1. It
> probably isn't though; I guess U-Boot's GPIO numbering scheme is also
> already entrenched?

Yes it starts at zero. I'm not sure how to even begin such a
discussion on the list :-)

Regards,
Simon

>
> --
> nvpublic

RE: [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions

[Stephen Warren]

Simon Glass wrote at Tuesday, January 24, 2012 4:12 PM:
> On Mon, Jan 23, 2012 at 10:18 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > On 01/21/2012 10:08 AM, Simon Glass wrote:
> >> Hi Stephen,
> >>
> >> On Wed, Jan 18, 2012 at 2:17 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> >>> On 01/11/2012 09:32 PM, Simon Glass wrote:
> >>>> This adds some support into fdtdec for reading GPIO definitions from
> >>>> the fdt. ...
> > ...
> >>>> diff --git a/include/fdtdec.h b/include/fdtdec.h
> >>> ...
> >>>> +/* GPIOs are numbered from 0 */
> >>>> +enum {
> >>>> +     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */
> >>>
> >>> Is this due to the way U-Boot works right now, or something defined by
> >>> this patch? It's been pointed out that the kernel's choice to use -1 as
> >>> "invalid GPIO" rather than 0 was a mistake, since that prevents GPIO
> >>> fields being easily added to platform data structures, since you then
> >>> have to go and initialize every new instance to -1, rather than relying
> >>> on BSS initializing it to 0. I assume this is just the way U-Boot works,
> >>> so solving this is outside the scope of this patch.
> >>
> >> It is nothing to do with U-Boot itself - we can choose any number.
> >
> > Surely the value you choose for DT parsing has to align with the value
> > that U-Boot's GPIO API chooses, so you can't just choose any number.
> 
> No, in the fdt we just leave out the gpio if it is not required. The
> FDT_GPIO_NONE is purely internal to U-Boot.

That's consistent with what I said; I'm talking about the value that a
missing DT property translates into within U-Boot.

-- 
nvpublic

Re: [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions

[Simon Glass]

Hi Stephen,

On Tue, Jan 24, 2012 at 3:14 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Simon Glass wrote at Tuesday, January 24, 2012 4:12 PM:
>> On Mon, Jan 23, 2012 at 10:18 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> > On 01/21/2012 10:08 AM, Simon Glass wrote:
>> >> Hi Stephen,
>> >>
>> >> On Wed, Jan 18, 2012 at 2:17 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> >>> On 01/11/2012 09:32 PM, Simon Glass wrote:
>> >>>> This adds some support into fdtdec for reading GPIO definitions from
>> >>>> the fdt. ...
>> > ...
>> >>>> diff --git a/include/fdtdec.h b/include/fdtdec.h
>> >>> ...
>> >>>> +/* GPIOs are numbered from 0 */
>> >>>> +enum {
>> >>>> +     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */
>> >>>
>> >>> Is this due to the way U-Boot works right now, or something defined by
>> >>> this patch? It's been pointed out that the kernel's choice to use -1 as
>> >>> "invalid GPIO" rather than 0 was a mistake, since that prevents GPIO
>> >>> fields being easily added to platform data structures, since you then
>> >>> have to go and initialize every new instance to -1, rather than relying
>> >>> on BSS initializing it to 0. I assume this is just the way U-Boot works,
>> >>> so solving this is outside the scope of this patch.
>> >>
>> >> It is nothing to do with U-Boot itself - we can choose any number.
>> >
>> > Surely the value you choose for DT parsing has to align with the value
>> > that U-Boot's GPIO API chooses, so you can't just choose any number.
>>
>> No, in the fdt we just leave out the gpio if it is not required. The
>> FDT_GPIO_NONE is purely internal to U-Boot.
>
> That's consistent with what I said; I'm talking about the value that a
> missing DT property translates into within U-Boot.

OK I see. I'm not proposing to change U-Boot convention now (if in
fact it has one). At least FDT_GPIO_NONE is a constant that people
need to check against (but they should use fdt_gpio_isvalid()
instead). We can adjust this in the future if U-Boot people want to.

Regards,
Simon
>
> --
> nvpublic
>

[PATCH v4 04/20] arm: fdt: Ensure that an embedded fdt is word-aligned

[Simon Glass]

By putting the fdt blob into a distinctive area we can ensure that it appears
at the start of the data section and is word-aligned.

Note: It does not seem to be possible to get objcopy to honour its
--section-alignment flag, which would otherwise provide an easier fix
for this problem.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 arch/arm/cpu/armv7/u-boot.lds |    5 +++++
 dts/Makefile                  |    2 +-
 2 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 40ecf78..793e51b 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -43,6 +43,11 @@ SECTIONS
 
 	. = ALIGN(4);
 	.data : {
+		/*
+		 * Sadly objcopy seems to ignore --section-alignment.
+		 * Put any embedded device tree first so it is aligned.
+		 */
+		*(.dts.data)
 		*(.data)
 	}
 
diff --git a/dts/Makefile b/dts/Makefile
index 5792afd..83547d4 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -79,7 +79,7 @@ $(obj)dt.o: $(DT_BIN)
 	\
 	cd $(dir ${DT_BIN}) && \
 	$(OBJCOPY) -I binary -O $${oformat} -B $${oarch} \
-		$(notdir ${DT_BIN}) $@
+		--prefix-sections=.dts $(notdir ${DT_BIN}) $@
 	rm $(DT_BIN)
 
 OBJS-$(CONFIG_OF_EMBED)	:= dt.o
-- 
1.7.7.3

Re: [PATCH v4 04/20] arm: fdt: Ensure that an embedded fdt is word-aligned

[Albert ARIBAUD]

Hi Simon,

Le 12/01/2012 05:32, Simon Glass a écrit :
> By putting the fdt blob into a distinctive area we can ensure that it appears
> at the start of the data section and is word-aligned.
>
> Note: It does not seem to be possible to get objcopy to honour its
> --section-alignment flag, which would otherwise provide an easier fix
> for this problem.

Stop me if I am wrong, but objcopy obviously works with output sections 
of its input file, not with input ones that this file was linked from, 
and so it cannot act upon alignment of data input sections, right? And 
as, before your patch, there is no designated output section for DTS 
data, it ends up (possibly mis-aligned) in the .data output section 
(which is globally aligned however), so there is no chance anyway that 
objcopy can re-align DTS data if they were mis-aligned.

So I must be missing something. Can you clarify the scenario that gets 
fixed here?

Not that I am against the patch, mind you, quite the opposite. I am just 
wondering about the pros and cons of having a separated (and aligned) 
DTS data *output* section and placing that section after .code and .data 
rather than between them.

Amicalement,
-- 
Albert.

Re: [PATCH v4 04/20] arm: fdt: Ensure that an embedded fdt is word-aligned

[Simon Glass]

[-- Attachment #1.1: Type: text/plain, Size: 2030 bytes --]

Hi Albert,

On Feb 18, 2012 3:51 AM, "Albert ARIBAUD" <albert.u.boot@aribaud.net> wrote:
>
> Hi Simon,
>
> Le 12/01/2012 05:32, Simon Glass a écrit :
>
>> By putting the fdt blob into a distinctive area we can ensure that it
appears
>> at the start of the data section and is word-aligned.
>>
>> Note: It does not seem to be possible to get objcopy to honour its
>> --section-alignment flag, which would otherwise provide an easier fix
>> for this problem.
>
>
> Stop me if I am wrong, but objcopy obviously works with output sections
of its input file, not with input ones that this file was linked from, and
so it cannot act upon alignment of data input sections, right? And as,
before your patch, there is no designated output section for DTS data, it
ends up (possibly mis-aligned) in the .data output section (which is
globally aligned however), so there is no chance anyway that objcopy can
re-align DTS data if they were mis-aligned.

Well that's a shame if true. I was rather hoping that it would respect
input section alignment when packing into an output section - it must do
that in at least some cases since otherise I don't see how code regions
could be collected together without one becoming misaligned if the one
before was an odd size.

>
> So I must be missing something. Can you clarify the scenario that gets
fixed here?

The fdt blob is in one of the object files. If during linking the file
before it has a data segment whose size is not a multiple of 4, then the
fdt object can be misaligned in the output.

>
> Not that I am against the patch, mind you, quite the opposite. I am just
wondering about the pros and cons of having a separated (and aligned) DTS
data *output* section and placing that section after .code and .data rather
than between them.

Bear in mind that embedding the fdt in the image is really only for
development.

We could have a separate output section if you like. Up to you.

Regards,
Simon

>
> Amicalement,
> --
> Albert.

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [PATCH v4 04/20] arm: fdt: Ensure that an embedded fdt is word-aligned

[Albert ARIBAUD]

Hi Simon,

Le 18/02/2012 19:09, Simon Glass a écrit :
> Hi Albert,
>
> On Feb 18, 2012 3:51 AM, "Albert ARIBAUD"<albert.u.boot@aribaud.net>  wrote:
>>
>> Hi Simon,
>>
>> Le 12/01/2012 05:32, Simon Glass a écrit :
>>
>>> By putting the fdt blob into a distinctive area we can ensure that it
> appears
>>> at the start of the data section and is word-aligned.
>>>
>>> Note: It does not seem to be possible to get objcopy to honour its
>>> --section-alignment flag, which would otherwise provide an easier fix
>>> for this problem.
>>
>>
>> Stop me if I am wrong, but objcopy obviously works with output sections
> of its input file, not with input ones that this file was linked from, and
> so it cannot act upon alignment of data input sections, right? And as,
> before your patch, there is no designated output section for DTS data, it
> ends up (possibly mis-aligned) in the .data output section (which is
> globally aligned however), so there is no chance anyway that objcopy can
> re-align DTS data if they were mis-aligned.
>
> Well that's a shame if true. I was rather hoping that it would respect
> input section alignment when packing into an output section - it must do
> that in at least some cases since otherise I don't see how code regions
> could be collected together without one becoming misaligned if the one
> before was an odd size.

Objcopy is only a utility to convert built binaries from one format to 
another, and rightly ignores any alignment considerations. Alignment 
constraints are solved at link time within the .lds file. This is why I 
suggest a separate output section in u-boot.lds, because then you can 
set that section's alignment where all alignment constraints are laid out.

>> So I must be missing something. Can you clarify the scenario that gets
> fixed here?
>
> The fdt blob is in one of the object files. If during linking the file
> before it has a data segment whose size is not a multiple of 4, then the
> fdt object can be misaligned in the output.

Understood. This example of an alignment failure scenario shows that the 
failure cause is indeed that the FDT is embedded in the .data output 
section at link time.

>> Not that I am against the patch, mind you, quite the opposite. I am just
> wondering about the pros and cons of having a separated (and aligned) DTS
> data *output* section and placing that section after .code and .data rather
> than between them.
>
> Bear in mind that embedding the fdt in the image is really only for
> development.

Understood, and I think that's one more reason to make sure that the act 
of FDT embedding does not alter .data input section ordering.

> We could have a separate output section if you like. Up to you.

I much prefer embedded FDT data to be explicitly mapped to a a dedicated 
.fdt output section in u-boot.lds, because it ensures that aligment 
constaints for .fdt and .data can be controlled independently.

> Regards,
> Simon

Amicalement,
-- 
Albert.

Re: [PATCH v4 04/20] arm: fdt: Ensure that an embedded fdt is word-aligned

[Simon Glass]

[-- Attachment #1.1: Type: text/plain, Size: 3733 bytes --]

Hi Albert,

On Feb 19, 2012 12:27 AM, "Albert ARIBAUD" <albert.u.boot@aribaud.net>
wrote:
>
> Hi Simon,
>
> Le 18/02/2012 19:09, Simon Glass a écrit :
>
>> Hi Albert,
>>
>> On Feb 18, 2012 3:51 AM, "Albert ARIBAUD"<albert.u.boot@aribaud.net>
 wrote:
>>>
>>>
>>> Hi Simon,
>>>
>>> Le 12/01/2012 05:32, Simon Glass a écrit :
>>>
>>>> By putting the fdt blob into a distinctive area we can ensure that it
>>
>> appears
>>>>
>>>> at the start of the data section and is word-aligned.
>>>>
>>>> Note: It does not seem to be possible to get objcopy to honour its
>>>> --section-alignment flag, which would otherwise provide an easier fix
>>>> for this problem.
>>>
>>>
>>>
>>> Stop me if I am wrong, but objcopy obviously works with output sections
>>
>> of its input file, not with input ones that this file was linked from,
and
>> so it cannot act upon alignment of data input sections, right? And as,
>> before your patch, there is no designated output section for DTS data, it
>> ends up (possibly mis-aligned) in the .data output section (which is
>> globally aligned however), so there is no chance anyway that objcopy can
>> re-align DTS data if they were mis-aligned.
>>
>> Well that's a shame if true. I was rather hoping that it would respect
>> input section alignment when packing into an output section - it must do
>> that in at least some cases since otherise I don't see how code regions
>> could be collected together without one becoming misaligned if the one
>> before was an odd size.
>
>
> Objcopy is only a utility to convert built binaries from one format to
another, and rightly ignores any alignment considerations. Alignment
constraints are solved at link time within the .lds file. This is why I
suggest a separate output section in u-boot.lds, because then you can set
that section's alignment where all alignment constraints are laid out.
>

Sorry I had that wrong - it's not the link step I am bothered by, it is the
objcopy step.

What I would like to do is mark the input section, created by objcopy, with
a particular alignment so that the linker does the right thing. This
feature appears to be present in objcopy but does not appear to work.
Perhaps I should debug that first to see what is going on.

>
>>> So I must be missing something. Can you clarify the scenario that gets
>>
>> fixed here?
>>
>> The fdt blob is in one of the object files. If during linking the file
>> before it has a data segment whose size is not a multiple of 4, then the
>> fdt object can be misaligned in the output.
>
>
> Understood. This example of an alignment failure scenario shows that the
failure cause is indeed that the FDT is embedded in the .data output
section at link time.
>
>
>>> Not that I am against the patch, mind you, quite the opposite. I am just
>>
>> wondering about the pros and cons of having a separated (and aligned) DTS
>> data *output* section and placing that section after .code and .data
rather
>> than between them.
>>
>> Bear in mind that embedding the fdt in the image is really only for
>> development.
>
>
> Understood, and I think that's one more reason to make sure that the act
of FDT embedding does not alter .data input section ordering.
>

Well it is just a data section really.

>
>> We could have a separate output section if you like. Up to you.
>
>
> I much prefer embedded FDT data to be explicitly mapped to a a dedicated
.fdt output section in u-boot.lds, because it ensures that aligment
constaints for .fdt and .data can be controlled independently.

I will take a look at this.

Regards,
Simon

>
>
>> Regards,
>> Simon
>
>
> Amicalement,
> --
> Albert.

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [PATCH v4 04/20] arm: fdt: Ensure that an embedded fdt is word-aligned

[Albert ARIBAUD]

Hi Simon,

Le 19/02/2012 17:23, Simon Glass a écrit :

> Sorry I had that wrong - it's not the link step I am bothered by, it is the
> objcopy step.
>
> What I would like to do is mark the input section, created by objcopy, with
> a particular alignment so that the linker does the right thing. This
> feature appears to be present in objcopy but does not appear to work.
> Perhaps I should debug that first to see what is going on.

(Formally there are two "objcopy steps" in u-boot building. One happens 
after the link step, where from the u-boot ELF binary objcopy derives 
the u-boot.bin pure binary and u-boot.srec S-Record file. I suspect 
you're referring to the other one, which happens before the link stage 
and which turns the binary FDT data into an ELF-linkable object. Correct?)

Maybe one is allowed to specify alignment requirements when making an 
ELF object file from a pure binary with objcopy; but obviously it does 
not work as you want it to, whereas section alignment in linker scripts 
is a tried and proven method.

>>>> So I must be missing something. Can you clarify the scenario that gets
>>>
>>> fixed here?
>>>
>>> The fdt blob is in one of the object files. If during linking the file
>>> before it has a data segment whose size is not a multiple of 4, then the
>>> fdt object can be misaligned in the output.
>>
>>
>> Understood. This example of an alignment failure scenario shows that the
> failure cause is indeed that the FDT is embedded in the .data output
> section at link time.
>>
>>
>>>> Not that I am against the patch, mind you, quite the opposite. I am just
>>>
>>> wondering about the pros and cons of having a separated (and aligned) DTS
>>> data *output* section and placing that section after .code and .data
> rather
>>> than between them.
>>>
>>> Bear in mind that embedding the fdt in the image is really only for
>>> development.
>>
>>
>> Understood, and I think that's one more reason to make sure that the act
> of FDT embedding does not alter .data input section ordering.
>
> Well it is just a data section really.

So are the relocation tables in .rel.dyn and .dynsyms, but that does not 
mean they have to go to the "dot data" output section.

>>> We could have a separate output section if you like. Up to you.
>>
>>
>> I much prefer embedded FDT data to be explicitly mapped to a a dedicated
> .fdt output section in u-boot.lds, because it ensures that aligment
> constaints for .fdt and .data can be controlled independently.
>
> I will take a look at this.

Thanks. This should be fairly easy to do in the linker script by 
inserting an output section (e.g. ".fdt") after .data, aligning the 
start of that section to a word boundary, and explicitly mapping the 
.data section of the FDT object file into it.

> Regards,
> Simon

Amicalement,
-- 
Albert.

Re: [PATCH v4 04/20] arm: fdt: Ensure that an embedded fdt is word-aligned

[Simon Glass]

Hi Albert,

On Sun, Feb 19, 2012 at 10:33 AM, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:
> Hi Simon,
>
> Le 19/02/2012 17:23, Simon Glass a écrit :
>
>
>> Sorry I had that wrong - it's not the link step I am bothered by, it is
>> the
>> objcopy step.
>>
>> What I would like to do is mark the input section, created by objcopy,
>> with
>> a particular alignment so that the linker does the right thing. This
>> feature appears to be present in objcopy but does not appear to work.
>> Perhaps I should debug that first to see what is going on.
>
>
> (Formally there are two "objcopy steps" in u-boot building. One happens
> after the link step, where from the u-boot ELF binary objcopy derives the
> u-boot.bin pure binary and u-boot.srec S-Record file. I suspect you're
> referring to the other one, which happens before the link stage and which
> turns the binary FDT data into an ELF-linkable object. Correct?)
>
> Maybe one is allowed to specify alignment requirements when making an ELF
> object file from a pure binary with objcopy; but obviously it does not work
> as you want it to, whereas section alignment in linker scripts is a tried
> and proven method.
>
>
>>>>> So I must be missing something. Can you clarify the scenario that gets
>>>>
>>>>
>>>> fixed here?
>>>>
>>>> The fdt blob is in one of the object files. If during linking the file
>>>> before it has a data segment whose size is not a multiple of 4, then the
>>>> fdt object can be misaligned in the output.
>>>
>>>
>>>
>>> Understood. This example of an alignment failure scenario shows that the
>>
>> failure cause is indeed that the FDT is embedded in the .data output
>> section at link time.
>>>
>>>
>>>
>>>>> Not that I am against the patch, mind you, quite the opposite. I am
>>>>> just
>>>>
>>>>
>>>> wondering about the pros and cons of having a separated (and aligned)
>>>> DTS
>>>> data *output* section and placing that section after .code and .data
>>
>> rather
>>>>
>>>> than between them.
>>>>
>>>> Bear in mind that embedding the fdt in the image is really only for
>>>> development.
>>>
>>>
>>>
>>> Understood, and I think that's one more reason to make sure that the act
>>
>> of FDT embedding does not alter .data input section ordering.
>>
>> Well it is just a data section really.
>
>
> So are the relocation tables in .rel.dyn and .dynsyms, but that does not
> mean they have to go to the "dot data" output section.
>
>
>>>> We could have a separate output section if you like. Up to you.
>>>
>>>
>>>
>>> I much prefer embedded FDT data to be explicitly mapped to a a dedicated
>>
>> .fdt output section in u-boot.lds, because it ensures that aligment
>> constaints for .fdt and .data can be controlled independently.
>>
>> I will take a look at this.
>
>
> Thanks. This should be fairly easy to do in the linker script by inserting
> an output section (e.g. ".fdt") after .data, aligning the start of that
> section to a word boundary, and explicitly mapping the .data section of the
> FDT object file into it.

Just an update on this: I am going to drop this patch from the series
now and deal with it later once the lds cleanup series lands. I don't
want to patch a file that is being removed.

Regards,
Simon

>
>
>> Regards,
>> Simon
>
>
> Amicalement,
> --
> Albert.

[PATCH v4 06/20] tegra: fdt: Add Tegra2x device tree file from kernel

[Simon Glass]

This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git

config.mk is updated to provide this file to boards through the
built-in mechanism:

/include/ ARCH_CPU_DTS

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 arch/arm/cpu/armv7/tegra2/config.mk |    2 +
 arch/arm/dts/tegra20.dtsi           |  169 +++++++++++++++++++++++++++++++++++
 2 files changed, 171 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/dts/tegra20.dtsi

diff --git a/arch/arm/cpu/armv7/tegra2/config.mk b/arch/arm/cpu/armv7/tegra2/config.mk
index 2303dba..fe9ef5b 100644
--- a/arch/arm/cpu/armv7/tegra2/config.mk
+++ b/arch/arm/cpu/armv7/tegra2/config.mk
@@ -31,3 +31,5 @@ CFLAGS_arch/arm/lib/board.o += -march=armv4t
 endif
 
 USE_PRIVATE_LIBGCC = yes
+
+CONFIG_ARCH_DEVICE_TREE := tegra20
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
new file mode 100644
index 0000000..6146d24
--- /dev/null
+++ b/arch/arm/dts/tegra20.dtsi
@@ -0,0 +1,169 @@
+/include/ "skeleton.dtsi"
+
+/ {
+	compatible = "nvidia,tegra20";
+	interrupt-parent = <&intc>;
+
+	intc: interrupt-controller@50041000 {
+		compatible = "nvidia,tegra20-gic";
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		reg = < 0x50041000 0x1000 >,
+		      < 0x50040100 0x0100 >;
+	};
+
+	i2c@7000c000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "nvidia,tegra20-i2c";
+		reg = <0x7000C000 0x100>;
+		interrupts = < 70 >;
+	};
+
+	i2c@7000c400 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "nvidia,tegra20-i2c";
+		reg = <0x7000C400 0x100>;
+		interrupts = < 116 >;
+	};
+
+	i2c@7000c500 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "nvidia,tegra20-i2c";
+		reg = <0x7000C500 0x100>;
+		interrupts = < 124 >;
+	};
+
+	i2c@7000d000 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "nvidia,tegra20-i2c";
+		reg = <0x7000D000 0x200>;
+		interrupts = < 85 >;
+	};
+
+	i2s@70002800 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "nvidia,tegra20-i2s";
+		reg = <0x70002800 0x200>;
+		interrupts = < 45 >;
+		dma-channel = < 2 >;
+	};
+
+	i2s@70002a00 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "nvidia,tegra20-i2s";
+		reg = <0x70002a00 0x200>;
+		interrupts = < 35 >;
+		dma-channel = < 1 >;
+	};
+
+	das@70000c00 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "nvidia,tegra20-das";
+		reg = <0x70000c00 0x80>;
+	};
+
+	gpio: gpio@6000d000 {
+		compatible = "nvidia,tegra20-gpio";
+		reg = < 0x6000d000 0x1000 >;
+		interrupts = < 64 65 66 67 87 119 121 >;
+		#gpio-cells = <2>;
+		gpio-controller;
+	};
+
+	pinmux: pinmux@70000000 {
+		compatible = "nvidia,tegra20-pinmux";
+		reg = < 0x70000014 0x10    /* Tri-state registers */
+			0x70000080 0x20    /* Mux registers */
+			0x700000a0 0x14    /* Pull-up/down registers */
+			0x70000868 0xa8 >; /* Pad control registers */
+	};
+
+	serial@70006000 {
+		compatible = "nvidia,tegra20-uart";
+		reg = <0x70006000 0x40>;
+		reg-shift = <2>;
+		interrupts = < 68 >;
+	};
+
+	serial@70006040 {
+		compatible = "nvidia,tegra20-uart";
+		reg = <0x70006040 0x40>;
+		reg-shift = <2>;
+		interrupts = < 69 >;
+	};
+
+	serial@70006200 {
+		compatible = "nvidia,tegra20-uart";
+		reg = <0x70006200 0x100>;
+		reg-shift = <2>;
+		interrupts = < 78 >;
+	};
+
+	serial@70006300 {
+		compatible = "nvidia,tegra20-uart";
+		reg = <0x70006300 0x100>;
+		reg-shift = <2>;
+		interrupts = < 122 >;
+	};
+
+	serial@70006400 {
+		compatible = "nvidia,tegra20-uart";
+		reg = <0x70006400 0x100>;
+		reg-shift = <2>;
+		interrupts = < 123 >;
+	};
+
+	sdhci@c8000000 {
+		compatible = "nvidia,tegra20-sdhci";
+		reg = <0xc8000000 0x200>;
+		interrupts = < 46 >;
+	};
+
+	sdhci@c8000200 {
+		compatible = "nvidia,tegra20-sdhci";
+		reg = <0xc8000200 0x200>;
+		interrupts = < 47 >;
+	};
+
+	sdhci@c8000400 {
+		compatible = "nvidia,tegra20-sdhci";
+		reg = <0xc8000400 0x200>;
+		interrupts = < 51 >;
+	};
+
+	sdhci@c8000600 {
+		compatible = "nvidia,tegra20-sdhci";
+		reg = <0xc8000600 0x200>;
+		interrupts = < 63 >;
+	};
+
+	usb@c5000000 {
+		compatible = "nvidia,tegra20-ehci", "usb-ehci";
+		reg = <0xc5000000 0x4000>;
+		interrupts = < 52 >;
+		phy_type = "utmi";
+	};
+
+	usb@c5004000 {
+		compatible = "nvidia,tegra20-ehci", "usb-ehci";
+		reg = <0xc5004000 0x4000>;
+		interrupts = < 53 >;
+		phy_type = "ulpi";
+	};
+
+	usb@c5008000 {
+		compatible = "nvidia,tegra20-ehci", "usb-ehci";
+		reg = <0xc5008000 0x4000>;
+		interrupts = < 129 >;
+		phy_type = "utmi";
+	};
+
+};
+
-- 
1.7.7.3

Re: [PATCH v4 06/20] tegra: fdt: Add Tegra2x device tree file from kernel

[Stephen Warren]

On 01/11/2012 09:32 PM, Simon Glass wrote:
> This was taken from commit b48c54e2 at:
> git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
> 
> config.mk is updated to provide this file to boards through the
> built-in mechanism:
> 
> /include/ ARCH_CPU_DTS
> 
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

> diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
...
> +	i2c@7000d000 {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		compatible = "nvidia,tegra20-i2c";
> +		reg = <0x7000D000 0x200>;
> +		interrupts = < 85 >;
> +	};

This is slightly out-of-date now; in next-20120118, that node's
compatible flag is nvidia,tegra20-i2c-dvc. The HW register layout is
somewhat different for this I2C controller, and the different compatible
flag is how the driver this.

Still, you can always apply that fix in a later patch before you add I2C
support.

-- 
nvpublic

Re: [PATCH v4 06/20] tegra: fdt: Add Tegra2x device tree file from kernel

[Simon Glass]

Hi Stephen,

On Wed, Jan 18, 2012 at 2:24 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 01/11/2012 09:32 PM, Simon Glass wrote:
>> This was taken from commit b48c54e2 at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
>>
>> config.mk is updated to provide this file to boards through the
>> built-in mechanism:
>>
>> /include/ ARCH_CPU_DTS
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>
>> diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
> ...
>> +     i2c@7000d000 {
>> +             #address-cells = <1>;
>> +             #size-cells = <0>;
>> +             compatible = "nvidia,tegra20-i2c";
>> +             reg = <0x7000D000 0x200>;
>> +             interrupts = < 85 >;
>> +     };
>
> This is slightly out-of-date now; in next-20120118, that node's
> compatible flag is nvidia,tegra20-i2c-dvc. The HW register layout is
> somewhat different for this I2C controller, and the different compatible
> flag is how the driver this.
>
> Still, you can always apply that fix in a later patch before you add I2C
> support.

This series was original submitted 24 November, so of course things
change. The changes you mention relate to I2C and I think I picked
these up in the later I2C patches.

But since we are chasing a moving target, I really don't want to get
too worried about redoing all the patches every time the kernel burps
:-) The changes you mention are not even in mainline yet and don't
relate to USB (this series).

Is it ok to adopt this sort of thinking throughout these series? As
you know it is easy to pick up a new fdt file later and make any
changes that are needed. I am well aware that things are still in
flux.

Regards,
Simon

>
> --
> nvpublic

Re: [PATCH v4 06/20] tegra: fdt: Add Tegra2x device tree file from kernel

[Stephen Warren]

On 01/19/2012 04:51 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Wed, Jan 18, 2012 at 2:24 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 01/11/2012 09:32 PM, Simon Glass wrote:
>>> This was taken from commit b48c54e2 at:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
>>>
>>> config.mk is updated to provide this file to boards through the
>>> built-in mechanism:
>>>
>>> /include/ ARCH_CPU_DTS
>>>
>>> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>>
>>> diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
>> ...
>>> +     i2c@7000d000 {
>>> +             #address-cells = <1>;
>>> +             #size-cells = <0>;
>>> +             compatible = "nvidia,tegra20-i2c";
>>> +             reg = <0x7000D000 0x200>;
>>> +             interrupts = < 85 >;
>>> +     };
>>
>> This is slightly out-of-date now; in next-20120118, that node's
>> compatible flag is nvidia,tegra20-i2c-dvc. The HW register layout is
>> somewhat different for this I2C controller, and the different compatible
>> flag is how the driver this.
>>
>> Still, you can always apply that fix in a later patch before you add I2C
>> support.
> 
> This series was original submitted 24 November, so of course things
> change. The changes you mention relate to I2C and I think I picked
> these up in the later I2C patches.

As I said, as long as this is updated before the I2C support that relies
on it (as IIRC your I2C patch series did), that's fine.

-- 
nvpublic

[PATCH v4 07/20] tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel

[Simon Glass]

This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 board/nvidia/dts/tegra2-seaboard.dts |   36 ++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)
 create mode 100644 board/nvidia/dts/tegra2-seaboard.dts

diff --git a/board/nvidia/dts/tegra2-seaboard.dts b/board/nvidia/dts/tegra2-seaboard.dts
new file mode 100644
index 0000000..dde5d03
--- /dev/null
+++ b/board/nvidia/dts/tegra2-seaboard.dts
@@ -0,0 +1,36 @@
+/dts-v1/;
+
+/memreserve/ 0x1c000000 0x04000000;
+/include/ ARCH_CPU_DTS
+
+/ {
+	model = "NVIDIA Seaboard";
+	compatible = "nvidia,seaboard", "nvidia,tegra20";
+
+	chosen {
+		bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/mmcblk1p3 rw rootwait";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = < 0x00000000 0x40000000 >;
+	};
+
+	serial@70006300 {
+		clock-frequency = < 216000000 >;
+	};
+
+	sdhci@c8000400 {
+		cd-gpios = <&gpio 69 0>; /* gpio PI5 */
+		wp-gpios = <&gpio 57 0>; /* gpio PH1 */
+		power-gpios = <&gpio 70 0>; /* gpio PI6 */
+	};
+
+	sdhci@c8000600 {
+		support-8bit;
+	};
+
+	usb@c5000000 {
+		nvidia,vbus-gpio = <&gpio 24 0>; /* PD0 */
+	};
+};
-- 
1.7.7.3

Re: [PATCH v4 07/20] tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel

[Stephen Warren]

On 01/11/2012 09:32 PM, Simon Glass wrote:
> This was taken from commit b48c54e2 at:
> git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

> diff --git a/board/nvidia/dts/tegra2-seaboard.dts b/board/nvidia/dts/tegra2-seaboard.dts

This is also somewhat out-of-date w.r.t. the latest in kernel tag
next-20120118. It's probably not too much of an issue, so this is
probably fine to apply as-is. U-Boot may benefit from the addition of
many status="disable" properties, and clock-frequency properties for the
I2C nodes. It'd be good to keep U-Boot up-to-date with the kernel as
much as possible. Of course, there are ongoing changes being queued for
the kernel as work is done too...

-- 
nvpublic

Re: [PATCH v4 07/20] tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel

[Simon Glass]

Hi Stephen,

On Wed, Jan 18, 2012 at 2:28 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 01/11/2012 09:32 PM, Simon Glass wrote:
>> This was taken from commit b48c54e2 at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>
>> diff --git a/board/nvidia/dts/tegra2-seaboard.dts b/board/nvidia/dts/tegra2-seaboard.dts
>
> This is also somewhat out-of-date w.r.t. the latest in kernel tag
> next-20120118. It's probably not too much of an issue, so this is
> probably fine to apply as-is. U-Boot may benefit from the addition of
> many status="disable" properties, and clock-frequency properties for the
> I2C nodes. It'd be good to keep U-Boot up-to-date with the kernel as
> much as possible. Of course, there are ongoing changes being queued for
> the kernel as work is done too...
>

OK once everything is in we can do any updates that then exist based
on what is finalised in the kernel.

Regards,
Simon

> --
> nvpublic

[PATCH v4 08/20] fdt: Add staging area for device tree binding documentation

[Simon Glass]

Add a directory to hold device tree binding files, to permit easy review
of this material in U-Boot patches.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v4:
- Add staging area for device tree bindings used in U-Boot

 doc/device-tree-bindings/README |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)
 create mode 100644 doc/device-tree-bindings/README

diff --git a/doc/device-tree-bindings/README b/doc/device-tree-bindings/README
new file mode 100644
index 0000000..84e8cba
--- /dev/null
+++ b/doc/device-tree-bindings/README
@@ -0,0 +1,19 @@
+Device Tree Bindings Staging Area
+=================================
+
+This directory contains device tree bindings for U-Boot.
+
+These follow along with Linux kernel bindings, with a few additions. By
+adding the files here, U-Boot patches can clearly show thees additions.
+This makes it easier for device tree people to review these additions in
+patches sent to the U-Boot mailing list.
+
+The intent is not to commit these files to U-Boot, or at least only
+temporarily, Rather we hope that the files will be stored in another
+repo (shared with Linux) which is brought in as needed. Failing that,
+changes here will be  commited to the Linux
+Documentation/devicetree/bindings/ directory.
+
+
+sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org
+11-Jan-12
-- 
1.7.7.3

Re: [PATCH v4 08/20] fdt: Add staging area for device tree binding documentation

[Stephen Warren]

On 01/11/2012 09:32 PM, Simon Glass wrote:
> Add a directory to hold device tree binding files, to permit easy review
> of this material in U-Boot patches.
> 
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

> diff --git a/doc/device-tree-bindings/README b/doc/device-tree-bindings/README

> +The intent is not to commit these files to U-Boot, or at least only
> +temporarily, Rather we hope that the files will be stored in another
> +repo (shared with Linux) which is brought in as needed. Failing that,
> +changes here will be  commited to the Linux
> +Documentation/devicetree/bindings/ directory.

Given there is no shared repo right now, I'd assert we should be
specific and explicitly state that the intent /is/ to check in the
binding documentation here, and mirror the kernel tree.

But, the patch is fine to me as-is if you wish.

-- 
nvpublic

Re: [PATCH v4 08/20] fdt: Add staging area for device tree binding documentation

[Simon Glass]

Hi Stephen,

On Wed, Jan 18, 2012 at 2:30 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 01/11/2012 09:32 PM, Simon Glass wrote:
>> Add a directory to hold device tree binding files, to permit easy review
>> of this material in U-Boot patches.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>
>> diff --git a/doc/device-tree-bindings/README b/doc/device-tree-bindings/README
>
>> +The intent is not to commit these files to U-Boot, or at least only
>> +temporarily, Rather we hope that the files will be stored in another
>> +repo (shared with Linux) which is brought in as needed. Failing that,
>> +changes here will be  commited to the Linux
>> +Documentation/devicetree/bindings/ directory.
>
> Given there is no shared repo right now, I'd assert we should be
> specific and explicitly state that the intent /is/ to check in the
> binding documentation here, and mirror the kernel tree.
>
> But, the patch is fine to me as-is if you wish.

I'm fine with this too, it probably is more sensible if the U-Boot PTB
don't mind.

Regards,
Simon

>
> --
> nvpublic

[PATCH v4 09/20] fdt: Add tegra-usb bindings file from linux

[Simon Glass]

This file is taken from the Linux mailing list.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 doc/device-tree-bindings/usb/tegra-usb.txt |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)
 create mode 100644 doc/device-tree-bindings/usb/tegra-usb.txt

diff --git a/doc/device-tree-bindings/usb/tegra-usb.txt b/doc/device-tree-bindings/usb/tegra-usb.txt
new file mode 100644
index 0000000..035d63d
--- /dev/null
+++ b/doc/device-tree-bindings/usb/tegra-usb.txt
@@ -0,0 +1,13 @@
+Tegra SOC USB controllers
+
+The device node for a USB controller that is part of a Tegra
+SOC is as described in the document "Open Firmware Recommended
+Practice : Universal Serial Bus" with the following modifications
+and additions :
+
+Required properties :
+ - compatible : Should be "nvidia,tegra20-ehci" for USB controllers
+   used in host mode.
+ - phy_type : Should be one of "ulpi" or "utmi".
+ - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
+   activated for the bus to be powered.
-- 
1.7.7.3

[PATCH v4 11/20] tegra: fdt: Add clock bindings

[Simon Glass]

This adds a basic binding for the oscillator and peripheral clocks. The
second cell is the clock number, defined as the bit number within the clock
enable register if the peripheral clock.

This uses the RFC clock bindings from Grant Likely so may change later:

https://lkml.org/lkml/2011/12/12/498

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v4:
- Add clock bindings for Tegra2x

 arch/arm/dts/tegra20.dtsi                      |   27 ++++++++++++
 doc/device-tree-bindings/clock/tegra-periphclk |   51 ++++++++++++++++++++++++
 2 files changed, 78 insertions(+), 0 deletions(-)
 create mode 100644 doc/device-tree-bindings/clock/tegra-periphclk

diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 6146d24..68eae12 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -4,6 +4,33 @@
 	compatible = "nvidia,tegra20";
 	interrupt-parent = <&intc>;
 
+	clocks = <&osc_clk>;
+	clock-names = "osc_clk";
+	clock-ranges;
+
+	clocks {
+		#address-cells = <1>;
+		#size-cells = <1>;
+
+		/* The frequency of this clock is board-specific */
+		osc_clk: oscclk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+		};
+
+		/*
+		 * This node provides clocks to all peripherals. We don't
+		 * enumerate the clock names for now since there are no
+		 * users of this information.
+		 */
+		periph_clk: periphclk {
+			compatible = "tegra,periphclk";
+			#clock-cells = <1>;
+			clocks = <&osc_clk>;
+			reg = <0x60006000 400>;
+		};
+	};
+
 	intc: interrupt-controller@50041000 {
 		compatible = "nvidia,tegra20-gic";
 		interrupt-controller;
diff --git a/doc/device-tree-bindings/clock/tegra-periphclk b/doc/device-tree-bindings/clock/tegra-periphclk
new file mode 100644
index 0000000..8d21e4d
--- /dev/null
+++ b/doc/device-tree-bindings/clock/tegra-periphclk
@@ -0,0 +1,51 @@
+Clock controllers
+
+(there isn't yet a binding in Linux, so this describes what is in U-Boot)
+
+The device node for a clock controller is as described in the document
+"Open Firmware Recommended Practice : Universal Serial Bus" with the
+following modifications and additions :
+
+This is based on Grant Likely's proposed patch for clock bindings.
+
+Required properties :
+ - compatible : Should be "tegra,periphclk" for peripheral clock controller
+ - clocks : Should contain a single phandle pointing to the oscillator clock
+
+Peripherals which refer to a clock should have a property called "clocks" with
+two cells: phandle of the peripheral clock and the clock ID number (which
+is the bit number in the peripheral clock controller enable register numbered
+from 0).
+
+Example:
+
+clocks {
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	/* The frequency of this clock is board-specific */
+	osc_clk: oscclk {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	/*
+	 * This node provides clocks to all peripherals. We don't
+	 * enumerate the clock names for now since there are no
+	 * users of this information.
+	 */
+	periph_clk: periphclk {
+		compatible = "tegra,periphclk";
+		#clock-cells = <1>;
+		clocks = <&osc_clk>;
+		reg = <0x60006000 400>;
+	};
+};
+
+usb@c5004000 {
+	compatible = "nvidia,tegra20-ehci", "usb-ehci";
+	reg = <0xc5004000 0x4000>;
+	interrupts = < 53 >;
+	phy_type = "ulpi";
+	clocks = <&periph_clk 58>;	// PERIPH_ID_USB2
+};
-- 
1.7.7.3

[PATCH] ARM: tegra: Define Tegra20 CAR binding

[Stephen Warren]

Document a binding for the Tegra20 CAR (Clock And Reset) Controller,
add it to tegra20.dtsi, and configure it for the board in tegra-
seaboard.dts.

Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
All, Simon Glass is attempting to upstream Tegra USB support in U-Boot.
The driver is only instantiated from device tree, and needs to configure
clocks for the USB module. Hence, he proposed a clock binding for Tegra.
I've read through Grant's proposed common clock bindings and reworked
Simon's proposal a little, ending up with the patch below for the kernel.
I'd appreciate any comments you have.

Grant, can you confirm that it's reasonable to start making use of your
proposed common clock bindings in U-Boot, even though they're only an RFC?

Grant, there are a couple of FIXMEs in the binding documentation below.
Can you give any insight on these?

A comment on the shared enable issue:

When enabling/disabling clocks, Tegra requires you to reset the HW module
that the clock is routed to. Both reset and clock enable registers are
part of the CAR. U-Boot currently has an API to do the reset based on a
"peripheral ID", which simply means a bit number in a set of 3 "reset"
registers. The bits in those registers share the same numbering as the
"clock enable" registers. Hence, to make life easy for U-Boot, I've
defined the clock IDs in this binding to be equal to these bit numbers.
However, this breaks down where there isn't a 1:1 mapping between reset
and clock enable bits, and clocks. For example, there's a single reset
and clock enable bit for the SPDIF controller, yet this applies to two
clocks; spdif_in and spdif_out. Hence, this simplification for U-Boot
breaks down. I think the correct solution is to fix U-Boot not to
require this simplification, renumber the clocks in the CAR binding in
a completely arbitrary fashion, and require U-Boot to contain a mapping
table between CAR's DT clock IDs and any other information related to
those clocks. Do you see any alternative? We really need the two SPDIF
clocks to be different clock IDs in the binding, since each has a
completely independant mux for the clock source/parent, and the two
clocks obviously can't share the same clock ID (well, hmm, perhaps they
could if we used 2 cells for the specifier, 1 for the bit number, and
one more to differentiate clocks that use the same bit...). I'm still
inclined to simply push back on U-Boot to do it right.

 .../bindings/clock/nvidia,tegra20-car.txt          |  156 ++++++++++++++++++++
 arch/arm/boot/dts/tegra-seaboard.dts               |   18 +++
 arch/arm/boot/dts/tegra20.dtsi                     |    7 +
 3 files changed, 181 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt

diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
new file mode 100644
index 0000000..71cfdd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -0,0 +1,156 @@
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,<chip>-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- clock-names : Should contain a list of strings, with values "32k_in",
+  and "osc".
+- #clock-cells : Should be 1.
+  In clock consumers, this cell represents the clock ID exposed by the CAR.
+  For a list of valid values, see the clock-output-names property.
+
+Optional properties :
+- clock-output-names : Should contain a list of strings defining the clocks
+  that the CAR provides. The list of names and clock IDs is below. The IDs
+  may be used in clock specifiers. The names should be listed in this clock-
+  output-names property, sorted in ID order, if this property is present.
+
+  The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+  registers. Later, subsequent IDs will be assigned to all other clocks the
+  CAR controls.
+
+    0   "cpu"
+    1   "unassigned"
+    2   "unassigned"    FIXME: Is it OK to have 2 identical (unused) names?
+    3   "ac97"
+    4   "rtc"
+    5   "tmr"
+    6   "uart1"
+    7   "uart2"
+    8   "gpio"
+    9   "sdmmc2"
+    10  "spdif"         FIXME: One enable bit controls two clocks!!!
+    11  "i2s1"
+    12  "i2c1"
+    13  "ndflash"
+    14  "sdmmc1"
+    15  "sdmmc4"
+    16  "twc"
+    17  "pwm"
+    18  "i2s2"
+    19  "epp"
+    20  "vi"            FIXME: One enable bit controls two clocks!!!
+    21  "2d"
+    22  "usbd"
+    23  "isp"
+    24  "3d"
+    25  "ide"
+    26  "disp2"
+    27  "disp1"
+    28  "host1x"
+    29  "vcp"
+    30  "unassigned"
+    31  "cache2"
+
+    32  "mem"
+    33  "ahbdma"
+    34  "apbdma"
+    35  "unassigned"
+    36  "kbc"
+    37  "stat_mon"
+    38  "pmc"
+    39  "fuse"
+    40  "kfuse"
+    41  "sbc1"
+    42  "snor"
+    43  "spi"
+    44  "sbc2"
+    45  "xio"
+    46  "sbc3"
+    47  "dvc_i2c"
+    48  "dsi"
+    49  "tvo"
+    50  "mipi"
+    51  "hdmi"
+    52  "csi"
+    53  "tvdac"
+    54  "i2c2"
+    55  "uart3"
+    56  "unassigned"
+    57  "emc"
+    58  "usb2"
+    59  "usb3"
+    60  "mpe"
+    61  "vde"
+    62  "bsea"
+    63  "bsev"
+
+    64  "speedo"
+    65  "uart4"
+    66  "uart5"
+    67  "i2c3"
+    68  "sbc4"
+    69  "sdmmc3"
+    70  "pcie"
+    71  "owr"
+    72  "afi"
+    73  "csite"
+    74  "unassigned"
+    75  "avpucq"
+    76  "unassigned"
+    77  "unassigned"
+    78  "unassigned"
+    79  "unassigned"
+    80  "unassigned"
+    81  "unassigned"
+    82  "unassigned"
+    83  "unassigned"
+    84  "irama"
+    85  "iramb"
+    86  "iramc"
+    87  "iramd"
+    88  "cram2"
+    89  "audio_2x"
+    90  "clk_d"
+    91  "unassigned"
+    92  "sus"
+    93  "cdev1"
+    94  "cdev2"
+    95  "unassigned"
+
+Example:
+
+clocks {
+	clk_32k: oscillator@0 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <32768>;
+	};
+
+	osc: oscillator@1 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+		clock-frequency = <12000000>;
+	};
+};
+
+tegar_car: clock@60006000 {
+	compatible = "tegra,periphclk";
+	reg = <0x60006000 1000>;
+	clocks = <&clk_32k> <&osc>;
+	clock-names = "32k_in", "osc";
+	#clock-cells = <1>;
+};
+
+usb@c5004000 {
+	...
+	clocks = <&tegra_car 58>; /* usb2 */
+};
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts b/arch/arm/boot/dts/tegra-seaboard.dts
index b55a02e..f9347fe 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -11,6 +11,24 @@
 		reg = < 0x00000000 0x40000000 >;
 	};
 
+	clocks {
+		clk_32k: oscillator@0 {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+
+		osc: oscillator@1 {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <12000000>;
+		};
+	};
+
+	clock@60006000 {
+		clocks = <&clk_32k> <&osc>;
+	};
+
 	i2c@7000c000 {
 		clock-frequency = <400000>;
 	};
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 3da7afd..be4abd2 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -4,6 +4,13 @@
 	compatible = "nvidia,tegra20";
 	interrupt-parent = <&intc>;
 
+	tegar_car: clock@60006000 {
+		compatible = "tegra,periphclk";
+		reg = <0x60006000 1000>;
+		clock-names = "32k_in", "osc";
+		#clock-cells = <1>;
+	};
+
 	intc: interrupt-controller@50041000 {
 		compatible = "arm,cortex-a9-gic";
 		interrupt-controller;
-- 
1.7.0.4

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Olof Johansson]

Hi,

On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:

>  .../bindings/clock/nvidia,tegra20-car.txt          |  156 ++++++++++++++++++++
>  arch/arm/boot/dts/tegra-seaboard.dts               |   18 +++
>  arch/arm/boot/dts/tegra20.dtsi                     |    7 +
>  3 files changed, 181 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> new file mode 100644
> index 0000000..71cfdd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> @@ -0,0 +1,156 @@
> +* NVIDIA Tegra20 Clock And Reset Controller
> +
> +This binding uses the common clock binding:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
> +for muxing and gating Tegra's clocks, and setting their rates.
> +
> +Required properties :
> +- compatible : Should be "nvidia,<chip>-car"
> +- reg : Should contain CAR registers location and length
> +- clocks : Should contain phandle and clock specifiers for two clocks:
> +  the 32 KHz "32k_in", and the board-specific oscillator "osc".
> +- clock-names : Should contain a list of strings, with values "32k_in",
> +  and "osc".

Hmm. I'd prefer to just ditch the notion of "clock-names" in the cases
where it isn't strictly necessary. Just because some vendors don't want
to define an order between their clocks doesn't mean it's a good idea
for everybody to use that model. In this case, just declaring that the
two clocks refs have to be to those two clocks in that order should
be sufficient.

> +- #clock-cells : Should be 1.
> +  In clock consumers, this cell represents the clock ID exposed by the CAR.
> +  For a list of valid values, see the clock-output-names property.
> +
> +Optional properties :
> +- clock-output-names : Should contain a list of strings defining the clocks
> +  that the CAR provides. The list of names and clock IDs is below. The IDs
> +  may be used in clock specifiers. The names should be listed in this clock-
> +  output-names property, sorted in ID order, if this property is present.
> +
> +  The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
> +  registers. Later, subsequent IDs will be assigned to all other clocks the
> +  CAR controls.

Aren't these names hardcoded per SoC? If so, they can be derived from the
compatible field + output number without having a table in the device tree.

If anything, you might want to enumerate the allowed/expected values, but
actually putting them in a property seems overkill.

[...]

> +Example:
> +
> +clocks {
> +	clk_32k: oscillator@0 {

If it has a unit addres (@<x>) it needs a reg property with the same base
address.

> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <32768>;
> +	};
> +
> +	osc: oscillator@1 {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +		clock-frequency = <12000000>;
> +	};
> +};
> +
> +tegar_car: clock@60006000 {

typo? tegra_car?

> +	compatible = "tegra,periphclk";
> +	reg = <0x60006000 1000>;
> +	clocks = <&clk_32k> <&osc>;
> +	clock-names = "32k_in", "osc";
> +	#clock-cells = <1>;
> +};
> +
> +usb@c5004000 {
> +	...
> +	clocks = <&tegra_car 58>; /* usb2 */
> +};

RE: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Stephen Warren]

Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
> On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
> > diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> > +* NVIDIA Tegra20 Clock And Reset Controller
> > +
> > +This binding uses the common clock binding:
> > +Documentation/devicetree/bindings/clock/clock-bindings.txt
> > +
> > +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
> > +for muxing and gating Tegra's clocks, and setting their rates.
> > +
> > +Required properties :
> > +- compatible : Should be "nvidia,<chip>-car"
> > +- reg : Should contain CAR registers location and length
> > +- clocks : Should contain phandle and clock specifiers for two clocks:
> > +  the 32 KHz "32k_in", and the board-specific oscillator "osc".
> > +- clock-names : Should contain a list of strings, with values "32k_in",
> > +  and "osc".
> 
> Hmm. I'd prefer to just ditch the notion of "clock-names" in the cases
> where it isn't strictly necessary. Just because some vendors don't want
> to define an order between their clocks doesn't mean it's a good idea
> for everybody to use that model. In this case, just declaring that the
> two clocks refs have to be to those two clocks in that order should
> be sufficient.

OK, that seems reasonable. I'm happy using of_clk_get() rather than
of_clk_get_by_name(). I guess that means we should just avoid any
discussion of clock-output-names too.

> > +- #clock-cells : Should be 1.
> > +  In clock consumers, this cell represents the clock ID exposed by the CAR.
> > +  For a list of valid values, see the clock-output-names property.
> > +
> > +Optional properties :
> > +- clock-output-names : Should contain a list of strings defining the clocks
> > +  that the CAR provides. The list of names and clock IDs is below. The IDs
> > +  may be used in clock specifiers. The names should be listed in this clock-
> > +  output-names property, sorted in ID order, if this property is present.
> > +
> > +  The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
> > +  registers. Later, subsequent IDs will be assigned to all other clocks the
> > +  CAR controls.
> 
> Aren't these names hardcoded per SoC? If so, they can be derived from the
> compatible field + output number without having a table in the device tree.
>
> If anything, you might want to enumerate the allowed/expected values, but
> actually putting them in a property seems overkill.

Yes, the set of clocks is hard-coded per SoC, and the clock is uniquely
identified by compatible+id.

clock-output-names doesn't actually serve any functional purpose in
Grant's common clock bindings patches; it's more of a documentation
thing. As such, yes, I can remove the suggestion to actually put the
table into the device tree, and rework the binding to simply define
what the mapping is independently.

...
> > +Example:
> > +
> > +clocks {
> > +	clk_32k: oscillator@0 {
> 
> If it has a unit addres (@<x>) it needs a reg property with the same base
> address.

I thought everything needed a unit address period? Is the rule more like
the unit address is optional, but if present must match reg, so I can
simply remove @0 and @1 here? I guess that makes a lot more sense.

> > +		compatible = "fixed-clock";
> > +		#clock-cells = <0>;
> > +		clock-frequency = <32768>;
> > +	};
> > +
> > +	osc: oscillator@1 {
> > +		compatible = "fixed-clock";
> > +		#clock-cells = <0>;
> > +		clock-frequency = <12000000>;
> > +	};
> > +};

-- 
nvpublic

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Olof Johansson]

Hi,

On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
>> On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
>> > diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
>> > +* NVIDIA Tegra20 Clock And Reset Controller
>> > +
>> > +This binding uses the common clock binding:
>> > +Documentation/devicetree/bindings/clock/clock-bindings.txt
>> > +
>> > +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
>> > +for muxing and gating Tegra's clocks, and setting their rates.
>> > +
>> > +Required properties :
>> > +- compatible : Should be "nvidia,<chip>-car"
>> > +- reg : Should contain CAR registers location and length
>> > +- clocks : Should contain phandle and clock specifiers for two clocks:
>> > +  the 32 KHz "32k_in", and the board-specific oscillator "osc".
>> > +- clock-names : Should contain a list of strings, with values "32k_in",
>> > +  and "osc".
>>
>> Hmm. I'd prefer to just ditch the notion of "clock-names" in the cases
>> where it isn't strictly necessary. Just because some vendors don't want
>> to define an order between their clocks doesn't mean it's a good idea
>> for everybody to use that model. In this case, just declaring that the
>> two clocks refs have to be to those two clocks in that order should
>> be sufficient.
>
> OK, that seems reasonable. I'm happy using of_clk_get() rather than
> of_clk_get_by_name(). I guess that means we should just avoid any
> discussion of clock-output-names too.

Sounds good to me. Let's make sure Grant is OK with it too though.

>> > +- #clock-cells : Should be 1.
>> > +  In clock consumers, this cell represents the clock ID exposed by the CAR.
>> > +  For a list of valid values, see the clock-output-names property.
>> > +
>> > +Optional properties :
>> > +- clock-output-names : Should contain a list of strings defining the clocks
>> > +  that the CAR provides. The list of names and clock IDs is below. The IDs
>> > +  may be used in clock specifiers. The names should be listed in this clock-
>> > +  output-names property, sorted in ID order, if this property is present.
>> > +
>> > +  The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
>> > +  registers. Later, subsequent IDs will be assigned to all other clocks the
>> > +  CAR controls.
>>
>> Aren't these names hardcoded per SoC? If so, they can be derived from the
>> compatible field + output number without having a table in the device tree.
>>
>> If anything, you might want to enumerate the allowed/expected values, but
>> actually putting them in a property seems overkill.
>
> Yes, the set of clocks is hard-coded per SoC, and the clock is uniquely
> identified by compatible+id.
>
> clock-output-names doesn't actually serve any functional purpose in
> Grant's common clock bindings patches; it's more of a documentation
> thing. As such, yes, I can remove the suggestion to actually put the
> table into the device tree, and rework the binding to simply define
> what the mapping is independently.

Again, sounds good to me.

>> > +Example:
>> > +
>> > +clocks {
>> > +   clk_32k: oscillator@0 {
>>
>> If it has a unit addres (@<x>) it needs a reg property with the same base
>> address.
>
> I thought everything needed a unit address period? Is the rule more like
> the unit address is optional, but if present must match reg, so I can
> simply remove @0 and @1 here? I guess that makes a lot more sense.

Nope, you only need a unit address to make a node unique, i.e. if you
have more than one with the same name. It's not something that's been
followed very well on ARM dts files, I have even seen review comments
asking for explicit unit IDs when none are needed.

So you can't remove @0 and @1 here, since there are two oscillator subnodes.

I'm not 100% sure if you have to have the unit address represented as
"reg" or not, but it should probably be represented by _something_ in
the properties of the node. Mitch? Segher? :)


>> > +           compatible = "fixed-clock";
>> > +           #clock-cells = <0>;
>> > +           clock-frequency = <32768>;
>> > +   };
>> > +
>> > +   osc: oscillator@1 {
>> > +           compatible = "fixed-clock";
>> > +           #clock-cells = <0>;
>> > +           clock-frequency = <12000000>;
>> > +   };
>> > +};


-Olof

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Mitch Bradley]

On 1/20/2012 9:32 PM, Olof Johansson wrote:
> Hi,
>
> On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren<swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>  wrote:
>> Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
>>> On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
>>>> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
>>>> +* NVIDIA Tegra20 Clock And Reset Controller
>>>> +
>>>> +This binding uses the common clock binding:
>>>> +Documentation/devicetree/bindings/clock/clock-bindings.txt
>>>> +
>>>> +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
>>>> +for muxing and gating Tegra's clocks, and setting their rates.
>>>> +
>>>> +Required properties :
>>>> +- compatible : Should be "nvidia,<chip>-car"
>>>> +- reg : Should contain CAR registers location and length
>>>> +- clocks : Should contain phandle and clock specifiers for two clocks:
>>>> +  the 32 KHz "32k_in", and the board-specific oscillator "osc".
>>>> +- clock-names : Should contain a list of strings, with values "32k_in",
>>>> +  and "osc".
>>>
>>> Hmm. I'd prefer to just ditch the notion of "clock-names" in the cases
>>> where it isn't strictly necessary. Just because some vendors don't want
>>> to define an order between their clocks doesn't mean it's a good idea
>>> for everybody to use that model. In this case, just declaring that the
>>> two clocks refs have to be to those two clocks in that order should
>>> be sufficient.
>>
>> OK, that seems reasonable. I'm happy using of_clk_get() rather than
>> of_clk_get_by_name(). I guess that means we should just avoid any
>> discussion of clock-output-names too.
>
> Sounds good to me. Let's make sure Grant is OK with it too though.
>
>>>> +- #clock-cells : Should be 1.
>>>> +  In clock consumers, this cell represents the clock ID exposed by the CAR.
>>>> +  For a list of valid values, see the clock-output-names property.
>>>> +
>>>> +Optional properties :
>>>> +- clock-output-names : Should contain a list of strings defining the clocks
>>>> +  that the CAR provides. The list of names and clock IDs is below. The IDs
>>>> +  may be used in clock specifiers. The names should be listed in this clock-
>>>> +  output-names property, sorted in ID order, if this property is present.
>>>> +
>>>> +  The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
>>>> +  registers. Later, subsequent IDs will be assigned to all other clocks the
>>>> +  CAR controls.
>>>
>>> Aren't these names hardcoded per SoC? If so, they can be derived from the
>>> compatible field + output number without having a table in the device tree.
>>>
>>> If anything, you might want to enumerate the allowed/expected values, but
>>> actually putting them in a property seems overkill.
>>
>> Yes, the set of clocks is hard-coded per SoC, and the clock is uniquely
>> identified by compatible+id.
>>
>> clock-output-names doesn't actually serve any functional purpose in
>> Grant's common clock bindings patches; it's more of a documentation
>> thing. As such, yes, I can remove the suggestion to actually put the
>> table into the device tree, and rework the binding to simply define
>> what the mapping is independently.
>
> Again, sounds good to me.
>
>>>> +Example:
>>>> +
>>>> +clocks {
>>>> +   clk_32k: oscillator@0 {
>>>
>>> If it has a unit addres (@<x>) it needs a reg property with the same base
>>> address.
>>
>> I thought everything needed a unit address period? Is the rule more like
>> the unit address is optional, but if present must match reg, so I can
>> simply remove @0 and @1 here? I guess that makes a lot more sense.
>
> Nope, you only need a unit address to make a node unique, i.e. if you
> have more than one with the same name. It's not something that's been
> followed very well on ARM dts files, I have even seen review comments
> asking for explicit unit IDs when none are needed.
>
> So you can't remove @0 and @1 here, since there are two oscillator subnodes.
>
> I'm not 100% sure if you have to have the unit address represented as
> "reg" or not, but it should probably be represented by _something_ in
> the properties of the node. Mitch? Segher? :)

unit-address is, by definition, the first address component of reg

>
>
>>>> +           compatible = "fixed-clock";
>>>> +           #clock-cells =<0>;
>>>> +           clock-frequency =<32768>;
>>>> +   };
>>>> +
>>>> +   osc: oscillator@1 {
>>>> +           compatible = "fixed-clock";
>>>> +           #clock-cells =<0>;
>>>> +           clock-frequency =<12000000>;
>>>> +   };
>>>> +};
>
>
> -Olof
>
>

RE: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Stephen Warren]

Olof Johansson wrote at Saturday, January 21, 2012 12:32 AM:
> On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
> >> On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
> >> > diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> >> > +* NVIDIA Tegra20 Clock And Reset Controller
> >> > +
> >> > +This binding uses the common clock binding:
> >> > +Documentation/devicetree/bindings/clock/clock-bindings.txt
> >> > +
> >> > +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
> >> > +for muxing and gating Tegra's clocks, and setting their rates.
> >> > +
> >> > +Required properties :
> >> > +- compatible : Should be "nvidia,<chip>-car"
> >> > +- reg : Should contain CAR registers location and length
> >> > +- clocks : Should contain phandle and clock specifiers for two clocks:
> >> > +  the 32 KHz "32k_in", and the board-specific oscillator "osc".
> >> > +- clock-names : Should contain a list of strings, with values "32k_in",
> >> > +  and "osc".
...
> >> > +Example:
> >> > +
> >> > +clocks {
> >> > +   clk_32k: oscillator@0 {
> >>
> >> If it has a unit addres (@<x>) it needs a reg property with the same base
> >> address.
> >
> > I thought everything needed a unit address period? Is the rule more like
> > the unit address is optional, but if present must match reg, so I can
> > simply remove @0 and @1 here? I guess that makes a lot more sense.
> 
> Nope, you only need a unit address to make a node unique, i.e. if you
> have more than one with the same name. It's not something that's been
> followed very well on ARM dts files, I have even seen review comments
> asking for explicit unit IDs when none are needed.
> 
> So you can't remove @0 and @1 here, since there are two oscillator subnodes.

If I keep the unit address, then I need to add a reg property per Mitch's
response. But, then I need #address-cells and #size-cells in the clock
node too. Yuck, since this isn't an addressable bus.

Instead, is it acceptable to simply rename the nodes to e.g.:

clk_32k: clock {...};
osc: crystal {...};

In the long term, I believe that osc/crystal is going to continue to
be a top-level object, but clk_32k is actually an output from the PMU
chip, and hence there won't be any naming conflict here anyway...

-- 
nvpublic

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Mitch Bradley]

On 1/23/2012 6:18 AM, Stephen Warren wrote:
> Olof Johansson wrote at Saturday, January 21, 2012 12:32 AM:
>> On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren<swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>  wrote:
>>> Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
>>>> On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
>>>>> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
>>>>> +* NVIDIA Tegra20 Clock And Reset Controller
>>>>> +
>>>>> +This binding uses the common clock binding:
>>>>> +Documentation/devicetree/bindings/clock/clock-bindings.txt
>>>>> +
>>>>> +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
>>>>> +for muxing and gating Tegra's clocks, and setting their rates.
>>>>> +
>>>>> +Required properties :
>>>>> +- compatible : Should be "nvidia,<chip>-car"
>>>>> +- reg : Should contain CAR registers location and length
>>>>> +- clocks : Should contain phandle and clock specifiers for two clocks:
>>>>> +  the 32 KHz "32k_in", and the board-specific oscillator "osc".
>>>>> +- clock-names : Should contain a list of strings, with values "32k_in",
>>>>> +  and "osc".
> ...
>>>>> +Example:
>>>>> +
>>>>> +clocks {
>>>>> +   clk_32k: oscillator@0 {
>>>>
>>>> If it has a unit addres (@<x>) it needs a reg property with the same base
>>>> address.
>>>
>>> I thought everything needed a unit address period? Is the rule more like
>>> the unit address is optional, but if present must match reg, so I can
>>> simply remove @0 and @1 here? I guess that makes a lot more sense.
>>
>> Nope, you only need a unit address to make a node unique, i.e. if you
>> have more than one with the same name. It's not something that's been
>> followed very well on ARM dts files, I have even seen review comments
>> asking for explicit unit IDs when none are needed.
>>
>> So you can't remove @0 and @1 here, since there are two oscillator subnodes.
>
> If I keep the unit address, then I need to add a reg property per Mitch's
> response. But, then I need #address-cells and #size-cells in the clock
> node too. Yuck, since this isn't an addressable bus.
>
> Instead, is it acceptable to simply rename the nodes to e.g.:
>
> clk_32k: clock {...};
> osc: crystal {...};


One consideration:  These nodes are children of a parent, so that parent 
is implicitly a "bus node", even though there is no physical hardware 
bus.  The path resolution rules say that, in the absence of a 
"#address-cells" property in a bus node, the default value is 2.  So any 
code that implements that rule will think these nodes are missing a 
"reg" property, thus triggering the "wildcard node" rule, which says 
that you can match the node with any unit address.

Whether or not that would cause problems in practice is hard to say.  I 
think that my Open Firmware implementation would handle it okay, but I 
can't speak to the Linux device tree code.

I'm not sure why you thing "yuck" about synthesizing an address space 
for the subnodes.  It doesn't seem that bad to me.

>
> In the long term, I believe that osc/crystal is going to continue to
> be a top-level object, but clk_32k is actually an output from the PMU
> chip, and hence there won't be any naming conflict here anyway...
>

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Grant Likely]

On Fri, Jan 20, 2012 at 11:32:04PM -0800, Olof Johansson wrote:
> Hi,
> 
> On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
> >> On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
> >> > diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> >> > +* NVIDIA Tegra20 Clock And Reset Controller
> >> > +
> >> > +This binding uses the common clock binding:
> >> > +Documentation/devicetree/bindings/clock/clock-bindings.txt
> >> > +
> >> > +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
> >> > +for muxing and gating Tegra's clocks, and setting their rates.
> >> > +
> >> > +Required properties :
> >> > +- compatible : Should be "nvidia,<chip>-car"
> >> > +- reg : Should contain CAR registers location and length
> >> > +- clocks : Should contain phandle and clock specifiers for two clocks:
> >> > +  the 32 KHz "32k_in", and the board-specific oscillator "osc".
> >> > +- clock-names : Should contain a list of strings, with values "32k_in",
> >> > +  and "osc".
> >>
> >> Hmm. I'd prefer to just ditch the notion of "clock-names" in the cases
> >> where it isn't strictly necessary. Just because some vendors don't want
> >> to define an order between their clocks doesn't mean it's a good idea
> >> for everybody to use that model. In this case, just declaring that the
> >> two clocks refs have to be to those two clocks in that order should
> >> be sufficient.
> >
> > OK, that seems reasonable. I'm happy using of_clk_get() rather than
> > of_clk_get_by_name(). I guess that means we should just avoid any
> > discussion of clock-output-names too.
> 
> Sounds good to me. Let's make sure Grant is OK with it too though.

Yes, I agree.

g.

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Simon Glass]

Hi Stephen,

On Wed, Jan 18, 2012 at 4:16 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Document a binding for the Tegra20 CAR (Clock And Reset) Controller,
> add it to tegra20.dtsi, and configure it for the board in tegra-
> seaboard.dts.
>
> Signed-off-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> All, Simon Glass is attempting to upstream Tegra USB support in U-Boot.
> The driver is only instantiated from device tree, and needs to configure
> clocks for the USB module. Hence, he proposed a clock binding for Tegra.
> I've read through Grant's proposed common clock bindings and reworked
> Simon's proposal a little, ending up with the patch below for the kernel.
> I'd appreciate any comments you have.
>
> Grant, can you confirm that it's reasonable to start making use of your
> proposed common clock bindings in U-Boot, even though they're only an RFC?
>
> Grant, there are a couple of FIXMEs in the binding documentation below.
> Can you give any insight on these?
>
> A comment on the shared enable issue:
>
> When enabling/disabling clocks, Tegra requires you to reset the HW module
> that the clock is routed to. Both reset and clock enable registers are
> part of the CAR. U-Boot currently has an API to do the reset based on a
> "peripheral ID", which simply means a bit number in a set of 3 "reset"
> registers. The bits in those registers share the same numbering as the
> "clock enable" registers. Hence, to make life easy for U-Boot, I've
> defined the clock IDs in this binding to be equal to these bit numbers.
> However, this breaks down where there isn't a 1:1 mapping between reset
> and clock enable bits, and clocks. For example, there's a single reset
> and clock enable bit for the SPDIF controller, yet this applies to two
> clocks; spdif_in and spdif_out. Hence, this simplification for U-Boot
> breaks down. I think the correct solution is to fix U-Boot not to
> require this simplification, renumber the clocks in the CAR binding in
> a completely arbitrary fashion, and require U-Boot to contain a mapping
> table between CAR's DT clock IDs and any other information related to
> those clocks. Do you see any alternative? We really need the two SPDIF
> clocks to be different clock IDs in the binding, since each has a
> completely independant mux for the clock source/parent, and the two
> clocks obviously can't share the same clock ID (well, hmm, perhaps they
> could if we used 2 cells for the specifier, 1 for the bit number, and
> one more to differentiate clocks that use the same bit...). I'm still
> inclined to simply push back on U-Boot to do it right.

Are SPDIF and VI the only examples of this? If so, perhaps just having
a special extra clock ID for those two and mapping in a special way
would be more efficient. So two IDs would map to one clock/reset bit
but different clocks.

Also I note that one is an input and one is an output clock. So we
could name them this way, and use the separate ID for the input clocks
perhaps.

If you do add an arbitrary mapping, what would it be? It might as well
follow along with the registers so far as it can, since the device
tree should describe the hardware. Then the mapping becomes a few
lines of code in the driver instead of YAT (yet another table).

Poor U-Boot doesn't even use the SPDIF or vi controllers.

>
>  .../bindings/clock/nvidia,tegra20-car.txt          |  156 ++++++++++++++++++++
>  arch/arm/boot/dts/tegra-seaboard.dts               |   18 +++
>  arch/arm/boot/dts/tegra20.dtsi                     |    7 +
>  3 files changed, 181 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> new file mode 100644
> index 0000000..71cfdd2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
> @@ -0,0 +1,156 @@
> +* NVIDIA Tegra20 Clock And Reset Controller
> +
> +This binding uses the common clock binding:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
> +for muxing and gating Tegra's clocks, and setting their rates.
> +
> +Required properties :
> +- compatible : Should be "nvidia,<chip>-car"
> +- reg : Should contain CAR registers location and length
> +- clocks : Should contain phandle and clock specifiers for two clocks:
> +  the 32 KHz "32k_in", and the board-specific oscillator "osc".
> +- clock-names : Should contain a list of strings, with values "32k_in",
> +  and "osc".
> +- #clock-cells : Should be 1.
> +  In clock consumers, this cell represents the clock ID exposed by the CAR.
> +  For a list of valid values, see the clock-output-names property.
> +
> +Optional properties :
> +- clock-output-names : Should contain a list of strings defining the clocks
> +  that the CAR provides. The list of names and clock IDs is below. The IDs
> +  may be used in clock specifiers. The names should be listed in this clock-
> +  output-names property, sorted in ID order, if this property is present.
> +
> +  The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
> +  registers. Later, subsequent IDs will be assigned to all other clocks the
> +  CAR controls.

I hope that at some point these would have symbolic names so that we
don't need to use open-coded integers in the device tree cells.

> +
> +    0   "cpu"
> +    1   "unassigned"
> +    2   "unassigned"    FIXME: Is it OK to have 2 identical (unused) names?

Or in fact just empty so save space?

> +    3   "ac97"
> +    4   "rtc"
> +    5   "tmr"
> +    6   "uart1"
> +    7   "uart2"
> +    8   "gpio"
> +    9   "sdmmc2"
> +    10  "spdif"         FIXME: One enable bit controls two clocks!!!
> +    11  "i2s1"
> +    12  "i2c1"
> +    13  "ndflash"
> +    14  "sdmmc1"
> +    15  "sdmmc4"
> +    16  "twc"
> +    17  "pwm"
> +    18  "i2s2"
> +    19  "epp"
> +    20  "vi"            FIXME: One enable bit controls two clocks!!!
> +    21  "2d"
> +    22  "usbd"
> +    23  "isp"
> +    24  "3d"
> +    25  "ide"
> +    26  "disp2"
> +    27  "disp1"
> +    28  "host1x"
> +    29  "vcp"
> +    30  "unassigned"
> +    31  "cache2"
> +
> +    32  "mem"
> +    33  "ahbdma"
> +    34  "apbdma"
> +    35  "unassigned"
> +    36  "kbc"
> +    37  "stat_mon"
> +    38  "pmc"
> +    39  "fuse"
> +    40  "kfuse"
> +    41  "sbc1"
> +    42  "snor"
> +    43  "spi"
> +    44  "sbc2"
> +    45  "xio"
> +    46  "sbc3"
> +    47  "dvc_i2c"
> +    48  "dsi"
> +    49  "tvo"
> +    50  "mipi"
> +    51  "hdmi"
> +    52  "csi"
> +    53  "tvdac"
> +    54  "i2c2"
> +    55  "uart3"
> +    56  "unassigned"
> +    57  "emc"
> +    58  "usb2"
> +    59  "usb3"
> +    60  "mpe"
> +    61  "vde"
> +    62  "bsea"
> +    63  "bsev"
> +
> +    64  "speedo"
> +    65  "uart4"
> +    66  "uart5"
> +    67  "i2c3"
> +    68  "sbc4"
> +    69  "sdmmc3"
> +    70  "pcie"
> +    71  "owr"
> +    72  "afi"
> +    73  "csite"
> +    74  "unassigned"
> +    75  "avpucq"
> +    76  "unassigned"
> +    77  "unassigned"
> +    78  "unassigned"
> +    79  "unassigned"
> +    80  "unassigned"
> +    81  "unassigned"
> +    82  "unassigned"
> +    83  "unassigned"
> +    84  "irama"
> +    85  "iramb"
> +    86  "iramc"
> +    87  "iramd"
> +    88  "cram2"
> +    89  "audio_2x"
> +    90  "clk_d"
> +    91  "unassigned"
> +    92  "sus"
> +    93  "cdev1"
> +    94  "cdev2"
> +    95  "unassigned"
> +
> +Example:
> +
> +clocks {
> +       clk_32k: oscillator@0 {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <32768>;
> +       };
> +
> +       osc: oscillator@1 {
> +               compatible = "fixed-clock";
> +               #clock-cells = <0>;
> +               clock-frequency = <12000000>;
> +       };
> +};
> +
> +tegar_car: clock@60006000 {
> +       compatible = "tegra,periphclk";
> +       reg = <0x60006000 1000>;

0x1000 ?

> +       clocks = <&clk_32k> <&osc>;
> +       clock-names = "32k_in", "osc";
> +       #clock-cells = <1>;
> +};
> +
> +usb@c5004000 {
> +       ...
> +       clocks = <&tegra_car 58>; /* usb2 */
> +};
> diff --git a/arch/arm/boot/dts/tegra-seaboard.dts b/arch/arm/boot/dts/tegra-seaboard.dts
> index b55a02e..f9347fe 100644
> --- a/arch/arm/boot/dts/tegra-seaboard.dts
> +++ b/arch/arm/boot/dts/tegra-seaboard.dts
> @@ -11,6 +11,24 @@
>                reg = < 0x00000000 0x40000000 >;
>        };
>
> +       clocks {
> +               clk_32k: oscillator@0 {
> +                       compatible = "fixed-clock";
> +                       #clock-cells = <0>;
> +                       clock-frequency = <32768>;
> +               };
> +
> +               osc: oscillator@1 {
> +                       compatible = "fixed-clock";
> +                       #clock-cells = <0>;
> +                       clock-frequency = <12000000>;
> +               };

Is there a reason why these two nodes are in the tegra20.dtsi include
file? Is it because some boards don't have one of these clocks? Or
because the frequency is not know? If the former, perhaps used status
= "disabled" and if the latter perhaps define only the frequency in
this file? Just trying to reduce boilerplate and complexity for board
bring-up engineers.

Also the oscillator frequency seems to be detected at run-time. What
happens if it doesn't match the fdt? Should be not detect it at
run-time?

> +       };
> +
> +       clock@60006000 {
> +               clocks = <&clk_32k> <&osc>;

Why is the clocks property here, but the clock-names property in the
include file?

> +       };
> +
>        i2c@7000c000 {
>                clock-frequency = <400000>;
>        };
> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
> index 3da7afd..be4abd2 100644
> --- a/arch/arm/boot/dts/tegra20.dtsi
> +++ b/arch/arm/boot/dts/tegra20.dtsi
> @@ -4,6 +4,13 @@
>        compatible = "nvidia,tegra20";
>        interrupt-parent = <&intc>;
>
> +       tegar_car: clock@60006000 {

Is car a standard name? If not tegra_clk_rst would be an alternative.

> +               compatible = "tegra,periphclk";
> +               reg = <0x60006000 1000>;

0x1000 ?

> +               clock-names = "32k_in", "osc";
> +               #clock-cells = <1>;
> +       };
> +
>        intc: interrupt-controller@50041000 {
>                compatible = "arm,cortex-a9-gic";
>                interrupt-controller;
> --
> 1.7.0.4
>

Regards,
Simon

RE: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Stephen Warren]

Simon Glass wrote at Sunday, January 22, 2012 11:03 AM:
> On Wed, Jan 18, 2012 at 4:16 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > Document a binding for the Tegra20 CAR (Clock And Reset) Controller,
> > add it to tegra20.dtsi, and configure it for the board in tegra-
> > seaboard.dts.
...
> > A comment on the shared enable issue:
> >
> > When enabling/disabling clocks, Tegra requires you to reset the HW module
> > that the clock is routed to. Both reset and clock enable registers are
> > part of the CAR. U-Boot currently has an API to do the reset based on a
> > "peripheral ID", which simply means a bit number in a set of 3 "reset"
> > registers. The bits in those registers share the same numbering as the
> > "clock enable" registers. Hence, to make life easy for U-Boot, I've
> > defined the clock IDs in this binding to be equal to these bit numbers.
> > However, this breaks down where there isn't a 1:1 mapping between reset
> > and clock enable bits, and clocks. For example, there's a single reset
> > and clock enable bit for the SPDIF controller, yet this applies to two
> > clocks; spdif_in and spdif_out. Hence, this simplification for U-Boot
> > breaks down. I think the correct solution is to fix U-Boot not to
> > require this simplification, renumber the clocks in the CAR binding in
> > a completely arbitrary fashion, and require U-Boot to contain a mapping
> > table between CAR's DT clock IDs and any other information related to
> > those clocks. Do you see any alternative? We really need the two SPDIF
> > clocks to be different clock IDs in the binding, since each has a
> > completely independant mux for the clock source/parent, and the two
> > clocks obviously can't share the same clock ID (well, hmm, perhaps they
> > could if we used 2 cells for the specifier, 1 for the bit number, and
> > one more to differentiate clocks that use the same bit...). I'm still
> > inclined to simply push back on U-Boot to do it right.
> 
> Are SPDIF and VI the only examples of this?

I think so. I should double-check to be sure though before committing
to a final binding.

> If so, perhaps just having
> a special extra clock ID for those two and mapping in a special way
> would be more efficient. So two IDs would map to one clock/reset bit
> but different clocks.

I thought about that initially, but it doesn't make semantic sense;
there isn't a 1:1 mapping between clock ID and reset bit, so I don't
think we should pretend there is for some clocks, and special-case
others.

> Also I note that one is an input and one is an output clock. So we
> could name them this way, and use the separate ID for the input clocks
> perhaps.

I don't think that solves the problem; HW modules and drivers use both
clocks, so special-casing the input clocks doesn't make the problem
less relevant.

> If you do add an arbitrary mapping, what would it be? It might as well
> follow along with the registers so far as it can, since the device
> tree should describe the hardware. Then the mapping becomes a few
> lines of code in the driver instead of YAT (yet another table).

The mapping would be that the clock IDs are unrelated to the bit numbers
in the CAR's reset/clock-enable registers.

In practice, this means that to find the reset bit number, you need a
table indexed by the .dts's clock number, with the bit number being
retrieved from that table.

So instead of bit = of_get_u32(1), we'd have bit = table[of_get_u32(1)].

In practice, I believe we'll need such a table anyway, since each clock
has many more parameters than just the reset bit ID; some clocks have
no reset bit at all, some clocks have a mux but some don't, the inputs
to the mux are different for each clock, some have a divider but some
don't, where there's a divider or mux, you need to know the register
address to configure them, each clock has a different max rate, etc.

Having thought a little more about this, I'm definitely leaning towards
this way; making the clock ID and register bit completely unrelated just
to make it really obvious that you can't use the clock ID as a register
bit.

-- 
nvpublic

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Peter De Schrijver]

What about the peripheral resets which are also handled by CAR? Peripheral
clock nodes also offer assert and deassert methods for the reset signal
associated with them. Those methods are used when powergating domains for
example. Should we model this in the same binding?

Thanks,

Peter.

RE: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Stephen Warren]

Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:
> What about the peripheral resets which are also handled by CAR? Peripheral
> clock nodes also offer assert and deassert methods for the reset signal
> associated with them. Those methods are used when powergating domains for
> example. Should we model this in the same binding?

In most cases, I think the resets are handled purely within clock enable
and disable, so there's no need to explicitly manage them or represent
them in the device tree. Do you agree here?

I recall that you mentioned some power-management code might need to
manage reset separately though. Can you explain why a module would be
reset separately from disabling the clocks though?

If we do need this, I think we can just add a property to the node of
each device that needs such explicit management. Something like:

tegra_car: clock@60006000 {
    compatible = "nvidia,tegra20-car";
    ....
};

foo@70007000 {
    compatible = "nvidia,tegra20-foo";
    regs = <...>;
    nvidia,car-reset-id = <&tegra_car 30>;
};

And the driver for "foo" can ignore cell 0, and extract the cell 1 and
pass the value to tegra_periph_reset_assert().

I'd expect to put the CAR phandle into the property in case we ever get
a more generalized reset subsystem, and need more general code to
interpret the property. I did the same for the Tegra APB DMA controller
client binding where clients need to know the "DMA select" value.

Does that all seem reasonable?

-- 
nvpublic

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Colin Cross]

On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:
>> What about the peripheral resets which are also handled by CAR? Peripheral
>> clock nodes also offer assert and deassert methods for the reset signal
>> associated with them. Those methods are used when powergating domains for
>> example. Should we model this in the same binding?
>
> In most cases, I think the resets are handled purely within clock enable
> and disable, so there's no need to explicitly manage them or represent
> them in the device tree. Do you agree here?

clk_enable could force a deasserted reset, but clk_disable cannot
imply asserting reset.  The clocks need to be turned off for power
management without resetting the registers.

> I recall that you mentioned some power-management code might need to
> manage reset separately though. Can you explain why a module would be
> reset separately from disabling the clocks though?

The TRM lists a very specific sequence of clocks, resets, clamps, and
power for power domain gating.  Other than that, I think the only use
for directly calling reset that ended up in the Android Tegra2 tree
was for error recovery on HW blocks that could get locked up, probably
I2C.

> If we do need this, I think we can just add a property to the node of
> each device that needs such explicit management. Something like:
>
> tegra_car: clock@60006000 {
>    compatible = "nvidia,tegra20-car";
>    ....
> };
>
> foo@70007000 {
>    compatible = "nvidia,tegra20-foo";
>    regs = <...>;
>    nvidia,car-reset-id = <&tegra_car 30>;
> };
>
> And the driver for "foo" can ignore cell 0, and extract the cell 1 and
> pass the value to tegra_periph_reset_assert().
>
> I'd expect to put the CAR phandle into the property in case we ever get
> a more generalized reset subsystem, and need more general code to
> interpret the property. I did the same for the Tegra APB DMA controller
> client binding where clients need to know the "DMA select" value.
>
> Does that all seem reasonable?
>
> --
> nvpublic
>

RE: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Stephen Warren]

Colin Cross wrote at Tuesday, January 24, 2012 3:33 PM:
> On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:
> >> What about the peripheral resets which are also handled by CAR? Peripheral
> >> clock nodes also offer assert and deassert methods for the reset signal
> >> associated with them. Those methods are used when powergating domains for
> >> example. Should we model this in the same binding?
> >
> > In most cases, I think the resets are handled purely within clock enable
> > and disable, so there's no need to explicitly manage them or represent
> > them in the device tree. Do you agree here?
> 
> clk_enable could force a deasserted reset, but clk_disable cannot
> imply asserting reset.  The clocks need to be turned off for power
> management without resetting the registers.

Yes, I just spoke to someone off-list, and he said the same thing. He
went on to say that therefore even the reset removal with clk_enable
was questionable, and that drivers should explicitly manage reset
removal themselves. Does that seem a reasonable stance? It'd certainly
take away the somewhat asymmetric nature of reset removal just magically
working when you first enable the clocks. We'd presumably then want a
common reset infra-structure and binding to match that change?

(I know that'd make Simon happy, since then we'd be able to represent
the reset IDs directly everywhere, unrelated to the clock IDs, and
hence he could just use the reset IDs directly in the U-Boot code he's
writing and ignore the non 1:1 mapping between clock and reset IDs)

> > I recall that you mentioned some power-management code might need to
> > manage reset separately though. Can you explain why a module would be
> > reset separately from disabling the clocks though?
> 
> The TRM lists a very specific sequence of clocks, resets, clamps, and
> power for power domain gating.  Other than that, I think the only use
> for directly calling reset that ended up in the Android Tegra2 tree
> was for error recovery on HW blocks that could get locked up, probably
> I2C.

OK, those reasons make sense.

-- 
nvpublic

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Colin Cross]

On Tue, Jan 24, 2012 at 2:43 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Colin Cross wrote at Tuesday, January 24, 2012 3:33 PM:
>> On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> > Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:
>> >> What about the peripheral resets which are also handled by CAR? Peripheral
>> >> clock nodes also offer assert and deassert methods for the reset signal
>> >> associated with them. Those methods are used when powergating domains for
>> >> example. Should we model this in the same binding?
>> >
>> > In most cases, I think the resets are handled purely within clock enable
>> > and disable, so there's no need to explicitly manage them or represent
>> > them in the device tree. Do you agree here?
>>
>> clk_enable could force a deasserted reset, but clk_disable cannot
>> imply asserting reset.  The clocks need to be turned off for power
>> management without resetting the registers.
>
> Yes, I just spoke to someone off-list, and he said the same thing. He
> went on to say that therefore even the reset removal with clk_enable
> was questionable, and that drivers should explicitly manage reset
> removal themselves. Does that seem a reasonable stance? It'd certainly
> take away the somewhat asymmetric nature of reset removal just magically
> working when you first enable the clocks. We'd presumably then want a
> common reset infra-structure and binding to match that change?

In 99% of drivers reset is irrelevant, as long as the block is out of
reset by the time the driver starts writing to registers.  clk_enable
is a decent place to ensure that - it always has to be done before
writing to the registers, and it maps nicely to the reset bits on
Tegra.  It would be nice if those driver didn't need to deassert reset
explicitly, especially if that requires a Tegra-specific API.

> (I know that'd make Simon happy, since then we'd be able to represent
> the reset IDs directly everywhere, unrelated to the clock IDs, and
> hence he could just use the reset IDs directly in the U-Boot code he's
> writing and ignore the non 1:1 mapping between clock and reset IDs)
>
>> > I recall that you mentioned some power-management code might need to
>> > manage reset separately though. Can you explain why a module would be
>> > reset separately from disabling the clocks though?
>>
>> The TRM lists a very specific sequence of clocks, resets, clamps, and
>> power for power domain gating.  Other than that, I think the only use
>> for directly calling reset that ended up in the Android Tegra2 tree
>> was for error recovery on HW blocks that could get locked up, probably
>> I2C.
>
> OK, those reasons make sense.
>
> --
> nvpublic
>

Re: [PATCH] ARM: tegra: Define Tegra20 CAR binding

[Peter De Schrijver]

On Tue, Jan 24, 2012 at 11:59:40PM +0100, Colin Cross wrote:
> On Tue, Jan 24, 2012 at 2:43 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > Colin Cross wrote at Tuesday, January 24, 2012 3:33 PM:
> >> On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren <swarren-DDmLM1+adcphl2p70BpVqQ@public.gmane.orgm> wrote:
> >> > Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:
> >> >> What about the peripheral resets which are also handled by CAR? Peripheral
> >> >> clock nodes also offer assert and deassert methods for the reset signal
> >> >> associated with them. Those methods are used when powergating domains for
> >> >> example. Should we model this in the same binding?
> >> >
> >> > In most cases, I think the resets are handled purely within clock enable
> >> > and disable, so there's no need to explicitly manage them or represent
> >> > them in the device tree. Do you agree here?
> >>
> >> clk_enable could force a deasserted reset, but clk_disable cannot
> >> imply asserting reset.  The clocks need to be turned off for power
> >> management without resetting the registers.
> >
> > Yes, I just spoke to someone off-list, and he said the same thing. He
> > went on to say that therefore even the reset removal with clk_enable
> > was questionable, and that drivers should explicitly manage reset
> > removal themselves. Does that seem a reasonable stance? It'd certainly
> > take away the somewhat asymmetric nature of reset removal just magically
> > working when you first enable the clocks. We'd presumably then want a
> > common reset infra-structure and binding to match that change?
> 
> In 99% of drivers reset is irrelevant, as long as the block is out of
> reset by the time the driver starts writing to registers.  clk_enable
> is a decent place to ensure that - it always has to be done before
> writing to the registers, and it maps nicely to the reset bits on
> Tegra.  It would be nice if those driver didn't need to deassert reset
> explicitly, especially if that requires a Tegra-specific API.

I think this could be solved by moving the drivers to runtime PM and handle the
clock and reset bits in tegra platform device specific code. iirc that's the
way it's handled in OMAP?

Cheers,

Peter. 

[PATCH v4 12/20] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Simon Glass]

This adds clock references to the USB part of the device tree for U-Boot.

The USB timing information may vary between boards sometimes, but for
now we hard-code it in C. This is because all current T2x boards use
the same values, we will deal with T3x later and we first need to agree
on the format for this timing information in the fdt and may in fact
decide that it has no place there.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 arch/arm/dts/tegra20.dtsi |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 68eae12..ca7b523 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -176,6 +176,7 @@
 		reg = <0xc5000000 0x4000>;
 		interrupts = < 52 >;
 		phy_type = "utmi";
+		clocks = <&periph_clk 22>;	// PERIPH_ID_USBD
 	};
 
 	usb@c5004000 {
@@ -183,6 +184,7 @@
 		reg = <0xc5004000 0x4000>;
 		interrupts = < 53 >;
 		phy_type = "ulpi";
+		clocks = <&periph_clk 58>;	// PERIPH_ID_USB2
 	};
 
 	usb@c5008000 {
@@ -190,6 +192,7 @@
 		reg = <0xc5008000 0x4000>;
 		interrupts = < 129 >;
 		phy_type = "utmi";
+		clocks = <&periph_clk 59>;	// PERIPH_ID_USB3
 	};
 
 };
-- 
1.7.7.3

Re: [PATCH v4 12/20] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Stephen Warren]

On 01/11/2012 09:33 PM, Simon Glass wrote:
> This adds clock references to the USB part of the device tree for U-Boot.
> 
> The USB timing information may vary between boards sometimes, but for
> now we hard-code it in C. This is because all current T2x boards use
> the same values, we will deal with T3x later and we first need to agree
> on the format for this timing information in the fdt and may in fact
> decide that it has no place there.

> diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi

> +		clocks = <&periph_clk 22>;	// PERIPH_ID_USBD

Typically /* */ rather than // I think

-- 
nvpublic

Re: [PATCH v4 12/20] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Simon Glass]

Hi Stephen,

On Wed, Jan 18, 2012 at 4:19 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 01/11/2012 09:33 PM, Simon Glass wrote:
>> This adds clock references to the USB part of the device tree for U-Boot.
>>
>> The USB timing information may vary between boards sometimes, but for
>> now we hard-code it in C. This is because all current T2x boards use
>> the same values, we will deal with T3x later and we first need to agree
>> on the format for this timing information in the fdt and may in fact
>> decide that it has no place there.
>
>> diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
>
>> +             clocks = <&periph_clk 22>;      // PERIPH_ID_USBD
>
> Typically /* */ rather than // I think

Yes will fix. Looking forward to your symbolic stuff so that I can
remove the comment.

Regards,
Simon

>
> --
> nvpublic

[PATCH v4 13/20] tegra: usb: fdt: Add USB definitions for Tegra2 Seaboard

[Simon Glass]

We set up two USB ports, one of which can be host or device.
For some reason the kernel version does enable both ports.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v2:
- Use "okay" instead of "ok" for fdt node status
- Remove 0x from fdt aliases

Changes in v3:
- Remove "okay" from nodes since this is the default anyway
- Fix device tree indenting with tabs instead of spaces
- Disable USB2 which is not used on Seaboard

 board/nvidia/dts/tegra2-seaboard.dts |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/board/nvidia/dts/tegra2-seaboard.dts b/board/nvidia/dts/tegra2-seaboard.dts
index dde5d03..7a4ecae 100644
--- a/board/nvidia/dts/tegra2-seaboard.dts
+++ b/board/nvidia/dts/tegra2-seaboard.dts
@@ -11,6 +11,12 @@
 		bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/mmcblk1p3 rw rootwait";
 	};
 
+	aliases {
+		/* This defines the order of our USB ports */
+		usb0 = "/usb@c5008000";
+		usb1 = "/usb@c5000000";
+	};
+
 	memory {
 		device_type = "memory";
 		reg = < 0x00000000 0x40000000 >;
@@ -32,5 +38,10 @@
 
 	usb@c5000000 {
 		nvidia,vbus-gpio = <&gpio 24 0>; /* PD0 */
+		support-host-mode;
+	};
+
+	usb@c5004000 {
+		status = "disabled";
 	};
 };
-- 
1.7.7.3

[PATCH v4 15/20] fdt: Add function to return peripheral/clock ID

[Simon Glass]

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 <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v4:
- Add fdtdec function to return peripheral ID

 include/fdtdec.h |   13 +++++++++++++
 lib/fdtdec.c     |   13 +++++++++++++
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 6c0a2d1..f3115a6 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -272,3 +272,16 @@ int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
  * @return 0 if all ok or gpio was FDT_GPIO_NONE; -1 on error
  */
 int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
+
+/**
+ * Decode a peripheral ID from a device tree node. This may be a temporary
+ * function depending on what happens with clocks in the Linux fdt.
+ *
+ * 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
+ */
+int fdtdec_decode_periph_id(const void *blob, int node);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index f0b2196..780948c 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -414,3 +414,16 @@ int fdtdec_setup_gpio(struct fdt_gpio_state *gpio)
 		return -1;
 	return 0;
 }
+
+int fdtdec_decode_periph_id(const void *blob, int node)
+{
+	u32 cell[2];
+	int err;
+
+	err = fdtdec_get_int_array(blob, node, "clocks", cell,
+				   ARRAY_SIZE(cell));
+	if (err)
+		return -1;
+
+	return cell[1];
+}
-- 
1.7.7.3

[PATCH v4 20/20] tegra: fdt: Enable FDT support for Seaboard

[Simon Glass]

This switches Seaboard over to use FDT for run-time config instead of
CONFIG options. USB is the only user at present.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v3:
- Drop Tegra USB alignment patch as we will deal with this another way

 include/configs/seaboard.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h
index b6d9f7a..1dc775a 100644
--- a/include/configs/seaboard.h
+++ b/include/configs/seaboard.h
@@ -27,6 +27,11 @@
 #include <asm/sizes.h>
 #include "tegra2-common.h"
 
+/* Enable fdt support for Seaboard. Flash the image in u-boot-dtb.bin */
+#define CONFIG_DEFAULT_DEVICE_TREE	tegra2-seaboard
+#define CONFIG_OF_CONTROL
+#define CONFIG_OF_SEPARATE
+
 /* High-level configuration options */
 #define TEGRA2_SYSMEM		"mem=384M@0M nvmem=128M@384M mem=512M@512M"
 #define V_PROMPT		"Tegra2 (SeaBoard) # "
-- 
1.7.7.3

[PATCH v4 02/20] fdt: Add functions to access phandles, arrays and bools

[Simon Glass]

Add a function to look up a property which is a phandle in a node, and
another to read a fixed-length integer array from an fdt property.
Also add a function to read boolean properties, although there is no
actual boolean type in U-Boot.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 include/fdtdec.h |   39 +++++++++++++++++++++++++++++++
 lib/fdtdec.c     |   67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 106 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 01badd4..047f603 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -188,3 +188,42 @@ int fdtdec_find_aliases_for_id(const void *blob, const char *name,
  * @return compatible string for that id
  */
 const char *fdtdec_get_compatible(enum fdt_compat_id id);
+
+/* Look up a phandle and follow it to its node. Then return the offset
+ * of that node.
+ *
+ * @param blob		FDT blob
+ * @param node		node to examine
+ * @param prop_name	name of property to find
+ * @return node offset if found, -ve error code on error
+ */
+int fdtdec_lookup_phandle(const void *blob, int node, const char *prop_name);
+
+/**
+ * Look up a property in a node and return its contents in an integer
+ * array of given length. The property must have at least enough data for
+ * the array (4*count bytes). It may have more, but this will be ignored.
+ *
+ * @param blob		FDT blob
+ * @param node		node to examine
+ * @param prop_name	name of property to find
+ * @param array		array to fill with data
+ * @param count		number of array elements
+ * @return 0 if ok, or -FDT_ERR_NOTFOUND if the property is not found,
+ *		or -FDT_ERR_BADLAYOUT if not enough data
+ */
+int fdtdec_get_int_array(const void *blob, int node, const char *prop_name,
+		u32 *array, int count);
+
+/**
+ * Look up a boolean property in a node and return it.
+ *
+ * A boolean properly is true if present in the device tree and false if not
+ * present, regardless of its value.
+ *
+ * @param blob	FDT blob
+ * @param node	node to examine
+ * @param prop_name	name of property to find
+ * @return 1 if the properly is present; 0 if it isn't present
+ */
+int fdtdec_get_bool(const void *blob, int node, const char *prop_name);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 846ec3f..977528b 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -269,3 +269,70 @@ int fdtdec_check_fdt(void)
 			"binary or define CONFIG_OF_EMBED\n");
 	return 0;
 }
+
+int fdtdec_lookup_phandle(const void *blob, int node, const char *prop_name)
+{
+	const u32 *phandle;
+	int lookup;
+
+	phandle = fdt_getprop(blob, node, prop_name, NULL);
+	if (!phandle)
+		return -FDT_ERR_NOTFOUND;
+
+	lookup = fdt_node_offset_by_phandle(blob, fdt32_to_cpu(*phandle));
+	return lookup;
+}
+
+/**
+ * Look up a property in a node and check that it has a minimum length.
+ *
+ * @param blob		FDT blob
+ * @param node		node to examine
+ * @param prop_name	name of property to find
+ * @param min_len	minimum property length in bytes
+ * @param err		0 if ok, or -FDT_ERR_NOTFOUND if the property is not
+			found, or -FDT_ERR_BADLAYOUT if not enough data
+ * @return pointer to cell, which is only valid if err == 0
+ */
+static const void *get_prop_check_min_len(const void *blob, int node,
+		const char *prop_name, int min_len, int *err)
+{
+	const void *cell;
+	int len;
+
+	debug("%s: %s\n", __func__, prop_name);
+	cell = fdt_getprop(blob, node, prop_name, &len);
+	if (!cell)
+		*err = -FDT_ERR_NOTFOUND;
+	else if (len < min_len)
+		*err = -FDT_ERR_BADLAYOUT;
+	else
+		*err = 0;
+	return cell;
+}
+
+int fdtdec_get_int_array(const void *blob, int node, const char *prop_name,
+		u32 *array, int count)
+{
+	const u32 *cell;
+	int i, err = 0;
+
+	debug("%s: %s\n", __func__, prop_name);
+	cell = get_prop_check_min_len(blob, node, prop_name,
+				      sizeof(u32) * count, &err);
+	if (!err) {
+		for (i = 0; i < count; i++)
+			array[i] = fdt32_to_cpu(cell[i]);
+	}
+	return err;
+}
+
+int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
+{
+	const s32 *cell;
+	int len;
+
+	debug("%s: %s\n", __func__, prop_name);
+	cell = fdt_getprop(blob, node, prop_name, &len);
+	return cell != NULL;
+}
-- 
1.7.7.3

Re: [PATCH v4 02/20] fdt: Add functions to access phandles, arrays and bools

[Stephen Warren]

On 01/11/2012 09:32 PM, Simon Glass wrote:
> Add a function to look up a property which is a phandle in a node, and
> another to read a fixed-length integer array from an fdt property.
> Also add a function to read boolean properties, although there is no
> actual boolean type in U-Boot.
> 
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
(only because I commented on this before; I'm not an FDT maintainer here)

-- 
nvpublic

Re: [U-Boot] [PATCH v4 02/20] fdt: Add functions to access phandles, arrays and bools

[Jerry Van Baren]

On 01/11/2012 11:32 PM, Simon Glass wrote:
> Add a function to look up a property which is a phandle in a node, and
> another to read a fixed-length integer array from an fdt property.
> Also add a function to read boolean properties, although there is no
> actual boolean type in U-Boot.
> 
> Signed-off-by: Simon Glass<sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Acked-by: Gerald Van Baren <vanbaren-He//nVnquyzQT0dZR+AlfA@public.gmane.org>

Thanks,
gvb

[PATCH v4 05/20] arm: fdt: Add skeleton device tree file from kernel

[Simon Glass]

This was taken from commit b48c54e2 at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 arch/arm/dts/skeleton.dtsi |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/dts/skeleton.dtsi

diff --git a/arch/arm/dts/skeleton.dtsi b/arch/arm/dts/skeleton.dtsi
new file mode 100644
index 0000000..b41d241
--- /dev/null
+++ b/arch/arm/dts/skeleton.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree; the bare minimum needed to boot; just include and
+ * add a compatible value.  The bootloader will typically populate the memory
+ * node.
+ */
+
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	chosen { };
+	aliases { };
+	memory { device_type = "memory"; reg = <0 0>; };
+};
-- 
1.7.7.3

[PATCH v4 10/20] tegra: fdt: Add additional USB binding

[Simon Glass]

This adds a property to indicate a port which can switch between host and device
mode.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 doc/device-tree-bindings/usb/tegra-usb.txt |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/doc/device-tree-bindings/usb/tegra-usb.txt b/doc/device-tree-bindings/usb/tegra-usb.txt
index 035d63d..96fd022 100644
--- a/doc/device-tree-bindings/usb/tegra-usb.txt
+++ b/doc/device-tree-bindings/usb/tegra-usb.txt
@@ -11,3 +11,7 @@ Required properties :
  - phy_type : Should be one of "ulpi" or "utmi".
  - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
    activated for the bus to be powered.
+
+Optional properties:
+ - support-host-mode : If present then this peripheral can switch between
+   host and device mode
-- 
1.7.7.3

Re: [PATCH v4 10/20] tegra: fdt: Add additional USB binding

[Stephen Warren]

On 01/11/2012 09:32 PM, Simon Glass wrote:
> This adds a property to indicate a port which can switch between host and device
> mode.
> 
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> 
>  doc/device-tree-bindings/usb/tegra-usb.txt |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/device-tree-bindings/usb/tegra-usb.txt b/doc/device-tree-bindings/usb/tegra-usb.txt
> index 035d63d..96fd022 100644
> --- a/doc/device-tree-bindings/usb/tegra-usb.txt
> +++ b/doc/device-tree-bindings/usb/tegra-usb.txt
> @@ -11,3 +11,7 @@ Required properties :
>   - phy_type : Should be one of "ulpi" or "utmi".
>   - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
>     activated for the bus to be powered.
> +
> +Optional properties:
> + - support-host-mode : If present then this peripheral can switch between
> +   host and device mode

All of Tegra's USB ports support host mode, and it's the typical mode of
operation. The TRM also indicates that all USB ports support device mode
(possibly depending on the PHY type that's been selected for or attached
to port). Port 2 explicitly doesn't support run-time switching, but by
omission, ports 1 and 3 do.

Hence, "support-host-mode" is not an accurate name, and doesn't match
the description given either.

I think that it'd be better to:
* Add properties to explicitly specify whether the port is
intended/allowed to operate (per board design) in each of host or device
mode.
* Default to static host mode if no properties are present.

i.e.:

+Optional properties:
+ - enable-host-mode : Indicate that the port is intended to operate in
+   host mode.
+ - enable-device-mode : Indicate that the port is intended to operate
+   in device mode.

We should error out if both properties are set for USB 2, since it
doesn't support run-time switching. Perhaps you can skip this
error-checking for now since we aren't implementing device mode anywhere
anyway...

Then in the later patch in your series that was using support-host-mode,

* Do VBUS detection only if both enable-host-mode and enable-device-mode
are present.
* Do VBUS GPIO enable if enable-host-mode is present (or assumed by
default) and VBUS detection passed (if it ran).

-- 
nvpublic

Re: [PATCH v4 10/20] tegra: fdt: Add additional USB binding

[Olof Johansson]

On Wed, Jan 18, 2012 at 03:48:30PM -0700, Stephen Warren wrote:
> On 01/11/2012 09:32 PM, Simon Glass wrote:
> > This adds a property to indicate a port which can switch between host and device
> > mode.
> > 
> > Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > ---
> > 
> >  doc/device-tree-bindings/usb/tegra-usb.txt |    4 ++++
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> > 
> > diff --git a/doc/device-tree-bindings/usb/tegra-usb.txt b/doc/device-tree-bindings/usb/tegra-usb.txt
> > index 035d63d..96fd022 100644
> > --- a/doc/device-tree-bindings/usb/tegra-usb.txt
> > +++ b/doc/device-tree-bindings/usb/tegra-usb.txt
> > @@ -11,3 +11,7 @@ Required properties :
> >   - phy_type : Should be one of "ulpi" or "utmi".
> >   - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
> >     activated for the bus to be powered.
> > +
> > +Optional properties:
> > + - support-host-mode : If present then this peripheral can switch between
> > +   host and device mode
> 
> All of Tegra's USB ports support host mode, and it's the typical mode of
> operation. The TRM also indicates that all USB ports support device mode
> (possibly depending on the PHY type that's been selected for or attached
> to port). Port 2 explicitly doesn't support run-time switching, but by
> omission, ports 1 and 3 do.
> 
> Hence, "support-host-mode" is not an accurate name, and doesn't match
> the description given either.
> 
> I think that it'd be better to:
> * Add properties to explicitly specify whether the port is
> intended/allowed to operate (per board design) in each of host or device
> mode.
> * Default to static host mode if no properties are present.
> 
> i.e.:
> 
> +Optional properties:
> + - enable-host-mode : Indicate that the port is intended to operate in
> +   host mode.
> + - enable-device-mode : Indicate that the port is intended to operate
> +   in device mode.

fsl-usb.txt uses "dr_mode" here, which might make sense to reuse given some of
the shared IP in question for device mode:

 - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
   controllers.  Can be "host", "peripheral", or "otg".  Default to
   "host" if not defined for backward compatibility.


-Olof

Re: [PATCH v4 10/20] tegra: fdt: Add additional USB binding

[Simon Glass]

Hi Olof,

On Wed, Jan 18, 2012 at 9:35 PM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
> On Wed, Jan 18, 2012 at 03:48:30PM -0700, Stephen Warren wrote:
>> On 01/11/2012 09:32 PM, Simon Glass wrote:
>> > This adds a property to indicate a port which can switch between host and device
>> > mode.
>> >
>> > Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> > ---
>> >
>> >  doc/device-tree-bindings/usb/tegra-usb.txt |    4 ++++
>> >  1 files changed, 4 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/doc/device-tree-bindings/usb/tegra-usb.txt b/doc/device-tree-bindings/usb/tegra-usb.txt
>> > index 035d63d..96fd022 100644
>> > --- a/doc/device-tree-bindings/usb/tegra-usb.txt
>> > +++ b/doc/device-tree-bindings/usb/tegra-usb.txt
>> > @@ -11,3 +11,7 @@ Required properties :
>> >   - phy_type : Should be one of "ulpi" or "utmi".
>> >   - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
>> >     activated for the bus to be powered.
>> > +
>> > +Optional properties:
>> > + - support-host-mode : If present then this peripheral can switch between
>> > +   host and device mode
>>
>> All of Tegra's USB ports support host mode, and it's the typical mode of
>> operation. The TRM also indicates that all USB ports support device mode
>> (possibly depending on the PHY type that's been selected for or attached
>> to port). Port 2 explicitly doesn't support run-time switching, but by
>> omission, ports 1 and 3 do.
>>
>> Hence, "support-host-mode" is not an accurate name, and doesn't match
>> the description given either.
>>
>> I think that it'd be better to:
>> * Add properties to explicitly specify whether the port is
>> intended/allowed to operate (per board design) in each of host or device
>> mode.
>> * Default to static host mode if no properties are present.
>>
>> i.e.:
>>
>> +Optional properties:
>> + - enable-host-mode : Indicate that the port is intended to operate in
>> +   host mode.
>> + - enable-device-mode : Indicate that the port is intended to operate
>> +   in device mode.
>
> fsl-usb.txt uses "dr_mode" here, which might make sense to reuse given some of
> the shared IP in question for device mode:
>
>  - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
>   controllers.  Can be "host", "peripheral", or "otg".  Default to
>   "host" if not defined for backward compatibility.

What does 'dr' mean?

Regards,
Simon

>
>
> -Olof

Re: [PATCH v4 10/20] tegra: fdt: Add additional USB binding

[Olof Johansson]

Hi,

On Wed, Jan 18, 2012 at 9:55 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:

>> fsl-usb.txt uses "dr_mode" here, which might make sense to reuse given some of
>> the shared IP in question for device mode:
>>
>>  - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
>>   controllers.  Can be "host", "peripheral", or "otg".  Default to
>>   "host" if not defined for backward compatibility.
>
> What does 'dr' mean?

After some searching, it looks like it means "dual-role", which seems
appropriate terminology for the tegra SoC as well.


-Olof

Re: [PATCH v4 10/20] tegra: fdt: Add additional USB binding

[Simon Glass]

Hi Olof,

On Wed, Jan 18, 2012 at 10:41 PM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
> Hi,
>
> On Wed, Jan 18, 2012 at 9:55 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>
>>> fsl-usb.txt uses "dr_mode" here, which might make sense to reuse given some of
>>> the shared IP in question for device mode:
>>>
>>>  - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
>>>   controllers.  Can be "host", "peripheral", or "otg".  Default to
>>>   "host" if not defined for backward compatibility.
>>
>> What does 'dr' mean?
>
> After some searching, it looks like it means "dual-role", which seems
> appropriate terminology for the tegra SoC as well.

Thanks for looking that up.

Well maybe, but it could mean data reverse mode or distinctive
ring...I like Stephen's nice device-tree-friendly naming and
explanation :-) Are we stuck with this?

Regards,
Simon

>
>
> -Olof

Re: [PATCH v4 10/20] tegra: fdt: Add additional USB binding

[Olof Johansson]

On Wed, Jan 18, 2012 at 10:59 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> Hi Olof,
>
> On Wed, Jan 18, 2012 at 10:41 PM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>> Hi,
>>
>> On Wed, Jan 18, 2012 at 9:55 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
>>
>>>> fsl-usb.txt uses "dr_mode" here, which might make sense to reuse given some of
>>>> the shared IP in question for device mode:
>>>>
>>>>  - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
>>>>   controllers.  Can be "host", "peripheral", or "otg".  Default to
>>>>   "host" if not defined for backward compatibility.
>>>
>>> What does 'dr' mean?
>>
>> After some searching, it looks like it means "dual-role", which seems
>> appropriate terminology for the tegra SoC as well.
>
> Thanks for looking that up.
>
> Well maybe, but it could mean data reverse mode or distinctive
> ring...I like Stephen's nice device-tree-friendly naming and
> explanation :-) Are we stuck with this?

I think there's value in staying common with similar bindings on other
platforms, yes. Sorry. :)


-Olof

RE: [PATCH v4 10/20] tegra: fdt: Add additional USB binding

[Stephen Warren]

Olof Johansson wrote at Thursday, January 19, 2012 12:13 AM:
> On Wed, Jan 18, 2012 at 10:59 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> > Hi Olof,
> >
> > On Wed, Jan 18, 2012 at 10:41 PM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
> >> Hi,
> >>
> >> On Wed, Jan 18, 2012 at 9:55 PM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> >>
> >>>> fsl-usb.txt uses "dr_mode" here, which might make sense to reuse given some of
> >>>> the shared IP in question for device mode:
> >>>>
> >>>>  - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
> >>>>   controllers.  Can be "host", "peripheral", or "otg".  Default to
> >>>>   "host" if not defined for backward compatibility.
> >>>
> >>> What does 'dr' mean?
> >>
> >> After some searching, it looks like it means "dual-role", which seems
> >> appropriate terminology for the tegra SoC as well.
> >
> > Thanks for looking that up.
> >
> > Well maybe, but it could mean data reverse mode or distinctive
> > ring...I like Stephen's nice device-tree-friendly naming and
> > explanation :-) Are we stuck with this?
> 
> I think there's value in staying common with similar bindings on other
> platforms, yes. Sorry. :)

Ack from me too. If there's an existing convention, I'd prefer to stick
with it. Sorry, I should have looked this up before coming up with
something new.

-- 
nvpublic

Re: [PATCH v4 10/20] tegra: fdt: Add additional USB binding

[Simon Glass]

Hi,

On Thu, Jan 19, 2012 at 9:33 AM, Stephen Warren <swarren@nvidia.com> wrote:
> Olof Johansson wrote at Thursday, January 19, 2012 12:13 AM:
>> On Wed, Jan 18, 2012 at 10:59 PM, Simon Glass <sjg@chromium.org> wrote:
>> > Hi Olof,
>> >
>> > On Wed, Jan 18, 2012 at 10:41 PM, Olof Johansson <olof@lixom.net> wrote:
>> >> Hi,
>> >>
>> >> On Wed, Jan 18, 2012 at 9:55 PM, Simon Glass <sjg@chromium.org> wrote:
>> >>
>> >>>> fsl-usb.txt uses "dr_mode" here, which might make sense to reuse given some of
>> >>>> the shared IP in question for device mode:
>> >>>>
>> >>>>  - dr_mode : indicates the working mode for "fsl-usb2-dr" compatible
>> >>>>   controllers.  Can be "host", "peripheral", or "otg".  Default to
>> >>>>   "host" if not defined for backward compatibility.
>> >>>
>> >>> What does 'dr' mean?
>> >>
>> >> After some searching, it looks like it means "dual-role", which seems
>> >> appropriate terminology for the tegra SoC as well.
>> >
>> > Thanks for looking that up.
>> >
>> > Well maybe, but it could mean data reverse mode or distinctive
>> > ring...I like Stephen's nice device-tree-friendly naming and
>> > explanation :-) Are we stuck with this?
>>
>> I think there's value in staying common with similar bindings on other
>> platforms, yes. Sorry. :)
>
> Ack from me too. If there's an existing convention, I'd prefer to stick
> with it. Sorry, I should have looked this up before coming up with
> something new.

OK thanks for that. Will take a look.

Regards,
Simon

>
> --
> nvpublic
>