Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp589767imm; Wed, 23 May 2018 02:08:26 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpg7YCs8L10c3rL1qtMXmWHIXRlPwF1FPFvNdccInezdRH2QkO802G4SbMESUmf9/snu2M2 X-Received: by 2002:a17:902:8b82:: with SMTP id ay2-v6mr2063050plb.295.1527066506193; Wed, 23 May 2018 02:08:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527066506; cv=none; d=google.com; s=arc-20160816; b=vPLiWkpNAVkjztdGk1R06HXolI8AoX8UHGLRiqZwm234K2lfKXm0DHNJa2ofkSQL1a B6DTtNnc5DHbHIcW+y3kcldtHdI7MhfSi/HXp/JMuxrajxQUMwHUY3ONzkYn56UHMBy/ 10Gh4ztZG2Vn+GEA5QCsd9ZoppHRPo4lm+n9cOU47Kv3JcatqZKDZlRQGN+UoEKK3QIH SYUp9vO07VU8QWQfR3fx/6pW9M+2pi0PGMccUxLRsUo7oqOOkxRcUd9ddDtjRMIlLd9k JrrhEN5icIHWfi9soj1Zox5CKtgaKS/uqCZmNC2KwqpSJNMHyjrNI+JAj9KUnVAqiTd1 RVow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=iTav0ki0bl+UJ1SnuyDUqd6aVSNbTvD2UNnko8/e/44=; b=snvsljedWewUQcNcrEMbKeBfWVrHfD2hfCjEpz/rlnqzaYmL8SnANx6eY/O+GILolr A5MQ1Zzdhb6KqSmUlKyvFSLFjreRzWy8eKIW0L4jYOKc1qd1ukT1PDLsAlpQr3CnzauG HF9pUubMSj5ZiGXkvYbe91sni0vOy09lmCgZCjWDQdEgtTufGkQ7E0SHhppTO80GHl9h sWKFFj+i3ZFOLHsWUHqmucg/jh9PATQ8IZ0Y91h+Gi1EqQsBTOZ2urjD1SMRl83RfKp9 yxfBzGSiUHPQtiBX6bWpIl2csx7XuuLA0pRmP3J1XoUNP0F4ux84t+6GFEhX07pH1UIU 6KhA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b84-v6si20001676pfb.189.2018.05.23.02.08.11; Wed, 23 May 2018 02:08:26 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=nvidia.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932167AbeEWJHx (ORCPT + 99 others); Wed, 23 May 2018 05:07:53 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:18729 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754378AbeEWJHt (ORCPT ); Wed, 23 May 2018 05:07:49 -0400 Received: from hqpgpgate102.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com (using TLS: TLSv1, AES128-SHA) id ; Wed, 23 May 2018 02:07:52 -0700 Received: from HQMAIL101.nvidia.com ([172.20.161.6]) by hqpgpgate102.nvidia.com (PGP Universal service); Wed, 23 May 2018 02:07:50 -0700 X-PGP-Universal: processed; by hqpgpgate102.nvidia.com on Wed, 23 May 2018 02:07:50 -0700 Received: from [10.21.132.148] (10.124.1.5) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 23 May 2018 09:07:45 +0000 Subject: Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd To: Ulf Hansson , Rajendra Nayak CC: Geert Uytterhoeven , Linux PM , Greg Kroah-Hartman , Kevin Hilman , "Rafael J . Wysocki" , Linux Kernel Mailing List , Todor Tomov , Viresh Kumar , , Vincent Guittot , Linux ARM 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> From: Jon Hunter Message-ID: <3838f17a-2ac8-bf3f-f0b1-f69bbe17629c@nvidia.com> Date: Wed, 23 May 2018 10:07:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.124.1.5] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To HQMAIL101.nvidia.com (172.20.187.10) Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/05/18 07:12, Ulf Hansson wrote: ... >>>>> Thanks for sending this. Believe it or not this has still been on my to-do list >>>>> and so we definitely need a solution for Tegra. >>>>> >>>>> Looking at the above it appears that additional power-domains exposed as devices >>>>> to the client device. So I assume that this means that the drivers for devices >>>>> with multiple power-domains will need to call RPM APIs for each of these >>>>> additional power-domains. Is that correct? >>>> >>>> They can, but should not! >>>> >>>> Instead, the driver shall use device_link_add() and device_link_del(), >>>> dynamically, depending on what PM domain that their original device >>>> needs for the current running use case. >>>> >>>> In that way, they keep existing runtime PM deployment, operating on >>>> its original device. >>> >>> OK, sounds good. Any reason why the linking cannot be handled by the above API? Is there a use-case where you would not want it linked? >> >> I am guessing the linking is what would give the driver the ability to decide which subset of powerdomains it actually wants to control >> at any point using runtime PM. If we have cases wherein the driver would want to turn on/off _all_ its associated powerdomains _always_ >> then a default linking of all would help. > > First, I think we need to decide on *where* the linking should be > done, not at both places, as that would just mess up synchronization > of who is responsible for calling the device_link_del() at detach. > > Second, It would in principle be fine to call device_link_add() and > device_link_del() as a part of the attach/detach APIs. However, there > is a downside to such solution, which would be that the driver then > needs call the detach API, just to do device_link_del(). Of course > then it would also needs to call the attach API later if/when needed. > Doing this adds unnecessary overhead - comparing to just let the > driver call device_link_add|del() when needed. On the upside, yes, it > would put less burden on the drivers as it then only needs to care > about using one set of functions. > > Which solution do you prefer? 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. Rajendra, do you have a use-case right now where the driver would want to handle the linking? Cheers Jon -- nvpublic