Hi Felipe & Rob,
On 05/25/2016 04:04 PM, Felipe Balbi wrote:
Hi,
William Wu <william.wu@xxxxxxxxxxxxxx> writes:
Hi Felipe,
On 05/24/2016 05:32 PM, Felipe Balbi wrote:
Hi,
William Wu <william.wu@xxxxxxxxxxxxxx> writes:
This patch documents the device tree documentation required for
Rockchip USB3.0 core wrapper consist of USB3.0 IP from Synopsys.
It could operate in device mode (SS, HS, FS) and host
mode (SS, HS, FS, LS).
Signed-off-by: William Wu <william.wu@xxxxxxxxxxxxxx>
---
Changes in v2:
- add rockchip,dwc3.txt to Documentation/devicetree/bindings/ (Felipe, Brian)
.../devicetree/bindings/usb/rockchip,dwc3.txt | 45 ++++++++++++++++++++++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
new file mode 100644
index 0000000..10303d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
@@ -0,0 +1,45 @@
+Rockchip SuperSpeed DWC3 USB SoC controller
+
+Required properties:
+- compatible: should contain "rockchip,dwc3"
+- clocks: A list of phandle + clock-specifier pairs for the
+ clocks listed in clock-names
+- clock-names: Should contain the following:
+ "clk_usb3otg0_ref" Controller reference clk
+ "clk_usb3otg0_suspend"Controller suspend clk, can use 24 MHz or 32 KHz
+ "aclk_usb3" Master/Core clock, have to be >= 62.5 MHz for SS operation
+
+
+Optional clocks:
+ "aclk_usb3otg0" Aclk for specific usb controller clock.
+ "aclk_usb3_rksoc_axi_perf" USB AXI perf clock. Not present on all platforms.
+ "aclk_usb3_grf" USB grf clock. Not present on all platforms.
+
+Required child node:
+A child node must exist to represent the core DWC3 IP block. The name of
+the node is not important. The content of the node is defined in dwc3.txt.
+
+Phy documentation is provided in the following places:
+
+Example device nodes:
+
+ usbdrd3_0: usb@fe800000 {
+
no reg property?
For now, we don't need reg property here. Because we only need to do
enable some clocks and populate its children in
drivers/usb/dwc3/dwc3-of-simple.c.
And it's similar to arch/arm/boot/dts/exynos5420.dtsi usbdrd3_0 node.
compatible = "rockchip,dwc3";
+ clocks = <&cru SCLK_USB3OTG0_REF>, <&cru SCLK_USB3OTG0_SUSPEND>,
+ <&cru ACLK_USB3>, <&cru ACLK_USB3OTG0>,
+ <&cru ACLK_USB3_RKSOC_AXI_PERF>, <&cru ACLK_USB3_GRF>;
+ clock-names = "clk_usb3otg0_ref", "clk_usb3otg0_suspend",
+ "aclk_usb3", "aclk_usb3otg0",
+ "aclk_usb3_rksoc_axi_perf", "aclk_usb3_grf";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+ usbdrd_dwc3_0: dwc3 {
no address here?
I think here don't necessarily need address. The child node dwc3 can
inherit address from the parent node.
And with this dtsi patch, the dev path show as follows:
/sys/devices/platform/usb@fe800000/fe800000.dwc3
Is it need for coding style or other reason?
I don't think your arguments match what devicetree folks want to see in
DT. Let's ask them. Rob, care to look at this one?
Sorry, I need to correct myself. I have done some test, and the result
shows that
the child node dwc3 don't inherit address from the parent node, but get
address
from its reg property. And It seems that whether I add address here or
not, the
dwc3 node always get address from reg property.
However, I don't know much about the DT. But I think it's better to add
address here than no.
+ compatible = "snps,dwc3";
+ reg = <0x0 0xfe800000 0x0 0x100000>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "otg";
+ status = "disabled";
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
