Proceedings of the PM SW Workshop Jun 2010

From OMAPpedia

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

Contents 1 HWMOD Framework Enhancements 1.1 Reset Management Support in HWMOD 1.2 More Granular HWMOD Structures 1.3 Multi-level omap_device_idle 1.4 Access to HWMOD Internal Data 1.5 Miscellaneous Issues 1.6 Minutes 2 Power Domain And Clock Domain Cleanup 3 SRF Replacement - Constraints Part 3.1 Types of Latency Constraints 3.2 Details of Interrupt Latency 3.3 Details of Device Latency 3.4 Proposed Implementation

HWMOD Framework Enhancements

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.

• RFC Patches

Placeholder for patches from Vibhore to support device latency contraint

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

• 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. 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 & Paul

• 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

SRF Replacement - Constraints Part

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);
}