Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

LAS16-200: SCMI - System Management and Control Interface

2,351 views

Published on

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

Published in: Technology
  • I like this service ⇒ www.HelpWriting.net ⇐ from Academic Writers. I don't have enough time write it by myself.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • You can try to use this service ⇒ www.WritePaper.info ⇐ I have used it several times in college and was absolutely satisfied with the result.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

LAS16-200: SCMI - System Management and Control Interface

  1. 1. ENGINEERS  AND  DEVICES WORKING  TOGETHER System  Control  and  Management  Interface Charles  García-­‐Tobin
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. ENGINEERS  AND  DEVICES WORKING  TOGETHER Thank  You #LAS16 For  further  information:  www.linaro.org LAS16  keynotes  and  videos  on:  connect.linaro.org
  17. 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

×