From: Sibi Sankar <email@example.com> To: Evan Green <firstname.lastname@example.org> Cc: Rob Herring <email@example.com>, Georgi Djakov <firstname.lastname@example.org>, Bjorn Andersson <email@example.com>, Andy Gross <firstname.lastname@example.org>, LKML <email@example.com>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <firstname.lastname@example.org>, linux-arm-msm <email@example.com>, Mark Rutland <firstname.lastname@example.org>, David Dai <email@example.com>, Saravana Kannan <firstname.lastname@example.org>, Viresh Kumar <email@example.com>, firstname.lastname@example.org Subject: Re: [PATCH v3 2/2] interconnect: qcom: Add OSM L3 interconnect provider support Date: Wed, 08 Jan 2020 01:01:39 +0530 Message-ID: <email@example.com> (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 <firstname.lastname@example.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 <email@example.com> 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 index Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.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] ` <email@example.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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ email@example.com public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git