On 7/27/2023 6:46 PM, Rob Herring wrote:
On Thu, 27 Jul 2023 18:13:33 +0530, Rohit Agarwal wrote:
Update the RPMHPD references with new bindings defined in rpmhpd.h
for Qualcomm SoCs SM8[2345]50.
Signed-off-by: Rohit Agarwal
---
Changes in v2:
- Removed the unnecessary inclusion of
Please resend under the correct email.
Thanks,
Jessica Zhang
On 7/27/2023 6:12 PM, parellan wrote:
From: Paloma Arellano
Enable display compression (DSC v1.2) and CMD mode for 1080x2400 Visionox
VTDR6130 AMOLED DSI panel. In addition, this patch will set the default
to command mode with DSC
Enable display compression (DSC v1.2) and CMD mode for 1080x2400 Visionox
VTDR6130 AMOLED DSI panel. In addition, this patch will set the default
to command mode with DSC enabled.
Note: This patch has only been validated DSC over command mode as DSC over
video mode has never been validated for
From: Paloma Arellano
Enable display compression (DSC v1.2) and CMD mode for 1080x2400 Visionox
VTDR6130 AMOLED DSI panel. In addition, this patch will set the default
to command mode with DSC enabled.
Note: This patch has only been validated DSC over command mode as DSC over
video mode has
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> Let's just stash it in adreno_platform_config rather than looking it up
> in N different places.
This leaves me with the feeling that we are abusing the
dev->platform_data, but we were doing it anyway even before the patch.
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> Sometimes it is useful to know the sub-generation (or "family"). And in
> any case, this helps us get away from infering the generation from the
Nit: inferring
> numerical chip-id.
>
> v2: Fix is_a2xx() typo
>
>
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> This simplifies the code.
>
> v2: Use a table of structs instead of flat uint32_t[]
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 171 ++---
>
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> There are cases where there are differences due to SoC integration.
> Such as cache-coherency support, and (in the next patch) e-fuse to
> speedbin mappings.
>
> Signed-off-by: Rob Clark
> ---
>
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> It is better to explicitly list it. With the move to opaque chip-id's
> for future devices, we should avoid trying to infer things like
> generation from the numerical value.
>
> Signed-off-by: Rob Clark
> Reviewed-by:
On Fri, 28 Jul 2023 at 00:22, Rob Clark wrote:
>
> From: Rob Clark
>
> Even in the ocmem case, the allocated ocmem buffer size should match the
> requested size.
>
> v2: Move stray hunk to previous patch, make OCMEM size mismatch an error
> condition.
>
> Signed-off-by: Rob Clark
On Fri, 28 Jul 2023 at 00:13, Rob Clark wrote:
>
> On Wed, Jul 26, 2023 at 3:33 PM Dmitry Baryshkov
> wrote:
> >
> > On Thu, 27 Jul 2023 at 01:04, Rob Clark wrote:
> > >
> > > On Wed, Jul 26, 2023 at 2:43 PM Dmitry Baryshkov
> > > wrote:
> > > >
> > > > On 26/07/2023 23:11, Rob Clark wrote:
>
From: Rob Clark
Since the revision becomes an opaque identifier with future GPUs, move
away from treating different ranges of bits as having a given meaning.
This means that we need to explicitly list different patch revisions in
the device table.
Signed-off-by: Rob Clark
---
From: Rob Clark
Upcoming GPUs use an opaque chip-id for identifying the GPU.
Signed-off-by: Rob Clark
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
From: Rob Clark
This is used in a few places, including one that is parsed by userspace
tools. So let's standardize it a bit better.
Signed-off-by: Rob Clark
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 8 +++-
drivers/gpu/drm/msm/adreno/adreno_gpu.c
From: Rob Clark
Let's just stash it in adreno_platform_config rather than looking it up
in N different places.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15 +++
drivers/gpu/drm/msm/adreno/adreno_device.c | 5 +++--
From: Rob Clark
Sometimes it is useful to know the sub-generation (or "family"). And in
any case, this helps us get away from infering the generation from the
numerical chip-id.
v2: Fix is_a2xx() typo
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 31
From: Rob Clark
All of these are derivatives of a630.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git
From: Rob Clark
This simplifies the code.
v2: Use a table of structs instead of flat uint32_t[]
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 171 ++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 51 ++
From: Rob Clark
There are cases where there are differences due to SoC integration.
Such as cache-coherency support, and (in the next patch) e-fuse to
speedbin mappings.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 34 +++---
From: Rob Clark
It is better to explicitly list it. With the move to opaque chip-id's
for future devices, we should avoid trying to infer things like
generation from the numerical value.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 23
From: Rob Clark
Rather than just open coding a list of gpu-id matches.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
From: Rob Clark
This just duplicates what is in adreno_info, and can cause confusion if
used before it is set.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1
From: Rob Clark
Even in the ocmem case, the allocated ocmem buffer size should match the
requested size.
v2: Move stray hunk to previous patch, make OCMEM size mismatch an error
condition.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +-
From: Rob Clark
No real need to have marketing names in the kernel.
Signed-off-by: Rob Clark
Reviewed-by: Konrad Dybcio
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 25 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 13 +--
From: Rob Clark
Downstream seems to be moving to using the chip_id as simply an opaque
identifier, and if we want to avoid headaches with userspace mesa
supporting both kgsl and upstream, we should move away from the
assumption that certain bits in the chip_id have a specific meaning.
v2 adds a
On Wed, Jul 26, 2023 at 3:33 PM Dmitry Baryshkov
wrote:
>
> On Thu, 27 Jul 2023 at 01:04, Rob Clark wrote:
> >
> > On Wed, Jul 26, 2023 at 2:43 PM Dmitry Baryshkov
> > wrote:
> > >
> > > On 26/07/2023 23:11, Rob Clark wrote:
> > > > On Wed, Jul 26, 2023 at 1:00 PM Dmitry Baryshkov
> > > >
On 2023-07-27 22:22:20, Marijn Suijten wrote:
> On 2023-07-27 19:21:04, Dmitry Baryshkov wrote:
> > As the INTF is fixed at the encoder creation time, we can move the
> > check whether INTF supports tearchck to dpu_encoder_phys_cmd_init().
> > This function can return an error if INTF doesn't have
On 2023-07-27 23:16:22, Dmitry Baryshkov wrote:
> On 27/07/2023 23:14, Marijn Suijten wrote:
> > On 2023-07-27 19:21:02, Dmitry Baryshkov wrote:
> >> Replace the only user of the DPU_INTF_TE feature flag with the direct
> >> DPU version comparison.
> >>
> >> Signed-off-by: Dmitry Baryshkov
> >
>
On 2023-07-27 19:21:04, Dmitry Baryshkov wrote:
> As the INTF is fixed at the encoder creation time, we can move the
> check whether INTF supports tearchck to dpu_encoder_phys_cmd_init().
> This function can return an error if INTF doesn't have required feature.
> Performing this check in
On 2023-07-27 19:21:03, Dmitry Baryshkov wrote:
> The dpu_encoder_phys_cmd_te_rd_ptr_irq() function uses neither hw_intf
> nor hw_pp data, so we can drop the corresponding check.
Maybe because it would catch "bogus" interrupts, or these blocks are
accessed somewhere down the line in the vblank
On 27/07/2023 23:14, Marijn Suijten wrote:
On 2023-07-27 19:21:02, Dmitry Baryshkov wrote:
Replace the only user of the DPU_INTF_TE feature flag with the direct
DPU version comparison.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
---
On 2023-07-27 19:21:02, Dmitry Baryshkov wrote:
> Replace the only user of the DPU_INTF_TE feature flag with the direct
> DPU version comparison.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 ++--
>
On 2023-07-27 19:21:01, Dmitry Baryshkov wrote:
> The DPU_INTF_TE bit is set for all INTF blocks on DPU >= 5.0, however
> only INTF_1 and INTF_2 actually support tearing control. Rather than
> trying to fix the DPU_INTF_TE, check for the presense of the
I would more exactly expand "fix" to
On 2023-07-27 19:21:00, Dmitry Baryshkov wrote:
> Inline the _setup_intf_ops() function, it makes it easier to handle
> different conditions involving INTF configuration.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 47
On 2023-07-27 19:20:59, Dmitry Baryshkov wrote:
> The DPU_PINGPONG_TE flag became unused, we can drop it now.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4
On 2023-07-27 19:20:58, Dmitry Baryshkov wrote:
> The DPU_PINGPONG_TE bit is set for all PINGPONG blocks on DPU < 5.0.
> Rather than checking for the flag, check for the presense of the
> corresponding interrupt line.
>
> Signed-off-by: Dmitry Baryshkov
> ---
>
On 2023-07-27 19:20:58, Dmitry Baryshkov wrote:
> The DPU_PINGPONG_TE bit is set for all PINGPONG blocks on DPU < 5.0.
> Rather than checking for the flag, check for the presense of the
> corresponding interrupt line.
>
> Signed-off-by: Dmitry Baryshkov
That's a smart use of the interrupt
On 2023-07-27 22:51:32, Dmitry Baryshkov wrote:
> On 27/07/2023 22:41, Marijn Suijten wrote:
> > On 2023-07-27 22:34:59, Dmitry Baryshkov wrote:
> >> On 27/07/2023 22:29, Marijn Suijten wrote:
> >>> On 2023-07-27 18:04:54, Dmitry Baryshkov wrote:
> In preparation to reworking the IRQ indices,
Title nit: How about making this "UP by 1"?
On 2023-07-27 18:04:55, Dmitry Baryshkov wrote:
> In order to simplify IRQ declarations, shift IRQ indices by 1. This
Same here, UP by one.
> makes 0 the 'no IRQ' value. Thanks to this change, we do no longer have
> to explicitly set the 'no
On 27/07/2023 22:41, Marijn Suijten wrote:
On 2023-07-27 22:34:59, Dmitry Baryshkov wrote:
On 27/07/2023 22:29, Marijn Suijten wrote:
On 2023-07-27 18:04:54, Dmitry Baryshkov wrote:
In preparation to reworking the IRQ indices, move irq_tbl access to
separate helper.
I am not seeing the
On 2023-07-27 22:34:59, Dmitry Baryshkov wrote:
> On 27/07/2023 22:29, Marijn Suijten wrote:
> > On 2023-07-27 18:04:54, Dmitry Baryshkov wrote:
> >> In preparation to reworking the IRQ indices, move irq_tbl access to
> >> separate helper.
> >
> > I am not seeing the advantage of the helper, but
On 27/07/2023 22:29, Marijn Suijten wrote:
On 2023-07-27 18:04:54, Dmitry Baryshkov wrote:
In preparation to reworking the IRQ indices, move irq_tbl access to
separate helper.
I am not seeing the advantage of the helper, but making every function
look up dpu_kms->hw_intr->irq_tbl[irq_idx]
On 2023-07-27 18:04:54, Dmitry Baryshkov wrote:
> In preparation to reworking the IRQ indices, move irq_tbl access to
> separate helper.
I am not seeing the advantage of the helper, but making every function
look up dpu_kms->hw_intr->irq_tbl[irq_idx] only once and storing that in
a local
On 2023-07-27 18:04:53, Dmitry Baryshkov wrote:
> In preparation of slighly changing IRQ numbering, move DPU_IRQ_REG()
> macro to the dpu_hw_interrupts.h header. Also split the DPU_IRQ_MASK()
> macro into local DPU_IRQ_MASK() and the global DPU_IRQ_OFFSET() macros.
>
> Signed-off-by: Dmitry
On 2023-07-27 18:04:52, Dmitry Baryshkov wrote:
> There is no point in passing the IRQ index to IRQ callbacks, no function
> uses that. Drop it at last.
>
> Signed-off-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 2 +-
>
On 2023-07-27 17:45:38, Dmitry Baryshkov wrote:
> Please exuse me for the spam, I missed the triggered WARN_ON because of
> the dropped patch.
>
> Declaring the mask of supported interrupts proved to be error-prone. It
> is very easy to add a bit with no corresponding backing block or to miss
>
As the INTF is fixed at the encoder creation time, we can move the
check whether INTF supports tearchck to dpu_encoder_phys_cmd_init().
This function can return an error if INTF doesn't have required feature.
Performing this check in dpu_encoder_phys_cmd_tearcheck_config() is less
useful, as this
The DPU_INTF_TE bit is set for all INTF blocks on DPU >= 5.0, however
only INTF_1 and INTF_2 actually support tearing control. Rather than
trying to fix the DPU_INTF_TE, check for the presense of the
corresponding interrupt line.
Signed-off-by: Dmitry Baryshkov
---
The dpu_encoder_phys_cmd_te_rd_ptr_irq() function uses neither hw_intf
nor hw_pp data, so we can drop the corresponding check.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 8
1 file changed, 8 deletions(-)
diff --git
Replace the only user of the DPU_INTF_TE feature flag with the direct
DPU version comparison.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 -
Inline the _setup_intf_ops() function, it makes it easier to handle
different conditions involving INTF configuration.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 47 +
1 file changed, 21 insertions(+), 26 deletions(-)
diff --git
The DPU_PINGPONG_TE flag became unused, we can drop it now.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git
The DPU_PINGPONG_TE bit is set for all PINGPONG blocks on DPU < 5.0.
Rather than checking for the flag, check for the presense of the
corresponding interrupt line.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 2 +-
1 file changed, 1 insertion(+), 1
Drop two feature flags, DPU_INTF_TE and DPU_PINGPONG_TE, in favour of
performing the MDSS revision checks instead.
Dependencies: [1], [2]
[1] https://patchwork.freedesktop.org/series/118088/
[2] https://patchwork.freedesktop.org/series/118836/
Dmitry Baryshkov (7):
drm/msm/dpu: enable
On 27/07/2023 18:24, Abhinav Kumar wrote:
On 7/27/2023 1:39 AM, Dmitry Baryshkov wrote:
On Thu, 27 Jul 2023 at 02:20, Abhinav Kumar
wrote:
On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
Switch to using data from MDSS driver to program the SSPP fetch and
UBWC
configuration.
On 7/27/2023 1:39 AM, Dmitry Baryshkov wrote:
On Thu, 27 Jul 2023 at 02:20, Abhinav Kumar wrote:
On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
Switch to using data from MDSS driver to program the SSPP fetch and UBWC
configuration.
Signed-off-by: Dmitry Baryshkov
---
In order to simplify IRQ declarations, shift IRQ indices by 1. This
makes 0 the 'no IRQ' value. Thanks to this change, we do no longer have
to explicitly set the 'no interrupt' fields in catalog structures.
Signed-off-by: Dmitry Baryshkov
---
.../msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4
In preparation of slighly changing IRQ numbering, move DPU_IRQ_REG()
macro to the dpu_hw_interrupts.h header. Also split the DPU_IRQ_MASK()
macro into local DPU_IRQ_MASK() and the global DPU_IRQ_OFFSET() macros.
Signed-off-by: Dmitry Baryshkov
---
In preparation to reworking the IRQ indices, move irq_tbl access to
separate helper.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 48 +--
.../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 12 +++--
2 files changed, 41 insertions(+), 19
Having an explicit init of interrupt fields to -1 for not existing IRQs
makes it easier to forget and/or miss such initialisation, resulting in
a wrong interrupt definition.
Instead shift all IRQ indices to turn '0' to be the non-existing IRQ.
Dependencies: [1]
[1]
There is no point in passing the IRQ index to IRQ callbacks, no function
uses that. Drop it at last.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 2 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
On Thu, Jul 27, 2023 at 12:51 AM Konrad Dybcio wrote:
>
> On 27.07.2023 00:53, Rob Clark wrote:
> > On Wed, Jul 26, 2023 at 3:33 PM Dmitry Baryshkov
> > wrote:
> >>
> >> On Thu, 27 Jul 2023 at 01:04, Rob Clark wrote:
> >>>
> >>> On Wed, Jul 26, 2023 at 2:43 PM Dmitry Baryshkov
> >>> wrote:
>
The following changes since commit cd036d542afb82adfbbd43c5dbeb7010e8e91ee7:
drm/msm/a6xx: Add A610 speedbin support (2023-06-18 11:35:27 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-fixes-2023-07-27
for you to fetch changes up to
Now as the list of the interrupts is constructed from the catalog
data, drop the mdss_irqs field from catalog.
Reviewed-by: Neil Armstrong
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 8
While reworking interrupts masks, it was easier to keep old
MDP_INTFn_7xxx_INTR and MDP_INTFn_7xxx_TEAR_INTR symbols. Now it is time
to drop them and use unified symbol names.
Reviewed-by: Neil Armstrong
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
Inline __intr_offset(), there is no point in having a separate oneline
function for setting base block address.
Reviewed-by: Neil Armstrong
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 8 +---
1 file changed, 1
Declaring the mask of supported interrupts proved to be error-prone. It
is very easy to add a bit with no corresponding backing block or to miss
the INTF TE bit. Replace this with looping over the enabled INTF blocks
to setup the irq mask.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry
There is no point in having a single enum (and a single array) for both
DPU < 7.0 and DPU >= 7.0 interrupt registers. Instead define a single
enum and two IRQ address arrays.
Reviewed-by: Neil Armstrong
Reviewed-by: Marijn Suijten
Fixes: c7314613226a0 ("drm/msm: Add missing struct identifier")
Please exuse me for the spam, I missed the triggered WARN_ON because of
the dropped patch.
Declaring the mask of supported interrupts proved to be error-prone. It
is very easy to add a bit with no corresponding backing block or to miss
the INTF TE bit. Replace this static configuration with the
On 2023-07-27 16:34:49, Dmitry Baryshkov wrote:
> On 27/07/2023 15:22, Dmitry Baryshkov wrote:
> >
> > On Sun, 23 Jul 2023 18:08:38 +0200, Marijn Suijten wrote:
> >> Bring up the SM6125 DPU now that all preliminary series (such as INTF
> >> TE) have been merged (for me to test the hardware
On 27/07/2023 15:22, Dmitry Baryshkov wrote:
On Sun, 23 Jul 2023 18:08:38 +0200, Marijn Suijten wrote:
Bring up the SM6125 DPU now that all preliminary series (such as INTF
TE) have been merged (for me to test the hardware properly), and most
other conflicting work (barring ongoing catalog
While reworking interrupts masks, it was easier to keep old
MDP_INTFn_7xxx_INTR and MDP_INTFn_7xxx_TEAR_INTR symbols. Now it is time
to drop them and use unified symbol names.
Reviewed-by: Neil Armstrong
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
Declaring the mask of supported interrupts proved to be error-prone. It
is very easy to add a bit with no corresponding backing block or to miss
the INTF TE bit. Replace this with looping over the enabled INTF blocks
to setup the irq mask.
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry
Now as the list of the interrupts is constructed from the catalog
data, drop the mdss_irqs field from catalog.
Reviewed-by: Neil Armstrong
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
.../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 8
There is no point in having a single enum (and a single array) for both
DPU < 7.0 and DPU >= 7.0 interrupt registers. Instead define a single
enum and two IRQ address arrays.
Reviewed-by: Neil Armstrong
Reviewed-by: Marijn Suijten
Fixes: c7314613226a0 ("drm/msm: Add missing struct identifier")
Inline __intr_offset(), there is no point in having a separate oneline
function for setting base block address.
Reviewed-by: Neil Armstrong
Reviewed-by: Marijn Suijten
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 8 +---
1 file changed, 1
Declaring the mask of supported interrupts proved to be error-prone. It
is very easy to add a bit with no corresponding backing block or to miss
the INTF TE bit. Replace this static configuration with the irq mask
calculated from the HW catalog data.
Changes since v2:
- Rebased on top of
On Thu, 27 Jul 2023 18:13:33 +0530, Rohit Agarwal wrote:
> Update the RPMHPD references with new bindings defined in rpmhpd.h
> for Qualcomm SoCs SM8[2345]50.
>
> Signed-off-by: Rohit Agarwal
> ---
>
> Changes in v2:
> - Removed the unnecessary inclusion of header rpmpd.h.
>
> This patch is
Update the RPMHPD references with new bindings defined in rpmhpd.h
for Qualcomm SoCs SM8[2345]50.
Signed-off-by: Rohit Agarwal
---
Changes in v2:
- Removed the unnecessary inclusion of header rpmpd.h.
This patch is dependent on the series that includes the new rpmhpd.h header
On 21/05/2023 20:34, Dmitry Baryshkov wrote:
In case the drm_modeset_register_all() function fails, its error code
will be ignored. Instead make the drm_dev_register() bail out in case of
such an error.
Fixes: 79190ea2658a ("drm: Add callbacks for late registering")
Signed-off-by: Dmitry
On 7/27/2023 6:00 PM, Rohit Agarwal wrote:
On 7/27/2023 5:57 PM, Krzysztof Kozlowski wrote:
On 27/07/2023 14:21, Rohit Agarwal wrote:
https://lore.kernel.org/all/1689744162-9421-1-git-send-email-quic_rohia...@quicinc.com/
Please mention the dependency in patch changelog ---, so it is
On 7/27/2023 5:57 PM, Krzysztof Kozlowski wrote:
On 27/07/2023 14:21, Rohit Agarwal wrote:
https://lore.kernel.org/all/1689744162-9421-1-git-send-email-quic_rohia...@quicinc.com/
Please mention the dependency in patch changelog ---, so it is obvious
for people applying it and also for the
On 7/27/2023 5:54 PM, Dmitry Baryshkov wrote:
On 27/07/2023 15:21, Rohit Agarwal wrote:
On 7/27/2023 5:15 PM, Krzysztof Kozlowski wrote:
On 27/07/2023 13:19, Rohit Agarwal wrote:
On 7/27/2023 4:46 PM, Rob Herring wrote:
On Thu, 27 Jul 2023 14:39:13 +0530, Rohit Agarwal wrote:
Update the
On 27/07/2023 14:21, Rohit Agarwal wrote:
>>> https://lore.kernel.org/all/1689744162-9421-1-git-send-email-quic_rohia...@quicinc.com/
>> Please mention the dependency in patch changelog ---, so it is obvious
>> for people applying it and also for the bot.
> Sure. Will send a cover letter for this
On 27/07/2023 15:21, Rohit Agarwal wrote:
On 7/27/2023 5:15 PM, Krzysztof Kozlowski wrote:
On 27/07/2023 13:19, Rohit Agarwal wrote:
On 7/27/2023 4:46 PM, Rob Herring wrote:
On Thu, 27 Jul 2023 14:39:13 +0530, Rohit Agarwal wrote:
Update the RPMHPD references with new bindings defined in
On Tue, 11 Jul 2023 18:19:58 -0700, Abhinav Kumar wrote:
> With commit dac76a0144d31 ("fetch DPU configuration from match data"),
> dpu core revision was dropped in favor of using the compatible string
> from the device tree to select the dpu catalog being used in the device.
>
> This approach
On Sun, 23 Jul 2023 18:08:38 +0200, Marijn Suijten wrote:
> Bring up the SM6125 DPU now that all preliminary series (such as INTF
> TE) have been merged (for me to test the hardware properly), and most
> other conflicting work (barring ongoing catalog *improvements*) has made
> its way in as
On 7/27/2023 5:15 PM, Krzysztof Kozlowski wrote:
On 27/07/2023 13:19, Rohit Agarwal wrote:
On 7/27/2023 4:46 PM, Rob Herring wrote:
On Thu, 27 Jul 2023 14:39:13 +0530, Rohit Agarwal wrote:
Update the RPMHPD references with new bindings defined in rpmhpd.h
for Qualcomm SoCs SM8[2345]50.
On 27/07/2023 13:19, Rohit Agarwal wrote:
>
> On 7/27/2023 4:46 PM, Rob Herring wrote:
>> On Thu, 27 Jul 2023 14:39:13 +0530, Rohit Agarwal wrote:
>>> Update the RPMHPD references with new bindings defined in rpmhpd.h
>>> for Qualcomm SoCs SM8[2345]50.
>>>
>>> Signed-off-by: Rohit Agarwal
>>>
On 7/27/2023 4:46 PM, Rob Herring wrote:
On Thu, 27 Jul 2023 14:39:13 +0530, Rohit Agarwal wrote:
Update the RPMHPD references with new bindings defined in rpmhpd.h
for Qualcomm SoCs SM8[2345]50.
Signed-off-by: Rohit Agarwal
---
On Thu, 27 Jul 2023 14:39:13 +0530, Rohit Agarwal wrote:
> Update the RPMHPD references with new bindings defined in rpmhpd.h
> for Qualcomm SoCs SM8[2345]50.
>
> Signed-off-by: Rohit Agarwal
> ---
> Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 4 ++--
>
Update the RPMHPD references with new bindings defined in rpmhpd.h
for Qualcomm SoCs SM8[2345]50.
Signed-off-by: Rohit Agarwal
---
Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 4 ++--
Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml | 4 ++--
On Thu, 27 Jul 2023 at 02:20, Abhinav Kumar wrote:
>
>
>
> On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
> > Switch to using data from MDSS driver to program the SSPP fetch and UBWC
> > configuration.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> >
On Thu, 27 Jul 2023 at 02:14, Abhinav Kumar wrote:
>
>
>
> On 7/26/2023 3:58 PM, Dmitry Baryshkov wrote:
> > On Thu, 27 Jul 2023 at 01:30, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 5/21/2023 10:10 AM, Dmitry Baryshkov wrote:
> >>> As we are going to use MDSS data for DPU programming,
On 27.07.2023 00:53, Rob Clark wrote:
> On Wed, Jul 26, 2023 at 3:33 PM Dmitry Baryshkov
> wrote:
>>
>> On Thu, 27 Jul 2023 at 01:04, Rob Clark wrote:
>>>
>>> On Wed, Jul 26, 2023 at 2:43 PM Dmitry Baryshkov
>>> wrote:
On 26/07/2023 23:11, Rob Clark wrote:
> On Wed, Jul 26, 2023
On 7/27/2023 12:38 PM, Pavan Kondeti wrote:
On Thu, Jul 27, 2023 at 12:24:10PM +0530, Rohit Agarwal wrote:
On 7/27/2023 11:06 AM, Pavan Kondeti wrote:
On Thu, Jul 27, 2023 at 10:21:10AM +0530, Rohit Agarwal wrote:
Update the RPMHPD references with new bindings defined in rpmhpd.h
for
On Thu, Jul 27, 2023 at 12:24:10PM +0530, Rohit Agarwal wrote:
>
> On 7/27/2023 11:06 AM, Pavan Kondeti wrote:
> > On Thu, Jul 27, 2023 at 10:21:10AM +0530, Rohit Agarwal wrote:
> > > Update the RPMHPD references with new bindings defined in rpmhpd.h
> > > for Qualcomm SoCs SM8[2345]50.
> > >
>
On 7/27/2023 11:06 AM, Pavan Kondeti wrote:
On Thu, Jul 27, 2023 at 10:21:10AM +0530, Rohit Agarwal wrote:
Update the RPMHPD references with new bindings defined in rpmhpd.h
for Qualcomm SoCs SM8[2345]50.
Signed-off-by: Rohit Agarwal
---
On Thu, 27 Jul 2023 10:21:10 +0530, Rohit Agarwal wrote:
> Update the RPMHPD references with new bindings defined in rpmhpd.h
> for Qualcomm SoCs SM8[2345]50.
>
> Signed-off-by: Rohit Agarwal
> ---
> Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml| 3 ++-
>
99 matches
Mail list logo
