[PATCH v3 2/2] mailbox: Add Broadcom STB mailbox driver

[Jim Quinlan]

On Fri, Oct 9, 2020 at 12:38 PM Sudeep Holla <sudeep.holla at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4167 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20201021/bd30e471/attachment-0001.p7s>