(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@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
