Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp3822400ybi; Mon, 29 Jul 2019 13:18:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqwcGqGcxg6fCO6Wr2zA6HW0VPD0L5VlfMRKmEtoDR3BkoNlkvcwmLdIQbsMDN3NhES29Ou8 X-Received: by 2002:a17:902:2d01:: with SMTP id o1mr114414340plb.105.1564431497140; Mon, 29 Jul 2019 13:18:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564431497; cv=none; d=google.com; s=arc-20160816; b=Yq9dj4ZoFp4zA7ImjSDrI8pAtTclTY/TBvePXc0wkwAnjlfFhudDzhxHds1uwr0Kz4 4Bd2TiMKDco5JPoWw5Xfhgwc+m0qoLeis3sL2y98Cdx7WFNYVTc/hSJShtajIo4EwsQB +hvMpkBc7xpaTBPsZ8AUksbdgc6nBXKHwuK66Bu2V2g9xKCamC1ol2Sc7TfNotvwHpNT hVsrax1W9UCh74eNO2+cBqIHNBO3lUIoO+nERR29ZhIS7ys+aOL7TU1fHJ5ZjU1PDsMY lNAoAt89GdSHlSF6oFwRykXjtlh722SRCPWKyVTzqOiZYlciny0hxR57QzaEik2meXhJ oRsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=r8zi81LHOHqEUYJ5h1qiWav8ZTAlVex16b4xeeFlwaI=; b=U7HzqQzvNYxvu3QKSfVFnV7HPY75AaMTaTUjUIzyxeqVyKNlGZYoko+oj2u8MhfYWj iAT2+klzGs7uHEba3/Us96Hznx2gnVaojZI7wB4bMG5JoiGtxPRUvW/atawlWc6eNPkN XaLdr/u05Ii0U7QfccaALlGCXlFEdLCAe4BBXPq2RmeCttUnAVC92HnpvKYmyvwK7C+S 3XGD3KLIZmalIatIj0g+CbTEk8xYAqoXNp5nZp/5800/ZGC0AYnIFVVpUS2e3AIvSQor lV8ZEmdnGAYxI5ctpuUE2njpN1miBauAQL5gZLTmXESiN4cB1D9Uf9yEAMl/Z7pj8tnC ElJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="I6/EVosz"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b25si31889571pgl.270.2019.07.29.13.18.02; Mon, 29 Jul 2019 13:18:17 -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=@google.com header.s=20161025 header.b="I6/EVosz"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729423AbfG2UQ5 (ORCPT + 99 others); Mon, 29 Jul 2019 16:16:57 -0400 Received: from mail-oi1-f195.google.com ([209.85.167.195]:40946 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727302AbfG2UQ4 (ORCPT ); Mon, 29 Jul 2019 16:16:56 -0400 Received: by mail-oi1-f195.google.com with SMTP id w196so24897910oie.7 for ; Mon, 29 Jul 2019 13:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r8zi81LHOHqEUYJ5h1qiWav8ZTAlVex16b4xeeFlwaI=; b=I6/EVoszemoOmGnO4iFjE+KkZf4mW8yad0zcnup0o2vWzk84+cO5qrk8H0szXoY/yT dF/VG41/bLAp3LCro842eoAFVplvHIxwGBEpTU/93OM6j7gkkopwHpAJvhLbBWUoa2c2 ZNOWp8QWsyddeXwnUn00kHkCslGISArM1EWlRfLoh0nYkvglI+yW2KAZhojjjvK85wzI RDRoh+mkhNIob/680owAhI9JomaSkwGmk7B89s2SD8EwAkFlhJplFkrqu57X92lglO0y Kj1ugsHCxSV3muxvPQhnL1vEEgylOpVZ0Uf2YVjK34Vcxy11LZCmMGRZVZyYkR9KurSW VZNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r8zi81LHOHqEUYJ5h1qiWav8ZTAlVex16b4xeeFlwaI=; b=ErD9PfVclletSLYSc/r4K+DmnM5WAUsqRQZ3wtxVSHeBI2CNitQ+b8aq8O2/Q7hA3y 1RCldfPCRkeQ36SmFjf3TbyKHj4B60Zt2Dun73u1PZyj7RpBfWxtwxT0U7ml3N1j5nOF Uypwogulh0jm7/8Be3XZ4KUIHmpRyJh/OQ4mmG6PseanB0Z3miIQzZECTmwI7WQckRlv WBdAvCQlygpx2uhPIRUpzYuBFlVhPuGAOJGr54kP3PncJqzwFzF03C6xWjjtpONQK5qW V3SOZrVcDOBUnFPVeSs9YJf71+U83sipB44I2J/thooh+G5w7Y0uwI71uQ7H/HQdpM62 oAxA== X-Gm-Message-State: APjAAAXpyPZu2G++oV2tjCP4Q/bkLGJ7UD+eC1hU5tpQ5wVY7Q2R5NCm pqakVunhtF4H/YpyT7LwbslTUqCzpjmo85gi2GAcbg== X-Received: by 2002:aca:1803:: with SMTP id h3mr21244210oih.24.1564431415085; Mon, 29 Jul 2019 13:16:55 -0700 (PDT) MIME-Version: 1.0 References: <20190726231558.175130-1-saravanak@google.com> <20190729093545.kvnqxjkyx4nogddk@vireshk-i7> In-Reply-To: <20190729093545.kvnqxjkyx4nogddk@vireshk-i7> From: Saravana Kannan Date: Mon, 29 Jul 2019 13:16:19 -0700 Message-ID: Subject: Re: [PATCH v4 0/3] Introduce Bandwidth OPPs for interconnects To: Viresh Kumar Cc: Rob Herring , Mark Rutland , Viresh Kumar , Nishanth Menon , Stephen Boyd , "Rafael J. Wysocki" , Georgi Djakov , Vincent Guittot , "Sweeney, Sean" , David Dai , adharmap@codeaurora.org, Rajendra Nayak , Sibi Sankar , Bjorn Andersson , Evan Green , Android Kernel Team , Linux PM , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 29, 2019 at 2:35 AM Viresh Kumar wrote: > > On 26-07-19, 16:15, Saravana Kannan wrote: > > Interconnects and interconnect paths quantify their performance levels in > > terms of bandwidth and not in terms of frequency. So similar to how we have > > frequency based OPP tables in DT and in the OPP framework, we need > > bandwidth OPP table support in DT and in the OPP framework. > > > > So with the DT bindings added in this patch series, the DT for a GPU > > that does bandwidth voting from GPU to Cache and GPU to DDR would look > > something like this: > > > > gpu_cache_opp_table: gpu_cache_opp_table { > > compatible = "operating-points-v2"; > > > > gpu_cache_3000: opp-3000 { > > opp-peak-KBps = <3000000>; > > opp-avg-KBps = <1000000>; > > }; > > gpu_cache_6000: opp-6000 { > > opp-peak-KBps = <6000000>; > > opp-avg-KBps = <2000000>; > > }; > > gpu_cache_9000: opp-9000 { > > opp-peak-KBps = <9000000>; > > opp-avg-KBps = <9000000>; > > }; > > }; > > > > gpu_ddr_opp_table: gpu_ddr_opp_table { > > compatible = "operating-points-v2"; > > > > gpu_ddr_1525: opp-1525 { > > opp-peak-KBps = <1525000>; > > opp-avg-KBps = <452000>; > > }; > > gpu_ddr_3051: opp-3051 { > > opp-peak-KBps = <3051000>; > > opp-avg-KBps = <915000>; > > }; > > gpu_ddr_7500: opp-7500 { > > opp-peak-KBps = <7500000>; > > opp-avg-KBps = <3000000>; > > }; > > }; > > > > gpu_opp_table: gpu_opp_table { > > compatible = "operating-points-v2"; > > opp-shared; > > > > opp-200000000 { > > opp-hz = /bits/ 64 <200000000>; > > }; > > opp-400000000 { > > opp-hz = /bits/ 64 <400000000>; > > }; > > }; > > > > gpu@7864000 { > > ... > > operating-points-v2 = <&gpu_opp_table>, <&gpu_cache_opp_table>, <&gpu_ddr_opp_table>; > > ... > > }; > > One feedback I missed giving earlier. Will it be possible to get some > user code merged along with this ? I want to make sure anything we add > ends up getting used. Sibi might be working on doing that for the SDM845 CPUfreq driver. Georgi could also change his GPU driver use case to use this BW OPP table and required-opps. The problem is that people don't want to start using this until we decide on the DT representation. So it's like a chicken and egg situation. -Saravana