On 1/10/25 10:59 AM, Peng Fan wrote:
On Wed, Jan 08, 2025 at 07:38:30PM +0100, Marek Vasut wrote:
On 1/8/25 3:55 AM, Alice Guo (OSS) wrote:
-----邮件原件-----
发件人: Marek Vasut <[email protected]>
发送时间: 2025年1月7日 19:11
收件人: Alice Guo (OSS) <[email protected]>; Tom Rini
<[email protected]>; Stefano Babic <[email protected]>; Fabio Estevam
<[email protected]>; dl-uboot-imx <[email protected]>; Lukasz
Majewski <[email protected]>; Sean Anderson <[email protected]>; Simon
Glass <[email protected]>; Alper Nebi Yasak <[email protected]>
抄送: [email protected]; [email protected]; Viorel Suman
<[email protected]>; Ye Li <[email protected]>
主题: Re: 回复: 回复: [EXT] Re: [PATCH v3 02/17] firmware: scmi: smt:
Interrupt communication enable
On 1/7/25 4:24 AM, Alice Guo (OSS) wrote:
主题: Re: 回复: [EXT] Re: [PATCH v3 02/17] firmware: scmi: smt: Interrupt
communication enable
On 1/6/25 7:17 AM, Alice Guo (OSS) wrote:
On 1/3/25 7:45 AM, Alice Guo wrote:
From: Viorel Suman <[email protected]>
When interrupt driven communication is supported
U-Boot does not use interrupts.
, the transport allows
the caller to choose between interrupt and polling driven
communications. To make the choice, the channel flags are used.
i.MX95 uses interrupt driven communication so that Channel flags
should be set to 1.
How does this work in U-Boot, which does not use interrupts ?
Hi Marek,
The clearer explanation will be added in the commit log.
This is based on Arm® System Control and Management Interface
Platform
Design Document Version 3.2 (Document number: DEN0056E) 5.1.2. When
Bit[0] of Channel flags is 1, the System Manager runs on M core will
trigger general-purpose interrupts to A core. U-Boot polls
General-purpose Status (GSR) until GIPn is set.
If U-Boot does polling, why does this bit need to be set, shouldn't
the bit be cleared instead ?
My commit log may have caused your misunderstanding. If the bit is not set,
the System Manager will not request doorbell interrupt. The following is the
code from imx-sm:
if (callee)
{
/* Generate completion interrupt */
if ((buf->channelFlags & SMT_COMP_INT) != 0U)
{
status = RPC_SMT_DoorbellRing(smtChannel);
}
}
Can the SM be updated instead ?
System Manager not only interacts with U-Boot, but also with Linux/QNX/RTOS.
System Manager cannot be changed.
How come other SCMI providers (like optee) do not need this kind of change ?
Here to i.MX SM, this is just a doorbell to tell remote side that info
is ready. To U-Boot i.MX, MU GSR set means SM sends data back, so with COMP_INT
set, U-Boot could poll the MU GSR bit. Using interrupt here is not that
accurate, it is just a doorbell.
For OP-TEE, it is using SMC, it is sync transports, SMC return means SCMI done.
No need polling any bit or else.
In that case, do you need to check the DT /firmware/scmi node compatible
string for compatible="arm,scmi-smc" and enable this flag only if the
compatible is "arm,scmi", and disable the flag otherwise ?
