^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) The OMAP PM interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) This document describes the temporary OMAP PM interface. Driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) authors use these functions to communicate minimum latency or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) throughput constraints to the kernel power management code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) Over time, the intention is to merge features from the OMAP PM
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) interface into the Linux PM QoS code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) Drivers need to express PM parameters which:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) - support the range of power management parameters present in the TI SRF;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) - separate the drivers from the underlying PM parameter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) implementation, whether it is the TI SRF or Linux PM QoS or Linux
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) latency framework or something else;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) - specify PM parameters in terms of fundamental units, such as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) latency and throughput, rather than units which are specific to OMAP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) or to particular OMAP variants;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) - allow drivers which are shared with other architectures (e.g.,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) DaVinci) to add these constraints in a way which won't affect non-OMAP
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) systems,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) - can be implemented immediately with minimal disruption of other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) architectures.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) This document proposes the OMAP PM interface, including the following
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) five power management functions for driver code:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) 1. Set the maximum MPU wakeup latency::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) (*pdata->set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) 2. Set the maximum device wakeup latency::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) 3. Set the maximum system DMA transfer start latency (CORE pwrdm)::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) (*pdata->set_max_sdma_lat)(struct device *dev, long t)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) 4. Set the minimum bus throughput needed by a device::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) (*pdata->set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) 5. Return the number of times the device has lost context::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) (*pdata->get_dev_context_loss_count)(struct device *dev)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) Further documentation for all OMAP PM interface functions can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) found in arch/arm/plat-omap/include/mach/omap-pm.h.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) The OMAP PM layer is intended to be temporary
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) ---------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) The intention is that eventually the Linux PM QoS layer should support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) the range of power management features present in OMAP3. As this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) happens, existing drivers using the OMAP PM interface can be modified
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) to use the Linux PM QoS code; and the OMAP PM interface can disappear.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) Driver usage of the OMAP PM functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) -------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) As the 'pdata' in the above examples indicates, these functions are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) exposed to drivers through function pointers in driver .platform_data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) structures. The function pointers are initialized by the `board-*.c`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) files to point to the corresponding OMAP PM functions:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) - set_max_dev_wakeup_lat will point to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) omap_pm_set_max_dev_wakeup_lat(), etc. Other architectures which do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) not support these functions should leave these function pointers set
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) to NULL. Drivers should use the following idiom::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) if (pdata->set_max_dev_wakeup_lat)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) (*pdata->set_max_dev_wakeup_lat)(dev, t);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) The most common usage of these functions will probably be to specify
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) the maximum time from when an interrupt occurs, to when the device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) becomes accessible. To accomplish this, driver writers should use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) set_max_mpu_wakeup_lat() function to constrain the MPU wakeup
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) latency, and the set_max_dev_wakeup_lat() function to constrain the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) device wakeup latency (from clk_enable() to accessibility). For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) example::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) /* Limit MPU wakeup latency */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) if (pdata->set_max_mpu_wakeup_lat)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) (*pdata->set_max_mpu_wakeup_lat)(dev, tc);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) /* Limit device powerdomain wakeup latency */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) if (pdata->set_max_dev_wakeup_lat)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) (*pdata->set_max_dev_wakeup_lat)(dev, td);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) /* total wakeup latency in this example: (tc + td) */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) The PM parameters can be overwritten by calling the function again
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) with the new value. The settings can be removed by calling the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) function with a t argument of -1 (except in the case of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) set_max_bus_tput(), which should be called with an r argument of 0).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) The fifth function above, omap_pm_get_dev_context_loss_count(),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) is intended as an optimization to allow drivers to determine whether the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) device has lost its internal context. If context has been lost, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) driver must restore its internal context before proceeding.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) Other specialized interface functions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) -------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) The five functions listed above are intended to be usable by any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) device driver. DSPBridge and CPUFreq have a few special requirements.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) DSPBridge expresses target DSP performance levels in terms of OPP IDs.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) CPUFreq expresses target MPU performance levels in terms of MPU
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) frequency. The OMAP PM interface contains functions for these
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) specialized cases to convert that input information (OPPs/MPU
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) frequency) into the form that the underlying power management
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) implementation needs:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) 6. `(*pdata->dsp_get_opp_table)(void)`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) 7. `(*pdata->dsp_set_min_opp)(u8 opp_id)`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) 8. `(*pdata->dsp_get_opp)(void)`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) 9. `(*pdata->cpu_get_freq_table)(void)`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) 10. `(*pdata->cpu_set_freq)(unsigned long f)`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) 11. `(*pdata->cpu_get_freq)(void)`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) Customizing OPP for platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) Defining CONFIG_PM should enable OPP layer for the silicon
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) and the registration of OPP table should take place automatically.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) However, in special cases, the default OPP table may need to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) tweaked, for e.g.:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) * enable default OPPs which are disabled by default, but which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) could be enabled on a platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) * Disable an unsupported OPP on the platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) * Define and add a custom opp table entry
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) in these cases, the board file needs to do additional steps as follows:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) arch/arm/mach-omapx/board-xyz.c::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) #include "pm.h"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) ....
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) static void __init omap_xyz_init_irq(void)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) ....
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) /* Initialize the default table */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) omapx_opp_init();
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) /* Do customization to the defaults */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) ....
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) NOTE:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) omapx_opp_init will be omap3_opp_init or as required
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) based on the omap family.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags