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

[Oleksii Moisieiev <Oleksii_Moisieiev@xxxxxxxx>]

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.

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.