Re: [PATCH v3 02/22] dt-bindings: arm: add support for ARM System Control and Management Interface(SCMI) protocol

From: Arnd Bergmann
Date: Thu Oct 05 2017 - 07:56:23 EST

On Wed, Oct 4, 2017 at 4:47 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
> On 04/10/17 15:17, Arnd Bergmann wrote:
>> On Wed, Oct 4, 2017 at 3:53 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
>>> On 04/10/17 13:35, Arnd Bergmann wrote:
>>>> On Wed, Oct 4, 2017 at 1:07 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:

>> There are probably several ways of doing this better, we should see
>> what the best is we can come up with.
>> I think generally speaking we need a way for a mailbox user to
>> know what it should use as the mailbox data here, so it is
>> able to talk to different incompatible mailbox providers.
>> One idea I had is to use a nested mailbox driver, that turns
>> a doorbell or single-register styled mailbox into a variable-length
>> mailbox by adding a memory region, like
>> mailbox@1233000 {
>> compatible = "vendor-hardware-specifc-id";
>> interrupts = <34>;
>> reg = <0x1233000 0x100>;
>> #mbox-cells = <1>;
>> };
>> mailbox {
>> compatible = "shmem-mailbox";
>> mboxes = <&/mailbox@1233000 25>;
>> #mbox-cells = <1>;
>> shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
>> };
>> This would create one mailbox that only takes a register argument,
>> and another one that can take longer messages based on the first.
>> In your driver, you then refer to the second one and pass the
>> variable-length data into that directly.
> 1. IIUC it was intentional not to include shmem as part of mailbox
> controller binding and was pushed to client drivers as it's generally
> not part of mailbox IP block. I am not sure if there are any other
> specific reasons for that, but I may be missing some facts.

Ok, I see.

> 2. I am not sure if we need nested driver/bindings (at-least to begin
> with). On a platform I don't think both/all modes will be used.
> I had proposal for adding doorbell for ARM MHU based on extended
> bindings, but it was rejected[1]. But I really preferred that over
> the shim layer I had to add in v3.

Maybe we can come up with a more generic way to do doorbells
on top of mailboxes instead? This sounds like a problem that
would come back with other drivers, so the MHU-specific shim
will not be a permanent solution either.