[U-Boot] [PATCH v5 4/6] mvebu: usb: xhci: Add VBUS regulator supply to the host driver

[Marek Vasut]

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, kostap at marvell.com wrote:
>> >>>>> From: Konstantin Porotchkin <kostap at 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 <kostap at marvell.com>
>> >>>>> Cc: Stefan Roese <sr at denx.de>
>> >>>>> Cc: Marek Vasut <marex at denx.de>
>> >>>>> Cc: Nadav Haklai <nadavh at marvell.com>
>> >>>>> Cc: Neta Zur Hershkovits <neta at marvell.com>
>> >>>>> Cc: Igal Liberman <igall at marvell.com>
>> >>>>> Cc: Haim Boot <hayim at 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 <marex at 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