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@xxxxxxxxxxxxxxxxx
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@xxxxxxxx> 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@xxxxxxxx>
---
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 = <®_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
