From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Hunter Subject: Re: oprofile and ARM A9 hardware counter Date: Wed, 9 May 2012 16:45:08 -0500 Message-ID: <4FAAE564.6040708@ti.com> References: <20120403092524.GD17741@mudshark.cambridge.arm.com> <20120403094749.GH17741@mudshark.cambridge.arm.com> <20120403123444.GL17741@mudshark.cambridge.arm.com> <878vicsxef.fsf@ti.com> <20120403160706.GP17741@mudshark.cambridge.arm.com> <87ehs4pfw4.fsf@ti.com> <20120404111524.GF32505@mudshark.cambridge.arm.com> <20120426180719.GC20186@mudshark.cambridge.arm.com> <4FA45580.8070802@ti.com> <87ipg76hfm.fsf@ti.com> <4FA8284C.7080803@ti.com> <87k40nzi3i.fsf@ti.com> <4FA8FCFF.40105@ti.com> <4FA9588E.9020906@ti.com> <87sjfal65t.fsf@ti.com> <4FAA4DB9.8060504@ti.com> <4FAAB1A3.9040806@ti.com> <4FAAC54 9.6010206@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from bear.ext.ti.com ([192.94.94.41]:47237 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756346Ab2EIVp2 (ORCPT ); Wed, 9 May 2012 17:45:28 -0400 In-Reply-To: <4FAAC549.6010206@ti.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: "Cousson, Benoit" Cc: Kevin Hilman , Paul Walmsley , Ming Lei , Will Deacon , Maynard Johnson , "Shilimkar, Santosh" , "oprofile-list@lists.sourceforge.net" , Lik Lik , "eranian@gmail.com" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Hi All, On 05/09/2012 02:28 PM, Jon Hunter wrote: [...] >>>>> No hacking intended here, just getting the flags correct ;-) >>>>> >>>>> So let me start from the beginning ... >>>>> >>>>> 1. I agree that for the EMU CD that the valid HW states are HW_AUTO and >>>>> SW_WKUP. >>>>> >>>>> 2. When the EMU CD is active (due to something like PMU), we want to >>>>> keep the CD in the SW_WKUP state, otherwise we can automatically >>>>> transition to idle and reset the IP (at least for omap4430). >>>> >>>>> 3. When the EMU CD is inactive, we want to keep the CD in the HW_AUTO >>>>> state because SW_SLEEP is NOT supported. >>>>> >>>>> In the current code, we have the CLKDM_CAN_DISABLE_AUTO flag disabled >>>>> and the CLKDM_CAN_ENABLE_AUTO flag enabled. If CLKDM_CAN_ENABLE_AUTO is >>>>> set then the omap_pm_clkdms_setup() function will place the CD into >>>>> HW_AUTO regardless of CLKDM_CAN_DISABLE_AUTO, and the next time the >>>>> hwmod _enable() is called it is in the HW_AUTO state and so it is >>>>> allowed to idle. This is not what we want. Do you agree? >>>>> >>>>> If I set CLKDM_CAN_DISABLE_AUTO flag and disable CLKDM_CAN_ENABLE_AUTO, >>>>> then I do not have the above problem. >>>>> >>>>> To be honest, with you the more I look and test the code, the more >>>>> confused I am by the definition of the CLKDM_CAN_HWSUP ... >>>>> >>>>> #define CLKDM_CAN_HWSUP (CLKDM_CAN_ENABLE_AUTO | CLKDM_CAN_DISABLE_AUTO) >>>>> >>>>> When I look at where these flags are used, I see that >>>>> CLKDM_CAN_ENABLE_AUTO is used in clkdm_allow_idle and >>>>> CLKDM_CAN_DISABLE_AUTO is used in clkdm_deny_idle. So this implies that ... >>>>> >>>>> CLKDM_CAN_ENABLE_AUTO = Supports HW_AUTO state when CD is active >>>>> CLKDM_CAN_DISABLE_AUTO = Does NOT supports HW_AUTO state when CD is active >>>>> >>>>> Are the above the correct definitions? >>>> >>>> Not quite. >>>> >>>> These flags describe the capabilities as defined in CLKTRCTRL field of >>>> the CLKSTCTRL register (e.g. CM_EMU_CLKSTCTRL) >>>> >>>> CLKDM_CAN_ENABLE_AUTO: IP supports HW_AUTO state (and it can be enabled) >>>> CLKDM_CAN_DISABLE_AUTO: HW_AUTO feature can be disabled (a.k.a. NO_SLEEP) >>>> >>>> Note that in OMAP4, the latter called NO_SLEEP in the TRM, but in OMAP3 >>>> it's described as "The automatic hardware-supervised mode is disabled" >>> >>> Yeah, in fact this is the source of the current confusion for my point of view. >>> >>> We chat about that with Paul some time back. >>> >>> EMU CD does support HW_AUTO and SW_WKUP, so it means that if you want to disable the AUTO mode you can use the SW_WKUP. >>> Assuming that CLKDM_CAN_DISABLE_AUTO is equivalent to NO_SLEEP is thus not correct. In fact any state != HW_AUTO should be considered a non-automatic mode. >>> So EMU does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP. >>> >>> But the way it is implemented does not really allow that, because disable hwsup imply setting state to OMAP34XX_CLKSTCTRL_DISABLE_AUTO. >>> >>> void omap4_cminst_clkdm_disable_hwsup(u8 part, s16 inst, u16 cdoffs) >>> { >>> _clktrctrl_write(OMAP34XX_CLKSTCTRL_DISABLE_AUTO, part, inst, cdoffs); >>> } >>> >>> So if we want to allow that, some code change are needed in order to set the clkdm mode to OMAP34XX_CLKSTCTRL_FORCE_WAKEUP if OMAP34XX_CLKSTCTRL_DISABLE_AUTO is not supported. >>> >>>> What is confusing to me is that the OMAP4 TRM doesn't list the NO_SLEEP >>>> mode as supported by the EMU. It seems to me that if the IP supports >>>> HW_AUTO, it should be able to be enabled *and* disabled. >>> >>> No, not really, this is mostly OMAP3 legacy, and we do have plan to remove these useless modes going forward. We can effectively disable AUTO mode by going to FORCE_WAKEUP. >>> >>> - 0x0 NO_SLEEP A clock domain sleep transition is never initiated, irrespective of the hardware conditions. >>> - 0x1 SW_SLEEP A software-forced sleep transition. The transition is initiated when the associated hardware conditions are satisfied >>> - 0x2 SW_WKUP A software-forced clock domain wake-up transition is initiated, irrespective of the hardware conditions. >>> - 0x3 HW_AUTO Hardware-controlled automatic sleep and wake-up transition is initiated by the PRCM module when the associated hardware conditions are satisfied >>> >>> >>> On OMAP4, SW_SLEEP is equivalent to ENABLE_AUTO and >>> NO_SLEEP is equivalent to SW_WKUP. There are some slight differences inside the HW, but in term of functionality this is mostly equivalent. >>> >>> >>> Bottom-line, if we fix the omap4_cminst_clkdm_disable_hwsup, we can consider that the EMU CD does support CLKDM_CAN_ENABLE_AUTO, CLKDM_CAN_DISABLE_AUTO and CLKDM_CAN_FORCE_WAKEUP, which is equivalent to CLKDM_CAN_HWSUP | CLKDM_CAN_FORCE_WAKEUP. >> >> Per our discussion and just to re-iterate here for OMAP4+ devices, we >> should have ... >> >> CAN_DISABLE_AUTO --> SW_WKUP >> CAN_ENABLE_AUTO --> HW_AUTO >> CAN_FORCE_WAKEUP --> SW_WKUP >> CAN_FORCE_SLEEP --> HW_AUTO >> >> Hence, the NO_SLEEP and SW_SLEEP should not be used for OMAP4+ (per the >> equivalents highlighted above). At least that is the current theory :-) > > I realise now the the l4cfg CD does not support SW_WKUP and so I guess > we still need NO_SLEEP in that case. So that would break the above > mapping and we would have to handle it in software. I have posted my latest series here [1] based upon that from Will [2] which attempts to fix the EMU CD based upon the inputs from this thread. It is working on my omap4460 panda. Hopefully Ming and/or Will can also test. I know that Ming is out this week but said he can test next week. Cheers Jon [1] http://marc.info/?l=linux-omap&m=133659938028348&w=2 [2] git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git perf/omap4