From: "Michael Walle" <mwalle@kernel.org>
To: "AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>
Cc: <devicetree@vger.kernel.org>,
"Sean Wang" <sean.wang@mediatek.com>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH v2 2/2] arm64: dts: mediatek: add Kontron 3.5"-SBC-i1200
Date: Mon, 19 Feb 2024 14:59:16 +0100 [thread overview]
Message-ID: <CZ93XYV3MB10.YRCFWLLHIICY@kernel.org> (raw)
In-Reply-To: <b50d49fd-2976-46fc-9f35-354fb39720ad@collabora.com>
[-- 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 --]
WARNING: multiple messages have this Message-ID (diff)
From: "Michael Walle" <mwalle@kernel.org>
To: "AngeloGioacchino Del Regno"
<angelogioacchino.delregno@collabora.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Matthias Brugger" <matthias.bgg@gmail.com>
Cc: <devicetree@vger.kernel.org>,
"Sean Wang" <sean.wang@mediatek.com>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH v2 2/2] arm64: dts: mediatek: add Kontron 3.5"-SBC-i1200
Date: Mon, 19 Feb 2024 14:59:16 +0100 [thread overview]
Message-ID: <CZ93XYV3MB10.YRCFWLLHIICY@kernel.org> (raw)
In-Reply-To: <b50d49fd-2976-46fc-9f35-354fb39720ad@collabora.com>
[-- Attachment #1.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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-19 13:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 8:44 [PATCH v2 1/2] dt-bindings: arm64: mediatek: add Kontron 3.5"-SBC-i1200 Michael Walle
2024-02-19 8:44 ` Michael Walle
2024-02-19 8:44 ` [PATCH v2 2/2] arm64: dts: " Michael Walle
2024-02-19 8:44 ` Michael Walle
2024-02-19 10:00 ` AngeloGioacchino Del Regno
2024-02-19 10:00 ` AngeloGioacchino Del Regno
2024-02-19 13:09 ` Michael Walle
2024-02-19 13:09 ` Michael Walle
2024-02-19 13:35 ` AngeloGioacchino Del Regno
2024-02-19 13:35 ` AngeloGioacchino Del Regno
2024-02-19 13:59 ` Michael Walle [this message]
2024-02-19 13:59 ` Michael Walle
2024-02-20 8:54 ` AngeloGioacchino Del Regno
2024-02-20 8:54 ` AngeloGioacchino Del Regno
2024-02-19 9:06 ` [PATCH v2 1/2] dt-bindings: arm64: " Krzysztof Kozlowski
2024-02-19 9:06 ` Krzysztof Kozlowski
2024-02-19 9:25 ` Michael Walle
2024-02-19 9:25 ` Michael Walle
2024-02-19 9:23 ` AngeloGioacchino Del Regno
2024-02-19 9:23 ` AngeloGioacchino Del Regno
2024-02-19 9:36 ` Michael Walle
2024-02-19 9:36 ` Michael Walle
2024-02-19 10:07 ` AngeloGioacchino Del Regno
2024-02-19 10:07 ` AngeloGioacchino Del Regno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CZ93XYV3MB10.YRCFWLLHIICY@kernel.org \
--to=mwalle@kernel.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=robh@kernel.org \
--cc=sean.wang@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.