[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1182e5f8-2588-32ff-8380-04273c28d1cd@xilinx.com>
Date: Mon, 7 Aug 2017 08:09:32 +0200
From: Michal Simek <michal.simek@...inx.com>
To: Alexander Graf <agraf@...e.de>,
Michal Simek <michal.simek@...inx.com>
CC: <linux-arm-kernel@...ts.infradead.org>,
Punnaiah Choudary Kalluri
<punnaiah.choudary.kalluri@...inx.com>,
Baoyou Xie <baoyou.xie@...aro.org>,
Bharat Kumar Gogada <bharatku@...inx.com>,
Lucas Stach <l.stach@...gutronix.de>,
Rob Herring <robh+dt@...nel.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Catalin Marinas <catalin.marinas@....com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
yangbo lu <yangbo.lu@....com>,
Sören Brinkmann <soren.brinkmann@...inx.com>,
Alexandre Belloni <alexandre.belloni@...e-electrons.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Will Deacon <will.deacon@....com>,
<devicetree@...r.kernel.org>,
Andreas Färber <afaerber@...e.de>,
Moritz Fischer <mdf@...nel.org>,
Michal Simek <monstr@...str.eu>,
Mark Rutland <mark.rutland@....com>,
Shawn Guo <shawnguo@...nel.org>,
Simon Horman <horms+renesas@...ge.net.au>,
<linux-kernel@...r.kernel.org>, Marc Zyngier <marc.zyngier@....com>
Subject: Re: [PATCH 0/3] arm64 xilinx zynqmp firmware interface
On 5.8.2017 06:23, Alexander Graf wrote:
>
>
>> Am 04.08.2017 um 15:45 schrieb Michal Simek <michal.simek@...inx.com>:
>>
>> Hi,
>>
>> xilinx is using this interface for very long time and we can't merge our
>> driver changes to Linux because of missing communication layer with
>> firmware. This interface was developed before scpi and scmi was
>> available. In connection to power management scpi and scmi are missing
>> pieces which we already use. There is a separate discussion how to
>> extend scmi to support all our use cases.
>> This simply patch is not adding any power management features but only
>> adding minimum functionality which are needed for drivers.
>
> If you're thinking of changing the interface later down the road, wouldn't it make sense to probe EL3 for its existence?
You could then expose this interface on today's EL3 and something
scpi/scmi based on tomorrow's.
Right now driver is checking pmu firmware version. Based on this it is
clear how to communicate with it. The same checking could be there for
ATF version. Both of these should tell you exactly what's the
communication channel.
If we decide to use scmi or any other implementation we will increase
versions.
Thanks,
Michal
Powered by blists - more mailing lists