Re: 回复: 回复: 回复: [EXT] Re: [PATCH v3 02/17] firmware: scmi: smt: Interrupt communication enable

[Marek Vasut]

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 <marex at denx.de>
>>>> 发送时间: 2025年1月7日 19:11
>>>> 收件人: Alice Guo (OSS) <alice.guo at oss.nxp.com>; Tom Rini
>>>> <trini at konsulko.com>; Stefano Babic <sbabic at denx.de>; Fabio Estevam
>>>> <festevam at gmail.com>; dl-uboot-imx <uboot-imx at nxp.com>; Lukasz
>>>> Majewski <lukma at denx.de>; Sean Anderson <seanga2 at gmail.com>; Simon
>>>> Glass <sjg at chromium.org>; Alper Nebi Yasak <alpernebiyasak at gmail.com>
>>>> 抄送: u-boot at lists.denx.de; tharvey at gateworks.com; Viorel Suman
>>>> <viorel.suman at nxp.com>; Ye Li <ye.li at nxp.com>
>>>> 主题: 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 <viorel.suman at nxp.com>
>>>>>>>>>
>>>>>>>>> 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 ?