>
>
> > 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?
