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 75D4CC4167D for ; Thu, 14 Oct 2021 11:44:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 56B7361130 for ; Thu, 14 Oct 2021 11:44:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231186AbhJNLqH (ORCPT ); Thu, 14 Oct 2021 07:46:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58370 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231194AbhJNLqF (ORCPT ); Thu, 14 Oct 2021 07:46:05 -0400 Received: from mail.marcansoft.com (marcansoft.com [IPv6:2a01:298:fe:f::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1AD0C061570; Thu, 14 Oct 2021 04:44:00 -0700 (PDT) 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 1D7CD3FA67; Thu, 14 Oct 2021 11:43:52 +0000 (UTC) To: Ulf Hansson Cc: Viresh Kumar , Sibi Sankar , Saravana Kannan , Linux ARM , 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 , linux-clk , DTML , Linux PM , Linux Kernel Mailing List References: <20211011165707.138157-1-marcan@marcan.st> <20211011165707.138157-5-marcan@marcan.st> <20211012032144.2ltlpat7orrsyr6k@vireshk-i7> <20211012055143.xmkbvhbnolspgjin@vireshk-i7> From: Hector Martin Subject: Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist Message-ID: Date: Thu, 14 Oct 2021 20:43:50 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: es-ES Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/10/2021 18.55, Ulf Hansson wrote: > Yes, this sounds like you should move away from modeling the memory > part as a parent genpd for the CPUs' genpd. > > As Viresh pointed out, a devfreq driver seems like a better way to do > this. As a matter of fact, there are already devfreq drivers that do > this, unless I am mistaken. > > It looks like devfreq providers are listening to opp/cpufreq > notifiers, as to get an indication of when it could make sense to > change a performance state. > > In some cases the devfreq provider is also modeled as an interconnect > provider, allowing consumers to specify memory bandwidth constraints, > which may trigger a new performance state to be set for the memory > controller. > > In the tegra case, the memory controller is modelled as an > interconnect provider and the devfreq node is modelled as an > interconnect-consumer of the memory controller. Perhaps this can work > for apple SoCs too? I was poking around and noticed the OPP core can already integrate with interconnect requirements, so perhaps the memory controller can be an interconnect provider, and the CPU nodes can directly reference it as a consumer? This seems like a more accurate model of what the hardware does, and I think I saw some devices doing this already. (only problem is I have no idea of the actual bandwidth numbers involved here... I'll have to run some benchmarks to make sure this isn't just completely dummy data) > > That said, perhaps as an option to move forward, we can try to get the > cpufreq pieces solved first. Then as a step on top, add the > performance scaling for the memory controller? Sure; that's a pretty much independent part of this patchset, though I'm thinking I might as well try some things out for v2 anyway; if it looks like it'll take longer we can split it out and do just the cpufreq side. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub