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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ