From mboxrd@z Thu Jan 1 00:00:00 1970 From: Georgi Djakov Subject: Re:[PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings Date: Tue, 7 Aug 2018 17:54:38 +0300 Message-ID: References: <20180731161340.13000-1-georgi.djakov@linaro.org> <20180731161340.13000-3-georgi.djakov@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Rob Herring , maxime.ripard@bootlin.com Cc: linux-pm@vger.kernel.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Rob Herring , Mike Turquette , khilman@baylibre.com, Vincent Guittot , skannan@codeaurora.org, Bjorn Andersson , Amit Kucheria , seansw@qti.qualcomm.com, daidavid1@codeaurora.org, evgreen@chromium.org, Mark Rutland , Lorenzo Pieralisi , Alexandre Bailon , Arnd Bergmann , Linux Kernel Mailing List , linux-arm-kernel , linux-arm-msm@vger.kernel.org, devicetree@vger.kerne List-Id: linux-arm-msm@vger.kernel.org Hi Rob, On 08/03/2018 12:02 AM, Rob Herring wrote: > On Tue, Jul 31, 2018 at 10:13 AM Georgi Djakov wrote: >> >> This binding is intended to represent the interconnect hardware present >> in some of the modern SoCs. Currently it consists only of a binding for >> the interconnect hardware devices (provider). > > If you want the bindings reviewed, then you need to send them to the > DT list. CC'ing me is pointless, I get CC'ed too many things to read. Ops, ok! > The consumer and producer binding should be a single patch. One is not > useful without the other. The reason for splitting them is that they can be reviewed separately. Also we can rely on platform data instead of using DT and the consumer binding. However will do as you suggest. > There is also a patch series from Maxime Ripard that's addressing the > same general area. See "dt-bindings: Add a dma-parent property". We > don't need multiple ways to address describing the device to memory > paths, so you all had better work out a common solution. Looks like this fits exactly into the interconnect API concept. I see MBUS as interconnect provider and display/camera as consumers, that report their bandwidth needs. I am also planning to add support for priority. Thanks, Georgi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B1D29C46471 for ; Tue, 7 Aug 2018 14:54:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6033121502 for ; Tue, 7 Aug 2018 14:54:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linaro.org header.i=@linaro.org header.b="cFhg+3gu" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6033121502 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389802AbeHGRJX (ORCPT ); Tue, 7 Aug 2018 13:09:23 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36720 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388894AbeHGRJX (ORCPT ); Tue, 7 Aug 2018 13:09:23 -0400 Received: by mail-wm0-f66.google.com with SMTP id w24-v6so18439050wmc.1 for ; Tue, 07 Aug 2018 07:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:subject:to:cc:references:openpgp:autocrypt:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fHdWEX4FvOJ4Dd3bhHgaUlFW4+bntbx8kLWTZ+ZVlTw=; b=cFhg+3gu8eQaVKqNhfowD+i7U/PD54GjuRe5SwShs0NZjpCM32DftZLchP82pgDOY1 YnJ7z0E5N2wWvVxd53p3zWHg5snkJLSqgMpt4v2HJseAl3SJCaozEJ+NvlLS3VDOA5ea s9i8P9FS7LVdSVfQmWgvkFYQvXMovmoKR/uyc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:openpgp:autocrypt :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fHdWEX4FvOJ4Dd3bhHgaUlFW4+bntbx8kLWTZ+ZVlTw=; b=McdbbJ2t0y6q0NHE6TcYVSVTcaiFvY7zhP7CY+XT3mrAe1NSRBBjWeyhWQ9Y6isipx ahXkw+OD+mQ4FZRsdLwEGR4OQLI4UYmPwkbvzxx68nSFunOPJOAk2gan8whmUlCune1i VDwcHOlMf0bmJ8xSGSw+J+OUc/OcEz2PwmpYPlOKTkBlWXkwlbiAEBegq5jHVhDa21j5 ZcvraMOLp1lSXuPz8VGyBfm4MPGQUKKz60x8yr+NjozflNJo6QPMrWj98wEYoijhzJJn 7hCxJMG9W/lgbud6vWsdn87vpakaXzslmh/XjeRIBQe99aSsAoHzzZbigT7rWZFHHai7 jq8w== X-Gm-Message-State: AOUpUlEFtT4/L3QW8ZfkaeZBTGkTikocI78w3cabbZQhOZa1mxrpBt8w oZPQ5/38oF5cYjUJ+GAc6CvcbQ== X-Google-Smtp-Source: AA+uWPx1yt6/BF+RIPNnLDTUnXD3h4d1l9lwJB0Vsen8CbvroFJaOkgqLZR9gneM43Wxnp/laTSPCw== X-Received: by 2002:a1c:3646:: with SMTP id d67-v6mr1804019wma.15.1533653680262; Tue, 07 Aug 2018 07:54:40 -0700 (PDT) Received: from [10.44.66.8] ([212.45.67.2]) by smtp.googlemail.com with ESMTPSA id w4-v6sm1513628wrt.40.2018.08.07.07.54.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Aug 2018 07:54:39 -0700 (PDT) From: Georgi Djakov Subject: Re:[PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings To: Rob Herring , maxime.ripard@bootlin.com Cc: linux-pm@vger.kernel.org, Greg Kroah-Hartman , "Rafael J. Wysocki" , Rob Herring , Mike Turquette , khilman@baylibre.com, Vincent Guittot , skannan@codeaurora.org, Bjorn Andersson , Amit Kucheria , seansw@qti.qualcomm.com, daidavid1@codeaurora.org, evgreen@chromium.org, Mark Rutland , Lorenzo Pieralisi , Alexandre Bailon , Arnd Bergmann , Linux Kernel Mailing List , linux-arm-kernel , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org References: <20180731161340.13000-1-georgi.djakov@linaro.org> <20180731161340.13000-3-georgi.djakov@linaro.org> Openpgp: preference=signencrypt Autocrypt: addr=georgi.djakov@linaro.org; prefer-encrypt=mutual; keydata= xsFNBFjTuRcBEACyAOVzghvyN19Sa/Nit4LPBWkICi5W20p6bwiZvdjhtuh50H5q4ktyxJtp 1+s8dMSa/j58hAWhrc2SNL3fttOCo+MM1bQWwe8uMBQJP4swgXf5ZUYkSssQlXxGKqBSbWLB uFHOOBTzaQBaNgsdXo+mQ1h8UCgM0zQOmbs2ort8aHnH2i65oLs5/Xgv/Qivde/FcFtvEFaL 0TZ7odM67u+M32VetH5nBVPESmnEDjRBPw/DOPhFBPXtal53ZFiiRr6Bm1qKVu3dOEYXHHDt nF13gB+vBZ6x5pjl02NUEucSHQiuCc2Aaavo6xnuBc3lnd4z/xk6GLBqFP3P/eJ56eJv4d0B 0LLgQ7c1T3fU4/5NDRRCnyk6HJ5+HSxD4KVuluj0jnXW4CKzFkKaTxOp7jE6ZD/9Sh74DM8v etN8uwDjtYsM07I3Szlh/I+iThxe/4zVtUQsvgXjwuoOOBWWc4m4KKg+W4zm8bSCqrd1DUgL f67WiEZgvN7tPXEzi84zT1PiUOM98dOnmREIamSpKOKFereIrKX2IcnZn8jyycE12zMkk+Sc ASMfXhfywB0tXRNmzsywdxQFcJ6jblPNxscnGMh2VlY2rezmqJdcK4G4Lprkc0jOHotV/6oJ mj9h95Ouvbq5TDHx+ERn8uytPygDBR67kNHs18LkvrEex/Z1cQARAQABzShHZW9yZ2kgRGph a292IDxnZW9yZ2kuZGpha292QGxpbmFyby5vcmc+wsF+BBMBAgAoBQJY07kXAhsDBQkHhM4A BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyi/eZcnWWUuvsD/4miikUeAO6fU2Xy3fT l7RUCeb2Uuh1/nxYoE1vtXcow6SyAvIVTD32kHXucJJfYy2zFzptWpvD6Sa0Sc58qe4iLY4j M54ugOYK7XeRKkQHFqqR2T3g/toVG1BOLS2atooXEU+8OFbpLkBXbIdItqJ1M1SEw8YgKmmr JlLAaKMq3hMb5bDQx9erq7PqEKOB/Va0nNu17IL58q+Q5Om7S1x54Oj6LiG/9kNOxQTklOQZ t61oW1Ewjbl325fW0/Lk0QzmfLCrmGXXiedFEMRLCJbVImXVKdIt/Ubk6SAAUrA5dFVNBzm2 L8r+HxJcfDeEpdOZJzuwRyFnH96u1Xz+7X2V26zMU6Wl2+lhvr2Tj7spxjppR+nuFiybQq7k MIwyEF0mb75RLhW33sdGStCZ/nBsXIGAUS7OBj+a5fm47vQKv6ekg60oRTHWysFSJm1mlRyq exhI6GwUo5GM/vE36rIPSJFRRgkt6nynoba/1c4VXxfhok2rkP0x3CApJ5RimbvITTnINY0o CU6f1ng1I0A1UTi2YcLjFq/gmCdOHExT4huywfu1DDf0p1xDyPA1FJaii/gJ32bBP3zK53hM dj5S7miqN7F6ZpvGSGXgahQzkGyYpBR5pda0m0k8drV2IQn+0W8Qwh4XZ6/YdfI81+xyFlXc CJjljqsMCJW6PdgEH87BTQRY07kXARAAvupGd4Jdd8zRRiF+jMpv6ZGz8L55Di1fl1YRth6m lIxYTLwGf0/p0oDLIRldKswena3fbWh5bbTMkJmRiOQ/hffhPSNSyyh+WQeLY2kzl6geiHxD zbw37e2hd3rWAEfVFEXOLnmenaUeJFyhA3Wd8OLdRMuoV+RaLhNfeHctiEn1YGy2gLCq4VNb 4Wj5hEzABGO7+LZ14hdw3hJIEGKtQC65Jh/vTayGD+qdwedhINnIqslk9tCQ33a+jPrCjXLW X29rcgqigzsLHH7iVHWA9R5Aq7pCy5hSFsl4NBn1uV6UHlyOBUuiHBDVwTIAUnZ4S8EQiwgv WQxEkXEWLM850V+G6R593yZndTr3yydPgYv0xEDACd6GcNLR/x8mawmHKzNmnRJoOh6Rkfw2 fSiVGesGo83+iYq0NZASrXHAjWgtZXO1YwjW9gCQ2jYu9RGuQM8zIPY1VDpQ6wJtjO/KaOLm NehSR2R6tgBJK7XD9it79LdbPKDKoFSqxaAvXwWgXBj0Oz+Y0BqfClnAbxx3kYlSwfPHDFYc R/ppSgnbR5j0Rjz/N6Lua3S42MDhQGoTlVkgAi1btbdV3qpFE6jglJsJUDlqnEnwf03EgjdJ 6KEh0z57lyVcy5F/EUKfTAMZweBnkPo+BF2LBYn3Qd+CS6haZAWaG7vzVJu4W/mPQzsAEQEA AcLBZQQYAQIADwUCWNO5FwIbDAUJB4TOAAAKCRCyi/eZcnWWUhlHD/0VE/2x6lKh2FGP+QHH UTKmiiwtMurYKJsSJlQx0T+j/1f+zYkY3MDX+gXa0d0xb4eFv8WNlEjkcpSPFr+pQ7CiAI33 99kAVMQEip/MwoTYvM9NXSMTpyRJ/asnLeqa0WU6l6Z9mQ41lLzPFBAJ21/ddT4xeBDv0dxM GqaH2C6bSnJkhSfSja9OxBe+F6LIAZgCFzlogbmSWmUdLBg+sh3K6aiBDAdZPUMvGHzHK3fj gHK4GqGCFK76bFrHQYgiBOrcR4GDklj4Gk9osIfdXIAkBvRGw8zg1zzUYwMYk+A6v40gBn00 OOB13qJe9zyKpReWMAhg7BYPBKIm/qSr82aIQc4+FlDX2Ot6T/4tGUDr9MAHaBKFtVyIqXBO xOf0vQEokkUGRKWBE0uA3zFVRfLiT6NUjDQ0vdphTnsdA7h01MliZLQ2lLL2Mt5lsqU+6sup Tfql1omgEpjnFsPsyFebzcKGbdEr6vySGa3Cof+miX06hQXKe99a5+eHNhtZJcMAIO89wZmj 7ayYJIXFqjl/X0KBcCbiAl4vbdBw1bqFnO4zd1lMXKVoa29UHqby4MPbQhjWNVv9kqp8A39+ E9xw890l1xdERkjVKX6IEJu2hf7X3MMl9tOjBK6MvdOUxvh1bNNmXh7OlBL1MpJYY/ydIm3B KEmKjLDvB0pePJkdTw== Message-ID: Date: Tue, 7 Aug 2018 17:54:38 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On 08/03/2018 12:02 AM, Rob Herring wrote: > On Tue, Jul 31, 2018 at 10:13 AM Georgi Djakov wrote: >> >> This binding is intended to represent the interconnect hardware present >> in some of the modern SoCs. Currently it consists only of a binding for >> the interconnect hardware devices (provider). > > If you want the bindings reviewed, then you need to send them to the > DT list. CC'ing me is pointless, I get CC'ed too many things to read. Ops, ok! > The consumer and producer binding should be a single patch. One is not > useful without the other. The reason for splitting them is that they can be reviewed separately. Also we can rely on platform data instead of using DT and the consumer binding. However will do as you suggest. > There is also a patch series from Maxime Ripard that's addressing the > same general area. See "dt-bindings: Add a dma-parent property". We > don't need multiple ways to address describing the device to memory > paths, so you all had better work out a common solution. Looks like this fits exactly into the interconnect API concept. I see MBUS as interconnect provider and display/camera as consumers, that report their bandwidth needs. I am also planning to add support for priority. Thanks, Georgi From mboxrd@z Thu Jan 1 00:00:00 1970 From: georgi.djakov@linaro.org (Georgi Djakov) Date: Tue, 7 Aug 2018 17:54:38 +0300 Subject: [PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings In-Reply-To: References: <20180731161340.13000-1-georgi.djakov@linaro.org> <20180731161340.13000-3-georgi.djakov@linaro.org> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Rob, On 08/03/2018 12:02 AM, Rob Herring wrote: > On Tue, Jul 31, 2018 at 10:13 AM Georgi Djakov wrote: >> >> This binding is intended to represent the interconnect hardware present >> in some of the modern SoCs. Currently it consists only of a binding for >> the interconnect hardware devices (provider). > > If you want the bindings reviewed, then you need to send them to the > DT list. CC'ing me is pointless, I get CC'ed too many things to read. Ops, ok! > The consumer and producer binding should be a single patch. One is not > useful without the other. The reason for splitting them is that they can be reviewed separately. Also we can rely on platform data instead of using DT and the consumer binding. However will do as you suggest. > There is also a patch series from Maxime Ripard that's addressing the > same general area. See "dt-bindings: Add a dma-parent property". We > don't need multiple ways to address describing the device to memory > paths, so you all had better work out a common solution. Looks like this fits exactly into the interconnect API concept. I see MBUS as interconnect provider and display/camera as consumers, that report their bandwidth needs. I am also planning to add support for priority. Thanks, Georgi