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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A589FC433F5 for ; Tue, 12 Oct 2021 09:31:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 840DB610D1 for ; Tue, 12 Oct 2021 09:31:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235581AbhJLJdb convert rfc822-to-8bit (ORCPT ); Tue, 12 Oct 2021 05:33:31 -0400 Received: from marcansoft.com ([212.63.210.85]:49154 "EHLO mail.marcansoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232657AbhJLJda (ORCPT ); Tue, 12 Oct 2021 05:33:30 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 429AA425CB; Tue, 12 Oct 2021 09:31:25 +0000 (UTC) Date: Tue, 12 Oct 2021 18:31:18 +0900 From: "Hector Martin \"marcan\"" To: Viresh Kumar CC: Sibi Sankar , Saravana Kannan , linux-arm-kernel@lists.infradead.org, Alyssa Rosenzweig , Sven Peter , Marc Zyngier , Mark Kettenis , Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , Viresh Kumar , Nishanth Menon , Catalin Marinas , "Rafael J. Wysocki" , Kevin Hilman , Ulf Hansson , linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: =?US-ASCII?Q?Re=3A_=5BRFC_PATCH_4/9=5D_opp=3A_core=3A_Don=27t_wa?= =?US-ASCII?Q?rn_if_required_OPP_device_does_not_exist?= User-Agent: K-9 Mail for Android In-Reply-To: <20211012092603.lkmhhjoo5v67wh44@vireshk-i7> References: <20211011165707.138157-1-marcan@marcan.st> <20211011165707.138157-5-marcan@marcan.st> <20211012032144.2ltlpat7orrsyr6k@vireshk-i7> <20211012055143.xmkbvhbnolspgjin@vireshk-i7> <20211012092603.lkmhhjoo5v67wh44@vireshk-i7> Message-ID: <049FC437-EC38-4FE5-891E-5E25960892CF@marcan.st> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org On 2021年10月12日 18:26:03 JST, Viresh Kumar wrote: >On 12-10-21, 14:57, Hector Martin wrote: >> >> This is arguably not entirely representative of how the hardware works, >> since technically the cluster switching couldn't care less what the memory >> controller is doing; it's a soft dependency, states that should be switched >> together but are not interdependent (in fact, the clock code does this >> unconditionally after the CPU p-state change, regardless of whether we're >> shifting up or down; this is, FWIW, the same order macOS uses, and it >> clearly doesn't matter which way you do it). > >Yeah, I understand what you are doing. But the current patch is >incorrect in the sense that it can cause a bug on other platforms. To >make this work, you should rather set this genpd as parent of CPU >devices (which are doing anyway since you are updating them with CPU's >DVFS). With that the clk driver won't be required to do the magic >behind the scene. > That doesn't work, though, because the CPUs aren't normal devices with runtime-pm. That was the first thing I tried :). If you think this *should* be made to work instead then I can try that. -- Hector Martin "marcan" (marcan@marcan.st) Public key: https://mrcn.st/pub