RE: [PATCH 7/8] : Hwmod api changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

> -----Original Message-----
> From: Paul Walmsley [mailto:paul@xxxxxxxxx] 
> Sent: Monday, August 09, 2010 1:51 PM
> To: Nayak, Rajendra
> Cc: Kalliguddi, Hema; linux-usb@xxxxxxxxxxxxxxx; 
> linux-omap@xxxxxxxxxxxxxxx; 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-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux