Proceedings of the PM SW Workshop Jun 2010

Revision as of 09:15, 11 June 2010 by Anand sawant (Talk | contribs)

Jump to: navigation, search

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

HWMOD Framework Enhancements

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.

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

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

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

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