From: Vladimir Zapolskiy <vz@mleia.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>,
linux-clk@vger.kernel.org
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: How to implement common clk in multi function controller?
Date: Wed, 11 Nov 2015 11:30:40 +0200 [thread overview]
Message-ID: <56430AC0.5090707@mleia.com> (raw)
In-Reply-To: <CAK7LNASM+tJpd-kBHGHe7TXWm4i-UEfbq7T3dn99p2fKFwtxAA@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: vz@mleia.com (Vladimir Zapolskiy)
To: linux-arm-kernel@lists.infradead.org
Subject: How to implement common clk in multi function controller?
Date: Wed, 11 Nov 2015 11:30:40 +0200 [thread overview]
Message-ID: <56430AC0.5090707@mleia.com> (raw)
In-Reply-To: <CAK7LNASM+tJpd-kBHGHe7TXWm4i-UEfbq7T3dn99p2fKFwtxAA@mail.gmail.com>
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
next prev parent reply other threads:[~2015-11-11 9:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-11 3:16 How to implement common clk in multi function controller? Masahiro Yamada
2015-11-11 3:16 ` Masahiro Yamada
2015-11-11 9:30 ` Vladimir Zapolskiy [this message]
2015-11-11 9:30 ` Vladimir Zapolskiy
2015-11-11 9:47 ` Chen-Yu Tsai
2015-11-11 9:47 ` Chen-Yu Tsai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56430AC0.5090707@mleia.com \
--to=vz@mleia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.