[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140515165531.GV29318@piout.net>
Date: Thu, 15 May 2014 18:55:31 +0200
From: Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Cc: Mike Turquette <mturquette@...aro.org>,
Jisheng Zhang <jszhang@...vell.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 06/10] clk: berlin: add core clock driver for BG2/BG2CD
On 15/05/2014 at 17:43:03 +0200, Sebastian Hesselbarth wrote :
> On 05/15/2014 10:09 AM, Alexandre Belloni wrote:
> >On 14/05/2014 at 22:15:17 +0200, Sebastian Hesselbarth wrote :
> >>+ /* clock divider cells */
> >>+ parent_names[1] = avpllb_names[CH4];
> >>+ parent_names[2] = avpllb_names[CH5];
> >>+ parent_names[3] = avpllb_names[CH6];
> >>+ parent_names[4] = avpllb_names[CH7];
> >>+
> >>+ parent_names[0] = refclk_names[SYSPLL];
> >
> >It should actually be:
> >
> >parent_names[0] = avpllb_names[CH4];
> >parent_names[1] = avpllb_names[CH5];
> >parent_names[2] = avpllb_names[CH6];
> >parent_names[3] = avpllb_names[CH7];
> >parent_names[4] = refclk_names[SYSPLL];
>
> Given the comment to remove index 0 in the last patch, I translate that
> into: "the input mux bypass is there, but {cannot,should not,we do not
> want it to} be used". *sigh*
>
> Actually, almost all of this is based on Chromecast mirrored BSP code
> and I though about leaving the bypass mux in - even if it is not used
> at all.
>
> The reason is that I am _very_ tired of reading through the BSP code
> and have all the things in mind where the BSP code is unclear.
>
Ok, I made a mistake, I also have a hard time to picture everything
myself ;)
So, the mux is there iand can be used, hence, the parents are actually:
parent_names[0] = refclk_names[SYSPLL];
parent_names[1] = avpllb_names[CH4];
parent_names[2] = avpllb_names[CH5];
parent_names[3] = avpllb_names[CH6];
parent_names[4] = avpllb_names[CH7];
parent_names[5] = refclk_names[SYSPLL];
and disregard my comment on the previous patch.
> >>+ data = &bg2_divs[CLKID_SYS];
> >>+ clks[CLKID_SYS] = berlin2_div_register(&data->map, base, data->name,
> >>+ data->div_flags, parent_names, 5, data->flags, &lock);
> >>+
> >>+ parent_names[0] = refclk_names[CPUPLL];
> >>+ parent_names[5] = refclk_names[MEMPLL];
> >
> >The only valid choice here should be (remember, we are not adding 1 to
> >the index anymore):
> >parent_names[4] = refclk_names[MEMPLL];
There, you actually had it right, maybe we could set parent_names[1] to
parent_names[4] to something bogus or all to refclk_names[MEMPLL].
>
> Funny to see that there ought to be a CPUPLL which isn't used by the
> CPU at all. This also implies to remove CPUPLL, right?
>
> >>+ data = &bg2_divs[CLKID_CPU];
> >>+ clks[CLKID_CPU] = berlin2_div_register(&data->map, base, data->name,
> >>+ data->div_flags, parent_names, 6, data->flags, &lock);
> >>+
> >
> >This is where it gets tricky, now we should have:
> >parent_names[0] = avpllb_names[CH4];
> >parent_names[1] = avplla_names[CH5];
> >parent_names[2] = avpllb_names[CH6];
> >parent_names[3] = avpllb_names[CH7];
> >parent_names[4] = refclk_names[SYSPLL];
>
> First I thought that it is just the default input mux clocks again..
> but then I noticed that it is actually AVPLL_A5 not B5.
>
Here it becomes:
parent_names[0] = refclk_names[SYSPLL];
parent_names[1] = avpllb_names[CH4];
parent_names[2] = avplla_names[CH5];
parent_names[3] = avpllb_names[CH6];
parent_names[4] = avpllb_names[CH7];
parent_names[5] = refclk_names[SYSPLL];
> Ok, I admit having confirmed information is maybe better. So, you agree
> that we can remove the input mux bypass on the complex divider, too?
> (Including all the consequences: remove it from the divmap, driver, ...)
>
No, let's keep the mux, sorry about that confusion.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists