1 / 7

TI OMAP HSI Driver PM Dynamic OPP change

TI OMAP HSI Driver PM Dynamic OPP change. Djamil ELAIDI Modem Integration – Google HUB v0.6 , Dec 16, 2011. HSI Dynamic OPP change : background. HSI IP : HSI RX and TX bit rate : depends on HSI Functional clock cannot be higher than Fclk

blue
Download Presentation

TI OMAP HSI Driver PM Dynamic OPP change

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TI OMAP HSI Driver PMDynamic OPP change Djamil ELAIDI Modem Integration – Google HUB v0.6, Dec 16, 2011

  2. HSI Dynamic OPP change : background • HSI IP : • HSI RX and TX bit rate : • depends on HSI Functional clock • cannot be higher than Fclk • HSI Functional clock can be clocked by 96MHz or 192MHz • Max Speed is achieved using 192MHz Fclk, stream pipelined mode • HSI is part of L3INIT Power Domain, L3INIT_PD is in CORE voltage domain • HSI available OPPs are : • OPP50 (96MHz, 0.962V) • OPP100 (192MHz, 1.127V) • HSI can run at : • 96MHz with both voltages. • 192MHz only if powered by 1.127V, otherwise it will crash. • It is necessary to switch L3INIT_PD to 1.127V to allow HSI@OPP100 & achieve max throughput • But obviously there is a drawback of running HSI@OPP100 : • HSI@OPP100 has a negative impact on power management, so it is necessary to go back to OPP50 as soon as high throughput is no more required.

  3. HSI Dynamic OPP change : implementation • Implemented only on kernel 3.0, branch p-android-omap-3.0 • Added IOCTL to change HSI FClk to 96MHz or 192MHz • hsi_ioctl(HSI_IOCTL_SET_HI_SPEED, 0) : switch to OPP50 (96MHz) • hsi_ioctl(HSI_IOCTL_SET_HI_SPEED, 1) : switch to OPP100 (192MHz) • OMAP PM API for device scaling use mutexes, so hsi_ioctl(HSI_IOCTL_SET_HI_SPEED, x) might sleep. • RX/TX divisors and RX error counters are not automatially changed with this ioctl. • Added IOCTL to get current HSI FClk • hsi_ioctl(HSI_IOCTL_GET_SPEED, &clk) : returns 96000000 or 192000000

  4. HSI Dynamic OPP change : interface • Decision of when to increase/decrease modem speed is up to Link Layer. • AP-LL and CP-LL must synchronize to know when HSI link speed is changing and when change is over. • If CP-HSI speed is increased to 192MHz (or more than 96Mhz), AP-HSI must switch to OPP100. • If CP-HSI speed is decreased to less than 96Mhz, AP-HSI can switch to OPP50 to allow power saving. • Constraints : • After OPP is changed RX/TX divisors and RX error counters need to be changed (divided or multiplied by 2) using hsi_ioctl(HSI_IOCTL_SET_RX) and hsi_ioctl(HSI_IOCTL_SET_TX) • Link Layer shall ensure : • No read or write are ongoing when OPP change is started • No read or write are started while OPP change is ongoing • No data is received while OPP change is ongoing • HSI driver will : • Reject OPP change (-EBUSY) if any Read or Write is pending • Reject read or write operation (-EAGAIN) if OPP change operation is ongoing • In case AP HSI receives data without any explicit HSI read, up to 8 frames can be received per channel until AC_READY is lowered. In this case if OPP change operation occurs during data reception, data integrity is not guarantied and HSI driver may raise errors.

  5. HSI Dynamic OPP change : latencies • OMAP PM API for device scaling use mutexes (one for all power domains), so if a device scale is already in progress, latency will increase. • With DVFS framework from K3.0, measurements using Ftrace show omap_device_scale() takes to complete in average 300us. • Condition : low CPU load, not sure about worst case latency • No SW measurable difference between OPP50->OPP100 & OPP100->OPP50 transitions. • Architecture measurements (DVFS framework from K35) • OPP50->OPP100 : 579.5us (518.5us@OPP50 + 61us@OPP100) • OPP100->OPP50 : 610us (122us@OPP100 + 488us@OPP50) • Recommendation is (between SW OPP request and effective OPP change) : 1ms • This latency doesn’t include AP-CP OPP change handshake

  6. HSI Dynamic OPP change : open points • Shall HSI driver handle RX/TX divisors and RX error counters automatically after OPP change (divided or multiplied by 2) or shall Link Layer do it ? • In addition of ioctl to change HSI FClk, shall HSI driver provide an ioctl to change the TX and RX speed (Fclk + dividers at the same time) ? • This would minimize number of ioctl to change the OPP (no need for ioctl(SET_TX/SET_RX) • Will LL be able to guaranty no data will be received during HSI OPP change ? • Can LTE modem support (without impact on throughput): • OPP handshake protocol • Maximum OPP latency induced by DVFS FW + HW • How many bits can modem hold internally while OPP change is ongoing on AP ? • What is the OPP change protocol on CP side ? • Latency between OPP change request and HSI link readiness : TBD

  7. HSI Dynamic OPP change : optimizations • To minimize OPP change duration during which RX/TX is suspended, following optimization is possible : • If OPP50 -> OPP100 : • Perform a VDD_CORE voltage scale first • Suspend TX/RX • Do the frequency scaling • Resume TX/RX • If OPP100 -> OPP50 : • ?

More Related