tegra: Add fdt definitions and USB driver

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 <[email protected]>

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<[email protected]>

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

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

where:

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

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

An example is:

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

include/fdtdec.h +0 -0

Quoted 5 lines · 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>;

That's not true in general.

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

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

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

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

Quoted 8 lines

where:

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

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

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

Quoted 3 lines

An example is:

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

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

...

Quoted 1 line

include/fdtdec.h +0 -0

...

include/fdtdec.h enum fdt_compat_id { · line 66

Quoted 3 lines

include/fdtdec.h +3 -0

+/* GPIOs are numbered from 0 */
+enum {
+     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */

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

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

--
nvpublic

Hi Stephen,

Quoted 3 lines · Stephen Warren

Quoted 2 lines · Simon Glass

This adds some support into fdtdec for reading GPIO definitions from the fdt. ...

Quoted 13 lines

Quoted 1 line

include/fdtdec.h +0 -0

...

include/fdtdec.h enum fdt_compat_id { · line 66

Quoted 3 lines

include/fdtdec.h +3 -0

+/* GPIOs are numbered from 0 */
+enum {
+     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */

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

It is nothing to do with U-Boot itself - we can choose any number.

What is Linux using now / planning to use?

Quoted 6 lines · Simon Glass

Hi Stephen,

Quoted 3 lines · Stephen Warren

Quoted 2 lines · Simon Glass

This adds some support into fdtdec for reading GPIO definitions from the fdt. ...

...

Quoted 14 lines

Quoted 13 lines

Quoted 1 line

include/fdtdec.h +0 -0

...

include/fdtdec.h enum fdt_compat_id { · line 66

Quoted 3 lines

include/fdtdec.h +3 -0

+/* GPIOs are numbered from 0 */
+enum {
+     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */

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

Quoted 1 line

It is nothing to do with U-Boot itself - we can choose any number.

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

Quoted 2 lines

What is Linux using now / planning to use?

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

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

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

--
nvpublic

Quoted 22 lines · Simon Glass

Quoted 6 lines

Hi Stephen,

Quoted 3 lines · Stephen Warren

Quoted 2 lines · Simon Glass

This adds some support into fdtdec for reading GPIO definitions from the fdt. ...

...

Quoted 14 lines

Quoted 13 lines

Quoted 1 line

include/fdtdec.h +0 -0

...

include/fdtdec.h

Quoted 3 lines

include/fdtdec.h +3 -0

+/* GPIOs are numbered from 0 */
+enum {
+     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */

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

Quoted 4 lines

Quoted 1 line

It is nothing to do with U-Boot itself - we can choose any number.

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

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

Simon Glass wrote at Tuesday, January 24, 2012 4:12 PM:

Quoted 25 lines · Stephen Warren

Quoted 24 lines · Simon Glass

Quoted 6 lines

Hi Stephen,

Quoted 3 lines · Stephen Warren

Quoted 2 lines · Simon Glass

This adds some support into fdtdec for reading GPIO definitions from the fdt. ...

...

Quoted 15 lines

Quoted 13 lines

Quoted 1 line

include/fdtdec.h +0 -0

...

include/fdtdec.h

Quoted 3 lines

include/fdtdec.h +3 -0

+/* GPIOs are numbered from 0 */
+enum {
+     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */

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

It is nothing to do with U-Boot itself - we can choose any number.

Quoted 5 lines

Quoted 2 lines

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

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

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

--
nvpublic

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.

Hi Simon,

Quoted 1 line · Simon Glass

By putting the fdt blob into a distinctive area we can ensure that it

Quoted 5 lines

at the start of the data section and is word-aligned.

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

Stop me if I am wrong, but objcopy obviously works with output sections

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

Not that I am against the patch, mind you, quite the opposite. I am just

Amicalement,
--
Albert.

Hi Albert,

Quoted 6 lines · Albert ARIBAUD

Hi Simon,

Quoted 1 line · Simon Glass

By putting the fdt blob into a distinctive area we can ensure that it

appears

Quoted 8 lines

Quoted 5 lines

at the start of the data section and is word-aligned.

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

Stop me if I am wrong, but objcopy obviously works with output sections

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

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

Quoted 1 line

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

fixed here?

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

Quoted 1 line

Not that I am against the patch, mind you, quite the opposite. I am just

wondering about the pros and cons of having a separated (and aligned) DTS data *output* section and placing that section after .code and .data rather than between them.

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

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

Regards,
Simon

Hi Simon,

Quoted 3 lines · Simon Glass

Hi Albert,

On Feb 18, 2012 3:51 AM, "Albert ARIBAUD"<[email protected]>

Quoted 18 lines

Quoted 7 lines

Hi Simon,

Quoted 1 line · Simon Glass

By putting the fdt blob into a distinctive area we can ensure that it

appears

Quoted 9 lines

Quoted 6 lines

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.

Quoted 3 lines

Quoted 1 line

Stop me if I am wrong, but objcopy obviously works with output sections

of its input file, not with input ones that this file was linked from,

Quoted 6 lines

so it cannot act upon alignment of data input sections, right? And as, before your patch, there is no designated output section for DTS data, it ends up (possibly mis-aligned) in the .data output section (which is globally aligned however), so there is no chance anyway that objcopy can re-align DTS data if they were mis-aligned.

Quoted 5 lines

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

Objcopy is only a utility to convert built binaries from one format to

Quoted 8 lines

Quoted 2 lines

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

fixed here?

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

Understood. This example of an alignment failure scenario shows that the

Quoted 6 lines

Quoted 3 lines

Not that I am against the patch, mind you, quite the opposite. I am just

wondering about the pros and cons of having a separated (and aligned) DTS data *output* section and placing that section after .code and .data

Quoted 4 lines

than between them.

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

Understood, and I think that's one more reason to make sure that the act

Quoted 2 lines

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

I much prefer embedded FDT data to be explicitly mapped to a a dedicated

Quoted 4 lines

Regards,
Simon

Amicalement,
--
Albert.

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

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

Quoted 10 lines

Quoted 7 lines

Quoted 1 line

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

fixed here?

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

Understood. This example of an alignment failure scenario shows that the

failure cause is indeed that the FDT is embedded in the .data output section at link time.

Quoted 6 lines

Quoted 6 lines

Quoted 3 lines

Not that I am against the patch, mind you, quite the opposite. I am just

wondering about the pros and cons of having a separated (and aligned) DTS data *output* section and placing that section after .code and .data

rather

Quoted 2 lines

Quoted 2 lines

than between them.

Quoted 5 lines

Quoted 2 lines

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

Understood, and I think that's one more reason to make sure that the act

of FDT embedding does not alter .data input section ordering.

Well it is just a data section really.

Quoted 4 lines

Quoted 1 line

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

I much prefer embedded FDT data to be explicitly mapped to a a dedicated

.fdt output section in u-boot.lds, because it ensures that aligment constaints for .fdt and .data can be controlled independently.

I will take a look at this.

Regards,
Simon

Hi Simon,

Quoted 9 lines · Simon Glass

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

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

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

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

Quoted 35 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

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

fixed here?

Quoted 7 lines

Quoted 3 lines

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

Understood. This example of an alignment failure scenario shows that the

failure cause is indeed that the FDT is embedded in the .data output section at link time.

Quoted 10 lines

Quoted 10 lines

Quoted 5 lines

Not that I am against the patch, mind you, quite the opposite. I am just

wondering about the pros and cons of having a separated (and aligned) DTS
data *output* section and placing that section after .code and .data

rather

Quoted 8 lines

Quoted 5 lines

than between them.

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

Quoted 5 lines

Quoted 1 line

Understood, and I think that's one more reason to make sure that the act

of FDT embedding does not alter .data input section ordering.

Well it is just a data section really.

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

Quoted 9 lines

Quoted 5 lines

Quoted 1 line

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

I much prefer embedded FDT data to be explicitly mapped to a a dedicated

.fdt output section in u-boot.lds, because it ensures that aligment constaints for .fdt and .data can be controlled independently.

Quoted 1 line

I will take a look at this.

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

Quoted 4 lines

Regards,
Simon

Amicalement,
--
Albert.

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 <[email protected]>

arch/arm/dts/tegra20.dtsi +0 -0

Quoted 11 lines · 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 <[email protected]>

arch/arm/dts/tegra20.dtsi +0 -0

...

Quoted 7 lines

+     i2c@7000d000 {
+             #address-cells = <1>;
+             #size-cells = <0>;
+             compatible = "nvidia,tegra20-i2c";
+             reg = <0x7000D000 0x200>;
+             interrupts = < 85 >;
+     };

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

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

--
nvpublic

Hi Stephen,

Quoted 26 lines · Stephen Warren

Quoted 11 lines · 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 <[email protected]>

arch/arm/dts/tegra20.dtsi +0 -0

...

arch/arm/dts/tegra20.dtsi line 45

Quoted 7 lines

arch/arm/dts/tegra20.dtsi +7 -0

+     i2c@7000d000 {
+             #address-cells = <1>;
+             #size-cells = <0>;
+             compatible = "nvidia,tegra20-i2c";
+             reg = <0x7000D000 0x200>;
+             interrupts = < 85 >;
+     };

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

Quoted 2 lines

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

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

Quoted 4 lines · 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 <[email protected]>

board/nvidia/dts/tegra2-seaboard.dts

Quoted 1 line

board/nvidia/dts/tegra2-seaboard.dts +0 -0

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

--
nvpublic

doc/device-tree-bindings/README line 15

Quoted 12 lines · Simon Glass

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

Signed-off-by Simon Glass <[email protected]>

doc/device-tree-bindings/README +5 -0

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

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

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

--
nvpublic

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

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +5 -0

new file mode 100644
index 0000000..71cfdd2
@@ -0,0 +1,156 @@
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +11 -0

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

Quoted 15 lines

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +14 -0

+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,<chip>-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- clock-names : Should contain a list of strings, with values "32k_in",

Quoted 1 line

+ and "osc".

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

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt line 28

Quoted 13 lines

+- #clock-cells : Should be 1.

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +12 -0

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

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

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

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt line 132

Quoted 4 lines

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +4 -0

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

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

Quoted 11 lines

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +11 -0

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

Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:

Quoted 16 lines · Stephen Warren

Quoted 15 lines

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +14 -0

+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,<chip>-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- clock-names : Should contain a list of strings, with values "32k_in",

Quoted 8 lines

Quoted 1 line

+  and "osc".

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

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

Quoted 17 lines

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt line 28

Quoted 13 lines

+- #clock-cells : Should be 1.
+  In clock consumers, this cell represents the clock ID exposed by the CAR.
+  For a list of valid values, see the clock-output-names property.

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +10 -0

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

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

Quoted 2 lines

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

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

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

Quoted 7 lines

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt line 132

Quoted 4 lines

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +4 -0

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

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

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

Quoted 11 lines

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt line 143

Quoted 11 lines

+           compatible = "fixed-clock";
+           #clock-cells = <0>;
+           clock-frequency = <32768>;
+   };

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +7 -0

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

Hi,

Quoted 26 lines · Stephen Warren

Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:

Quoted 16 lines · Stephen Warren

Quoted 15 lines

(quoted diff) +14 -0

+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,<chip>-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- clock-names : Should contain a list of strings, with values "32k_in",

Quoted 8 lines

Quoted 1 line

+ and "osc".

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

Quoted 3 lines

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

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

Quoted 20 lines

Quoted 17 lines

Review

Quoted 13 lines

+- #clock-cells : Should be 1.

(quoted diff) +12 -0

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

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

Quoted 2 lines

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

Quoted 8 lines

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

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

Again, sounds good to me.

Quoted 11 lines

Quoted 7 lines

Review

Quoted 4 lines

(quoted diff) +4 -0

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

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

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

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

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

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

Quoted 13 lines

Quoted 13 lines

Review

Quoted 13 lines

(quoted diff) +11 -0

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

-Olof

Quoted 18 lines

Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:

Quoted 17 lines · Stephen Warren

Quoted 16 lines

(quoted diff) +15 -0

+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,<chip>-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- clock-names : Should contain a list of strings, with values "32k_in",
+  and "osc".

Quoted 11 lines

Quoted 7 lines

Review

Quoted 4 lines

(quoted diff) +4 -0

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

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

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

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

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

Olof Johansson wrote at Saturday, January 21, 2012 12:32 AM:

Quoted 19 lines · Stephen Warren

Quoted 18 lines

Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:

Quoted 17 lines · Stephen Warren

Quoted 16 lines

(quoted diff) +15 -0

+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,<chip>-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- clock-names : Should contain a list of strings, with values "32k_in",
+  and "osc".

...

Quoted 12 lines

Quoted 11 lines

Quoted 7 lines

Review

Quoted 4 lines

(quoted diff) +4 -0

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

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

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

Quoted 6 lines

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

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

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

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

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

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

Hi,

Quoted 26 lines · Stephen Warren

Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:

Quoted 24 lines · Stephen Warren

Quoted 6 lines

(quoted diff) +5 -0

+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+

Review

Quoted 10 lines

(quoted diff) +10 -0

+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,<chip>-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- clock-names : Should contain a list of strings, with values "32k_in",
+  and "osc".

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

Quoted 3 lines

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

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

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

Signed-off-by Stephen Warren <[email protected]>

---
All, Simon Glass is attempting to upstream Tegra USB support in U-Boot. The driver is only instantiated from device tree, and needs to configure clocks for the USB module. Hence, he proposed a clock binding for Tegra. I've read through Grant's proposed common clock bindings and reworked Simon's proposal a little, ending up with the patch below for the kernel. I'd appreciate any comments you have.

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

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

A comment on the shared enable issue:

When enabling/disabling clocks, Tegra requires you to reset the HW module that the clock is routed to. Both reset and clock enable registers are part of the CAR. U-Boot currently has an API to do the reset based on a "peripheral ID", which simply means a bit number in a set of 3 "reset" registers. The bits in those registers share the same numbering as the "clock enable" registers. Hence, to make life easy for U-Boot, I've defined the clock IDs in this binding to be equal to these bit numbers. However, this breaks down where there isn't a 1:1 mapping between reset and clock enable bits, and clocks. For example, there's a single reset and clock enable bit for the SPDIF controller, yet this applies to two clocks; spdif_in and spdif_out. Hence, this simplification for U-Boot breaks down. I think the correct solution is to fix U-Boot not to require this simplification, renumber the clocks in the CAR binding in a completely arbitrary fashion, and require U-Boot to contain a mapping

table between CAR's DT clock IDs and any other information related to those clocks. Do you see any alternative? We really need the two SPDIF clocks to be different clock IDs in the binding, since each has a completely independant mux for the clock source/parent, and the two clocks obviously can't share the same clock ID (well, hmm, perhaps they could if we used 2 cells for the specifier, 1 for the bit number, and one more to differentiate clocks that use the same bit...). I'm still inclined to simply push back on U-Boot to do it right.

 .../bindings/clock/nvidia,tegra20-car.txt          |  156 ++++++++++++++++++++ arch/arm/boot/dts/tegra-seaboard.dts               |   18 +++ arch/arm/boot/dts/tegra20.dtsi                     |    7 +

 3 files changed, 181 insertions(+), 0 deletions(-)

 create mode 100644 Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +18 -0

new file mode 100644
index 0000000..71cfdd2
@@ -0,0 +1,156 @@
+* NVIDIA Tegra20 Clock And Reset Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+
+Required properties :
+- compatible : Should be "nvidia,<chip>-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- clock-names : Should contain a list of strings, with values "32k_in",
+  and "osc".
+- #clock-cells : Should be 1.
+  In clock consumers, this cell represents the clock ID exposed by the CAR.
+  For a list of valid values, see the clock-output-names property.

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +105 -0

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

Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt new file +9 -0

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

arch/arm/boot/dts/tegra-seaboard.dts +2 -0

index b55a02e..f9347fe 100644
@@ -11,6 +11,24 @@
                reg = < 0x00000000 0x40000000 >;
        };
 
+       clocks {
+               clk_32k: oscillator@0 {

arch/arm/boot/dts/tegra-seaboard.dts +2 -0

+       };
+
        i2c@7000c000 {
                clock-frequency = <400000>;
        };

arch/arm/boot/dts/tegra20.dtsi +0 -0

index 3da7afd..be4abd2 100644

arch/arm/boot/dts/tegra20.dtsi +4 -1

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

1.7.0.4

Quoted 3 lines

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

Quoted 16 lines

A comment on the shared enable issue:

When enabling/disabling clocks, Tegra requires you to reset the HW module that the clock is routed to. Both reset and clock enable registers are part of the CAR. U-Boot currently has an API to do the reset based on a "peripheral ID", which simply means a bit number in a set of 3 "reset" registers. The bits in those registers share the same numbering as the "clock enable" registers. Hence, to make life easy for U-Boot, I've defined the clock IDs in this binding to be equal to these bit numbers. However, this breaks down where there isn't a 1:1 mapping between reset and clock enable bits, and clocks. For example, there's a single reset and clock enable bit for the SPDIF controller, yet this applies to two clocks; spdif_in and spdif_out. Hence, this simplification for U-Boot breaks down. I think the correct solution is to fix U-Boot not to require this simplification, renumber the clocks in the CAR binding in a completely arbitrary fashion, and require U-Boot to contain a mapping

Quoted 8 lines

table between CAR's DT clock IDs and any other information related to those clocks. Do you see any alternative? We really need the two SPDIF clocks to be different clock IDs in the binding, since each has a completely independant mux for the clock source/parent, and the two clocks obviously can't share the same clock ID (well, hmm, perhaps they could if we used 2 cells for the specifier, 1 for the bit number, and one more to differentiate clocks that use the same bit...). I'm still inclined to simply push back on U-Boot to do it right.

Are SPDIF and VI the only examples of this?

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

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

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

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

Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:

Quoted 4 lines

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

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

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

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

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

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

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

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

Does that all seem reasonable?

--
nvpublic

Quoted 6 lines

Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:

Quoted 4 lines

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

Quoted 3 lines

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

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

Quoted 3 lines

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

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

Colin Cross wrote at Tuesday, January 24, 2012 3:33 PM:

Quoted 7 lines · Stephen Warren

Quoted 6 lines

Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:

Quoted 4 lines

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

Quoted 7 lines

Quoted 3 lines

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

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

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

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

Quoted 9 lines

Quoted 3 lines

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

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

OK, those reasons make sense.

--
nvpublic

Quoted 16 lines · Stephen Warren

Colin Cross wrote at Tuesday, January 24, 2012 3:33 PM:

Quoted 7 lines · Stephen Warren

Quoted 6 lines

Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:

Quoted 4 lines

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

Quoted 7 lines

Quoted 3 lines

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

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

Quoted 7 lines

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

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

Quoted 7 lines · Simon Glass

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

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

arch/arm/dts/tegra20.dtsi

Quoted 3 lines

arch/arm/dts/tegra20.dtsi +1 -0

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

Typically /* */ rather than // I think

--
nvpublic

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 <[email protected]>

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<[email protected]>

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

Signed-off-by Simon Glass <[email protected]>

---

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

doc/device-tree-bindings/usb/tegra-usb.txt +0 -0

index 035d63d..96fd022 100644

Quoted 14 lines · Simon Glass

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

Signed-off-by Simon Glass <[email protected]>

---

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

doc/device-tree-bindings/usb/tegra-usb.txt +0 -0

index 035d63d..96fd022 100644

doc/device-tree-bindings/usb/tegra-usb.txt Required properties : · line 17

Quoted 7 lines

doc/device-tree-bindings/usb/tegra-usb.txt +4 -0

@@ -11,3 +11,7 @@ Required properties :
  - phy_type : Should be one of "ulpi" or "utmi".
  - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
    activated for the bus to be powered.
+
+Optional properties:
+ - support-host-mode : If present then this peripheral can switch between
+   host and device mode

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

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

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

i.e.:

Quoted 38 lines · Stephen Warren

Quoted 17 lines · Simon Glass

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

Signed-off-by Simon Glass <[email protected]>

---

 doc/device-tree-bindings/usb/tegra-usb.txt |    4 ++++

 1 files changed, 4 insertions(+), 0 deletions(-)

doc/device-tree-bindings/usb/tegra-usb.txt +0 -0

index 035d63d..96fd022 100644
@@ -11,3 +11,7 @@ Required properties :

  - phy_type : Should be one of "ulpi" or "utmi".
  - nvidia,vbus-gpio : If present, specifies a gpio that needs to be activated for the bus to be powered.

doc/device-tree-bindings/usb/tegra-usb.txt Required properties : · line 17

Quoted 4 lines

doc/device-tree-bindings/usb/tegra-usb.txt +4 -0

+
+Optional properties:
+ - support-host-mode : If present then this peripheral can switch between
+   host and device mode

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

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

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

Quoted 7 lines

i.e.:

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

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

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

-Olof

Quoted 6 lines

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

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

What does 'dr' mean?

Hi,

Quoted 3 lines · Simon Glass

Quoted 3 lines

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

Quoted 5 lines

Quoted 3 lines

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

What does 'dr' mean?

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

-Olof

Hi Olof,

Quoted 13 lines · Olof Johansson

Hi,

Quoted 8 lines · Simon Glass

Quoted 6 lines

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

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

What does 'dr' mean?

Quoted 2 lines

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

Thanks for looking that up.

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

Quoted 19 lines

Hi Olof,

Quoted 15 lines · Olof Johansson

Hi,

Quoted 8 lines · Simon Glass

Quoted 6 lines

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

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

What does 'dr' mean?

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

Quoted 5 lines

Thanks for looking that up.

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

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

Olof Johansson wrote at Thursday, January 19, 2012 12:13 AM:

Quoted 26 lines · Simon Glass

Quoted 24 lines

Hi Olof,

Quoted 7 lines · Olof Johansson

Hi,

Quoted 3 lines · Simon Glass

Quoted 3 lines

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

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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

What does 'dr' mean?

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

Thanks for looking that up.

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

Quoted 2 lines

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

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

--
nvpublic

CONFIG_USB_EHCI_TXFIFO_THRESH enables setting of the txfilltuning field in the EHCI controller on reset.

Signed-off-by Simon Glass <[email protected]>

---

?README ? ? ? ? ? ? ? ? ? ? ?| ? ?3 +++
?drivers/usb/host/ehci-hcd.c | ? ?7 +++++++
?drivers/usb/host/ehci.h ? ? | ? ?6 +++++-

?3 files changed, 15 insertions(+), 1 deletions(-)

This adds basic support for the Tegra2 USB controller. Board files should call board_usb_init() to set things up.

Configuration is performed through the FDT, with aliases used to set the order of the ports, like this fragment:

? ? ? ?aliases {
? ? ? ? ? ? ? ?/* This defines the order of our USB ports */ ? ? ? ? ? ? ? ?usb0 = "/usb at 0xc5008000";
? ? ? ? ? ? ? ?usb1 = "/usb at 0xc5000000";
? ? ? ?};

drivers/usb/host files ONLY: Acked-by: Remy Bohmer <[email protected]>

Signed-off-by Simon Glass <[email protected]>

---
Changes in v2:
- Rename params to timing
- Store entire fdt config in port list, not just register pointer
- Remove non-fdt operation of USB, since it is not needed
- Decode USB VBUS GPIO from the fdt
- Decode phy type differently (to match new kernel fdt)
- Rename tegra20-usb to tegra20-ehcui (to match new kernel fdt)
- Improve debug() printouts in case of failure to init USB

Changes in v3:
- Remove usbparams properties from fdt and moved them to C code

Changes in v4:
- Use updated fdtdec alias functiona to get USB aliases
- Use peripheral clock node to obtain peripheral ID

?arch/arm/cpu/armv7/tegra2/Makefile ? ? ? ?| ? ?4 +-
?arch/arm/cpu/armv7/tegra2/usb.c ? ? ? ? ? | ?426 +++++++++++++++++++++++++++++
?arch/arm/include/asm/arch-tegra2/tegra2.h | ? ?2 +
?arch/arm/include/asm/arch-tegra2/usb.h ? ?| ?255 +++++++++++++++++
?drivers/usb/host/Makefile ? ? ? ? ? ? ? ? | ? ?1 +
?drivers/usb/host/ehci-tegra.c ? ? ? ? ? ? | ? 63 +++++

+void usbf_reset_controller(enum periph_id id, struct usb_ctlr *usbctlr)

arch/arm/cpu/armv7/tegra2/usb.c +6 -0

+       /*
+        * Set USB1_NO_LEGACY_MODE to 1, Registers are accessible under
+        * base address
+        */
+       if (id == PERIPH_ID_USBD)
+               setbits_le32(&usbctlr->usb1_legacy_ctrl, USB1_NO_LEGACY_MODE);

arch/arm/cpu/armv7/tegra2/usb.c +3 -0

+       /* Set USB3 to use UTMIP PHY */
+       if (id == PERIPH_ID_USB3)
+               setbits_le32(&usbctlr->susp_ctrl, UTMIP_PHY_ENB);

arch/arm/cpu/armv7/tegra2/usb.c +2 -0

+static void init_usb_controller(enum periph_id id, struct usb_ctlr *usbctlr,
+               const u32 timing[])

arch/arm/cpu/armv7/tegra2/usb.c line 74

Quoted 7 lines · Simon Glass

This adds basic support for the Tegra2 USB controller. Board files should call board_usb_init() to set things up.

arch/arm/cpu/armv7/tegra2/usb.c +2 -0

 
+/* Record which controller can switch from host to device mode */
+static struct fdt_usb *host_dev_ctlr;

As you'll note from my comments on the DT bindings, it doesn't make sense to have a single global variable for that; both USB1 and USB3 can switch at run-time apparently, and USB2 at initialization time.

Quoted 1 line

+void usbf_reset_controller(enum periph_id id, struct usb_ctlr *usbctlr)

...

Quoted 6 lines

+ ? ? ? /*
+ ? ? ? ?* Set USB1_NO_LEGACY_MODE to 1, Registers are accessible under
+ ? ? ? ?* base address
+ ? ? ? ?*/
+ ? ? ? if (id == PERIPH_ID_USBD)
+ ? ? ? ? ? ? ? setbits_le32(&usbctlr->usb1_legacy_ctrl, USB1_NO_LEGACY_MODE);

...

Quoted 3 lines

+ ? ? ? /* Set USB3 to use UTMIP PHY */
+ ? ? ? if (id == PERIPH_ID_USB3)
+ ? ? ? ? ? ? ? setbits_le32(&usbctlr->susp_ctrl, UTMIP_PHY_ENB);

...

Quoted 2 lines

+static void init_usb_controller(enum periph_id id, struct usb_ctlr *usbctlr,
+ ? ? ? ? ? ? ? const u32 timing[])

...

Quoted 8 lines

+ ? ? ? /*
+ ? ? ? ?* To Use the A Session Valid for cable detection logic, VBUS_WAKEUP
+ ? ? ? ?* mux must be switched to actually use a_sess_vld threshold.
+ ? ? ? ?*/
+ ? ? ? if (id == PERIPH_ID_USBD) {
+ ? ? ? ? ? ? ? clrsetbits_le32(&usbctlr->usb1_legacy_ctrl,
+ ? ? ? ? ? ? ? ? ? ? ? VBUS_SENSE_CTL_MASK, VBUS_SENSE_CTL_A_SESS_VLD);
+ ? ? ? }

Uggh. The driver shouldn't really be altering its behaviour based on knowledge of the instance number. Can those conditions be modified to test something else instead?

For the first (USBD) condition, it seems like if the registers are different, we should really have either different compatible values, or a flag in the DT to indicate this.

For the second (USB3) condition, shouldn't this be testing the phy type field, not the instance ID?

For the third (USBD) condition, can it test whether there's a VBUS GPIO defined, or whether an appropriate combination of my proposed enable-host-mode/enable-device-mode properties are present?

--
nvpublic

Quoted 4 lines · Simon Glass

This adds basic USB support for port 0. The other port is not supported yet.

board/nvidia/common/board.c +0 -0

Quoted 3 lines

+#ifdef CONFIG_USB_EHCI_TEGRA
+ ? ? /* For USB GPIO PD0. for now, since we have no pinmux in fdt */
+ ? ? pinmux_tristate_disable(PINGRP_SLXK);

Can we ifdef this so it only happens on Seaboard? Who knows what other boards use that pin group for. Unfortunately, I checked and this really does appear required for Seaboard, since there's no pull on the USB1_VBUS_EN GPIO, so Tegra must drive it.

--
nvpublic

This series brings in the Linux kernel fdt file and provides a working USB driver for Tegra2 Seaboard.

(I have done this in one series since otherwise most of the fdt additions will just look like dead code.)

The driver requires CONFIG_OF_CONTROL and a device tree to operate.

Some enhancements to fdtdec are required to make this easier, and these are included in the series also. I have had to bring in basic GPIO support due to the request to put the USB VBUS into the fdt.

Since the kernel recently got a very minimal USB binding, I have started with that and extended it where appropriate.

Tegra likes to have cache-aligned buffers. I have dropped the patch which implements this since we will solve this problem by making callers align their buffers (as we did with MMC).

Changes in v2:
- Use "okay" instead of "ok" for fdt node status
- Remove 0x from fdt aliases
- Rename params to timing
- Store entire fdt config in port list, not just register pointer
- Remove non-fdt operation of USB, since it is not needed
- Decode USB VBUS GPIO from the fdt
- Decode phy type differently (to match new kernel fdt)
- Rename tegra20-usb to tegra20-ehcui (to match new kernel fdt)
- Improve debug() printouts in case of failure to init USB
- Add setting of pinmux for USB VBUS GPIO
- Remove unneeded CONFIG_TEGRA_USBx defines

Changes in v3:
- Remove "okay" from nodes since this is the default anyway
- Fix device tree indenting with tabs instead of spaces
- Disable USB2 which is not used on Seaboard
- Remove usbparams properties from fdt and moved them to C code
- Drop Tegra USB alignment patch as we will deal with this another way

Changes in v4:
- Add staging area for device tree bindings used in U-Boot
- Add clock bindings for Tegra2x
- Add fdtdec function to return peripheral ID
- Use updated fdtdec alias functiona to get USB aliases
- Use peripheral clock node to obtain peripheral ID

Simon Glass (20):
?fdt: Tidy up a few fdtdec problems
?fdt: Add functions to access phandles, arrays and bools ?fdt: Add basic support for decoding GPIO definitions
?arm: fdt: Ensure that an embedded fdt is word-aligned ?arm: fdt: Add skeleton device tree file from kernel ?tegra: fdt: Add Tegra2x device tree file from kernel ?tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel ?fdt: Add staging area for device tree binding documentation ?fdt: Add tegra-usb bindings file from linux
?tegra: fdt: Add additional USB binding
?tegra: fdt: Add clock bindings
?tegra: usb: fdt: Add additional device tree definitions for USB ports ?tegra: usb: fdt: Add USB definitions for Tegra2 Seaboard ?usb: Add support for txfifo threshold
?fdt: Add function to return peripheral/clock ID
?tegra: usb: Add support for Tegra USB peripheral
?tegra: usb: Add USB support to nvidia boards
?tegra: usb: Add common USB defines for tegra2 boards ?tegra: usb: Enable USB on Seaboard
?tegra: fdt: Enable FDT support for Seaboard

?README ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?3 +
?arch/arm/cpu/armv7/tegra2/Makefile ? ? ? ? ? ? | ? ?4 +-
?arch/arm/cpu/armv7/tegra2/config.mk ? ? ? ? ? ?| ? ?2 +
?arch/arm/cpu/armv7/tegra2/usb.c ? ? ? ? ? ? ? ?| ?426 ++++++++++++++++++++++++
?arch/arm/cpu/armv7/u-boot.lds ? ? ? ? ? ? ? ? ?| ? ?5 +
?arch/arm/dts/skeleton.dtsi ? ? ? ? ? ? ? ? ? ? | ? 13 +
?arch/arm/dts/tegra20.dtsi ? ? ? ? ? ? ? ? ? ? ?| ?199 +++++++++++
?arch/arm/include/asm/arch-tegra2/tegra2.h ? ? ?| ? ?2 +
?arch/arm/include/asm/arch-tegra2/usb.h ? ? ? ? | ?255 ++++++++++++++
?board/nvidia/common/board.c ? ? ? ? ? ? ? ? ? ?| ? ?8 +
?board/nvidia/dts/tegra2-seaboard.dts ? ? ? ? ? | ? 47 +++
?doc/device-tree-bindings/README ? ? ? ? ? ? ? ?| ? 19 +
?doc/device-tree-bindings/clock/tegra-periphclk | ? 51 +++
?doc/device-tree-bindings/usb/tegra-usb.txt ? ? | ? 17 +
?drivers/usb/host/Makefile ? ? ? ? ? ? ? ? ? ? ?| ? ?1 +
?drivers/usb/host/ehci-hcd.c ? ? ? ? ? ? ? ? ? ?| ? ?7 +
?drivers/usb/host/ehci-tegra.c ? ? ? ? ? ? ? ? ?| ? 63 ++++
?drivers/usb/host/ehci.h ? ? ? ? ? ? ? ? ? ? ? ?| ? ?6 +-
?dts/Makefile ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ?2 +-
?include/configs/seaboard.h ? ? ? ? ? ? ? ? ? ? | ? 12 +
?include/configs/tegra2-common.h ? ? ? ? ? ? ? ?| ? 14 +
?include/fdtdec.h ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ?121 +++++++-
?lib/fdtdec.c ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ?181 ++++++++++-

?23 files changed, 1445 insertions(+), 13 deletions(-) ?create mode 100644 arch/arm/cpu/armv7/tegra2/usb.c ?create mode 100644 arch/arm/dts/skeleton.dtsi
?create mode 100644 arch/arm/dts/tegra20.dtsi
?create mode 100644 arch/arm/include/asm/arch-tegra2/usb.h ?create mode 100644 board/nvidia/dts/tegra2-seaboard.dts ?create mode 100644 doc/device-tree-bindings/README ?create mode 100644 doc/device-tree-bindings/clock/tegra-periphclk ?create mode 100644 doc/device-tree-bindings/usb/tegra-usb.txt ?create mode 100644 drivers/usb/host/ehci-tegra.c

--
1.7.7.3