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=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 93B33C7618B for ; Wed, 24 Jul 2019 14:18:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6723E22ADB for ; Wed, 24 Jul 2019 14:18:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="TND1gWT+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728216AbfGXOSS (ORCPT ); Wed, 24 Jul 2019 10:18:18 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:46544 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728183AbfGXOSS (ORCPT ); Wed, 24 Jul 2019 10:18:18 -0400 Received: by mail-pf1-f193.google.com with SMTP id c73so21027486pfb.13 for ; Wed, 24 Jul 2019 07:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=message-id:mime-version:content-transfer-encoding:in-reply-to :references:subject:to:cc:from:user-agent:date; bh=i6ucO8M1kBwfk/WDeuCHxIoA+2DfAiPuMamyFSvxMIE=; b=TND1gWT+zyPtTrknjApjowmDcsWxhTeFFGQQKuHPjwHM2p+eRGXgyM/jgeho5dZ5b/ bLE5zwWspO66n2PXUX4fU3WNEigbELc5ZOvRddO9zVh/AEf6mn610vnp/GjuLr8pjT3r Tl8gh340iXQfZf7V6Z0eW5ED8IBh6e7w7hGeQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version :content-transfer-encoding:in-reply-to:references:subject:to:cc:from :user-agent:date; bh=i6ucO8M1kBwfk/WDeuCHxIoA+2DfAiPuMamyFSvxMIE=; b=I6Dwp8csdpsSdVrr/+KtbmJzsZg7QJHbvQX9Fu1CUTxgVyrgHe7EZDoRKarjIje3oc 3WKS7wxwPFVzBb+3aick0s57XoxXhu0e7kCH9nayEwGGiqE+2JLVWotnIcz3ZQ+0qxYZ YEwmUs0UNhx+64OTSy0vws/T85MII+JdBPM19H7rsqXDI84b2AIWdjZDsuRUsLxND4Bz oQgQ1V6VqYtJGjNjkPvz/ABGM9nIKdoMH0E7QXup1NUCfDWXoWKqA3OCHlVD+uIO0xvj PvBNDA8Pvk+co9YRw7LiDw3Z8Okgw7eCQ3DTC9CRw4DS1It4J98Emj48ghRfz/+M7sRD mbsQ== X-Gm-Message-State: APjAAAWkC8yQ9eVAoBjdSd3d/vxyzCw5GmCFbLOteoFzvFIEwfyIoK1j P5aTwM1VhI3ylwewDaKhN/scyg== X-Google-Smtp-Source: APXvYqwA2DaROWqS6dAgzLQRMlZAOqpPRUpDwwbWaRi5dnx4FVbkt5kHlJYwChON/qwoRaxOY5ouTQ== X-Received: by 2002:a17:90a:d151:: with SMTP id t17mr87008292pjw.60.1563977898088; Wed, 24 Jul 2019 07:18:18 -0700 (PDT) Received: from chromium.org ([2620:15c:202:1:fa53:7765:582b:82b9]) by smtp.gmail.com with ESMTPSA id j20sm44352358pfr.113.2019.07.24.07.18.17 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 24 Jul 2019 07:18:17 -0700 (PDT) Message-ID: <5d3868a9.1c69fb81.876aa.ac30@mx.google.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <8c181f08-559b-5d77-a617-65cfd3d5da55@codeaurora.org> References: <1563568344-1274-1-git-send-email-daidavid1@codeaurora.org> <1563568344-1274-2-git-send-email-daidavid1@codeaurora.org> <5d371ce7.1c69fb81.9650.8239@mx.google.com> <8c181f08-559b-5d77-a617-65cfd3d5da55@codeaurora.org> Subject: Re: [PATCH 1/2] dt-bindings: interconnect: Update Qualcomm SDM845 DT bindings To: David Dai , bjorn.andersson@linaro.org, georgi.djakov@linaro.org, robh+dt@kernel.org Cc: evgreen@google.com, ilina@codeaurora.org, seansw@qti.qualcomm.com, elder@linaro.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org From: Stephen Boyd User-Agent: alot/0.8.1 Date: Wed, 24 Jul 2019 07:18:16 -0700 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Quoting David Dai (2019-07-23 14:48:42) > On 7/23/2019 7:42 AM, Stephen Boyd wrote: > > Quoting David Dai (2019-07-19 13:32:23) > >> +- compatible : shall contain only one of the following: > >> + "qcom,sdm845-bcm-voter", > >> + > >> +Examples: > >> + > >> +apps_rsc: rsc@179c0000 { > > But there isn't a reg property. > I'll change this to the generic example with just apps_rsc: rsc { > > > >> + label =3D "apps_rsc"; > > Is label required? Any answer? > > > >> + compatible =3D "qcom,rpmh-rsc"; > >> + > >> + apps_bcm_voter: bcm_voter { > >> + compatible =3D "qcom,sdm845-bcm-voter"; > >> + }; > >> +} > >> + > >> +disp_rsc: rsc@179d0000 { > >> + label =3D "disp_rsc"; > >> + compatible =3D "qcom,rpmh-rsc"; > >> + > >> + disp_bcm_voter: bcm_voter { > >> + compatible =3D "qcom,sdm845-bcm-voter"; > >> + }; > >> +} > >> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,sdm84= 5.txt b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt > >> index 5c4f1d9..27f9ed9 100644 > >> --- a/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt > >> +++ b/Documentation/devicetree/bindings/interconnect/qcom,sdm845.txt [...] > >> + > >> +mem_noc: interconnect@1380000 { > >> + compatible =3D "qcom,sdm845-mem_noc"; > >> + reg =3D <0 0x1380000 0 0x27200>; > >> + #interconnect-cells =3D <1>; > >> + qcom,bcm-voter =3D <&apps_bcm_voter>, <&disp_bcm_voter>; > >> +}; > > How does a consumer target a particular RSC? For example, how can > > display decide to use the disp_bcm_voter node from mem_noc here? Maybe > > you can add that consumer to the example? >=20 > I was thinking that the association between the bcm voters and the icc=20 > nodes would be handled by the interconnect provider, and that there=20 > would be a set of display specific icc nodes with their own unique IDs=20 > that the consumers could reference. I will mention this as part of the=20 > description and provide an example. >=20 > Ex: interconnects =3D <&mmss_noc MASTER_MDP0_DISP &mem_noc SLAVE_EBI_DISP= >; >=20 It looks backwards to me. Don't the consumers want to consume a particular RSC, i.e. apps or display RSC, so they can choose where to put the bcm vote and then those RSCs want to find MMIO registers for mmss_noc or mem_noc that they have to write to tune something else like QoS? If the MMIO space is the provider then I'm lost how it can differentiate between the RSCs that may be targetting the particular NoC.=20 Maybe I've just completely missed something and this is all decided already. If so, sorry, I'm just trying to understand.