From patchwork Tue Apr 23 13:28:18 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Georgi Djakov X-Patchwork-Id: 162694 Delivered-To: patch@linaro.org Received: by 2002:a02:c6d8:0:0:0:0:0 with SMTP id r24csp3790032jan; Tue, 23 Apr 2019 06:28:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqzi3AmZ1xnZMHiAjGK8UBOj3cjBInLAtLmD1pcXUJq3G5Yl0s1223kRf7GDHcdypbWWOOIL X-Received: by 2002:a63:5c56:: with SMTP id n22mr25164981pgm.108.1556026109276; Tue, 23 Apr 2019 06:28:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556026109; cv=none; d=google.com; s=arc-20160816; b=uDNHshIFRBFEubnWKm/d0PibjTrD+KTTODP9Qi6/V/ENRh0MqvmVrQI/j7lJFmom8+ d4zvG3MbIWrodtodcx4Z2AeA9vMPU1vxfyxxsmXIIlYkRH2s1EiXVYzS7B39M+hBj4ME 3S1BDim+Cy58bcwuFTmvflMT6bXo1hCOjCZB/arIXvi+YCOnSQ7PlfUHWK2GKvWYYi/E 4aE09bJlcOTtZ1Z0m5mP5vOfCGrvf72C8l918j/cwzA0YQnhXSS5LzLmKklb4mnPdXgs VfwFU9xneA88HNrDDjyuLj+74v96dyBtUiDrGneIk3teJK5u/Jgy8HA8JTGJu2SXsKAq 6Ouw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=az2eewAoUAngKwYt3jfUJjVHvJWsoW9KqfbViPSA1zI=; b=eUYMPm7OXn3gqg53YXu04cMfwQI0DWEyCMxgnIo9lCJ9ddQUgwKOCHM55JSr3JVNuL TIF4iGa2lwqH5jfJWKLIw9P77uwEt56sx/p29Wp2Tqjx8R45DtPYyDOfzKJCjms84gFg d/lwFZDbdw6jiHk1FCwveWnoZqPYZbwhX6S1qtnTLQVmjwa5yGYHox9clPrsDC42DRDr R2lmzgXSNrxuXo2I7diXRFE52kRp+vdo4srrEmuNBiOPKawpWC3h2k/njDg75fZSmtUW TW+8UnPXzXujkX5A/m9kcarmI2BaCx9IVb5ZEMwFzWuQfEi4LZQfbjvSFoAm+bRxkSUX rofg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=KTlYUPxc; spf=pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=devicetree-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d37si16122866pla.97.2019.04.23.06.28.28; Tue, 23 Apr 2019 06:28:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=KTlYUPxc; spf=pass (google.com: best guess record for domain of devicetree-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=devicetree-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727829AbfDWN22 (ORCPT + 7 others); Tue, 23 Apr 2019 09:28:28 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:46870 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727761AbfDWN22 (ORCPT ); Tue, 23 Apr 2019 09:28:28 -0400 Received: by mail-lj1-f194.google.com with SMTP id h21so13488161ljk.13 for ; Tue, 23 Apr 2019 06:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=az2eewAoUAngKwYt3jfUJjVHvJWsoW9KqfbViPSA1zI=; b=KTlYUPxcIs3ky4JbfVSD7KmOrUfwPu7Z/zzH+LBPE5xcoxjc4UTDtlcJGkUpxxTc94 7J4duCMd4H1oL4V/yEidAePnFeX6P8plqYrhoKnwNABDfBBoIrKw01RHcapFmNmRplIX 2vOJEHJCDuhuTIw+7uNgBmImpPAnWc51EGCx1nVW5/3y252uDNmr9vpFPqSd22va2LKX Xwv//ZWgyDBXYznEsSv/xUyDweXdfE814lxNhO5sXs67kLBmmu8QaxcAjESil7GzZP/3 uQSEiftQnCWcWgkqVfRB//NHlVlk6RpyMGor/Grl6X5KvyD7VtZlj1FXEihhYHDyqaBy 8uGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=az2eewAoUAngKwYt3jfUJjVHvJWsoW9KqfbViPSA1zI=; b=hEvh9WA7yY8RH1sGOL03SI4RA5LmK2lf/G4d5qOtEe/ZSaaW5E+M6dKquG61NFE9RF 0mlhI9TMSCpPFOWaQxGAmTBSA6jwoain+MxfdnLItavQgWXHuhMXGeK3jcxlgzvtfXEo uPJhuy+yDeO4zbpxmOcQR3U91ZO7euO9xlHykFqM3ptZB9AUejscQIgfYe6CxTHZa4o4 Mjaxf07cdwfAAFU86AubHQ99yOv0YiematDi4riO0WiIe+3Z59/4e3KLpEeZ4fPvaDzI ojHAtQeBfO7j+8kJ+V21wvraajN9A2B2wtPqoE8ssrthxLmHKU0hxlsd3uPfpozJVZ5d ooBg== X-Gm-Message-State: APjAAAWAjOratOoU8zrZi7eLqiuGzDlZ0qQ8Bg67GvMyHAGs6TZBJvjv xBAWdWusPmclCrBhZtUUPPTB/A== X-Received: by 2002:a2e:a0c9:: with SMTP id f9mr3304999ljm.62.1556026106182; Tue, 23 Apr 2019 06:28:26 -0700 (PDT) Received: from localhost.localdomain ([212.45.67.2]) by smtp.googlemail.com with ESMTPSA id y206sm4617107lfc.72.2019.04.23.06.28.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Apr 2019 06:28:25 -0700 (PDT) From: Georgi Djakov To: vireshk@kernel.org, sboyd@kernel.org, nm@ti.com, robh+dt@kernel.org, mark.rutland@arm.com, rjw@rjwysocki.net Cc: jcrouse@codeaurora.org, vincent.guittot@linaro.org, bjorn.andersson@linaro.org, amit.kucheria@linaro.org, seansw@qti.qualcomm.com, daidavid1@codeaurora.org, evgreen@chromium.org, sibis@codeaurora.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, georgi.djakov@linaro.org Subject: [PATCH v2 0/5] Introduce OPP bandwidth bindings Date: Tue, 23 Apr 2019 16:28:18 +0300 Message-Id: <20190423132823.7915-1-georgi.djakov@linaro.org> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Here is a proposal to extend the OPP bindings with bandwidth based on a previous discussion [1]. Every functional block on a SoC can contribute to the system power efficiency by expressing its own bandwidth needs (to memory or other SoC modules). This will allow the system to save power when high throughput is not required (and also provide maximum throughput when needed). There are at least three ways for a device to determine its bandwidth needs: 1. The device can dynamically calculate the needed bandwidth based on some known variable. For example: UART (baud rate), I2C (fast mode, high-speed mode, etc), USB (specification version, data transfer type), SDHC (SD standard, clock rate, bus-width), Video Encoder/Decoder (video format, resolution, frame-rate) 2. There is a hardware specific value. For example: hardware specific constant value (e.g. for PRNG) or use-case specific value that is hard-coded. 3. Predefined SoC/board specific bandwidth values. For example: CPU or GPU bandwidth is related to the current core frequency and both bandwidth and frequency are scaled together. This patchset is trying to address point 3 above by extending the OPP bindings to support predefined SoC/board bandwidth values and adds support in cpufreq-dt to scale the interconnect between the CPU and the DDR together with frequency and voltage. [1] https://patchwork.kernel.org/patch/10577315/ Changes in v2: * Added support for configuring multiple interconnect paths per each device and changed the way we describe it in DT. (Viresh) * Rename the DT property opp-bw-MBps to bandwidth-MBps. (Viresh) * Document MBps in property-units.txt. (Rob) * New patch to add of_icc_get_by_index() helper function. * Add _of_find_paths() to populate OPP tables with interconnect path data from DT. (Viresh) v1: https://lore.kernel.org/lkml/20190313090010.20534-1-georgi.djakov@linaro.org/ Georgi Djakov (5): dt-bindings: opp: Introduce bandwidth-MBps bindings interconnect: Add of_icc_get_by_index() helper function OPP: Add support for parsing the interconnect bandwidth OPP: Update the bandwidth on OPP frequency changes cpufreq: dt: Add support for interconnect bandwidth scaling Documentation/devicetree/bindings/opp/opp.txt | 38 +++++++ .../devicetree/bindings/property-units.txt | 4 + drivers/cpufreq/cpufreq-dt.c | 27 ++++- drivers/interconnect/core.c | 45 ++++++-- drivers/opp/core.c | 96 ++++++++++++++++- drivers/opp/of.c | 102 ++++++++++++++++++ drivers/opp/opp.h | 9 ++ include/linux/interconnect.h | 6 ++ include/linux/pm_opp.h | 14 +++ 9 files changed, 327 insertions(+), 14 deletions(-)