Proceedings of the PM SW Workshop Jun 2010

This wikipage contains proceedings of the PM SW Workshop held in Bangalore on 7-11 Jun, 2010

Reset Management Support in HWMOD

 * Problem Statement
 * Most processor IPs do have a HW reset signal controlled by the PRM.
 * There is currently no abstraction layer to control the PRM reset register.
 * Since these reset signals are IP specific, they should be controlled manually by the driver code.


 * Proposed Solution
 * Add two APIs for asserting / deasserting reset lines in hwmods processor that require manual reset control.
 * Add one API to get the current reset state.


 * RFC Patches
 * RFC Patches Branch: hwmod_reset

More Granular HWMOD Structures

 * Problem Statement
 * Today hwmod structs are generated at a module level for DSS and IPU (Ducati).
 * However the drivers require control at submodule level. E.g. The DSS2 driver would require to control sub-modules like dispc, dsi1, dsi2, hdmi etc.
 * Also the syslink and IOMMU drivers need control at individual M3 level


 * Proposed Solution
 * Generate hwmod structs at sub-module level.
 * Need to decide if hierarchical control is needed


 * RFC Patches
 * RFC Patches Branch: hwmod_dss

Multi-level omap_device_idle

 * Problem Statement
 * Today most drivers only use one level of device_idle by populating activate/ deactivate_func as omap_device_idle_hwmods/ omap_device_enable_hwmods
 * omap_device_idle_hwmods disables the device clocks, if they happen to be the last set of clocks in the clockdomian, the clockdomain transitions to inactive and the powerdomain to the target state programmed (Deepest possile by default)
 * How do we support multiple levels of device idling? So that drivers can prevent going to the deepest idle state incase latency is not acceptable.


 * Proposed Solution
 * Use device latency constraint to control the powerdomain (of the device) target state.
 * Start with mapping the different device idle states with the different powerdomain states supported.
 * Keep the activate/deactivate_func same as before.

Placeholder for patches from Vibhore to support device latency contraint
 * RFC Patches

Access to HWMOD Internal Data

 * Problem Statement
 * Information stored in hwmod structs are not directly accessible to drivers. There might be instances when this is needed.
 * E.g. A driver requesting for optional clocks can do away with knowing the clock name string.
 * Syslink, which needs to request for i2c1 clocks can request for i2c hmwod main_clk.


 * Proposed Solution
 * Discuss and identify a list of all the hwmod internal data that might be needed by drivers and define apis for each of them - Rajendra

Miscellaneous Issues

 * Today omap_device_build provides a way to only pass platform_data structure during device registration. How do you pass other info which needs to be part of struct device? E.g. in the case of USB driver, there is a need to populate the dma_mask.
 * Is usecounting needed at omap_device level?
 * More to be added as identified during discussions

Minutes & Action Items

 * Aligned on all the discussions and PPT presented by Benoit & Rajendra
 * Aligned on Latency measurements; need to identify the resources to do it
 * Need to check with Tomi Valkeinen if he is going to maintain DSS going forward or is he planning to transfer the role to some one else (Vaibhav?)
 * Other HF Clock frequencies are not currently validated on TI boards. Can TI build boards that take external clock input?
 * Need to check if the power domain and device transition latencies can be supplied by the HW team as a part of HW spec.
 * It’s OK to have worst case numbers in terms of clock cycles & the clock being used. This is because absolute numbers will vary with clock frequency.
 * Additional HWMOD Enhancements Identified
 * rt_va : hwmod Paul
 * ifdef !CONFIG_PM_RUNTIME, leave enabled : hwmod Kevin
 * dev-> init_name : Thara, Kevin
 * Add clk_add_alias to omap_device_build : omap_device/ hwmod Paul
 * Add PRCM reset code for processor IPs & connect to HWMOD_INIT_NO_RESET : hwmod Benoit
 * Fix hwmod locking by adding lockless enable/ idle functions : device/ hwmod Kevin
 * Syslink needs to call device driver functions to reserve devices : syslink/ other devices? Is a HWMOD processor reset API necessary? Benoit
 * Connect omap_device lifecycle to device/ platform_device: hwmod Paul
 * Integration code that needs to set dev->dma_mask need to call get_device/ put_device : Integration code
 * Fine grained hwmod locking Paul
 * Add power domain/ clock domain wakeup latency tracking
 * Fix OMAP4 hwmod generator to generate HWMOD_NO_IDLEST Partha
 * Remove OCP_USER from OMAP4 hwmods without address space: OMAP4 autogen Partha

Power Domain And Clock Domain Cleanup
Aligned on the following two phase approach
 * Phase 1 
 * Clean up instances of usage of PRM/ CM APIs outside power domain & clock domain frameworks. Move these instances to appropriate frameworks.
 * This work can go ahead – there is enough clarity.
 * Need to figure out how to handle PRM FSM in some of the APIs - Rajendra & Benoit


 * Phase 2
 * Split the power domain and clock domain framework into platform and platform independent parts
 * Adopt the approach of doing the changes first and then moving
 * Some work has been done by Abhijit but need more discussions

Types of Latency Constraints

 * Interrupt latency or System latency
 * This is the total amount of time taken once an interrupt occurs to the time the interrupt handler is scheduled.
 * Depends mainly on the system sleep state or C state.
 * Since different C states take different amount of time to wakeup, the interrupt/ system latency constraint actually governs the deepest C state acceptable to the system at any given time.


 * Device latency constraint
 * This is the total amount of time taken for a device to become accessible.
 * It includes turning the clocks on, bringing the clockdomain out of inactive, power domain out of RET or OFF (with context restore) state.
 * This constraint mainly governs the deepest device idle state (only clocks cut, clockdomain in inactive, Powerdomain in RET or off) acceptable to the device at any given time.

Details of Interrupt Latency

 * pm_qos framework (kernel/pm_qos_params.c) already has support for CPU_DMA_LATENCY
 * The CPUidle menu governor also looks at CPU_DMA_LATENCY before deciding on the target C state
 * The omap-pm apis (omap_pm_set_max_mpu_wakeup_lat and omap_pm_set_max_sdma_lat) and be used to internally update the pm-qos framework which already does use-counting.
 * Something like a pdev->name can be used to identify the device putting the constraint.

Details of Device Latency

 * When a device is ready to idle, it calls the omap_device_idle api. Today, this turns the clocks off and eventually the clockdomain/powerdomains transition to the respective states.
 * Without any device latency constraints in place a device calling omap_device_idle could hit a OFF state.
 * The initial proposal is to map device states to various powerdomain states supported.
 * The omap-pm api (omap_pm_set_max_dev_wakeup_lat) called by the device will map to a given powerdomain state acceptable to the device.
 * This can be implemented by extending the current powerdomain framework to keep track of all the devices in the domain and their acceptable latencies. For each powerdomain, latency information for each state supported will also be needed.
 * Implementing the api will involve identifying the powrdomain the device belongs to, determining the lowest acceptable latency among *all* other devices in the powerdomain and then mapping the latency to the target powerdomain state.

Proposed Implementation

 * OMAP PM layer - API’s exported to driver are defined here
 * Are all drivers going to be of type omap_device?
 * Design for existing omap-pm vs. omap_device layer?
 * -1 to release constraint, otherwise 0 or higher (acceptable latency in us)
 * We can’t assume that only releasing the constraint will lower power
 * Lowering the constraint can still trigger power state change

void omap_pm_set_max_dev_wakeup_lat(struct device *dev, long t) { /* existing code */ 1. Look for devices’ power domain (might be multiple step if starting with general device) 2. Use device name as identifier for constraint request if (t == -1) pwrdm_release_wakeup_lat_constraint (pwrdm, lat_dev_name); else pwrdm_set_wakeup_lat_constraint (pwrdm, lat_dev_name, t); }

struct powerdomain { /* existing entries*/ const u32 wakeup_lat[PWRDM_MAX_PWRSTS-1]; static LIST_HEAD(wakeup_lat_constraint_list); } static struct powerdomain core_44xx_pwrdm = { .wakeup_lat = { 50,  /* off */ 20,  /* ret */ -1 for not supported power state 0,    /* inactive */ Do we have to worry about OSWR? } }
 * Power domain layer – constraint enforcement/ tracking implemented here
 * How does the state change happen? Just by programming next state?
 * powerdomain struct extended to capture following:
 * Power domain’s wakeup latency for each supported power state
 * List header for wakeup latency constraint placed by all devices in this domain; can be defined in powerdomains44

pwrdm_set_wakeup_lat_constraint (struct powerdomain *pwrdm, char *lat_dev_name, long lat_us){ 1. If new constraint, add a new entry to wakeup_lat_constraint_list 2. If already existing, update entries’ latency value 3. pwrdm_check_for_state_change (pwrdm) } pwrdm_release_wakeup_lat_constraint (struct powerdomain *pwrdm, char   *lat_dev_name){ 1. Remove this devices’ constraint from wakeup_lat_constraint_list 2. pwrdm_check_for_state_change (pwrdm) } pwrdm_check_for_state_change (struct powerdomain *pwrdm){ 1. min_latency = find_min_wakeup_latency_constraint (pwrdm) //go through the list for minimum latency value 2. find power state that has latency lower than minimum constraint for (new_state = 0x0; new_state < PWRDM_MAX_PWRSTS; new_state++){ if (pwrdm->wakeup_lat[i] < min_latency) break; } 	3. if (pwrdm->state != new_state) pwrdm_set_next_pwrst (pwrdm, new_state); // existing function to program next state }
 * 3 Scenarios: new constraint, update old constraint, or release it

Minutes & Action Items

 * Use device wakeup latency instead of device latency.
 * Need to start pursuing the HW team to provide wakeup latency numbers – this is a very much needed in the long run; and it is needed for complete entitlement of HW PM features by the SW
 * Aligned on Vibhore’s proposal + comments provided during the meeting (e.g. structures suggested by Paul during meeting); Vibhore can go ahead with the implementation

.wakeuplat = { [FUNC-PWRST-OFF] = 50, [FUNC-PWRST-OSWR] = 30, [FUNC-PWRST-CSWR] = 5, [FUNC-PWRST-ON] = 0, }; .func_pwrsts = (FUNC_PWRST_OFF | FUNC_PWRST_OSWR | FUNC_PWRST_CSWR |  FUNC_PWRST_ON) 1 << FUNC_PWRST_OFF pwrdm_wakelat_set_constraint pwrdm_wakeuplat_remove_constraint pwrdm_wakeuplat_update_pwrst)


 * The open question is how we measure the latencies and who will do it.

SRF Replacement - OPP Part
Aligned on using device based OPP approach & maintaining constraints in voltage layer for OPP part of SRF replacement. Sufficient details have been worked out to proceed with the basic DVFS implementation of VDD MPU, VDD IVA & VDD Core voltage domains.

RFC Patches
Here is a work-in-progress patch that shows work done so far and some of the review comments addressed. Please note that this is in no way completed, compiling, clean patch. It is provided to have a better idea of the changes proposed and discussed.



Minutes & Action Items

 * Attaining VDD MPU, VDD IVA & VDD Core DVFS basic functionality
 * Shift in approach from voltage domain based OPP to device based OPP
 * OPP will be stored in separate SOC dependent file from other clock, hwmod, voltage files.
 * These will be loaded into memory and then board-specific modifications will be done.
 * The device HWMODs will point to the dynamic versions of the device-OPPs.
 * Kevin is targeting it for the next merge window – should be doable by month end but needs Thara’s full bandwidth
 * Kevin will do the data structural changes and get them working with existing SRF – Kevin (initial version posted: 16 June)
 * Then Thara will take it and remove the SRF.
 * Then Thara will implement the new APIs for DVFS & omap device layer viz. omap_device_set_min_rate(hwmod, rate) & omap_device_get_cur_rate(dev) These internally will call set_rate & get_rate of the HWMOD.
 * Once VDD Core OPP changes, the changing of scalable functional clocks (for affected IPs as per the Excel sheet) will be done by HWMOD function implementations.
 * The final part will be to extend the voltage layer to take care of constraints and cross VDD dependencies (they are there in OMAP3 code but needs to be transformed to the new format)
 * Kevin suggested to use plist (priority assigned doubly linked lists) for this purpose


 * Enhancement to allow drivers to block or allow rate change of their scalable clocks 
 * The following APIs need to be added to the clock framework to allow drivers to block or allow rate change of their scalable clocks (& their parents)
 * The APIs are clock_block_change, clock_allow_change, is_clock_rate_change_allowed – Paul is OK if some one also picks up this.
 * Need to ensure that the implementation doesn’t result into race conditions
 * This is needed for OMAP4 VDD Core DVFS implementation for handling of corner cases. E.g. if a driver doesn’t want to allow functional or optional clock change. Today’s SRF doesn’t support this and there are no major issues with it.

MUSB

 * MUSB team to investigate whether omap_device_enable_wakeup and omap_device_disable_wakeup functions need to be added to take care of an errata
 * Current user of this will be MUSB but in future other drivers can also use this

MMC

 * Can Suspend & Runtime Suspend implementations be made common? This will lead to early suspend from the drivers. - MMC team to explore this option

DSS

 * Using detailed DSS sub-module specific hwmod requires imeplementing dispc_device-dispc_driver, dsi_driver, dsi_device-dsi_driver as platform_devices - Senthil to plan
 * Follow-up discussion on this with Tomi needed for finalizing on the design - Senthil
 * Check if the DSS DPLLs are same as that of the main OMAP3,4 dplls.         This will aid in the decision of if Clock-FW could also address DSS DPLLs. - Senthil

DMA

 * Manjunath to add the HWMOD data first before doing the registration.
 * Manjunath to add Channel count etc in dev_attr.
 * Manjunath to move DMA implementation into device drivers & have exported APIs. One more reason is to have a generic driver hiding SDMA & EDMA under the hood.
 * Manjunath to do the platform device conversion.
 * Manjunath to do HWMOD changes
 * Manjunath to do the conversion into plat-omap & mach-omap layers getting rid of cpuxx checks.
 * Manjunath to move plat-omap to driver layer
 * Next step could be to implement Async Tx DMA support.
 * Manjunath & Santosh to align with the DMA maintainer (dan.j.williams@intel.com)

General Minutes and Action Items

 * All hwmods need to be tested only through run-time PM.
 * This is true for all other drivers.
 * If CONFIG_RUNTIME_PM is not enabled, hw-mod initialization should keep the clocks turned-on.
 * Review all h/w-attrs and segregate into Class specific dev-attrs is appropriate.
 * All HWMOD data should not be introduced in one-shot. HWMOD database for a particular device should be introduced incrementally as the driver gets modified and tested.
 * SmartReflex should be targeted for the Aug end merge window.
 * There is need to have more meetings between maintainers (Paul, Kevin, Tony) and the key HW IP designers for the following reasons
 * For HW designers to understand how “hacks” or “one of cases” negatively impact Linux SW design (making it complex and difficult to manage)
 * For maintainers to better understand constraints of HW design so that they can suggest a better SW modeling solution