From: Sibi Sankar <sibis@codeaurora.org>
To: Evan Green <evgreen@chromium.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
Subject: Re: [PATCH v3 2/2] interconnect: qcom: Add OSM L3 interconnect provider support
Date: Wed, 08 Jan 2020 01:01:39 +0530 [thread overview]
Message-ID: <d2ceee796d27283506311a0b61f80931@codeaurora.org> (raw)
In-Reply-To: <CAE=gft6Dr_=zQ1h93qdxzi-GsZv3caddyOGaGQpSi+8BmBSO+Q@mail.gmail.com>
On 2020-01-08 00:44, Evan Green wrote:
> 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
Thanks will stick to the #defines
for now.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.
next prev parent reply other threads:[~2020-01-07 19:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20191118154435.20357-1-sibis@codeaurora.org>
2019-11-18 15:45 ` [PATCH v3 1/2] dt-bindings: interconnect: Add OSM L3 DT bindings Sibi Sankar
2019-11-19 0:31 ` Stephen Boyd
2019-11-19 10:29 ` sibis
2019-11-18 15:45 ` [PATCH v3 2/2] interconnect: qcom: Add OSM L3 interconnect provider support Sibi Sankar
[not found] ` <0101016e7f30ad15-18908ef0-a2b9-4a2a-bf32-6cb3aa447b01-000000@us-west-2.amazonses.com>
2019-11-18 22:42 ` Evan Green
2019-11-19 12:00 ` sibis
2019-11-27 8:42 ` Sibi Sankar
2019-12-06 19:16 ` Evan Green
2019-12-16 18:30 ` Sibi Sankar
2020-01-07 19:14 ` Evan Green
2020-01-07 19:31 ` Sibi Sankar [this message]
2019-11-21 12:58 ` Georgi Djakov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d2ceee796d27283506311a0b61f80931@codeaurora.org \
--to=sibis@codeaurora.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=daidavid1@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=evgreen@chromium.org \
--cc=georgi.djakov@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel-owner@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=saravanak@google.com \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.