Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp9661042imu; Wed, 5 Dec 2018 08:18:26 -0800 (PST) X-Google-Smtp-Source: AFSGD/WdxdbEgurRBvIO6S5s70kRunPP+GVXkMIFjt9Yf8do6ZCPuUzQZ17H2IkrtaZMlKSqiwsg X-Received: by 2002:a62:d885:: with SMTP id e127mr24818073pfg.197.1544026705993; Wed, 05 Dec 2018 08:18:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544026705; cv=none; d=google.com; s=arc-20160816; b=kn/Iay61RFTvGCkThKlk6s3FWze7nJWfX8X4fmVqf/MPSupHpZ3MBu8bEIwn7mLRIC 9XZOeoBAh9rMt09XvgIEJgudD8b/hanRfHCeysU0Gzo36HmY0QBfTBmJLKeGMykwwWgl a7DXg8hSdRq7yZPgQB08LBsV227zBm6xZainzZYXUX6Y1Jsd2LLWBA9kFCSMk5/urAFU 5bF7ZKj3iKFlEWAn6IYSyhHN76EB9CyJc3Pp3kCuculk0CkEkLJnrw0bPrAYInb6n1xW maBu8s8hLMUbl5QFTGvl1SLuX58K3s0odQdwI32Psx9Mr3flbs4D9KQTHmxszwM/wMG7 WImg== 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=3Kqb/EYldVaCacQDudvzhtRyHatQPHCEq/xFhQfp84Y=; b=zBmUPTGbkwPT5jl8JbXt8EbSFCOUHSM7W/430q4FLXT2njEV9PAjfrAA9/+uRrsrRM vCjEwsW9HfUkLAoTXuSOw16txQ6Rik5rqud3jgLcNqzZoXOQPcqiQOPNnucvYI+jpMTd cbutbTlFX/aLh0aRf+TmF+K8SaW0+0nd+wJKBlRXHDgwbYZbieTFOBG1RzNaC0d/G9Ms RE/MXTrazMY0sv6S4vP3Juq0Jvb75JVjgPyDLLEDvgxVxROQ75zPlU3mFAJaPdpqEjtn jkVaSlzNyHk51nSx6D/1KiXrs2BPwxboMhjbxMa0hPHNXP81ZqtkkRHwtp+j82jfvsWm 6rrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=HgKVnjHd; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m3si20549223pld.331.2018.12.05.08.18.10; Wed, 05 Dec 2018 08:18:25 -0800 (PST) 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=@kernel.org header.s=default header.b=HgKVnjHd; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728172AbeLEQQf (ORCPT + 99 others); Wed, 5 Dec 2018 11:16:35 -0500 Received: from mail.kernel.org ([198.145.29.99]:37680 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727182AbeLEQQf (ORCPT ); Wed, 5 Dec 2018 11:16:35 -0500 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 68195214E0; Wed, 5 Dec 2018 16:16:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1544026593; bh=+gwzwDnPJNvLtZKEcJq1sOD+YlIQ9jtCtlNxDquqasA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=HgKVnjHdkCcyggeq7BjdbCl7BxcHvgPf7S/DHpWyahmTZ4lLqTK5pZFLBIiUO9OcU NRMpTnap7OOMroC5aC+ikTZ9aOsLb3hDUZktI5SL1HNqXFX6A6GF1mxAtwfQ+tLxrc U+KcYKEEF9B9CCrd+RqhQQ/7RzYVyHMHt2OEk5pI= Received: by mail-qt1-f171.google.com with SMTP id k12so22845746qtf.7; Wed, 05 Dec 2018 08:16:33 -0800 (PST) X-Gm-Message-State: AA+aEWaura9G5+NXGidyNAWPOazdvFcE5ke8E4FEyaDh61YP0oItMIaI s521FzAez3+ER+zoOboc4QMDbgwy6gI/Yxs4/A== X-Received: by 2002:ac8:6b18:: with SMTP id w24mr24356925qts.144.1544026592489; Wed, 05 Dec 2018 08:16:32 -0800 (PST) MIME-Version: 1.0 References: <20181127180349.29997-1-georgi.djakov@linaro.org> <20181127180349.29997-2-georgi.djakov@linaro.org> In-Reply-To: <20181127180349.29997-2-georgi.djakov@linaro.org> From: Rob Herring Date: Wed, 5 Dec 2018 10:16:20 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v10 1/7] interconnect: Add generic on-chip interconnect API To: Georgi Djakov Cc: "open list:THERMAL" , Greg Kroah-Hartman , "Rafael J. Wysocki" , Michael Turquette , Kevin Hilman , Vincent Guittot , Saravana Kannan , Bjorn Andersson , Amit Kucheria , seansw@qti.qualcomm.com, daidavid1@codeaurora.org, Evan Green , Mark Rutland , Lorenzo Pieralisi , Alexandre Bailon , Maxime Ripard , Arnd Bergmann , Thierry Reding , ksitaraman@nvidia.com, sanjayc@nvidia.com, devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , linux-arm-msm , linux-tegra@vger.kernel.org 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 Tue, Nov 27, 2018 at 12:03 PM Georgi Djakov wrote: > > This patch introduces a new API to get requirements and configure the > interconnect buses across the entire chipset to fit with the current > demand. > > The API is using a consumer/provider-based model, where the providers are > the interconnect buses and the consumers could be various drivers. > The consumers request interconnect resources (path) between endpoints and > set the desired constraints on this data flow path. The providers receive > requests from consumers and aggregate these requests for all master-slave > pairs on that path. Then the providers configure each participating in the > topology node according to the requested data flow path, physical links and > constraints. The topology could be complicated and multi-tiered and is SoC > specific. > > Signed-off-by: Georgi Djakov > Reviewed-by: Evan Green [...] > +struct icc_path *icc_get(struct device *dev, const int src_id, > + const int dst_id); > +void icc_put(struct icc_path *path); > +int icc_set(struct icc_path *path, u32 avg_bw, u32 peak_bw); icc_set() is very generic, but this function isn't easily extended to other parameters than bandwidth. Perhaps icc_set_bandwidth() instead. Then when you add some other setting, you just add a new function. Of course, if you wind up with a bunch of different parameters, then you'll probably need an atomic type interface where you test all the settings together and then commit them separately in one call. But from a DT perspective, I certainly hope there are not lots of new settings folks want to add. :) Rob