Quoting Douglas Anderson (2022-05-31 16:01:26)
> 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.
On 5/31/2022 4:01 PM, Douglas Anderson 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.
Hi Doug
On 5/31/2022 4:01 PM, Douglas Anderson 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
On 5/31/2022 5:18 AM, Dmitry Baryshkov wrote:
Replace magic register writes in msm_mdss_enable() with version that
contains less magic and more variable names that can be traced back to
the dpu_hw_catalog or the downstream dtsi files.
Signed-off-by: Dmitry Baryshkov
---
Hi,
On Tue, May 31, 2022 at 2:29 PM Abhinav Kumar wrote:
>
> > @@ -136,6 +178,13 @@ static int msm_mdss_enable(struct msm_mdss *msm_mdss)
> > {
> > int ret;
> >
> > + /*
> > + * Several components have AXI clocks that can only be turned on if
> > + * the interconnect is
Hi Doug
On 5/31/2022 7:28 AM, Douglas Anderson 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
Hi,
On Tue, May 10, 2022 at 12:30 PM Douglas Anderson wrote:
>
> This patch is v3 of the first 2 patches from my RFC series ("drm/dp:
> Improvements
> for DP AUX channel") [1]. I've broken the series in two so we can make
> progress on the two halves separately.
>
> v2 of this series tries to
Maxime,
On Mon, May 23, 2022 at 10:00 AM Doug Anderson wrote:
>
> Hi,
>
> On Sat, May 21, 2022 at 2:17 AM Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Tue, May 10, 2022 at 12:29:43PM -0700, Douglas Anderson wrote:
> > > This adds a devm managed version of drm_bridge_add(). Like other
> > >
On Tue, May 31, 2022 at 1:34 PM Dmitry Baryshkov
wrote:
>
> On Tue, 31 May 2022 at 23:08, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > If a GEM object is allocated, and then exported as a dma-buf fd which is
> > mmap'd before or without the GEM buffer being directly mmap'd, the
> > vma_node
On Mon, May 30, 2022 at 12:34 AM Haowen Bai wrote:
>
> The ctx->hw is dereferencing before null checking, so move
> it after checking.
>
> Signed-off-by: Haowen Bai
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
On Tue, 31 May 2022 at 23:08, Rob Clark wrote:
>
> From: Rob Clark
>
> If a GEM object is allocated, and then exported as a dma-buf fd which is
> mmap'd before or without the GEM buffer being directly mmap'd, the
> vma_node could be unitialized. This leads to a situation where the CPU
> mapping
From: Rob Clark
If a GEM object is allocated, and then exported as a dma-buf fd which is
mmap'd before or without the GEM buffer being directly mmap'd, the
vma_node could be unitialized. This leads to a situation where the CPU
mapping is not correctly torn down in drm_vma_node_unmap().
Fixes:
On 5/24/2022 1:14 AM, Jiapeng Chong wrote:
Eliminate the follow clang warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c:544:33: warning: variable
‘mode’ set but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
Fixes:
On 5/29/2022 7:19 PM, Haowen Bai wrote:
The phys_enc->wb_idx is dereferencing before null checking, so move
it after checking.
Signed-off-by: Haowen Bai
Fixes: d7d0e73f7de33 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
writeback")
Reviewed-by: Abhinav Kumar
---
On Tue, May 31, 2022 at 5:32 AM Daniel Vetter wrote:
>
> On Mon, 30 May 2022 at 17:41, Rob Clark wrote:
> >
> > On Mon, May 30, 2022 at 7:49 AM Daniel Vetter wrote:
> > >
> > > On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
> > > >
> > > > On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
>
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.
Unfortunately, the sc7180 scheme seems like it was a
It was noticed that on sdm845 after an MDSS suspend/resume cycle the
driver can not read HW_REV registers properly (they will return 0
instead). Chaning the "iface" clock from < GCC_DISP_AHB_CLK> to
< DISP_CC_MDSS_AHB_CLK> fixes the issue.
Fixes: 08c2a076d18f ("arm64: dts: qcom: sdm845: Add dpu
On Mon, 30 May 2022 at 17:41, Rob Clark wrote:
>
> On Mon, May 30, 2022 at 7:49 AM Daniel Vetter wrote:
> >
> > On Mon, 30 May 2022 at 15:54, Rob Clark wrote:
> > >
> > > On Mon, May 30, 2022 at 12:26 AM Thomas Zimmermann
> > > wrote:
> > > >
> > > > Hi
> > > >
> > > > Am 29.05.22 um 18:29
Replace magic register writes in msm_mdss_enable() with version that
contains less magic and more variable names that can be traced back to
the dpu_hw_catalog or the downstream dtsi files.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 79 ++
19 matches
Mail list logo
