On Fri, 27 Jan 2012 23:02:51 -0700 (MST) Paul Walmsley <paul@xxxxxxxxx> 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:
signature.asc
Description: PGP signature
