On 21/04/2023 02:25, Kuogee Hsieh wrote:
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 38 ++-
drivers/gpu
Stop using _sspp_subblk_offset() to get offset of the scaler_blk. Inline
this function and use ctx->cap->sblk->scaler_blk.base directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 27 +++--
1 file changed, 9 insertions(+), 18 deletions(-)
d
The src_blk declares a lame copy of main SSPP register space. It's
offset is always 0. It's length has been fixed to 0x150, while SSPP's
length is now correct. Drop the src_blk and access SSPP registers
without additional subblock lookup.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/
Stop using _sspp_subblk_offset() to get offset of the csc_blk. Inline
this function and use ctx->cap->sblk->csc_blk.base directly.
As this was the last user, drop _sspp_subblk_offset() too.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 43 +---
Rework dpu_hw_sspp.c to access sblk base address directly rather than
getting the sblk address through indirect function call.
Dmitry Baryshkov (3):
drm/msm/dpu: drop SSPP's SRC subblock
drm/msm/dpu: access QSEED registers directly
drm/msm/dpu: access CSC/CSC10 registers directly
.../gpu/d
On 4/21/2023 1:53 PM, Marijn Suijten wrote:
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their ID to a dpu_hw_xxx_init() function which
uses an _xxx_offset() helper to search for and find the exact same
catalog pointer again to initialize the b
On 22/04/2023 02:16, Kuogee Hsieh wrote:
On 4/21/2023 4:11 PM, Dmitry Baryshkov wrote:
On 22/04/2023 02:08, Kuogee Hsieh wrote:
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee
On 4/21/2023 4:11 PM, Dmitry Baryshkov wrote:
On 22/04/2023 02:08, Kuogee Hsieh wrote:
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add D
On 22/04/2023 02:08, Kuogee Hsieh wrote:
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necess
On 22/04/2023 01:47, Abhinav Kumar wrote:
Gamma correction blocks (GC) are not used today so lets remove
the usage of DPU_DSPP_GC in the dspp flush to make it easier
to remove GC from the catalog.
We can add this back when GC is properly supported in DPU with
one of the standard DRM properties.
On 22/04/2023 01:47, Abhinav Kumar wrote:
Since Gamma Correction (GC) block is currently unused, drop
related code from the dpu hardware catalog otherwise this
becomes a burden to carry across chipsets in the catalog.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catal
On 4/21/2023 3:16 PM, Dmitry Baryshkov wrote:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary
sub-block and feature flag informatio
Since Gamma Correction (GC) block is currently unused, drop
related code from the dpu hardware catalog otherwise this
becomes a burden to carry across chipsets in the catalog.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 +---
drivers/gpu/drm/msm/disp/dpu1/
Gamma correction blocks (GC) are not used today so lets remove
the usage of DPU_DSPP_GC in the dspp flush to make it easier
to remove GC from the catalog.
We can add this back when GC is properly supported in DPU with
one of the standard DRM properties.
Signed-off-by: Abhinav Kumar
---
drivers/
On 22/04/2023 01:34, Abhinav Kumar wrote:
On 4/20/2023 3:52 PM, Dmitry Baryshkov wrote:
On 20/04/2023 22:56, Marijn Suijten wrote:
On 2023-04-20 22:51:22, Dmitry Baryshkov wrote:
On 20/04/2023 22:47, Abhinav Kumar wrote:
On 4/20/2023 11:01 AM, Dmitry Baryshkov wrote:
On 20/04/2023 04:36,
On 4/20/2023 3:52 PM, Dmitry Baryshkov wrote:
On 20/04/2023 22:56, Marijn Suijten wrote:
On 2023-04-20 22:51:22, Dmitry Baryshkov wrote:
On 20/04/2023 22:47, Abhinav Kumar wrote:
On 4/20/2023 11:01 AM, Dmitry Baryshkov wrote:
On 20/04/2023 04:36, Konrad Dybcio wrote:
On 20.04.2023 03:
On 22/04/2023 01:05, Kuogee Hsieh wrote:
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary
sub-block and feature flag information.
Each display compression engine (DCE) contains
On 4/20/2023 5:07 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary
sub-block and feature flag information.
Each display compression engine (DCE) contains dual hard
slice DSC encoders so both sha
On 22/04/2023 00:30, Kuogee Hsieh wrote:
On 4/21/2023 2:13 PM, Dmitry Baryshkov wrote:
On 22/04/2023 00:07, Kuogee Hsieh wrote:
On 4/20/2023 5:27 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
During DSC preparation, add run time calculation to figure out what
usage mo
On 4/21/2023 2:13 PM, Dmitry Baryshkov wrote:
On 22/04/2023 00:07, Kuogee Hsieh wrote:
On 4/20/2023 5:27 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
During DSC preparation, add run time calculation to figure out what
usage modes, split mode and merge mode, is going
On 22/04/2023 00:07, Kuogee Hsieh wrote:
On 4/20/2023 5:27 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
During DSC preparation, add run time calculation to figure out what
usage modes, split mode and merge mode, is going to be setup.
Signed-off-by: Kuogee Hsieh
---
On 4/20/2023 5:27 PM, Dmitry Baryshkov wrote:
On 21/04/2023 02:25, Kuogee Hsieh wrote:
During DSC preparation, add run time calculation to figure out what
usage modes, split mode and merge mode, is going to be setup.
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder
The Resource Manager already iterates over all available blocks from the
catalog, only to pass their ID to a dpu_hw_xxx_init() function which
uses an _xxx_offset() helper to search for and find the exact same
catalog pointer again to initialize the block with, fallible error
handling and all.
Inst
Doing a for loop in every DPU HW block driver init to find a catalog
entry matching the given ID is rather useless if the init function
called by RM already has that catalog entry pointer, and uses exactly
its ID to drive this init and for loop. Remove all that machinery to
drop quite some lines o
Some of these members were initialized while never read, while others
were not even assigned any pointer value at all. Drop them to save some
space, and above all confusion when looking at or accidentally
dereferencing these members.
Signed-off-by: Marijn Suijten
Reviewed-by: Abhinav Kumar
Revi
The WB debug log mask ended up never being assigned, leading to writes
to this block to never be logged even if the mask is enabled in
dpu_hw_util_log_mask via debugfs.
Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback
blocks")
Signed-off-by: Marijn Suijten
Reviewed-by:
dd-support-for-DSC-encoder-v1-2-engine/20230421-072925
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/1682033114-28483-2-git-send-email-quic_khsieh%40quicinc.com
patch subject: [PATCH v1 1/5] drm/msm/dpu: add support for DSC encoder v1.2
eng
On 4/21/2023 7:56 AM, Srinivas Kandagatla wrote:
while binding the code always registers a audio driver, however there
is no corresponding unregistration done in unbind. This leads to multiple
redundant audio platform devices if dp_display_bind and dp_display_unbind
happens multiple times duri
On 21/04/2023 20:46, Abhinav Kumar wrote:
On 4/20/2023 3:25 PM, Dmitry Baryshkov wrote:
The regdma is currently not used by the current driver. We have no way
to practically verify that the regdma is described correctly. Drop it
now.
Signed-off-by: Dmitry Baryshkov
---
As Marijn noted, per
On 21/04/2023 10:35, Marijn Suijten wrote:
On 2023-04-21 01:25:58, Dmitry Baryshkov wrote:
Stop mapping the regdma region. The driver does not support regdma.
Signed-off-by: Dmitry Baryshkov
Should you add a third patch to remove this from dt-bindings?
(msm8998 has it in both dpu and mdss fi
On 4/20/2023 3:25 PM, Dmitry Baryshkov wrote:
Stop mapping the regdma region. The driver does not support regdma.
Signed-off-by: Dmitry Baryshkov
---
As pointed out by Marijn, the binding can be dropped too but for this
change,
Reviewed-by: Abhinav Kumar
On 4/20/2023 3:25 PM, Dmitry Baryshkov wrote:
The regdma is currently not used by the current driver. We have no way
to practically verify that the regdma is described correctly. Drop it
now.
Signed-off-by: Dmitry Baryshkov
---
As Marijn noted, perhaps we can drop even DPU_CLK_CTRL_REG_DMA
On 21/04/2023 19:27, Mark Yacoub wrote:
From: Mark Yacoub
Nit: is there a reason for this header? My first impression is that it
matches your outgoing name & email address and as such is not necessary.
Nit#2: subject should mention 'Key', as you are creating a property for
the key.
[Wh
Le ven. 21 avr. 2023 à 15:27, Hans Verkuil a écrit :
>
> Hi Arnaud,
>
> Some review comments below...
Hi Hans,
For context, I first based my work on the fbdev driver from Qualcomm a
few years ago, on our own CEC framework which does not implement any
CEC protocol logic (as android does). At the
From: Mark Yacoub
[Why]
To support protected content, the driver requires a key.
Currently, it's being injected from debugfs, which is not super useful
to run a user space in the wild.
[How]
When the key is needed, fetch the "Content Protection Property" on the
connector and get the key blob. Ve
From: Mark Yacoub
[Why]
User space might need to inject data into the kernel without allowing it
to be read again by any user space.
An example of where this is particularly useful is secret keys fetched
by user space and injected into the kernel to enable content protection.
[How]
Create a DRM_
From: Mark Yacoub
[Why]
To enable Protected Content, some drivers require a key to be injected
from user space to enable HDCP on the connector.
[How]
Create new "Content Protection Property" of type "Blob"
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/drm_atomic_uapi.c | 9 +
include
From: Mark Yacoub
Hi all,
Following up to my HDCP patches[1], this series introduces a new connector prop
that is required to push the key from user space to a driver that requires a
key from user space to enable HDCP on a connector.
Patch 1 is the WO blob patch to protect the key
Patch 2 is
From: Mark Yacoub
[Why]
To support protected content, the driver requires a key.
Currently, it's being injected from debugfs, which is not super useful
to run a user space in the wild.
[How]
When the key is needed, fetch the "Content Protection Property" on the
connector and get the key blob. Ve
From: Mark Yacoub
[Why]
To enable Protected Content, some drivers require a key to be injected
from user space to enable HDCP on the connector.
[How]
Create new "Content Protection Property" of type "Blob"
Signed-off-by: Mark Yacoub
---
drivers/gpu/drm/drm_atomic_uapi.c | 9 +
include
From: Mark Yacoub
Hi all,
Following up to my HDCP patches[1], this series introduces a new connector prop
that is required to push the key from user space to a driver that requires a
key from user space to enable HDCP on a connector.
Patch 1 is the DRM code that creates this prop.
Patch 2 is
while binding the code always registers a audio driver, however there
is no corresponding unregistration done in unbind. This leads to multiple
redundant audio platform devices if dp_display_bind and dp_display_unbind
happens multiple times during startup. On X13s platform this resulted in
6 to 9 a
On Fri, Apr 21, 2023 at 4:59 AM Tvrtko Ursulin
wrote:
>
>
> On 21/04/2023 12:45, Emil Velikov wrote:
> > On Fri, 21 Apr 2023 at 12:23, Tvrtko Ursulin
> > wrote:
> >
> >> On 21/04/2023 11:26, Emil Velikov wrote:
> >>> On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
> >>>
> +/**
> + * enu
On Fri, Apr 21, 2023 at 2:33 AM Emil Velikov wrote:
>
> Greeting all,
>
> Sorry for the delay - Easter Holidays, food coma and all that :-)
>
> On Tue, 18 Apr 2023 at 15:31, Rob Clark wrote:
> >
> > On Tue, Apr 18, 2023 at 1:34 AM Daniel Vetter wrote:
> > >
> > > On Tue, Apr 18, 2023 at 09:27:49
Hi Arnaud,
Some review comments below...
On 4/18/23 20:10, Arnaud Vrac wrote:
> Some Qualcomm SoCs that support HDMI also support CEC, including MSM8996
> and MSM8998. The hardware block can handle a single CEC logical address
> and broadcast messages.
>
> Port the CEC driver from downstream msm
On Fri, 21 Apr 2023 00:31:15 +0200, Konrad Dybcio wrote:
> Document the SM6375 MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6375-mdss.yaml | 216
> +
> 1 file changed, 216 insertions(+)
>
My bot found errors running 'make DT_CHECKER_
On Fri, 21 Apr 2023 00:31:13 +0200, Konrad Dybcio wrote:
> Document the SM6350 MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-mdss.yaml | 214
> +
> 1 file changed, 214 insertions(+)
>
My bot found errors running 'make DT_CHECKER_
On 21/04/2023 12:45, Emil Velikov wrote:
On Fri, 21 Apr 2023 at 12:23, Tvrtko Ursulin
wrote:
On 21/04/2023 11:26, Emil Velikov wrote:
On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
+/**
+ * enum drm_gem_object_status - bitmask of object state for fdinfo reporting
+ * @DRM_GEM_OBJECT_RESI
On Fri, 21 Apr 2023 at 12:23, Tvrtko Ursulin
wrote:
> On 21/04/2023 11:26, Emil Velikov wrote:
> > On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
> >
> >> +/**
> >> + * enum drm_gem_object_status - bitmask of object state for fdinfo
> >> reporting
> >> + * @DRM_GEM_OBJECT_RESIDENT: object is re
On 21/04/2023 11:26, Emil Velikov wrote:
On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
+/**
+ * enum drm_gem_object_status - bitmask of object state for fdinfo reporting
+ * @DRM_GEM_OBJECT_RESIDENT: object is resident in memory (ie. not unpinned)
+ * @DRM_GEM_OBJECT_PURGEABLE: object marke
On Wed, 12 Apr 2023 at 23:43, Rob Clark wrote:
> +/**
> + * enum drm_gem_object_status - bitmask of object state for fdinfo reporting
> + * @DRM_GEM_OBJECT_RESIDENT: object is resident in memory (ie. not unpinned)
> + * @DRM_GEM_OBJECT_PURGEABLE: object marked as purgeable by userspace
> + *
> +
Greeting all,
Sorry for the delay - Easter Holidays, food coma and all that :-)
On Tue, 18 Apr 2023 at 15:31, Rob Clark wrote:
>
> On Tue, Apr 18, 2023 at 1:34 AM Daniel Vetter wrote:
> >
> > On Tue, Apr 18, 2023 at 09:27:49AM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 17/04/2023 21:12, Rob Cl
On 2023-04-21 01:25:58, Dmitry Baryshkov wrote:
> Stop mapping the regdma region. The driver does not support regdma.
>
> Signed-off-by: Dmitry Baryshkov
Should you add a third patch to remove this from dt-bindings?
(msm8998 has it in both dpu and mdss files)
Regardless, the patch itself is:
R
On 2023-04-21 01:25:57, Dmitry Baryshkov wrote:
> The regdma is currently not used by the current driver. We have no way
> to practically verify that the regdma is described correctly. Drop it
> now.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 1 -
54 matches
Mail list logo
