From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756073AbdJJJNf (ORCPT ); Tue, 10 Oct 2017 05:13:35 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:17201 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755344AbdJJJNc (ORCPT ); Tue, 10 Oct 2017 05:13:32 -0400 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Tue, 10 Oct 2017 02:13:07 -0700 Subject: Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains To: Todor Tomov , Ulf Hansson , "Rafael J. Wysocki" , "Kevin Hilman" , "linux-pm@vger.kernel.org" CC: Rajendra Nayak , "Rafael J. Wysocki" , Geert Uytterhoeven , "Stanimir Varbanov" , Stephen Boyd , Marek Szyprowski , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" , Bjorn Andersson , References: <1490710443-27425-1-git-send-email-jonathanh@nvidia.com> <1832647.f77WMLkdQb@aspire.rjw.lan> <107242f1-de90-b8bb-bc2c-feaf014485aa@nvidia.com> <5fcfeda6-f95c-cdaa-73a5-5c7499a3f9f5@codeaurora.org> <72397ec8-d169-c5b1-2120-459031b35d48@linaro.org> From: Jon Hunter Message-ID: <1a4f49f0-23f2-a037-c5ca-bbb8b58f0b67@nvidia.com> Date: Tue, 10 Oct 2017 10:13:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <72397ec8-d169-c5b1-2120-459031b35d48@linaro.org> X-Originating-IP: [10.21.132.144] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/10/17 17:36, Todor Tomov wrote: > Hi, > > On 30.05.2017 06:41, Rajendra Nayak wrote: >> [].. >> >>>>> I was proposing to have such a lower-layer by splitting the existing >>>>> genpd framework so the drivers would have the option of calling the >>>>> lower-level power control functions to look-up pm-domains and control >>>>> them directly from their rpm callbacks (if they need to). Same as we do >>>>> for clocks. This way you would not need to mess with the genpd ->start() >>>>> callback and leave it to the driver to handle itself as it knows what >>>>> needs to be done. This assumes that the device is never bound to the >>>>> pm-domain by the genpd core. >>>> >>>> Yes, agree! To me this is the only solution what would really work. >>> >>> I agree! :-) >>> >>>> Perhaps Rafael can confirm that he is fine with a solution like this? >>> >>> Yes and Rafael, please can you also elaborate on what you meant by >>> "allow genpd to use either a list of power resources or the on/off >>> callbacks provided by itself to cover different use cases"? >>> >>> I would like to understand exactly what you meant by allowing genpd to >>> use a list of power resources (ie. how you envisioned we could achieve >>> this). >> >> While thinking through the problem of devices associated with multiple Power >> domains (or power resources) and controlling them individually (or together) >> I was wondering if something like a PM domain governor (with PM resource >> level constraints) could help. >> >> So with just one set of PM domain callbacks, its quite easy to control multiple power >> resources, if they need to be *all* turned on/off together, using something similar to >> what Jon proposed in his RFC [1] >> >> However, there could be instances where in we might need to control them individually >> and in such cases we could hook up a PM domain governor which decides if an individual >> PM resource can be turned on or off while the device is runtime suspended/resumed. >> We can expose some PM resource level QoS APIs which the drivers can use to express their >> needs, which the PM domain governor then takes into account during the decision making. >> >> if this seems worth pursuing further, I can post some RFCs on these lines and >> get the discussion going. >> >> thanks, >> Rajendra >> >> [1] https://lkml.org/lkml/2016/9/20/173 >> > > I have come to a similar case with multiple power domains on Qualcomm APQ8096 - the > camera subsystem has two VFE modules (Video Front End - these are image processing modules) > and each of them has a separate power domain but we might want to control these from > a single driver. > > So I wanted to ask if there have been any news on this topic lately? There has not but there is still clearly a need for this and we need it for Tegra. I still plan to get back to this but recently a few items have cropped up and I have not had chance. So sorry about that. My plan was to split the current GPD framework so there is a lower-level set of APIs for managing the power-domains as I discussed with Rafael [0]. Cheers Jon [0] https://lkml.org/lkml/2017/5/2/203 -- nvpublic