From patchwork Mon Jun 12 14:13:56 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Georgi Djakov X-Patchwork-Id: 103621 Delivered-To: patch@linaro.org Received: by 10.140.91.77 with SMTP id y71csp214167qgd; Mon, 12 Jun 2017 07:14:15 -0700 (PDT) X-Received: by 10.99.109.7 with SMTP id i7mr55875344pgc.143.1497276855118; Mon, 12 Jun 2017 07:14:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497276855; cv=none; d=google.com; s=arc-20160816; b=ZTQ95lzpS14Ne98uDp5T1WFXa8yWz0nf6plG4Yiu7srKqWByYSLB7OAegRAOcmJIij Jaf0oBDi6yvqp1I06aJKAqs48W7Y068gRQWl7jPNm/SWgpRNKsxXs7oVA6WJNlVpZLh6 J3+XDzjFmd94PnBZqcDaECbyWdrTsx70J2CF1BfyLnTECQbnwjKZxkmqH1h9oF+b4cBx ongFqhmCVs956jibHrmQfQNPU6PLV6fwKvIjGu+UZMGpZWghTH25IbSbLEn12yXhXwHG 7YkKzdSiiG4NnTsQFAencz6b+cKGxQjthUYwm7YxyhgwojCMf79JwEFVIt4pfPSa/e76 vOBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=bN8Hp2imNuowyQWjvTFvqkQE3UjisBLxn9Ys0H+wzAw=; b=xfazOpJ2Ld3bZfDeBdSGPZelsnMKPZ85nJ6JuHrxIvjibGYMiYUNr5P0V0Cl4/YO0o 0HeRz4Thy0Lf0HV0j1IaO2Pma7+4psQuky8b71GCjv6VWKBoMCkmzerTtqrxm7g7mXxA aVJ/abH9sB8WNFC//r8i3z15oWQMy7cExfhfYcJHskHTjXdDaY9EAIhtHBd06amctLzR aiOzyWk6iXSWCqRW3bOW/e2O4eaUOn9NQwQulP9z7GDLwlqCA7cb3Vaod0F7oCM5gVk5 xqVBeEH4fEhEBwTdCZsTs1tA1bA2KgITW9o3ydG4aeqHSOYWmFmSzLJhw3fToO4YYH6r 3/pA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org; 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 m10si12794467pgn.212.2017.06.12.07.14.14; Mon, 12 Jun 2017 07:14:15 -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; 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 S1752286AbdFLOOF (ORCPT + 25 others); Mon, 12 Jun 2017 10:14:05 -0400 Received: from mail-wr0-f170.google.com ([209.85.128.170]:35772 "EHLO mail-wr0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751968AbdFLOOD (ORCPT ); Mon, 12 Jun 2017 10:14:03 -0400 Received: by mail-wr0-f170.google.com with SMTP id q97so99073360wrb.2 for ; Mon, 12 Jun 2017 07:14:02 -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; bh=bN8Hp2imNuowyQWjvTFvqkQE3UjisBLxn9Ys0H+wzAw=; b=IC6ByKITSQLXTn3GZe5T4V9Wwz1IxD9zM3u/0yW+phL6cpfa1NdISATmNsQD/N2wA0 7nagaKaBLcGBAY3pKZNYoLl/N2REA6M0OCbmpl+jGq2ir947kdq6T7u3h+CAjh9iBp1c istJyNw2h8xaHdZumaLSHYTk3vJjb8XfZYDHQ= 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; bh=bN8Hp2imNuowyQWjvTFvqkQE3UjisBLxn9Ys0H+wzAw=; b=oebXiUjyYQfpqJFcNgA4QSpDuch7MQ3PB2c+mvk4oD1J77pnjfooXf956FknySsdjk p5j7l3QveqmENdnYq8rw0JxXAS33BkpDjeX8NwfOp6i5uPFQVt+aHMSNT1SW8TGtHgGh 5LGz80MG3QefpWcyGwRJZa5Q+GdrIDBsCOljO+fPJfloiYfPPoOTsm3FZdhxFFXeOQ1F MvGXJvAldjCat2M87HDDuY8MOH0y0QmuNr4lPC8p33iBag2aijspFqdy6d6oOhoSJSxb Vkd/1UkJbTejyqWcgq3212HeTZ1hTe//+euO5eaSrtEC8d2IeGGxDs2NPmyyyZBe0kNP gJYw== X-Gm-Message-State: AODbwcBvTafHWsMp1vwsf1bZ6XpdJr9HgidzKn1E0I5asIz0U0id/7Te 281aR5ejxebxZKJi X-Received: by 10.223.172.145 with SMTP id o17mr7344175wrc.181.1497276841319; Mon, 12 Jun 2017 07:14:01 -0700 (PDT) Received: from mms-0441.qualcomm.mm-sol.com ([212.45.67.2]) by smtp.googlemail.com with ESMTPSA id q77sm265383wmb.4.2017.06.12.07.13.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 12 Jun 2017 07:14:00 -0700 (PDT) From: Georgi Djakov To: linux-pm@vger.kernel.org, rjw@rjwysocki.net Cc: robh+dt@kernel.org, khilman@baylibre.com, mturquette@baylibre.com, gregkh@linuxfoundation.org, vincent.guittot@linaro.org, skannan@codeaurora.org, sboyd@codeaurora.org, andy.gross@linaro.org, seansw@qti.qualcomm.com, davidai@quicinc.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, georgi.djakov@linaro.org Subject: [RFC v2 0/3] Introduce on-chip interconnect API Date: Mon, 12 Jun 2017 17:13:56 +0300 Message-Id: <20170612141359.26117-1-georgi.djakov@linaro.org> X-Mailer: git-send-email 2.13.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Modern SoCs have multiple processors and various dedicated cores (video, gpu, graphics, modem). These cores are talking to each other and can generate a lot of data flowing through the on-chip interconnects. These interconnect buses could form different topologies such as crossbar, point to point buses, hierarchical buses or use the network-on-chip concept. These buses have been sized usually to handle use cases with high data throughput but it is not necessary all the time and consume a lot of power. Furthermore, the priority between masters can vary depending on the running use case like video playback or cpu intensive tasks. Having an API to control the requirement of the system in term of bandwidth and QoS, so we can adapt the interconnect configuration to match those by scaling the frequencies, setting link priority and tuning QoS parameters. This configuration can be a static, one-time operation done at boot for some platforms or a dynamic set of operations that happen at run-time. This patchset introduce a new API to get the requirement and configure the interconnect buses across the entire chipset to fit with the current demand. The API is NOT for changing the performance of the endpoint devices, but only the interconnect path in between them. The API is using a consumer/provider-based model, where the providers are the interconnect controllers and the consumers could be various drivers. The consumers request interconnect resources (path) to an endpoint and set the desired constraints on this data flow path. The provider(s) 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. Below is a simplified diagram of a real-world SoC topology. The interconnect providers are the memory front-end and the NoCs. +----------------+ +----------------+ | HW Accelerator |--->| M NoC |<---------------+ +----------------+ +----------------+ | | | +------------+ +-------------+ V +------+ | | | +--------+ | PCIe | | | | | Slaves | +------+ | | | +--------+ | | C NoC | V V | | +------------------+ +------------------------+ | | +-----+ | |-->| |-->| |-->| CPU | | |-->| |<--| | +-----+ | Memory | | S NoC | +------------+ | |<--| |---------+ | | |<--| |<------+ | | +--------+ +------------------+ +------------------------+ | | +-->| Slaves | ^ ^ ^ ^ | | +--------+ | | | | | V +-----+ | +-----+ +-----+ +---------+ +----------------+ +--------+ | CPU | | | GPU | | DSP | | Masters |-->| P NoC |-->| Slaves | +-----+ | +-----+ +-----+ +---------+ +----------------+ +--------+ | +-------+ | Modem | +-------+ This RFC does not implement all features but only main skeleton to check the validity of the proposal. TODO: * Constraints are currently stored in internal data structure. Should PM QoS be used instead? * Extend interconect_set() to handle parameters such as latency and other QoS values. * Cache the path between the nodes instead of walking the graph on each get(). * Sync interconnect requests with the idle state of the device. Summary of the patches: Patch 1 introduces the interconnect API. Patch 2 creates the first vendor specific interconnect controller driver. Patch 3 is a proposal for DT bindings Changes since RFC v1 (https://lkml.org/lkml/2017/5/15/605) * Refactored code into shorter functions. * Added a new aggregate() API function. * Rearranged some structs to reduce padding bytes. Changes since RFC v0 (https://lkml.org/lkml/2017/3/1/599) * Removed DT support and added optional Patch 3 with new bindings proposal. * Converted the topology into internal driver data. * Made the framework modular. * interconnect_get() now takes (src and dst ports as arguments). * Removed public declarations of some structs. * Now passing prev/next nodes to the vendor driver. * Properly remove requests on _put(). * Added refcounting. * Updated documentation. * Changed struct interconnect_path to use array instead of linked list. Georgi Djakov (3): interconnect: Add generic interconnect controller API interconnect: Add Qualcomm msm8916 interconnect provider driver dt-binding: Interconnect device-tree bindings draft .../bindings/interconnect/interconnect.txt | 75 ++++ Documentation/interconnect/interconnect.txt | 65 ++++ drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/interconnect/Kconfig | 15 + drivers/interconnect/Makefile | 2 + drivers/interconnect/interconnect.c | 376 +++++++++++++++++++ drivers/interconnect/qcom/Kconfig | 12 + drivers/interconnect/qcom/Makefile | 2 + drivers/interconnect/qcom/interconnect_msm8916.c | 417 +++++++++++++++++++++ include/dt-bindings/interconnect/qcom,msm8916.h | 87 +++++ include/linux/interconnect-consumer.h | 72 ++++ include/linux/interconnect-provider.h | 120 ++++++ 13 files changed, 1246 insertions(+) create mode 100644 Documentation/devicetree/bindings/interconnect/interconnect.txt create mode 100644 Documentation/interconnect/interconnect.txt create mode 100644 drivers/interconnect/Kconfig create mode 100644 drivers/interconnect/Makefile create mode 100644 drivers/interconnect/interconnect.c create mode 100644 drivers/interconnect/qcom/Kconfig create mode 100644 drivers/interconnect/qcom/Makefile create mode 100644 drivers/interconnect/qcom/interconnect_msm8916.c create mode 100644 include/dt-bindings/interconnect/qcom,msm8916.h create mode 100644 include/linux/interconnect-consumer.h create mode 100644 include/linux/interconnect-provider.h