From: Heiko Stuebner <heiko@sntech.de>
To: Elaine Zhang <zhangqing@rock-chips.com>
Cc: mturquette@baylibre.com, sboyd@codeaurora.org, xf@rock-chips.com,
wdc@rock-chips.com, linux-clk@vger.kernel.org,
huangtao@rock-chips.com, xxx@rock-chips.com,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v1 2/2] clk: rockchip: describe clk_gmac using the new muxgrf type on rk3328
Date: Tue, 07 Feb 2017 01:13:41 +0100 [thread overview]
Message-ID: <2060105.7dU1ly8Kaa@phil> (raw)
In-Reply-To: <1486349435-8681-3-git-send-email-zhangqing@rock-chips.com>
Hi Elaine,
Am Montag, 6. Februar 2017, 10:50:35 CET schrieb Elaine Zhang:
> With the newly introduced clk type for muxes in the grf we now can
> describe some missing clocks, like the clk_gmac2io and clk_gmac2phy
> that selects between clk_mac2io_src and gmac_clkin based on a bit
> set in the general register files.
>
> Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
both patches look good, but I do have a question below.
Anyway, we're very late in the cycle for 4.10, so we'll need to wait until
after the next merge-window.
> ---
> drivers/clk/rockchip/clk-rk3328.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/clk/rockchip/clk-rk3328.c
> b/drivers/clk/rockchip/clk-rk3328.c index 1e384e143504..b04f29774ee7 100644
> --- a/drivers/clk/rockchip/clk-rk3328.c
> +++ b/drivers/clk/rockchip/clk-rk3328.c
> @@ -20,6 +20,7 @@
> #include <dt-bindings/clock/rk3328-cru.h>
> #include "clk.h"
>
> +#define RK3328_GRF_SOC_CON4 0x410
> #define RK3328_GRF_SOC_STATUS0 0x480
> #define RK3328_GRF_MAC_CON1 0x904
> #define RK3328_GRF_MAC_CON2 0x908
> @@ -214,6 +215,8 @@ enum rk3328_plls {
> "gmac_clkin" };
> PNAME(mux_mac2phy_src_p) = { "clk_mac2phy_src",
> "phy_50m_out" };
> +PNAME(mux_mac2io_ext_p) = { "clk_mac2io",
> + "gmac_clkin" };
>
> static struct rockchip_pll_clock rk3328_pll_clks[] __initdata = {
> [apll] = PLL(pll_rk3328, PLL_APLL, "apll", mux_pll_p,
> @@ -680,6 +683,10 @@ enum rk3328_plls {
> COMPOSITE(SCLK_MAC2IO_OUT, "clk_mac2io_out", mux_2plls_p, 0,
> RK3328_CLKSEL_CON(27), 15, 1, MFLAGS, 8, 5, DFLAGS,
> RK3328_CLKGATE_CON(3), 5, GFLAGS),
> + MUXGRF(SCLK_MAC2IO, "clk_mac2io", mux_mac2io_src_p,
> CLK_SET_RATE_NO_REPARENT, + RK3328_GRF_MAC_CON1, 10, 1, MFLAGS),
> + MUXGRF(SCLK_MAC2IO_EXT, "clk_mac2io_ext", mux_mac2io_ext_p,
> CLK_SET_RATE_NO_REPARENT, + RK3328_GRF_SOC_CON4, 14, 1, MFLAGS),
>
> COMPOSITE(SCLK_MAC2PHY_SRC, "clk_mac2phy_src", mux_2plls_p, 0,
> RK3328_CLKSEL_CON(26), 7, 1, MFLAGS, 0, 5, DFLAGS,
> @@ -691,6 +698,8 @@ enum rk3328_plls {
> COMPOSITE_NOMUX(SCLK_MAC2PHY_OUT, "clk_mac2phy_out", "clk_mac2phy", 0,
> RK3328_CLKSEL_CON(26), 8, 2, DFLAGS,
> RK3328_CLKGATE_CON(9), 2, GFLAGS),
> + MUXGRF(SCLK_MAC2PHY, "clk_mac2phy", mux_mac2phy_src_p,
> CLK_SET_RATE_NO_REPARENT, + RK3328_GRF_MAC_CON2, 10, 1, MFLAGS),
You don't set CLK_SET_RATE_PARENT but you do set CLK_SET_RATE_NO_REPARENT -
essentially disabling all automatic clock-changes for them.
Does this mean that these clocks should always only be set "manually" from
something like the assigned-clocks in dts?
This is not a problem in itself, I just want to understand how they should be
used :-)
Thanks
Heiko
next prev parent reply other threads:[~2017-02-07 0:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-06 2:50 [PATCH v1 0/2] clk: rockchip: describe clk_gmac2io and clk_gmac2phy on rk3328 Elaine Zhang
2017-02-06 2:50 ` [PATCH v1 1/2] rockchip: clk: rk3328: add clk_mac2io_ext ID Elaine Zhang
2017-02-06 2:50 ` [PATCH v1 2/2] clk: rockchip: describe clk_gmac using the new muxgrf type on rk3328 Elaine Zhang
2017-02-07 0:13 ` Heiko Stuebner [this message]
2017-03-10 10:46 ` [PATCH v1 0/2] clk: rockchip: describe clk_gmac2io and clk_gmac2phy " Heiko Stübner
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=2060105.7dU1ly8Kaa@phil \
--to=heiko@sntech.de \
--cc=huangtao@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mturquette@baylibre.com \
--cc=sboyd@codeaurora.org \
--cc=wdc@rock-chips.com \
--cc=xf@rock-chips.com \
--cc=xxx@rock-chips.com \
--cc=zhangqing@rock-chips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).