| Message ID | 20240716103025.1198495-4-claudiu.beznea.uj@bp.renesas.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | Add RTC support for the Renesas RZ/G3S SoC | expand |
Quoting Claudiu (2024-07-16 03:30:17) > diff --git a/drivers/clk/renesas/clk-vbattb.c b/drivers/clk/renesas/clk-vbattb.c > new file mode 100644 > index 000000000000..8effe141fc0b > --- /dev/null > +++ b/drivers/clk/renesas/clk-vbattb.c > @@ -0,0 +1,212 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * VBATTB clock driver > + * > + * Copyright (C) 2024 Renesas Electronics Corp. > + */ > + > +#include <linux/cleanup.h> > +#include <linux/clk.h> Prefer clk providers to not be clk consumers. > +#include <linux/clk-provider.h> > +#include <linux/device.h> > +#include <linux/io.h> > +#include <linux/of.h> > +#include <linux/of_platform.h> Is of_platform.h used? Include mod_devicetable.h for of_device_id. > +#include <linux/platform_device.h> > + > +#define VBATTB_BKSCCR 0x0 > +#define VBATTB_BKSCCR_SOSEL BIT(6) > +#define VBATTB_SOSCCR2 0x8 > +#define VBATTB_SOSCCR2_SOSTP2 BIT(0) [..] > + > +static int vbattb_clk_probe(struct platform_device *pdev) > +{ > + struct device_node *np = pdev->dev.of_node; > + struct clk_parent_data parent_data = {}; > + struct device *dev = &pdev->dev; > + struct clk_init_data init = {}; > + struct vbattb_clk *vbclk; > + u32 load_capacitance; > + struct clk_hw *hw; > + int ret, bypass; > + > + vbclk = devm_kzalloc(dev, sizeof(*vbclk), GFP_KERNEL); > + if (!vbclk) > + return -ENOMEM; > + > + vbclk->base = devm_platform_ioremap_resource(pdev, 0); > + if (IS_ERR(vbclk->base)) > + return PTR_ERR(vbclk->base); > + > + bypass = vbattb_clk_need_bypass(dev); This is a tri-state bool :( > + if (bypass < 0) { > + return bypass; > + } else if (bypass) { > + parent_data.fw_name = "clkin"; > + bypass = VBATTB_BKSCCR_SOSEL; And now it is a mask value. > + } else { > + parent_data.fw_name = "xin"; > + } > + > + ret = of_property_read_u32(np, "renesas,vbattb-load-nanofarads", &load_capacitance); > + if (ret) > + return ret; > + > + ret = vbattb_clk_validate_load_capacitance(vbclk, load_capacitance); > + if (ret) > + return ret; > + > + vbattb_clk_update_bits(vbclk->base, VBATTB_BKSCCR, VBATTB_BKSCCR_SOSEL, bypass); Please don't overload 'bypass'. Use two variables or a conditional. I also wonder if this is really a mux, and either assigned-clock-parents should be used, or the clk_ops should have an init routine that looks at which parent is present by determining the index and then use that to set the mux. The framework can take care of failing to set the other parent when it isn't present. > + > + spin_lock_init(&vbclk->lock); > + > + init.name = "vbattclk"; > + init.ops = &vbattb_clk_ops; > + init.parent_data = &parent_data; > + init.num_parents = 1; > + init.flags = 0; > + > + vbclk->hw.init = &init; > + hw = &vbclk->hw; > + > + ret = devm_clk_hw_register(dev, hw); > + if (ret) > + return ret; > + > + return of_clk_add_hw_provider(np, of_clk_hw_simple_get, hw); > +} > + > +static const struct of_device_id vbattb_clk_match[] = { > + { .compatible = "renesas,r9a08g045-vbattb-clk" }, > + { /* sentinel */ } > +}; Any MODULE_DEVICE_TABLE?
Hi, Stephen, On 17.07.2024 01:28, Stephen Boyd wrote: > Quoting Claudiu (2024-07-16 03:30:17) >> diff --git a/drivers/clk/renesas/clk-vbattb.c b/drivers/clk/renesas/clk-vbattb.c >> new file mode 100644 >> index 000000000000..8effe141fc0b >> --- /dev/null >> +++ b/drivers/clk/renesas/clk-vbattb.c >> @@ -0,0 +1,212 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * VBATTB clock driver >> + * >> + * Copyright (C) 2024 Renesas Electronics Corp. >> + */ >> + >> +#include <linux/cleanup.h> >> +#include <linux/clk.h> > > Prefer clk providers to not be clk consumers. I added it here to be able to use devm_clk_get_optional() as it was proposed to me in v1 to avoid adding a new binding for bypass and detect if it's needed by checking the input clock name. > >> +#include <linux/clk-provider.h> >> +#include <linux/device.h> >> +#include <linux/io.h> >> +#include <linux/of.h> >> +#include <linux/of_platform.h> > > Is of_platform.h used? > > Include mod_devicetable.h for of_device_id. Ok. > >> +#include <linux/platform_device.h> >> + >> +#define VBATTB_BKSCCR 0x0 >> +#define VBATTB_BKSCCR_SOSEL BIT(6) >> +#define VBATTB_SOSCCR2 0x8 >> +#define VBATTB_SOSCCR2_SOSTP2 BIT(0) > [..] >> + >> +static int vbattb_clk_probe(struct platform_device *pdev) >> +{ >> + struct device_node *np = pdev->dev.of_node; >> + struct clk_parent_data parent_data = {}; >> + struct device *dev = &pdev->dev; >> + struct clk_init_data init = {}; >> + struct vbattb_clk *vbclk; >> + u32 load_capacitance; >> + struct clk_hw *hw; >> + int ret, bypass; >> + >> + vbclk = devm_kzalloc(dev, sizeof(*vbclk), GFP_KERNEL); >> + if (!vbclk) >> + return -ENOMEM; >> + >> + vbclk->base = devm_platform_ioremap_resource(pdev, 0); >> + if (IS_ERR(vbclk->base)) >> + return PTR_ERR(vbclk->base); >> + >> + bypass = vbattb_clk_need_bypass(dev); > > This is a tri-state bool :( > >> + if (bypass < 0) { >> + return bypass; >> + } else if (bypass) { >> + parent_data.fw_name = "clkin"; >> + bypass = VBATTB_BKSCCR_SOSEL; > > And now it is a mask value. > >> + } else { >> + parent_data.fw_name = "xin"; >> + } >> + >> + ret = of_property_read_u32(np, "renesas,vbattb-load-nanofarads", &load_capacitance); >> + if (ret) >> + return ret; >> + >> + ret = vbattb_clk_validate_load_capacitance(vbclk, load_capacitance); >> + if (ret) >> + return ret; >> + >> + vbattb_clk_update_bits(vbclk->base, VBATTB_BKSCCR, VBATTB_BKSCCR_SOSEL, bypass); > > Please don't overload 'bypass'. Use two variables or a conditional. OK. > > I also wonder if this is really a mux, It's a way to determine what type of clock (crystal oscillator or device clock) is connected to RTXIN/RTXOUT pins of the module (the module block diagram at [1]) based on the clock name. Depending on the type of the clock connected to RTXIN/RTXOUT we need to select the XC or XBYP as input for the mux at [1]. [1] https://gcdnb.pbrd.co/images/QYsCvhfQlX6n.png > and either assigned-clock-parents should be used, > or the clk_ops should have an init routine that looks at > which parent is present by determining the index and then use that to > set the mux. The framework can take care of failing to set the other > parent when it isn't present. On the board, at any moment, it will be only one clock as input to the VBATTB clock (either crystal oscillator or a clock device). If I'm getting you correctly, this will involve describing both clocks in some scenarios. E.g. if want to use crystal osc, I can use this DT description: vbattclk: clock-controller@1c { compatible = "renesas,r9a08g045-vbattb-clk"; reg = <0 0x1c 0 0x10>; clocks = <&vbattb_xtal>; clock-names = "xin"; #clock-cells = <0>; status = "disabled"; }; vbattb_xtal: vbattb-xtal { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <32768>; }; If external clock device is to be used, I should describe a fake clock too: vbattclk: clock-controller@1c { compatible = "renesas,r9a08g045-vbattb-clk"; reg = <0 0x1c 0 0x10>; clocks = <&vbattb_xtal>, <&ext_clk>; clock-names = "xin", "clkin"; #clock-cells = <0>; status = "disabled"; }; vbattb_xtal: vbattb-xtal { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <0>; }; ext_clk: ext-clk { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <32768>; }; Is this what you are suggesting? > >> + >> + spin_lock_init(&vbclk->lock); >> + >> + init.name = "vbattclk"; >> + init.ops = &vbattb_clk_ops; >> + init.parent_data = &parent_data; >> + init.num_parents = 1; >> + init.flags = 0; >> + >> + vbclk->hw.init = &init; >> + hw = &vbclk->hw; >> + >> + ret = devm_clk_hw_register(dev, hw); >> + if (ret) >> + return ret; >> + >> + return of_clk_add_hw_provider(np, of_clk_hw_simple_get, hw); >> +} >> + >> +static const struct of_device_id vbattb_clk_match[] = { >> + { .compatible = "renesas,r9a08g045-vbattb-clk" }, >> + { /* sentinel */ } >> +}; > > Any MODULE_DEVICE_TABLE? I failed to added it. Thank you for your review, Claudiu Beznea
Quoting claudiu beznea (2024-07-17 01:31:20) > Hi, Stephen, > > On 17.07.2024 01:28, Stephen Boyd wrote: > > Quoting Claudiu (2024-07-16 03:30:17) > >> diff --git a/drivers/clk/renesas/clk-vbattb.c b/drivers/clk/renesas/clk-vbattb.c > >> new file mode 100644 > >> index 000000000000..8effe141fc0b > >> --- /dev/null > >> +++ b/drivers/clk/renesas/clk-vbattb.c > >> @@ -0,0 +1,212 @@ > >> +// SPDX-License-Identifier: GPL-2.0 > >> +/* > >> + * VBATTB clock driver > >> + * > >> + * Copyright (C) 2024 Renesas Electronics Corp. > >> + */ > >> + > >> +#include <linux/cleanup.h> > >> +#include <linux/clk.h> > > > > Prefer clk providers to not be clk consumers. > > I added it here to be able to use devm_clk_get_optional() as it was > proposed to me in v1 to avoid adding a new binding for bypass and detect if > it's needed by checking the input clock name. > Understood. > > > > > I also wonder if this is really a mux, > > It's a way to determine what type of clock (crystal oscillator or device > clock) is connected to RTXIN/RTXOUT pins of the module > (the module block diagram at [1]) based on the clock name. Depending on the > type of the clock connected to RTXIN/RTXOUT we need to select the XC or > XBYP as input for the mux at [1]. > > [1] https://gcdnb.pbrd.co/images/QYsCvhfQlX6n.png That diagram shows a mux block, so at least something in there is a mux. From what I can tell the binding uses clock-names to describe the mux. What I'd like to avoid is using clk_get() to determine how to configure the mux. That's because clk_get() is a clk consumer API, and because we want clk providers to be able to register clks without making sure that the entire parent chain has been registered first. Eventually, we'd like clk_get() to probe defer if the clk is an orphan. Having clk providers use clk_get() breaks that pretty quickly. > > > > and either assigned-clock-parents should be used, > > or the clk_ops should have an init routine that looks at > > which parent is present by determining the index and then use that to > > set the mux. The framework can take care of failing to set the other > > parent when it isn't present. > > > On the board, at any moment, it will be only one clock as input to the > VBATTB clock (either crystal oscillator or a clock device). If I'm getting > you correctly, this will involve describing both clocks in some scenarios. > > E.g. if want to use crystal osc, I can use this DT description: > > vbattclk: clock-controller@1c { > compatible = "renesas,r9a08g045-vbattb-clk"; > reg = <0 0x1c 0 0x10>; > clocks = <&vbattb_xtal>; > clock-names = "xin"; > #clock-cells = <0>; > status = "disabled"; > }; > > vbattb_xtal: vbattb-xtal { > compatible = "fixed-clock"; > #clock-cells = <0>; > clock-frequency = <32768>; > }; > > If external clock device is to be used, I should describe a fake clock too: > > vbattclk: clock-controller@1c { > compatible = "renesas,r9a08g045-vbattb-clk"; > reg = <0 0x1c 0 0x10>; > clocks = <&vbattb_xtal>, <&ext_clk>; Is vbattb_xtal the fake clk? If so, I'd expect this to be clocks = <0>, <&ext_clk>; so that we don't have a useless clk node. > clock-names = "xin", "clkin"; > #clock-cells = <0>; > status = "disabled"; > }; > > vbattb_xtal: vbattb-xtal { > compatible = "fixed-clock"; > #clock-cells = <0>; > clock-frequency = <0>; > }; > > ext_clk: ext-clk { > compatible = "fixed-clock"; > #clock-cells = <0>; > clock-frequency = <32768>; > }; > > Is this what you are suggesting? > Sort of. Ignoring the problem with the subnode for the clk driver, I don't really like having clock-names that don't match the hardware pin names. From the diagram you provided, it looks like clock-names should be "bclk" and "rtxin" for the bus clock and the rtxin signal. Then the clock-cells should be "1" instead of "0", and the mux should be one of those provided clks and "xc" and "xbyp" should be the other two. If that was done, then assigned-clocks could be used to assign the parent of the mux. #define VBATTBCLK 0 #define VBATTB_XBYP 1 #define VBATTB_XC 2 vbattb: vbattb@1005c000 { compatible = "renesas,r9a08g045-vbattb"; reg = <0x1005c000 0x1000>; ranges = <0 0 0x1005c000 0 0x1000>; interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "tampdi"; clocks = <&cpg CPG_MOD R9A08G045_VBAT_BCLK>, <&ext_clk>; clock-names = "bclk", "rtxin"; power-domains = <&cpg>; resets = <&cpg R9A08G045_VBAT_BRESETN>; #clock-cells = <1>; assigned-clocks = <&vbattb VBATTBCLK>; assigned-clock-parents = <&vbattb VBATTB_XBYP>; renesas,vbattb-load-nanofarads = <12500>; }; One last thing that I don't really understand is why this needs to be a clk provider. In the diagram, the RTC is also part of vbattb, so it looks odd to have this node be a clk provider with #clock-cells at all. Is it the case that if the rtxin pin is connected, you mux that over, and if the pin is disconnected you mux over the internal oscillator? I'm really wondering why a clk provider is implemented at all. Why not just hit the registers directly from the RTC driver depending on a devm_clk_get_optional() call?
On 18.07.2024 03:39, Stephen Boyd wrote: > Quoting claudiu beznea (2024-07-17 01:31:20) >> Hi, Stephen, >> >> On 17.07.2024 01:28, Stephen Boyd wrote: >>> Quoting Claudiu (2024-07-16 03:30:17) >>>> diff --git a/drivers/clk/renesas/clk-vbattb.c b/drivers/clk/renesas/clk-vbattb.c >>>> new file mode 100644 >>>> index 000000000000..8effe141fc0b >>>> --- /dev/null >>>> +++ b/drivers/clk/renesas/clk-vbattb.c >>>> @@ -0,0 +1,212 @@ >>>> +// SPDX-License-Identifier: GPL-2.0 >>>> +/* >>>> + * VBATTB clock driver >>>> + * >>>> + * Copyright (C) 2024 Renesas Electronics Corp. >>>> + */ >>>> + >>>> +#include <linux/cleanup.h> >>>> +#include <linux/clk.h> >>> >>> Prefer clk providers to not be clk consumers. >> >> I added it here to be able to use devm_clk_get_optional() as it was >> proposed to me in v1 to avoid adding a new binding for bypass and detect if >> it's needed by checking the input clock name. >> > > Understood. > >> >>> >>> I also wonder if this is really a mux, >> >> It's a way to determine what type of clock (crystal oscillator or device >> clock) is connected to RTXIN/RTXOUT pins of the module >> (the module block diagram at [1]) based on the clock name. Depending on the >> type of the clock connected to RTXIN/RTXOUT we need to select the XC or >> XBYP as input for the mux at [1]. >> >> [1] https://gcdnb.pbrd.co/images/QYsCvhfQlX6n.png > > That diagram shows a mux block, so at least something in there is a mux. > From what I can tell the binding uses clock-names to describe the mux. > What I'd like to avoid is using clk_get() to determine how to configure > the mux. That's because clk_get() is a clk consumer API, and because we > want clk providers to be able to register clks without making sure that > the entire parent chain has been registered first. Eventually, we'd like > clk_get() to probe defer if the clk is an orphan. Having clk providers > use clk_get() breaks that pretty quickly. > >> >> >>> and either assigned-clock-parents should be used, >>> or the clk_ops should have an init routine that looks at >>> which parent is present by determining the index and then use that to >>> set the mux. The framework can take care of failing to set the other >>> parent when it isn't present. >> >> >> On the board, at any moment, it will be only one clock as input to the >> VBATTB clock (either crystal oscillator or a clock device). If I'm getting >> you correctly, this will involve describing both clocks in some scenarios. >> >> E.g. if want to use crystal osc, I can use this DT description: >> >> vbattclk: clock-controller@1c { >> compatible = "renesas,r9a08g045-vbattb-clk"; >> reg = <0 0x1c 0 0x10>; >> clocks = <&vbattb_xtal>; >> clock-names = "xin"; >> #clock-cells = <0>; >> status = "disabled"; >> }; >> >> vbattb_xtal: vbattb-xtal { >> compatible = "fixed-clock"; >> #clock-cells = <0>; >> clock-frequency = <32768>; >> }; >> >> If external clock device is to be used, I should describe a fake clock too: >> >> vbattclk: clock-controller@1c { >> compatible = "renesas,r9a08g045-vbattb-clk"; >> reg = <0 0x1c 0 0x10>; >> clocks = <&vbattb_xtal>, <&ext_clk>; > > Is vbattb_xtal the fake clk? If so, I'd expect this to be > > clocks = <0>, <&ext_clk>; > > so that we don't have a useless clk node. > >> clock-names = "xin", "clkin"; >> #clock-cells = <0>; >> status = "disabled"; >> }; >> >> vbattb_xtal: vbattb-xtal { >> compatible = "fixed-clock"; >> #clock-cells = <0>; >> clock-frequency = <0>; >> }; >> >> ext_clk: ext-clk { >> compatible = "fixed-clock"; >> #clock-cells = <0>; >> clock-frequency = <32768>; >> }; >> >> Is this what you are suggesting? >> > > Sort of. Ignoring the problem with the subnode for the clk driver, I > don't really like having clock-names that don't match the hardware pin > names. From the diagram you provided, it looks like clock-names should > be "bclk" and "rtxin" for the bus clock and the rtxin signal. Then the > clock-cells should be "1" instead of "0", and the mux should be one of > those provided clks and "xc" and "xbyp" should be the other two. If that > was done, then assigned-clocks could be used to assign the parent of the > mux. > > #define VBATTBCLK 0 > #define VBATTB_XBYP 1 > #define VBATTB_XC 2 > > vbattb: vbattb@1005c000 { > compatible = "renesas,r9a08g045-vbattb"; > reg = <0x1005c000 0x1000>; > ranges = <0 0 0x1005c000 0 0x1000>; > interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; > interrupt-names = "tampdi"; > clocks = <&cpg CPG_MOD R9A08G045_VBAT_BCLK>, <&ext_clk>; > clock-names = "bclk", "rtxin"; > power-domains = <&cpg>; > resets = <&cpg R9A08G045_VBAT_BRESETN>; > #clock-cells = <1>; > assigned-clocks = <&vbattb VBATTBCLK>; > assigned-clock-parents = <&vbattb VBATTB_XBYP>; > renesas,vbattb-load-nanofarads = <12500>; > }; I think I got it now. Thank you for the detailed explanation. > > One last thing that I don't really understand is why this needs to be a > clk provider. In the diagram, the RTC is also part of vbattb, so it > looks odd to have this node be a clk provider with #clock-cells at all. I did it like this because the RTC is a different IP mapped at it's own address and considering the other VBATTB functionalities (tamper, SRAM) might be implemented at some point. I also failed to notice that RTC might not work w/o bclk being enabled (thanks for pointing it). I saw that diagram more like describing the always-on power domain (PD_VBATTB) where the VBATTB logic and RTC resides. That power domain is backed by battery. From HW manual [1]: "PD_VBATT domain is the area where the RTC/backup register is located, works on battery power when the power of PD_VCC and PD_ISOVCC domain are turned off." [1] https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg3s-general-purpose-microprocessors-single-core-arm-cortex-a55-11-ghz-cpu-and-dual-core-cortex-m33-250 > Is it the case that if the rtxin pin is connected, you mux that over, > and if the pin is disconnected you mux over the internal oscillator? From the description here at [2] I'm getting that the "32-KHz clock oscillator" block is used when crystal oscillator is connected to RTXIN, RTXOUT pins and it is skipped if external clock device is connected. [2] https://i2.paste.pics/RFKJ0.png?rand=Xq8w1RLDvZ > I'm > really wondering why a clk provider is implemented at all. Why not just > hit the registers directly from the RTC driver depending on a > devm_clk_get_optional() call? I did it like this because the RTC is a different IP mapped at it's own address with it's own interrupts, clock, power domain and considering that the other VBATTB functionalities (tamper, SRAM) might be used at some point in future. At the same time I failed to noticed the VBATTB clock might be needed for RTC. Do you consider better to just take a regmap to VBATTB from RTC driver and set the VBATTB from RTC driver itself? Thank you, Claudiu Beznea
Quoting claudiu beznea (2024-07-18 07:41:03) > > > On 18.07.2024 03:39, Stephen Boyd wrote: > > > > Sort of. Ignoring the problem with the subnode for the clk driver, I > > don't really like having clock-names that don't match the hardware pin > > names. From the diagram you provided, it looks like clock-names should > > be "bclk" and "rtxin" for the bus clock and the rtxin signal. Then the > > clock-cells should be "1" instead of "0", and the mux should be one of > > those provided clks and "xc" and "xbyp" should be the other two. If that > > was done, then assigned-clocks could be used to assign the parent of the > > mux. > > > > #define VBATTBCLK 0 > > #define VBATTB_XBYP 1 > > #define VBATTB_XC 2 > > > > vbattb: vbattb@1005c000 { > > compatible = "renesas,r9a08g045-vbattb"; > > reg = <0x1005c000 0x1000>; > > ranges = <0 0 0x1005c000 0 0x1000>; > > interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; > > interrupt-names = "tampdi"; > > clocks = <&cpg CPG_MOD R9A08G045_VBAT_BCLK>, <&ext_clk>; > > clock-names = "bclk", "rtxin"; > > power-domains = <&cpg>; > > resets = <&cpg R9A08G045_VBAT_BRESETN>; > > #clock-cells = <1>; > > assigned-clocks = <&vbattb VBATTBCLK>; > > assigned-clock-parents = <&vbattb VBATTB_XBYP>; > > renesas,vbattb-load-nanofarads = <12500>; > > }; > > I think I got it now. Thank you for the detailed explanation. > > > > > One last thing that I don't really understand is why this needs to be a > > clk provider. In the diagram, the RTC is also part of vbattb, so it > > looks odd to have this node be a clk provider with #clock-cells at all. > > I did it like this because the RTC is a different IP mapped at it's own > address and considering the other VBATTB functionalities (tamper, SRAM) > might be implemented at some point. > > I also failed to notice that RTC might not work w/o bclk being enabled > (thanks for pointing it). > > I saw that diagram more like describing the always-on power domain > (PD_VBATTB) where the VBATTB logic and RTC resides. That power domain is > backed by battery. From HW manual [1]: "PD_VBATT domain is the area where > the RTC/backup register is located, works on battery power when the power > of PD_VCC and PD_ISOVCC domain are turned off." Ah ok, so PD_VBATTB is like a power domain/wrapper and not an IP block mapped on the bus at the same address as the RTC that it wraps. That changes things a bit. > > [1] > https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg3s-general-purpose-microprocessors-single-core-arm-cortex-a55-11-ghz-cpu-and-dual-core-cortex-m33-250 > > > Is it the case that if the rtxin pin is connected, you mux that over, > > and if the pin is disconnected you mux over the internal oscillator? > > From the description here at [2] I'm getting that the "32-KHz clock > oscillator" block is used when crystal oscillator is connected to RTXIN, > RTXOUT pins and it is skipped if external clock device is connected. > > [2] https://i2.paste.pics/RFKJ0.png?rand=Xq8w1RLDvZ It looks like in both cases something is connected to the pins. XC is to use an external crystal connected to both pins and XBYP is to use a single clk. Given that, perhaps naming the clk "rtx" is simplest and then using assigned-clock-parents is most direct because there's only really one "logical" clk input for this device. That means the XC and XBYP clks have the same parent, "rtx", and the XC clk is a gateable fixed rate clk while the XBYP clk is a fixed factor clk that does nothing besides pass on the rate of the "rtx" clk. > > > I'm > > really wondering why a clk provider is implemented at all. Why not just > > hit the registers directly from the RTC driver depending on a > > devm_clk_get_optional() call? > > I did it like this because the RTC is a different IP mapped at it's own > address with it's own interrupts, clock, power domain and considering that > the other VBATTB functionalities (tamper, SRAM) might be used at some point > in future. At the same time I failed to noticed the VBATTB clock might be > needed for RTC. The docs say VBATT in some places. Not sure if you want to rename it to vbatt and drop the extra b which probably stands for "backup"? > > Do you consider better to just take a regmap to VBATTB from RTC driver and > set the VBATTB from RTC driver itself? No, don't do that. The only change from the above DT node is that the assigned-clocks and assigned-clock-parents property should be moved to the RTC node. vbattb: vbattb@1005c000 { compatible = "renesas,r9a08g045-vbattb"; reg = <0x1005c000 0x1000>; ranges = <0 0 0x1005c000 0 0x1000>; interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; interrupt-names = "tampdi"; clocks = <&cpg CPG_MOD R9A08G045_VBAT_BCLK>, <&ext_clk>; clock-names = "bclk", "rtx"; power-domains = <&cpg>; resets = <&cpg R9A08G045_VBAT_BRESETN>; #clock-cells = <1>; renesas,vbattb-load-nanofarads = <12500>; }; rtc@1004ec00 { compatible = "renesas,r9a08g045-rtc"; reg = <0x1004ec00 0x400>; clocks = <&vbattb VBATTBCLK>; assigned-clocks = <&vbattb VBATTBCLK>; assigned-clock-parents = <&vbattb VBATTB_XBYP>; // Or VBATTB_XC if external crystal connected };
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig index 4410d16de4e2..1f5f38136eb2 100644 --- a/drivers/clk/renesas/Kconfig +++ b/drivers/clk/renesas/Kconfig @@ -228,6 +228,11 @@ config CLK_RZG2L bool "RZ/{G2L,G2UL,G3S,V2L} family clock support" if COMPILE_TEST select RESET_CONTROLLER +config CLK_RENESAS_VBATTB + bool "Renesas VBATTB clock controller" + depends on MFD_RENESAS_VBATTB + 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 f7e18679c3b8..84a2783a7b46 100644 --- a/drivers/clk/renesas/Makefile +++ b/drivers/clk/renesas/Makefile @@ -51,3 +51,4 @@ obj-$(CONFIG_CLK_RZG2L) += rzg2l-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..8effe141fc0b --- /dev/null +++ b/drivers/clk/renesas/clk-vbattb.c @@ -0,0 +1,212 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * VBATTB clock driver + * + * Copyright (C) 2024 Renesas Electronics Corp. + */ + +#include <linux/cleanup.h> +#include <linux/clk.h> +#include <linux/clk-provider.h> +#include <linux/device.h> +#include <linux/io.h> +#include <linux/of.h> +#include <linux/of_platform.h> +#include <linux/platform_device.h> + +#define VBATTB_BKSCCR 0x0 +#define VBATTB_BKSCCR_SOSEL BIT(6) +#define VBATTB_SOSCCR2 0x8 +#define VBATTB_SOSCCR2_SOSTP2 BIT(0) +#define VBATTB_XOSCCR 0x14 +#define VBATTB_XOSCCR_OUTEN BIT(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 + * @hw: clk hw + * @lock: lock + * @load_capacitance: load capacitance + */ +struct vbattb_clk { + void __iomem *base; + struct clk_hw hw; + spinlock_t lock; + u8 load_capacitance; +}; + +#define to_vbattb_clk(_hw) container_of(_hw, struct vbattb_clk, hw) + +static void vbattb_clk_update_bits(void __iomem *base, u32 offset, u32 mask, u32 val) +{ + u32 tmp; + + tmp = readl_relaxed(base + offset); + tmp &= ~mask; + tmp |= (val & mask); + writel_relaxed(tmp, base + offset); +} + +static int vbattb_clk_enable(struct clk_hw *hw) +{ + struct vbattb_clk *vbclk = to_vbattb_clk(hw); + void __iomem *base = vbclk->base; + + guard(spinlock)(&vbclk->lock); + + vbattb_clk_update_bits(base, VBATTB_SOSCCR2, VBATTB_SOSCCR2_SOSTP2, 0); + vbattb_clk_update_bits(base, VBATTB_XOSCCR, VBATTB_XOSCCR_OUTEN | VBATTB_XOSCCR_XSEL, + VBATTB_XOSCCR_OUTEN | vbclk->load_capacitance); + + return 0; +} + +static void vbattb_clk_disable(struct clk_hw *hw) +{ + struct vbattb_clk *vbclk = to_vbattb_clk(hw); + void __iomem *base = vbclk->base; + + guard(spinlock)(&vbclk->lock); + + vbattb_clk_update_bits(base, VBATTB_XOSCCR, VBATTB_XOSCCR_OUTEN, 0); + vbattb_clk_update_bits(base, VBATTB_SOSCCR2, VBATTB_SOSCCR2_SOSTP2, VBATTB_SOSCCR2_SOSTP2); +} + +static int vbattb_clk_is_enabled(struct clk_hw *hw) +{ + struct vbattb_clk *vbclk = to_vbattb_clk(hw); + void __iomem *base = vbclk->base; + unsigned int xosccr, sosccr2; + + guard(spinlock)(&vbclk->lock); + + xosccr = readl_relaxed(base + VBATTB_XOSCCR); + sosccr2 = readl_relaxed(base + VBATTB_SOSCCR2); + + return ((xosccr & VBATTB_XOSCCR_OUTEN) && !(sosccr2 & VBATTB_SOSCCR2_SOSTP2)); +} + +static const struct clk_ops vbattb_clk_ops = { + .enable = vbattb_clk_enable, + .disable = vbattb_clk_disable, + .is_enabled = vbattb_clk_is_enabled, +}; + +static int vbattb_clk_validate_load_capacitance(struct vbattb_clk *vbclk, u32 load_capacitance) +{ + switch (load_capacitance) { + case 4000: + vbclk->load_capacitance = VBATTB_XOSCCR_XSEL_4_PF; + break; + case 7000: + vbclk->load_capacitance = VBATTB_XOSCCR_XSEL_7_PF; + break; + case 9000: + vbclk->load_capacitance = VBATTB_XOSCCR_XSEL_9_PF; + break; + case 12500: + vbclk->load_capacitance = VBATTB_XOSCCR_XSEL_12_5_PF; + break; + default: + return -EINVAL; + } + + return 0; +} + +static int vbattb_clk_need_bypass(struct device *dev) +{ + struct clk *clkin, *xin; + + clkin = devm_clk_get_optional(dev, "clkin"); + xin = devm_clk_get_optional(dev, "xin"); + + if (!IS_ERR_OR_NULL(clkin) && !IS_ERR_OR_NULL(xin)) + return -EINVAL; + else if (!clkin && !IS_ERR_OR_NULL(xin)) + return 0; + else if (!IS_ERR_OR_NULL(clkin) && !xin) + return 1; + + return -EINVAL; +} + +static int vbattb_clk_probe(struct platform_device *pdev) +{ + struct device_node *np = pdev->dev.of_node; + struct clk_parent_data parent_data = {}; + struct device *dev = &pdev->dev; + struct clk_init_data init = {}; + struct vbattb_clk *vbclk; + u32 load_capacitance; + struct clk_hw *hw; + int ret, bypass; + + vbclk = devm_kzalloc(dev, sizeof(*vbclk), GFP_KERNEL); + if (!vbclk) + return -ENOMEM; + + vbclk->base = devm_platform_ioremap_resource(pdev, 0); + if (IS_ERR(vbclk->base)) + return PTR_ERR(vbclk->base); + + bypass = vbattb_clk_need_bypass(dev); + if (bypass < 0) { + return bypass; + } else if (bypass) { + parent_data.fw_name = "clkin"; + bypass = VBATTB_BKSCCR_SOSEL; + } else { + parent_data.fw_name = "xin"; + } + + ret = of_property_read_u32(np, "renesas,vbattb-load-nanofarads", &load_capacitance); + if (ret) + return ret; + + ret = vbattb_clk_validate_load_capacitance(vbclk, load_capacitance); + if (ret) + return ret; + + vbattb_clk_update_bits(vbclk->base, VBATTB_BKSCCR, VBATTB_BKSCCR_SOSEL, bypass); + + spin_lock_init(&vbclk->lock); + + init.name = "vbattclk"; + init.ops = &vbattb_clk_ops; + init.parent_data = &parent_data; + init.num_parents = 1; + init.flags = 0; + + vbclk->hw.init = &init; + hw = &vbclk->hw; + + ret = devm_clk_hw_register(dev, hw); + if (ret) + return ret; + + return of_clk_add_hw_provider(np, of_clk_hw_simple_get, hw); +} + +static const struct of_device_id vbattb_clk_match[] = { + { .compatible = "renesas,r9a08g045-vbattb-clk" }, + { /* sentinel */ } +}; + +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");