From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB939C352A3 for ; Fri, 7 Feb 2020 02:04:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ADEB520715 for ; Fri, 7 Feb 2020 02:04:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="n54HafII" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727003AbgBGCES (ORCPT ); Thu, 6 Feb 2020 21:04:18 -0500 Received: from mail-qv1-f65.google.com ([209.85.219.65]:42851 "EHLO mail-qv1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726956AbgBGCES (ORCPT ); Thu, 6 Feb 2020 21:04:18 -0500 Received: by mail-qv1-f65.google.com with SMTP id dc14so272890qvb.9 for ; Thu, 06 Feb 2020 18:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=f/k2mGN9MY7NNfoOb4gMqNsjIZIFXh28kOhlDVSQmA0=; b=n54HafII/Lex3YLQXDbmveG7TRPxgfQUwWoNXykBlSczgnFnbEiABU6Nlwne2EnVqZ BLZNg9eH05yf+6HnfQFJWO3Ox35KsJoJtLmFEwLlc7LmqfuMonfkWKrE2MVp0ijf+rlC pgFHFzmYKEZYMyZMpnzqCt5JXY3Du2ndL/p2s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=f/k2mGN9MY7NNfoOb4gMqNsjIZIFXh28kOhlDVSQmA0=; b=fr411P74IsNPzMoYxXrsmCI3apCS1qsnMGolwgpuCZG2dWt5PeJy8glkEoMxpk1Ox/ tT5M/Xx4wLiUUrFPbRb4Wk2RCZ1WNb+xlzKUbRK7e9aWtuG4Dl6aLu9Toa09TkrkRpkI swV6wEC6ScO220ZnQbOfMDgwCwKCxH70A0t/t7ZI1UvUCelb9j5Xc9VqhyPm0haLP6Lc r78b/bKCbhqDuCjuzWExa0gliNQxHhmwzKOkaNr0My9hob9k2KhJwV6IZZ9B3KmHQplQ xYG5kpuztHzqCv4VfZUwSdOjyvdj6IiPafMDhLeO0LyOqAzE8dixbKf32CUaaSIdW9gv xSAw== X-Gm-Message-State: APjAAAVRog9Pl8YI0Mu47VI92gj2k9iNiseK55xFrMXel3I2pJkMM1/0 mL8ShnBnkvHhBmki4JbPBztPF0nkDvLGMD12um0DBw== X-Google-Smtp-Source: APXvYqy6BPTxmJROJmd8xpRbLnJsPInZlt9zqkAt5bAH9XGkXglHOonteC+kQPoH8wbuH3FDnIt6xkHqcmjd+EAPUBo= X-Received: by 2002:ad4:5a48:: with SMTP id ej8mr4977078qvb.187.1581041055375; Thu, 06 Feb 2020 18:04:15 -0800 (PST) MIME-Version: 1.0 References: <20200108052337.65916-1-drinkcat@chromium.org> <20200108052337.65916-6-drinkcat@chromium.org> In-Reply-To: From: Nicolas Boichat Date: Fri, 7 Feb 2020 10:04:04 +0800 Message-ID: Subject: Re: [PATCH v2 5/7] drm/panfrost: Add support for multiple power domain support To: Ulf Hansson Cc: Steven Price , Rob Herring , Mark Rutland , Devicetree List , Tomeu Vizoso , David Airlie , lkml , Liam Girdwood , dri-devel , Mark Brown , "moderated list:ARM/Mediatek SoC support" , Alyssa Rosenzweig , Hsin-Yi Wang , Matthias Brugger , linux-arm Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Ulf, On Mon, Jan 27, 2020 at 3:55 PM Ulf Hansson wrote: > > On Fri, 10 Jan 2020 at 02:53, Nicolas Boichat wro= te: > > > > +Ulf to keep me honest on the power domains > > > > On Thu, Jan 9, 2020 at 10:08 PM Steven Price wro= te: > > > > > > On 08/01/2020 05:23, Nicolas Boichat wrote: > > > > When there is a single power domain per device, the core will > > > > ensure the power domains are all switched on. > > > > > > > > However, when there are multiple ones, as in MT8183 Bifrost GPU, > > > > we need to handle them in driver code. > > > > > > > > > > > > Signed-off-by: Nicolas Boichat > > > > --- > > > > > > > > The downstream driver we use on chromeos-4.19 currently uses 2 > > > > additional devices in device tree to accomodate for this [1], but > > > > I believe this solution is cleaner. > > > > > > I'm not sure what is best, but it seems odd to encode this into the P= anfrost driver itself - it doesn't have any knowledge of what to do with th= ese power domains. The naming of the domains looks suspiciously like someon= e thought that e.g. only half of the cores could be powered, but it doesn't= look like that was implemented in the chromeos driver linked and anyway th= at is *meant* to be automatic in the hardware! (I.e. if you only power up o= ne cores in one core stack then the PDC should only enable the power domain= for that set of cores). > > > > This is actually implemented in the Chrome OS driver [1]. IMHO power > > domains are a bit confusing [2]: > > i. If there's only 1 power domain in the device, then the core takes > > care of power on the domain (based on pm_runtime) > > ii. If there's more than 1 power domain, then the device needs to > > link the domains manually. > > > > So the Chrome OS [1] driver takes approach (i), by creating 3 devices, > > each with 1 power domain that is switched on/off automatically using > > pm_runtime. > > > > This patch takes approach (ii) with device links to handle the extra do= mains. > > > > I believe the latter is more upstream-friendly, but, as always, > > suggestions welcome. > > Apologies for the late reply. A few comments below. No worries, than for the helpful reply! > If the device is partitioned across multiple PM domains (it may need > several power rails), then that should be described with the "multi PM > domain" approach in the DTS. As in (ii). > > Using "device links" is however optional, as it may depend on the use > case. If all multiple PM domains needs to be powered on/off together, > then it's certainly recommended to use device links. That's the case here, there's no support for turning on/off the domains individually. > However, if the PM domains can be powered on/off independently (one > can be on while another is off), then it's probably easier to operate > directly with runtime PM, on the returned struct *device from > dev_pm_domain_attach_by_id(). > > Also note, there is dev_pm_domain_attach_by_name(), which allows us to > specify a name for the PM domain in the DTS, rather than using an > index. This may be more future proof to use. Agree, probably better to have actual names than just "counting" the number of domains like I do, especially as we have a compatible struct anyway. I'll update the patch. > [...] > > Hope this helps. > > Kind regards > Uffe