Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1700862 > unrolled thread

Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox Alexander Graf <agraf@suse.de> - 2017-08-01 13:00 +0200
    Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox Jassi Brar <jassisinghbrar@gmail.com> - 2017-08-01 18:00 +0200
      Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox Sudeep Holla <sudeep.holla@arm.com> - 2017-08-02 19:00 +0200

#1700862 — Re: [PATCH v2 0/3] mailbox: arm: introduce smc triggered mailbox

Hi Andre,

On 24.07.17 01:23, Andre Przywara wrote:
> This is a reworked version of my previous post. It addresses Jassi's
> comments on the driver and also tries to cover Rob's and Mark's comments
> on the binding documentation.
> I dropped the more example-like DT changes from v1, as they are actually
> not meant to be merged into the Linux tree, but instead are provided as
> part of some firmware actually implementing this functionality.
> 
> Please let me know what you think.

Could you please quickly explain what it would take to provide SCMI on 
top of this instead of SCPI?

https://lkml.org/lkml/2017/6/7/624

I can certainly see that SCPI is an easier target because it's already 
upstream and widely spread. But wouldn't it make sense to jump on the 
SCMI train while it's taking steam?


Thanks,

Alex

[toc] | [next] | [standalone]

#1701179

On Tue, Aug 1, 2017 at 4:20 PM, Alexander Graf <agraf@suse.de> wrote:
> Hi Andre,
>
> On 24.07.17 01:23, Andre Przywara wrote:
>>
>> This is a reworked version of my previous post. It addresses Jassi's
>> comments on the driver and also tries to cover Rob's and Mark's comments
>> on the binding documentation.
>> I dropped the more example-like DT changes from v1, as they are actually
>> not meant to be merged into the Linux tree, but instead are provided as
>> part of some firmware actually implementing this functionality.
>>
>> Please let me know what you think.
>
>
> Could you please quickly explain what it would take to provide SCMI on top
> of this instead of SCPI?
>
> https://lkml.org/lkml/2017/6/7/624
>
The SCMI (and SCPI) code is broken, that is, unless the firmware/SM is
trained to ignore the random value (pointer to a structure) passed via
R1. Which may be possible to do, but is surely a sign of poor
implementation. And may not be possible if some protocol other than
SCMI runs in parallel.

Andre, your take please?

Thanks.

[toc] | [prev] | [next] | [standalone]

#1702274

(sorry for SCPI/SCMI discussion in this thread)

On 01/08/17 16:50, Jassi Brar wrote:
> On Tue, Aug 1, 2017 at 4:20 PM, Alexander Graf <agraf@suse.de> wrote:
>> Hi Andre,
>>
>> On 24.07.17 01:23, Andre Przywara wrote:
>>>
>>> This is a reworked version of my previous post. It addresses Jassi's
>>> comments on the driver and also tries to cover Rob's and Mark's comments
>>> on the binding documentation.
>>> I dropped the more example-like DT changes from v1, as they are actually
>>> not meant to be merged into the Linux tree, but instead are provided as
>>> part of some firmware actually implementing this functionality.
>>>
>>> Please let me know what you think.
>>
>>
>> Could you please quickly explain what it would take to provide SCMI on top
>> of this instead of SCPI?
>>
>> https://lkml.org/lkml/2017/6/7/624
>>
> The SCMI (and SCPI) code is broken, that is, unless the firmware/SM is
> trained to ignore the random value (pointer to a structure) passed via
> R1. Which may be possible to do, but is surely a sign of poor
> implementation. And may not be possible if some protocol other than
> SCMI runs in parallel.
> 

Since SCPI and SCMI are based on doorbell designs like ACPI PCC, they
can't send any data as all the data are part of shared memory.

What data needs to be sent from SCPI/SCMI as part of mbox_send_message
in your opinion ? I can't think of any generic way to form this data.

It's not possible to generalize that and SCPI/SCMI's transport is
specifically designed in that way to avoid any kind of dependency
on the mailbox hardware so that the protocol can be generic exactly like
ACPI PCC.

I understand your concern on how existing mailbox controllers work with
it. They can't as they stand today as they expect some specific data
based on the hardware or the protocol they support on it.

One option to deal with this is to have a generic DT based doorbell kind
of controller driver but I am not sure if we can define register level
bindings like ACPI PCC.

Or we teach them to ignore the data if it's not present. I don't like
the idea of adding shim layer for each of the controller as each one
expect different format and more over SCPI/SCMI doesn't even require it
to support SCMI on those mailbox controllers. That may end up with 2x
drivers(one actual driver and and another shim layer for it)

-- 
Regards,
Sudeep

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web