Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp64102ybv; Thu, 6 Feb 2020 18:06:17 -0800 (PST) X-Google-Smtp-Source: APXvYqzd16nm75cEXSPTEsyXN/P7UCbV3hpB/DH4QypfDmzklqP9GlPfAekxbAIW5jGGOeU+ewZ5 X-Received: by 2002:aca:4309:: with SMTP id q9mr566458oia.158.1581041177437; Thu, 06 Feb 2020 18:06:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581041177; cv=none; d=google.com; s=arc-20160816; b=mt1I3H9dJYwXmRhFK4oiIETauhPJyfZRiMBefN4WKnBqFkZQKSl+qgQea9gkxT4oCo CHH2JkaM1IfnqjkVP/SLgEdbMNDnRH8QNtAll53S0Fi/PGdwXwbfctzG8Tyja4DEpt/f 53JL8XFojVu6IV1pD5Px+OK6vGB1mJ0dDF37l6KvDyRkyoVVdjUOuje5NyJbRSQmDafk eYwO4yCWDJKs8fb5mcGvJA0RXVVIR4vdjd2EqlecuA/pSvmSaDEU5m41N1m4OlfC/DTD PgZ93p68yNxJVBUaryvnLvXp+QZduUDoNNVNl2ANhZJULRT5Z0EgwIm/zmrWQVFUkZC+ hyzQ== 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:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=f/k2mGN9MY7NNfoOb4gMqNsjIZIFXh28kOhlDVSQmA0=; b=nsnAbQKOKpY7L0vH5SXJLJUoKzhLO7UhCg5dCnK+PU+649PRGVDWug4nrsoEaZ/hfW dpVHS793iWqSgMz8ggIsHDZWIYF3NIbN70/JQczmnEK880SQUBlt3fvuXR7RFwujOy++ QZHCJAHwwS1tUx7Ev7eT8+OlT6h+M8QVSW2Skw95KPukga1QolO8fSuZh3jojOG6V6OX uu9JdAcfDXrzVUUN4PF0gN2XfNm5PcdKUVm+wEofdUHKPM3tXJIlFfdm/bfBym9JgXYw 7ljVw+JxSE/AiPQVCT2F0FgeAu3MDrZWfLwoihGvK4UIe8h7bZ/hpElB+DhpHRfC3ONK D+cw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=n54HafII; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l9si819681oti.229.2020.02.06.18.06.02; Thu, 06 Feb 2020 18:06:17 -0800 (PST) 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=@chromium.org header.s=google header.b=n54HafII; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727178AbgBGCES (ORCPT + 99 others); Thu, 6 Feb 2020 21:04:18 -0500 Received: from mail-qv1-f68.google.com ([209.85.219.68]:43384 "EHLO mail-qv1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727000AbgBGCES (ORCPT ); Thu, 6 Feb 2020 21:04:18 -0500 Received: by mail-qv1-f68.google.com with SMTP id p2so269213qvo.10 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=kq2566EJw+5PXrf7qc2K0C4MQxCruoiRZhmoX142KMu+jxkYYOKhwgIZnC1qlpe5bF D5UsIZTSOdrvyhM1LDPBkIpX4ydzz1EvgXkjiFQC8aguJo+QvAGeApmQxN70713urFaj f5V79n1OwaRDBebSCbp31bfJkOfWHeiObHGYpLbhVSRi27DJTz4xw4C5y5EXcI09eOYv jRNm8KLydi9awig25aERCfaXmc+6odMd2qk7KYr9l9oleboZpvsy7d0kjfODAOguP2KR ZJhyNoaXNSXoSnfy75U0DwZAZGzvTpE9n35m626r2WIJHnWDPVDdu618iMKmaUfkElyb z/BA== X-Gm-Message-State: APjAAAUNEosIruZKIwa2IRLWlFOuGVSVkK2im5tquACvPUKNCd8iafGC oQ8YND7ARBOpJdfN1anV/0YP615MDmkxZlNfN/xepA== 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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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