On Mon, Dec 16, 2019 at 10:30 AM Sibi Sankar <sibis@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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
