Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3319751imm; Fri, 25 May 2018 03:46:21 -0700 (PDT) X-Google-Smtp-Source: AB8JxZp9SxN2iLwZQYPufFg46WOQ/RFCuouUonMjtrX7hBnxGstKW78T8uS5KkzIFZTVGTcovwYQ X-Received: by 2002:a17:902:422:: with SMTP id 31-v6mr2126918ple.320.1527245181176; Fri, 25 May 2018 03:46:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527245181; cv=none; d=google.com; s=arc-20160816; b=Lc0a8S+he6jJp2SRoJ2RLPfJVtEp+977YoJfKtd1oaUZ1tNQmoZQF/+Oiu9yusfbrM DqapHtTXJYLJ8L+UolCVbW75aeo6K574hu34vlzcB1sarsGseJILo54eHydiWsEnPyCd 55nacCk43mzFdJVNXaf+TNkB50hrwU/MKU6SZETCa4G4nRYK52yauWk2gwe9UwXKck/+ tdPMobw7NikVAM2ySmAOrMcDwgGaC1E5d7K7rlhj9Kd7QsCIA4sNfJJULkdlO3gXX4e0 Rh9o05Wfr4Nr339Rl20XMDxPlRjmdt84N9OgwgHh4kipSM5EmqRcNE4MACSTcoj8VcHT ucjg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=Z54XG3YjWwOhVhlcYiq/CRg4MEcQpZWgY04LKK2aixk=; b=RUDG99/SfGrX+VBymsiMDG0jNxnBCv8Xe0A4EsNodHrhIoY+WZAdY+Ev8EWL/l9TYq KncCL4UCKu6yhT5MZ4NKwiV3zZkA8wrHTdJ8OewP71hf+zl0pHYDuaRPj/Xmn1JBEw+d BOfyOrcRGIdl4yDMP/M1CBB7yonEbVna0ro05wZUzVtJxYNu4RBihgqsdHSULchih3iP kjKSepLcLt7Jx+O5NNeRiJntiOdW+g1GkrF+Cc3y78vP4z3055nCbz1Erl97H4Zt2WiS HkJzJvPilrob3AmX9iS1c/w4fP2R/P9EaKBHafoHdt1V+3pJl+o002SqcP2jc57LxJi+ DwYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=KH7sLKdv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a3-v6si21817666plc.574.2018.05.25.03.46.06; Fri, 25 May 2018 03:46:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=KH7sLKdv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965827AbeEYKpz (ORCPT + 99 others); Fri, 25 May 2018 06:45:55 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:39982 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965255AbeEYKpw (ORCPT ); Fri, 25 May 2018 06:45:52 -0400 Received: by mail-it0-f68.google.com with SMTP id j186-v6so6263024ita.5 for ; Fri, 25 May 2018 03:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z54XG3YjWwOhVhlcYiq/CRg4MEcQpZWgY04LKK2aixk=; b=KH7sLKdvOj3PAKFm4u3rOaZmtZ0Jy7Jywq5m+Qrwv6Kp7WZRA6jKyXQ1u5RBjfuQL1 6p7eqIqlBXuritVDew3mlJMGjriFDQ8qJoCH+ET+vp27Dj/VhBwaXrKXnZi/Q/id1bri Fx3ytppXSovGHddw1sXbMJ7Mh4ajfxQUqYGOk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z54XG3YjWwOhVhlcYiq/CRg4MEcQpZWgY04LKK2aixk=; b=pzMkcMhkt4VPPBf9S0N0XW0SphfQQ0whLarV+8/R+7Aq3iNMpv+mc4B+mdyT28yUzC 0tId8+eFX587QhPEqhPVJTs/kbuMpvxK1SRsu+1F7efZYkL708VtB/LP8JPi4rP5k6lq B8WQ1kSdD5uGZTLBJvkkmMSZwxoBf9Ris7lFkezLA0HQ2DBH5X3EYqfx5w11Cc1tkTpP DoMh7Q2sy9mMm2glAQjtS+bgI2K2iL84Ln8I3qPl5r4p8AIbmUN7+4J6nRccMRuq2mKp rd1BgaSnBbLaU39LGH4vsDGyVVqaJSFubdsG7NVpgFq17JfkR8Wh677wq2RTQTMN1VRX chKQ== X-Gm-Message-State: ALKqPwekmuPXWFjKKJ18AIZMmxNqssX5hmd8qYuPJTOu/DCLlEAW5+Xw 4ROWirvrEvd649QeeT+Tpx0oaD62w3ta01T5EKEA2Q== X-Received: by 2002:a24:694b:: with SMTP id e72-v6mr1543641itc.38.1527245152076; Fri, 25 May 2018 03:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:7353:0:0:0:0:0 with HTTP; Fri, 25 May 2018 03:45:51 -0700 (PDT) In-Reply-To: <2c63af8c-4745-a751-8d3d-f7122e921e6f@nvidia.com> References: <1526639490-12167-1-git-send-email-ulf.hansson@linaro.org> <1526639490-12167-10-git-send-email-ulf.hansson@linaro.org> <1c21d18e-954a-f3a8-9817-0117b7cb7e4f@nvidia.com> <2c63af8c-4745-a751-8d3d-f7122e921e6f@nvidia.com> From: Ulf Hansson Date: Fri, 25 May 2018 12:45:51 +0200 Message-ID: Subject: Re: [PATCH 9/9] PM / Domains: Add dev_pm_domain_attach_by_id() to manage multi PM domains To: Jon Hunter Cc: "Rafael J . Wysocki" , Linux PM , Greg Kroah-Hartman , Geert Uytterhoeven , Todor Tomov , Rajendra Nayak , Viresh Kumar , Vincent Guittot , Kevin Hilman , Linux Kernel Mailing List , Linux ARM , linux-tegra@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25 May 2018 at 10:31, Jon Hunter wrote: > > On 24/05/18 22:11, Ulf Hansson wrote: >> >> On 24 May 2018 at 17:48, Jon Hunter wrote: >>> >>> >>> On 18/05/18 11:31, Ulf Hansson wrote: >>>> >>>> >>>> The existing dev_pm_domain_attach() function, allows a single PM domain >>>> to >>>> be attached per device. To be able to support devices that are >>>> partitioned >>>> across multiple PM domains, let's introduce a new interface, >>>> dev_pm_domain_attach_by_id(). >>>> >>>> The dev_pm_domain_attach_by_id() returns a new allocated struct device >>>> with >>>> the corresponding attached PM domain. This enables for example a driver >>>> to >>>> operate on the new device from a power management point of view. The >>>> driver >>>> may then also benefit from using the received device, to set up so >>>> called >>>> device-links towards its original device. Depending on the situation, >>>> these >>>> links may then be dynamically changed. >>>> >>>> The new interface is typically called by drivers during their probe >>>> phase, >>>> in case they manages devices which uses multiple PM domains. If that is >>>> the >>>> case, the driver also becomes responsible of managing the detaching of >>>> the >>>> PM domains, which typically should be done at the remove phase. >>>> Detaching >>>> is done by calling the existing dev_pm_domain_detach() function and for >>>> each of the received devices from dev_pm_domain_attach_by_id(). >>>> >>>> Note, currently its only genpd that supports multiple PM domains per >>>> device, but dev_pm_domain_attach_by_id() can easily by extended to cover >>>> other PM domain types, if/when needed. >>>> >>>> Signed-off-by: Ulf Hansson >>>> --- >>>> drivers/base/power/common.c | 33 ++++++++++++++++++++++++++++++++- >>>> include/linux/pm_domain.h | 7 +++++++ >>>> 2 files changed, 39 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/base/power/common.c b/drivers/base/power/common.c >>>> index 7ae62b6..d3db974 100644 >>>> --- a/drivers/base/power/common.c >>>> +++ b/drivers/base/power/common.c >>>> @@ -117,13 +117,44 @@ int dev_pm_domain_attach(struct device *dev, bool >>>> power_on) >>>> EXPORT_SYMBOL_GPL(dev_pm_domain_attach); >>>> /** >>>> + * dev_pm_domain_attach_by_id - Attach a device to one of its PM >>>> domains. >>> >>> >>> >>> Isn't this more of a 'get'? >> >> >> I don't think so, at least according to the common understanding of >> how we use get and put APIs. >> >> For example, clk_get() returns a cookie to a clk, which you then can >> do a hole bunch of different clk specific operations on. >> >> This is different, there are no specific PM domain operations the >> caller can or should do. Instead the idea is to keep drivers more or >> less transparent, still using runtime PM as before. The only care the >> caller need to take is to use device links, which BTW isn't a PM >> domain specific thing. > > > Yes, but a user can still call pm_runtime_get/put with the device returned > if they wish to, right? Correct. [...] >>>> + */ >>>> +struct device *dev_pm_domain_attach_by_id(struct device *dev, >>>> + unsigned int index) >>>> +{ >>>> + if (dev->pm_domain) >>> >>> >>> >>> I wonder if this is worthy of a ... >>> >>> if (WARN_ON(dev->pm_domain)) >>> >>>> + return NULL; >>> >>> >>> >>> Don't we consider this an error case? I wonder why not return PTR_ERR >>> here >>> as well? This would be consistent with dev_pm_domain_attach(). >> >> >> Please see above comment. > > > Right, but this case still seems like an error. My understanding is that > only drivers will use this API directly and it will not be used by the > device driver core (unlike dev_pm_domain_attach), so if anyone calls this > attempting to attach another PM domain when one is already attached, they > are doing something wrong. [...] You may be right! What I was thinking of is whether multiple PM domains may be optional in some cases, but instead a PM domain have already been attached by dev_pm_domain_attach(), prior the driver starts to probe. Then, assuming we return an error for this case, that means the caller then need to check the dev->pm_domain pointer, prior calling dev_pm_domain_attach_by_id(). Wouldn't it? Perhaps that is more clear though? Kind regards Uffe