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 07:00:45 -0700 Message-ID: <87aa1isrg2.fsf@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> <4FA9138D.8010604@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from na3sys009aog125.obsmtp.com ([74.125.149.153]:57379 "EHLO na3sys009aog125.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753815Ab2EHOAi (ORCPT ); Tue, 8 May 2012 10:00:38 -0400 Received: by dadm1 with SMTP id m1so4287234dad.36 for ; Tue, 08 May 2012 07:00:30 -0700 (PDT) In-Reply-To: (Jean Pihet's message of "Tue, 8 May 2012 15:18:44 +0200") Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Jean Pihet Cc: "Cousson, Benoit" , Jon Hunter , Will Deacon , Paul Walmsley , Ming Lei , 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" 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. Kevin From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@ti.com (Kevin Hilman) Date: Tue, 08 May 2012 07:00:45 -0700 Subject: oprofile and ARM A9 hardware counter In-Reply-To: (Jean Pihet's message of "Tue, 8 May 2012 15:18:44 +0200") 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> <4FA9138D.8010604@ti.com> Message-ID: <87aa1isrg2.fsf@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. Kevin