Hi Claudiu,
> -----Original Message-----
> From: claudiu beznea <claudiu.beznea@xxxxxxxxx>
> 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@xxxxxxxxx>
> >> 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@xxxxxxxxxxxxxx>
> >>
> >> 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@xxxxxxxxxxxxxx>
> >> ---
> >>
> >> 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
