From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that is used
by the RTC. The input to the VBATTB could be a 32KHz crystal
or an external clock device.
The HW block diagram for the clock generator is as follows:
+----------+ XC `\
RTXIN --->| |----->| \ +----+ VBATTCLK
| 32K clock| | |----->|gate|----------->
| osc | XBYP | | +----+
RTXOUT --->| |----->| /
+----------+ ,
After discussions w/ Stephen Boyd the clock tree associated with this
hardware block was exported in Linux as:
vbattb-xtal
xbyp
xc
mux
vbattbclk
where:
- input-xtal is the input clock (connected to RTXIN, RTXOUT pins)
- xc, xbyp are mux inputs
- mux is the internal mux
- vbattclk is the gate clock that feeds in the end the RTC
to allow selecting the input of the MUX though assigned-clock DT
properties, using the already existing clock drivers and avoid adding
other DT properties. If the crystal is connected on RTXIN,
RTXOUT pins the XC will be selected as mux input. If an external clock
device is connected on RTXIN, RTXOUT pins the XBYP will be selected as
mux input.
The load capacitance of the internal crystal can be configured
with renesas,vbattb-load-nanofarads DT property.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
---
Changes in v5:
- collected tags
Changes in v4:
- dropped oscillator from patch description
- s/on-board/internal in patch description
- updated dt-binding included file name in the driver as it has been
renamed to include/dt-bindings/clock/renesas,r9a08g045-vbattb.h
- dropped the "_BIT" from driver macros
- used "quartz-load-femtofarads" dt property instead of adding a new one
- register the "vbattclk" as critical clock as this feeds the RTC counter
logic and it needs to stay on from the moment the RTC is configured;
along with it, added a comment to express this.
Changes in v3:
- updated patch description
- dropped dependency on MFD_RENESAS_VBATTB as now there is no
driver built under this flag
- dropped include/clk.h
- added pm_runtime and reset control support
- updated register offsets
- registered 4 clocks: xc, xbyp, mux, vbattclk using generic
clock drivers
- added MODULE_DEVICE_TABLE()
Changes in v2:
- updated patch description
- added vendor name in Kconfig flag
- used cleanup.h lock helpers
- dropped the MFD code
- updated registers offsets
- added vbattb_clk_update_bits() and used it where possible
- added vbattb_clk_need_bypass() to detect the bypass setup necessity
- changed the compatible and driver names
drivers/clk/renesas/Kconfig | 4 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/clk-vbattb.c | 205 +++++++++++++++++++++++++++++++
3 files changed, 210 insertions(+)
create mode 100644 drivers/clk/renesas/clk-vbattb.c
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index 76791a1c50ac..4e835a3f1ab4 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -237,6 +237,10 @@ config CLK_RZV2H
bool "RZ/V2H(P) family clock support" if COMPILE_TEST
select RESET_CONTROLLER
+config CLK_RENESAS_VBATTB
+ bool "Renesas VBATTB clock controller"
+ select RESET_CONTROLLER
+
# Generic
config CLK_RENESAS_CPG_MSSR
bool "CPG/MSSR clock support" if COMPILE_TEST
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index 23d2e26051c8..82efaa835ac7 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -53,3 +53,4 @@ obj-$(CONFIG_CLK_RZV2H) += rzv2h-cpg.o
obj-$(CONFIG_CLK_RENESAS_CPG_MSSR) += renesas-cpg-mssr.o
obj-$(CONFIG_CLK_RENESAS_CPG_MSTP) += clk-mstp.o
obj-$(CONFIG_CLK_RENESAS_DIV6) += clk-div6.o
+obj-$(CONFIG_CLK_RENESAS_VBATTB) += clk-vbattb.o
diff --git a/drivers/clk/renesas/clk-vbattb.c b/drivers/clk/renesas/clk-vbattb.c
new file mode 100644
index 000000000000..ff9d1ead455c
--- /dev/null
+++ b/drivers/clk/renesas/clk-vbattb.c
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * VBATTB clock driver
+ *
+ * Copyright (C) 2024 Renesas Electronics Corp.
+ */
+
+#include <linux/cleanup.h>
+#include <linux/clk-provider.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/mod_devicetable.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/reset.h>
+
+#include <dt-bindings/clock/renesas,r9a08g045-vbattb.h>
+
+#define VBATTB_BKSCCR 0x1c
+#define VBATTB_BKSCCR_SOSEL 6
+#define VBATTB_SOSCCR2 0x24
+#define VBATTB_SOSCCR2_SOSTP2 0
+#define VBATTB_XOSCCR 0x30
+#define VBATTB_XOSCCR_OUTEN 16
+#define VBATTB_XOSCCR_XSEL GENMASK(1, 0)
+#define VBATTB_XOSCCR_XSEL_4_PF 0x0
+#define VBATTB_XOSCCR_XSEL_7_PF 0x1
+#define VBATTB_XOSCCR_XSEL_9_PF 0x2
+#define VBATTB_XOSCCR_XSEL_12_5_PF 0x3
+
+/**
+ * struct vbattb_clk - VBATTB clock data structure
+ * @base: base address
+ * @lock: lock
+ */
+struct vbattb_clk {
+ void __iomem *base;
+ spinlock_t lock;
+};
+
+static int vbattb_clk_validate_load_capacitance(u32 *reg_lc, u32 of_lc)
+{
+ switch (of_lc) {
+ case 4000:
+ *reg_lc = VBATTB_XOSCCR_XSEL_4_PF;
+ break;
+ case 7000:
+ *reg_lc = VBATTB_XOSCCR_XSEL_7_PF;
+ break;
+ case 9000:
+ *reg_lc = VBATTB_XOSCCR_XSEL_9_PF;
+ break;
+ case 12500:
+ *reg_lc = VBATTB_XOSCCR_XSEL_12_5_PF;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static void vbattb_clk_action(void *data)
+{
+ struct device *dev = data;
+ struct reset_control *rstc = dev_get_drvdata(dev);
+ int ret;
+
+ ret = reset_control_assert(rstc);
+ if (ret)
+ dev_err(dev, "Failed to de-assert reset!");
+
+ ret = pm_runtime_put_sync(dev);
+ if (ret < 0)
+ dev_err(dev, "Failed to runtime suspend!");
+
+ of_clk_del_provider(dev->of_node);
+}
+
+static int vbattb_clk_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct clk_parent_data parent_data = {};
+ struct clk_hw_onecell_data *clk_data;
+ const struct clk_hw *parent_hws[2];
+ struct device *dev = &pdev->dev;
+ struct reset_control *rstc;
+ struct vbattb_clk *vbclk;
+ u32 of_lc, reg_lc;
+ struct clk_hw *hw;
+ /* 4 clocks are exported: VBATTB_XC, VBATTB_XBYP, VBATTB_MUX, VBATTB_VBATTCLK. */
+ u8 num_clks = 4;
+ int ret;
+
+ /* Default to 4pF as this is not needed if external clock device is connected. */
+ of_lc = 4000;
+ of_property_read_u32(np, "quartz-load-femtofarads", &of_lc);
+
+ ret = vbattb_clk_validate_load_capacitance(®_lc, of_lc);
+ if (ret)
+ return ret;
+
+ vbclk = devm_kzalloc(dev, sizeof(*vbclk), GFP_KERNEL);
+ if (!vbclk)
+ return -ENOMEM;
+
+ clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, num_clks), GFP_KERNEL);
+ if (!clk_data)
+ return -ENOMEM;
+ clk_data->num = num_clks;
+
+ vbclk->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(vbclk->base))
+ return PTR_ERR(vbclk->base);
+
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return ret;
+
+ rstc = devm_reset_control_get_shared(dev, NULL);
+ if (IS_ERR(rstc))
+ return PTR_ERR(rstc);
+
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret)
+ return ret;
+
+ ret = reset_control_deassert(rstc);
+ if (ret) {
+ pm_runtime_put_sync(dev);
+ return ret;
+ }
+
+ dev_set_drvdata(dev, rstc);
+ ret = devm_add_action_or_reset(dev, vbattb_clk_action, dev);
+ if (ret)
+ return ret;
+
+ spin_lock_init(&vbclk->lock);
+
+ parent_data.fw_name = "rtx";
+ hw = devm_clk_hw_register_gate_parent_data(dev, "xc", &parent_data, 0,
+ vbclk->base + VBATTB_SOSCCR2,
+ VBATTB_SOSCCR2_SOSTP2,
+ CLK_GATE_SET_TO_DISABLE, &vbclk->lock);
+ if (IS_ERR(hw))
+ return PTR_ERR(hw);
+ clk_data->hws[VBATTB_XC] = hw;
+
+ hw = devm_clk_hw_register_fixed_factor_fwname(dev, np, "xbyp", "rtx", 0, 1, 1);
+ if (IS_ERR(hw))
+ return PTR_ERR(hw);
+ clk_data->hws[VBATTB_XBYP] = hw;
+
+ parent_hws[0] = clk_data->hws[VBATTB_XC];
+ parent_hws[1] = clk_data->hws[VBATTB_XBYP];
+ hw = devm_clk_hw_register_mux_parent_hws(dev, "mux", parent_hws, 2, 0,
+ vbclk->base + VBATTB_BKSCCR,
+ VBATTB_BKSCCR_SOSEL,
+ 1, 0, &vbclk->lock);
+ if (IS_ERR(hw))
+ return PTR_ERR(hw);
+ clk_data->hws[VBATTB_MUX] = hw;
+
+ /* Set load capacitance before registering the VBATTCLK clock. */
+ scoped_guard(spinlock, &vbclk->lock) {
+ u32 val = readl_relaxed(vbclk->base + VBATTB_XOSCCR);
+
+ val &= ~VBATTB_XOSCCR_XSEL;
+ val |= reg_lc;
+ writel_relaxed(val, vbclk->base + VBATTB_XOSCCR);
+ }
+
+ /* This feeds the RTC counter clock and it needs to stay on. */
+ hw = devm_clk_hw_register_gate_parent_hw(dev, "vbattclk", hw, CLK_IS_CRITICAL,
+ vbclk->base + VBATTB_XOSCCR,
+ VBATTB_XOSCCR_OUTEN, 0,
+ &vbclk->lock);
+
+ if (IS_ERR(hw))
+ return PTR_ERR(hw);
+ clk_data->hws[VBATTB_VBATTCLK] = hw;
+
+ return of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_data);
+}
+
+static const struct of_device_id vbattb_clk_match[] = {
+ { .compatible = "renesas,r9a08g045-vbattb" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, vbattb_clk_match);
+
+static struct platform_driver vbattb_clk_driver = {
+ .driver = {
+ .name = "renesas-vbattb-clk",
+ .of_match_table = vbattb_clk_match,
+ },
+ .probe = vbattb_clk_probe,
+};
+module_platform_driver(vbattb_clk_driver);
+
+MODULE_DESCRIPTION("Renesas VBATTB Clock Driver");
+MODULE_AUTHOR("Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>");
+MODULE_LICENSE("GPL");
--
2.39.2On Wed, Oct 30, 2024 at 01:01:13PM +0200, Claudiu wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that is used
> by the RTC. The input to the VBATTB could be a 32KHz crystal
> or an external clock device.
>
> The HW block diagram for the clock generator is as follows:
>
> +----------+ XC `\
> RTXIN --->| |----->| \ +----+ VBATTCLK
> | 32K clock| | |----->|gate|----------->
> | osc | XBYP | | +----+
> RTXOUT --->| |----->| /
> +----------+ ,
>
> After discussions w/ Stephen Boyd the clock tree associated with this
> hardware block was exported in Linux as:
>
> vbattb-xtal
> xbyp
> xc
> mux
> vbattbclk
>
> where:
> - input-xtal is the input clock (connected to RTXIN, RTXOUT pins)
> - xc, xbyp are mux inputs
> - mux is the internal mux
> - vbattclk is the gate clock that feeds in the end the RTC
>
> to allow selecting the input of the MUX though assigned-clock DT
> properties, using the already existing clock drivers and avoid adding
> other DT properties. If the crystal is connected on RTXIN,
> RTXOUT pins the XC will be selected as mux input. If an external clock
> device is connected on RTXIN, RTXOUT pins the XBYP will be selected as
> mux input.
>
> The load capacitance of the internal crystal can be configured
> with renesas,vbattb-load-nanofarads DT property.
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> ---
>
> Changes in v5:
> - collected tags
>
> Changes in v4:
> - dropped oscillator from patch description
> - s/on-board/internal in patch description
> - updated dt-binding included file name in the driver as it has been
> renamed to include/dt-bindings/clock/renesas,r9a08g045-vbattb.h
> - dropped the "_BIT" from driver macros
> - used "quartz-load-femtofarads" dt property instead of adding a new one
> - register the "vbattclk" as critical clock as this feeds the RTC counter
> logic and it needs to stay on from the moment the RTC is configured;
> along with it, added a comment to express this.
>
> Changes in v3:
> - updated patch description
> - dropped dependency on MFD_RENESAS_VBATTB as now there is no
> driver built under this flag
> - dropped include/clk.h
> - added pm_runtime and reset control support
> - updated register offsets
> - registered 4 clocks: xc, xbyp, mux, vbattclk using generic
> clock drivers
> - added MODULE_DEVICE_TABLE()
>
> Changes in v2:
> - updated patch description
> - added vendor name in Kconfig flag
> - used cleanup.h lock helpers
> - dropped the MFD code
> - updated registers offsets
> - added vbattb_clk_update_bits() and used it where possible
> - added vbattb_clk_need_bypass() to detect the bypass setup necessity
> - changed the compatible and driver names
>
>
> drivers/clk/renesas/Kconfig | 4 +
> drivers/clk/renesas/Makefile | 1 +
> drivers/clk/renesas/clk-vbattb.c | 205 +++++++++++++++++++++++++++++++
> 3 files changed, 210 insertions(+)
> create mode 100644 drivers/clk/renesas/clk-vbattb.c
>
> diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
> index 76791a1c50ac..4e835a3f1ab4 100644
> --- a/drivers/clk/renesas/Kconfig
> +++ b/drivers/clk/renesas/Kconfig
> @@ -237,6 +237,10 @@ config CLK_RZV2H
> bool "RZ/V2H(P) family clock support" if COMPILE_TEST
> select RESET_CONTROLLER
>
> +config CLK_RENESAS_VBATTB
> + bool "Renesas VBATTB clock controller"
tristate
> + select RESET_CONTROLLER
> +
...
> +
> +static const struct of_device_id vbattb_clk_match[] = {
> + { .compatible = "renesas,r9a08g045-vbattb" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, vbattb_clk_match);
> +
> +static struct platform_driver vbattb_clk_driver = {
> + .driver = {
> + .name = "renesas-vbattb-clk",
> + .of_match_table = vbattb_clk_match,
> + },
> + .probe = vbattb_clk_probe,
> +};
> +module_platform_driver(vbattb_clk_driver);
That's a module, isn't it?
> +
> +MODULE_DESCRIPTION("Renesas VBATTB Clock Driver");
> +MODULE_AUTHOR("Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>");
> +MODULE_LICENSE("GPL");
> --
> 2.39.2
>
Hi Krzysztof,
On Thu, Oct 31, 2024 at 8:48 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, Oct 30, 2024 at 01:01:13PM +0200, Claudiu wrote:
> > From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> >
> > The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that is used
> > by the RTC. The input to the VBATTB could be a 32KHz crystal
> > or an external clock device.
> >
> > The HW block diagram for the clock generator is as follows:
> >
> > +----------+ XC `\
> > RTXIN --->| |----->| \ +----+ VBATTCLK
> > | 32K clock| | |----->|gate|----------->
> > | osc | XBYP | | +----+
> > RTXOUT --->| |----->| /
> > +----------+ ,
> >
> > After discussions w/ Stephen Boyd the clock tree associated with this
> > hardware block was exported in Linux as:
> >
> > vbattb-xtal
> > xbyp
> > xc
> > mux
> > vbattbclk
> >
> > where:
> > - input-xtal is the input clock (connected to RTXIN, RTXOUT pins)
> > - xc, xbyp are mux inputs
> > - mux is the internal mux
> > - vbattclk is the gate clock that feeds in the end the RTC
> >
> > to allow selecting the input of the MUX though assigned-clock DT
> > properties, using the already existing clock drivers and avoid adding
> > other DT properties. If the crystal is connected on RTXIN,
> > RTXOUT pins the XC will be selected as mux input. If an external clock
> > device is connected on RTXIN, RTXOUT pins the XBYP will be selected as
> > mux input.
> >
> > The load capacitance of the internal crystal can be configured
> > with renesas,vbattb-load-nanofarads DT property.
> >
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> > --- a/drivers/clk/renesas/Kconfig
> > +++ b/drivers/clk/renesas/Kconfig
> > @@ -237,6 +237,10 @@ config CLK_RZV2H
> > bool "RZ/V2H(P) family clock support" if COMPILE_TEST
> > select RESET_CONTROLLER
> >
> > +config CLK_RENESAS_VBATTB
> > + bool "Renesas VBATTB clock controller"
>
> tristate
Good point.
However, does it work as a module, or would that break the RTC?
And this is missing
depends on ARCH_RENESAS || COMPILE_TEST
which I can add while applying.
>
> > + select RESET_CONTROLLER
> > +
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi, Geert, Krzysztof,
On 31.10.2024 10:43, Geert Uytterhoeven wrote:
> Hi Krzysztof,
>
> On Thu, Oct 31, 2024 at 8:48 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Wed, Oct 30, 2024 at 01:01:13PM +0200, Claudiu wrote:
>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>
>>> The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that is used
>>> by the RTC. The input to the VBATTB could be a 32KHz crystal
>>> or an external clock device.
>>>
>>> The HW block diagram for the clock generator is as follows:
>>>
>>> +----------+ XC `\
>>> RTXIN --->| |----->| \ +----+ VBATTCLK
>>> | 32K clock| | |----->|gate|----------->
>>> | osc | XBYP | | +----+
>>> RTXOUT --->| |----->| /
>>> +----------+ ,
>>>
>>> After discussions w/ Stephen Boyd the clock tree associated with this
>>> hardware block was exported in Linux as:
>>>
>>> vbattb-xtal
>>> xbyp
>>> xc
>>> mux
>>> vbattbclk
>>>
>>> where:
>>> - input-xtal is the input clock (connected to RTXIN, RTXOUT pins)
>>> - xc, xbyp are mux inputs
>>> - mux is the internal mux
>>> - vbattclk is the gate clock that feeds in the end the RTC
>>>
>>> to allow selecting the input of the MUX though assigned-clock DT
>>> properties, using the already existing clock drivers and avoid adding
>>> other DT properties. If the crystal is connected on RTXIN,
>>> RTXOUT pins the XC will be selected as mux input. If an external clock
>>> device is connected on RTXIN, RTXOUT pins the XBYP will be selected as
>>> mux input.
>>>
>>> The load capacitance of the internal crystal can be configured
>>> with renesas,vbattb-load-nanofarads DT property.
>>>
>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
>>> --- a/drivers/clk/renesas/Kconfig
>>> +++ b/drivers/clk/renesas/Kconfig
>>> @@ -237,6 +237,10 @@ config CLK_RZV2H
>>> bool "RZ/V2H(P) family clock support" if COMPILE_TEST
>>> select RESET_CONTROLLER
>>>
>>> +config CLK_RENESAS_VBATTB
>>> + bool "Renesas VBATTB clock controller"
>>
>> tristate
>
> Good point.
> However, does it work as a module, or would that break the RTC?
On RZ/G3S the RTC counter needs the clock provided by VBATTB.
I'll try with this as a module.
>
> And this is missing
>
> depends on ARCH_RENESAS || COMPILE_TEST
>
> which I can add while applying.
Thank you!
Claudiu
>
>>
>>> + select RESET_CONTROLLER
>>> +
>
> Gr{oetje,eeting}s,
>
> Geert
>
On 31/10/2024 10:26, Claudiu Beznea wrote: > Hi, Geert, Krzysztof, > > On 31.10.2024 10:43, Geert Uytterhoeven wrote: >> Hi Krzysztof, >> >> On Thu, Oct 31, 2024 at 8:48 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>> On Wed, Oct 30, 2024 at 01:01:13PM +0200, Claudiu wrote: >>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> >>>> >>>> The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that is used >>>> by the RTC. The input to the VBATTB could be a 32KHz crystal >>>> or an external clock device. >>>> >>>> The HW block diagram for the clock generator is as follows: >>>> >>>> +----------+ XC `\ >>>> RTXIN --->| |----->| \ +----+ VBATTCLK >>>> | 32K clock| | |----->|gate|-----------> >>>> | osc | XBYP | | +----+ >>>> RTXOUT --->| |----->| / >>>> +----------+ , >>>> >>>> After discussions w/ Stephen Boyd the clock tree associated with this >>>> hardware block was exported in Linux as: >>>> >>>> vbattb-xtal >>>> xbyp >>>> xc >>>> mux >>>> vbattbclk >>>> >>>> where: >>>> - input-xtal is the input clock (connected to RTXIN, RTXOUT pins) >>>> - xc, xbyp are mux inputs >>>> - mux is the internal mux >>>> - vbattclk is the gate clock that feeds in the end the RTC >>>> >>>> to allow selecting the input of the MUX though assigned-clock DT >>>> properties, using the already existing clock drivers and avoid adding >>>> other DT properties. If the crystal is connected on RTXIN, >>>> RTXOUT pins the XC will be selected as mux input. If an external clock >>>> device is connected on RTXIN, RTXOUT pins the XBYP will be selected as >>>> mux input. >>>> >>>> The load capacitance of the internal crystal can be configured >>>> with renesas,vbattb-load-nanofarads DT property. >>>> >>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> >>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> >> >>>> --- a/drivers/clk/renesas/Kconfig >>>> +++ b/drivers/clk/renesas/Kconfig >>>> @@ -237,6 +237,10 @@ config CLK_RZV2H >>>> bool "RZ/V2H(P) family clock support" if COMPILE_TEST >>>> select RESET_CONTROLLER >>>> >>>> +config CLK_RENESAS_VBATTB >>>> + bool "Renesas VBATTB clock controller" >>> >>> tristate >> >> Good point. >> However, does it work as a module, or would that break the RTC? > > On RZ/G3S the RTC counter needs the clock provided by VBATTB. > > I'll try with this as a module. So it will defer, why would this be a problem? This does not look like critical core component, which would halt the system probe (and even then systems like Android put everything as modules). Best regards, Krzysztof
On 31.10.2024 11:46, Krzysztof Kozlowski wrote: > On 31/10/2024 10:26, Claudiu Beznea wrote: >> Hi, Geert, Krzysztof, >> >> On 31.10.2024 10:43, Geert Uytterhoeven wrote: >>> Hi Krzysztof, >>> >>> On Thu, Oct 31, 2024 at 8:48 AM Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>> On Wed, Oct 30, 2024 at 01:01:13PM +0200, Claudiu wrote: >>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> >>>>> >>>>> The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that is used >>>>> by the RTC. The input to the VBATTB could be a 32KHz crystal >>>>> or an external clock device. >>>>> >>>>> The HW block diagram for the clock generator is as follows: >>>>> >>>>> +----------+ XC `\ >>>>> RTXIN --->| |----->| \ +----+ VBATTCLK >>>>> | 32K clock| | |----->|gate|-----------> >>>>> | osc | XBYP | | +----+ >>>>> RTXOUT --->| |----->| / >>>>> +----------+ , >>>>> >>>>> After discussions w/ Stephen Boyd the clock tree associated with this >>>>> hardware block was exported in Linux as: >>>>> >>>>> vbattb-xtal >>>>> xbyp >>>>> xc >>>>> mux >>>>> vbattbclk >>>>> >>>>> where: >>>>> - input-xtal is the input clock (connected to RTXIN, RTXOUT pins) >>>>> - xc, xbyp are mux inputs >>>>> - mux is the internal mux >>>>> - vbattclk is the gate clock that feeds in the end the RTC >>>>> >>>>> to allow selecting the input of the MUX though assigned-clock DT >>>>> properties, using the already existing clock drivers and avoid adding >>>>> other DT properties. If the crystal is connected on RTXIN, >>>>> RTXOUT pins the XC will be selected as mux input. If an external clock >>>>> device is connected on RTXIN, RTXOUT pins the XBYP will be selected as >>>>> mux input. >>>>> >>>>> The load capacitance of the internal crystal can be configured >>>>> with renesas,vbattb-load-nanofarads DT property. >>>>> >>>>> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> >>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> >>> >>>>> --- a/drivers/clk/renesas/Kconfig >>>>> +++ b/drivers/clk/renesas/Kconfig >>>>> @@ -237,6 +237,10 @@ config CLK_RZV2H >>>>> bool "RZ/V2H(P) family clock support" if COMPILE_TEST >>>>> select RESET_CONTROLLER >>>>> >>>>> +config CLK_RENESAS_VBATTB >>>>> + bool "Renesas VBATTB clock controller" >>>> >>>> tristate >>> >>> Good point. >>> However, does it work as a module, or would that break the RTC? >> >> On RZ/G3S the RTC counter needs the clock provided by VBATTB. >> >> I'll try with this as a module. > > So it will defer, why would this be a problem? This does not look like No problems with it. I wrongly phrased it. That being said, I'll set CLK_RENESAS_VBATTB as module along with RTC and do the proper adjustments in drivers/clk/renesas/Kconfig. Thank you, Claudiu > critical core component, which would halt the system probe (and even > then systems like Android put everything as modules). > > Best regards, > Krzysztof >
© 2016 - 2024 Red Hat, Inc.