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 ... -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot