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 <will.deacon@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
