On Wed, 1 Jun 2022 at 20:18, Abhinav Kumar <quic_abhinavk@xxxxxxxxxxx> wrote:
> On 6/1/2022 3:04 AM, Dmitry Baryshkov wrote:
> > On Wed, 1 Jun 2022 at 02:01, Douglas Anderson <dianders@xxxxxxxxxxxx> wrote:
> >>
> >> In commit a670ff578f1f ("drm/msm/dpu: always use mdp device to scale
> >> bandwidth") we fully moved interconnect stuff to the DPU driver. This
> >> had no change for sc7180 but _did_ have an impact for other SoCs. It
> >> made them match the sc7180 scheme.
> >
> > [skipped the description]
> >
> >>
> >> Changes in v2:
> >> - Don't set bandwidth in init.
> >>
> >> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 ----
> >> drivers/gpu/drm/msm/msm_mdss.c | 57 +++++++++++++++++++++++++
> >> 2 files changed, 57 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >> index 2b9d931474e0..3025184053e0 100644
> >> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> >> @@ -49,8 +49,6 @@
> >> #define DPU_DEBUGFS_DIR "msm_dpu"
> >> #define DPU_DEBUGFS_HWMASKNAME "hw_log_mask"
> >>
> >> -#define MIN_IB_BW 400000000ULL /* Min ib vote 400MB */
> >> -
> >> static int dpu_kms_hw_init(struct msm_kms *kms);
> >> static void _dpu_kms_mmu_destroy(struct dpu_kms *dpu_kms);
> >>
> >
> > [skipped]
> >
> >> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> >> index 0454a571adf7..e13c5c12b775 100644
> >> --- a/drivers/gpu/drm/msm/msm_mdss.c
> >> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> >> @@ -5,6 +5,7 @@
> >>
> >> #include <linux/clk.h>
> >> #include <linux/delay.h>
> >> +#include <linux/interconnect.h>
> >> #include <linux/irq.h>
> >> #include <linux/irqchip.h>
> >> #include <linux/irqdesc.h>
> >> @@ -25,6 +26,8 @@
> >> #define UBWC_CTRL_2 0x150
> >> #define UBWC_PREDICTION_MODE 0x154
> >>
> >> +#define MIN_IB_BW 400000000UL /* Min ib vote 400MB */
> >
> > As msm_mdss is now used for both DPU and MDP5 devices, could you
> > please confirm that this value is valid for older devices too? E.g.
> > db410c or 8974
> >
> I need to check with Kalyan on this value (400MB) as I am unable to find
> documentation on this. Will update this thread when I do.
>
> So prior to this change 627dc55c273da ("drm/msm/disp/dpu1: icc path
> needs to be set before dpu runtime resume"), this value was coming from
> the hw catalog
>
> @@ -1191,10 +1193,10 @@ static int __maybe_unused
> dpu_runtime_resume(struct device *dev)
>
> ddev = dpu_kms->dev;
>
> + WARN_ON(!(dpu_kms->num_paths));
> /* Min vote of BW is required before turning on AXI clk */
> for (i = 0; i < dpu_kms->num_paths; i++)
> - icc_set_bw(dpu_kms->path[i], 0,
> - dpu_kms->catalog->perf.min_dram_ib);
> + icc_set_bw(dpu_kms->path[i], 0, Bps_to_icc(MIN_IB_BW));
>
> After this, we moved to a hard-coded value, I am not sure why.
>
> So nothing wrong with this change as such, the only question is whether
> this value is correct for older chips.
>
> But the question here is, are older chips even using icc.
>
> It seems like only sc7180, RB3/RB5 are unless i am mistaken.
We are not using it for msm8916 (but we should most probably). And for
the msm8996 the icc patches were by Yassine.
> So is there really any impact to the older chips with this change.
>
> If not, we should probably let this one go ahead and move back to
> catalog based approach while extending ICC for older chips.
Let's get this sorted out. I'm fine with 400 MBps, if that works for
all chipsets.
--
With best wishes
Dmitry
