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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81FCCC2D0A3 for ; Fri, 6 Nov 2020 10:56:31 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 08B9720665 for ; Fri, 6 Nov 2020 10:56:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="XHXpUUid"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="XE3WmDim" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 08B9720665 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=AUUR3HU3ZdDk0kClnGChmpHub1QPezLuF8DKKbWLOIA=; b=XHXpUUidTtiQx8DhnNP0c/VcE eNH/2MSTZ61tlpN5i/ZGccEyHFuajl0rkum0BJ6QS/7ZwoGD2XRtX8P9X4oYQZICsbGiw/f9KwvG7 /I/HSHelHsX/lrwrRyRlFb4W6RMw0IqanIIhDcXwXvLURedrS6XaRAS20EvQVlYgMjt4snlRpHLiU PzdKZ6othFMbEVvs2OZ7Sq3DB0moIFvSZqYY0x2gnLv9DLBQKpjFQmH1yNUj0SBZ4kybK8zvPR5TI wq3P32VmEI4Vxptau7a/QLpwPkOJ2Nnv5Ol45erl7orGK8MarwbdMfpS6Bgk9gYz2xfRXtYXiRD3o gcGn1khyQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kazOt-0006uT-Pg; Fri, 06 Nov 2020 10:55:23 +0000 Received: from mail-pl1-x641.google.com ([2607:f8b0:4864:20::641]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kazOq-0006t4-Cs for linux-arm-kernel@lists.infradead.org; Fri, 06 Nov 2020 10:55:21 +0000 Received: by mail-pl1-x641.google.com with SMTP id 1so500749ple.2 for ; Fri, 06 Nov 2020 02:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=b/EXZYeChCIs1m40/OogMCYwnFfXBPrTLz46deLiJcA=; b=XE3WmDim8YAmqM4wMueP497yfYpq4mZKBuDgqPG/tLQgt6JSE0/4rnF/ynwrUFUtoD PQ5xhlF+SNe+ddNm3uq1E+sW+nc5eCrwv24/wQzXUILasKZByU53yrycLJmEBB9oErna IYdADsb7pse/R6UfvZYps8Y7FrZP9cIMsDW9gF4LvQH0kmFTCXYT0ESV4wOshPeby7tV R23mChkPhLJr78HSEuhX9xsyg0sxLwNhU4i7N1Ru1R4slkqFpd+Rz4K/Z7wssYvRnHbp U7T6XYHccwRJkqgoN0hfDBue85ZLX2awle9liKb/q4YQ+f7QZcdeIA4Vp5wWI2RDbduO cOmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=b/EXZYeChCIs1m40/OogMCYwnFfXBPrTLz46deLiJcA=; b=nvwnAVtoYc71ucgUIQp2GRMBKLkFHydYC2/Tqsy4LTP2lwTXn06CPgPl8aR2zq65kB jPLro+fJmAo0HWdVcqBqodjyYnTKyaM1sSpw8cf3usgtNZwAFfLGwvq9Zk14kWsxaWpC vHtrJn46xtS+PjDKjA0c4FHMznD+BN7WJR7yuTFLCPEMjq5lSMwsqd0OxW5wlmzxqwS5 SNaT5LYO5PFoCzFbtnoLXvdjXSWoHBdE+WcLEqS719OQyj7Wq01QX3MwWkucVAkKxT2X VyitRYlhPQYeuWycS+/OMM610vSdljZ4BOMUUVKn8upVq1bmsLhwSmw6mDDPD55sa8V3 R1Eg== X-Gm-Message-State: AOAM5339dslrir4R5N4TBTNVeiJwTANJRGTapMWgwaId+pGNQCCucK7v GEqYcfbNn/Az2VMaLccubiI68A== X-Google-Smtp-Source: ABdhPJwLCX4MA/OOHdhLU3UIDCLaYzo+IJOWbKzfu+djgm7NfBe6J0VuY+WxKlwV8jfW74rAFh9prA== X-Received: by 2002:a17:902:7c12:b029:d6:ed57:fe13 with SMTP id x18-20020a1709027c12b02900d6ed57fe13mr1373599pll.59.1604660117422; Fri, 06 Nov 2020 02:55:17 -0800 (PST) Received: from localhost ([122.172.12.172]) by smtp.gmail.com with ESMTPSA id y124sm1641133pfy.28.2020.11.06.02.55.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Nov 2020 02:55:16 -0800 (PST) Date: Fri, 6 Nov 2020 16:25:14 +0530 From: Viresh Kumar To: Lukasz Luba Subject: Re: [PATCH v3 3/3] [RFC] CPUFreq: Add support for cpu-perf-dependencies Message-ID: <20201106105514.bhtdklyhn7goml64@vireshk-i7> References: <20201102120115.29993-1-nicola.mazzucato@arm.com> <20201102120115.29993-4-nicola.mazzucato@arm.com> <20201106092020.za3oxg7gutzc3y2b@vireshk-i7> <0a334a73-45ef-58ff-7dfd-9df6f4ff290a@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0a334a73-45ef-58ff-7dfd-9df6f4ff290a@arm.com> User-Agent: NeoMutt/20180716-391-311a52 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201106_055520_477536_732738F3 X-CRM114-Status: GOOD ( 17.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: nm@ti.com, devicetree@vger.kernel.org, linux-pm@vger.kernel.org, sboyd@kernel.org, vireshk@kernel.org, daniel.lezcano@linaro.org, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, robh+dt@kernel.org, Nicola Mazzucato , sudeep.holla@arm.com, chris.redpath@arm.com, morten.rasmussen@arm.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 06-11-20, 10:37, Lukasz Luba wrote: > Good question. > > How about a different interface for those cpufreq drivers? > That new registration API would allow to specify the cpumask. > Or rely on EM cpumask: em_span_cpus(em) > > Currently we have two ways to register cooling device: > 1. when the cpufreq driver set a flag CPUFREQ_IS_COOLING_DEV, the core > will register cooling device > 2. cpufreq driver can explicitly call the registration function: > cpufreq_cooling_register() with 'policy' as argument > > That would need substantial change to the cpufreq cooling code, from > policy oriented to custom driver's cpumask (like EM registration). I am even wondering if we should really make that change. Why do we need the combined load of the CPUs to be sent back to the IPA governor ? Why shouldn't they all do that (they == cdev) ? This is a bit confusing to me, sorry about that. The cpufreq governors take a look at all the CPUs utilization and set the frequency based on the highest utilization (and not the total util). While in this case we present the total load of the CPUs to the IPA (based on the current frequency of the CPUs), in response to which it tells us the frequency at which all the CPUs of the policy can run at (I am not even sure if it is the right thing to do as the CPUs have different loads). And how do we fit this dependent_cpus thing into this. Sorry, I am not sure what's the right way of doing thing here. -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel