Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2610195pxu; Mon, 14 Dec 2020 06:49:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJzsDAlSxhij0TZp5/dmgn/NP3uFGtWGeDK0RTV29z/+I089wIJsO8hqOjNsXbjs0ip3kGVD X-Received: by 2002:a17:906:5609:: with SMTP id f9mr10045352ejq.535.1607957368931; Mon, 14 Dec 2020 06:49:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607957368; cv=none; d=google.com; s=arc-20160816; b=L2GHVhgLD3Q3UyNVDQScGzPYebnnmStGBg4lmMFF9oUE7homVwlkjkEa11Ctnl4r6j VZZb3qQ1bBSi6NW+1HsNjYDwAfA3N1Oi8EueghsdljyHwHkhw8Napd8eH6tinOJ/1j2A p2IdyLRk5/hevnDkK95il001uX8PNXk4po2KrJsVcxwz91+lahelqkYj2Yr9vSZgPKyd G2mvZ0xPExxdegLhaV68VbQQ25nYanfL2jy0c5IOjh4RoS4DbBLk/voM0HTTPISMYWbz RNE56xGMTRSum5fMjCleXto43SemDSCbr9qkdUuVYRFUMKDdUKPTkCNCdAr0CzlVtyj1 zG4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=TYOQAGOZqsYRqQKS0Qaz8BDB4+mnGJNdPasbhsUdBs0=; b=ooTgj6L0Emp3MpSoZLO3EiruOBWHzR7JXK96lY22p0wNgPQZSWM/Z78eZD9YUgHcXw f3IT5r9OZ/HVelqKDnG1nM7AnO/Jj7bP4oWW/5r8iEoImPGoWNq924muXXKsaLyuODxX aHGkybkgED2ZWTrTfrCK696uoG/Uj+U+rTmY+MJtcbkhFyZ3y5X41eAGqRYCBQ8h6yq1 HCi66WrGsNihXeli1a9w2aXtAqhFUczZamLo2oaV6Zj1yBRsvyvyNPbNqrG/K/nZwg81 TjALx0q7OY6lXdGKRklIMOSQO8izE/clvXYlnuH+iisN2jN2A8r5QSBQne6vtvoBcqx7 uVWA== 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 g32si11506029ede.551.2020.12.14.06.49.04; Mon, 14 Dec 2020 06:49:28 -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 S2394767AbgLNMjk (ORCPT + 99 others); Mon, 14 Dec 2020 07:39:40 -0500 Received: from foss.arm.com ([217.140.110.172]:46712 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391213AbgLNMjk (ORCPT ); Mon, 14 Dec 2020 07:39:40 -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 9BD1DD6E; Mon, 14 Dec 2020 04:38:54 -0800 (PST) Received: from e108754-lin.cambridge.arm.com (unknown [10.1.198.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 0726B3F66B; Mon, 14 Dec 2020 04:38:52 -0800 (PST) From: Ionela Voinescu To: rjw@rjwysocki.net, viresh.kumar@linaro.org, lenb@kernel.org Cc: yousaf.kaukab@suse.com, jeremy.linton@arm.com, lukasz.luba@arm.com, valentin.schneider@arm.com, linux-acpi@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, ionela.voinescu@arm.com Subject: [PATCH v2 0/4] cppc_cpufreq: fix, clarify and improve support Date: Mon, 14 Dec 2020 12:38:19 +0000 Message-Id: <20201214123823.3949-1-ionela.voinescu@arm.com> X-Mailer: git-send-email 2.29.2.dirty MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi guys, I'm sending v2 of some of the patches at [1] in light of the discussions at [2]. v2: - Patches 1-3 are trivial rebase on linux next 20201211, with conflicts fixed after eliminating what previously was "[PATCH 4/8] cppc_cpufreq: replace per-cpu structures with lists." Therefore, I have kept Viresh's acks. - Patch 4 is a merge between: - [PATCH 4/8] cppc_cpufreq: replace per-cpu structures with lists - [PATCH] cppc_cpufreq: optimise memory allocation for HW and NONE coordination both found at [1]. This functionality was introducing the problem at [2] and it's fixed in this version by bailing out of driver registration if a _CPC entry is not found for a CPU. Yousaf, it would be great if you can test this and make sure it matches your expectations. Rafael, Viresh if you think this last patch introduces too many changes, you can skip it for 5.11 which is around the corner and have more time for review for 5.12. I've added more eyes in the review list. All patches are based on linux next 20201211 after patch at [3] is applied. [1] https://lore.kernel.org/linux-pm/20201105125524.4409-1-ionela.voinescu@arm.com/#t [2] https://lore.kernel.org/linux-pm/20201210142139.20490-1-yousaf.kaukab@suse.com/ [3] https://lore.kernel.org/linux-pm/20201214120740.10948-1-ionela.voinescu@arm.com/ Ionela Voinescu (4): cppc_cpufreq: use policy->cpu as driver of frequency setting cppc_cpufreq: clarify support for coordination types cppc_cpufreq: expose information on frequency domains cppc_cpufreq: replace per-cpu data array with a list .../ABI/testing/sysfs-devices-system-cpu | 3 +- drivers/acpi/cppc_acpi.c | 141 ++++++------ drivers/cpufreq/cppc_cpufreq.c | 204 ++++++++++-------- include/acpi/cppc_acpi.h | 6 +- 4 files changed, 181 insertions(+), 173 deletions(-) -- 2.29.2.dirty