Proceedings of the PM SW Workshop Jun 2010

(Difference between revisions)

Jump to: navigation, search

Revision as of 09:05, 11 June 2010

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

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

Branch: hwmod_dss

@@ Line 12: / Line 12: @@
 ** Add one API to get the current reset state.
-* '''RFC patches can be found at'''
+* '''RFC Patches'''
 ** [http://dev.omapzoom.org/pub/scm/swarch/linux-omap-adv.git 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'''
+** [http://dev.omapzoom.org/pub/scm/swarch/linux-omap-adv.git RFC Patches]
+Branch: hwmod_dss