From patchwork Fri May 18 08:24:46 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Saravana Kannan X-Patchwork-Id: 916114 Return-Path: X-Original-To: incoming-dt@patchwork.ozlabs.org Delivered-To: patchwork-incoming-dt@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=devicetree-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=codeaurora.org header.i=@codeaurora.org header.b="jTxVzvcb"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=codeaurora.org header.i=@codeaurora.org header.b="OAyfDFHe"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 40nLpp02snz9s1b for ; Fri, 18 May 2018 18:25:54 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753758AbeERIZB (ORCPT ); Fri, 18 May 2018 04:25:01 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:57142 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751744AbeERIY4 (ORCPT ); Fri, 18 May 2018 04:24:56 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id B7BCA60F5F; Fri, 18 May 2018 08:24:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526631895; bh=QaBVN/FkgWs5jHkPUeVWqR0ERvax2emUrqkrlRSO62o=; h=From:To:Cc:Subject:Date:From; b=jTxVzvcbQKsNdFtHaQJ4Jtv3Ho6YossVyDGHzyVMZX5LzeunboY1SCzNswSPs/3qb nogysi8I+j1QsmiTDN4rqcjexpY4MioQdm8Kw3T8z5F5k/F7AJpA68TrHrY9dkubv4 ibNNxdWRDBVBlZCVtHr6c38/IRxH/mLyMZC7ozdE= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED, T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from skannan1-linux.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: skannan@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 3531C60D81; Fri, 18 May 2018 08:24:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1526631894; bh=QaBVN/FkgWs5jHkPUeVWqR0ERvax2emUrqkrlRSO62o=; h=From:To:Cc:Subject:Date:From; b=OAyfDFHetZFwr/546ES+zjomoqA++EeGjsBv2JEdHRFHzevRu7usgbB1+Y+myBcIG sIk7RL3I6cEy8iHpxBw93uYjjUtho1KFVunOlK2fGViUGaujsOgGHLWBUaRnIdvI6P qDYijmmMuiPwxfbfApNY1Ermw+FrBoNeNw+Zz6kI= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 3531C60D81 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=skannan@codeaurora.org From: Saravana Kannan To: "Rafael J. Wysocki" , Viresh Kumar , MyungJoo Ham , Kyungmin Park , Chanwoo Choi , Rob Herring , Mark Rutland Cc: Saravana Kannan , Rajendra Nayak , Amit Kucheria , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: [PATCH 0/2] Adding support for scaling cache/memory based on CPU frequency Date: Fri, 18 May 2018 01:24:46 -0700 Message-Id: <1526631889-5084-1-git-send-email-skannan@codeaurora.org> X-Mailer: git-send-email 1.8.2.1 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor performance and power. The same idea applies for RAM/DDR. To achieve this, this patch series adds a generic devfreq governor that can listen to the frequency transitions of each CPU frequency domain and then adjusts the frequency of the cache (or any devfreq device) based on the frequency of the CPUs. To decide the frequency of the device, the governor does one of the following: * Uses a CPU frequency to device frequency mapping table - Either one mapping table used for all CPU freq policies (typically used for system with homogeneous cores/clusters that have the same OPPs. - One mapping table per CPU freq policy (typically used for ASMP systems with heterogeneous CPUs with different OPPs) OR * Scales the device frequency in proportion to the CPU frequency. So, if the CPUs are running at their max frequency, the device runs at its max frequency. If the CPUs are running at their min frequency, the device runs at its min frequency. And interpolated for frequencies in between. Since CPUs/clusters can be hotplugged and their policies disables, this devfreq governor also has to listen to CPU freq policy notifiers for these events. So, this patch brings back the policy CREATE/REMOVE notifiers. Saravana Kannan (2): Revert "cpufreq: Remove policy create/remove notifiers" PM / devfreq: Generic cpufreq governor .../bindings/devfreq/devfreq-cpufreq.txt | 53 ++ drivers/cpufreq/cpufreq.c | 16 +- drivers/devfreq/Kconfig | 8 + drivers/devfreq/Makefile | 1 + drivers/devfreq/governor_cpufreq.c | 628 +++++++++++++++++++++ include/linux/cpufreq.h | 3 + 6 files changed, 704 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/devfreq/devfreq-cpufreq.txt create mode 100644 drivers/devfreq/governor_cpufreq.c