Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752191AbdCMOwL convert rfc822-to-8bit (ORCPT ); Mon, 13 Mar 2017 10:52:11 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:14612 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751566AbdCMOwD (ORCPT ); Mon, 13 Mar 2017 10:52:03 -0400 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Mon, 13 Mar 2017 07:49:39 -0700 Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains To: Geert Uytterhoeven References: <1474367287-10402-1-git-send-email-jonathanh@nvidia.com> <52493231-71f4-1b62-b325-8532e63e4229@nvidia.com> <3e88692d-613b-9c25-2554-7d399c45637a@nvidia.com> <161ee6b9-7a76-c7b4-3cb4-06259fef4898@nvidia.com> CC: Ulf Hansson , "Rafael J. Wysocki" , Kevin Hilman , Rajendra Nayak , Stanimir Varbanov , Stephen Boyd , Marek Szyprowski , Linux PM list , "linux-kernel@vger.kernel.org" , "linux-tegra@vger.kernel.org" , Bjorn Andersson From: Jon Hunter Message-ID: Date: Mon, 13 Mar 2017 14:51:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.26.11.107] X-ClientProxiedBy: UKMAIL102.nvidia.com (10.26.138.15) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3608 Lines: 83 Hi Geert, On 13/03/17 14:38, Geert Uytterhoeven wrote: > Hi Jon, > > On Mon, Mar 13, 2017 at 3:27 PM, Jon Hunter wrote: >> On 13/03/17 14:19, Geert Uytterhoeven wrote: >>> On Mon, Mar 13, 2017 at 3:09 PM, Jon Hunter wrote: >>>> On 13/03/17 11:45, Ulf Hansson wrote: >>>>> +Björn >>>>> >>>>> On 13 March 2017 at 10:37, Jon Hunter wrote: >>>>>> Looks like there is still some interest/needs in/for this. Any thoughts >>>>>> on how we can move this forward? >>>>> >>>>> At the Linaro Connect last week, I was talking to Björn, Rajendra and >>>>> Stephen more about these related issues. >>>>> >>>>> It definitely seems like we need to progress with this somehow, >>>>> meaning we need a solution for being able to associate a device with >>>>> more than one PM domain. In that context, I don't think genpd based on >>>>> its current design, is a good fit to solve the problem. >>>>> >>>>> Instead I think we need something entirely new (perhaps some code can >>>>> be borrowed from genpd), which is more similar to the clock/regulator >>>>> framework. In other words, what you also were suggesting in a earlier >>>>> reply. >>>>> In this way, the driver/subsystem gains full flexibility of managing >>>>> its device's PM domains, which seems like the best future-proof >>>>> solution. >>>> >>>> I agree, I think that that would give us the most flexibility to handle >>>> whatever scenario. However, I was thinking that we could still use the >>>> genpd core to register pm-domains with and control. My thought was to >>>> allow devices to have a bindings with multiple pm-domains ... >>>> >>>> dev-xyz { >>>> ... >>>> power-domains = <&domain-a>, <&domain-b>; >>>> }; >>>> >>>> Then in the genpd core we do having something like ... >>>> >>>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c >>>> index e697dec9d25b..d1ae6ddf4903 100644 >>>> --- a/drivers/base/power/domain.c >>>> +++ b/drivers/base/power/domain.c >>>> @@ -2026,6 +2026,15 @@ int genpd_dev_pm_attach(struct device *dev) >>>> "samsung,power-domain", 0); >>>> if (!pd_args.np) >>>> return -ENOENT; >>>> + } else if (ret > 1) { >>>> + /* >>>> + * If there are more than one PM domain defined for a device, >>>> + * then these need to be manually controlled by the device >>>> + * driver because the genpd core cannot bind a device with >>> >>> Which device driver? >>> The driver for the device that belongs to multiple PM domains? >> >> Yes, exactly. So maybe I would need to say ... "manually controlled by >> the driver for *this* device ..." > > That looks a bit cumbersome to me. > > Power (and clock) domains are platform features. Any IP core may show up > in a new SoC, and suddenly have become part of one or more PM Domains. > Having to handle that in each individual driver will cause lots of churn. > Especially as the multiple PM Domains a device may belong to may be > fairly orthogonal to each other. Yes that's true. However, in order to make this work for everyone and have a generic solution I am not sure how that can be avoided. If there are cases where devices require multiple PM domains but the usage is quite simple (ie. all on when device in use and all off when device is not in use), I could see the APIs I proposed being extended to include some _bulk() versions like we have for regulators. Cheers Jon -- nvpublic