[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABb+yY04F0zuiD8iW=m2wPCqftoe+VmcGzzRCXp184JKr25KPw@mail.gmail.com>
Date: Thu, 6 Jul 2017 11:58:33 +0530
From: Jassi Brar <jassisinghbrar@...il.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Rob Herring <robh@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Devicetree List <devicetree@...r.kernel.org>,
Alexey Klimov <alexey.klimov@....com>,
Jassi Brar <jaswinder.singh@...aro.org>
Subject: Re: [PATCH v2 2/6] Documentation: devicetree: add bindings to support
ARM MHU doorbells
On Wed, Jul 5, 2017 at 11:32 PM, Sudeep Holla <sudeep.holla@....com> wrote:
>
> I have posted the SCMI patches now[1],
>
I wish I was CC'ed on that. Now LKML seems too busy to forward it.
> please let me know how to get
> both SCPI and SCMI working together with different doorbell bits on the
> same channel.
>
You say in the cover letter :
"Let me begin admitting that we are introducing yet another protocol to
achieve same things as many existing protocols like ARM SCPI, TI SCI,
QCOM RPM, Nvidia Tegra BPMP, and so on"
So SCMI is supposed to replace SCPI, SCI, RPM and BPMP or SCMI is
to be used for future platforms.
If SCPI and SCMI achieve the same, why have them both active simultaneously?
Assuming there really is some sane excuse :-
SCPI and SCMI are two separate client working over an MHU channel.
So, as is the case with users relying on a common resource, you need a
shim arbitrator that serialises access to the resource.
Powered by blists - more mailing lists