linux-kernel - Re: [PATCH 3/3] clk: tegra: T114: add DFLL DVCO reset control

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.02.1306071703050.7753@utopia.booyaka.com>
Date:	Fri, 7 Jun 2013 17:06:29 +0000 (UTC)
From:	Paul Walmsley <pwalmsley@...dia.com>
To:	Prashant Gaikwad <pgaikwad@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>
cc:	linux-tegra@...r.kernel.org, mturquette@...aro.org,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	Aleksandr Frid <afrid@...dia.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 3/3] clk: tegra: T114: add DFLL DVCO reset control

Hi Stephen,

On Fri, 7 Jun 2013, Stephen Warren wrote:

> On 06/07/2013 06:19 AM, Paul Walmsley wrote:
> > Add DFLL DVCO reset line control functions to the CAR IP block driver.
> > 
> > The DVCO present in the DFLL IP block has a separate reset line,
> > exposed via the CAR IP block.  This reset line is asserted upon SoC
> > reset.  Unless something (such as the DFLL driver) deasserts this
> > line, the DVCO will not oscillate, although reads and writes to the
> > DFLL IP block will complete.
> > 
> > Thanks to Aleksandr Frid <afrid@...dia.com> for identifying this and
> > saving hours of debugging time.
> 
> > diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
> 
> >  void tegra114_clock_tune_cpu_trimmers_high(void);
> >  void tegra114_clock_tune_cpu_trimmers_low(void);
> >  void tegra114_clock_tune_cpu_trimmers_init(void);
> > +void tegra114_clock_assert_dfll_dvco_reset(void);
> > +void tegra114_clock_deassert_dfll_dvco_reset(void);
> 
> Where/what is the code that will call these new APIs? If it's going to
> be something in drivers/clk, that seems fine.

That's correct - they'll be used by the DFLL clocksource code, which will 
live in drivers/clk/tegra.  You've seen the patches already ;-)

> The reset assert/de-assert functions at least might be worth exposing
> using the new generic module reset API. I believe Prashant Gaikwad is
> working on converting the Tegra clock driver to be a module reset
> provider, hence removing the existing custom
> tegra_periph_reset_{de,}assert() APIs.

OK, will take a look to see if this can be done without getting in the way 
of Prashant's work.  I'd naïvely assume that it might be best to convert 
these as part of his series - that way we won't duplicate effort.

Prashant, what stage are you at in the conversion?  If you're close to 
completion, maybe we can just add this functionality in with your patches?


- Paul