Hi,
On Wed, Jan 9, 2019 at 9:52 AM Jayant Shekhar <jshekhar@xxxxxxxxxxxxxx> wrote:
> @@ -127,7 +153,11 @@ static int dpu_mdss_enable(struct msm_mdss *mdss)
> {
> struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
> struct dss_module_power *mp = &dpu_mdss->mp;
> - int ret;
> + int ret, i;
> + u64 avg_bw = dpu_mdss->num_paths ? MAX_BW / dpu_mdss->num_paths : 0;
> +
> + for (i = 0; i < dpu_mdss->num_paths; i++)
> + icc_set(dpu_mdss->path[i], avg_bw, kBps_to_icc(MAX_BW));
You'll need to change icc_set() here to icc_set_bw() to match v13, AKA:
- https://patchwork.kernel.org/patch/10766335/
- https://lkml.kernel.org/r/20190116161103.6937-2-georgi.djakov@xxxxxxxxxx
> ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, true);
> if (ret)
> @@ -140,12 +170,15 @@ static int dpu_mdss_disable(struct msm_mdss *mdss)
> {
> struct dpu_mdss *dpu_mdss = to_dpu_mdss(mdss);
> struct dss_module_power *mp = &dpu_mdss->mp;
> - int ret;
> + int ret, i;
>
> ret = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
> if (ret)
> DPU_ERROR("clock disable failed, ret:%d\n", ret);
>
> + for (i = 0; i < dpu_mdss->num_paths; i++)
> + icc_set(dpu_mdss->path[i], 0, 0);
This will also need to change to icc_set_bw()
I'm curious what the plan is for landing this series. Sean / Rob /
Gerogi: do you have any preference? Options I'd imagine:
A) Wait until interconnect lands (in 5.1?) and land this through
drm-misc / msm-next in the version after (5.2?)
B) Georgi provides an immutable branch for interconnect when his lands
(assuming he's sending his stuff upstream via pull request) and that
immutable branch gets merged into the the relevant drm tree.
C) Sean and/or Rob Acks this series and indicates that it should go in
through Gerogi's tree (probably only works if Georgi plans to send a
pull request). If we're going this route then (IIUC) we'd want to
land this in Gerogi's tree sooner rather than later so it can get some
bake time in linux-next (we've been baking it in Chrome OS for a
while, but nice to see it in linux-next too).
Does anyone have a preference? It's be nice if whoever is planning to
land this could indicate whether they'd prefer Jayant send a new
version to handle the API change or if the relevant maintainer can
just do the fixup when the patch lands.
Thanks!
-Doug
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
