mbox series

[v4,0/6] Add USB VBUS regulator for RZ/G2L

Message ID 20240616105402.45211-1-biju.das.jz@bp.renesas.com (mailing list archive)
Headers show
Series Add USB VBUS regulator for RZ/G2L | expand

Message

Biju Das June 16, 2024, 10:53 a.m. UTC
As per RZ/G2L HW manual, VBUS enable can be controlled by the VBOUT bit of
the VBUS Control Register(VBENCTL) register in the USBPHY Control. But
this IP is in the Reset block.

Reset driver exposes this register as regmap and instantiate the USB VBUS
regulator device. Consumers(phy device) can use regulator APIs to control
VBUS as controlling is done in the atomic context.

We need to have merge strategy which subsytem will apply this patches
as it involves multiple subsystems Reset, Regulator, PHY, DT and Renesas
SoC??

v3->v4:
 * Fixed example indentation to 4 char spaces in patch#1
 * Dropped regulator-{min,max}-microvolt from example.
 * Updated commit header and description in patch#3
 * Replaced regulator_set_hardware_enable_register()->regulator_hardware_enable()
 * Updated documentation to "must use of regulator_get_exclusive() for consumers"
 * Enforced exclusive access in regulator_hardware_enable().
 * Added generic support regulator_hardware_enable().
 * Added check for of_get_child_by_name().
 * Released the resource by of_node_put()
 * Updated commit description with regulator_hardware_enable()
 * Used devm_regulator_get_exclusive() to get regulator handle.
 * Dropped regulator-{min,max}-microvolt.
v2->v3:
 * Documented regulator-vbus in the binding file.
 * Updated commit description and header for patch#2
 * Moved regulator device creation and instantiation at the end of probe().
 * Introduced new API regulator_set_hardware_enable_register() to enable/disable
   regulator in atomic context.
 * Dropped vbus_voltages table from patch#4
 * Added support for enabling/disabling regulator through regmap API's
 * Updated rzg2l_usb_vbus_rdesc with enable_{reg,mask}, fixed_uV and
   n_voltages
 * Updated of_node with child node of the parent device.
 * Replaced regulator's regmap API with newly introduced
   regulator_set_hardware_enable_register to enable/disable regulator
   in interrupt context in patch#5
 * Dropped using "usb_vbus-supply" in patch#5.
 * Upated vbus regulator label name in dts file.
 * Updated node and regulator name that matches with the binding documentation.
v1->v2:
 * Introduced a regulator driver to control VBUS

Biju Das (6):
  dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document USB VBUS
    regulator
  reset: renesas: Add USB VBUS regulator device as child
  regulator: core: Add helper for allow HW access to enable/disable
    regulator
  regulator: Add Renesas RZ/G2L USB VBUS regulator driver
  phy: renesas: phy-rcar-gen3-usb2: Control VBUS for RZ/G2L SoCs
  arm64: dts: renesas: rz-smarc: Replace fixed regulator for USB VBUS

 .../reset/renesas,rzg2l-usbphy-ctrl.yaml      | 10 +++
 Documentation/power/regulator/consumer.rst    |  6 ++
 .../boot/dts/renesas/rz-smarc-common.dtsi     | 11 +--
 drivers/phy/renesas/phy-rcar-gen3-usb2.c      |  8 +-
 drivers/regulator/Kconfig                     |  9 +++
 drivers/regulator/Makefile                    |  1 +
 drivers/regulator/core.c                      | 28 +++++++
 .../regulator/renesas-usb-vbus-regulator.c    | 74 +++++++++++++++++++
 drivers/reset/reset-rzg2l-usbphy-ctrl.c       | 37 ++++++++++
 include/linux/regulator/consumer.h            |  7 ++
 10 files changed, 182 insertions(+), 9 deletions(-)
 create mode 100644 drivers/regulator/renesas-usb-vbus-regulator.c

Comments

Vinod Koul June 20, 2024, 4:37 p.m. UTC | #1
On 16-06-24, 11:53, Biju Das wrote:
> As per RZ/G2L HW manual, VBUS enable can be controlled by the VBOUT bit of
> the VBUS Control Register(VBENCTL) register in the USBPHY Control. But
> this IP is in the Reset block.
> 
> Reset driver exposes this register as regmap and instantiate the USB VBUS
> regulator device. Consumers(phy device) can use regulator APIs to control
> VBUS as controlling is done in the atomic context.
> 
> We need to have merge strategy which subsytem will apply this patches
> as it involves multiple subsystems Reset, Regulator, PHY, DT and Renesas
> SoC??

Why is there a dependency.. why cant they go thru respective trees?
Biju Das June 20, 2024, 5:11 p.m. UTC | #2
Hi Vinod,

Thanks for the feedback.

> -----Original Message-----
> From: Vinod Koul <vkoul@kernel.org>
> Sent: Thursday, June 20, 2024 5:38 PM
> Subject: Re: [PATCH v4 0/6] Add USB VBUS regulator for RZ/G2L
> 
> On 16-06-24, 11:53, Biju Das wrote:
> > As per RZ/G2L HW manual, VBUS enable can be controlled by the VBOUT
> > bit of the VBUS Control Register(VBENCTL) register in the USBPHY
> > Control. But this IP is in the Reset block.
> >
> > Reset driver exposes this register as regmap and instantiate the USB
> > VBUS regulator device. Consumers(phy device) can use regulator APIs to
> > control VBUS as controlling is done in the atomic context.
> >
> > We need to have merge strategy which subsytem will apply this patches
> > as it involves multiple subsystems Reset, Regulator, PHY, DT and
> > Renesas SoC??
> 
> Why is there a dependency.. why cant they go thru respective trees?

In this series, only regulator driver changes has no dependency.

PHY driver (phy-rcar-gen3-usb2.c) has a dependency on new regulator consumer API regulator_hardware_enable(),
Without this it will lead to compilation error.

USB PHY ctrl driver(reset-rzg2l-usbphy-ctrl.c) instantiate and bind regulator driver(renesas-usb-vbus-regulator.c).

If regulator driver is not there means, USB PHY ctrl driver probe() fails,
that will break existing USB functionality.

Cheers,
Biju
Mark Brown June 27, 2024, 11:17 a.m. UTC | #3
On Sun, 16 Jun 2024 11:53:52 +0100, Biju Das wrote:
> As per RZ/G2L HW manual, VBUS enable can be controlled by the VBOUT bit of
> the VBUS Control Register(VBENCTL) register in the USBPHY Control. But
> this IP is in the Reset block.
> 
> Reset driver exposes this register as regmap and instantiate the USB VBUS
> regulator device. Consumers(phy device) can use regulator APIs to control
> VBUS as controlling is done in the atomic context.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next

Thanks!

[3/6] regulator: core: Add helper for allow HW access to enable/disable regulator
      commit: 1cb7d29157603561af4c38535e936850ceb99f0f
[4/6] regulator: Add Renesas RZ/G2L USB VBUS regulator driver
      commit: 84fbd6198766336f627ba08f073fd9970729074e

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark