On 02/09/2017 08:06 PM, Konstantin Porotchkin wrote: > > > On 02/09/2017 07:24 PM, Marek Vasut wrote: >> On 02/09/2017 05:43 PM, Konstantin Porotchkin wrote: >>> >>> On 02/09/2017 06:15 PM, Marek Vasut wrote: >>>> On 02/09/2017 04:54 PM, Konstantin Porotchkin wrote: >>>>> >>>>> On 02/09/2017 05:36 PM, Marek Vasut wrote: >>>>>> On 02/09/2017 04:30 PM, Konstantin Porotchkin wrote: >>>>>>> >>>>>>> >>>>>>> On 02/09/2017 03:37 PM, Marek Vasut wrote: >>>>>>>> On 02/09/2017 12:32 PM, kos...@marvell.com wrote: >>>>>>>>> From: Konstantin Porotchkin <kos...@marvell.com> >>>>>>>>> >>>>>>>>> The USB device should linked to VBUS regulator through >>>> "vbus-supply" >>>>>>>>> DTS property. >>>>>>>>> This patch adds handling for "vbus-supply" property inside the USB >>>>>>>>> device entry for turning on the VBUS regulator upon the host >>>> adapter >>>>>>>>> probe. >>>>>>>>> >>>>>>>>> Signed-off-by: Konstantin Porotchkin <kos...@marvell.com> >>>>>>>>> Cc: Stefan Roese <s...@denx.de> >>>>>>>>> Cc: Marek Vasut <ma...@denx.de> >>>>>>>>> Cc: Nadav Haklai <nad...@marvell.com> >>>>>>>>> Cc: Neta Zur Hershkovits <n...@marvell.com> >>>>>>>>> Cc: Igal Liberman <ig...@marvell.com> >>>>>>>>> Cc: Haim Boot <ha...@marvell.com> >>>>>>>>> --- >>>>>>>>> Changes for v5: >>>>>>>>> - Extended clocks description in documentation >>>>>>>>> - Removed print for regulator not found case >>>>>>>>> >>>>>>>>> doc/device-tree-bindings/usb/marvell.xhci-usb.txt | 29 >>>>>>>>> +++++++++++++++++++++++ >>>>>>>>> drivers/usb/host/Kconfig | 1 + >>>>>>>>> drivers/usb/host/xhci-mvebu.c | 13 +++++++++- >>>>>>>>> 3 files changed, 42 insertions(+), 1 deletion(-) >>>>>>>>> create mode 100644 >>>> doc/device-tree-bindings/usb/marvell.xhci-usb.txt >>>>>>>>> >>>>>>>>> diff --git a/doc/device-tree-bindings/usb/marvell.xhci-usb.txt >>>>>>>>> b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt >>>>>>>>> new file mode 100644 >>>>>>>>> index 0000000..6cc370c >>>>>>>>> --- /dev/null >>>>>>>>> +++ b/doc/device-tree-bindings/usb/marvell.xhci-usb.txt >>>>>>>>> @@ -0,0 +1,29 @@ >>>>>>>>> +Marvell SOC USB controllers >>>>>>>>> + >>>>>>>>> +This controller is integrated in Armada 3700/8K. >>>>>>>>> +It uses the same properties as a generic XHCI host controller >>>>>>>>> + >>>>>>>>> +Required properties : >>>>>>>>> + - compatible: should be one or more of: >>>>>>>>> + - "marvell,armada3700-xhci", "generic-xhci" for Armada 37xx >>>> SoCs >>>>>>>>> + - "marvell,armada-8k-xhci", "generic-xhci" for Armada A8K SoCs >>>>>>>>> + - reg: should contain address and length of the standard XHCI >>>>>>>>> + register set for the device. >>>>>>>>> + - interrupts: one XHCI interrupt should be described here. >>>>>>>>> + >>>>>>>>> +Optional properties: >>>>>>>>> + - clocks: reference to a platform clocks that should be >>>>>>>>> enabled/configured >>>>>>>>> + upon interface initialization. May not exist on all platforms. >>>>>>>> >>>>>>>> This is probably block clock then ? >>>>>>>> >>>>>>>> Otherwise, >>>>>>>> Acked-by: Marek Vasut <ma...@denx.de> >>>>>>> Otherwise the the internal SoC clock does not require >>>> gating/muxing or >>>>>>> any other configuration for making this USB host adapter running. >>>>>>> Not sure if I understood your question well. >>>>>> >>>>>> Well, do these clock drive the USB block or do they drive the >>>> register >>>>>> interface or what ? >>>>> This entry is generic and applicable to all XHCI controllers, so it is >>>>> hard to answer your question. It supposes to be a clock that drives >>>> the >>>>> data transfer. It can be directly connected to the internal clock >>>>> generator and divider or pass though an additional gate/mux. In the >>>> last >>>>> case it can be inhibited or redirected. >>>> >>>> So it's a PHY clock then ? Or XHCI block clock ? >>>> >>>> marvell.xhci-usb.txt probably doesn't contain generic stuff, but >>>> marvell >>>> XHCI implementation specific stuff, right ? >>> No, in this particular case this entry is generic. That is why I >>> proposed to remove it in the past. >>> For the purpose of mvebu XHCI driver this entry is not required. >>> In general and in Marvell case particularly, every unit is driven by >>> some kind of internal clock. >> >> And those internal clock can never ever be gated ? That's some odd >> design, I would not expect that on an advanced ARM chip ... I guess >> marvell is not power conscious ? :) The example contradicts what you >> just said though, it points into some clock module ... > Yes, it can be gated. It is a gated clock coming from system controller. > This XHCI driver supports two different SoC families, so the real clock > names may vary. > Please help me to understand what is missing in this description? > Should I add "this clock is a gated unit clock driven by system > controller" to th description? > Should I drop this description file and submit it in a separate patch?
Something like "phandle to system controller clock for this block" would do then, or something ... -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
