lkml.org 
[lkml]   [2017]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface
From
Date


On 06/10/17 14:47, Jassi Brar wrote:
> On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 06/10/17 12:26, Jassi Brar wrote:
>>> On Wed, Oct 4, 2017 at 5:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> This patch adds ARM MHU specific mailbox interface for SCMI.
>>>>>
>>>>> Cc: Arnd Bergmann <arnd@arndb.de>
>>>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>>>
>>>> This clearly needs an explanation why we need another driver.
>>>>
>>> Yes the patch needs explanation which is that we need a shim layer to
>>> map SCMI requests onto what the underlying controller expects. The
>>> alternative was to clone the controller driver (MHU now and others
>>> later when their platforms support SCMI) and pretend SCMI is the only
>>> client they are ever going to serve.
>>>
>>
>> Again that's not the point, doorbell is more common feature and that can
>> be supported. As SCMI expects doorbell feature in the specification, it
>> just need to support that class of controllers.
>>
> NO. All SCMI expects is SHMEM and a signal reaching the other end.
> The signal mechanism need not necessarily be "doorbell".
>

Agreed, but creating an abstraction ro do something as generic as
doorbell and writing shim layer for each controller to use SCMI also
sounds bad.

--
Regards,
Sudeep

\
 
 \ /
  Last update: 2017-10-06 15:52    [W:0.080 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site