Title: SCMI - System Management and Control Interface Abstract: In this session we present a new standard proposal for system control and management. The industry, both in high end mobile and enterprise, is trending towards the use of power and system controllers. In most cases the controllers have very similar communication mechanisms between application processors and controllers. In addition, these controllers generally provide very similar functions, e.g. DVFS, power domain management, sensor management. This standard proposal provides an extensible, OS agnostic, and virtualizable interface to access these functions. Speaker(s):Charles Garcia-Tobin

1. ENGINEERS AND DEVICES
WORKING TOGETHER
System
Control
and
Management
Interface
Charles
García-­‐Tobin

2. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS
AND DEVICES
WORKING
TOGETHER
Agenda
• What’s
this
all
about
• Requirements
of
SCMI
• What’s
the
status

3. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
A
nice
future
We’d
like
a
common
methodology
for
system
management
functions
This
requires
a
method
that
is:
1. Extensible
2. OS
agnostic:
○Virtualizable so that guest or host drivers look the same
○So we can run other OSs
3. Wide
coverage:
work
across
segments
from
mobile
to
enterprise
and
anywhere
in
between
Standard
interfacesProprietary
interfaces
Past Future

4. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
We
are
not
really
there
L but
there
are
opportunities
J
● PSCI
fixes
this
for
core
power
management,
but
not
performance
management
or
peripheral
device
management
● ACPI
covers
many
of
the
gaps
in
ACPI
but
has
low
level
of
adoption
outside
enterprise
● Everybody
has
to
implement
the
same
functions
● In
many
segments
everybody
is
doing
this
in
similar
ways
○ There
is
a
strong
trend
to
use
system
level
controllers,
all
with
very
similar
interfaces
● ARM
has
published
the
Power
System
Control
Architecture
(PSCA)
which
covers
the
use
of
system
controllers
with
ARM
IP

5. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
SCMI
system
control
and
management
interface
● SCMI
is
an
extensible
interface
covering
performance
and
power
functions
● Aim
is
to
create
an
interface
that
can
be
driven
from
ACPI,
or
directly
from
kernel
● Builds
on
strong
trend
in
the
industry
towards
µC
based
platform
controllers
● Candidate
version
for
review
○ http://connect.arm.com/dropzone/systemarch/DEN0056A_S
ystem_Control_and_Management_Interface_candidate_B.p
df
OS
Device Power Sensors
System Management and Control Interface (SCMI)
Platform Controller
Power
domain prt
Perf domain
protocol
Power domain
protocol
Sensors
protocol
Mailbox
Doorbel
Mailbox
Doorbel
Other transport
Mailbox
Doorbel
Mailbox
Doorbel
Mailbox
Doorbell
PSCI
ACPI / DT
Core
Power
Core
perf

6. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
SCMI
structure
SCMI
is
split
into
two
layers:
● Protocols:
The
services
you
want
to
provide:
○ Device Power/Perf management
○ Core perf management
○ Sensor management
● Transports:
The
mechanism
by
which
the
service
is
communicated
between
the
OS
and
system
controllers
OS
Device Power Sensors
System Management and Control Interface (SCMI)
Platform Controller
Power
domain prt
Perf domain
protocol
Power domain
protocol
Sensors
protocol
Mailbox
Doorbel
Mailbox
Doorbel
Other transport
Mailbox
Doorbel
Mailbox
Doorbel
Mailbox
Doorbell
PSCI
ACPI / DT
Core
Power
Core
perf

7. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
Power
domain
protocol
•PROTOCOL_ATTRIBUTES
•PROTOCOL_VERSION
•PROTOCOL_MESSAGE_ATTRIBUTES
•POWER_DOMAIN_ATTRIBUTES
•POWER_STATE_GET
•POWER_STATE_SET
•POWERT_STATE_NOTIFY
•POWER_STATE_CHANGED
•Optional
Shared
Memory
for
stats
Performance
domain
protocol
•PROTOCOL_ATTRIBUTES
•PROTOCOL_VERSION
•PROTOCOL_MESSAGE_ATTRIBUTES
•PERFORMANCE_DOMAIN_ATTRIBUTES
•PERFORMANCE_DESCRIBE_LEVELS
•PERFORMANCE_LIMITS_GET
•PERFORMANCE_LIMITS_SET
•PERFORMANCE_LEVEL_GET
•PERFORMANCE_LEVEL_SET
•PERFORMANCE_NOTIFY_LIMIT
•PERFORMANCE_NOTIFY_LEVEL
•PERFORMANCE_LIMIT_CHANGED
•PERFORMANCE_LEVEL_CHANGED
•Optional
Shared
Memory
for
stats
Protocols
examples
• There
are
additional
protocols
to
cover
sensors,
clocks
and
binary
transfer
Discovery
protocol
•PROTOCOL_ATTRIBUTES
•PROTOCOL_VERSION
•PROTOCOL_MESSAGE_ATTRIBUTES
•DISCOVER_VENDOR
•DISCOVER_SUB_VENDOR
•DISCOVER_IMPLEMENTATION_VERSION
•DISCOVER_LIST_PROTOCOLS
•DISCOVER_AGENT

8. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
Transports
● Have
the
notion
of
channels
○ Platform
uses
these
to
identify
calling
agent
○ Different
channels
depending
on
who
initiates
communication,
agent
or
platform
● Today
the
specification
only
defines
a
mailbox
transport
○ Uses
a
shared
memory
area
and
doorbell
interrupts
○ Supports
interrupts
or
polling
○ Very
similar
to
ACPI
PCC
○ This
could
be
extended
in
the
future
• Delayed responses
• Notifications
agent
• Synchronous commands
• Asynchronous command
• Delayed responses
• Notifications
agent
• Synchronous commands
• Asynchronous command platform
• Delayed responses
• Notifications
agent
• Synchronous commands
• Asynchronous command
Agent
to
platform
channels
Platform
to
agent
channels
● Method
by
which
parameters/results
are
passed
between
the
caller
of
the
interface
(an
agent)
and
the
implementer
(the
platform)

9. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS
AND DEVICES
WORKING
TOGETHER
Agenda
• What’s
this
all
about
• Requirements
of
SCMI
• What’s
the
status

10. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
Extensibility
and
OS
agnosticism
● The
design
is
inherently
extensible
allowing
more
protocols
or
transports
to
be
added
over
time
● OS
agnostic
○ Different
OSs
same
Firmware
● Virtualizable
○ In
practice
this
generally
means
memory
based
transport
e.g Mailbox
● The
current
draft
of
the
specification
provides
a
mailbox
transport
○ In
future
an
SMC
transport
could
be
added
if
we
enable
ways
of
isolating
management
from
security

11. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
Wide
coverage:
How
it
all
comes
together:
linux -­‐ mobile
Android/ChromeOS/Other user side linux
EAS
Core-idling Sched-util/rfeq
Use case driven / Perf management
EAS-core
IPA
Sched-tune
Hotplug
2nd core boot
Sched-freqSched-freq
SCMI
Sensor protocol
Power domain protocol
Perf protocol
PSCI
Power Controller
cpuidle
Kernel API
SMC call
Non secure channel
Secure channel
Sysfs interface

12. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
Wide
coverage:
How
it
could
all
come
together:
enterprise
Core-idling Perf management
Sched-freqSched-freq
SCMI
Power domain protocol
Perf protocol
PSCI
Power Controller
Kernel API
SMC call
Non secure channel
Secure channel
ACPILPI
Device PM
D-states CPPC Power metering dev.
Hot add/remove
2nd core boot
Sensor protocol

13. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
Wide
coverage:
How
it
could
all
come
together:
enterprise
Core-idling Perf management
Sched-freqSched-freq
SCMI
Power domain protocol
Perf protocol
PSCI
Power Controller
Kernel API
SMC call
Non secure channel
Secure channel
ACPILPI
Device PM
D-states CPPC Power metering dev.
Hot add/remove
2nd core boot
Sensor protocol

14. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS
AND DEVICES
WORKING
TOGETHER
Agenda
• What’s
this
all
about
• Requirements
of
SCMI
• What’s
the
status

15. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
Status
and
plans
● There
are
remaining
challenges
○ Interaction
with
ACPI
CPPC
○ Use
of
SCMI
from
ASL
● We
are
prototyping
○ In
Juno
we
have
basic
power
control
and
performance
management
working
○ We
have
looked
at
interaction
with
CPPC
● We’d
like
to
release
first
public
spec
end
of
this
year
○ Concentrating
on
mobile
○ Feedback
welcome
● We
are
planning
to
upstream
SCMI
code
following
spec
publication
○ In
linux and
ARM
TF
and
SCP
reference
FW
● Candidate
version
for
review
○ http://connect.arm.com/dropzone/systemarch/DEN0056A_System_Control_and_Management_Interface_candidate_B.pdf

16. ENGINEERS AND DEVICES
WORKING TOGETHER
Thank
You
#LAS16
For
further
information:
www.linaro.org
LAS16
keynotes
and
videos
on:
connect.linaro.org

17. ENGINEERS AND DEVICES
WORKING TOGETHER
ENGINEERS AND DEVICES
WORKING TOGETHER
Wide
coverage:
SCMI
is
not
just
for
application
processor
cores
• The
spec
mainly
describes
communications
between
AP
and
platform
• Other
system
agents
could
use
the
same
interface,
e.g.
a
modem
in
mobile
or
an
management
controller
in
enterprise
• Self
managed
agents
must
use
private
channels
Paltform controller
Secure
Application Processor
OSPM
CPU Power Device or CPU
performance
Device power
domains
Sensors
PSCI
CPU power
domains
Management
Power
capping
Non secure
Private
PSCI SMC call