lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ