Message-ID:
 <TY3PR01MB1134612B0952B267BE89E686F86E0A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Tue, 7 Oct 2025 15:20:19 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Philipp Zabel <p.zabel@...gutronix.de>, Tommaso Merciai
	<tommaso.merciai.xr@...renesas.com>, Tommaso Merciai <tomm.merciai@...il.com>
CC: "linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, Vinod Koul
	<vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>, Geert
 Uytterhoeven <geert+renesas@...der.be>, magnus.damm <magnus.damm@...il.com>,
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>, Prabhakar Mahadev Lad
	<prabhakar.mahadev-lad.rj@...renesas.com>, "linux-phy@...ts.infradead.org"
	<linux-phy@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL register for OTG
 mode

Hi Philipp,

> -----Original Message-----
> From: Philipp Zabel <p.zabel@...gutronix.de>
> Sent: 07 October 2025 15:13
> Subject: Re: [PATCH 04/18] reset: rzv2h-usb2phy: Set VBENCTL register for OTG mode
> 
> Hi Biju,
> 
> On Di, 2025-10-07 at 11:04 +0000, Biju Das wrote:
> > Hi Philipp,
> >
> > > -----Original Message-----
> > > From: Philipp Zabel <p.zabel@...gutronix.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@...gutronix.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@...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-hardw
> > are?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).

My Bad. I rechecked the link and confirm what you said is correct.
I am using NDA document.

> 
> > > > > 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.

OK.

> 
> > 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.

Will check this and update you.

Cheers,
Biju

Powered by blists - more mailing lists