On Sun, 09 Jan 2022 18:18:13 +0100, David Heidelberg wrote:
> Convert mdp4 binding into yaml format.
>
> Signed-off-by: David Heidelberg
> ---
> .../devicetree/bindings/display/msm/mdp4.txt | 114
> .../devicetree/bindings/display/msm/mdp4.yaml | 124 ++
> 2
On Sun, Jan 09, 2022 at 01:03:47AM +0100, David Heidelberg wrote:
> Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
>
> Other changes:
> - fixed reg-names numbering to match 0..3 instead 0,1,3,4
> - phy part moved into phy/ directory
>
> Signed-off-by: David Heidelberg
> ---
On Sat, Jan 08, 2022 at 08:00:58PM +0100, David Heidelberg wrote:
> Update documentation compatible and checking to comprehend
> both V2 and 6G version bindings.
>
> Following this commit, there will be update for
> compatible string in chipsets dtsi.
>
> Additional changes:
> - switch to
Move handling of VBIF blocks into dpu_rm. This serves the purpose of
unification of handling of all hardware blocks inside the DPU driver.
This removes hand-coded loops in dpu_vbif (which look for necessary VBIF
instance by looping through the dpu_kms->hw_vbif and comparing
vbif_idx).
Now as dpu_hw_intf is not hanled by dpu_rm_get_assigned_resources, there
is no point in embedding the (empty) struct dpu_hw_blk into dpu_hw_intf
(and using typecasts between dpu_hw_blk and dpu_hw_intf). Drop it and
use dpu_hw_intf directly.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen
Using IS_ERR_OR_NULL() together with PTR_ERR() is a typical mistake. If
the value is NULL, then the function will return 0 instead of a proper
return code. Moreover none of dpu_hw_*_init() functions can return NULL.
So, replace all dpu_rm_init()'s IS_ERR_OR_NULL() calls with IS_ERR().
INTF blocks are not really handled by resource manager, they are
assigned at dpu_encoder_setup_display using dpu_encoder_get_intf().
Then this allocation is passed to RM and then returned to then
dpu_encoder.
So allocate them outside of RM and use them directly.
Signed-off-by: Dmitry Baryshkov
Add missing calls to dpu_hw_dspp_destroy() to free resources allocated
for DSPP hardware blocks.
Fixes: e47616df008b ("drm/msm/dpu: add support for color processing blocks in
dpu driver")
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8
INTF blocks are not really handled by resource manager, they are
assigned at dpu_encoder_setup_display using dpu_encoder_get_intf().
Then this allocation is passed to RM and then returned to then
dpu_encoder. So allocate them outside of RM and use them directly.
While we are at it, drop the
No code uses lm_max_width from resource manager, so drop it. Instead of
calculating the lm_max_width, code can use max_mixer_width field from
the hw catalog.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12
On 07/01/2022 04:27, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-01-05 15:10:31)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index bf4d72356a12..2301ac114920 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++
Quoting Dmitry Baryshkov (2022-01-20 23:37:45)
> On Fri, 21 Jan 2022 at 07:30, Stephen Boyd wrote:
> >
> > Quoting Dmitry Baryshkov (2022-01-19 14:16:15)
> > > diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> > > b/drivers/gpu/drm/msm/msm_io_utils.c
> > > index 7b504617833a..5533c87c7158 100644
Hi Jani
On 1/21/2022 1:17 AM, Jani Nikula wrote:
On Thu, 20 Jan 2022, Abhinav Kumar wrote:
Instead of creating an internal encoder for the writeback
connector to satisfy DRM requirements, allow the clients
to pass a real encoder to it by changing the drm_writeback's
encoder to a pointer.
If
On Thu, 20 Jan 2022, Abhinav Kumar wrote:
> Instead of creating an internal encoder for the writeback
> connector to satisfy DRM requirements, allow the clients
> to pass a real encoder to it by changing the drm_writeback's
> encoder to a pointer.
>
> If a real encoder is not passed,
14 matches
Mail list logo
