Re: OMAP HDQ: was Re: DSS2/PM on 3.2 broken?

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]

On Fri, 27 Jan 2012 23:02:51 -0700 (MST) Paul Walmsley <paul@pwsan.com> wrote:


> Since the HDQ module doesn't support the idle protocol, the target clock 
> FSM in the CM is what should determine whether the module is considered 
> idle or not.  And as long as the bit in the CM_FCLKEN register 
> corresponding to HDQ_FCLK is set, the FSM should consider the module as 
> active, and the clockdomain should not be allowed to go inactive.
> 
> I write "should."  Given that big caution at the bottom of section 20.4.5 
> "System Power Management and Wakeup", this appears to have not been 
> correctly implemented.

Can you help me understand why you say "should" there.
You seem to be implying that a down-stream clock gate should cause an
upstream clock to stay active, but that doesn't make sense to me given the
presence of the much richer SIDLE framework.  Also I cannot find it in the
TRM (though there a lots of words in there and I might have missed some).

Most modules use SIDLE to keep the upstream clock active.  HDQ doesn't have
that so it needs software over-rid to keep it active.

> 
> > It also mentions the AUTO_HDQ bit of PRCM.CM_AUTOIDLE1_CORE.  This had me
> > confused for a while, but I think it only affects the iclk.  
> 
> That's correct.
> 
> > I don't think the iclk is the problem.  It is the fclk that is 
> > disappearing because the clkdm that feeds it is being turned off.
> 
> Disabling AUTO_HDQ is probably a reasonable workaround.  It would prevent 
> the CORE_L4 clockdomain from going inactive, and that happens to be where 
> the functional clock originates from, also.
> 
> We have a partial facility to handle this type of bug in the existing 
> code.  Could you please try the patch enclosed at the bottom of this 
> E-mail and see if it helps?

Yes, that patch fixes my problem too - the HDQ keeps working.

(it's a bit smoke-and-mirrors though .. I want fclk to stay on, so let's make
sure iclk doesn't autoidle, because we *know* they have the same source :-)


Thanks,
NeilBrown


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]