Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2066589imm; Thu, 24 May 2018 05:19:36 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqYCpjSYCDfg3Oblvv6cErgYBIdxDfZsoUfOE8hPkHJjUkb/U0Xz/0JNu/jE31X8nkJsTNs X-Received: by 2002:a63:3759:: with SMTP id g25-v6mr946837pgn.59.1527164376671; Thu, 24 May 2018 05:19:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527164376; cv=none; d=google.com; s=arc-20160816; b=ZR27SIgXCfcZ0oaVgmkpR2sxltC5PASIE9PPr8l6zG8SvNUtkrzX3tNd4GjVnK2ZYJ y3TH4/e7iqC8hK9tTi/Qucwendg6M3fJfdyQ+d8vHqxBbkir4cZLyOmlSdEAxGKOkX4A syeCe75fUwl/dM6Av4hpanl0zIQoj2arS/21tGiAdjn3J8EE1qbcIXFccz8YZG9ku+pp zButXuRsEdzlseAdam6JK9zoc0gScuUVhWU2BijYAYwy5ejOGzH1PxpobrUdTDbhoqSV N3V1jeIZsx25Ai44uSltGHKVeBwbrb652yKmYNLsjO5iXRY0g5n98kXH3QXuj88tccGs yP3w== 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=OUf+n0WkcI1KjI3dSQMWSGdlXtR+g1Jjkr/mDkXTqc0=; b=e/NnjzzaMsBbHhf2fzj4p5iHModfSAOxIknT7ryaZVAxsJ6tCu4fOAevcTCPSWR7IE kGByo4tyo3rvzBQ02yzoJttc3OAPjzfUyIy1Fbtq3i7hHoXBUGbeasJVPZTXtpxM8aqS 8+Ni5JbjCNvjgt2DRXmy2SNkXLC37GXC+sd77EVbfTtuBH6SD7ojetv70Q+jWycijhjA CglkskmrWHNGYxFXwNUoCPMffB+99RgyAngt7kNMe3eZForNNocnezO2GyVBV3cWS5ZY 58pI8Xpbt4yDF5/39RGhVzwcxIsSknalqhlqpmZHcTfDMkBAcLOkAaxf0spJcfR3+HcZ 27vg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=eUku5ciK; 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 w13-v6si7773436pgp.195.2018.05.24.05.19.21; Thu, 24 May 2018 05:19:36 -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=eUku5ciK; 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 S969917AbeEXMRf (ORCPT + 99 others); Thu, 24 May 2018 08:17:35 -0400 Received: from mail-it0-f67.google.com ([209.85.214.67]:50979 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966450AbeEXMR3 (ORCPT ); Thu, 24 May 2018 08:17:29 -0400 Received: by mail-it0-f67.google.com with SMTP id p3-v6so2054669itc.0 for ; Thu, 24 May 2018 05:17:28 -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=OUf+n0WkcI1KjI3dSQMWSGdlXtR+g1Jjkr/mDkXTqc0=; b=eUku5ciKDgXLfenQ0gMwHb6NCptQ0zLMFGSxI4rPbKTFTEXjI8cRLxBLwoY5GT+mJr eTa2OCPaX2AO6GS+b8WQAiOkv/4dnLOZ2s6tWfqD9chtx6TuDMCDVT/fCKqO98gnfyqZ KPXkd9+QQTS8UcZ2sg9RiJewLQAWXYuXsRjT0= 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=OUf+n0WkcI1KjI3dSQMWSGdlXtR+g1Jjkr/mDkXTqc0=; b=t+aG/kD4BHgUgPDiUybKqYHJZvCoUEhhbv/hTSC7ISOK44B+GPLkOuHPfS3vwYXM2i 2TRPbSEKhuhcZT6ke9zczDNn/hQAGtUcOwpMLrPmdwFwrP1Lb5vYJQZ/gBDikPl8ND3r dpuzPE3Q9nXGmAOEX+bs+IhPKGBj4D2hIeIwGbAVQ5M3AqpVJwnHGbCIezg8W4e8SjQI b+SCdte30jVZ4WMyjiqcHZVm1+zaE6jfAVeL3TFhCNoJQsaUuKjD/2dBfl9ZN1/I2VbC Y2+Xj+EL9O1dgF6Trd3N9P7oHo3z9t17sCwhnli9dC62f4SDq1Ugl2hbH2BFdUBHcFAU 8R1Q== X-Gm-Message-State: ALKqPwf0DLsUIzaLvmIuq9I5vDhI0styEFvI3bqyHQv2nT7y5ku2zkTs DCp2JBR/8AwA9K0pAWzeK75WFhXYxDn6BPPHPjbwWQ== X-Received: by 2002:a24:694b:: with SMTP id e72-v6mr9374872itc.38.1527164248199; Thu, 24 May 2018 05:17:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:7353:0:0:0:0:0 with HTTP; Thu, 24 May 2018 05:17:27 -0700 (PDT) In-Reply-To: <1687797a-93f1-7e5c-6060-01c12c070964@nvidia.com> References: <1526639490-12167-1-git-send-email-ulf.hansson@linaro.org> <1526639490-12167-9-git-send-email-ulf.hansson@linaro.org> <5a79d3a2-d090-645b-da69-524b7e7a4d90@nvidia.com> <51f7de26-579a-8b9e-4e79-f4eee923ab38@codeaurora.org> <3838f17a-2ac8-bf3f-f0b1-f69bbe17629c@nvidia.com> <1687797a-93f1-7e5c-6060-01c12c070964@nvidia.com> From: Ulf Hansson Date: Thu, 24 May 2018 14:17:27 +0200 Message-ID: Subject: Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd To: Jon Hunter Cc: Rajendra Nayak , Geert Uytterhoeven , Linux PM , Greg Kroah-Hartman , Kevin Hilman , "Rafael J . Wysocki" , Linux Kernel Mailing List , Todor Tomov , Viresh Kumar , linux-tegra@vger.kernel.org, Vincent Guittot , Linux ARM 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 24 May 2018 at 11:36, Jon Hunter wrote: > > On 24/05/18 08:04, Ulf Hansson wrote: > > ... > >>> Any reason why we could not add a 'boolean' argument to the API to >>> indicate >>> whether the new device should be linked? I think that I prefer the API >>> handles it, but I can see there could be instances where drivers may wish >>> to >>> handle it themselves. >> >> >> Coming back to this question. Both Tegra XUSB and Qcom Camera use >> case, would benefit from doing the linking themselves, as it needs >> different PM domains to be powered on depending on the current use >> case - as to avoid wasting power. >> >> However, I can understand that you prefer some simplicity over >> optimizations, as you told us. Then, does it mean that you are >> insisting on extending the APIs with a boolean for linking, or are you >> fine with the driver to call device_link_add()? > > > I am fine with the driver calling device_link_add(), but I just wonder if we > will find a several drivers doing this and then we will end up doing this > later anyway. Okay. > > The current API is called ... > > * genpd_dev_pm_attach_by_id() - Attach a device to one of its PM domain. > * @dev: Device to attach. > * @index: The index of the PM domain. > > This naming and description is a bit misleading, because really it is not > attaching the device that is passed, but creating a new device to attach a > PM domain to. So we should consider renaming and changing the description > and indicate that users need to link the device. I picked the name to be consistent with the existing genpd_dev_pm_attach(). Do you have a better suggestion? I agree, some details is missing to the description, let me try to improve it. Actually, I was trying to follow existing descriptions from genpd_dev_pm_attach(), so perhaps that also needs a little update. However, do note that, neither genpd_dev_pm_attach() or genpd_dev_pm_attach_by_id() is supposed to be called by drivers, but rather only by the driver core. So description may not be so important. In regards to good descriptions, for sure the API added in patch9, dev_pm_domain_attach_by_id(), needs a good one, as this is what drivers should be using. > > Finally, how is a PM domain attached via calling genpd_dev_pm_attach_by_id() > detached? Via the existing genpd_dev_pm_detach(), according to what I have described in the change log. I clarify the description in regards to this as well. Kind regards Uffe