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: <20150107144805.GF1621@ulmo>
Date:	Wed, 7 Jan 2015 15:48:08 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Vince Hsu <vinceh@...dia.com>
Cc:	Peter De Schrijver <pdeschrijver@...dia.com>,
	Lucas Stach <dev@...xeye.de>, swarren@...dotorg.org,
	gnurou@...il.com, bskeggs@...hat.com, martin.peres@...e.fr,
	seven@...rod-online.com, samuel.pitoiset@...il.com,
	nouveau@...ts.freedesktop.org, linux-tegra@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/11] ARM: tegra: add function to control the GPU rail
 clamp

On Wed, Jan 07, 2015 at 10:28:29PM +0800, Vince Hsu wrote:
> On 04:08:52PM Jan 07, Peter De Schrijver wrote:
> > On Wed, Jan 07, 2015 at 02:27:10PM +0100, Thierry Reding wrote:
> > 
> > > > Yeah. I plan to have the information of all the clock client of the
> > > > partitions and
> > > > the memory clients be defined statically in c source, e.g. pmc-tegra124.c.
> > > > All modules can declare which domain they belong to in DT. One domain can
> > > > be really power gated only when no module is awake. Note the clock clients
> > > > of
> > > > one domain might not equal to the clocks of the module. The reset is not
> > > > either.
> > > > So I don't get the clock and reset from module. How do you think?
> > > 
> > > This whole situation is quite messy. The above sequence basically means
> > > that drivers can't reset hardware modules because otherwise they might
> > > race with the power domain code. It also means that we can't powergate
> > 
> > The powerdomain framework won't call any powergating method as long as a
> > module in the domain is still active. So as long as drivers don't try to
> > reset the hw without having done a pm_runtime_get(), we shouldn't have such
> > a race?
> Agree. And as long as the driver has the correct reset procedure, that should
> be fine to occur between power ungating and gating sequences.
> 
> > 
> > > modules on demand because they might be in the same power domain as one
> > > other module that's still busy.
> > > 
> > 
> > The powerdomain framework keeps track of which modules are active (by hooking
> > into runtime pm) and won't try to shutdown a domain unless all modules are
> > inactive.
> Yeah. By the way, that means we should start supporting runtime pm for all
> the modules to use generic power domain.

Indeed, that'll be a prerequisite before we can merge power domain
support. I do have a couple of local patches that add very rudimentary
runtime PM for various drivers. For starters we could probably just do
the

	pm_runtime_enable(...);
	pm_runtime_get_sync(...)

in the ->probe() and

	pm_runtime_put_sync(...);
	pm_runtime_disable(...);

in the ->remove() callbacks for those drivers. That's by no means
optimal but should get us pretty close to what we do now and still
support the generic power domains.

Thierry

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ