Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp242039yba; Tue, 23 Apr 2019 23:51:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqxbtS+IdwEUJ7Ah1P3jkLREfcM40vBmwkG0NHETKwifzA2bHHBIUcl/RA2jTkvWt4bqar3O X-Received: by 2002:a17:902:7d8f:: with SMTP id a15mr30303040plm.3.1556088691414; Tue, 23 Apr 2019 23:51:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556088691; cv=none; d=google.com; s=arc-20160816; b=EQhBSGDvCzopgcPFMrMZ9fNp35kKgCfOjSEcjM4gL4jC7aomlR04hHI2J9V4ScUMQN aqSYibjdth4/8OFcd9RGXo/GfSQdcKF8vXTRoa91YAAETzomneLqv2+bZiVc+XG10Qg2 +7X9Q+8zBcQO+9JdtWHKPJCJ8ZBnFIZV+lm8PV8P28CD0UG9y8spLCEhA0YQnlL/yd6C 7biyVciVsnvhbXudN26+mis6aVWJOHak5zgas7m3/HNvewe6zstVVP7daBAaz//gYjOQ tj1x8FQeq6u1HchkDtw5kq4aLPAFNhBnktyA9PT4YkYMkpMfXp4AzLDgINstGfAqS7QC GIcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=GPwJ+Dv6Yye/GYCQu2DK/IFt2gkz+D0Qa9x7sKSg3nI=; b=UXcpOOFSfJ+8OZ33y0/16LKSjZsYhqfjaPIirKIcTOKnIwvk/S8D5BagsIwBpJ9KO/ lMBhe5ivJHzLurGO2EC0wakSYZHsuq1TzwCv6gYv1sydyRtQf59xH/P9MoudpODsavGF VGvUAOFmKG/8nPeH7SKYi4TPBcU5aG0+T2TmhbHjE2hGRg4rrSc6jI9UXk7q/1Pxpfw9 lgGETn7lfwWVLhS+ZN1oMqfjSJQYIuZofiWhQIw3EWOJFCsOMGXw8e1YARCqbJ4pvecP iKFtYm+0zK/FHVa5ROUaSBROsy1suSVLvEOGJSFPSDGHWN1Mk66Dow6pfv2PXY+8CnXs FsiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=dJ948rqB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 m4si17858975plt.26.2019.04.23.23.51.16; Tue, 23 Apr 2019 23:51:31 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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=dJ948rqB; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 S1730048AbfDXGts (ORCPT + 99 others); Wed, 24 Apr 2019 02:49:48 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:36135 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730041AbfDXGtq (ORCPT ); Wed, 24 Apr 2019 02:49:46 -0400 Received: by mail-pg1-f195.google.com with SMTP id 85so8898654pgc.3 for ; Tue, 23 Apr 2019 23:49:45 -0700 (PDT) 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=GPwJ+Dv6Yye/GYCQu2DK/IFt2gkz+D0Qa9x7sKSg3nI=; b=dJ948rqBPaZUvCFKrcFhohdvlVX+94B52yZpDc1e32ZAQF/qVhzuZZ4jPUd8xVAgai 8tuQb8/MbuZzo+qVuDRVQBNbmriA7n+3nYm42BEyxr+JhfubavBmV5YVS1w6zOd29Do/ B2e3QKb1dRAEUfk6fq0lkaY37McCPfFS9K7WivszZl37/A1ZPl3NbbONHppdWXIevzfQ o0a72GLVsFV3QycR8O338TBhGnEauxITlydfPW9unppA6Mhn/e057kyBQZyrnXMypzcx ipknOmaPzQJUzz1a6jzbkNsSgumZwYIY5im6HLJGwQDNilkSSaOwvvSaPCgaZKA5Ov4u Dmhw== 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=GPwJ+Dv6Yye/GYCQu2DK/IFt2gkz+D0Qa9x7sKSg3nI=; b=qkLB4rAf2A+Cimo1s2Q26ka/fBAkwU6rkzmjK7wu6//DOwrAx9FdyPhJkIzNuSUnlK aHIIon/4P3SdiIixyGDPXYGFkX7DNs41QpZeCI3VeiPVWxupVYC/netiVdAU3QYTXTz8 zCcDkW5joHqlYDfszgw3pxIkjYlwNILVsULbLF2ZB2ETTcW1MqKTTSBeJHm080etsDQL ijHVssCQuXiVsMqEqbqH7A7PdJ9vvgFsQmn7y3aEeffN+WFK/DubE2gGYGvEg2n9JQGK uCgG2COz/9hpNP4O1K5kMHwLwO3hdd9P1Ec6+kBQl41K0c4plls0LDegb6Ju60KFTcXO DNUg== X-Gm-Message-State: APjAAAUGfNlaZDwhFAUIbY5W+Yp9MSjpQlt5dlKw432a7uS2iMzvtLzI hcIZPNBYgoCLktZ3sp/OWScGtg== X-Received: by 2002:a62:4554:: with SMTP id s81mr32218642pfa.66.1556088585455; Tue, 23 Apr 2019 23:49:45 -0700 (PDT) Received: from localhost ([122.166.139.136]) by smtp.gmail.com with ESMTPSA id b13sm24443639pfd.12.2019.04.23.23.49.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 23:49:44 -0700 (PDT) Date: Wed, 24 Apr 2019 12:19:42 +0530 From: Viresh Kumar To: Rajendra Nayak Cc: Georgi Djakov , vireshk@kernel.org, sboyd@kernel.org, nm@ti.com, robh+dt@kernel.org, mark.rutland@arm.com, rjw@rjwysocki.net, 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 Subject: Re: [PATCH v2 1/5] dt-bindings: opp: Introduce bandwidth-MBps bindings Message-ID: <20190424064942.v5g6jr5l3xy5z3xv@vireshk-i7> References: <20190423132823.7915-1-georgi.djakov@linaro.org> <20190423132823.7915-2-georgi.djakov@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180323-120-3dd1ac Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24-04-19, 12:16, Rajendra Nayak wrote: > > > On 4/23/2019 6:58 PM, Georgi Djakov wrote: > > In addition to frequency and voltage, some devices may have bandwidth > > requirements for their interconnect throughput - for example a CPU > > or GPU may also need to increase or decrease their bandwidth to DDR > > memory based on the current operating performance point. > > > > Extend the OPP tables with additional property to describe the bandwidth > > needs of a device. The average and peak bandwidth values depend on the > > hardware and its properties. > > > > Signed-off-by: Georgi Djakov > > --- > > Documentation/devicetree/bindings/opp/opp.txt | 38 +++++++++++++++++++ > > .../devicetree/bindings/property-units.txt | 4 ++ > > 2 files changed, 42 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt > > index 76b6c79604a5..830f0206aea7 100644 > > --- a/Documentation/devicetree/bindings/opp/opp.txt > > +++ b/Documentation/devicetree/bindings/opp/opp.txt > > @@ -132,6 +132,9 @@ Optional properties: > > - opp-level: A value representing the performance level of the device, > > expressed as a 32-bit integer. > > +- bandwidth-MBps: The interconnect bandwidth is specified with an array containing > > + the two integer values for average and peak bandwidth in megabytes per second. > > + > > - clock-latency-ns: Specifies the maximum possible transition latency (in > > nanoseconds) for switching to this OPP from any other OPP. > > @@ -546,3 +549,38 @@ Example 6: opp-microvolt-, opp-microamp-: > > }; > > }; > > }; > > + > > +Example 7: bandwidth-MBps: > > +Average and peak bandwidth values for the interconnects between CPU and DDR > > +memory and also between CPU and L3 are defined per each OPP. Bandwidth of both > > +interconnects is scaled together with CPU frequency. > > + > > +/ { > > + cpus { > > + CPU0: cpu@0 { > > + compatible = "arm,cortex-a53", "arm,armv8"; > > + ... > > + operating-points-v2 = <&cpu_opp_table>; > > + /* path between CPU and DDR memory and CPU and L3 */ > > + interconnects = <&noc MASTER_CPU &noc SLAVE_DDR>, > > + <&noc MASTER_CPU &noc SLAVE_L3>; > > + }; > > + }; > > + > > + cpu_opp_table: cpu_opp_table { > > + compatible = "operating-points-v2"; > > + opp-shared; > > + > > + opp-200000000 { > > + opp-hz = /bits/ 64 <200000000>; > > + /* CPU<->DDR bandwidth: 457 MB/s average, 1525 MB/s peak */ > > + * CPU<->L3 bandwidth: 914 MB/s average, 3050 MB/s peak */ > > + bandwidth-MBps = <457 1525>, <914 3050>; > > Should this also have a bandwidth-MBps-name perhaps? Without that I guess we assume > the order in which we specify the interconnects is the same as the order here? Right, so I suggested not to add the -name property and to rely on the order. Though I missed that he hasn't mentioned the order thing here. @Georgi: Please mention above in the binding that the order is same as interconnects binding. -- viresh