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

[Marek Vasut]

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, 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 ...
> 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