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

[Peng Fan <peng.fan@oss.nxp.com>]

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

Regards,
Peng