Hi.
I am implementing clk and reset drivers for my SoCs.
(drivers/clk/uniphier/* and drivers/reset/uniphier/*)
In my SoCs, one hardware block contains various
registers for both clock and reset controlling.
(so, it is like a MFD system controller device).
I think it is a common case.
I am guessing my device tree would be like follows:
(one syscon device contains clk and rst devices under it)
syscon {
compatible = "socionext,uniphier-syscon",
"syscon", "simple-mfd";
reg = <... ...>;
clk_ctrl {
.compatible = "socionext,uniphier-clkctrl";
#clock-cells = <1>;
};
rst_ctrl {
.compatible = "socionext,uniphier-rstctrl";
#reset-cells = <1>;
};
};
One problem I noticed was,
we are supposed to use regmap for register access
if we use syscon.
OTOH, common clk APIs such as clk-gate, clk-divider
expect simple register access via writel()/readl().
Is it a good idea to expand such APIs to regmap?
Of course, I could my own uniphier/clk-gate.c
to use regmap as other SoCs do.
But, I think regmap is general demand, so
I am wondering if it could be supported in common parts.
Or, any other good solution exists?
--
Best Regards
Masahiro Yamada
Hi Masahiro,
On 11.11.2015 05:16, Masahiro Yamada wrote:
> Hi.
>
> I am implementing clk and reset drivers for my SoCs.
> (drivers/clk/uniphier/* and drivers/reset/uniphier/*)
>
>
> In my SoCs, one hardware block contains various
> registers for both clock and reset controlling.
> (so, it is like a MFD system controller device).
> I think it is a common case.
>
I met the same problem with LPC32xx clocks, one hardware block
contains clock controller, power controller, wakeup
controllers and partially pinmux and dma configuration.
I've sent a mmio version for review some time ago, but I had
to change interface to regmap recently.
> I am guessing my device tree would be like follows:
> (one syscon device contains clk and rst devices under it)
>
> syscon {
> compatible = "socionext,uniphier-syscon",
> "syscon", "simple-mfd";
> reg = <... ...>;
>
> clk_ctrl {
> .compatible = "socionext,uniphier-clkctrl";
> #clock-cells = <1>;
> };
>
> rst_ctrl {
> .compatible = "socionext,uniphier-rstctrl";
> #reset-cells = <1>;
> };
> };
>
Eventually I implement the same layout, but replace "syscon" and
"simple-mfd" with "simple-bus" only.
For a single interface syscon_node_to_regmap() I don't see a point to
add a dependency on MFD and syscon.
>
> One problem I noticed was,
> we are supposed to use regmap for register access
> if we use syscon.
>
> OTOH, common clk APIs such as clk-gate, clk-divider
> expect simple register access via writel()/readl().
>
> Is it a good idea to expand such APIs to regmap?
It might be a good idea.
>
> Of course, I could my own uniphier/clk-gate.c
> to use regmap as other SoCs do.
>
> But, I think regmap is general demand, so
> I am wondering if it could be supported in common parts.
>
> Or, any other good solution exists?
>
I had to copy low-level parts from clk-gate, clk-divider and clk-mux to
my driver and reimplement them on regmap API, of course I won't call
this as a good solution, but if regmap is unavoidable, that's what remains.
--
With best wishes,
Vladimir
Hi,
On Wed, Nov 11, 2015 at 11:16 AM, Masahiro Yamada
<[email protected]> wrote:
> Hi.
>
> I am implementing clk and reset drivers for my SoCs.
> (drivers/clk/uniphier/* and drivers/reset/uniphier/*)
>
>
> In my SoCs, one hardware block contains various
> registers for both clock and reset controlling.
> (so, it is like a MFD system controller device).
> I think it is a common case.
sunxi uses a "instance per register" design, that is each
register corresponds to one (or more, in rare cases) clock
or reset control. Each will get a separate device node in
the DT.
For registers that have both clocks and resets, they are
combined in a single driver if it makes sense (for example
serving the same set of peripherals).
See drivers/clk/sunxi/clk-usb.c for such a driver.
Regards
ChenYu
> I am guessing my device tree would be like follows:
> (one syscon device contains clk and rst devices under it)
>
> syscon {
> compatible = "socionext,uniphier-syscon",
> "syscon", "simple-mfd";
> reg = <... ...>;
>
> clk_ctrl {
> .compatible = "socionext,uniphier-clkctrl";
> #clock-cells = <1>;
> };
>
> rst_ctrl {
> .compatible = "socionext,uniphier-rstctrl";
> #reset-cells = <1>;
> };
> };
>
>
>
> One problem I noticed was,
> we are supposed to use regmap for register access
> if we use syscon.
>
> OTOH, common clk APIs such as clk-gate, clk-divider
> expect simple register access via writel()/readl().
>
> Is it a good idea to expand such APIs to regmap?
>
>
> Of course, I could my own uniphier/clk-gate.c
> to use regmap as other SoCs do.
>
> But, I think regmap is general demand, so
> I am wondering if it could be supported in common parts.
>
> Or, any other good solution exists?
>
>
>
> --
> Best Regards
> Masahiro Yamada
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html