> -----Original Message----- > From: Paul Walmsley [mailto:p...@pwsan.com] > Sent: Monday, August 09, 2010 1:51 PM > To: Nayak, Rajendra > Cc: Kalliguddi, Hema; linux-...@vger.kernel.org; > linux-omap@vger.kernel.org; Basak, Partha; Felipe Balbi; Tony > Lindgren; Cousson, Benoit; Kevin Hilman > Subject: RE: [PATCH 7/8] : Hwmod api changes > > (cc Benoît) > > On Mon, 9 Aug 2010, Nayak, Rajendra wrote: > > > Does it make sense for the framework itself to enable wakeup > > for all devices when the slave port is programmed to be in > > Smartidle > > It seems to me that they are separate mechanisms? If a module is > programmed for slave smart-idle, then the module prevents the > PRCM from > shutting off the module clock(s) until the module is not > busy. This seems > distinct from ENAWAKEUP, which I thought simply controlled > whether the > module would assert the SWakeup signal to the PRCM when an > external wakeup > condition occurred for that module. Is that an accurate summary?
hmm.. the reason I thought the two were related was because the need to assert a SWakeup will arise only when the module is programmed in smart-idle. If the module is either in no-idle (in which case no idle-ack is asserted by the module) or force-idle (when the module is forced to idle and expected to stay idle) there might not be a need for the module to be capable of asserting a SWakeup. The reason I proposed ENAWAKEUP to be always enabled with smart-idle was with as understanding that we may never have a case wherein the module is programmed in smart-idle but not expected to assert SWakeup (if it supports one). I will check up on this if there ever could be such a case. > > > instead of exposing 2 more omap device level api;s to the drivers? > > Something like this probably needs to be exposed to core code > that would > also set/clear PM_WKEN_* for the appropriate processor > module. Right now > we just set a bunch of these bits directly in pmXXXX.c, and > that needs to > change. > > The other issue is that I suspct the module needs to be > enabled in order > for SYSCONFIG writes to succeed; right now the underlying > hwmod code does > not appear to enforce this :-( > > But I don't see why drivers would need to call these > functions directly. > Hema, was that your intention? If so, you could you please > explain the > use case? > > > I have a patch for this and can post it for review in case you > > feel it makes sense. > > > - Paul-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
