Hi Will, Will Deacon <will.dea...@arm.com> writes:
> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote: >> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote: >> > >> > Part of the problem is that the clockdomain data for the emu_sys >> > clockdomain is wrong. Here's something to try to fix it. It might just >> > be enough to get it to work. >> >> Hmm, doesn't seem to work but I do see the following in dmesg when I try to >> use perf: >> >> powerdomain: waited too long for powerdomain emu_pwrdm to complete >> transition >> >> which is new with your patch. > > Sorry to nag, but does anybody have a clue where to go from here? I can > start digging in the OMAP PM code, but it's all new territory for me. Unfortunately, digging in the code isn't going to help much. We've been trying to get our heads around some undocumented reset behavior for the various debug IPs in OMAP. After a little digging and clarification from HW designers, it appears that if we allow the EMU clockdomain to idle, a full reset of the debug IPs is done. That means there are two solutions to this problem: 1) don't ever alow EMU clockdomain to idle. 2) modify CTI driver to re-init for every use. Obviously (1) is the easiet, and hacks for that have already been posted, but that has pretty significant impacts on power savings. (2) is the right solution to merge upstream, but needs writing. For (2), using runtime PM methods in the driver would be the simplest here since the ->runtime_resume method will be called every time the device is about to be used. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
