On Wed, Oct 4, 2017 at 4:47 PM, Sudeep Holla [off-list ref] wrote:

On 04/10/17 15:17, Arnd Bergmann wrote:

quoted

On Wed, Oct 4, 2017 at 3:53 PM, Sudeep Holla [off-list ref] wrote:

quoted

On 04/10/17 13:35, Arnd Bergmann wrote:

quoted

On Wed, Oct 4, 2017 at 1:07 PM, Sudeep Holla [off-list ref] wrote:

quoted

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 at 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.

       Arnd