On 06/25/2014 05:02 PM, Andrew Bresticker wrote: > On Wed, Jun 25, 2014 at 2:54 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: >> On 06/18/2014 12:16 AM, Andrew Bresticker wrote: >>> Add device-tree binding documentation for the XHCI controller present >>> on Tegra124 and later SoCs. >> >>> diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt >> >>> + - 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. >>> + - 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. -- 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
