From: Philipp Zabel <p.zabel@pengutronix.de>
To: Biju Das <biju.das.jz@bp.renesas.com>,
Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>,
Tommaso Merciai <tomm.merciai@gmail.com>
Cc: "linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
"magnus.damm" <magnus.damm@gmail.com>,
Fabrizio Castro <fabrizio.castro.jz@renesas.com>,
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>,
"linux-phy@lists.infradead.org" <linux-phy@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL register for OTG mode
Date: Tue, 07 Oct 2025 16:13:02 +0200 [thread overview]
Message-ID: <988658d3485232a0bb6c433b6533ebf0ae41226a.camel@pengutronix.de> (raw)
In-Reply-To: <TY3PR01MB1134623A14F4F313986F631ED86E0A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Hi Biju,
On Di, 2025-10-07 at 11:04 +0000, Biju Das wrote:
> Hi Philipp,
>
> > -----Original Message-----
> > From: Philipp Zabel <p.zabel@pengutronix.de>
> > Sent: 07 October 2025 10:44
> > Subject: Re: [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL register for OTG mode
> >
> > Hi Biju,
> >
> > On Di, 2025-10-07 at 04:02 +0000, Biju Das wrote:
> > > Hi Philipp,
> > >
> > > Thanks for the feedback.
> > >
> > > > -----Original Message-----
> > > > From: Philipp Zabel <p.zabel@pengutronix.de>
> > > > Sent: 06 October 2025 17:32
> > > > Subject: Re: [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL
> > > > register for OTG mode
> > > >
> > > > On Mi, 2025-10-01 at 23:26 +0200, Tommaso Merciai wrote:
> > > > > Add logic to set the VBENCTL register when the USB controller
> > > > > operates in OTG mode. This is required to ensure proper USB
> > > > > transceiver behavior when the device is configured as OTG.
> > > > >
> > > > > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > > >
> > > > I had reservations about this driver before, because of the opaque
> > > > register initialization sequence, and I was told that no, this is a reset driver alright [1].
> > >
> > > The latest hardware manual document about VBENCTRL register which sets source for VBUS selection.
> > > s
> >
> > I still can't look at this, right? The USB2PHY control register space appears to be documented in
> > the "RZ/V2H Group User's Manual: Hardware (Additional document)" (under NDA).
>
> It is documented here[1], Page 2177, USB2PHY Control Register (USB2m_PHY_VBENCTL)
>
> [1]
> https://www.renesas.com/en/document/mah/rzg3e-group-users-manual-hardware?r=25574493
For me, that link points to a document without the USB2m_PHY_* register
definitions. Page 2177 is unrelated (documenting PCI_EP_HLOG2_Fn,
somewhere in the PCIe interface chapter).
> > > > Can you please try to find a proper abstraction for this, because
> > > > drivers/reset is not the correct place for USB OTG mode handling.
> > >
> > > Sorry for the confusion. This driver is not handling USB OTG mode. It
> > > just configures VBENCTRL(one time setting) that selects the source for
> > > VBUS_SEL. Actual USB OTG mode handling is done USB PHY driver which sets host/device mode based on
> > ID detection.
> >
> > So this is a mux for the VBUS_SEL signal?
>
> Yes, Please find the bit definition.
>
> 0 VBUS_SEL 0h RW Select VBUSEN control
> 0b: Output PP controlled by PORTSC1 register of the Host Controller as VBUSEN.
> 1b: Output VBOUT controlled by VBCTRL register of the Host Controller as VBUSEN.
>
> We have USB PHY control driver(This driver)-> USB PHY driver->| USB HOST(Generic ehci/ohci)
> | USB function (renesas usbhs)
>
> We plan to set 1b for this IP in this driver for OTG channel during probe.
> After that using VBOUT register the PHY driver can switch between Host and device.
Thank you for the explanation.
> > Why don't the USB host controller drivers parse their "dr_mode"
> > property themselves and control USB2PHY VBENCTRL via the mux API, for example?
>
> Currently for OTG channel, based ID detection IRQ, the USB PHY driver switches between host
> and device. We use method2 below for the host operation.
>
> For Host operation:
> Method1: USB2m_PHY_VBENCTL.VBUS_SEL=0
> or
> method2: USB2m_PHY_VBENCTL.VBUS_SEL=1 and USB_HOST_VBCTRL.VBOUT = 1
>
> For device operation:
> USB2m_PHY_VBENCTL.VBUS_SEL=1 and USB_HOST_VBCTRL.VBOUT = 0
>
> Are you suggesting to use method1(mux) for host operation?
No, not necessarily. I was thinking of letting the PHY driver, before
registering the VBOUT controlled VBUS regulator in its probe function,
call into the mux API to set VBENCTL.VBUS_SEL=1 and thus make the VBOUT
bit functional.
> Currently this is one time configuration. If we plan to
> use mux, then it becomes dynamic.
>
> How we can we make use of PHY driver using mux API to select the mux register(VBUS_SEL)
> in USB PHY control Driver?
For example, this driver could spawn an auxiliary mux device with a
driver in drivers/mux that registers a mux for VBENCTL.VBUS_SEL on the
&usb20phyrst node.
The phy could then get a "mux-states = <&usb20phyrst 1>;" property in
its device tree node and call the equivalent of:
mux_state = devm_mux_state_get_optional(dev, NULL);
mux_state_select(mux_state);
to switch to VBOUT controlled VBUSEN.
regards
Philipp
next prev parent reply other threads:[~2025-10-07 14:13 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 21:26 [PATCH 00/18] Add USB2.0 support for RZ/G3E Tommaso Merciai
2025-10-01 21:26 ` [PATCH 01/18] phy: renesas: rcar-gen3-usb2: Use devm_pm_runtime_enable() Tommaso Merciai
2025-10-01 21:26 ` [PATCH 02/18] phy: renesas: rcar-gen3-usb2: Factor out VBUS control logic Tommaso Merciai
2025-10-01 21:26 ` [PATCH 03/18] reset: rzv2h-usb2phy: Simplify pm_runtime driver handling Tommaso Merciai
2025-10-06 16:21 ` Philipp Zabel
2025-10-07 7:01 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL register for OTG mode Tommaso Merciai
2025-10-06 16:31 ` Philipp Zabel
2025-10-07 4:02 ` Biju Das
2025-10-07 9:44 ` Philipp Zabel
2025-10-07 11:04 ` Biju Das
2025-10-07 14:13 ` Philipp Zabel [this message]
2025-10-07 15:20 ` Biju Das
2025-10-01 21:26 ` [PATCH 05/18] dt-bindings: phy: renesas,usb2-phy: Document USB VBUS regulator Tommaso Merciai
2025-10-01 21:26 ` [PATCH 06/18] phy: renesas: rcar-gen3-usb2: Add regulator for OTG VBUS control Tommaso Merciai
2025-10-01 21:26 ` [PATCH 07/18] regulator: devres: Disable exclusive regulator before releasing Tommaso Merciai
2025-10-02 16:29 ` Mark Brown
2025-10-03 17:33 ` Tommaso Merciai
2025-10-06 11:52 ` Mark Brown
2025-10-06 12:53 ` Tommaso Merciai
2025-10-01 21:26 ` [PATCH 08/18] dt-bindings: clock: renesas,r9a09g047-cpg: Add USB2 PHY core clocks Tommaso Merciai
2025-10-09 13:48 ` Geert Uytterhoeven
2025-10-01 21:26 ` [PATCH 09/18] clk: renesas: r9a09g047: Add clock and reset entries for USB2 Tommaso Merciai
2025-10-09 13:49 ` Geert Uytterhoeven
2025-10-01 21:26 ` [PATCH 10/18] dt-bindings: usb: renesas,usbhs: Add RZ/G3E SoC support Tommaso Merciai
2025-10-01 21:26 ` [PATCH 11/18] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3E SoC Tommaso Merciai
2025-10-01 21:26 ` [PATCH 12/18] dt-bindings: reset: Document RZ/G3E USB2PHY reset Tommaso Merciai
2025-10-01 21:26 ` [PATCH 13/18] arm64: dts: renesas: r9a09g056: Add USB2.0 PHY VBUS internal regulator node Tommaso Merciai
2025-10-01 21:26 ` [PATCH 14/18] arm64: dts: renesas: r9a09g056n48-rzv2n-evk: Enable USB2 PHY0 VBUS support Tommaso Merciai
2025-10-01 21:26 ` [PATCH 15/18] arm64: dts: renesas: r9a09g057: Add USB2.0 PHY VBUS internal regulator node Tommaso Merciai
2025-10-01 21:27 ` [PATCH 16/18] arm64: dts: renesas: r9a09g057h44-rzv2h-evk: Enable USB2 PHY0 VBUS support Tommaso Merciai
2025-10-01 21:27 ` [PATCH 17/18] arm64: dts: renesas: r9a09g047: Add USB2.0 support Tommaso Merciai
2025-10-01 21:27 ` [PATCH 18/18] arm64: dts: renesas: r9a09g047e57-smarc: Enable " Tommaso Merciai
2025-10-02 18:48 ` [PATCH 00/18] Add USB2.0 support for RZ/G3E Conor Dooley
2025-10-03 10:03 ` Tommaso Merciai
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=988658d3485232a0bb6c433b6533ebf0ae41226a.camel@pengutronix.de \
--to=p.zabel@pengutronix.de \
--cc=biju.das.jz@bp.renesas.com \
--cc=fabrizio.castro.jz@renesas.com \
--cc=geert+renesas@glider.be \
--cc=kishon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=tomm.merciai@gmail.com \
--cc=tommaso.merciai.xr@bp.renesas.com \
--cc=vkoul@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®