HWMOD

From OMAPpedia

Welcome to the HWMOD & Device Driver Adaptations wiki.

Contents 1 Introduction 2 Steps involved in HWMOD 3 Plan for Device Driver Adaptation Using HWMOD 4 Device Driver Adaptation to HWMOD - Schedule and Progress 5 HWMOD Framework Enhancements 5.1 Reset Management Support in HWMOD 5.2 More Granular HWMOD Structures 5.3 Multi-level omap_device_idle 5.4 Access to HWMOD Internal Data 5.5 Miscellaneous Issues 5.6 Additional HWMOD Enhancements Identified 6 HWMOD Dashboard 6.1 HWMOD Framework Changes 6.2 Platform & Power Drivers 6.3 Multimedia Drivers 6.4 Bridge/Link Drivers 6.5 Networking & Navigation Drivers

[edit] Introduction

This webpage describes the HWMOD & Device Driver Adaptations software development effort for OMAP3 and OMAP4 platforms. The purpose is to provide information on the current status and features planned in the road map.

[edit] Steps involved in HWMOD

• Convert your device to platform device driver. This doesn't require any understanding of PM or HWMOD. E.g. GPIO, which was a library, was converted to platform driver first before doing any HWMOD.

• Use HWMOD and make sure that the functionality achieved in the previous step is achieved (without PM).
  • Do omap_device_build() call that looks up the HWMOD database and does platform device registration.
  • Earlier individual devices had to be registered using platform_device_register() by passing all the information (like IRQ line, memory map, DMA channel etc.) in the platform_device structure.
  • The information had to manually populated.
  • Now that is taken care of by omap_device_build()

• Use omap_device APIs viz. omap_device_enable(), omap_device_idle() & omap_device_shutdown() for power management in place of clock related controls.

• Use omap_pm_layer to put the constraints.

• Test driver's normal functionality with adaptations enabled.

• Test system level PM features like CORE CSWR.

• Drivers implementing h/w mod need to implement run-time PM as well.
  • Instead of using omap_device_enable/disable functions directly, drivers will be calling get_sync/put_sync which eventually will call platform_pm_runtime_suspend & platform_pm_runtime_resume of platform bus.
  • These APIs will in turn call omap_device_enable/disable + the runtime_suspend/resume defined by the driver.
  • Refer the following for details on runtime PM:
    • http://www.elinux.org/images/0/08/ELC-2010-Hilman-Runtime-PM.pdf
    • \Documentation\power\runtime_pm.txt
    • arch\arm\mach-omap2\pm_bus.c for platform bus run time API implementation.

• Points to be noted
  • Compile and test the changes on OMAP4, OMAP3 & OMAP2 platforms
  • SoC specifics of any device is attached to the SoC specific hwmod using the dev_attr pointer. Make use of this.
  • Make use omap_hwmod_for_each_by_class() to iterate over all the hwmods in the device class while doing omap_device_build()
  • Any clocks other than fck/ick need to make use of clock FW APIs if required. For fck/ick do not use clock FW APIs as omap_device layer APIs takes care of the same. There is a opt_clk fld for other clocks (example: GPIO has debounce clock)
  • Do not break the working code and multi-omap build functionality.
  • All the SoC base address will be gathered in a single header file (omapXXXX.h) that should be used only by the omap_hwmod_xxxx_data.c file.

[edit] Plan for Device Driver Adaptation Using HWMOD

The following table gives the schedule for device driver adaptations to HWMOD and tracks the progress.

Device Driver Adaptation to HWMOD - Schedule and Progress

HWMod Activities/ Drivers	Applicability	Status (Not Started/ Implementation Stage/ Verification Stage/ Submitted/ Review Stage/ Accepted/ Merged)	Submission Target	Owner
HWMod Database for OMAP3	OMAP3	Implementation Stage	NA	All
HWMod Database for OMAP4 ES1.0	OMAP4	Submitted	7th May	Benoit
HWMod Database for OMAP4 ES2.0	OMAP4	Implementation Stage	Post ES2.0 verification (July)	Benoit
DMA	OMAP3/4	Review Stage	Initial Submission Done	Manjunath/ Santosh
GPIO	OMAP3/4	Review Stage	Initial Submission Done	Charu
GP-Timers	OMAP3/4	Verification Stage	End of May	Thara
Watchdog	OMAP3/4	Verification Stage	End of May	Charu
UART	OMAP3/4	Submitted for OMAP3	End of May	Govindraj
I2C	OMAP3/4	Review Stage	Initial Submission Done	Rajendra
MMC/ SD/ eMMC	OMAP3/4	Verification Stage	End of May	Kishore/ Venkat
SDIO	OMAP3/4	Implementation Stage	End of May	Kishore/ Sukumar
Keypad	OMAP3/4	Review Stage	Initial Submission Done	Abraham
McSPI	OMAP3/4	Verification Stage	End of June	Charu
McBSP	OMAP3/4	Not Started	End of June	Charu
EMIF	OMAP3/4	Not Started	End of July	Santosh
MUSB	OMAP3/4	Implementation Stage	End of June	Hema/ Anand Gadiyar
EHCI	OMAP3/4	Not Started	End of July	Keshava/ Maulik
OHCI	OMAP3/4	Not Started	End of July	Keshava/ Maulik
SmartReflex	OMAP3/4	Submitted for OMAP3	End of May	Thara
GPMC (should take care of NOR, NAND, OneNAND)	OMAP3	Not Started	End of July	Kishore/ Sukumar
SDRC	OMAP3	Not Started	End of July	Tarun/ Charu
DSS	OMAP3/4	Implementation Stage	End of July subject to overall code cleanup & successful verification	Senthil/ Mukund
Audio (McPDM, ABE)	OMAP3/4	Implementation Stage	End of June subject to ongoing audio upstreaming progress & successful verification	Jorge (OMAP4) & David (OMAP3)/ Liam
Syslink (Ducati, IVA-HD, Tesla)	OMAP3/4	Implementation Stage	End of July subject to overall code cleanup, ongoing syslink upstreaming & successful verification	Paul Hunt (OMAP4) & Ohad (OMAP3/ Hari K & Ohad
GFX	OMAP3/4	Implementation Stage	End of June subject to overall code cleanup, ongoing GFX upstreaming & successful verification	Hemant (OMAP4)/ Preshit (OMAP3)/
Networking & Navigation (Connectivity) Needs	OMAP3/4	TBD	TBD	Shahed Molla & Benzy Gabay

[edit] HWMOD Framework Enhancements

[edit] 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

[edit] 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

[edit] 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

[edit] 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

[edit] 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

[edit] Additional HWMOD Enhancements Identified

• Identified during the Bangalore PM SW workshop 7-11 Jun, 2010
  • 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

[edit] HWMOD Dashboard

[edit] HWMOD Framework Changes

Task	Owner	Target Date	State	Status	Comments & Actions
Pushing OMAP4 ES1.0 HWMOD database to Tony’s tree	Benoit	07-May	Completed	NA	None
Modeling multiple resets inputs for few IPs (IVAHD, Tesla, Ducati) in HWMOD database	Benoit	14-May	Completed		None
Developing APIs for sequencing multiple resets	Rajendra	14-May	Completed		None
Integrating with Rajendra's solution and providing the final solution to Ducati team	Rajendra	20-May	Completed	29 Jun Solution accepted. Awaiting feedback from Ducati Team On track (provided solution; testing by Ducati team in progress).	None
Submitting updated OMAP4 ES2.0 HWMOD database to internal tree	Benoit(OMAP4)	15-July	Completed		None
Fixing any HWMOD database related issues pertaining to driver PM adaptations	Benoit	31-Jul	Ongoing	Long term support activity	None
Extending h/w Mod database to model components with hierarchies like DSS (DSI, HDMI, RFBI) etc.	Benoit, Senthil & Partha	New: 21-Jul Old: 15-July	In progress	21-Jul: Partha and Senthil debugged, reviewed and fixed issues; final patches are expected on 21-Jul 14-Jul: Reviewed OMAP3 database. 07-Jul: Debugging in progress; expected to be completed by 09-Jul 30 Jun OMAP3 patches under development by Senthil 02 Jun OMAP4 patches provided by Benoit	None

[edit] Platform & Power Drivers

Task	Owner	First Submission Target Date	State	Status	Comments & Actions
GPIO	Charu	31-May	Accepted	07-Dec: Basic hwmod is accepted in l-o and it will be part of 2.6.38 merge window. The cleanup and runtime pm changes are planned in the next series. 11-Aug: Submitted V5. Working on review comments. 04-Aug: Submitted to L24.9. Submission of V5 to list planned by 04-Aug. 27-Jul: On track for L24.9, plan to submit to Kevin by 31-Jul. 21-Jul: Fixing PM runtime comments, rebasing for 2.6.35 & testing on omap4_next-wip in progress; target 26-Jul 30-Jun: Cleanup series planned for Aug 23-Jun: No new comments; but need to plan GPIO cleanup as a separate series 16-Jun: Waiting for acceptance	07-Dec: Cleanup and runtime pm changes as planned in the next series.
Watchdog	Charu & Shubro	31-May	Accepted	07-Dec: Already in mainline 18-Aug: Submitted V2 11-Aug: Submission of V2 delayed to 11-Aug to address final comments. 04-Aug: Submitted to L24.9. Submission of V2 to list planned by 04-Aug. 27-Jul: On track for L24.9, plan to submit to Kevin by 31-Jul. 21-Jul: Rebasing for 2.6.35 & testing on omap4_next-wip in progress; target 26-Jul 14-Jul: Tested V2 on internal omap4-next branch; testing on pm-wip/hwmods-omap4 branch is in progress. Patch submission will be done after that. 30-Jun: Testing of V2 under progress; target 02-Jul 23-Jun: Patch set ready; Testing on OMAP4 to be carried out by Shubro. 16-Jun: Fixed comments received; will be posted on 18-Jun	None
GP Timers	Thara & Tarun	31-May	Submitted V7 (20-Dec-2010)	30-Dec: Review and rework is under progress 18-Aug: Posted V211-Aug: Submission of V2 planned by 13-Aug. 04-Aug: Submitted to L24.9. Some debugging in progress. Submission to list planned by 13-Aug. 27-Jul: On track for L24.9, plan to submit to Kevin by 14-Aug. 21-Jul: Fixing PM runtime comments, rebasing for 2.6.35 & testing on omap4_next-wip in progress; target 26-Jul 14-Jul: Tarun working on the review comments. Plannning to post V2 by 23rd Jul 30-Jun:Nothing to update 23-Jun: Review comments received; Work will be done by Tarun by 10-Jul 16-Jun: Waiting for comments	None
UART	Govindraj	31-May	Accepted	14-Dec: HWMOD got accepted as part of 2.6.37 merge window. Runtime PM is planned for 2.6.39 merge window. 11-Aug: V3 Submission addressing usage of mutex-free version _omap_hwmod_enable() in Idle path based on irqdisabled check planned by 20-Aug. 04-Aug: Submitted to L24.9. Submission to list planned by 06-Aug. 27-Jul: HWMOD on track for L24.9, plan to submit to Kevin by 31-Jul. PM Runtime to be planned after this 14-Jul Started working on PM runtime. 07-JulWaiting for acceptance of current patch-set which supports hwmod without using RunTime PM framework. 30-Jun Submitted V2 as per the plan 23-Jun: Additional review comment regarding a corner case being fixed; will be posted 02-Jul 16-Jun: Waiting for acceptance	UART(OMAP Serial) driver is not merged in kernel.org yet. As a first step, functional driver with hwmod are posted. Runtime PM feature will be introduced as a second step once the driver is upstream. However, PM Runtime changes will be available internally in 15-Aug 2010 timeframe.
I2C	Rajendra	31-May	Accepted	20-Dec: Will be merged in 2.6.38. 11-Aug: Submitted V2. 04-Aug: Submitted to L24.9. Submission to list planned by 04-Aug. 27-Jul: On track for L24.9, plan to submit to Kevin by 31-Jul. 21-Jul: Rebasing for 2.6.35 & testing on omap4_next-wip in progress; target 26-Jul 14-Jul: Pending testing on OMAP4 on pm-wip/hwmods-omap4 branch. 30-Jun: Nothing to update 23-Jun: Patches are ready with run time PM & tested internally; need to have I2C support for OMAP4 on Kevin's HWMOD branch 16-Jun:Slipped due to workshop & wakeup travel; new date TBD	None
MMC & SDIO	Kishore & Sukumar	31-May	Submitted V1	14-Dec: Will be taken up in the next merge window. 18-Aug: V2 on track for 20-Aug posting; recent discussions in LO indicate that more cleanup may be needed in present upstream MMC driver 11-Aug: V2 Submission planned by 20-Aug. 04-Aug: Submitted to L24.9. Submission to list planned by 13-Aug. 27-Jul: Testing in progress, WA on hw issue in progress 21-Jul: Debugging continues; risk of 1 week delay 14-Jul: Stress testing with Runtime PM revealed race conditions in MMC driver impacting functionality. Debugging in progress. 07-Jul: V2 to be submitted by 16-Jul with some comments from PM workshop fixed. V3 will have further enhancements (w.r.t Suspend Resume). SDIO testing will be done internally in parallel. 30-Jun: Work in progress 23-Jun: Additional work needed per PM workshop camp; essential will be done by 09-Jul 16-Jun:Work in progress	None
Keypad	Abraham	New: 16-Jul Old: 31-May	Under Development	04-Jan 2011: Planned for 2.6.39 merge window 18-Aug: V1 planned by 20-Aug, deleyed due to release testing. 11-Aug: V1 Submission planned by 16-Aug. 04-Aug: Submitted to L24.9. Submission to list planned by 13-Aug. 27-Jul: On track for L24.9, plan to submit to Kevin by 31-Jul. 21-Jul: Fixing comments; rebasing for 2.6.35 & testing on omap4_next-wip in progress; target 26-Jul 07-Jul: Delayed due to wakeup 30-Jun: Runtime PM support addition is in progress; May get delayed to 16-Jul due to ongoing ES2.0 wakeup 23-Jun: Wakeup delayed completion of PM runtime APIs, new target 02-Jul 16-Jun: Target 23-Jun	30-Jun: Submitted Keypad HWMOD changes series V1 without runtime PM which is pending.
McBSP	Charu & Kishon	New: 30-Aug Old: 31-Jul, 30-Jun	Under Development	04-Jan 2011: Planned for 2.6.39 merge window 14-Dec: Planned for 2.6.39 merge window. 18-Aug: HWMOD changes are completed; Runtime PM chanegs are almost done 11-Aug: V1 submission by 30-Aug. 04-Aug: Analysis in progress. Requires significant cleanup & new HWMOD definition for sidetone. Yet to asses target date.27-Jul: Yet to start 21-Jul: Working to mobilize more resources and finish it earlier 30-Jun: Owner changed to Kishon from Charu. Kishon to ramp up and start implementation16-Jun: Target 23-Jun	Needs replan
McSPI	Charu & Govindraj	New: 31-Jul Old: 30-Jun	Submitted V2	04-Jan 2011: Planned for 2.6.39 merge window 14-Dec: McSPI submitted to LO.18-Aug: Submitted V1, has dependency on McSPI Slave mode patches which are also posted and are under review 11-Aug: V1 planned by 20-Aug. 04-Aug: Submitted to L24.9. Submission to list planned by 13-Aug. 27-Jul: On track for L24.9, plan to submit to Kevin by 15-Aug. 21-Jul: On track; target 26-Jul 14-Jul: Undergoing internal review 07-Jul: Submission planned before 14 Jul 30-Jun: Owner changed to Govindraj from Charu. Internal review done. After incorporating comments, 1st set of submission to LO expected by 02-Jul 16-Jun: Target 23-Jun	None
USB:MUSB	Hema	New: 31-Jul Old: 30-Jun	Submitted V2	04-Jan 2011: Planned for 2.6.39 merge window 14-Dec: Planned for 2.6.39 merge window. 18-Aug: Fixing of review comments on V1 is in progress; will be reposted by 18-Aug 11-Aug: Review rework in progress. 04-Aug: Submitted to L24.9. Submission to list planned by 10-Aug. 27-Jul: On track for L24.9, plan to submit to Kevin by 15-Aug. 21-Jul: review and rework in progress; rebasing ongoing; target 30-Jul 14-Jul: HWMOD + PM Runtime implementation completed. OMAP3 CORE OFF validation using Runtime PM in progress based on Kevin's PM branch(omap3_pm_defconfig). OMAP4 testing going on in parallel. Plan to send out patches for review by 23-Jul. 07-Jul: Hwmod framework API changes to take care of corner cases aligned internally. These changes will be circulated internally for review along with Run-Time PM changes on 07-Jul. 30-Jun: Risk Potentail enhancement of hwmod functions needed to cover errata scenarios. Also some h/w issues are being worked upon. Initial submission with PM runtime is targeted 09-Jul. Necessary hwmod framework change patches will also be suggested along with these changes. 16-Jun:HwMod changes reviewed internally, PM-Runtime changes in progress.	None
Smart Reflex	Thara	30-Jun	Submitted V5	04-Jan Queued for merging in 2.6.38 10-Dec: Review is under progress 18-Aug: 11-Aug: V2 planned by 13-Aug. 07-Jul: V1 with hwmod changes submitted. PM Runtime needs to be implemented. Pending comments from key people, who are currently on vacation.	None
USB:EHCI	Keshava	New: 15-Sep Old: 31-Jul	Under Development	14-Dec: Planned for 2.6.39 merge window. 18-Aug: work started; targeting 15-Sep posting 04-Aug: Slipped. Yet to start.27-Jul: 1st milestone at Risk 07-Jul Initialization of the driver platform data using hwmod database will be taken up as the first step, should be available for submission by 31-Jul. Enabling the Run-Time PM will be taken up once the functional driver is upstreamed. However, RunTime PM feature will be available internally for review earlier. Risk hw issues may impact upstreaming functional driver.	Needs replan
USB:OHCI	Keshava	New: 15-Sep Old: 31-Jul	Under Development	14-Dec: Planned for 2.6.39 merge window. 18-Aug: work started; targeting 15-Sep posting 04-Aug: Slipped. Yet to start. 27-Jul: 1st milestone at Risk 07-Jul Initialization of the driver platform data using hwmod database will be taken up as the first step, should be available for submission by 31-Jul. Enabling the Run-Time PM will be taken up once the functional driver is upstreamed. However, RunTime PM feature will be available internally for review earlier. Risk hw issues may impact upstreaming functional driver.	Needs replan
DMA	Manju	31-Jul	Accepted	10-Dec: DMA hwmod patches are queued in l-o for merging. Will be merged in 2.6.38. Cleanup, adopting runtime pm changes will be planned in the next series. 18-Aug: Plan to post V2 by 24-Aug 11-Aug: Review rework in progress. 04-Aug: Submitted to L24.9. Submission to list done. 27-Jul: On track for L24.9, plan to submit to Kevin by 15-Aug. 21-Jul: Review and rebasing in progress; on track 14-Jul: Posted RFC patches after testing on OMAP3 using pm-wip/hwmods-omap4 branch. OMAP4 testing inprogress on omap4-next.07-Jul Changes will be available for review internally on 09-Jul.	None
GPMC	Sukumar & Santosh	31-Aug	Not Started		None
SDRC	Tarun & Santosh	31-Aug	Not Started		None
EMIF	Tarun & Santosh	31-Jul	Completed	11-Aug: HWMOD is implemented, but the driver functionality is work in progress.04-Aug: Submitted to L24.9. Submission to list due 13-Aug21-Jul: Completed the implementation and review	None

[edit] Multimedia Drivers

Task	Owner	Target Date	State	Status	Comments & Actions
Audio	Jorge (OMAP4) & David (OMAP3)	09-Jul	Under Development	11-Aug: Component test in progress. 04-Aug: Code changes are ready. Debugging in progress on L24.9 kernel. 21-Jul: Would need revalidation as Audio driver is undergoing significant changes. Final validation to go beyond 31-Jul 14-Jul: Review comments incorporated including Runtime PM changes. Audio team can go ahead with posting these patches. 07-Jul: 09-Jul Risk. Review comments covering Suspend/Resume Runtime Suspend/Runtime Resume are being implemented. 30-Jun: Risk More Internal review comments provided. Revised date for submission: 09-Jul23-Jun:Internal review comments provided. 16-Jun: Nothing to update	None
DSS	Senthil	31-Jul	Prototype	18-Aug: RFC patches planned for 20-Aug. Delayed as DSS/DSS HWMOD on 2.6.35 broken. 11-Aug: DSS HWMOD chanages submitted on L24.9. Debugging/Validation in progress. Internal review done. Plan to submit RFC patches for community review by 16-Aug. 04-Aug: OMAP3 HWMOD RFC patches under internal review; target 06-Aug for external posting. OMAP3 HWMOD patches successfully migrated & validated on OMAP4 - going in L24.9. PM Runtime API support is under development 27-Jul: OMAP3 RFC patch-set under internal review. Changes migrated to OMAP4 and floated for internal review. 21-Jul: RFC patches working on OMAP3 expected today COB for internal review. Review & aligning on the final design to go in parallel to testing these patches on OMAP4. 14-Jul: DSS rearchitecture being prototyped on OMAP3. Planning to send first set of RFC patches by 19-Jul to the stake-holders for design review. Final design decision may get delayed due to key stake-holders being on vacation. Mayuresh is porting the work done on OMAP3 to OMAP4 in parallel.30-Jun: Risk Had design brainstroming with maintainers. Senthil to circulate early patchset to explain design. Risk:Time needed to solve to solve technical problems associated to one-driver multiple-device apporach. 23-Jun:Senthil created database for OMAP316-Jun: Reviwed in camp. To organize more brainstorming meetings with maintainers. Need to have multiple platform drivers for DSS subcomponents. Need to have DSS database for OMAP3 as well	None
SGX	Hemant (OMAP4)/ Preshit (OMAP3)	31-Jul	Under Development	04-Aug: PM Runtime debugging in progress. 27-Jul: Debug in progress 21-Jul: HWMOD Clock/Enable-Disable debugging in progress 14-Jul: Nothing to update this week. Needs prioritization, if there is any conflict. Review meeting planned. 30-Jun: Risk. Reviewed hwmod implementation. PM-runtime pending implementation 23-Jun: 16-Jun:	Performance Impact of Runtime PM framework a concern

[edit] Bridge/Link Drivers

Task	Owner	Target Date	State	Status	Comments & Actions
SysLink	Paul Hunt & Hari K (OMAP4) & Ohad (OMAP3/ Hari K & Ohad	31-Jul	Under Development	11-Aug: Validation on latest hwmod changes from Benoit in progress. 04-Aug: All Ducati & ISS issues resolved. HWMOD database changes & Diucati changes are ready; undergoing validation. Planned for L24.9 21-Jul: IVAHD validation in progress. ISS changes needed for HWMOD, dependency on Benoit. 14-Jul Runtime PM changes in progress for Ducati. Exploring the possibility of completing the final review for Ducati-Syslink by 23-Jul. HWMOD for IVAHD & ISS in progress. 07-Jul: SysLink tests on Ducati are fine with HWMOD patches shared offline covering RST functionality. 30-Jun: 23-Jun: 16-Jun: 19-May On track (provided solution; testing by Ducati team in progress)	Requirement for HWMOD enhancements to support reset of non cores Ducati, IVAHD outside of A9

[edit] Networking & Navigation Drivers

Task	Owner	Target Date	State	Status	Comments & Actions
Networking & Navigation	Shahed Molla & Benzy Gabay/Sukumar, Govindraj	31-Aug	Not Started	27-Jul: Dependent on SDIO & UART driver. Pending code review. 14-Jul Pending code review to rule out any direct access of OMAP SYSCONFIG registers, clokcs etc from networking/navigation drivers.	Dependency on UART & MMC readiness in platform and power; inactivity timers need to be propagated from OMAP3 to OMAP4 connectivity code. The networking components should not need any change as such. All changes should be confined to the drivers (SDIO, UART) called by these components