From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jordan Crouse Subject: Re: [PATCH V3 0/5] iommu/arm-smmu: Add runtime pm/sleep support Date: Fri, 7 Apr 2017 12:01:05 -0600 Message-ID: <20170407180105.GA22050@jcrouse-lnx.qualcomm.com> References: <1489073748-3659-1-git-send-email-sricharan@codeaurora.org> <20170331175457.GD4897@arm.com> <20170403172307.GI5706@arm.com> <20170404193914.GF18246@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]:38674 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934660AbdDGSBK (ORCPT ); Fri, 7 Apr 2017 14:01:10 -0400 Content-Disposition: inline In-Reply-To: <20170404193914.GF18246@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Stephen Boyd Cc: Will Deacon , Mark Rutland , "devicetree@vger.kernel.org" , Mathieu Poirier , linux-arm-msm , "iommu@lists.linux-foundation.org" , Rob Herring , linux-clk@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" On Tue, Apr 04, 2017 at 12:39:14PM -0700, Stephen Boyd wrote: > On 04/03, Will Deacon wrote: > > On Fri, Mar 31, 2017 at 10:58:16PM -0400, Rob Clark wrote: > > > On Fri, Mar 31, 2017 at 1:54 PM, Will Deacon wrote: > > > > On Thu, Mar 09, 2017 at 09:05:43PM +0530, Sricharan R wrote: > > > >> This series provides the support for turning on the arm-smmu's > > > >> clocks/power domains using runtime pm. This is done using the > > > >> recently introduced device links patches, which lets the symmu's > > > >> runtime to follow the master's runtime pm, so the smmu remains > > > >> powered only when the masters use it. > > > > > > > > Do you have any numbers for the power savings you achieve with this? > > > > How often do we actually manage to stop the SMMU clocks on an SoC with > > > > a handful of masters? > > > > > > > > In other words, is this too coarse-grained to be useful, or is it common > > > > that all the devices upstream of the SMMU are suspended? > > > > > > well, if you think about a phone/tablet with a command mode panel, > > > pretty much all devices will be suspended most of the time ;-) > > > > Well, that's really what I was asking about. I assumed that periodic > > modem/radio transactions would keep the SMMU clocked, so would like to get a > > rough idea of the power savings achieved with this coarse-grained approach. > > Sometimes we distribute SMMUs to each IP block in the system and > let each one of those live in their own clock + power domain. In > these cases, the SMMU can be powered down along with the only IP > block that uses it. Furthermore, sometimes we put the IP block > and the SMMU inside the same power domain to really tie the two > together, so we definitely have cases where all devices (device?) > upstream of the SMMU are suspended. And in the case of > multimedia, it could be very often that something like the camera > app isn't open and thus the SMMU dedicated for the camera can be > powered down. > > Other times we have two SMMUs in the system where one is > dedicated to GPU and the other is "everything else". Even in > these cases, we can suspend the GPU one when the GPU is inactive > because it's the only consumer. The other SMMU might not be as > fine grained, but I think we still power it down quite often > because the consumers are mostly multimedia devices that aren't > active when the display is off. And just to confuse things even further: with per-instance pagetables we have an interest in forcing the SMMU clocks *on* because we don't know when the GPU might try to hit the registers to switch a pagetable and if somebody in the pipeline is actively trying to do power management at the same time hilarity will ensue. The alternative to pm_runtime is the downstream driver that probes the SMMU clocks from DT and frobs them itself. I think we can agree that is far less reasonable. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project From mboxrd@z Thu Jan 1 00:00:00 1970 From: jcrouse@codeaurora.org (Jordan Crouse) Date: Fri, 7 Apr 2017 12:01:05 -0600 Subject: [PATCH V3 0/5] iommu/arm-smmu: Add runtime pm/sleep support In-Reply-To: <20170404193914.GF18246@codeaurora.org> References: <1489073748-3659-1-git-send-email-sricharan@codeaurora.org> <20170331175457.GD4897@arm.com> <20170403172307.GI5706@arm.com> <20170404193914.GF18246@codeaurora.org> Message-ID: <20170407180105.GA22050@jcrouse-lnx.qualcomm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Apr 04, 2017 at 12:39:14PM -0700, Stephen Boyd wrote: > On 04/03, Will Deacon wrote: > > On Fri, Mar 31, 2017 at 10:58:16PM -0400, Rob Clark wrote: > > > On Fri, Mar 31, 2017 at 1:54 PM, Will Deacon wrote: > > > > On Thu, Mar 09, 2017 at 09:05:43PM +0530, Sricharan R wrote: > > > >> This series provides the support for turning on the arm-smmu's > > > >> clocks/power domains using runtime pm. This is done using the > > > >> recently introduced device links patches, which lets the symmu's > > > >> runtime to follow the master's runtime pm, so the smmu remains > > > >> powered only when the masters use it. > > > > > > > > Do you have any numbers for the power savings you achieve with this? > > > > How often do we actually manage to stop the SMMU clocks on an SoC with > > > > a handful of masters? > > > > > > > > In other words, is this too coarse-grained to be useful, or is it common > > > > that all the devices upstream of the SMMU are suspended? > > > > > > well, if you think about a phone/tablet with a command mode panel, > > > pretty much all devices will be suspended most of the time ;-) > > > > Well, that's really what I was asking about. I assumed that periodic > > modem/radio transactions would keep the SMMU clocked, so would like to get a > > rough idea of the power savings achieved with this coarse-grained approach. > > Sometimes we distribute SMMUs to each IP block in the system and > let each one of those live in their own clock + power domain. In > these cases, the SMMU can be powered down along with the only IP > block that uses it. Furthermore, sometimes we put the IP block > and the SMMU inside the same power domain to really tie the two > together, so we definitely have cases where all devices (device?) > upstream of the SMMU are suspended. And in the case of > multimedia, it could be very often that something like the camera > app isn't open and thus the SMMU dedicated for the camera can be > powered down. > > Other times we have two SMMUs in the system where one is > dedicated to GPU and the other is "everything else". Even in > these cases, we can suspend the GPU one when the GPU is inactive > because it's the only consumer. The other SMMU might not be as > fine grained, but I think we still power it down quite often > because the consumers are mostly multimedia devices that aren't > active when the display is off. And just to confuse things even further: with per-instance pagetables we have an interest in forcing the SMMU clocks *on* because we don't know when the GPU might try to hit the registers to switch a pagetable and if somebody in the pipeline is actively trying to do power management at the same time hilarity will ensue. The alternative to pm_runtime is the downstream driver that probes the SMMU clocks from DT and frobs them itself. I think we can agree that is far less reasonable. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project