Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver

From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Oleksii Moisieiev <Oleksii_Moisieiev@epam.com>
Cc: Julien Grall <julien@xen.org>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [RFC v2 5/8] xen/arm: introduce SCMI-SMC mediator driver
Date: Mon, 14 Feb 2022 11:27:21 +0000	[thread overview]
Message-ID: <E78206B4-3793-498E-A580-F0561DF6D4AC@arm.com> (raw)
In-Reply-To: <20220214111300.GA3615313@EPUAKYIW015D>

Hi Oleksii,

> On 14 Feb 2022, at 11:13, Oleksii Moisieiev <Oleksii_Moisieiev@epam.com> wrote:
> 
> Hi Julien,
> 
> On Sat, Feb 12, 2022 at 12:43:56PM +0000, Julien Grall wrote:
>> Hi,
>> 
>> On 11/02/2022 11:18, Bertrand Marquis wrote:
>>> Do you plan to add support for other boards ?
>>> 
>>> Did you discuss more in general with the linux kernel guys to see if this
>>> approach was agreed and will be adopted by other manufacturers ?
>>> 
>>> All in all I think this is a good idea but I fear that all this will actually only
>>> be used by one board or one manufacturer and other might use a different
>>> strategy, I would like to unrisk this before merging this in Xen.
>> 
>> In the past we merged code that would only benefits one vendor (i.e. EEMI).
>> That said, this was a vendor specific protocol. I believe the situation is
>> different here because the spec is meant to be generic.
>> 
>>> @julien and Stefano: what is your view here ?
>> 
>> I share the same concerns as you. I think we need to make sure all the
>> pieces we rely on (e.g. firmware, DT bindings) have been agreed before we
>> can merge such code in Xen.
>> 
>> The first step is to have all the pieces available in public so they can be
>> reviewed and tested together.
>> 
>> Oleksii, on a separate e-mail, you said you made change for ATF. How much of
>> those changes was related to support for Xen? If they are some, then I think
>> they should be upstreamed first.
>> 
> 
> Let me share changes, that were done to AT-F and Linux kernel
> device-tree in terms of the SCMI mediator POC.
> Changes to the Linux kernel:
> https://github.com/oleksiimoisieiev/arm-trusted-firmware/pull/4
> Based on renesas-rcar linux-bsp, branch v5.10/rcar-5.0.0.rc5
> 
> Changes to AT-F:
> https://github.com/oleksiimoisieiev/linux-bsp/pull/3
> Based on renesas-rcar/arm-trusted-firmware branch rcar_gen3_v2.5.

You inverted the links but thanks this is really useful.

Did you push the ATF changes to mainstream ATF or discuss those with
the maintainers ?

The strategy overall is nice but we need to make sure this is accepted and
 merged by all parties (ATF and Linux) to make sure the support for this will
not only be available in Xen and for one board.

I will try to get in touch with the SCMI linux driver maintainer at arm to get his view.

Regards
Bertrand

> 
> All changes that were done are not Xen specific. Given AT-F changes are
> the implementation of the SCMI feature using SMC as transport. All
> changes were done accoding to the DEN0056C [0] and DEN0028D [1].
> 
> We pass channel_id via SMC to the Firmware on r7 bits [15:0] (See Section
> 4.1 of [1]). Then Firmware converts channel_id to agent_id. Channel_id can't be
> equal to agent_id in our case, because, according to the 4.2.2.8 of [0]
> - agent_id 0 is reserved to identify platform itself.
> 
> 
> [0] https://developer.arm.com/documentation/den0056/latest
> [1] https://developer.arm.com/documentation/den0028/latest
> 
> Best regards,
> Oleksii.