Message-ID: <02f505e2-132c-477a-1e6b-6a060ef3f404@gmail.com>
Date:   Thu, 27 Jun 2019 11:10:05 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Sudeep Holla <sudeep.holla@....com>
Cc:     Peng Fan <peng.fan@....com>, Jassi Brar <jassisinghbrar@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        ", Sascha Hauer" <kernel@...gutronix.de>,
        dl-linux-imx <linux-imx@....com>,
        Shawn Guo <shawnguo@...nel.org>,
        "festevam@...il.com" <festevam@...il.com>,
        Devicetree List <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Andre Przywara <andre.przywara@....com>,
        "van.freenix@...il.com" <van.freenix@...il.com>
Subject: Re: [PATCH V2 2/2] mailbox: introduce ARM SMC based mailbox

On 6/26/19 10:09 AM, Sudeep Holla wrote:
> On Wed, Jun 26, 2019 at 09:44:06AM -0700, Florian Fainelli wrote:
>> On 6/26/19 6:31 AM, Peng Fan wrote:
>>>>> The firmware driver might not have func-id, such as SCMI/SCPI.
>>>>> So add an optional func-id to let smc mailbox driver could
>>>>> use smc SiP func id.
>>>>>
>>>> There is no end to conforming to protocols. Controller drivers should
>>>> be written having no particular client in mind.
>>>
>>> If the func-id needs be passed from user, then the chan_id suggested
>>> by Sudeep should also be passed from user, not in mailbox driver.
>>>
>>> Jassi, so from your point, arm_smc_send_data just send a0 - a6
>>> to firmware, right?
>>>
>>> Sudeep, Andre, Florian,
>>>
>>> What's your suggestion? SCMI not support, do you have
>>> plan to add smc transport in SCMI?
>>
>> On the platforms that I work with, we have taken the liberty of
>> implementing SCMI in our monitor firmware because the other MCU we use
>> for dynamic voltage and frequency scaling did not have enough memory to
>> support that and we still had the ability to make that firmware be
>> trusted enough we could give it power management responsibilities. I
>> would certainly feel more comfortable if the SCMI specification was
>> amended to indicate that the Agent could be such a software entity,
>> still residing on the same host CPU as the Platform(s), but if not,
>> that's fine.
>>
> 
> That's completely legal and there's nothing in the specification that
> prohibits. I understand it's not explicitly not mentioned and I have
> been trying to get such things clarified. But since it's main focus
> is on the message protocol, the clarity on transport mechanism is very
> thin and there's hesitation to add more details under the impression
> that it may restrict the usage.
> 
> But as I mentioned, I understand what you need there :)
> 
>> This has lead us to implement a mailbox driver that uses a proprietary
>> SMC call for the P2A path ("tx" channel) and the return being done via
>> either that same SMC or through SGI. You can take a look at it in our
>> downstream tree here actually:
>>
>> https://github.com/Broadcom/stblinux-4.9/blob/master/linux/drivers/mailbox/brcmstb-mailbox.c
>>
> 
> Just curious, I see it's fast call and why do you still depend on
> interrupt to indicate completion of the message. Will the return from
> SMC not suffice ? Sorry if I am missing something obvious.

It is currently used for synchronous delayed responses where the SMC
call returns early, but the operation is carried out asynchronously by
e.g: the MCU that does voltage scaling a few milliseconds later. We'd
rather not block the caller for too long and that's where it stems from.
-- 
Florian

Powered by blists - more mailing lists