On Fri, Oct 9, 2020 at 12:38 PM Sudeep Holla <sudeep.ho...@arm.com> wrote: > > On Sat, Sep 19, 2020 at 03:22:30PM -0400, Jim Quinlan wrote: > > only implements the agent-to-platform channel; > > In that case any reason why you can't reuse the existing smc transport > for SCMI. It was added recently in case you haven't checked the latest > kernel version(v5.8 or above). Check out for drivers/firmware/arm_scmi/smc.c > IIUC rather vaguely Florian was cc-ed on those patches.
Hi Sudeep, Sorry for the delay. As Florian mentioned, we tried to use what you've submitted but could not because in our system a return does not indicate the completion of the SCMI operation. It is indicated by an interrupt. There are a number of reasons for this and some are out of our control. > > > > we may implement the platform-to-agent channel in the future. > > This is not yet support with that transport, it is hard to generalise > as different vendors have their own solutions there. > > > An unusual aspect of this driver is how the completion of an SCMI message > > is indicated. An SCMI message is initiated with an ARM SMC call, but the > > return of this call does not indicate the execution or completion of the > > message. Rather, the message's completion is signaled by an interrupt. > > > > So are these not fast SMC/HVC calls then ? If so we may need some changes > to that driver. I just rejected multiple message support as we had assumed > fast smc/hvc. Yes, we are using fast SMC calls. We don't have multiple message support either. The disconnect we have with the smc/hvc transport commit si this: smc_send_message(...) { /* ... */ + arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res); + scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info->shmem)); In our code the second line is not here but in the interrupt handler. I don't see any way you can easily change/augment the smc/hvc transport to accommodate us. Regards, Jim > > > -- > Regards, > Sudeep
smime.p7s
Description: S/MIME Cryptographic Signature