From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755230AbdJIQgz (ORCPT ); Mon, 9 Oct 2017 12:36:55 -0400 Received: from mail-wm0-f47.google.com ([74.125.82.47]:46674 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754387AbdJIQgx (ORCPT ); Mon, 9 Oct 2017 12:36:53 -0400 X-Google-Smtp-Source: AOwi7QBc+zTgjz5V0Qsmb6nPqWvZa5ypJSG2bbHeN867ddZ4MdAgcJ/WE+SLtP9o1A/6vNg9TLaubQ== Subject: Re: Re: [RFC PATCH 0/4] PM / Domains: Add support for explicit control of PM domains To: Jon Hunter , 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 , viresh.kumar@linaro.org 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> From: Todor Tomov Message-ID: <72397ec8-d169-c5b1-2120-459031b35d48@linaro.org> Date: Mon, 9 Oct 2017 19:36:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <5fcfeda6-f95c-cdaa-73a5-5c7499a3f9f5@codeaurora.org> 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 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? Thank you. Best regards, Todor