On Thu, 7 Jan 2010, Gopinath, Thara wrote: > >>-----Original Message----- > >>From: Paul Walmsley [mailto:paul@xxxxxxxxx] > >>Sent: Wednesday, January 06, 2010 6:02 AM > >>To: Gopinath, Thara > >>Cc: linux-omap@xxxxxxxxxxxxxxx > >>Subject: RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of sysconfig register. > >> > >>On Wed, 23 Dec 2009, Gopinath, Thara wrote: > >> > >>> Hi Paul,Kevin.. Does this patch look ok? > >> > >>Hello Thara, > >> > >>looking over this patch. Nice job on the descriptive patch comment; > >>it explains the problem well. What do you think about a slightly > >>different approach -- that is, to add a hook to the hwmod code to > >>invalidate the cache if the module's powerdomain has lost context? > > It should be possible but I feel it is a bit cumbersome. Couple of > reasons I have. > a. Some modules like smartreflex does not have any power domain > associated with it. Aren't the SmartReflex modules in their own powerdomain that changes with the CORE powerdomain? > b. Invalidating the cache is not needed for all modules even if the > module powerdomain context is lost. This is needed only for modules > which employ always restore mechanism. All other modules will do > explicit context save and restore of its registers I think we'll want to move all SYSCONFIG manipulation into the hwmod layer, once it is in place. > c. Getting whether power domain context is lost or not is not very > straight forward. If I am not mistaken the only way is to keep tab of > the powerdomain counters through omap_pm_get_dev_context_loss_count. I > might be mistaken. Yeah. Getting the hook in will take a little bit of work. Anyway, for the time being, we can take this patch. But the other reason that this approach doesn't appeal is that this new flag doesn't have anything to do with the hardware -- it's just a software workaround for device driver code. Ideally, all of these flags should be generatable based on hardware data only. Flags that pertain to how the device driver works belong in a different place. Perhaps they should still be connected to the hwmod code, but they should exist separately from the hwmod data. Queued for .33-rc (fixes). - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
