Re: [PATCH v2] usb: dwc3: Add support for VBUS power control

[Mike Looijmans <mike.looijmans@topic.nl>]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 17-06-2020 19:28, Mike Looijmans wrote:
> On 17-06-2020 18:13, Rob Herring wrote:
>> On Wed, Jun 17, 2020 at 8:38 AM Mike Looijmans 
>> <mike.looijmans@topic.nl> wrote:
>>> On 10-06-2020 22:22, Rob Herring wrote:
>>>> On Wed, Jun 03, 2020 at 02:09:15PM +0200, Mike Looijmans wrote:
>>>>> Support VBUS power control using regulator framework. Enables the 
>>>>> regulator
>>>>> while the port is in host mode.
>>>>>
>>>>> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
>>>>> ---
>>>>> v2: Add missing devm_regulator_get call which got lost during rebase
>>>>>
>>>>>    .../devicetree/bindings/usb/dwc3.txt          |  1 +
>>>>>    drivers/usb/dwc3/core.c                       | 34 
>>>>> ++++++++++++++-----
>>>>>    drivers/usb/dwc3/core.h                       |  4 +++
>>>>>    drivers/usb/dwc3/drd.c                        |  6 ++--
>>>>>    4 files changed, 33 insertions(+), 12 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
>>>>> b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>> index 9946ff9ba735..56bc3f238e2d 100644
>>>>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>>>>> @@ -37,6 +37,7 @@ Optional properties:
>>>>>     - phys: from the *Generic PHY* bindings
>>>>>     - phy-names: from the *Generic PHY* bindings; supported names 
>>>>> are "usb2-phy"
>>>>>       or "usb3-phy".
>>>>> + - vbus-supply: Regulator handle that provides the VBUS power.
>>>> Does the DWC3 block require Vbus to power itself? Doubtful. This
>>>> belongs in a usb-connector node. If the DWC3 driver wants to get the
>>>> Vbus supply, it can fetch it from that node.
>>>>
>>>> Rob
>>> Okay, I've been digging into that. But there's no actual driver that
>>> binds to a "usb-b-connector" compatible, so how do we get to the
>>> vbus-supply from there?
>>>
>>> [devm_]regulator_get only accepts a device as argument, and will not
>>> look into child nodes. The only way to get at the vbus of a child node
>>> (or a node linked through a port) would be to hand-code the equivalent
>>> of of_regulator_get(), which will not be acceptable.
>> Doesn't it look into child nodes calling of_get_child_regulator()?
> Looking at the code in regulator/core.c, yeah, it should. I'll have to 
> add some debugging lines and look into why it didn't work in my test.

Ah, I had put my "connector" child in the wrong node. If I add the 
following fragment to the dwc3 node, the vbus patch works:

     connector {
         compatible = "usb-b-connector";
         label = "micro-USB-otg";
         type = "micro";
         vbus-supply = <&reg_usb0_vbus>;
     };

The driver indeed picks up the vbus supply from a child node.

This would mean there's no change to the devicetree bindings, it's using 
already existing bindings.

>> You're right that it wouldn't work if graph is used. The connector has
>> to be either a child of a controller for the connector or the USB
>> controller. I'd expect you'd have the former for Type-C, but for
>> "usb-b-connector" the parent is more likely just the USB controller.
> For my current case, using a direct child would be fine, there's 
> nothing else connected. But I expect that we'll produce a board with 
> some USB-C connector some day yeah.
>>
>> In any case, having a struct device shouldn't be a requirement and
>> most subsystems expose a get function only needing the DT node.
>>
>>> Or is it the intention that I write a usb-X-connector device driver
>>> first that handles the vbus?
>> That's a kernel implementation detail that is independent of the
>> binding, but yes we'll probably need a driver or library helper
>> functions eventually. Note that it is possible to have a struct device
>> without a driver.
>>
>> Rob
>
>

-- 
Mike Looijmans