[PATCH v2 01/17] fdt: Tidy up a few fdtdec problems

[PATCH v2 01/17] 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@chromium.org>
---
Changes in v2:
- Use "okay" rather than "ok" in fdt to signify an enabled node
- Add header prototype for fdtdec_next_compatible()
- Change fdtdec_next_alias() to increment 'upto' only on success

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

diff --git a/include/fdtdec.h b/include/fdtdec.h
index d871cdd..49dbac4 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 0f87163..a0a34e4 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>"),
 };
 
 /**
@@ -84,14 +85,14 @@ 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;
 
 	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)
@@ -122,14 +123,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;
 }
 
 /*
@@ -140,7 +143,7 @@ int fdtdec_next_alias(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.3.1

Re: [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems

[Stephen Warren]

On 12/02/2011 07:11 PM, Simon Glass wrote:
...
> +int fdtdec_get_is_enabled(const void *blob, int node)
>  {
>  	const char *cell;
>  
>  	cell = fdt_getprop(blob, node, "status", NULL);
>  	if (cell)
> -		return 0 == strcmp(cell, "ok");
> -	return default_val;
> +		return 0 == strcmp(cell, "okay");
> +	return 1;
>  }

The kernel accepts both okay (standard) and ok (non-standard). I assume
the latter is required for some in-use-but-technically-incorrect .dts
files. I imagine U-Boot should act like the kernel here.

(Sorry if I wasn't clear here before; that's certainly what I intended
to mean)

-- 
nvpublic

Re: [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems

[Simon Glass]

Hi Stephen,

On Mon, Dec 5, 2011 at 1:27 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 12/02/2011 07:11 PM, Simon Glass wrote:
> ...
>> +int fdtdec_get_is_enabled(const void *blob, int node)
>>  {
>>       const char *cell;
>>
>>       cell = fdt_getprop(blob, node, "status", NULL);
>>       if (cell)
>> -             return 0 == strcmp(cell, "ok");
>> -     return default_val;
>> +             return 0 == strcmp(cell, "okay");
>> +     return 1;
>>  }
>
> The kernel accepts both okay (standard) and ok (non-standard). I assume
> the latter is required for some in-use-but-technically-incorrect .dts
> files. I imagine U-Boot should act like the kernel here.

Given that we are just starting out with fdt, do you think it would be
better to not bloat the code in this way? I don't mind either way -
just asking :-)

Regards,
Simon

>
> (Sorry if I wasn't clear here before; that's certainly what I intended
> to mean)
>
> --
> nvpublic

Re: [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems

[Stephen Warren]

On 12/05/2011 02:40 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Mon, Dec 5, 2011 at 1:27 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>> ...
>>> +int fdtdec_get_is_enabled(const void *blob, int node)
>>>  {
>>>       const char *cell;
>>>
>>>       cell = fdt_getprop(blob, node, "status", NULL);
>>>       if (cell)
>>> -             return 0 == strcmp(cell, "ok");
>>> -     return default_val;
>>> +             return 0 == strcmp(cell, "okay");
>>> +     return 1;
>>>  }
>>
>> The kernel accepts both okay (standard) and ok (non-standard). I assume
>> the latter is required for some in-use-but-technically-incorrect .dts
>> files. I imagine U-Boot should act like the kernel here.
> 
> Given that we are just starting out with fdt, do you think it would be
> better to not bloat the code in this way? I don't mind either way -
> just asking :-)

My point is that there are probably .dts files using "ok" instead of
"okay" or the kernel wouldn't support "ok". People will probably want to
use those with U-Boot without changing anything else. So, U-Boot should
interpret the FDT in the same way as the kernel.

-- 
nvpublic

Re: [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems

[Simon Glass]

Hi Stephen,

On Mon, Dec 5, 2011 at 2:07 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> On 12/05/2011 02:40 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Mon, Dec 5, 2011 at 1:27 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>>> ...
>>>> +int fdtdec_get_is_enabled(const void *blob, int node)
>>>>  {
>>>>       const char *cell;
>>>>
>>>>       cell = fdt_getprop(blob, node, "status", NULL);
>>>>       if (cell)
>>>> -             return 0 == strcmp(cell, "ok");
>>>> -     return default_val;
>>>> +             return 0 == strcmp(cell, "okay");
>>>> +     return 1;
>>>>  }
>>>
>>> The kernel accepts both okay (standard) and ok (non-standard). I assume
>>> the latter is required for some in-use-but-technically-incorrect .dts
>>> files. I imagine U-Boot should act like the kernel here.
>>
>> Given that we are just starting out with fdt, do you think it would be
>> better to not bloat the code in this way? I don't mind either way -
>> just asking :-)
>
> My point is that there are probably .dts files using "ok" instead of
> "okay" or the kernel wouldn't support "ok". People will probably want to
> use those with U-Boot without changing anything else. So, U-Boot should
> interpret the FDT in the same way as the kernel.

OK, how about:
		return 0 == strncmp(cell, "ok", 2);

(I do feel that if you do this sort of thing you end up with people
using 'ok' even in new fdts, since they look at code like this and
think it is fine)

Regards,
Simon

>
> --
> nvpublic

Re: [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems

[Scott Wood]

On 12/05/2011 04:11 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Mon, Dec 5, 2011 at 2:07 PM, Stephen Warren <swarren@nvidia.com> wrote:
>> My point is that there are probably .dts files using "ok" instead of
>> "okay" or the kernel wouldn't support "ok". People will probably want to
>> use those with U-Boot without changing anything else. So, U-Boot should
>> interpret the FDT in the same way as the kernel.

The kernel has to deal with real Open Firmware systems, some of which
pass buggy trees.  U-Boot should not blindly imitate all of Linux's
workarounds.

> OK, how about:
> 		return 0 == strncmp(cell, "ok", 2);
> 
> (I do feel that if you do this sort of thing you end up with people
> using 'ok' even in new fdts, since they look at code like this and
> think it is fine)

Indeed.

-Scott

Re: [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems

[Stephen Warren]

On 12/05/2011 03:18 PM, Scott Wood wrote:
> On 12/05/2011 04:11 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Mon, Dec 5, 2011 at 2:07 PM, Stephen Warren <swarren@nvidia.com> wrote:
>>> My point is that there are probably .dts files using "ok" instead of
>>> "okay" or the kernel wouldn't support "ok". People will probably want to
>>> use those with U-Boot without changing anything else. So, U-Boot should
>>> interpret the FDT in the same way as the kernel.
> 
> The kernel has to deal with real Open Firmware systems, some of which
> pass buggy trees.  U-Boot should not blindly imitate all of Linux's
> workarounds.

If it's certain that we'll never see anyone writing FDTs with "ok" in
them instead of "okay" (because such FDTs were only autogenerated by
Open Firmware), then I'm fine with the original code.

>> OK, how about:
>> 		return 0 == strncmp(cell, "ok", 2);
>>
>> (I do feel that if you do this sort of thing you end up with people
>> using 'ok' even in new fdts, since they look at code like this and
>> think it is fine)

That'd be buggy since it'd allow a lot more than ok/okay. A comment in
the code would avoid the issue.

-- 
nvpublic

Re: [PATCH v2 01/17] fdt: Tidy up a few fdtdec problems

[Simon Glass]

Hi Stephen,

On Mon, Dec 5, 2011 at 2:25 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 12/05/2011 03:18 PM, Scott Wood wrote:
>> On 12/05/2011 04:11 PM, Simon Glass wrote:
>>> Hi Stephen,
>>>
>>> On Mon, Dec 5, 2011 at 2:07 PM, Stephen Warren <swarren@nvidia.com> wrote:
>>>> My point is that there are probably .dts files using "ok" instead of
>>>> "okay" or the kernel wouldn't support "ok". People will probably want to
>>>> use those with U-Boot without changing anything else. So, U-Boot should
>>>> interpret the FDT in the same way as the kernel.
>>
>> The kernel has to deal with real Open Firmware systems, some of which
>> pass buggy trees.  U-Boot should not blindly imitate all of Linux's
>> workarounds.
>
> If it's certain that we'll never see anyone writing FDTs with "ok" in
> them instead of "okay" (because such FDTs were only autogenerated by
> Open Firmware), then I'm fine with the original code.
>
>>> OK, how about:
>>>              return 0 == strncmp(cell, "ok", 2);
>>>
>>> (I do feel that if you do this sort of thing you end up with people
>>> using 'ok' even in new fdts, since they look at code like this and
>>> think it is fine)
>
> That'd be buggy since it'd allow a lot more than ok/okay. A comment in
> the code would avoid the issue.

Hmm, ok I will revert to "okay" and add a comment.

Regards,
Simon

>
> --
> nvpublic

[PATCH v2 06/17] 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.3.1

[PATCH v2 02/17] 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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v2:
- Rename get_prop_len() to get_prop_check_min_len()

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

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 49dbac4..974520a 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -141,3 +141,43 @@ int fdtdec_get_is_enabled(const void *blob, int node);
  * if not.
  */
 int fdtdec_check_fdt(void);
+
+/**
+ * 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, or present with a 0 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 or is 0
+ */
+int fdtdec_get_bool(const void *blob, int node, const char *prop_name);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index a0a34e4..8f972b7 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -148,3 +148,86 @@ 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;
+}
+
+/**
+ * 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, or present with a 0 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 or is 0
+ */
+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);
+	if (!cell)
+		return 0;
+	if (len >= sizeof(u32) && *cell == 0)
+		return 0;
+
+	return 1;
+}
-- 
1.7.3.1

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

[Stephen Warren]

On 12/02/2011 07:11 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.

> +/**
> + * 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, or present with a 0 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 or is 0
> + */
> +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);
> +	if (!cell)
> +		return 0;
> +	if (len >= sizeof(u32) && *cell == 0)
> +		return 0;
> +
> +	return 1;
> +}

I'm still slightly worried that this implementation may interpret the
FDT differently to the kernel. At least the code I've written for
boolean properties /only/ looks at the presence of the property, and
never at the contents even if there is one.

That said, the ePAPR specification does only say that boolean properties
/might/ have an empty value, thus implying that a non-zero length is
permissible. so, perhaps this is fine.

Actually no, I'm more than worried now I think it through. You'd argued
for being able to write 0/1 to the property so that U-Boot could modify
the value in-place without having to add/remove nodes to/from the FDT
image, but rather just change their content. However, if this modified
FDT is then passed to the kernel (rather than some other fresh FDT),
then it's imperative that U-Boot and the kernel represent boolean
properties in the exact same way. Hence, we either can't have U-Boot use
this edit-in-place optimization, or U-Boot needs some "cleanup" of the
FDT image before passing it to the kernel. However, the latter is
impossible, since by then since the boot-the-kernel code has no idea
whether a property is a boolean or not, and hence implementing such a
cleanup is impossible.

-- 
nvpublic

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

[Simon Glass]

Hi Stephen,

On Mon, Dec 5, 2011 at 1:59 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> On 12/02/2011 07:11 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.
>
>> +/**
>> + * 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, or present with a 0 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 or is 0
>> + */
>> +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);
>> +     if (!cell)
>> +             return 0;
>> +     if (len >= sizeof(u32) && *cell == 0)
>> +             return 0;
>> +
>> +     return 1;
>> +}
>
> I'm still slightly worried that this implementation may interpret the
> FDT differently to the kernel. At least the code I've written for
> boolean properties /only/ looks at the presence of the property, and
> never at the contents even if there is one.
>
> That said, the ePAPR specification does only say that boolean properties
> /might/ have an empty value, thus implying that a non-zero length is
> permissible. so, perhaps this is fine.

OK

>
> Actually no, I'm more than worried now I think it through. You'd argued
> for being able to write 0/1 to the property so that U-Boot could modify
> the value in-place without having to add/remove nodes to/from the FDT
> image, but rather just change their content. However, if this modified
> FDT is then passed to the kernel (rather than some other fresh FDT),
> then it's imperative that U-Boot and the kernel represent boolean
> properties in the exact same way. Hence, we either can't have U-Boot use
> this edit-in-place optimization, or U-Boot needs some "cleanup" of the
> FDT image before passing it to the kernel. However, the latter is
> impossible, since by then since the boot-the-kernel code has no idea
> whether a property is a boolean or not, and hence implementing such a
> cleanup is impossible.

Hang on - this fdt cannot be passed to the kernel! It is for U-Boot's
use, for it's own configuration. There is no mechanism to fix up
U-Boot's internal fdt and pass it to the kernel. U-Boot scripts can't
even find its address!

That side of U-Boot is a complete different use of fdt and I have been
careful (so far) to keep them apart.

Regards,
Simon

>
> --
> nvpublic

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

[Stephen Warren]

On 12/05/2011 03:07 PM, Simon Glass wrote:
> On Mon, Dec 5, 2011 at 1:59 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>>> +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);
>>> +     if (!cell)
>>> +             return 0;
>>> +     if (len >= sizeof(u32) && *cell == 0)
>>> +             return 0;
>>> +
>>> +     return 1;
>>> +}
>>
>> I'm still slightly worried that this implementation may interpret the
>> FDT differently to the kernel. At least the code I've written for
>> boolean properties /only/ looks at the presence of the property, and
>> never at the contents even if there is one.
>>
>> That said, the ePAPR specification does only say that boolean properties
>> /might/ have an empty value, thus implying that a non-zero length is
>> permissible. so, perhaps this is fine.
> 
> OK
> 
>>
>> Actually no, I'm more than worried now I think it through. You'd argued
>> for being able to write 0/1 to the property so that U-Boot could modify
>> the value in-place without having to add/remove nodes to/from the FDT
>> image, but rather just change their content. However, if this modified
>> FDT is then passed to the kernel (rather than some other fresh FDT),
>> then it's imperative that U-Boot and the kernel represent boolean
>> properties in the exact same way. Hence, we either can't have U-Boot use
>> this edit-in-place optimization, or U-Boot needs some "cleanup" of the
>> FDT image before passing it to the kernel. However, the latter is
>> impossible, since by then since the boot-the-kernel code has no idea
>> whether a property is a boolean or not, and hence implementing such a
>> cleanup is impossible.
> 
> Hang on - this fdt cannot be passed to the kernel! It is for U-Boot's
> use, for it's own configuration. There is no mechanism to fix up
> U-Boot's internal fdt and pass it to the kernel. U-Boot scripts can't
> even find its address!
> 
> That side of U-Boot is a complete different use of fdt and I have been
> careful (so far) to keep them apart.

Yes, that's certainly the way it is right now.

I'd heard some discussion on changing that, and allowing U-Boot to pass
its internal configuration FDT to the kernel instead of loading it from
disk a second time. However, it looks like that discussion was purely
internal to NVIDIA and might have been motivated by some confusion
rather than actual intent.

As such, my comments about fixing stuff up to pass to the kernel don't
apply.

Still, I think we should be able pass the same FDT to U-Boot and the
kernel, and as such they should both interpret boolean properties in the
same way. This patch doesn't do that.

-- 
nvpublic

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

[Simon Glass]

Hi Stephen,

On Mon, Dec 5, 2011 at 2:36 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 12/05/2011 03:07 PM, Simon Glass wrote:
>> On Mon, Dec 5, 2011 at 1:59 PM, Stephen Warren <swarren@nvidia.com> wrote:
>>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>>>> +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);
>>>> +     if (!cell)
>>>> +             return 0;
>>>> +     if (len >= sizeof(u32) && *cell == 0)
>>>> +             return 0;
>>>> +
>>>> +     return 1;
>>>> +}
>>>
>>> I'm still slightly worried that this implementation may interpret the
>>> FDT differently to the kernel. At least the code I've written for
>>> boolean properties /only/ looks at the presence of the property, and
>>> never at the contents even if there is one.
>>>
>>> That said, the ePAPR specification does only say that boolean properties
>>> /might/ have an empty value, thus implying that a non-zero length is
>>> permissible. so, perhaps this is fine.
>>
>> OK
>>
>>>
>>> Actually no, I'm more than worried now I think it through. You'd argued
>>> for being able to write 0/1 to the property so that U-Boot could modify
>>> the value in-place without having to add/remove nodes to/from the FDT
>>> image, but rather just change their content. However, if this modified
>>> FDT is then passed to the kernel (rather than some other fresh FDT),
>>> then it's imperative that U-Boot and the kernel represent boolean
>>> properties in the exact same way. Hence, we either can't have U-Boot use
>>> this edit-in-place optimization, or U-Boot needs some "cleanup" of the
>>> FDT image before passing it to the kernel. However, the latter is
>>> impossible, since by then since the boot-the-kernel code has no idea
>>> whether a property is a boolean or not, and hence implementing such a
>>> cleanup is impossible.
>>
>> Hang on - this fdt cannot be passed to the kernel! It is for U-Boot's
>> use, for it's own configuration. There is no mechanism to fix up
>> U-Boot's internal fdt and pass it to the kernel. U-Boot scripts can't
>> even find its address!
>>
>> That side of U-Boot is a complete different use of fdt and I have been
>> careful (so far) to keep them apart.
>
> Yes, that's certainly the way it is right now.
>
> I'd heard some discussion on changing that, and allowing U-Boot to pass
> its internal configuration FDT to the kernel instead of loading it from
> disk a second time. However, it looks like that discussion was purely
> internal to NVIDIA and might have been motivated by some confusion
> rather than actual intent.
>
> As such, my comments about fixing stuff up to pass to the kernel don't
> apply.

OK

>
> Still, I think we should be able pass the same FDT to U-Boot and the
> kernel, and as such they should both interpret boolean properties in the
> same way. This patch doesn't do that.

OK, I will change it, and start a separate thread on
devicetree-discuss about fdtget/put.

Regards,
Simon

>
> --
> nvpublic

[PATCH v2 04/17] 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 some flags, proposed as follows:

   bit    meaning
   0      0=input, 1=output
   1      for output only: inital value of output
   2      0=polarity normal, 1=active low (inverted)

An example is:

enable-propounder = <&gpio 43 1>;

which means that GPIO 43 is an output and we can enable the propounder by
setting gpio 43 high.

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 and
gpio_direction_input/output() 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 |   49 ++++++++++++++++++++++++++++++++
 lib/fdtdec.c     |   83 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 132 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 974520a..57db42b 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -61,6 +61,26 @@ enum fdt_compat_id {
 	COMPAT_COUNT,
 };
 
+/* For now we allow 224 GPIOs. We can extend this later if required */
+enum {
+	FDT_GPIO_NONE = 255,	/* an invalid GPIO used to end our list */
+	FDT_GPIO_MAX  = 224,	/* maximum valid GPIO number */
+
+	FDT_GPIO_OUTPUT	= 1 << 0,	/* set as output (else input) */
+	FDT_GPIO_HIGH	= 1 << 1,	/* set output as high (else low) */
+	FDT_GPIO_ACTIVE_LOW = 1 << 2,	/* 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 */
+	u8 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.
@@ -181,3 +201,32 @@ 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 or is 0
  */
 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. This sets it
+ * to either input or output. If an output, then the defined value is
+ * assigned.
+ *
+ * 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 8f972b7..8eed752 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;
 
 /*
@@ -231,3 +234,83 @@ int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
 
 	return 1;
 }
+
+/**
+ * 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;
+	if (gpio->flags & FDT_GPIO_OUTPUT) {
+		return gpio_direction_output(gpio->gpio,
+					     gpio->flags & FDT_GPIO_HIGH);
+	} else {
+		return gpio_direction_input(gpio->gpio);
+	}
+}
-- 
1.7.3.1

Re: [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions

[Stephen Warren]

On 12/02/2011 07:11 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>;
> 
> where:
> 
> phandle is a pointer to the GPIO node
> gpio_num is the number of the GPIO (0 to 223)
> flags is some flags, proposed as follows:
> 
>    bit    meaning
>    0      0=input, 1=output
>    1      for output only: inital value of output
>    2      0=polarity normal, 1=active low (inverted)

The meaning of the flags (and even whether there are any flags any if so
how many cells there are to contain them) is defined by the GPIO
controller's binding. It's not something that can be interpreted in
isolation by a generic DT parsing function. See for example #gpio-cells
in tegra20.dtsi's gpio node and kernel file
Documentation/devicetree/bindings/gpio/gpio_nvidia.txt.

This implies that a lot of the code isn't correct, but I haven't
explicitly mentioned this everywhere for brevity.

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

I /think/ convention is to name such properties foo-gpios rather than
just foo. Still, this is only a comment on the example and not the code,
since the complete property name is passed into the new functions by the
caller.

> +/* For now we allow 224 GPIOs. We can extend this later if required */
> +enum {
> +	FDT_GPIO_NONE = 255,	/* an invalid GPIO used to end our list */

Can't you use 0 for that? (the kernel currently uses -1, but it seems
there's agreement that was a mistake). If you use 255, the number will
have to keep getting bumped as more complex systems become supported. If
not 0, perhaps U32_MAX or whatever the relevant ${type}_MAX is?

-- 
nvpublic

Re: [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions

[Simon Glass]

Hi Stephen,

On Mon, Dec 5, 2011 at 1:46 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 12/02/2011 07:11 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>;
>>
>> where:
>>
>> phandle is a pointer to the GPIO node
>> gpio_num is the number of the GPIO (0 to 223)
>> flags is some flags, proposed as follows:
>>
>>    bit    meaning
>>    0      0=input, 1=output
>>    1      for output only: inital value of output
>>    2      0=polarity normal, 1=active low (inverted)
>
> The meaning of the flags (and even whether there are any flags any if so
> how many cells there are to contain them) is defined by the GPIO
> controller's binding. It's not something that can be interpreted in
> isolation by a generic DT parsing function. See for example #gpio-cells
> in tegra20.dtsi's gpio node and kernel file
> Documentation/devicetree/bindings/gpio/gpio_nvidia.txt.

I see this in my version:

Required properties:
- compatible : "nvidia,tegra20-gpio"
- #gpio-cells : Should be two. The first cell is the pin number and the
  second cell is used to specify optional parameters:
  - bit 0 specifies polarity (0 for normal, 1 for inverted)
- gpio-controller : Marks the device node as a GPIO controller.

so how do I go about adding the other two bits?

>
> This implies that a lot of the code isn't correct, but I haven't
> explicitly mentioned this everywhere for brevity.

Well it's ok - these flags are only used in one place, and only the
input/output flag in fact.

It would be nice to use constants for these in the fdt instead of
numbers. Is that in progress?

enable-propounder = <&gpio 43 OUTPUT>;

>
>> An example is:
>>
>> enable-propounder = <&gpio 43 1>;
>
> I /think/ convention is to name such properties foo-gpios rather than
> just foo. Still, this is only a comment on the example and not the code,
> since the complete property name is passed into the new functions by the
> caller.

ok, will update.

>
>> +/* For now we allow 224 GPIOs. We can extend this later if required */
>> +enum {
>> +     FDT_GPIO_NONE = 255,    /* an invalid GPIO used to end our list */
>
> Can't you use 0 for that? (the kernel currently uses -1, but it seems
> there's agreement that was a mistake). If you use 255, the number will
> have to keep getting bumped as more complex systems become supported. If
> not 0, perhaps U32_MAX or whatever the relevant ${type}_MAX is?

But 0 is a valid GPIO isn't it?

I currently use the max value available to the u8. We can change it at
will when we update the u8 type to u16 which is why I made it a
constant.

Thanks for all your help with this.

Regards,
Simon

>
> --
> nvpublic

Re: [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions

[Stephen Warren]

On 12/05/2011 02:56 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Mon, Dec 5, 2011 at 1:46 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 12/02/2011 07:11 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>;
>>>
>>> where:
>>>
>>> phandle is a pointer to the GPIO node
>>> gpio_num is the number of the GPIO (0 to 223)
>>> flags is some flags, proposed as follows:
>>>
>>>    bit    meaning
>>>    0      0=input, 1=output
>>>    1      for output only: inital value of output
>>>    2      0=polarity normal, 1=active low (inverted)
>>
>> The meaning of the flags (and even whether there are any flags any if so
>> how many cells there are to contain them) is defined by the GPIO
>> controller's binding. It's not something that can be interpreted in
>> isolation by a generic DT parsing function. See for example #gpio-cells
>> in tegra20.dtsi's gpio node and kernel file
>> Documentation/devicetree/bindings/gpio/gpio_nvidia.txt.
> 
> I see this in my version:
> 
> Required properties:
> - compatible : "nvidia,tegra20-gpio"
> - #gpio-cells : Should be two. The first cell is the pin number and the
>   second cell is used to specify optional parameters:
>   - bit 0 specifies polarity (0 for normal, 1 for inverted)
> - gpio-controller : Marks the device node as a GPIO controller.
> 
> so how do I go about adding the other two bits?

I don't think you would. Input vs. output and output value are set up by
APIs such as gpio_direction_input/output based on what the driver wants
to do with the GPIOs.

>>> +/* For now we allow 224 GPIOs. We can extend this later if required */
>>> +enum {
>>> +     FDT_GPIO_NONE = 255,    /* an invalid GPIO used to end our list */
>>
>> Can't you use 0 for that? (the kernel currently uses -1, but it seems
>> there's agreement that was a mistake). If you use 255, the number will
>> have to keep getting bumped as more complex systems become supported. If
>> not 0, perhaps U32_MAX or whatever the relevant ${type}_MAX is?
> 
> But 0 is a valid GPIO isn't it?

Well, it depends how you define your numbering scheme. It may well be!

There are many ways of representing a GPIO:

* GPIO n on a specific controller (of which there may be many). This is
what DT GPIO bindings use.

* A system-wide GPIO ID, in which case the numbering is "virtual" (e.g.
a concatenation of the GPIOs on all the present controllers), and you
can choose to start the first controller's GPIOs at 0, 1, 1000 etc.,
thus leaving -1, 0, -n..999 etc. as invalid GPIOs. This is what the
Linux kernel's gpiolib uses (and some say this global numbering scheme
was a mistake).

> I currently use the max value available to the u8. We can change it at
> will when we update the u8 type to u16 which is why I made it a
> constant.

include/asm-generic/gpio.h seems to use an int to represent a GPIO. I'd
suggest these APIs do the same, rather than use a u8.

-- 
nvpublic

Re: [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions

[Simon Glass]

Hi Stephen,

On Mon, Dec 5, 2011 at 2:22 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> On 12/05/2011 02:56 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Mon, Dec 5, 2011 at 1:46 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>> On 12/02/2011 07:11 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>;
>>>>
>>>> where:
>>>>
>>>> phandle is a pointer to the GPIO node
>>>> gpio_num is the number of the GPIO (0 to 223)
>>>> flags is some flags, proposed as follows:
>>>>
>>>>    bit    meaning
>>>>    0      0=input, 1=output
>>>>    1      for output only: inital value of output
>>>>    2      0=polarity normal, 1=active low (inverted)
>>>
>>> The meaning of the flags (and even whether there are any flags any if so
>>> how many cells there are to contain them) is defined by the GPIO
>>> controller's binding. It's not something that can be interpreted in
>>> isolation by a generic DT parsing function. See for example #gpio-cells
>>> in tegra20.dtsi's gpio node and kernel file
>>> Documentation/devicetree/bindings/gpio/gpio_nvidia.txt.
>>
>> I see this in my version:
>>
>> Required properties:
>> - compatible : "nvidia,tegra20-gpio"
>> - #gpio-cells : Should be two. The first cell is the pin number and the
>>   second cell is used to specify optional parameters:
>>   - bit 0 specifies polarity (0 for normal, 1 for inverted)
>> - gpio-controller : Marks the device node as a GPIO controller.
>>
>> so how do I go about adding the other two bits?
>
> I don't think you would. Input vs. output and output value are set up by
> APIs such as gpio_direction_input/output based on what the driver wants
> to do with the GPIOs.

Fair enough. I am wanting to create a way for more information to be
provided about a GPIO so that it can be set up automatically ready for
use (reduces code size).

>
>>>> +/* For now we allow 224 GPIOs. We can extend this later if required */
>>>> +enum {
>>>> +     FDT_GPIO_NONE = 255,    /* an invalid GPIO used to end our list */
>>>
>>> Can't you use 0 for that? (the kernel currently uses -1, but it seems
>>> there's agreement that was a mistake). If you use 255, the number will
>>> have to keep getting bumped as more complex systems become supported. If
>>> not 0, perhaps U32_MAX or whatever the relevant ${type}_MAX is?
>>
>> But 0 is a valid GPIO isn't it?
>
> Well, it depends how you define your numbering scheme. It may well be!
>
> There are many ways of representing a GPIO:
>
> * GPIO n on a specific controller (of which there may be many). This is
> what DT GPIO bindings use.
>
> * A system-wide GPIO ID, in which case the numbering is "virtual" (e.g.
> a concatenation of the GPIOs on all the present controllers), and you
> can choose to start the first controller's GPIOs at 0, 1, 1000 etc.,
> thus leaving -1, 0, -n..999 etc. as invalid GPIOs. This is what the
> Linux kernel's gpiolib uses (and some say this global numbering scheme
> was a mistake).

Well maybe it was a mistake, but it seems painful for the user to
translate GPIO numbers in this way. U-Boot's GPIO command takes a GPIO
number, which starts at zero.

>
>> I currently use the max value available to the u8. We can change it at
>> will when we update the u8 type to u16 which is why I made it a
>> constant.
>
> include/asm-generic/gpio.h seems to use an int to represent a GPIO. I'd
> suggest these APIs do the same, rather than use a u8.

Do you mean the fdt_gpio_state structure? I have not used u8 for any
function calls and would not.

This adds 3 bytes for every entry. What is the benefit? People get
upset when we waste memory!

Regards,
Simon

>
> --
> nvpublic

Re: [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions

[Stephen Warren]

On 12/05/2011 03:52 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Mon, Dec 5, 2011 at 2:22 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 12/05/2011 02:56 PM, Simon Glass wrote:
>>> Hi Stephen,
>>>
>>> On Mon, Dec 5, 2011 at 1:46 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>>> On 12/02/2011 07:11 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>;
>>>>>
>>>>> where:
>>>>>
>>>>> phandle is a pointer to the GPIO node
>>>>> gpio_num is the number of the GPIO (0 to 223)
>>>>> flags is some flags, proposed as follows:
>>>>>
>>>>>    bit    meaning
>>>>>    0      0=input, 1=output
>>>>>    1      for output only: inital value of output
>>>>>    2      0=polarity normal, 1=active low (inverted)
>>>>
>>>> The meaning of the flags (and even whether there are any flags any if so
>>>> how many cells there are to contain them) is defined by the GPIO
>>>> controller's binding. It's not something that can be interpreted in
>>>> isolation by a generic DT parsing function. See for example #gpio-cells
>>>> in tegra20.dtsi's gpio node and kernel file
>>>> Documentation/devicetree/bindings/gpio/gpio_nvidia.txt.
>>>
>>> I see this in my version:
>>>
>>> Required properties:
>>> - compatible : "nvidia,tegra20-gpio"
>>> - #gpio-cells : Should be two. The first cell is the pin number and the
>>>   second cell is used to specify optional parameters:
>>>   - bit 0 specifies polarity (0 for normal, 1 for inverted)
>>> - gpio-controller : Marks the device node as a GPIO controller.
>>>
>>> so how do I go about adding the other two bits?
>>
>> I don't think you would. Input vs. output and output value are set up by
>> APIs such as gpio_direction_input/output based on what the driver wants
>> to do with the GPIOs.
> 
> Fair enough. I am wanting to create a way for more information to be
> provided about a GPIO so that it can be set up automatically ready for
> use (reduces code size).

At least in this case, I don't think it makes sense to do that. The FDT
is about representing that a particular GPIO is a VBUS GPIO. That
doesn't mean the GPIO /has/ to be an output driven high; that's only
true if the driver is enabled and chooses to configure that port as a
host port, not a device port.

If you wanted to represent GPIOs that were always configured to a
specific output value in DT, I think that'd be an unrelated binding
somewhere other than the USB bus's vbus-gpios property, since it'd have
a completely different semantic meaning.

>> include/asm-generic/gpio.h seems to use an int to represent a GPIO. I'd
>> suggest these APIs do the same, rather than use a u8.
> 
> Do you mean the fdt_gpio_state structure?

Yes.

> I have not used u8 for any
> function calls and would not.
> 
> This adds 3 bytes for every entry. What is the benefit? People get
> upset when we waste memory!

Well, U-boot has already chosen to use an int to represent a GPIO ID.
Given that, I assert that all places that store a GPIO ID should use the
same type. And realistically, we're only talking about a handful of
instances here, and any bloat is completely limited to those platforms
that use this feature, and linear with the number of GPIOs.

-- 
nvpublic

Re: [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions

[Simon Glass]

Hi Stephen,

On Mon, Dec 5, 2011 at 3:03 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> On 12/05/2011 03:52 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Mon, Dec 5, 2011 at 2:22 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>> On 12/05/2011 02:56 PM, Simon Glass wrote:
>>>> Hi Stephen,
>>>>
>>>> On Mon, Dec 5, 2011 at 1:46 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>>>> On 12/02/2011 07:11 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>;
>>>>>>
>>>>>> where:
>>>>>>
>>>>>> phandle is a pointer to the GPIO node
>>>>>> gpio_num is the number of the GPIO (0 to 223)
>>>>>> flags is some flags, proposed as follows:
>>>>>>
>>>>>>    bit    meaning
>>>>>>    0      0=input, 1=output
>>>>>>    1      for output only: inital value of output
>>>>>>    2      0=polarity normal, 1=active low (inverted)
>>>>>
>>>>> The meaning of the flags (and even whether there are any flags any if so
>>>>> how many cells there are to contain them) is defined by the GPIO
>>>>> controller's binding. It's not something that can be interpreted in
>>>>> isolation by a generic DT parsing function. See for example #gpio-cells
>>>>> in tegra20.dtsi's gpio node and kernel file
>>>>> Documentation/devicetree/bindings/gpio/gpio_nvidia.txt.
>>>>
>>>> I see this in my version:
>>>>
>>>> Required properties:
>>>> - compatible : "nvidia,tegra20-gpio"
>>>> - #gpio-cells : Should be two. The first cell is the pin number and the
>>>>   second cell is used to specify optional parameters:
>>>>   - bit 0 specifies polarity (0 for normal, 1 for inverted)
>>>> - gpio-controller : Marks the device node as a GPIO controller.
>>>>
>>>> so how do I go about adding the other two bits?
>>>
>>> I don't think you would. Input vs. output and output value are set up by
>>> APIs such as gpio_direction_input/output based on what the driver wants
>>> to do with the GPIOs.
>>
>> Fair enough. I am wanting to create a way for more information to be
>> provided about a GPIO so that it can be set up automatically ready for
>> use (reduces code size).
>
> At least in this case, I don't think it makes sense to do that. The FDT
> is about representing that a particular GPIO is a VBUS GPIO. That
> doesn't mean the GPIO /has/ to be an output driven high; that's only
> true if the driver is enabled and chooses to configure that port as a
> host port, not a device port.
>
> If you wanted to represent GPIOs that were always configured to a
> specific output value in DT, I think that'd be an unrelated binding
> somewhere other than the USB bus's vbus-gpios property, since it'd have
> a completely different semantic meaning.

I feel that it is useful to have a generic gpio setup function which
can at least set gpio to input or output. We could even make it
optional with an additional flag. IMO a lot of the reason for only
having one flag is that no one can OR together two decimal numbers
(i.e. we need symbolic constants in the fdt).

But for now I will drop this comment and the fdtdec_setup_gpio()
function. This will increase code size slightly since every driver
will need to call gpio_direction_input/output() manually.

>
>>> include/asm-generic/gpio.h seems to use an int to represent a GPIO. I'd
>>> suggest these APIs do the same, rather than use a u8.
>>
>> Do you mean the fdt_gpio_state structure?
>
> Yes.
>
>> I have not used u8 for any
>> function calls and would not.
>>
>> This adds 3 bytes for every entry. What is the benefit? People get
>> upset when we waste memory!
>
> Well, U-boot has already chosen to use an int to represent a GPIO ID.
> Given that, I assert that all places that store a GPIO ID should use the
> same type. And realistically, we're only talking about a handful of
> instances here, and any bloat is completely limited to those platforms
> that use this feature, and linear with the number of GPIOs.

OK I have changed this. Each structure element is now 4 bytes (50%)
bigger than before but I don't think this will add up to more than a
few hundred bytes all up.

Regards,
Simon

>
> --
> nvpublic

Re: [PATCH v2 04/17] fdt: Add basic support for decoding GPIO definitions

[Mike Frysinger]

[-- Attachment #1.1: Type: Text/Plain, Size: 1788 bytes --]

On Monday 05 December 2011 17:52:01 Simon Glass wrote:
> On Mon, Dec 5, 2011 at 2:22 PM, Stephen Warren wrote:
> > On 12/05/2011 02:56 PM, Simon Glass wrote:
> > * A system-wide GPIO ID, in which case the numbering is "virtual" (e.g.
> > a concatenation of the GPIOs on all the present controllers), and you
> > can choose to start the first controller's GPIOs at 0, 1, 1000 etc.,
> > thus leaving -1, 0, -n..999 etc. as invalid GPIOs. This is what the
> > Linux kernel's gpiolib uses (and some say this global numbering scheme
> > was a mistake).
> 
> Well maybe it was a mistake, but it seems painful for the user to
> translate GPIO numbers in this way. U-Boot's GPIO command takes a GPIO
> number, which starts at zero.

u-boot should simply follow what linux is doing as it keeps things a hell of a 
lot simpler for us: the code is done, people moving between the worlds don't 
get surprised and screw something up, and we don't accidentally forget "oh, in 
u-boot we do XXX instead of YYY" and screw things up ourselves.

> >> I currently use the max value available to the u8. We can change it at
> >> will when we update the u8 type to u16 which is why I made it a
> >> constant.
> > 
> > include/asm-generic/gpio.h seems to use an int to represent a GPIO. I'd
> > suggest these APIs do the same, rather than use a u8.
> 
> Do you mean the fdt_gpio_state structure? I have not used u8 for any
> function calls and would not.

the asm-generic/gpio.h using "int" as a gpio is wrong.  it should be 
"unsigned".  there's a patch somewhere to fix this.

> This adds 3 bytes for every entry. What is the benefit? People get
> upset when we waste memory!

some systems have more than 256 GPIOs.  it's actually not that hard to hit the 
limit.
-mike

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- 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 v2 04/17] fdt: Add basic support for decoding GPIO definitions

[Simon Glass]

Hi Mike,

On Mon, Dec 5, 2011 at 7:55 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 05 December 2011 17:52:01 Simon Glass wrote:
>> On Mon, Dec 5, 2011 at 2:22 PM, Stephen Warren wrote:
>> > On 12/05/2011 02:56 PM, Simon Glass wrote:
>> > * A system-wide GPIO ID, in which case the numbering is "virtual" (e.g.
>> > a concatenation of the GPIOs on all the present controllers), and you
>> > can choose to start the first controller's GPIOs at 0, 1, 1000 etc.,
>> > thus leaving -1, 0, -n..999 etc. as invalid GPIOs. This is what the
>> > Linux kernel's gpiolib uses (and some say this global numbering scheme
>> > was a mistake).
>>
>> Well maybe it was a mistake, but it seems painful for the user to
>> translate GPIO numbers in this way. U-Boot's GPIO command takes a GPIO
>> number, which starts at zero.
>
> u-boot should simply follow what linux is doing as it keeps things a hell of a
> lot simpler for us: the code is done, people moving between the worlds don't
> get surprised and screw something up, and we don't accidentally forget "oh, in
> u-boot we do XXX instead of YYY" and screw things up ourselves.

Good, I think that is what we are doing. But if Linux changes the GPIO
numbering we may need to do something.

>
>> >> I currently use the max value available to the u8. We can change it at
>> >> will when we update the u8 type to u16 which is why I made it a
>> >> constant.
>> >
>> > include/asm-generic/gpio.h seems to use an int to represent a GPIO. I'd
>> > suggest these APIs do the same, rather than use a u8.
>>
>> Do you mean the fdt_gpio_state structure? I have not used u8 for any
>> function calls and would not.
>
> the asm-generic/gpio.h using "int" as a gpio is wrong.  it should be
> "unsigned".  there's a patch somewhere to fix this.

OK, will wait to see it.

>
>> This adds 3 bytes for every entry. What is the benefit? People get
>> upset when we waste memory!
>
> some systems have more than 256 GPIOs.  it's actually not that hard to hit the
> limit.
> -mike

Not for me so far, but I don't doubt it. I have changed it to uint in
the series.

Regards,
Simon

[PATCH v2 05/17] 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.3.1

[PATCH v2 07/17] 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.3.1

[PATCH v2 08/17] 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>
---
Changes in v2:
- Pulled USB fdt definitions from newer for-next instead of master

 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.3.1

[PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Simon Glass]

This adds peripheral IDs and timing information to the USB part of the
device tree for U-Boot.

The peripheral IDs provide easy access to clock registers. We will likely
remove this in favor of a full clock tree when it is available in the
kernel (but probably still retain the peripheral ID, just move it into
a clock node).

The USB timing information does apparently vary between boards sometimes,
so is include in the fdt for convenience.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v2:
- Change fdt property usbparmas to usbtiming
- Add details for port USB2

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

diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 6146d24..d7ab843 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -144,11 +144,78 @@
 		interrupts = < 63 >;
 	};
 
+/* This table has USB timing parameters for each Oscillator frequency we
+ * support. There are four sets of values:
+ *
+ * 1. PLLU configuration information (reference clock is osc/clk_m and
+ * PLLU-FOs are fixed at 12MHz/60MHz/480MHz).
+ *
+ *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz
+ *  ----------------------------------------------------------------------
+ *      DIVN                960 (0x3c0)  200 (0c8)    960 (3c0h)   960 (3c0)
+ *      DIVM                13 (0d)      4 (04)       12 (0c)      26 (1a)
+ * Filter frequency (MHz)   1            4.8          6            2
+ * CPCON                    1100b        0011b        1100b        1100b
+ * LFCON0                   0            0            0            0
+ *
+ * 2. PLL CONFIGURATION & PARAMETERS for different clock generators:
+ *
+ * Reference frequency     13.0MHz         19.2MHz         12.0MHz     26.0MHz
+ * ---------------------------------------------------------------------------
+ * PLLU_ENABLE_DLY_COUNT   02 (0x02)       03 (03)         02 (02)     04 (04)
+ * PLLU_STABLE_COUNT       51 (33)         75 (4B)         47 (2F)    102 (66)
+ * PLL_ACTIVE_DLY_COUNT    05 (05)         06 (06)         04 (04)     09 (09)
+ * XTAL_FREQ_COUNT        127 (7F)        187 (BB)        118 (76)    254 (FE)
+ *
+ * 3. Debounce values IdDig, Avalid, Bvalid, VbusValid, VbusWakeUp, and
+ * SessEnd. Each of these signals have their own debouncer and for each of
+ * those one out of two debouncing times can be chosen (BIAS_DEBOUNCE_A or
+ * BIAS_DEBOUNCE_B).
+ *
+ * The values of DEBOUNCE_A and DEBOUNCE_B are calculated as follows:
+ *    0xffff -> No debouncing at all
+ *    <n> ms = <n> *1000 / (1/19.2MHz) / 4
+ *
+ * So to program a 1 ms debounce for BIAS_DEBOUNCE_A, we have:
+ * BIAS_DEBOUNCE_A[15:0] = 1000 * 19.2 / 4  = 4800 = 0x12c0
+ *
+ * We need to use only DebounceA for BOOTROM. We don't need the DebounceB
+ * values, so we can keep those to default.
+ *
+ * a4. The 20 microsecond delay after bias cell operation.
+ *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz
+ */
+	usbtiming@0 {
+		compatible = "nvidia,tegra20-usbtiming";
+		osc-frequency = <13000000>;
+		/* DivN, DivM, DivP, CPCON, LFCON, Delays     Debounce, Bias */
+		timing = <0x3c0 0x0d 0x00 0xc 0  0x02 0x33 0x05 0x7f 0x7ef4 5>;
+	};
+
+	usbtiming@1 {
+		compatible = "nvidia,tegra20-usbtiming";
+		osc-frequency = <19200000>;
+		timing = <0x0c8 0x04 0x00 0x3 0  0x03 0x4b 0x06 0xbb 0xbb80 7>;
+	};
+
+	usbtiming@2 {
+		compatible = "nvidia,tegra20-usbtiming";
+		osc-frequency = <12000000>;
+		timing = <0x3c0 0x0c 0x00 0xc 0  0x02 0x2f 0x04 0x76 0x7530 5>;
+	};
+
+	usbtiming@3 {
+		compatible = "nvidia,tegra20-usbtiming";
+		osc-frequency = <26000000>;
+		timing = <0x3c0 0x1a 0x00 0xc 0  0x04 0x66 0x09 0xfe 0xfde8 9>;
+	};
+
 	usb@c5000000 {
 		compatible = "nvidia,tegra20-ehci", "usb-ehci";
 		reg = <0xc5000000 0x4000>;
 		interrupts = < 52 >;
 		phy_type = "utmi";
+		periph-id = <22>;	// PERIPH_ID_USBD
 	};
 
 	usb@c5004000 {
@@ -156,6 +223,7 @@
 		reg = <0xc5004000 0x4000>;
 		interrupts = < 53 >;
 		phy_type = "ulpi";
+		periph-id = <58>;	// PERIPH_ID_USB2
 	};
 
 	usb@c5008000 {
@@ -163,6 +231,7 @@
 		reg = <0xc5008000 0x4000>;
 		interrupts = < 129 >;
 		phy_type = "utmi";
+		periph-id = <59>;	// PERIPH_ID_USB3
 	};
 
 };
-- 
1.7.3.1

Re: [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Stephen Warren]

On 12/02/2011 07:11 PM, Simon Glass wrote:
> This adds peripheral IDs and timing information to the USB part of the
> device tree for U-Boot.
> 
> The peripheral IDs provide easy access to clock registers. We will likely
> remove this in favor of a full clock tree when it is available in the
> kernel (but probably still retain the peripheral ID, just move it into
> a clock node).
> 
> The USB timing information does apparently vary between boards sometimes,
> so is include in the fdt for convenience.

Which parts vary? Most of it is PLL configuration, and it seems
basically impossible for that to vary yet still create the correct
output frequency.

> +/* This table has USB timing parameters for each Oscillator frequency we

This comment block should be indented to match the nodes.

> + * support. There are four sets of values:
> + *
> + * 1. PLLU configuration information (reference clock is osc/clk_m and
> + * PLLU-FOs are fixed at 12MHz/60MHz/480MHz).
> + *
> + *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz
> + *  ----------------------------------------------------------------------
> + *      DIVN                960 (0x3c0)  200 (0c8)    960 (3c0h)   960 (3c0)
> + *      DIVM                13 (0d)      4 (04)       12 (0c)      26 (1a)
> + * Filter frequency (MHz)   1            4.8          6            2
> + * CPCON                    1100b        0011b        1100b        1100b
> + * LFCON0                   0            0            0            0
> + *
> + * 2. PLL CONFIGURATION & PARAMETERS for different clock generators:
> + *
> + * Reference frequency     13.0MHz         19.2MHz         12.0MHz     26.0MHz
> + * ---------------------------------------------------------------------------
> + * PLLU_ENABLE_DLY_COUNT   02 (0x02)       03 (03)         02 (02)     04 (04)
> + * PLLU_STABLE_COUNT       51 (33)         75 (4B)         47 (2F)    102 (66)
> + * PLL_ACTIVE_DLY_COUNT    05 (05)         06 (06)         04 (04)     09 (09)
> + * XTAL_FREQ_COUNT        127 (7F)        187 (BB)        118 (76)    254 (FE)

Those two sets of data seem like they should simply be part of the clock
driver. Some part of the system boot or USB init process needs to say
"enable the USB clocks", and that code needs to write those hard-coded
values into the relevant clock registers (or calculate them at run-time;
whatever). This stuff can't vary by board.

> + * 3. Debounce values IdDig, Avalid, Bvalid, VbusValid, VbusWakeUp, and
> + * SessEnd. Each of these signals have their own debouncer and for each of
> + * those one out of two debouncing times can be chosen (BIAS_DEBOUNCE_A or
> + * BIAS_DEBOUNCE_B).
> + *
> + * The values of DEBOUNCE_A and DEBOUNCE_B are calculated as follows:
> + *    0xffff -> No debouncing at all
> + *    <n> ms = <n> *1000 / (1/19.2MHz) / 4
> + *
> + * So to program a 1 ms debounce for BIAS_DEBOUNCE_A, we have:
> + * BIAS_DEBOUNCE_A[15:0] = 1000 * 19.2 / 4  = 4800 = 0x12c0
> + *
> + * We need to use only DebounceA for BOOTROM. We don't need the DebounceB
> + * values, so we can keep those to default.
> + *
> + * a4. The 20 microsecond delay after bias cell operation.

      ^ typo

> + *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz

If this data varies at all, then those two sets of data seem
port-specific to me, and hence should be moved into a per-port property.
Having a single global set of parameters that gets applied to all ports
at once doesn't make sense to me, if the data varies.

I imagine the values are board specific too, and hence shouldn't be in
tegra20.dtsi but rather in tegra-seaboard.dts.

The values in these fields should be specific in a way that's agnostic
to the reference clock, e.g. as a number of mS/nS. That way, you'd just
specify the single set of values to use, and the driver would do the
calculations to map the time domain into the reference-clock-specific
values to put into the registers.

> + */
> +
> +	usbtiming@0 {
> +		compatible = "nvidia,tegra20-usbtiming";
> +		osc-frequency = <13000000>;
> +		/* DivN, DivM, DivP, CPCON, LFCON, Delays     Debounce, Bias */
> +		timing = <0x3c0 0x0d 0x00 0xc 0  0x02 0x33 0x05 0x7f 0x7ef4 5>;
> +	};
> +
> +	usbtiming@1 {
> +		compatible = "nvidia,tegra20-usbtiming";
> +		osc-frequency = <19200000>;
> +		timing = <0x0c8 0x04 0x00 0x3 0  0x03 0x4b 0x06 0xbb 0xbb80 7>;
> +	};
> +
> +	usbtiming@2 {
> +		compatible = "nvidia,tegra20-usbtiming";
> +		osc-frequency = <12000000>;
> +		timing = <0x3c0 0x0c 0x00 0xc 0  0x02 0x2f 0x04 0x76 0x7530 5>;
> +	};
> +
> +	usbtiming@3 {
> +		compatible = "nvidia,tegra20-usbtiming";
> +		osc-frequency = <26000000>;
> +		timing = <0x3c0 0x1a 0x00 0xc 0  0x04 0x66 0x09 0xfe 0xfde8 9>;
> +	};

You can't include those timing nodes right there, because the unit
addresses (@0, ... @3) aren't physical addresses in the same scheme as
all the other nodes.

> +
>  	usb@c5000000 {
>  		compatible = "nvidia,tegra20-ehci", "usb-ehci";
>  		reg = <0xc5000000 0x4000>;
>  		interrupts = < 52 >;
>  		phy_type = "utmi";
> +		periph-id = <22>;	// PERIPH_ID_USBD

Given this is a temporary U-Boot-specific solution, can the property be
named u-boot,periph-id so it's obvious that when writing a .dts for the
kernel only, you don't care about this value.

Personally, I'd suggest not having this property at all, but rather have
the driver maintain a base_address -> periph_id mapping table
internally. That table can be removed once the clock/reset bindings are
all set up, and the information can be obtained there instead.

-- 
nvpublic

Re: [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Simon Glass]

Hi Stephen,

On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 12/02/2011 07:11 PM, Simon Glass wrote:
>> This adds peripheral IDs and timing information to the USB part of the
>> device tree for U-Boot.
>>
>> The peripheral IDs provide easy access to clock registers. We will likely
>> remove this in favor of a full clock tree when it is available in the
>> kernel (but probably still retain the peripheral ID, just move it into
>> a clock node).
>>
>> The USB timing information does apparently vary between boards sometimes,
>> so is include in the fdt for convenience.
>
> Which parts vary? Most of it is PLL configuration, and it seems
> basically impossible for that to vary yet still create the correct
> output frequency.

See here for T30 differences, for example.

https://gerrit.chromium.org/gerrit/#patch,sidebyside,12440,1,board/nvidia/cardhu/tegra30.dtsi

>
>> +/* This table has USB timing parameters for each Oscillator frequency we
>
> This comment block should be indented to match the nodes.
>
>> + * support. There are four sets of values:
>> + *
>> + * 1. PLLU configuration information (reference clock is osc/clk_m and
>> + * PLLU-FOs are fixed at 12MHz/60MHz/480MHz).
>> + *
>> + *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz
>> + *  ----------------------------------------------------------------------
>> + *      DIVN                960 (0x3c0)  200 (0c8)    960 (3c0h)   960 (3c0)
>> + *      DIVM                13 (0d)      4 (04)       12 (0c)      26 (1a)
>> + * Filter frequency (MHz)   1            4.8          6            2
>> + * CPCON                    1100b        0011b        1100b        1100b
>> + * LFCON0                   0            0            0            0
>> + *
>> + * 2. PLL CONFIGURATION & PARAMETERS for different clock generators:
>> + *
>> + * Reference frequency     13.0MHz         19.2MHz         12.0MHz     26.0MHz
>> + * ---------------------------------------------------------------------------
>> + * PLLU_ENABLE_DLY_COUNT   02 (0x02)       03 (03)         02 (02)     04 (04)
>> + * PLLU_STABLE_COUNT       51 (33)         75 (4B)         47 (2F)    102 (66)
>> + * PLL_ACTIVE_DLY_COUNT    05 (05)         06 (06)         04 (04)     09 (09)
>> + * XTAL_FREQ_COUNT        127 (7F)        187 (BB)        118 (76)    254 (FE)
>
> Those two sets of data seem like they should simply be part of the clock
> driver. Some part of the system boot or USB init process needs to say
> "enable the USB clocks", and that code needs to write those hard-coded
> values into the relevant clock registers (or calculate them at run-time;
> whatever). This stuff can't vary by board.

We don't have a USB clock driver. This driver is in CPU code, so I am
not suggesting that it varies by board, only by SOC. This stuff is in
the SOC dts.
>
>> + * 3. Debounce values IdDig, Avalid, Bvalid, VbusValid, VbusWakeUp, and
>> + * SessEnd. Each of these signals have their own debouncer and for each of
>> + * those one out of two debouncing times can be chosen (BIAS_DEBOUNCE_A or
>> + * BIAS_DEBOUNCE_B).
>> + *
>> + * The values of DEBOUNCE_A and DEBOUNCE_B are calculated as follows:
>> + *    0xffff -> No debouncing at all
>> + *    <n> ms = <n> *1000 / (1/19.2MHz) / 4
>> + *
>> + * So to program a 1 ms debounce for BIAS_DEBOUNCE_A, we have:
>> + * BIAS_DEBOUNCE_A[15:0] = 1000 * 19.2 / 4  = 4800 = 0x12c0
>> + *
>> + * We need to use only DebounceA for BOOTROM. We don't need the DebounceB
>> + * values, so we can keep those to default.
>> + *
>> + * a4. The 20 microsecond delay after bias cell operation.
>
>      ^ typo
>
>> + *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz
>
> If this data varies at all, then those two sets of data seem
> port-specific to me, and hence should be moved into a per-port property.
> Having a single global set of parameters that gets applied to all ports
> at once doesn't make sense to me, if the data varies.

The hardware doesn't support this does it?

>
> I imagine the values are board specific too, and hence shouldn't be in
> tegra20.dtsi but rather in tegra-seaboard.dts.

I believe they vary by SOC, not board.

>
> The values in these fields should be specific in a way that's agnostic
> to the reference clock, e.g. as a number of mS/nS. That way, you'd just
> specify the single set of values to use, and the driver would do the
> calculations to map the time domain into the reference-clock-specific
> values to put into the registers.

Yes I agree. I don't have time to write this. Shall we go forward with
what we have, and Nvidia can tidy up later?

>
>> + */
>> +
>> +     usbtiming@0 {
>> +             compatible = "nvidia,tegra20-usbtiming";
>> +             osc-frequency = <13000000>;
>> +             /* DivN, DivM, DivP, CPCON, LFCON, Delays     Debounce, Bias */
>> +             timing = <0x3c0 0x0d 0x00 0xc 0  0x02 0x33 0x05 0x7f 0x7ef4 5>;
>> +     };
>> +
>> +     usbtiming@1 {
>> +             compatible = "nvidia,tegra20-usbtiming";
>> +             osc-frequency = <19200000>;
>> +             timing = <0x0c8 0x04 0x00 0x3 0  0x03 0x4b 0x06 0xbb 0xbb80 7>;
>> +     };
>> +
>> +     usbtiming@2 {
>> +             compatible = "nvidia,tegra20-usbtiming";
>> +             osc-frequency = <12000000>;
>> +             timing = <0x3c0 0x0c 0x00 0xc 0  0x02 0x2f 0x04 0x76 0x7530 5>;
>> +     };
>> +
>> +     usbtiming@3 {
>> +             compatible = "nvidia,tegra20-usbtiming";
>> +             osc-frequency = <26000000>;
>> +             timing = <0x3c0 0x1a 0x00 0xc 0  0x04 0x66 0x09 0xfe 0xfde8 9>;
>> +     };
>
> You can't include those timing nodes right there, because the unit
> addresses (@0, ... @3) aren't physical addresses in the same scheme as
> all the other nodes.

Shall I put them inside some other 'timing' node? Bear in mind we
don't have clock stuff yet.

>
>> +
>>       usb@c5000000 {
>>               compatible = "nvidia,tegra20-ehci", "usb-ehci";
>>               reg = <0xc5000000 0x4000>;
>>               interrupts = < 52 >;
>>               phy_type = "utmi";
>> +             periph-id = <22>;       // PERIPH_ID_USBD
>
> Given this is a temporary U-Boot-specific solution, can the property be
> named u-boot,periph-id so it's obvious that when writing a .dts for the
> kernel only, you don't care about this value.

ok. I suggest the kernel does something similar.

>
> Personally, I'd suggest not having this property at all, but rather have
> the driver maintain a base_address -> periph_id mapping table
> internally. That table can be removed once the clock/reset bindings are
> all set up, and the information can be obtained there instead.

I really want to avoid pushing SOC things into the drivers! The SOC
code provides clock/reset functions. It seems useful to have a way of
identifying all the peripherals in the SOC by number.

Regards,
Simon

>
> --
> nvpublic

Re: [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Stephen Warren]

On 12/05/2011 05:55 PM, Simon Glass wrote:
> On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>>> This adds peripheral IDs and timing information to the USB part of the
>>> device tree for U-Boot.
>>>
>>> The peripheral IDs provide easy access to clock registers. We will likely
>>> remove this in favor of a full clock tree when it is available in the
>>> kernel (but probably still retain the peripheral ID, just move it into
>>> a clock node).
>>>
>>> The USB timing information does apparently vary between boards sometimes,
>>> so is include in the fdt for convenience.
>>
>> Which parts vary? Most of it is PLL configuration, and it seems
>> basically impossible for that to vary yet still create the correct
>> output frequency.
> 
> See here for T30 differences, for example.
> 
> https://gerrit.chromium.org/gerrit/#patch,sidebyside,12440,1,board/nvidia/cardhu/tegra30.dtsi

OK, so that varies by SoC not board.

>>> +/* This table has USB timing parameters for each Oscillator frequency we
>>> + * support. There are four sets of values:
>>> + *
>>> + * 1. PLLU configuration information (reference clock is osc/clk_m and
>>> + * PLLU-FOs are fixed at 12MHz/60MHz/480MHz).
>>> + *
>>> + *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz
>>> + *  ----------------------------------------------------------------------
>>> + *      DIVN                960 (0x3c0)  200 (0c8)    960 (3c0h)   960 (3c0)
>>> + *      DIVM                13 (0d)      4 (04)       12 (0c)      26 (1a)
>>> + * Filter frequency (MHz)   1            4.8          6            2
>>> + * CPCON                    1100b        0011b        1100b        1100b
>>> + * LFCON0                   0            0            0            0
>>> + *
>>> + * 2. PLL CONFIGURATION & PARAMETERS for different clock generators:
>>> + *
>>> + * Reference frequency     13.0MHz         19.2MHz         12.0MHz     26.0MHz
>>> + * ---------------------------------------------------------------------------
>>> + * PLLU_ENABLE_DLY_COUNT   02 (0x02)       03 (03)         02 (02)     04 (04)
>>> + * PLLU_STABLE_COUNT       51 (33)         75 (4B)         47 (2F)    102 (66)
>>> + * PLL_ACTIVE_DLY_COUNT    05 (05)         06 (06)         04 (04)     09 (09)
>>> + * XTAL_FREQ_COUNT        127 (7F)        187 (BB)        118 (76)    254 (FE)
>>
>> Those two sets of data seem like they should simply be part of the clock
>> driver. Some part of the system boot or USB init process needs to say
>> "enable the USB clocks", and that code needs to write those hard-coded
>> values into the relevant clock registers (or calculate them at run-time;
>> whatever). This stuff can't vary by board.
> 
> We don't have a USB clock driver. This driver is in CPU code, so I am
> not suggesting that it varies by board, only by SOC. This stuff is in
> the SOC dts.
>>
>>> + * 3. Debounce values IdDig, Avalid, Bvalid, VbusValid, VbusWakeUp, and
>>> + * SessEnd. Each of these signals have their own debouncer and for each of
>>> + * those one out of two debouncing times can be chosen (BIAS_DEBOUNCE_A or
>>> + * BIAS_DEBOUNCE_B).
>>> + *
>>> + * The values of DEBOUNCE_A and DEBOUNCE_B are calculated as follows:
>>> + *    0xffff -> No debouncing at all
>>> + *    <n> ms = <n> *1000 / (1/19.2MHz) / 4
>>> + *
>>> + * So to program a 1 ms debounce for BIAS_DEBOUNCE_A, we have:
>>> + * BIAS_DEBOUNCE_A[15:0] = 1000 * 19.2 / 4  = 4800 = 0x12c0
>>> + *
>>> + * We need to use only DebounceA for BOOTROM. We don't need the DebounceB
>>> + * values, so we can keep those to default.
>>> + *
>>> + * a4. The 20 microsecond delay after bias cell operation.
>>
>>      ^ typo
>>
>>> + *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz
>>
>> If this data varies at all, then those two sets of data seem
>> port-specific to me, and hence should be moved into a per-port property.
>> Having a single global set of parameters that gets applied to all ports
>> at once doesn't make sense to me, if the data varies.
> 
> The hardware doesn't support this does it?

It looks like it doesn't; there are two debounce count registers and
each port (or something) can select which of those two debounce values
is used.

>> I imagine the values are board specific too, and hence shouldn't be in
>> tegra20.dtsi but rather in tegra-seaboard.dts.
> 
> I believe they vary by SOC, not board.

>> The values in these fields should be specific in a way that's agnostic
>> to the reference clock, e.g. as a number of mS/nS. That way, you'd just
>> specify the single set of values to use, and the driver would do the
>> calculations to map the time domain into the reference-clock-specific
>> values to put into the registers.
> 
> Yes I agree. I don't have time to write this. Shall we go forward with
> what we have, and Nvidia can tidy up later?

I definitely oppose that; the current bindings are simply not
conceptually correct. I'm opposed to merging something that's known to
be broken even if there's a clear intent/timeframe to fix it; it'd be
better to just defer merging it. (Well, even better to fix it to be
right an merge it!)

As a blanket statement, the USB driver shouldn't programming PLLs. This
applies whether the PLL configuration is hard-coded in the driver, is
parsed from DT, or whatever. We should definitely remove all the PLL
related stuff from the DT bindings, and have some core or board specific
code set up the PLLs. That code can be replaced by DT clock parsing when
its ready. The USB driver shouldn't be impacted by that change at all.

Re: the debounce values: The kernel doesn't touch those registers as far
as I can tell and everything works. I'd suggest completely removing that
from the DT bindings for now. It's quite possible it only works because
the HW register defaults are correct (or at least work OK) for a 12MHz
reference crystal, and all boards supported by the kernel just happen to
use that reference frequency, but I think the same is probably true for
(Tegra boards in) U-Boot right now too.

Taking that approach, you can completely remove the contentious parts of
the DT binding and defer the problem until more infra-structure is in
place to support those features.

>>> +
>>>       usb@c5000000 {
>>>               compatible = "nvidia,tegra20-ehci", "usb-ehci";
>>>               reg = <0xc5000000 0x4000>;
>>>               interrupts = < 52 >;
>>>               phy_type = "utmi";
>>> +             periph-id = <22>;       // PERIPH_ID_USBD
>>
>> Given this is a temporary U-Boot-specific solution, can the property be
>> named u-boot,periph-id so it's obvious that when writing a .dts for the
>> kernel only, you don't care about this value.
> 
> ok. I suggest the kernel does something similar.

The kernel will use the standardized clock bindings once they're ready
and we convert Tegra over to use them. The kernel is extremely unlikely
to ever use "periph-id" or "u-boot,periph-id".

Right now, the kernel's clock driver contains a mapping table from
device name (e.g. tegra-ehci.2) to clock name (e.g. usb3). This allows
the kernel USB driver to work without any explicit periph-id or similar
DT property.

I'd strongly suggest that's the cleanest transition plan for U-Boot
until the clock bindings are complete, and they are added to
tegra20.dtsi, and U-Boot can parse them, since it avoids temporarily
defining DT properties to WAR the issue, and then yanking them out
later. This mapping would be a part of the core Tegra SoC code,
completely isolated from the USB driver.

-- 
nvpublic

Re: [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Simon Glass]

Hi Stephen,

On Tue, Dec 6, 2011 at 12:28 PM, Stephen Warren <swarren@nvidia.com> wrote:
> On 12/05/2011 05:55 PM, Simon Glass wrote:
>> On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren <swarren@nvidia.com> wrote:
>>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>>>> This adds peripheral IDs and timing information to the USB part of the
>>>> device tree for U-Boot.
>>>>
>>>> The peripheral IDs provide easy access to clock registers. We will likely
>>>> remove this in favor of a full clock tree when it is available in the
>>>> kernel (but probably still retain the peripheral ID, just move it into
>>>> a clock node).
>>>>
>>>> The USB timing information does apparently vary between boards sometimes,
>>>> so is include in the fdt for convenience.
>>>
>>> Which parts vary? Most of it is PLL configuration, and it seems
>>> basically impossible for that to vary yet still create the correct
>>> output frequency.
>>
>> See here for T30 differences, for example.
>>
>> https://gerrit.chromium.org/gerrit/#patch,sidebyside,12440,1,board/nvidia/cardhu/tegra30.dtsi
>
> OK, so that varies by SoC not board.

Yes that's why I put it in tegra20.dtsi. But I have removed it now.

>
>>>> +/* This table has USB timing parameters for each Oscillator frequency we
>>>> + * support. There are four sets of values:
>>>> + *
>>>> + * 1. PLLU configuration information (reference clock is osc/clk_m and
>>>> + * PLLU-FOs are fixed at 12MHz/60MHz/480MHz).
>>>> + *
>>>> + *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz
>>>> + *  ----------------------------------------------------------------------
>>>> + *      DIVN                960 (0x3c0)  200 (0c8)    960 (3c0h)   960 (3c0)
>>>> + *      DIVM                13 (0d)      4 (04)       12 (0c)      26 (1a)
>>>> + * Filter frequency (MHz)   1            4.8          6            2
>>>> + * CPCON                    1100b        0011b        1100b        1100b
>>>> + * LFCON0                   0            0            0            0
>>>> + *
>>>> + * 2. PLL CONFIGURATION & PARAMETERS for different clock generators:
>>>> + *
>>>> + * Reference frequency     13.0MHz         19.2MHz         12.0MHz     26.0MHz
>>>> + * ---------------------------------------------------------------------------
>>>> + * PLLU_ENABLE_DLY_COUNT   02 (0x02)       03 (03)         02 (02)     04 (04)
>>>> + * PLLU_STABLE_COUNT       51 (33)         75 (4B)         47 (2F)    102 (66)
>>>> + * PLL_ACTIVE_DLY_COUNT    05 (05)         06 (06)         04 (04)     09 (09)
>>>> + * XTAL_FREQ_COUNT        127 (7F)        187 (BB)        118 (76)    254 (FE)
>>>
>>> Those two sets of data seem like they should simply be part of the clock
>>> driver. Some part of the system boot or USB init process needs to say
>>> "enable the USB clocks", and that code needs to write those hard-coded
>>> values into the relevant clock registers (or calculate them at run-time;
>>> whatever). This stuff can't vary by board.
>>
>> We don't have a USB clock driver. This driver is in CPU code, so I am
>> not suggesting that it varies by board, only by SOC. This stuff is in
>> the SOC dts.
>>>
>>>> + * 3. Debounce values IdDig, Avalid, Bvalid, VbusValid, VbusWakeUp, and
>>>> + * SessEnd. Each of these signals have their own debouncer and for each of
>>>> + * those one out of two debouncing times can be chosen (BIAS_DEBOUNCE_A or
>>>> + * BIAS_DEBOUNCE_B).
>>>> + *
>>>> + * The values of DEBOUNCE_A and DEBOUNCE_B are calculated as follows:
>>>> + *    0xffff -> No debouncing at all
>>>> + *    <n> ms = <n> *1000 / (1/19.2MHz) / 4
>>>> + *
>>>> + * So to program a 1 ms debounce for BIAS_DEBOUNCE_A, we have:
>>>> + * BIAS_DEBOUNCE_A[15:0] = 1000 * 19.2 / 4  = 4800 = 0x12c0
>>>> + *
>>>> + * We need to use only DebounceA for BOOTROM. We don't need the DebounceB
>>>> + * values, so we can keep those to default.
>>>> + *
>>>> + * a4. The 20 microsecond delay after bias cell operation.
>>>
>>>      ^ typo
>>>
>>>> + *  Reference frequency     13.0MHz      19.2MHz      12.0MHz      26.0MHz
>>>
>>> If this data varies at all, then those two sets of data seem
>>> port-specific to me, and hence should be moved into a per-port property.
>>> Having a single global set of parameters that gets applied to all ports
>>> at once doesn't make sense to me, if the data varies.
>>
>> The hardware doesn't support this does it?
>
> It looks like it doesn't; there are two debounce count registers and
> each port (or something) can select which of those two debounce values
> is used.
>
>>> I imagine the values are board specific too, and hence shouldn't be in
>>> tegra20.dtsi but rather in tegra-seaboard.dts.
>>
>> I believe they vary by SOC, not board.
>
>>> The values in these fields should be specific in a way that's agnostic
>>> to the reference clock, e.g. as a number of mS/nS. That way, you'd just
>>> specify the single set of values to use, and the driver would do the
>>> calculations to map the time domain into the reference-clock-specific
>>> values to put into the registers.
>>
>> Yes I agree. I don't have time to write this. Shall we go forward with
>> what we have, and Nvidia can tidy up later?
>
> I definitely oppose that; the current bindings are simply not
> conceptually correct. I'm opposed to merging something that's known to
> be broken even if there's a clear intent/timeframe to fix it; it'd be
> better to just defer merging it. (Well, even better to fix it to be
> right an merge it!)
>
> As a blanket statement, the USB driver shouldn't programming PLLs. This
> applies whether the PLL configuration is hard-coded in the driver, is
> parsed from DT, or whatever. We should definitely remove all the PLL
> related stuff from the DT bindings, and have some core or board specific
> code set up the PLLs. That code can be replaced by DT clock parsing when
> its ready. The USB driver shouldn't be impacted by that change at all.
>
> Re: the debounce values: The kernel doesn't touch those registers as far
> as I can tell and everything works. I'd suggest completely removing that
> from the DT bindings for now. It's quite possible it only works because
> the HW register defaults are correct (or at least work OK) for a 12MHz
> reference crystal, and all boards supported by the kernel just happen to
> use that reference frequency, but I think the same is probably true for
> (Tegra boards in) U-Boot right now too.
>
> Taking that approach, you can completely remove the contentious parts of
> the DT binding and defer the problem until more infra-structure is in
> place to support those features.

Sorry - I think this was on another thread - but I am removing the fdt
bindings for USB timings from this series. We can deal with it later
as needed.

>
>>>> +
>>>>       usb@c5000000 {
>>>>               compatible = "nvidia,tegra20-ehci", "usb-ehci";
>>>>               reg = <0xc5000000 0x4000>;
>>>>               interrupts = < 52 >;
>>>>               phy_type = "utmi";
>>>> +             periph-id = <22>;       // PERIPH_ID_USBD
>>>
>>> Given this is a temporary U-Boot-specific solution, can the property be
>>> named u-boot,periph-id so it's obvious that when writing a .dts for the
>>> kernel only, you don't care about this value.
>>
>> ok. I suggest the kernel does something similar.
>
> The kernel will use the standardized clock bindings once they're ready
> and we convert Tegra over to use them. The kernel is extremely unlikely
> to ever use "periph-id" or "u-boot,periph-id".

What is the time frame on this working be completed and merged?\

>
> Right now, the kernel's clock driver contains a mapping table from
> device name (e.g. tegra-ehci.2) to clock name (e.g. usb3). This allows
> the kernel USB driver to work without any explicit periph-id or similar
> DT property.

Where does tegra-ehci.2 come from? I don't see that in the fdt.

U-Boot itself does not have a device name or a clock name, or even the
concept of a clock. FDT control has only just arrived in U-Boot and it
needs to fit with what exists in the code base. There needs to be a
multiple sub-arch refactoring effort which I am sure will be taken up
once the kernel completes its work. But this is not just an FDT thing.

>
> I'd strongly suggest that's the cleanest transition plan for U-Boot
> until the clock bindings are complete, and they are added to
> tegra20.dtsi, and U-Boot can parse them, since it avoids temporarily
> defining DT properties to WAR the issue, and then yanking them out
> later. This mapping would be a part of the core Tegra SoC code,
> completely isolated from the USB driver.

Tegra U-Boot already uses peripheral IDs internally - it's
considerably more efficient to be able to refer to a peripheral by a
number than a string. Putting these in the fdt makes it easy for fdt
code to use internal clocks, etc. One way or another the driver code
needs to figure out the peripheral ID. Please have a look at
arch/arm/cpu/armv7/tegra2/clock.c.

I hope that our efforts can continue while we wait for the kernel to
implement clocks. We can then look at writing the required plumbing
code which presumably will be common across ARM architectures, not
tegra-specific. That is going to need review within U-Boot also, and
it is not going to happen overnight. Efficiency is much more of a
concern and no BSS is available when initial fdt decoding starts.

We will want to incorporate these changes with the pinmux stuff also,
since that is already required to do all of this properly.

The one-line addition per peripheral and can easier be converted to
use some other approach later. I've added a u-boot prefix on the
property to clearly show that this is a U-Boot property. I think this
is a reasonable solution.

Regards,
Simon

>
> --
> nvpublic

Re: [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Stephen Warren]

On 12/06/2011 02:09 PM, Simon Glass wrote:
> On Tue, Dec 6, 2011 at 12:28 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 12/05/2011 05:55 PM, Simon Glass wrote:
>>> On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>>>>> This adds peripheral IDs and timing information to the USB part of the
>>>>> device tree for U-Boot.
>>>>>
>>>>> The peripheral IDs provide easy access to clock registers. We will likely
>>>>> remove this in favor of a full clock tree when it is available in the
>>>>> kernel (but probably still retain the peripheral ID, just move it into
>>>>> a clock node).
>>>>>
>>>>> The USB timing information does apparently vary between boards sometimes,
>>>>> so is include in the fdt for convenience.

>>>>>       usb@c5000000 {
>>>>>               compatible = "nvidia,tegra20-ehci", "usb-ehci";
>>>>>               reg = <0xc5000000 0x4000>;
>>>>>               interrupts = < 52 >;
>>>>>               phy_type = "utmi";
>>>>> +             periph-id = <22>;       // PERIPH_ID_USBD
>>>>
>>>> Given this is a temporary U-Boot-specific solution, can the property be
>>>> named u-boot,periph-id so it's obvious that when writing a .dts for the
>>>> kernel only, you don't care about this value.
>>>
>>> ok. I suggest the kernel does something similar.
>>
>> The kernel will use the standardized clock bindings once they're ready
>> and we convert Tegra over to use them. The kernel is extremely unlikely
>> to ever use "periph-id" or "u-boot,periph-id".
> 
> What is the time frame on this working be completed and merged?

Sorry, I have no idea. I've been focusing on other subsystems (pinmux,
audio) and haven't been following the clock stuff at all. Hopefully
someone will start driving Tegra kernel towards common clock soon, but I
don't think exactly who and when has been nailed down yet.

>> Right now, the kernel's clock driver contains a mapping table from
>> device name (e.g. tegra-ehci.2) to clock name (e.g. usb3). This allows
>> the kernel USB driver to work without any explicit periph-id or similar
>> DT property.
> 
> Where does tegra-ehci.2 come from? I don't see that in the fdt.

Pre-DT, everything was instantiated from platform devices. Each one had
a name ("tegra-ehci") and an instance number ("2"), which concatenate to
"tegra-ehci.2". All the clocks (and I think other resources like
regulators) in the kernel were marked as being for use by a particular
device name. For example in arch/arm/mach-tegra/tegra2_clocks.c:

static struct clk tegra_list_clks[] = {
...
        PERIPH_CLK("usb3",      "tegra-ehci.2", ...),

With DT, the device names typically don't follow this format (in this
case, it'd be something more like "/usb@c5008000"). However, this
prevented the clock lookups by device name from working, so a temporary
scheme was put in place to keep the same device names. This is driven by
"AUXDATA", for example in arch/arm/mach-tegra/board-dt.c:


struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
...
//             compatible, unit address, device name
OF_DEV_AUXDATA("nvidia,tegra20-ehci", TEGRA_USB3_BASE, "tegra-ehci.2",

This means that any device with the given compatible property value, the
given unit address will be named accordingly.

This allows the existing clock/regulator lookups to work unmodified.

Once DT bindings are in place for clocks, regulators, etc., the clock
tables can be derived from DT, phandles will be used to match clocks and
devices rather than device names, and the AUXDATA table can go away.

The equivalent in U-Boot would be a table that maps from driver type
(e.g. COMPAT_NVIDIA_TEGRA20_USB or perhaps NVIDIA_TEGRA20_USB?) and
address to periph id. Again, once the clock bindings are complete and
the nodes present in the .dts file, that mapping table can be removed
and everything will work based on phandles.

I'd like to point out here that everything is in a pretty big state of
flux/development, since DT support for ARM is new. Temporary workarounds
like AUXDATA allow us to make as much work as possible using device
tree, but without having to put temporary nodes/properties into the .dts
files themselves. That way, the DT bindings will only ever get added to
in a compatible fashion, rather than going through multiple incompatible
sets of requirements.

-- 
nvpublic

Re: [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Simon Glass]

Hi Stephen,

On Wed, Dec 7, 2011 at 3:36 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> On 12/06/2011 02:09 PM, Simon Glass wrote:
>> On Tue, Dec 6, 2011 at 12:28 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>> On 12/05/2011 05:55 PM, Simon Glass wrote:
>>>> On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>>>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>>>>>> This adds peripheral IDs and timing information to the USB part of the
>>>>>> device tree for U-Boot.
>>>>>>
>>>>>> The peripheral IDs provide easy access to clock registers. We will likely
>>>>>> remove this in favor of a full clock tree when it is available in the
>>>>>> kernel (but probably still retain the peripheral ID, just move it into
>>>>>> a clock node).
>>>>>>
>>>>>> The USB timing information does apparently vary between boards sometimes,
>>>>>> so is include in the fdt for convenience.
>
>>>>>>       usb@c5000000 {
>>>>>>               compatible = "nvidia,tegra20-ehci", "usb-ehci";
>>>>>>               reg = <0xc5000000 0x4000>;
>>>>>>               interrupts = < 52 >;
>>>>>>               phy_type = "utmi";
>>>>>> +             periph-id = <22>;       // PERIPH_ID_USBD
>>>>>
>>>>> Given this is a temporary U-Boot-specific solution, can the property be
>>>>> named u-boot,periph-id so it's obvious that when writing a .dts for the
>>>>> kernel only, you don't care about this value.
>>>>
>>>> ok. I suggest the kernel does something similar.
>>>
>>> The kernel will use the standardized clock bindings once they're ready
>>> and we convert Tegra over to use them. The kernel is extremely unlikely
>>> to ever use "periph-id" or "u-boot,periph-id".
>>
>> What is the time frame on this working be completed and merged?
>
> Sorry, I have no idea. I've been focusing on other subsystems (pinmux,
> audio) and haven't been following the clock stuff at all. Hopefully
> someone will start driving Tegra kernel towards common clock soon, but I
> don't think exactly who and when has been nailed down yet.
>
>>> Right now, the kernel's clock driver contains a mapping table from
>>> device name (e.g. tegra-ehci.2) to clock name (e.g. usb3). This allows
>>> the kernel USB driver to work without any explicit periph-id or similar
>>> DT property.
>>
>> Where does tegra-ehci.2 come from? I don't see that in the fdt.
>
> Pre-DT, everything was instantiated from platform devices. Each one had
> a name ("tegra-ehci") and an instance number ("2"), which concatenate to
> "tegra-ehci.2". All the clocks (and I think other resources like
> regulators) in the kernel were marked as being for use by a particular
> device name. For example in arch/arm/mach-tegra/tegra2_clocks.c:
>
> static struct clk tegra_list_clks[] = {
> ...
>        PERIPH_CLK("usb3",      "tegra-ehci.2", ...),
>
> With DT, the device names typically don't follow this format (in this
> case, it'd be something more like "/usb@c5008000"). However, this
> prevented the clock lookups by device name from working, so a temporary
> scheme was put in place to keep the same device names. This is driven by
> "AUXDATA", for example in arch/arm/mach-tegra/board-dt.c:
>
>
> struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
> ...
> //             compatible, unit address, device name
> OF_DEV_AUXDATA("nvidia,tegra20-ehci", TEGRA_USB3_BASE, "tegra-ehci.2",
>
> This means that any device with the given compatible property value, the
> given unit address will be named accordingly.
>
> This allows the existing clock/regulator lookups to work unmodified.
>
> Once DT bindings are in place for clocks, regulators, etc., the clock
> tables can be derived from DT, phandles will be used to match clocks and
> devices rather than device names, and the AUXDATA table can go away.
>
> The equivalent in U-Boot would be a table that maps from driver type
> (e.g. COMPAT_NVIDIA_TEGRA20_USB or perhaps NVIDIA_TEGRA20_USB?) and
> address to periph id. Again, once the clock bindings are complete and
> the nodes present in the .dts file, that mapping table can be removed
> and everything will work based on phandles.
>
> I'd like to point out here that everything is in a pretty big state of
> flux/development, since DT support for ARM is new. Temporary workarounds
> like AUXDATA allow us to make as much work as possible using device
> tree, but without having to put temporary nodes/properties into the .dts
> files themselves. That way, the DT bindings will only ever get added to
> in a compatible fashion, rather than going through multiple incompatible
> sets of requirements.

Gosh.

I have to say that I feel that peripheral IDs are the best solution
for Tegra U-Boot until everything is worked out in the kernel.

We can't rely on phandles since they don't exist without an fdt,
unless we mandate that everyone must use an fdt. I don't feel
comfortable doing that until things are a bit more stable with all the
things you are working on.

I really can't see why we want to put a table in U-Boot which does a
mapping that is clear a hardware feature and IMO belongs in the fdt
(why repeat peripheral addresses in the code and the fdt?).

Plus I still don't have an answer to my question about how we can
ensure that instance 0 is a particular device. The fact that this just
happens to work in the kernel for uarts, and shouldn't matter for
everything else, is not good enough in U-Boot since scripts etc. rely
on instance mapping being stable.

So for now I think we should simply add a peripheral ID to the fdt,
use the alias mechanism (perhaps augmented by scanning peripherals not
mentioned by an alias if you like) and be done with it.

Regards,
Simon

>
> --
> nvpublic

Re: [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Stephen Warren]

On 12/08/2011 02:10 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Wed, Dec 7, 2011 at 3:36 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On 12/06/2011 02:09 PM, Simon Glass wrote:
>>> On Tue, Dec 6, 2011 at 12:28 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>>> On 12/05/2011 05:55 PM, Simon Glass wrote:
>>>>> On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>>>>>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>>>>>>> This adds peripheral IDs and timing information to the USB part of the
>>>>>>> device tree for U-Boot.
>>>>>>>
>>>>>>> The peripheral IDs provide easy access to clock registers. We will likely
>>>>>>> remove this in favor of a full clock tree when it is available in the
>>>>>>> kernel (but probably still retain the peripheral ID, just move it into
>>>>>>> a clock node).
>>>>>>>
>>>>>>> The USB timing information does apparently vary between boards sometimes,
>>>>>>> so is include in the fdt for convenience.
>>
>>>>>>>       usb@c5000000 {
>>>>>>>               compatible = "nvidia,tegra20-ehci", "usb-ehci";
>>>>>>>               reg = <0xc5000000 0x4000>;
>>>>>>>               interrupts = < 52 >;
>>>>>>>               phy_type = "utmi";
>>>>>>> +             periph-id = <22>;       // PERIPH_ID_USBD
>>>>>>
>>>>>> Given this is a temporary U-Boot-specific solution, can the property be
>>>>>> named u-boot,periph-id so it's obvious that when writing a .dts for the
>>>>>> kernel only, you don't care about this value.
>>>>>
>>>>> ok. I suggest the kernel does something similar.
>>>>
>>>> The kernel will use the standardized clock bindings once they're ready
>>>> and we convert Tegra over to use them. The kernel is extremely unlikely
>>>> to ever use "periph-id" or "u-boot,periph-id".
>>>
>>> What is the time frame on this working be completed and merged?
>>
>> Sorry, I have no idea. I've been focusing on other subsystems (pinmux,
>> audio) and haven't been following the clock stuff at all. Hopefully
>> someone will start driving Tegra kernel towards common clock soon, but I
>> don't think exactly who and when has been nailed down yet.
>>
>>>> Right now, the kernel's clock driver contains a mapping table from
>>>> device name (e.g. tegra-ehci.2) to clock name (e.g. usb3). This allows
>>>> the kernel USB driver to work without any explicit periph-id or similar
>>>> DT property.
>>>
>>> Where does tegra-ehci.2 come from? I don't see that in the fdt.
>>
>> Pre-DT, everything was instantiated from platform devices. Each one had
>> a name ("tegra-ehci") and an instance number ("2"), which concatenate to
>> "tegra-ehci.2". All the clocks (and I think other resources like
>> regulators) in the kernel were marked as being for use by a particular
>> device name. For example in arch/arm/mach-tegra/tegra2_clocks.c:
>>
>> static struct clk tegra_list_clks[] = {
>> ...
>>        PERIPH_CLK("usb3",      "tegra-ehci.2", ...),
>>
>> With DT, the device names typically don't follow this format (in this
>> case, it'd be something more like "/usb@c5008000"). However, this
>> prevented the clock lookups by device name from working, so a temporary
>> scheme was put in place to keep the same device names. This is driven by
>> "AUXDATA", for example in arch/arm/mach-tegra/board-dt.c:
>>
>>
>> struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
>> ...
>> //             compatible, unit address, device name
>> OF_DEV_AUXDATA("nvidia,tegra20-ehci", TEGRA_USB3_BASE, "tegra-ehci.2",
>>
>> This means that any device with the given compatible property value, the
>> given unit address will be named accordingly.
>>
>> This allows the existing clock/regulator lookups to work unmodified.
>>
>> Once DT bindings are in place for clocks, regulators, etc., the clock
>> tables can be derived from DT, phandles will be used to match clocks and
>> devices rather than device names, and the AUXDATA table can go away.
>>
>> The equivalent in U-Boot would be a table that maps from driver type
>> (e.g. COMPAT_NVIDIA_TEGRA20_USB or perhaps NVIDIA_TEGRA20_USB?) and
>> address to periph id. Again, once the clock bindings are complete and
>> the nodes present in the .dts file, that mapping table can be removed
>> and everything will work based on phandles.
>>
>> I'd like to point out here that everything is in a pretty big state of
>> flux/development, since DT support for ARM is new. Temporary workarounds
>> like AUXDATA allow us to make as much work as possible using device
>> tree, but without having to put temporary nodes/properties into the .dts
>> files themselves. That way, the DT bindings will only ever get added to
>> in a compatible fashion, rather than going through multiple incompatible
>> sets of requirements.
> 
> Gosh.
> 
> I have to say that I feel that peripheral IDs are the best solution
> for Tegra U-Boot until everything is worked out in the kernel.

The problem here is that it requires the DT to change incompatibly
later; it adds a property to the DT now that will be at best
meaningless/unused in the future.

If we simply don't add anything to the DT now, there's nothing to remove
from the DT later. Newer U-Boots might require additional information in
the DT (i.e. perhaps rely on full clock bindings) but won't deprecate
any existing fields.

> We can't rely on phandles since they don't exist without an fdt,
> unless we mandate that everyone must use an fdt. I don't feel
> comfortable doing that until things are a bit more stable with all the
> things you are working on.

Sure, phandles won't work until the complete clock binding is implemnted.

> I really can't see why we want to put a table in U-Boot which does a
> mapping that is clear a hardware feature and IMO belongs in the fdt
> (why repeat peripheral addresses in the code and the fdt?).

It's a HW feature of the clock/reset controller, not the USB controller.

> Plus I still don't have an answer to my question about how we can
> ensure that instance 0 is a particular device.

As I said before, in the context of USB (where IIRC the question was
asked), you can enable just a single USB controller. The code only
supports a single controller anyway.

For SD/MMC, it does make sense to statically name some/all devices. That
is what /aliases is for. It's just that as I said, /aliases is meant to
control naming of devices that have been enumerated, not control the
enumeration itself.

-- 
nvpublic

Re: [PATCH v2 09/17] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Simon Glass]

Hi Stephen,

On Mon, Dec 12, 2011 at 10:13 AM, Stephen Warren <swarren@nvidia.com> wrote:
> On 12/08/2011 02:10 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Wed, Dec 7, 2011 at 3:36 PM, Stephen Warren <swarren@nvidia.com> wrote:
>>> On 12/06/2011 02:09 PM, Simon Glass wrote:
>>>> On Tue, Dec 6, 2011 at 12:28 PM, Stephen Warren <swarren@nvidia.com> wrote:
>>>>> On 12/05/2011 05:55 PM, Simon Glass wrote:
>>>>>> On Mon, Dec 5, 2011 at 3:25 PM, Stephen Warren <swarren@nvidia.com> wrote:
>>>>>>> On 12/02/2011 07:11 PM, Simon Glass wrote:
>>>>>>>> This adds peripheral IDs and timing information to the USB part of the
>>>>>>>> device tree for U-Boot.
>>>>>>>>
>>>>>>>> The peripheral IDs provide easy access to clock registers. We will likely
>>>>>>>> remove this in favor of a full clock tree when it is available in the
>>>>>>>> kernel (but probably still retain the peripheral ID, just move it into
>>>>>>>> a clock node).
>>>>>>>>
>>>>>>>> The USB timing information does apparently vary between boards sometimes,
>>>>>>>> so is include in the fdt for convenience.
>>>
>>>>>>>>       usb@c5000000 {
>>>>>>>>               compatible = "nvidia,tegra20-ehci", "usb-ehci";
>>>>>>>>               reg = <0xc5000000 0x4000>;
>>>>>>>>               interrupts = < 52 >;
>>>>>>>>               phy_type = "utmi";
>>>>>>>> +             periph-id = <22>;       // PERIPH_ID_USBD
>>>>>>>
>>>>>>> Given this is a temporary U-Boot-specific solution, can the property be
>>>>>>> named u-boot,periph-id so it's obvious that when writing a .dts for the
>>>>>>> kernel only, you don't care about this value.
>>>>>>
>>>>>> ok. I suggest the kernel does something similar.
>>>>>
>>>>> The kernel will use the standardized clock bindings once they're ready
>>>>> and we convert Tegra over to use them. The kernel is extremely unlikely
>>>>> to ever use "periph-id" or "u-boot,periph-id".
>>>>
>>>> What is the time frame on this working be completed and merged?
>>>
>>> Sorry, I have no idea. I've been focusing on other subsystems (pinmux,
>>> audio) and haven't been following the clock stuff at all. Hopefully
>>> someone will start driving Tegra kernel towards common clock soon, but I
>>> don't think exactly who and when has been nailed down yet.
>>>
>>>>> Right now, the kernel's clock driver contains a mapping table from
>>>>> device name (e.g. tegra-ehci.2) to clock name (e.g. usb3). This allows
>>>>> the kernel USB driver to work without any explicit periph-id or similar
>>>>> DT property.
>>>>
>>>> Where does tegra-ehci.2 come from? I don't see that in the fdt.
>>>
>>> Pre-DT, everything was instantiated from platform devices. Each one had
>>> a name ("tegra-ehci") and an instance number ("2"), which concatenate to
>>> "tegra-ehci.2". All the clocks (and I think other resources like
>>> regulators) in the kernel were marked as being for use by a particular
>>> device name. For example in arch/arm/mach-tegra/tegra2_clocks.c:
>>>
>>> static struct clk tegra_list_clks[] = {
>>> ...
>>>        PERIPH_CLK("usb3",      "tegra-ehci.2", ...),
>>>
>>> With DT, the device names typically don't follow this format (in this
>>> case, it'd be something more like "/usb@c5008000"). However, this
>>> prevented the clock lookups by device name from working, so a temporary
>>> scheme was put in place to keep the same device names. This is driven by
>>> "AUXDATA", for example in arch/arm/mach-tegra/board-dt.c:
>>>
>>>
>>> struct of_dev_auxdata tegra20_auxdata_lookup[] __initdata = {
>>> ...
>>> //             compatible, unit address, device name
>>> OF_DEV_AUXDATA("nvidia,tegra20-ehci", TEGRA_USB3_BASE, "tegra-ehci.2",
>>>
>>> This means that any device with the given compatible property value, the
>>> given unit address will be named accordingly.
>>>
>>> This allows the existing clock/regulator lookups to work unmodified.
>>>
>>> Once DT bindings are in place for clocks, regulators, etc., the clock
>>> tables can be derived from DT, phandles will be used to match clocks and
>>> devices rather than device names, and the AUXDATA table can go away.
>>>
>>> The equivalent in U-Boot would be a table that maps from driver type
>>> (e.g. COMPAT_NVIDIA_TEGRA20_USB or perhaps NVIDIA_TEGRA20_USB?) and
>>> address to periph id. Again, once the clock bindings are complete and
>>> the nodes present in the .dts file, that mapping table can be removed
>>> and everything will work based on phandles.
>>>
>>> I'd like to point out here that everything is in a pretty big state of
>>> flux/development, since DT support for ARM is new. Temporary workarounds
>>> like AUXDATA allow us to make as much work as possible using device
>>> tree, but without having to put temporary nodes/properties into the .dts
>>> files themselves. That way, the DT bindings will only ever get added to
>>> in a compatible fashion, rather than going through multiple incompatible
>>> sets of requirements.
>>
>> Gosh.
>>
>> I have to say that I feel that peripheral IDs are the best solution
>> for Tegra U-Boot until everything is worked out in the kernel.
>
> The problem here is that it requires the DT to change incompatibly
> later; it adds a property to the DT now that will be at best
> meaningless/unused in the future.
>
> If we simply don't add anything to the DT now, there's nothing to remove
> from the DT later. Newer U-Boots might require additional information in
> the DT (i.e. perhaps rely on full clock bindings) but won't deprecate
> any existing fields.

I really don't see the difference between changing the code later and
changing the FDT later. The full clock bindings could be ages away. We
have already given it a u-boot prefix. We might even decided to keep
it for efficiency reasons.

>
>> We can't rely on phandles since they don't exist without an fdt,
>> unless we mandate that everyone must use an fdt. I don't feel
>> comfortable doing that until things are a bit more stable with all the
>> things you are working on.
>
> Sure, phandles won't work until the complete clock binding is implemnted.

No I mean they won't work if someone isn't using CONFIG_OF_CONTROL and
thus doesn't have a device tree at all. This option is optional in
U-Boot, and in fact has only been in mainline for 5 minutes, and there
are no users up until this patch. FDT still needs to prove its worth
in U-Boot.

>
>> I really can't see why we want to put a table in U-Boot which does a
>> mapping that is clear a hardware feature and IMO belongs in the fdt
>> (why repeat peripheral addresses in the code and the fdt?).
>
> It's a HW feature of the clock/reset controller, not the USB controller.

I think I was responding to your request to have tables in U-Boot like:

<device_type>, <peripheral_address> -> clock ID

My objection is that <device_type> is already encoded in the
compatible string, <peripheral_address> is in the reg property, and we
can avoid the same altogether by putting the peripheral ID in the FDT
too. In fact I thought we already agreed on u-boot,periph-id.

>
>> Plus I still don't have an answer to my question about how we can
>> ensure that instance 0 is a particular device.
>
> As I said before, in the context of USB (where IIRC the question was
> asked), you can enable just a single USB controller. The code only
> supports a single controller anyway.

Yes but it must be the correct controller. In other words, on Seaboard
the side controller must be first for USB to work.

>
> For SD/MMC, it does make sense to statically name some/all devices. That
> is what /aliases is for. It's just that as I said, /aliases is meant to
> control naming of devices that have been enumerated, not control the
> enumeration itself.

And UARTs I think. So I think this means we are happy with the aliases
approach, and we are now just discussing the algorithm.

Regards,
SImon

>
> --
> nvpublic

[PATCH v2 10/17] 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

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

diff --git a/board/nvidia/dts/tegra2-seaboard.dts b/board/nvidia/dts/tegra2-seaboard.dts
index dde5d03..19c6503 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 >;
@@ -31,6 +37,12 @@
 	};
 
 	usb@c5000000 {
-		nvidia,vbus-gpio = <&gpio 24 0>; /* PD0 */
+		nvidia,vbus-gpio = <&gpio 24 1>; /* PD0 high to enable vbus */
+		support-host-mode;
+		status = "okay";
+	};
+
+	usb@c5008000 {
+		status = "okay";
 	};
 };
-- 
1.7.3.1

Re: [PATCH v2 10/17] tegra: usb: fdt: Add USB definitions for Tegra2 Seaboard

[Stephen Warren]

On 12/02/2011 07:11 PM, Simon Glass wrote:
> We set up two USB ports, one of which can be host or device.
> For some reason the kernel version does enable both ports.

> +++ 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";
> +        };
> +

That's indented with spaces instead of TABs.

>  	memory {
>  		device_type = "memory";
>  		reg = < 0x00000000 0x40000000 >;
> @@ -31,6 +37,12 @@
>  	};
>  
>  	usb@c5000000 {
> -		nvidia,vbus-gpio = <&gpio 24 0>; /* PD0 */
> +		nvidia,vbus-gpio = <&gpio 24 1>; /* PD0 high to enable vbus */
> +		support-host-mode;
> +		status = "okay";

That's the default, and tegra20.dtsi doesn't specify status =
"disabled", so the status properties are redundant. You may want to
specify a disabled status in tegra-seaboard.dts for the other USB port
if it isn't used though.

> +	};
> +
> +	usb@c5008000 {
> +		status = "okay";
>  	};
>  };

-- 
nvpublic

[PATCH v2 17/17] 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>
---

 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.3.1