From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Rutland <mark.rutland@arm.com>
Date: Fri, 23 Jan 2015 14:08:06 +0000
Subject: [U-Boot] [PATCH v1 0/4] Jetson-TK1 support for PSCI
In-Reply-To: <20150123123720.GK23493@leverpostej>
References: <1421178290.11796.159.camel@hellion.org.uk>
	<20150114075724.GD9491@ulmo.nvidia.com>
	<20150115191937.GB20171@leverpostej>
	<20150116091258.GB9170@ulmo.nvidia.com>
	<20150122192015.GF12911@leverpostej>
	<20150123101044.GA11479@ulmo.nvidia.com>
	<20150123123720.GK23493@leverpostej>
Message-ID: <20150123140806.GM23493@leverpostej>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

[...]

> > > PSCI assumes that the FW is in full control of the registers it's
> > > poking. While a lock isn't necessarily bad, I suspect it's going to be
> > > very difficult to have that common across all users without the code
> > > becoming unmaintainable fast. I'd also hope that for arm64 we wouldn't
> > > need it.
> > > 
> > > When/how/why does the kernel to poke these registers?
> > 
> > The PMC is what controls power partitions. Some of these partitions are
> > assigned to CPUs, others are assigned to things like SATA, PCIe, display
> > and so on. The problem is that if we manage the CPU power partitions via
> > the firmware, then they will conflict with calls that we need to make
> > from other drivers that need to gate or ungate the partitions for their
> > hardware. As I understand it there's no provision in PSCI to manage non-
> > CPU devices, so this is a problem.
> 
> Ok.
> 
> > So I think either firmware needs to control everything, in which case we
> > are going to need a new interface (or extend PSCI) or it mustn't control
> > anything, in which case we need custom code in the kernel for SMP. Well,
> > the other alternative would be the lock that we can grab in the
> > powergate API and the PSCI calls.
> 
> One reason I'm not so keen on a lock is I could imagine you'd need to
> grab this for CPU_SUSPEND calls (i.e. cpuidle), at which point all CPUs
> are going to contend for the lock all the time.
> 
> One thing to bear in mind is that PSCI is only one user of the SMC
> space. Per SMC calling convention, portions of the SMC ID space are
> there to be used for other (vendor-specific) purposes.
> 
> So rather than extending PSCI, a parallel API could be implemented for
> power control of other devices, and the backend could arbitrate the two
> without the non-secure OS requiring implementation-specific mutual
> exclusion.
> 
> I think this has been brought up internally previously; I'll go and poke
> around in the area to see if we managed to figure out anything useful.

It sounds like what we figured out internally is roughly what I stated
above:

Allocate some SMC calls in the SIP and/or OEM Service Calls range for
vendor-specific device power management, and have the implementation on
the secure side (which would do the actual register poking) arbitrate
with any other secure-side access to those registers (i.e. CPU power
management, which it will already have to arbitrate).

Thanks,
Mark.