Hi Paul, > Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 -----Original Message----- >From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- >owner@xxxxxxxxxxxxxxx] On Behalf Of Paul Walmsley >Sent: Monday, January 11, 2010 11:21 PM >To: Gopinath, Thara >Cc: linux-omap@xxxxxxxxxxxxxxx >Subject: RE: [PATCH] OMAP3: hwmod: Adding flag to prevent caching of >sysconfig register. > >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? Yes, both SR1 and SR2 are inside a "tactical" power domain, without any SW control. It follows the CORE power domain state. This is in fact not very well explained in the TRM. Regards, Benoit > >> 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 -- 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
