Re: [PATCH v1 0/2] Add support for Xilinx ZynqMP SoC

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Mon, Mar 09, 2015 at 11:09:13AM +0000, Ian Campbell wrote:
> On Mon, 2015-03-09 at 13:14 +1000, Edgar E. Iglesias wrote:
> > On Fri, Mar 06, 2015 at 09:44:16AM +0000, Ian Campbell wrote:
> > > On Fri, 2015-03-06 at 11:31 +1000, Edgar E. Iglesias wrote:
> > > > On Thu, Mar 05, 2015 at 04:50:15PM +0000, Ian Campbell wrote:
> > > > > On Thu, 2015-03-05 at 18:27 +1000, Edgar E. Iglesias wrote:
> > > > > > From: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com>
> > > > > > 
> > > > > > Adds support for the Cadence UART in Xilinx ZynqMP. The
> > > > > > rest of the ZynqMP platform is discovered via device-tree.
> > > > > 
> > > > > Is it fully discovered and working out of the box? That would be ....
> > > > > awesome!
> > > > 
> > > > Yes it would be awesome if we can keep it like that :-)
> > > 
> > > I suppose you are seeing the "WARNING: Unrecognized/unsupported device
> > > tree compatible list" message?
> > 
> > Yes, thats right.
> > 
> > > 
> > > I wonder if we should either remove or tone down that warning, now that
> > > we have a platform which genuinely doesn't require any platform specific
> > > code. I think we probably want to say something so in bug reports we
> > > know what is happening, maybe just something like "Platform: Generic
> > > System".
> > 
> > 
> > Sounds good to me, I can send a follow up patch for that.
> 
> I've seen it and put it in my (rather long) list of things to look at,
> thanks!
> 
> > > > It's possible that we will need to add platform code in the future
> > > > as we test out more features. In particular we'll likely need to do
> > > > something around power/clock management.
> > > 
> > > Yes, this is something of an open problem for us, and one which I'm
> > > unsure how to solve without some platform specific code in each case.
> > > 
> > > Most power/clock management should be deferred to the h/w domain which
> > > is managing the I/O peripherals (likely dom0) but we need some way to
> > > filter its activities to keep e.g. the CPU and UART (or in reality any
> > > h/w block Xen itself is using, which isn't many fortunately) clocks on.
> > > 
> > > http://bugs.xenproject.org/xen/bug/45 is a related bug.
> > 
> > Very interesting, thanks.
> > 
> > There is another dimenson to the power/clock problem. The ZynqMP has a
> > runtime programmable TrustZone system partitioning block in the interconnect.
> > Something similar to ARMs TZASC. This allows you to program the
> > Secure/Non-Secure device partitioning for example at boot time.
> > Depending on the split, it might not be OK to give NS Linux or even
> > NS XEN direct access to the power/clock configuration registers.
> > I.e, we don't want NS Linux to power down a device currently in use
> > by a Trusted OS.
> > 
> > What we are considering is an extension to the PSCI approach, an SMC
> > interface to expose the low level power/clock operations.
> > 
> > Linux can still have all the smart control logic for Power Management
> > but an SMC interface would allow the various layers (XEN EL2,
> > ARM trusted firmware EL3) to filter or emulate the various requests.
> > 
> > Ofcourse, the devil will be in the details...
> > 
> > It would be interesting to hear your and others thought on that kind
> > of approach.
> 
> It's an interesting approach, and not without precedent AIUI. And I
> think you are right to make the link between NS.EL1 vs NS.EL2 and NS.EL*
> vs S.EL*, they are very similar problems in the end.
> 
> We've not actually come across such a platform yet, but I think it is
> inevitable that eventually we will need to trap platform specific SMC
> calls from dom0 on some platform and decide what to do with them on a
> per-operation basis (quash them, emulate them, forward them to S world,
> etc).
> 
> If such an interface was available for power/clock then I think that
> would be preferable to trapping and emulating register writes and
> white/blacklisting individual register bits etc.
> 
> Best of all, I think, at least from Xen's PoV, would be if there was
> some PSCI-like overall standard which all vendors used for this, such
> that Xen could grow a more generic framework for SMC traps of this type.

Yes, such a standard would be great.

Thanks alot for your comments!

Cheers,
Edgar