Proceedings of the PM SW Workshop Jun 2010
From OMAPpedia
(Difference between revisions)
Anand sawant (Talk | contribs) |
Anand sawant (Talk | contribs) |
||
| Line 56: | Line 56: | ||
* Is usecounting needed at omap_device level? | * Is usecounting needed at omap_device level? | ||
* More to be added as identified during discussions | * 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''' | ||
Revision as of 09:23, 11 June 2010
This wikipage contains proceedings of the PM SW Workshop held in Bangalore on 7-11 Jun, 2010
Contents |
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