Re: [PATCH 2/2] ARM: dts: USB for Tegra114 Dalmore

From: Sergei Shtylyov
Date: Wed Jul 31 2013 - 18:20:07 EST

On 08/01/2013 02:06 AM, Stephen Warren wrote:

Device tree entries for the three EHCI controllers on Tegra114.
Enables the the third controller (USB host) on Dalmore.

diff --git a/arch/arm/boot/dts/tegra114.dtsi
index abf6c40..2905145 100644
--- a/arch/arm/boot/dts/tegra114.dtsi
+++ b/arch/arm/boot/dts/tegra114.dtsi
@@ -430,6 +430,68 @@
status = "disable";

+ usb@7d000000 {
+ compatible = "nvidia,tegra30-ehci", "usb-ehci";
+ reg = <0x7d000000 0x4000>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ phy_type = "utmi";
+ clocks = <&tegra_car TEGRA114_CLK_USBD>;
+ nvidia,phy = <&phy1>;
+ status = "disabled";
+ };
+ phy1: usb-phy@7d000000 {

At the same address as the previous node?

Yes. The first node is for the EHCI driver and the second for the PHY
There is some overlap in the exact registers used, so both drives map the
whole USB controller block.

That's really horrible design.

Yup. Both USB PHY and EHCI controller registers really are interleaved
in one range.

But the standard EHCI register space has no holes IIRC, so they can't be really that much interleaved as you're describing (unless you have some non-standard registers of course)...
We just had a case of misinterpreting the EHCI/PHY register spaces as interleaved (while in fact they weren't) on Renesas R-Car which I had to resolve for 3.11.

+ compatible = "nvidia,tegra30-usb-phy";
+ reg = <0x7d000000 0x4000 0x7d000000 0x4000>;

Hm, there must be some mistake: two similar register ranges.

The second range is used to configure the UTMI pad registers. All the
UTMI pad
registers are located in the first USB controller's range.

Which second range? This is one and the same range.

Some registers in the USB1 register range actually are "global" and
relevant to all USB controllers. So:

There are two 2-cell entries in that reg property. The first entry
defines the registers for this USB PHY, and hence is unique for each USB
PHY node. The second defines the registers for whichever USB PHY
contains various shared registers across multiple PHYs, so is expected
to be identical across all USB PHY DT nodes.

Hm, couldn't you have those shared registers as a separate device?

Yes, the HW design really is this screwy.


Don't they cause numerous resource conflicts while device nodes being
instantiated as the platform devices?

No; the driver knows that the HW is screwy and there's lots of
register-range sharing going on, so it simply maps the registers, rather
than reserving the physical address range and mapping it.

Yes, it's clear that the driver should take special measures, I was asking about the platform device creation phase. What do you see in /proc/iomem?

WBR, Sergei

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at