Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp6336622ybv; Wed, 12 Feb 2020 10:14:55 -0800 (PST) X-Google-Smtp-Source: APXvYqwwz1R31PofgS8PorbewZak0rmLgWzy2BhKMsrcTQZEA9E49ueYdxUXHf+GE7FLSNPCKwd5 X-Received: by 2002:a05:6830:1e2d:: with SMTP id t13mr10652236otr.128.1581531294884; Wed, 12 Feb 2020 10:14:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581531294; cv=none; d=google.com; s=arc-20160816; b=sLFo2JBbxu6Un/GrSVmA3Vqc2iiKx5EZuZ9qcR1Lj3Jzv7edDEJzhQWxB7zLMK7Pw2 aVVVzCh992YnwbkRBBlbTzsxETdVo1ZCAbXkWgaCaD1rPOqjNcFNw7pNBisNO/hOGp9T NPycuqaCAw/GEaplF6kk2KXAaQkB0iVvtD/hD4bIA9lFK/e+w/e9A8gzWaH7jp4vkbqy S7bQlY4f3NEicymKnWM303DPQWGG/CVU4RIYZzaqTwgi4YURlkBNSHs2Ss4KEFIQ8cFl W+5emsqipb9x7VRrfK66n6yAH1nhhIFfMyJdX3nAKA1+HY3DB1rzpDvZeDpmMAW0PYDu QZjA== 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 :in-reply-to:references:mime-version:dkim-signature; bh=iB2HnqDNumDg+ptTbFjRfmTLEGsmOckifYOUnWZ9o7U=; b=cvpmWmF6yNYQSKufsH+BXCHk9A/W2KdYuz33Tv4Dq9wu3SNRnWtRI8II+rWSsqJH5c A+UiOZG+fkJdH7HEsd7tVYJiyf/m2Kac+WgE7eXg68yrGVmhoLYr7jdZLi10KUyudbm6 HMAWhPnewVwD72CMtEapIRUMjaIRJ9n5qppT4i4+g6KscIc6RX1BP0qIKuFm/lVJNyV7 CoIPoAKsH2wl97gKT7iYTubO4b+ctVgmVhNQD5huGVpsIpP0QEI+u7izNJIwi8zv31lt 99LZWaWs8dF9h9Mr93UxjjCAiCpuspiwYJL1jzRz+mtCkEI/6csxHufAEuHFHXtd0wuT +rVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=H0t1S9X9; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v18si546138otn.174.2020.02.12.10.14.42; Wed, 12 Feb 2020 10:14:54 -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=@kernel.org header.s=default header.b=H0t1S9X9; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728840AbgBLSOW (ORCPT + 99 others); Wed, 12 Feb 2020 13:14:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:48724 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727279AbgBLSOW (ORCPT ); Wed, 12 Feb 2020 13:14:22 -0500 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1351E21569; Wed, 12 Feb 2020 18:14:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581531261; bh=XPutHtfrd9L6DCjKR/i4gzTwtBJqO9VVCF2dsQMhOT0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=H0t1S9X9r5QrGUd7DvAOuSUSqqXDsgdC1XTVAcFbzj4EY2h/S8r/mWZNvB10mdCQa 38EaQisKKJidSQ7TOlCXmLvne+3QnPgrSM7v03v8XngdUW7peGivsjAvtTOAtfr4CA wewf/BxAmAKE916HXnBmP76nvVhL3jH9qCPQp3LY= Received: by mail-qv1-f42.google.com with SMTP id l14so1341710qvu.12; Wed, 12 Feb 2020 10:14:21 -0800 (PST) X-Gm-Message-State: APjAAAWvizwDu3Pmzojt+E/r5DutlCrkK5eWqajftF25OTp/uyq+nl5z fHi7yZtE0E6xw7ny0jjl+8lmTeSSFfqJcYtUFQ== X-Received: by 2002:a05:6214:11ac:: with SMTP id u12mr8482894qvv.85.1581531260167; Wed, 12 Feb 2020 10:14:20 -0800 (PST) MIME-Version: 1.0 References: <20200207052627.130118-1-drinkcat@chromium.org> <20200207052627.130118-8-drinkcat@chromium.org> In-Reply-To: From: Rob Herring Date: Wed, 12 Feb 2020 12:14:08 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 7/7] RFC: drm/panfrost: devfreq: Add support for 2 regulators To: Nicolas Boichat Cc: David Airlie , Daniel Vetter , Mark Rutland , Matthias Brugger , Tomeu Vizoso , Steven Price , Alyssa Rosenzweig , Liam Girdwood , Mark Brown , dri-devel , Devicetree List , lkml , linux-arm Mailing List , "moderated list:ARM/Mediatek SoC support" , Hsin-Yi Wang , Ulf Hansson , Viresh Kumar , Stephen Boyd 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 Wed, Feb 12, 2020 at 2:49 AM Nicolas Boichat wrote: > > +Viresh Kumar +Stephen Boyd for clock advice. > > On Fri, Feb 7, 2020 at 1:27 PM Nicolas Boichat wrote: > > > > The Bifrost GPU on MT8183 uses 2 regulators (core and SRAM) for > > devfreq, and provides OPP table with 2 sets of voltages. > > > > TODO: This is incomplete as we'll need add support for setting > > a pair of voltages as well. > > So all we need for this to work (at least apparently, that is, I can > change frequency) is this: > https://lore.kernel.org/patchwork/patch/1192945/ > (ah well, Viresh just replied, so, probably not, I'll check that out > and use the correct API) > > But then there's a slight problem: panfrost_devfreq uses a bunch of > clk_get_rate calls, and the clock PLLs (at least on MTK platform) are > never fully precise, so we get back 299999955 for 300 Mhz and > 799999878 for 800 Mhz. That means that the kernel is unable to keep > devfreq stats as neither of these values are in the table: > [ 4802.470952] devfreq devfreq1: Couldn't update frequency transition > information. > The kbase driver fixes this by remembering the last set frequency, and > reporting that to devfreq. Should we do that as well or is there a > better fix? > > Another thing that I'm not implementing is the dance that Mediatek > does in their kbase driver when changing the clock (described in patch > 2/7): > "" > The binding we use with out-of-tree Mali drivers includes more > clocks, this is used for devfreq: the out-of-tree driver switches > clk_mux to clk_sub_parent (26Mhz), adjusts clk_main_parent, then > switches clk_mux back to clk_main_parent: > (see https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_runtime_pm.c#423) > clocks = > <&topckgen CLK_TOP_MFGPLL_CK>, > <&topckgen CLK_TOP_MUX_MFG>, > <&clk26m>, > <&mfgcfg CLK_MFG_BG3D>; > clock-names = > "clk_main_parent", > "clk_mux", > "clk_sub_parent", > "subsys_mfg_cg"; > "" > Is there a clean/simple way to implement this in the clock > framework/device tree? Or should we implement something in the > panfrost driver? Putting parent clocks into 'clocks' for a device is a pretty common abuse. The 'assigned-clocks' binding is what's used for parent clock setup. Not sure that's going to help here though. Is this dance because the parent clock frequency can't be changed cleanly? If up to me, I'd put that dance in the clock driver. The GPU shouldn't have to care. Rob