Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp653322imm; Wed, 23 May 2018 03:24:11 -0700 (PDT) X-Google-Smtp-Source: AB8JxZowRYQYDVgd6zMhbqbS9ys16EbkwK/PTvdiVPb/0H/xyeRQPNaOpXuhdndKSTQvgoO/9ZpB X-Received: by 2002:a65:52c8:: with SMTP id z8-v6mr1892157pgp.46.1527071051318; Wed, 23 May 2018 03:24:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527071051; cv=none; d=google.com; s=arc-20160816; b=jrxMxR4PacEkhbMzQ3n3J8Pos0XLalwRnPKpXmBK0r77iLIplYN+D18T7wnBD98lyx lXd6md2LJ0ESrb0Hc2T4DAh1rXMndFtiutccaqyuKKfIWhbXR4QwmaqJYM93vuHtDd7n mKMzryKtKz8N7oWS4A9+hAgnUB9iYWal5TKXn+8qGKoIYi/FhobAYZ4c0kEl+FXExezM Uzs+XdXU6srNfxE4646+x2csO6oUZ2K9B4oziRLxkIi/qoa0kPNzAmHbInHZ5+mo31Gd lTJRGg89pgrU5azDZNu69V50KSpX69spTojgYK+XcTrj04xFCSpv7P+NPNpRm8Aa4wMJ x3EQ== 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=KkDrtB8y4CMBXYdSeKCCDUg31bzdxgSuzNW7Cdp9+a8=; b=BVQRkOLZIQ6VVwcRE5W8lxjuTEwl6nUpL9YY8tn+6NB4ikq3TJ1idVS/3qjWnvrhxI Gdpkk9d2QVehliZUs1v7ytR0JdCUcA51JrCEfeNqPJa6G8ugO74uqkBQCQDrJoUBt94y iO2EHrluPeLZyIaDk0c+qKj3f8z0B8SMBYJYexxSJZnE0qHAzA9Z7DGZBYby9++h23yq xkJng9oDebLt6QRjD7SbYq2lX84y7jgwaPTuoBoopUvdQ/vQ4V6p84j68xgoiRZSWjDc 9o+taeYsD/+UrBgZyF20guWdWMJKbKNE0AfKKg4OTN/hNYzUO/jiV0Vshq7QzNXxmEvp zrHg== 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 o76-v6si18336429pfj.118.2018.05.23.03.23.16; Wed, 23 May 2018 03:24:11 -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 S932427AbeEWKWP (ORCPT + 99 others); Wed, 23 May 2018 06:22:15 -0400 Received: from hqemgate14.nvidia.com ([216.228.121.143]:4902 "EHLO hqemgate14.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932243AbeEWKWO (ORCPT ); Wed, 23 May 2018 06:22:14 -0400 Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqemgate14.nvidia.com (using TLS: TLSv1, AES128-SHA) id ; Wed, 23 May 2018 03:22:16 -0700 Received: from HQMAIL101.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Wed, 23 May 2018 03:22:13 -0700 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Wed, 23 May 2018 03:22:13 -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 10:22:10 +0000 Subject: Re: [PATCH 8/9] PM / Domains: Add support for multi PM domains per device to genpd To: Ulf Hansson CC: Rajendra Nayak , 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> <3838f17a-2ac8-bf3f-f0b1-f69bbe17629c@nvidia.com> <00ba829d-faf4-168c-db00-531621b9280f@codeaurora.org> <22068fb1-f6e8-f2ec-d7f4-ab9e93469d7f@nvidia.com> From: Jon Hunter Message-ID: <8a3d0762-7d9c-8960-cdf9-f7f328f53692@nvidia.com> Date: Wed, 23 May 2018 11:22:08 +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: HQMAIL101.nvidia.com (172.20.187.10) 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 10:47, Ulf Hansson wrote: > On 23 May 2018 at 11:45, Jon Hunter wrote: >> >> On 23/05/18 10:33, Ulf Hansson wrote: >>> >>> On 23 May 2018 at 11:27, Rajendra Nayak wrote: >>>> >>>> >>>> >>>> On 05/23/2018 02:37 PM, Jon Hunter wrote: >>>>> >>>>> >>>>> 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? >>>> >>>> >>>> So if I understand this right, any driver which does want to control >>>> individual powerdomain state would >>>> need to do the linking itself right? >>>> >>>> What I am saying is, if I have device A, with powerdomains X and Y, and >>>> if I want to turn on only X, >>>> then I would want only X to be linked with A, and at a later point if I >>>> want both X and Y to be turned on, >>>> I would then go ahead and link both X and Y to A? Is that correct or did >>>> I get it all wrong? >>> >>> >>> Correct! >>> >>>> >>>> I know atleast Camera on msm8996 would need to do this since it has 2 vfe >>>> powerdoamins, which can be >>>> turned on one at a time (depending on what resolution needs to be >>>> supported) or both together if we >>>> really need very high resolution using both vfe modules. >>> >>> >>> I think this is also the case for the Tegra XUSB subsystem. >>> >>> The usb device is always attached to one PM domain, but depending on >>> if super-speed mode is used, another PM domain for that logic needs to >>> be powered on as well. >>> >>> Jon, please correct me if I am wrong! >> >> >> Yes this is technically correct, however, in reality I think we are always >> going to enable the superspeed domain if either the host or device domain is >> enabled. So we would probably always link the superspeed with the host and >> device devices. > > Why? Wouldn't that waste power if the superspeed mode isn't used? Simply to reduce complexity. Jon -- nvpublic