Re: [PATCH v2 2/2] arm64: dts: mediatek: add Kontron 3.5"-SBC-i1200

Michael Walle
2024-02-19T13:59:29Z

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

On Mon Feb 19, 2024 at 2:35 PM CET, AngeloGioacchino Del Regno wrote:
> >> vbus is always supplied by something, as otherwise USB won't work - whether this
> >> is an always-on regulator or a passthrough from external supply this doesn't really
> >> matter - you should model a regulator-fixed that provides the 5V VBUS line.
> >
> > I don't think this is correct, though. Think of an on-board USB
> > hub. There only D+/D- are connected (and maybe the USB3.2 SerDes
> > lanes). Or have a look at the M.2 pinout. There is no Vbus.
> >
>
> Yes but the MediaTek MTU3 and/or controllers do have it ;-)

.. and ..

> >> For example:
> >> vbus_fixed: regulator-vbus {
> >> compatible = "regulator-fixed";
> >> regulator-name = "usb-vbus";
> >> regulator-always-on;
> >> regulator-boot-on;
> >> regulator-min-microvolt = <5000000>;
> >> regulator-max-microvolt = <5000000>;
> >> };
> >
> > As mentioned above, I don't think this will make sense in my case.
> > >> P.S.: If the rail has a different name, please use that different name. Obviously
> >> that requires you to have schematics at hand, and I don't know if you do: if you
> >> don't, then that regulator-vbus name is just fine.
> >
> > I do have the schematics.
>
> In that case, you should model the power tree with the fixed power lines,
> check mt8195-cherry (and/or cherry-tomato) and radxa-nio-12l; even though
> those are technically "doing nothing", this is device tree, so it should
> provide a description of the hardware ... and the board does have fixed
> power lines.
> It has at least one: DC-IN (typec, barrel jack or whatever, the board needs
> power, doesn't it?!).

Mh, maybe I don't get it. But within the hardware there is simply no
Vbus. Thus I'd argue it doesn't make sense to have a vbus-supply
property. Besides, the mediatek,mtu3.yaml binding lists it as
deprecated anyway and it should rather be on the connector. There,
it makes perfectly sense (at least if it's a USB connector).

Thus in my case, the xhci for the front port has a vbus-supply
property (but it should rather have a connector node, as I've just
learned). But the internal port which connects to the USB hub
shouldn't have one.

+-----+ +-----+ +------+
| |<--Dp/Dn-->| |<------Dp/Dn----->| USB |
| SoC | | | | Conn |
| | | | +-----+ | |
+-----+ | USB | | PWR |--Vbus->| |
| Hub | | SW | +------+
| | +-----+
| | ^
| | | PRTPWR
| |-----'
+-----+

"PWR SW" is a power switch, the input (+5V) isn't shown here. The
power will be enabled by the USB Hub.

-michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 252 bytes --]