Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1952297AbdDZJ4C (ORCPT ); Wed, 26 Apr 2017 05:56:02 -0400 Received: from mail-qk0-f175.google.com ([209.85.220.175]:36728 "EHLO mail-qk0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1435419AbdDZJzv (ORCPT ); Wed, 26 Apr 2017 05:55:51 -0400 MIME-Version: 1.0 In-Reply-To: References: <1490710443-27425-1-git-send-email-jonathanh@nvidia.com> From: Ulf Hansson Date: Wed, 26 Apr 2017 11:55:50 +0200 Message-ID: Subject: Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains To: Geert Uytterhoeven Cc: Jon Hunter , "Rafael J . Wysocki" , Kevin Hilman , Rajendra Nayak , Stanimir Varbanov , Stephen Boyd , Marek Szyprowski , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3733 Lines: 80 On 26 April 2017 at 11:17, Geert Uytterhoeven wrote: > Hi Ulf, > > On Wed, Apr 26, 2017 at 11:04 AM, Ulf Hansson wrote: >> On 26 April 2017 at 10:06, Geert Uytterhoeven wrote: >>> On Tue, Apr 25, 2017 at 9:34 PM, Ulf Hansson wrote: >>>> However, we currently know about at least two different SoCs that need >>>> this. Perhaps we can extend the below list to justify adding a new >>>> framework/APIs. Something along the lines what you propose in $subject >>>> patchset. >>>> >>>> 1) Nvidia; to solve the USB super-speed host/device problem. >>>> 2) QCOM, which has pointed to several cases where the PM topology is >>>> laid out like devices having two PM domains.. >>>> 3?) I don't fully remember - but I think Geert also pointed to some >>>> examples where a device could reside in a clock domain but also in >>>> power domain for a Renesas SoC!? >>>> 4) ? >>> >>> Most Renesas SoCs have module clocks, which we model as a clock domain. >>> Some Renesas SoCs have power domains for CPUs, others have them for >>> devices as well. >>> As we always provide a virtual "always-on" power domain in the power domain >>> controller, all devices can refer to it using "power-domains" properties, >>> and the driver for the power domain controller can just forward the clock >>> domain operations to the clock driver. >> >> Okay, thanks for clarifying this. >> >> Thinking about this as bit more, when I realized that *if* we would >> add a new PM domain framework for explicit control of PM domains, that >> would mean you need to deploy support for that in the drivers. > > Correct. And we have to update DT bindings and DTS. > >> On the other hand, as you anyway would need to change the drivers, you >> could instead deploy clock support in the drivers, which would avoid >> using the clock domain. In that way, you could still stay with one PM >> domain pointer per device, used to control the power domains instead. >> Right? Or would that have other implications? > > That's exactly what we're doing already. No really, but perhaps I was not clear enough. Currently you deploy only runtime PM support in the driver and don't do any clk_get() etc. Then you have a PM domain (genpd) attached to the device and makes use of genpd's device specific callbacks, in struct gpd_dev_ops ->start|stop(), which allows you to control clocks for each device. Of course this is perfectly okay. So then my question is/was; does there exist cases when these devices (already attached to a PM domain) would needed to be attach to yet another separate PM domain? From the nicely detailed description below, I find the answer to be *no*!? > Which means that if you allow multiple entries in power-domains, we > have to change drivers, DT bindings, and DTS again (which we may > decide not to do ;-) > > On SH/R-Mobile, we always did it that way, as the user manual had an > explicit "always-on" power domain. > > On R-Car Gen2, the power domains contain CPU and L2 and GPU only, > so devices had their power-domains pointing to the clock controller. > > On R-Car Gen3, some devices were moved into power domains, so we > generalized this by creating a virtual "always-on" power domain, and > letting all devices point their power-domains properties to the power > domain controller, which forwards clock handling to the clock controller. > For consistency, this was applied to R-Car Gen2 as well. > > Cfr. some late relics fixed in e.g. commit 24b2d930a50662c1 > ('ARM: dts: r8a7794: Use SYSC "always-on" PM Domain for sound'), > but technically the fix was not needed, as it worked fine without. Thanks for the detailed summary! Kind regards Uffe