Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp461606pxb; Thu, 5 Nov 2020 04:58:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJzkMu8HqrxvOwNWFjWJsjJiewlpEE0EvNPp8YhkqEuqYrynS4t8fNW8qxhO+jL6R3a+7hhU X-Received: by 2002:a17:906:4dd4:: with SMTP id f20mr2154263ejw.94.1604581103581; Thu, 05 Nov 2020 04:58:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604581103; cv=none; d=google.com; s=arc-20160816; b=SGuBXAOu0Q35lGHqAApmz2PHVtUINxAprCSz1QkHE2kMDJ/T8SGfO78HaTbka1k+f1 P6+ktuHzVX4iV6uRA68nA0AEXv35tS6oCcW6gvk1lfANLl5wb8ao1LbIzk03B2IMjvnR Pf2Arxgas2kWTzNWfG1zCz+jX8kVa4cYjl+qhqon5WI2dM9m3grGDch/4NHN6qLDhF0h MhRzFvqYcNPyGxyKTPI+1jfzYF1J9cerMymifws/04F8FlsdXERrBgxq8Bdm1KzqZjNv x4bcJ7r7gS4jqC6Cz8kfxmYLBQVIchhdZusdUwf4s81T5DpYmVcWBq9gLKRF/csnkPX+ 2hDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from; bh=XDmkqBJJpD9qbZcUcnBMKLzlwB9Cx7iU7PbgZhZRnvE=; b=A0rxHmlYLSwtSts+eMZHT3BGHkCxMfrMEapif+zZDPY3fre7ylqxGHzlTxZ/ObEpiD AK2iPhTOB1rgOmZ1Ji8X9iTSnCgCVNh6B5yyhGjQpBNl1yO6cm1y+4zMisTbLPzXV4Y1 ojZGRnq+b22u5HXMBRV/Su3QE9htpG82AZMb/HPBIOM7QK5YgvNnotNyWw3RvTCdIIh5 VkdNiLl2dGp3zg+lBTN6criQo9TYct6E9qVr8hNwCNFiWVxkUhvNyk1Gm6S+DtSNorIH WU71uAutrARMl9f0XsNWlTgTn354UJ1YSm2qSnfdj4xBuFx7rcToNL3c6m56rFUFEbjv laLQ== 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=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cd26si1023261ejb.746.2020.11.05.04.58.01; Thu, 05 Nov 2020 04:58:23 -0800 (PST) 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=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730552AbgKEM4g (ORCPT + 99 others); Thu, 5 Nov 2020 07:56:36 -0500 Received: from foss.arm.com ([217.140.110.172]:59964 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726777AbgKEM4f (ORCPT ); Thu, 5 Nov 2020 07:56:35 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1E1B6142F; Thu, 5 Nov 2020 04:56:35 -0800 (PST) Received: from e108754-lin.cambridge.arm.com (e108754-lin.cambridge.arm.com [10.1.198.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id DD2823F719; Thu, 5 Nov 2020 04:56:33 -0800 (PST) From: Ionela Voinescu To: rjw@rjwysocki.net, viresh.kumar@linaro.org, lenb@kernel.org, sudeep.holla@arm.com Cc: morten.rasmussen@arm.com, jeremy.linton@arm.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, ionela.voinescu@arm.com Subject: [PATCH 0/8] cppc_cpufreq: fix, clarify and improve support Date: Thu, 5 Nov 2020 12:55:16 +0000 Message-Id: <20201105125524.4409-1-ionela.voinescu@arm.com> X-Mailer: git-send-email 2.17.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi guys, I found myself staring a bit too much at this driver in the past weeks and that's likely the cause for me coming up with this series of 8 patches that cleans up, clarifies and reworks parts of it, as follows: - patches 1-3/8: trivial clean-up and renaming with the purpose to improve readability - patch 4/8: replace previous per-cpu data structures with lists of domains and CPUs to get more efficient storage for driver data and fix previous issues in case of CPU hotplugging, as discussed at [1]. - patches 5-6/8: a few fixes and clarifications: mostly making sure the behavior described in the comments and debug messages matches the code and there is clear indication of what is supported and how. - patch 7/8: use the existing freqdomains_cpus attribute to inform the user on frequency domains. - patch 8/8: acpi: replace ALL coordination with NONE coordination when errors are find parsing the _PSD domains (as described in the comments in the code). Hopefully you'll find this useful for ease of maintenance and ease of future development of the driver. This functionality was tested on a Juno platform with modified _PSD tables to test the functionality for all currently supported coordination types: ANY, HW, NONE. The current code is based on v5.10-rc2. Thanks, Ionela. [1] https://lore.kernel.org/linux-pm/20200922162540.GB796@arm.com/ Ionela Voinescu (8): cppc_cpufreq: fix misspelling, code style and readability issues cppc_cpufreq: clean up cpu, cpu_num and cpunum variable use cppc_cpufreq: simplify use of performance capabilities cppc_cpufreq: replace per-cpu structures with lists cppc_cpufreq: use policy->cpu as driver of frequency setting cppc_cpufreq: clarify support for coordination types cppc_cpufreq: expose information on frequency domains acpi: fix NONE coordination for domain mapping failure .../ABI/testing/sysfs-devices-system-cpu | 3 +- drivers/acpi/cppc_acpi.c | 126 +++--- drivers/acpi/processor_perflib.c | 2 +- drivers/cpufreq/cppc_cpufreq.c | 358 +++++++++++------- include/acpi/cppc_acpi.h | 14 +- 5 files changed, 277 insertions(+), 226 deletions(-) -- 2.17.1