Thread (39 messages) 39 messages, 6 authors, 2014-07-10

[PATCH v1 5/9] of: Add NVIDIA Tegra XHCI controller binding

From: Stephen Warren <hidden>
Date: 2014-06-25 23:15:01
Also in: linux-devicetree, linux-tegra, lkml

On 06/25/2014 05:02 PM, Andrew Bresticker wrote:
On Wed, Jun 25, 2014 at 2:54 PM, Stephen Warren [off-list ref] wrote:
quoted
On 06/18/2014 12:16 AM, Andrew Bresticker wrote:
quoted
Add device-tree binding documentation for the XHCI controller present
on Tegra124 and later SoCs.
quoted
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
quoted
+ - clock-names: Must include the following entries:
+    - xusb_host
+    - xusb_falcon_src
+    - xusb_ss
+    - xusb_ss_src
+    - xusb_hs_src
+    - xusb_fs_src
Looking at include/dt-bindings/clock/tegra124-car.h I see a few entries
potentially missing here:

#define TEGRA124_CLK_XUSB_HOST_SRC 252
#define TEGRA124_CLK_XUSB_DEV_SRC 256
#define TEGRA124_CLK_XUSB_DEV 257
#define TEGRA124_CLK_XUSB_SS_DIV2 312
The driver doesn't use them, so I didn't put them in the binding.
I think we should add them in case we need them later. Best to fully
describe the HW rather than the parts of the HW that SW currently uses.
quoted
quoted
+    - pll_u_480m
Not just pll_u?
We specifically want pll_u_480M as that's what we use as the parent of
xusb_ss_src when scaling it to 120Mhz.
OK. I recall text in the TRM implying that SW should just leave PLL_U
alone and not fiddle with the separate output clocks. Still, if we have
a clock ID for each output, and it's the correct parent for the clock,
then it does make sense to use that ID.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help