On 09/07/2016 01:55 PM, Kevin Hilman wrote:
Nishanth Menon <nm@xxxxxx> writes:
[...] full mail thread in https://lkml.org/lkml/2016/9/6/747
Overall architecture is very similar to SCPI[4] as follows:
Dumb Q: I'm curious about the limitations in SCPI that were found that
made TI decided to implement its own version.
Not really a dumb question.. (and praying I dont trigger a flame war
:D) I will skip the approximately year something worth of discussions
and TI's Linaro connect requests for consolidation of standards aside,
lets not forget to add ARM's new protocol proposal to the list that I
cant seem to find public reference to (ccying folks in case I have'nt
looked the right place in http://infocenter.arm.com), but which also
developed in parallel to TI-SCI. Anyways..
Just as a background for new folks: ARM Power Control System
Architecture Specification Version (ARM DEN 0050) (which you'd need to
contact ARM to get access to) strongly recommends System Control
Processor - but ofcourse, SCPI evolved as ARMs way of solving the Juno
problem set (and Sudeep can probably add lots of backgrounds on that).
And SCPI is not, at least to my knowledge, mandatory for ARM vendors
to follow. It probably suffices to say that ARM had SCPI and TI
developed TI-SCI.
Now, to answer your question, why did we not just use SCPI instead of
re-inventing the wheel? To be honest, and folks who have the year
something background know this: We really did not want to spin our own.
SCPI and TISCI or other similar protocols tend to have few constraints
to work with:
a) messaging infrastructure and capabilities ARM MHU Vs what we have
for TI message Manager (one word vs upto 128 queued 64byte messages in
message manager from multiple simultaneous requesters)- examples being
virtualized pipes and sizes we have for communication allows our
protocol to optimize messaging appropriate to the SoC.
b) SoC architecture and constraints required of that - examples: here
being the processing entities, multitude variations of integrations
and SoC spins, required higher level of abstraction to even have a
resemblance of sanity at HLOS level.
c) To a minor extent, not really relevant for this thread: timelines
of parallel development and influence from corresponding SoC and other
stakeholders within each corporates.
Long story short, investigation was done into what SCPI was providing
(TI internal ofcourse) and SCPI did not fit our SoC generation needs -
-
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922g/index.html
vs http://processors.wiki.ti.com/index.php/TISCI is available to
compare and contrast but the key highlights are probably as follows:
- SCPI seems to be constrained around capabilities of MHU and does
not allow better leverage of h/w K2G (and future SoCs) have
capabilities of.
- SCPI abstraction levels did not fit our SoC architecture models we
are moving to where ARM cores running Linux are optional and no longer
the system master of the SoC - we do have non-ARM SoCs as well in our
SoC portfolio and obviously non-Linux solutions as well. some little
details:
- From being able to mandate response messages which can be tuned
from "dont bother to tell me once you are done" to fine grained as
"tell me when you get around to this operation but let me know before
you actually process" as optional states for any type of messages
- Levels of abstraction of "I dont care what you in system
controller do as long as my Display Subsystem func clk runs as xyz Hz"
- we need to care about hardware block level operation, not how the
SoC intricacies of operating the hardware block is.. example we need
capability to hold a hardware block active from two processing
entities for blocks that are capable of doing so (example: GPIO and
blocks with virtualized view capability)
and obviously more..
Obviously, each protocol could claim superiority of level of
control/abstraction provided based on SoC arch targeted etc.. but I
will try and avoid getting into that debate.
--
Regards,
Nishanth Menon
--
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
