Hi Paul,

On 07/04/2012 02:48 PM, Paul Walmsley wrote:

Hi Benoît,

On Fri, 15 Jun 2012, Cousson, Benoit wrote:

quoted

My point is simple, we should not add any new custom flag when all the 
information to detect such exception are already there in the current 
data and represent accurately what the HW is doing.

This seems like the crux of the issue.  We don't have sufficient 
information to detect this exception in our current data, in my view.  
The software additionally must know when it can rely on a clockdomain 
remaining active when the MPU is active.

Yes, indeed, but that will be accurate mostly for OMAP3.
On OMAP4, *in theory* the dynamic dependency should always ensure that a
clock domain will be accessible upon any initiator requests.
In that case the notion of a domain active when the MPU is active become
a little bit less accurate.
Except when we have to force the static dep because of HW bugs
workaround. In that case, we are in the same situation than OMAP3.

Ideally the hardcoded clockdomain sleep dependencies would be encoded, and 
we could test the intersection of those and the software-programmable 
clockdomain sleep dependencies.  But such a change seems too complex for 
the -rc cycle.  So the updated patch below uses a clockdomain data flag 
for this instead.

Yep, I do agree that encoding that kind of information will require more
thought and much more code.

I have the feeling that some information about the IP idle behavior
should help figuring out that module like counter_32k, GPIO or mailbox
can be handled without real SW control.

This intermediate approach is thus good for the moment.

From: Paul Walmsley <paul@pwsan.com>
Date: Wed, 4 Jul 2012 05:22:53 -0600
Subject: [PATCH] ARM: OMAP2+: hwmod code/clockdomain data: fix 32K sync timer

[...]

What do you mean here?

Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html