Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp2005604ybh; Sun, 8 Mar 2020 19:20:27 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtUWIA6HsfyzWaEaVuvCoMvlVaOex7OEIINWOHBsiS+ftWoYXQiuhKK3ml2X9blTJbh8+tZ X-Received: by 2002:aca:130c:: with SMTP id e12mr9701528oii.122.1583720427755; Sun, 08 Mar 2020 19:20:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583720427; cv=none; d=google.com; s=arc-20160816; b=uTQ9az3MVaKhwQMZdP6Gih2v0yHZhPex1olJBQON1vbdOMIJxdvVLVEixIyMgXBP9z cosmt9T2iVwUmiCtn4wXQYoUeN8sjbEoWS6mTTB/RAlorjys1Lh7/BWGTObyb3/rzGxn PyH9xGW5PcFnbuj2qVUq9uH5ZE03ZpFIq6Xzdhq3qWeWgB73LOmGItSQ9zNIoGkHIcEN LxgchsNxOSpsFZ8mrTjB+X6sqSPTvgKG8hHyXtcae4HN/nOxsjxQpiodqmm9atFXk5Os THN97qnmqLwaN3KaIUY2Y+FUD3m4hKibIF8/0u51lIAJrOX8qHapL7YU5pblZvP5HVUW 6C1Q== 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=QImbxmTkHKil1pvHr+BDxiJL2XLBZLzoyGW6wsTn3oQ=; b=RqZyyRcfcqkZT88WTwgwU/Dd6nMRJjo//McxrwIF4zrYELUnd3ncDOqRqSMRd6ORgH OjerMR4yzsKdad+rmUF9AZuz0vin23WXVUAWo/i5vTl/u/+Pwh11BS3ry//12IMa9rB7 1KZoMdqgP6M+1tMZ7pbSrWjEYGhlPBD8Z3BxwDTmq029nYBhEo9nww5bFU3GURgPF2h+ UjRolMnBOwob5+RvCrN6p8FvAYoozhrPETSQX8WkEoBIO6n8Ax46xFufMxzUs0GeZDkq wHXmiC0XpP93U8/Oi2jh1CFxb00FwnC6zilJbriYqJrirTVqjNyn5rWDrJFHDutPPrpf ZUiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=aWYnmvWG; 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 q9si3601537oif.92.2020.03.08.19.20.16; Sun, 08 Mar 2020 19:20:27 -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; dkim=pass header.i=@chromium.org header.s=google header.b=aWYnmvWG; 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 S1726770AbgCIBxt (ORCPT + 99 others); Sun, 8 Mar 2020 21:53:49 -0400 Received: from mail-vs1-f67.google.com ([209.85.217.67]:40584 "EHLO mail-vs1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726610AbgCIBxs (ORCPT ); Sun, 8 Mar 2020 21:53:48 -0400 Received: by mail-vs1-f67.google.com with SMTP id c18so5047168vsq.7 for ; Sun, 08 Mar 2020 18:53:47 -0700 (PDT) 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=QImbxmTkHKil1pvHr+BDxiJL2XLBZLzoyGW6wsTn3oQ=; b=aWYnmvWGdbntSuhyucIIAMxrZHkM4G5/Q9vbOmCQsekZAYHvr4Eog74dsXDkMYl2xD KvL1zeXKamlcuQTyyvQgkSKnT1gNRPF5uTVUa4a4fHcg/kx4VnHTixsNdroZ764sU1Uy +tKikHrHiZuRBXkYz+/Z8bBjwf8qxvraCz7gQ= 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=QImbxmTkHKil1pvHr+BDxiJL2XLBZLzoyGW6wsTn3oQ=; b=TG11dkfoz2NT6ZPm3UFzVr8NcVo+J9XY4qE1F+VoVaFQumSzRTAtAt9+pingMtV0KN ZRJ9sQLjVmLj7Lbp3TUGS9AWl/5mo2pUWIYGIv4z7Bj2jykUOqS1MQKIUinEYMwqr7+O u/0YmB0gwyesAXQbHL72gaC/z/RC7gZxaJlClbjJbToyP+TSEzq8xmkINFRaXtTAN7YD wk703ytlv5H/eQgM8nPYjLjFdGAO02V4n4PnBsfq2wa1jqu5Tn+/5SfSYxQuRp9EJtQi ap61ZlHgqjTaLuwZzV44e4ZJo7YPT1dTbtqpTr8jnb27ooDPc8kRMPscmJKndJRmEnnM DBmw== X-Gm-Message-State: ANhLgQ3G7aKi/8dgB6zJUSa4+wTtKPI4HZBxjYg93m/tm8G+Si3R2s9m VBQnxk7iiODACyA/k52WhQTLhnxhGYGBAsTHukcteA== X-Received: by 2002:a05:6102:9c7:: with SMTP id g7mr8614280vsi.186.1583718826912; Sun, 08 Mar 2020 18:53:46 -0700 (PDT) MIME-Version: 1.0 References: <20200207052627.130118-1-drinkcat@chromium.org> <20200207052627.130118-8-drinkcat@chromium.org> In-Reply-To: From: Nicolas Boichat Date: Mon, 9 Mar 2020 09:53:35 +0800 Message-ID: Subject: Re: [PATCH v4 7/7] RFC: drm/panfrost: devfreq: Add support for 2 regulators To: =?UTF-8?B?TmljayBGYW4gKOiMg+WTsue2rSk=?= Cc: Rob Herring , =?UTF-8?B?V2VpeWkgTHUgKOWRguWogeWEgCk=?= , 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 , =?UTF-8?B?SkIgVHNhaSAo6JSh5b+X5b2sKQ==?= , =?UTF-8?B?U2ogSHVhbmcgKOm7g+S/oeeSiyk=?= 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 Looping back on this, after digging a bit deeper... On Fri, Feb 14, 2020 at 9:38 AM Nick Fan (=E8=8C=83=E5=93=B2=E7=B6=AD) wrote: > [snip] > > > 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/+/ch > > > romeos-4.19/drivers/gpu/arm/midgard/platform/mediatek/mali_kbase_run > > > time_pm.c#423) > > > clocks =3D > > > <&topckgen CLK_TOP_MFGPLL_CK>, > > > <&topckgen CLK_TOP_MUX_MFG>, > > > <&clk26m>, > > > <&mfgcfg CLK_MFG_BG3D>; > > > clock-names =3D > > > "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? > > Nick/Weiyi, any idea why we do that dance in the first place? (maybe the = PLL clock is unstable while it's being changed?) > > Clock source may become unstable during clock frequency changes, so it is= always safer to switch to a more reliable clock source. > Otherwise, it may cause some problem in some corner case. > I would suggest to keep it. The Mediatek CPUfreq driver actually does a very similar dance: https://github.com/torvalds/linux/blob/master/drivers/cpufreq/mediatek-cpuf= req.c#L249 What they have in the device tree is the main clock, and the "intermediate" clock that is required during switching: clocks =3D <&mcucfg CLK_MCU_MP0_SEL>, <&topckgen CLK_TOP_ARMPLL_DIV_PLL1>; clock-names =3D "cpu", "intermediate"; The topology looks like this: clk26m 15 15 1 26000000 0 0 50000 armpll_ll 1 1 0 1417000000 0 0 50000 mcu_mp0_sel 0 0 0 1417000000 0 0 50000 And device tree provides mcu_mp0_sel as "cpu", and the armpll_div_pll1 as "intermediate". The driver looks up armpll_ll by calling get_parent, then: - set_parent(mcu_mp0_sel, armpll_div_pll1) - set_rate(armpll_ll, new_rate) - set_parent(mcu_mp0_sel, armpll_ll) On MT8183's GPU, the topology is a little bit more complicated (but I think there should be a way to merge mfg_bg3d an mfg_sel in the clock core) clk26m 15 15 1 26000000 0 0 50000 mfgpll 1 1 0 419999817 0 0 50000 mfgpll_ck 2 2 0 419999817 0 0 50000 mfg_sel 3 3 0 419999817 0 0 50000 mfg_bg3d 1 1 0 419999817 0 0 50000 We're going to need a special panfrost devfreq driver for mt8183 anyway (to handle the 2 regulators), so it would be easy to take a similar approach: - Add "intermediate" clock in the device tree (clk26m) - Find mfg_sel/mfgpll_ck using 1/2 clk_get_parent calls. - Switch mfg_sel to clk26m, set mfgpll_ck rate, switch mfg_sel back to mfgpll_ck. (BTW, I tried to look, and couldn't find examples or reparenting during clock changes in drivers/clk, are there existing drivers doing similar things? Or this would be new?).