From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Hilman Subject: Re: oprofile and ARM A9 hardware counter Date: Tue, 08 May 2012 14:28:40 -0700 Message-ID: <87mx5il5vb.fsf@ti.com> References: <20120403092524.GD17741@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> <4FA9138D.8010604@ti.com> <87aa1isrg2.fsf@ti.com> <4FA927B1.4020108@ti.com> <87wr4mr6io.fsf@ti.com> <4FA9794A.7030607@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from na3sys009aog117.obsmtp.com ([74.125.149.242]:48652 "EHLO na3sys009aog117.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754563Ab2EHV2Z (ORCPT ); Tue, 8 May 2012 17:28:25 -0400 Received: by pbbrq8 with SMTP id rq8so9673777pbb.21 for ; Tue, 08 May 2012 14:28:23 -0700 (PDT) In-Reply-To: <4FA9794A.7030607@ti.com> (Jon Hunter's message of "Tue, 8 May 2012 14:51:38 -0500") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Jon Hunter Cc: "Cousson, Benoit" , Paul Walmsley , Ming Lei , Will Deacon , Jean Pihet , 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" Jon Hunter writes: > On 05/08/2012 11:18 AM, Kevin Hilman wrote: >> "Cousson, Benoit" writes: >> >>> On 5/8/2012 4:00 PM, Kevin Hilman wrote: >>>> Jean Pihet writes: >>>> >>>> [...] >>>> >>>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The >>>>>>>> flags describe what the HW is capable of, and the EMU CD can support >>>>>>>> HW_AUTO >>>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid >>>>>>>> next >>>>>>>> power state is OFF, meaning that no retention mode is supported. So any >>>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup. >>>>>>>> >>>>>>>> That being said, being able to transition to OFF during idle is a >>>>>>>> perfectly >>>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to >>>>>>>> restore from OFF mode smoothly. >>>>>>>> >>>>>>>> It looks to me that what is missing here is *just* a restore path in the >>>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue >>>>>>>> :-) >>>>>>> >>>>>>> Although it is perfectly feasible to have a seamless transition of the >>>>>>> EMU power domain, I think the PMU counters will not be accurate >>>>>>> anymore since they stop counting events when going to OFF and re-start >>>>>>> after the state restore. >>>>>> >>>>>> >>>>>> Good point, but I think the PMU might still works fine because located >>>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is >>>>>> going to OFF and thus will be reset. >>>>> >>>>> Ever better point ;p Thanks for the precision. >>>>> In any case my point was: can we allow the EMU CD to go OFF or prevent >>>>> it from doing so? We need to answer that question first. >>>>> >>>> >>>> The idea I've suggested is to use runtime PM for this. As long as the >>>> PMU is in use, it will be runtime PM enabled (and not allowed to go into >>>> HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and >>>> then be reset. The next time it is needed, the runtime resume will need >>>> to do a full re-init. >>> >>> Oh, but does that mean that this driver is not pm_runtime adapted yet? >>> >> >> Actually, it is. Ming Lei has done it. >> >> Currently, Will has collected this[1] and is waiting (patiently) for us >> to produce a real fix that doesn't kill PM in the process. > > I had to make a couple mods to Ming's patches but I do have something > working now that _should_ not break PM. However, per my previous email > (in response to Benoit's) I am struggling with the definition of the > CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this. > > I was going to send out my patches, but I wanted to get some more > feedback on this first. While waiting for feeback, if you set the flags to CAN_FORCE_WAKEUP and CAN_HWSUP, can you get the PMU interrupts working after an EMU CD idle transition (and reset.) Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@ti.com (Kevin Hilman) Date: Tue, 08 May 2012 14:28:40 -0700 Subject: oprofile and ARM A9 hardware counter In-Reply-To: <4FA9794A.7030607@ti.com> (Jon Hunter's message of "Tue, 8 May 2012 14:51:38 -0500") References: <20120403092524.GD17741@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> <4FA9138D.8010604@ti.com> <87aa1isrg2.fsf@ti.com> <4FA927B1.4020108@ti.com> <87wr4mr6io.fsf@ti.com> <4FA9794A.7030607@ti.com> Message-ID: <87mx5il5vb.fsf@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Jon Hunter writes: > On 05/08/2012 11:18 AM, Kevin Hilman wrote: >> "Cousson, Benoit" writes: >> >>> On 5/8/2012 4:00 PM, Kevin Hilman wrote: >>>> Jean Pihet writes: >>>> >>>> [...] >>>> >>>>>>>> Yes, indeed, we should not hack the flags to fix that kind of issue. The >>>>>>>> flags describe what the HW is capable of, and the EMU CD can support >>>>>>>> HW_AUTO >>>>>>>> and SW_WAKEUP. AFAIK, the issue with that EMU CD is that the only valid >>>>>>>> next >>>>>>>> power state is OFF, meaning that no retention mode is supported. So any >>>>>>>> transition to idle will go to OFF and lead to a reset upon wakeup. >>>>>>>> >>>>>>>> That being said, being able to transition to OFF during idle is a >>>>>>>> perfectly >>>>>>>> valid state for most powerdomain in OMAP anyway, so we should be able to >>>>>>>> restore from OFF mode smoothly. >>>>>>>> >>>>>>>> It looks to me that what is missing here is *just* a restore path in the >>>>>>>> PMU/CTI code. But I'm probably missing some nasty details in this issue >>>>>>>> :-) >>>>>>> >>>>>>> Although it is perfectly feasible to have a seamless transition of the >>>>>>> EMU power domain, I think the PMU counters will not be accurate >>>>>>> anymore since they stop counting events when going to OFF and re-start >>>>>>> after the state restore. >>>>>> >>>>>> >>>>>> Good point, but I think the PMU might still works fine because located >>>>>> inside the MPU domain. AFAIR, only the path to access the PMU and the CTI is >>>>>> going to OFF and thus will be reset. >>>>> >>>>> Ever better point ;p Thanks for the precision. >>>>> In any case my point was: can we allow the EMU CD to go OFF or prevent >>>>> it from doing so? We need to answer that question first. >>>>> >>>> >>>> The idea I've suggested is to use runtime PM for this. As long as the >>>> PMU is in use, it will be runtime PM enabled (and not allowed to go into >>>> HWSUP idle.) When it is not used, it will be allowed to HWSUP idle, and >>>> then be reset. The next time it is needed, the runtime resume will need >>>> to do a full re-init. >>> >>> Oh, but does that mean that this driver is not pm_runtime adapted yet? >>> >> >> Actually, it is. Ming Lei has done it. >> >> Currently, Will has collected this[1] and is waiting (patiently) for us >> to produce a real fix that doesn't kill PM in the process. > > I had to make a couple mods to Ming's patches but I do have something > working now that _should_ not break PM. However, per my previous email > (in response to Benoit's) I am struggling with the definition of the > CLKDM_CAN_XXXXXX_AUTO flags to know the correct way to fix this. > > I was going to send out my patches, but I wanted to get some more > feedback on this first. While waiting for feeback, if you set the flags to CAN_FORCE_WAKEUP and CAN_HWSUP, can you get the PMU interrupts working after an EMU CD idle transition (and reset.) Kevin