[PATCH v2 02/11] mfd: renesas-vbattb: Add a MFD driver for the Renesas VBATTB IP

[Biju Das]

Hi Claudiu,

> -----Original Message-----
> From: claudiu beznea <claudiu.beznea at tuxon.dev>
> Sent: Wednesday, July 17, 2024 8:46 AM
> Subject: Re: [PATCH v2 02/11] mfd: renesas-vbattb: Add a MFD driver for
> the Renesas VBATTB IP
> 
> Hi, Biju,
> 
> On 16.07.2024 14:07, Biju Das wrote:
> > Hi Claudiu,
> >
> >> -----Original Message-----
> >> From: Claudiu <claudiu.beznea at tuxon.dev>
> >> Sent: Tuesday, July 16, 2024 11:30 AM
> >> Subject: [PATCH v2 02/11] mfd: renesas-vbattb: Add a MFD driver for
> >> the Renesas VBATTB IP
> >>
> >> From: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >>
> >> Renesas VBATTB IP has logic to control the RTC clock, tamper
> >> detection and a small 128B memory. Add a MFD driver to do the basic
> initialization of the VBATTB IP for the inner components to work.
> >>
> >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj at bp.renesas.com>
> >> ---
> >>
> >> Changes in v2:
> >> - none; this driver is new
> >>
> >>  drivers/mfd/Kconfig          |  8 ++++
> >>  drivers/mfd/Makefile         |  1 +
> >>  drivers/mfd/renesas-vbattb.c | 78
> >> ++++++++++++++++++++++++++++++++++++
> >>  3 files changed, 87 insertions(+)
> >>  create mode 100644 drivers/mfd/renesas-vbattb.c
> >>
> >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index
> >> bc8be2e593b6..df93e8b05065 100644
> >> --- a/drivers/mfd/Kconfig
> >> +++ b/drivers/mfd/Kconfig
> >> @@ -1383,6 +1383,14 @@ config MFD_SC27XX_PMIC
> >>  	  This driver provides common support for accessing the SC27xx PMICs,
> >>  	  and it also adds the irq_chip parts for handling the PMIC chip
> events.
> >>
> >> +config MFD_RENESAS_VBATTB
> >> +	tristate "Renesas VBATTB driver"
> >> +	depends on (ARCH_RZG2L && OF) || COMPILE_TEST
> >> +	select MFD_CORE
> >> +	help
> >> +	  Select this option to enable Renesas RZ/G3S VBATTB driver which
> >> +	  provides support for the RTC clock, tamper detector and 128B SRAM.
> >> +
> >>  config RZ_MTU3
> >>  	tristate "Renesas RZ/G2L MTU3a core driver"
> >>  	depends on (ARCH_RZG2L && OF) || COMPILE_TEST diff --git
> >> a/drivers/mfd/Makefile b/drivers/mfd/Makefile index
> >> 02b651cd7535..cd2f27492df2 100644
> >> --- a/drivers/mfd/Makefile
> >> +++ b/drivers/mfd/Makefile
> >> @@ -186,6 +186,7 @@ pcf50633-objs			:= pcf50633-core.o
> pcf50633-irq.o
> >>  obj-$(CONFIG_MFD_PCF50633)	+= pcf50633.o
> >>  obj-$(CONFIG_PCF50633_ADC)	+= pcf50633-adc.o
> >>  obj-$(CONFIG_PCF50633_GPIO)	+= pcf50633-gpio.o
> >> +obj-$(CONFIG_MFD_RENESAS_VBATTB)	+= renesas-vbattb.o
> >>  obj-$(CONFIG_RZ_MTU3)		+= rz-mtu3.o
> >>  obj-$(CONFIG_ABX500_CORE)	+= abx500-core.o
> >>  obj-$(CONFIG_MFD_DB8500_PRCMU)	+= db8500-prcmu.o
> >> diff --git a/drivers/mfd/renesas-vbattb.c
> >> b/drivers/mfd/renesas-vbattb.c new file mode 100644 index
> >> 000000000000..5d71565b8cbf
> >> --- /dev/null
> >> +++ b/drivers/mfd/renesas-vbattb.c
> >> @@ -0,0 +1,78 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * VBATTB driver
> >> + *
> >> + * Copyright (C) 2024 Renesas Electronics Corp.
> >> + */
> >> +
> >> +#include <linux/mod_devicetable.h>
> >> +#include <linux/of_platform.h>
> >> +#include <linux/platform_device.h>
> >> +#include <linux/pm_runtime.h>
> >> +#include <linux/reset.h>
> >> +
> >> +static int vbattb_probe(struct platform_device *pdev) {
> >> +	struct device *dev = &pdev->dev;
> >> +	struct reset_control *rstc;
> >> +	int ret;
> >> +
> >> +	rstc = devm_reset_control_array_get_exclusive(dev);
> >> +	if (IS_ERR(rstc))
> >> +		return PTR_ERR(rstc);
> >> +
> >> +	ret = devm_pm_runtime_enable(dev);
> >> +	if (ret)
> >> +		return ret;
> >> +
> >> +	ret = pm_runtime_resume_and_get(dev);
> >> +	if (ret)
> >> +		return ret;
> >
> > Maybe as an optimization drop pm calls and use "devm_clk_get_enabled"
> > instead as it perfectly fits in this scenario??
> 
> VBATTB is still part of a PM domain. That needs to be enabled as well.
> pm_runtime_* APIs takes care of both clock enable and power domain on
> operations.
> 
> One thing to notice is that on RZ/G3S the VBATTB clock is CRITICAL (thus
> enabled in the probe of the clock driver), the PM domain is always ON (and
> also enabled by clock driver). We can get rid of pm_runtime_* at all for
> RZ/G3S but I think it would be better to have it here as well for future
> platforms and to emphasize from driver that these resources are needed by
> the VBATTB. The same approach is used for  other RZ/G2 drivers that
> declares critical clocks/always-on domains (e.g. dma driver, IA55 driver).


If it is critical clock, the parent has to be critical clock. So you can blindly
use devm_clk_get_enabled() that simplifies probe(), if the PM domain controls only clock.


If the PM domain controls voltage means you should use PM domain APIs

Cheers,
Biju