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: <20140626103051.GB3679@tbergstrom-lnx.Nvidia.com>
Date:	Thu, 26 Jun 2014 13:30:51 +0300
From:	Peter De Schrijver <pdeschrijver@...dia.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Prashant Gaikwad <pgaikwad@...dia.com>,
	Mike Turquette <mturquette@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] clk: tegra: fix vi_sensor clocks on Tegra124

On Wed, Jun 25, 2014 at 11:02:14PM +0200, Stephen Warren wrote:
> On 06/25/2014 10:10 AM, Peter De Schrijver wrote:
> > vi_sensor and vi_sensor2 have a wrong hw clkid on Tegra124. Fix this by
> > correcting the hw clkid for Tegra124 and creating the Tegra114 vi_sensor clock
> > from its own data. Tegra124 was also using the wrong internal clock id.
> 
> > diff --git a/drivers/clk/tegra/clk-tegra-periph.c b/drivers/clk/tegra/clk-tegra-periph.c
> 
> > -	MUX("vi_sensor2", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_VI_SENSOR2, 20, TEGRA_PERIPH_NO_RESET, tegra_clk_vi_sensor2),
> > +	MUX("vi_sensor2", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_VI_SENSOR2, 165, TEGRA_PERIPH_NO_RESET, tegra_clk_vi_sensor2),
> ...
> > -	MUX8("vi_sensor", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_VI_SENSOR, 20, TEGRA_PERIPH_NO_RESET, tegra_clk_vi_sensor_8),
> > +	MUX8("vi_sensor", mux_pllm_pllc2_c_c3_pllp_plla, CLK_SOURCE_VI_SENSOR, 164, TEGRA_PERIPH_NO_RESET, tegra_clk_vi_sensor_8),
> 
> If I'm reading the TRM right, these are CAM_MCLK/CAM_MCLK2 in the
> RST_DEV_X register. Is the TRM simply inconsistent in the naming of
> these clocks, or is there some other inconsistency?
> 

Yeah, the TRM has an inconsistent naming of these clocks for all I can see.

> > diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
> 
> > @@ -777,7 +784,6 @@ static struct tegra_clk tegra114_clks[tegra_clk_max] __initdata = {
> >  	[tegra_clk_spdif_in] = { .dt_id = TEGRA114_CLK_SPDIF_IN, .present = true },
> >  	[tegra_clk_spdif_out] = { .dt_id = TEGRA114_CLK_SPDIF_OUT, .present = true },
> >  	[tegra_clk_vi_8] = { .dt_id = TEGRA114_CLK_VI, .present = true },
> > -	[tegra_clk_vi_sensor_8] = { .dt_id = TEGRA114_CLK_VI_SENSOR, .present = true },
> 
> Does it make any sense to
> s/tegra_clk_vi_sensor_8/tegra_clk_vi_sensor_114/ and put the definition
> into the table in clk-tegra-periph.c instead? I suppose if this clock
> definition is specific to Tegra114 there's not much point, so this is

That was exactly my reasoning, because this clock is specific to Tegra114,
it doesn't make much sense to put in clk-tegra-periph.c. Also Tegra20 and
Tegra30 have some peripheral clocks which are not defined in
clk-tegra-periph.c.

> probably fine. Hopefully the new tegra_clk_vi_sensor_8 lasts longer than
> just Tegra124...
> 
> So overall, I think:
> Acked-by: Stephen Warren <swarren@...dia.com>

Ok. I will take this into tegra-clk-next for 3.17 together with the changes
for sata.

Cheers,

Peter.
--
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