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

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

 



Hello Benoît, Rajendra, Hema,

On Mon, 9 Aug 2010, Cousson, Benoit wrote:

> On 8/9/2010 11:37 AM, Nayak, Rajendra wrote:
> > 
> > > From: Paul Walmsley [mailto:paul@xxxxxxxxx]
> > > Sent: Monday, August 09, 2010 1:51 PM
> > > 
> > > 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.
> 
> In fact, the SWakeup is asserted as soon as the module is in idle (idle_ack =
> 1) and cannot use the OCP interface to communicate a IRQ_REQ or DMA_REQ.
> But the wakeup capability is disabled by setting the SidleMode to Force-Idle,
> regardless of the value of Wakeup enable.
> Bottom-line is that the SWakeup can be asserted only if the module is in
> smart-idle.

In that case, it sounds like Rajendra's patch would be useful (to 
automatically enable ENAWAKEUP during target smart-idle, and disable it 
during target no-idle or force-idle, would be worthwhile)?

One other situation that we should consider would be if it ever makes 
sense to program a module to target smart-idle, but disable ENAWAKEUP.  I 
suppose it should only be necessary if there is a hardware bug where an IP 
block generates spurious SWakeups.  -- But if we have no current need for 
this type of workaround, maybe we can just ignore this case and have the 
ENAWAKEUP bit follow target smart-idle status.  Then if such a hardware 
bug appears, we can separate ENAWAKEUP programming later.

Thoughts?


- Paul

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

  Powered by Linux