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;
MIME-Version: 1.0
References: <20191118154435.20357-1-sibis@codeaurora.org> <0101016e7f30ad15-18908ef0-a2b9-4a2a-bf32-6cb3aa447b01-000000@us-west-2.amazonses.com>
 <CAE=gft5jGagsFS2yBeJCLt9R26RQjx9bfMxhQu8Jj4uc4ca40w@mail.gmail.com>
 <0101016e83897442-ecc4c00f-c0d1-4c2c-92ed-ce78e65c0935-000000@us-west-2.amazonses.com>
 <0101016eac068d05-761f0d60-b1ef-400f-bf84-3164c2a26d2e-000000@us-west-2.amazonses.com>
 <CAE=gft5cS54qn0JjxO58xL6sFyQk4t=8ofLFWPUSVQ9sdU4XpQ@mail.gmail.com> <b11c2116-f247-17c5-69ca-071183365a01@codeaurora.org>
In-Reply-To: <b11c2116-f247-17c5-69ca-071183365a01@codeaurora.org>
From:   Evan Green <evgreen@chromium.org>
Date:   Tue, 7 Jan 2020 11:14:58 -0800
Message-ID: <CAE=gft6Dr_=zQ1h93qdxzi-GsZv3caddyOGaGQpSi+8BmBSO+Q@mail.gmail.com>
Subject: Re: [PATCH v3 2/2] interconnect: qcom: Add OSM L3 interconnect
 provider support
To:     Sibi Sankar <sibis@codeaurora.org>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Georgi Djakov <georgi.djakov@linaro.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Andy Gross <agross@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        David Dai <daidavid1@codeaurora.org>,
        Saravana Kannan <saravanak@google.com>,
        Viresh Kumar <viresh.kumar@linaro.org>,
        linux-kernel-owner@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Dec 16, 2019 at 10:30 AM Sibi Sankar <sibis@codeaurora.org> wrote:
>
> Hey Evan,
>
> On 12/7/19 12:46 AM, Evan Green wrote:
> > On Wed, Nov 27, 2019 at 12:42 AM Sibi Sankar <sibis@codeaurora.org> wrote:
> >>
> >> Hey Evan/Georgi,
> >>
> >> https://git.linaro.org/people/georgi.djakov/linux.git/commit/?h=icc-dev&id=9197da7d06e88666d1588e3c21a743e60381264d
> >>
> >> With the "Redefine interconnect provider
> >> DT nodes for SDM845" series, wouldn't it
> >> make more sense to define the OSM_L3 icc
> >> nodes in the sdm845.c icc driver and have
> >> the common helpers in osm_l3 driver? Though
> >> we don't plan on linking the OSM L3 nodes
> >> to the other nodes on SDM845/SC7180, we
> >> might have GPU needing to be linked to the
> >> OSM L3 nodes on future SoCs. Let me know
> >> how you want this done.
> >>
> >> Anyway I'll re-spin the series once the
> >> SDM845 icc re-work gets re-posted.
> >
> > I don't have a clear picture of the proposal. You'd put the couple of
> > extra defines in sdm845.c for the new nodes. But then you'd need to do
> > something in icc_set() of sdm845. Is that when you'd call out to the
> > osm_l3 driver?
>
> with sdm845 icc rework "https://patchwork.kernel.org/cover/11293399/"
> osm l3 icc provider needs to know the total number of rsc icc nodes,
> i.e I can define the total number of rsc nodes and continue using the
> same design as v3 since on sdm845/sc7180 gpu is not cache coherent.
>
> or have the osm l3 table population logic and osm icc_set as helpers
> and have it called from the sdm845/sc7180 icc driver so that we would
> be able to link osm_l3 with rsc nodes on future qcom SoCs.

I see, so if we use the same design as v3, then the number of nodes is
established at compile-time, and ends up being specific to sdm845. I'm
fine with either approach, maybe leaning towards the hardcoded
#defines you have now, and waiting to do the refactoring until you
actually have two SoCs that can use this.
-Evan