devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Chen-Yu Tsai <wens@csie.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	devicetree <devicetree@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-sunxi <linux-sunxi@googlegroups.com>
Subject: Re: [PATCH 03/11] clk: sunxi-ng: a83t: Support new timing mode for mmc2 clock
Date: Tue, 18 Jul 2017 16:47:58 +0200	[thread overview]
Message-ID: <20170718144758.os7yy6saulb65gam@flea> (raw)
In-Reply-To: <CAGb2v67Ofdr9zL=o82F6-90meYZGaYtr_zy7y-OeBH30n1gERQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]

On Mon, Jul 17, 2017 at 06:12:35PM +0800, Chen-Yu Tsai wrote:
> On Mon, Jul 17, 2017 at 5:14 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Fri, Jul 14, 2017 at 02:42:54PM +0800, Chen-Yu Tsai wrote:
> >> The MMC2 clock supports a new timing mode. When the new mode is active,
> >> the output clock rate is halved.
> >>
> >> This patch sets the feature flag for the new timing mode, and adds
> >> a pre-divider based on the mode bit.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> >> ---
> >>  drivers/clk/sunxi-ng/ccu-sun8i-a83t.c | 38 +++++++++++++++++++++++++++--------
> >>  1 file changed, 30 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
> >> index 947f9f6e05d2..ee6688e9b361 100644
> >> --- a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
> >> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
> >> @@ -418,14 +418,36 @@ static SUNXI_CCU_PHASE(mmc1_sample_clk, "mmc1-sample", "mmc1",
> >>  static SUNXI_CCU_PHASE(mmc1_output_clk, "mmc1-output", "mmc1",
> >>                      0x08c, 8, 3, 0);
> >>
> >> -/* TODO Support MMC2 clock's new timing mode. */
> >> -static SUNXI_CCU_MP_WITH_MUX_GATE(mmc2_clk, "mmc2", mod0_default_parents,
> >> -                               0x090,
> >> -                               0, 4,         /* M */
> >> -                               16, 2,        /* P */
> >> -                               24, 2,        /* mux */
> >> -                               BIT(31),      /* gate */
> >> -                               0);
> >> +/*
> >> + * MMC2 supports both old and new timing modes. When the new timing
> >> + * mode is active, the output clock rate is halved by two. Here we
> >> + * treat it as a variable pre-divider. Note that the pre-divider is
> >> + * _not_ included in the possible factors during a set clock rate
> >> + * operation. It is only read out.
> >> + */
> >> +static const struct ccu_mux_var_prediv mmc2_new_timing_predivs[] = {
> >> +     { .index = 0, .shift = 30, .width = 1 },
> >> +     { .index = 1, .shift = 30, .width = 1 },
> >> +};
> >> +static struct ccu_mp mmc2_clk = {
> >> +     .enable = BIT(31),
> >> +     .m      = _SUNXI_CCU_DIV(0, 4),
> >> +     .p      = _SUNXI_CCU_DIV(16, 2),
> >> +     .mux    = {
> >> +             .shift  = 24,
> >> +             .width  = 2,
> >> +             .var_predivs    = mmc2_new_timing_predivs,
> >> +             .n_var_predivs  = ARRAY_SIZE(mmc2_new_timing_predivs),
> >> +     },
> >> +     .common         = {
> >> +             .reg            = 0x090,
> >> +             .features       = CCU_FEATURE_MMC_TIMING_SWITCH,
> >> +             .hw.init        = CLK_HW_INIT_PARENTS("mmc2",
> >> +                                                   mod0_default_parents,
> >> +                                                   &ccu_mp_ops,
> >> +                                                   CLK_GET_RATE_NOCACHE),
> >> +     },
> >> +};
> >
> > Treating the new bit seems a bit of a hack to me. It only works
> > because we're not evaluating the various pre-dividers during a
> > determine_rate (and set_rate), but it might change in the future, and
> > we will break all our eMMC controllers then.
> >
> > Since they're quite special, I was thinking about creating a new MMC
> > clock type? We're going to use it on a number of SoCs, and we'll be
> > able to model it properly, without crippling the regular and generic
> > MP clocks.
> 
> Yes that should be doable. I could put them in the same file and
> reuse all the existing MP clocks stuff by wrapping them in new
> functions that check the timing mode bit.
> 
> Would that work for you?

Yep, it does.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2017-07-18 14:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-14  6:42 [PATCH 00/11] ARM: sun8i: a83t: Add support for MMC controllers Chen-Yu Tsai
     [not found] ` <20170714064302.20383-1-wens-jdAy2FN1RRM@public.gmane.org>
2017-07-14  6:42   ` [PATCH 01/11] ARM: dts: sun8i: a83t: Switch to CCU device tree binding macros Chen-Yu Tsai
     [not found]     ` <20170714064302.20383-2-wens-jdAy2FN1RRM@public.gmane.org>
2017-07-17  9:06       ` Maxime Ripard
2017-07-14  6:42   ` [PATCH 02/11] clk: sunxi-ng: Add interface to query or configure MMC timing modes Chen-Yu Tsai
     [not found]     ` <20170714064302.20383-3-wens-jdAy2FN1RRM@public.gmane.org>
2017-07-17  9:09       ` Maxime Ripard
2017-07-14  6:42   ` [PATCH 03/11] clk: sunxi-ng: a83t: Support new timing mode for mmc2 clock Chen-Yu Tsai
     [not found]     ` <20170714064302.20383-4-wens-jdAy2FN1RRM@public.gmane.org>
2017-07-17  9:14       ` Maxime Ripard
2017-07-17 10:12         ` Chen-Yu Tsai
2017-07-18 14:47           ` Maxime Ripard [this message]
2017-07-14  6:42   ` [PATCH 04/11] mmc: sunxi: Keep default timing phase settings for new timing mode Chen-Yu Tsai
     [not found]     ` <20170714064302.20383-5-wens-jdAy2FN1RRM@public.gmane.org>
2017-07-14  9:16       ` Ulf Hansson
     [not found]         ` <CAPDyKFoOsp7ATFY-0N4ExVWQb=z1kCJqowLv7g7CSBK4jWVj_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-14  9:44           ` Chen-Yu Tsai
2017-07-17  9:14       ` Maxime Ripard
2017-07-17 10:37       ` Ulf Hansson
2017-07-14  6:42   ` [PATCH 05/11] mmc: sunxi: Support controllers that can use both old and new timings Chen-Yu Tsai
     [not found]     ` <20170714064302.20383-6-wens-jdAy2FN1RRM@public.gmane.org>
2017-07-14  9:26       ` Ulf Hansson
     [not found]         ` <CAPDyKFoLTXJ10EJRfPPggJBg8bh9BpdwTnew-WL0G7LpnO43Pg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-14  9:40           ` Chen-Yu Tsai
2017-07-14  9:57             ` Ulf Hansson
     [not found]               ` <CAPDyKFqe1hFmfWziu04fW=cQa0EGvT11YzuJ0f-eHy6+u7vutQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-17  9:20                 ` Maxime Ripard
2017-07-17  9:17       ` Maxime Ripard
2017-07-19  8:59         ` Chen-Yu Tsai
     [not found]           ` <CAGb2v67VmdfrMNLFH=6hhbGAHr15e0q4toDUbJ17d3exS3maFw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-07-19 11:28             ` Maxime Ripard
2017-07-17 13:10       ` kbuild test robot
2017-07-14  6:42   ` [PATCH 06/11] mmc: sunxi: Support MMC DDR52 transfer mode with new timing mode Chen-Yu Tsai
2017-07-14  6:42   ` [PATCH 07/11] mmc: sunxi: Add support for A83T eMMC (MMC2) Chen-Yu Tsai
2017-07-17 18:51     ` Rob Herring
2017-07-14  6:42   ` [PATCH 08/11] ARM: dts: sun8i: a83t: Add MMC controller device nodes Chen-Yu Tsai
     [not found]     ` <20170714064302.20383-9-wens-jdAy2FN1RRM@public.gmane.org>
2017-07-17  9:22       ` Maxime Ripard
2017-07-14  6:43   ` [PATCH 09/11] ARM: dts: sun8i: a83t: Add pingroup for 8-bit eMMC on mmc2 Chen-Yu Tsai
2017-07-14  6:43   ` [PATCH 10/11] ARM: dts: sun8i: a83t: cubietruck-plus: Enable micro-SD card and eMMC Chen-Yu Tsai
2017-07-14  6:43   ` [PATCH 11/11] ARM: dts: sun8i: a83t: h8homlet: Enable micro-SD card and onboard eMMC 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=20170718144758.os7yy6saulb65gam@flea \
    --to=maxime.ripard@free-electrons.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=mark.rutland@arm.com \
    --cc=mturquette@baylibre.com \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=ulf.hansson@linaro.org \
    --cc=wens@csie.org \
    /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).