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


On 06/10/17 14:34, Jassi Brar wrote:
> On Fri, Oct 6, 2017 at 6:57 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>
>> On 06/10/17 12:34, Jassi Brar wrote:
>>> On Wed, Oct 4, 2017 at 5:02 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>
>>>> Also, I have added shim only for specific controllers that need them.
>>>> E.g. ARM MHU as Jassi disagreed to add doorbell mechanism to that.
>>>> mbox_if provides default implementation that just calls direct mailbox
>>>> APIs.
>>>>
>>> Yeah you could hack away the MHU driver to make your life easy at the
>>> cost of duplicated code and extra DT bindings, but for a moment think
>>> what if your development platform wasn't MHU but, say, Rockchip
>>> mailbox controller?
>>>
>>
>> As mentioned before I understand your concern. But the point is this
>> needs to be replicated with each protocol on that controller.
>>
> Only generic protocols need to have a platform specific transport
> layer. There's no escaping that.
>
>> So as Arnd
>> pointed out we can reduce that by generalizing common things like doorbell.
>>
> Rockchip, and most other controllers, has no "doorbell". And yet each
> is perfectly capable of supporting SCMI.

Not sure of that, may be Linux drivers can be made to support but the
firmware needs to conform the SCMI specification. And when it does, all
we need is just notion of doorbell.

> Looking forward to your "generalised doorbell".
>

It won't be completely generic alone. The controllers need to have some
logic. It's just that they don't use any data from client, they just
signal the remote.

--
Regards,
Sudeep

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