Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2127350pxb; Mon, 11 Oct 2021 23:00:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxzNlsXngAzzlZBNleCFuwDF3JOJ+j81HdAhE7iQfJC1QKOE/5L6STjp/7lf7NbjOQ8zIsw X-Received: by 2002:a63:db41:: with SMTP id x1mr21294462pgi.474.1634018452511; Mon, 11 Oct 2021 23:00:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634018452; cv=none; d=google.com; s=arc-20160816; b=YIbfJm7CSsqDS8NlslpFk41jaPuhp9o0N4Ve68DKGVCAkYYVPkPTzjvm8bKHuKdWwK h+hwmEPSkwYnvsU49Fnxx+sMzDnUj9LtupTEBXfByHqnDZqqvACt55F5WfkfFx2hJQVR oFOo4pY12WpwQiECD21C/44CEa8w3iLMqs99Rk1xs1VmG1Xf6POyFy7XVR31DR8AdVW5 RuqPeu7zbjw2y3SEPKBgKha4o2x89QKWlW9vuIzGfwrtthMxTnpC5ZVDHC3NhyifHpko OXcnFfPMUXuun6cTLPDZg8TOZ7knAnqefx+zluh4h8leO4z8FlDlS4Mut4f9NIk5nvGo /ZVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=TrKyv0LfxcLOGiIhLhdQUzRgMUXknoe8H6gm4iNeajE=; b=ovdSFzUh/AGotxUNQNRknpAbTl0u6S55E+2MF5maKOpAqQ+tm0jP2ac9mJX27WgutR H3A3uNwk3IY8p/ywzloSsfjIAZa806BD77qzTskGKYJJQaUuEPUrgJ1SKi687ko+XQD3 FoT4uaoXb9/IzR5RBZrm3e3sfCOEaQ5kkk7Jq+tUhIgeMSY2ETCvEQ9Kgxj4aLo76qF/ TybI1PhWC+MQWWfZWhWAyZXIaKKoWqWuFmQ3mKf2SYJa17VJS2K6IJp92BnPtYyDfKKW qt741QPZ5l1NDa2MfExdyjyTjgYvCL8qR0BGliLCX3SvJby+zTrtoYO+UT5kSuObWOLr yEXg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u14si15469351pgk.369.2021.10.11.23.00.39; Mon, 11 Oct 2021 23:00:52 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=marcan.st Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232716AbhJLGAD (ORCPT + 99 others); Tue, 12 Oct 2021 02:00:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232254AbhJLGAC (ORCPT ); Tue, 12 Oct 2021 02:00:02 -0400 Received: from mail.marcansoft.com (marcansoft.com [IPv6:2a01:298:fe:f::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DEF06C061570; Mon, 11 Oct 2021 22:58: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)) (No client certificate requested) (Authenticated sender: marcan@marcan.st) by mail.marcansoft.com (Postfix) with ESMTPSA id 17A1E4206F; Tue, 12 Oct 2021 05:57:52 +0000 (UTC) Subject: Re: [RFC PATCH 4/9] opp: core: Don't warn if required OPP device does not exist To: Viresh Kumar , Sibi Sankar , Saravana Kannan Cc: 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 References: <20211011165707.138157-1-marcan@marcan.st> <20211011165707.138157-5-marcan@marcan.st> <20211012032144.2ltlpat7orrsyr6k@vireshk-i7> <20211012055143.xmkbvhbnolspgjin@vireshk-i7> From: Hector Martin Message-ID: Date: Tue, 12 Oct 2021 14:57: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: <20211012055143.xmkbvhbnolspgjin@vireshk-i7> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: es-ES Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/10/2021 14.51, Viresh Kumar wrote: > On 12-10-21, 14:34, Hector Martin wrote: >> The table *is* assigned to a genpd (the memory controller), it's just that >> that genpd isn't actually a parent of the CPU device. Without the patch you >> end up with: >> >> [ 3.040060] cpu cpu4: Failed to set performance rate of cpu4: 0 (-19) >> [ 3.042881] cpu cpu4: Failed to set required opps: -19 >> [ 3.045508] cpufreq: __target_index: Failed to change cpu frequency: -19 > > Hmm, Saravana and Sibi were working on a similar problem earlier and decided to > solve this using devfreq instead. Don't remember the exact series which got > merged for this, Sibi ? > > If this part fails, how do you actually set the performance state of the memory > controller's genpd ? The clock controller has the genpd as an actual power-domain parent, so it does it instead. From patch #7: > + if (cluster->has_pd) > + dev_pm_genpd_set_performance_state(cluster->dev, > + dev_pm_opp_get_required_pstate(opp, 0)); > + 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). -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub