Le jeu. 20 avr. 2023 à 02:30, Dmitry Baryshkov
a écrit :
>
> On 20/04/2023 03:27, Abhinav Kumar wrote:
> >
> >
> > On 4/19/2023 5:21 PM, Dmitry Baryshkov wrote:
> >> On 20/04/2023 03:17, Abhinav Kumar wrote:
> >>>
> >>>
> >>> On 4/19/2023 5:11 PM, Dmitry Baryshkov wrote:
> On 20/04/2023 03:10
On 20.04.2023 03:28, Abhinav Kumar wrote:
>
>
> On 4/19/2023 6:26 PM, Konrad Dybcio wrote:
>>
>>
>> On 20.04.2023 03:25, Dmitry Baryshkov wrote:
>>> On 20/04/2023 04:14, Konrad Dybcio wrote:
Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
dspp sub-block in addition to
On 4/19/2023 6:26 PM, Konrad Dybcio wrote:
On 20.04.2023 03:25, Dmitry Baryshkov wrote:
On 20/04/2023 04:14, Konrad Dybcio wrote:
Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
dspp sub-block in addition to PCCv4. The other block differ a bit
more, but none of them are sup
On 20.04.2023 03:25, Dmitry Baryshkov wrote:
> On 20/04/2023 04:14, Konrad Dybcio wrote:
>> Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
>> dspp sub-block in addition to PCCv4. The other block differ a bit
>> more, but none of them are supported upstream.
>>
>> This series add
On 20/04/2023 04:14, Konrad Dybcio wrote:
Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
dspp sub-block in addition to PCCv4. The other block differ a bit
more, but none of them are supported upstream.
This series adds configures the GCv1.8 on all the relevant SoCs.
Does this
There's a plethora of S(D)M-era SoCs that have a GC v1.8 but never
declared, let alone enabled it. Do so!
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 8
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 8
drivers/gpu/drm
SDM845 was the first SoC to include both PCC v4 and GC v1.8.
We don't currently support any other blocks but the common config
for these two can be reused for a large amount of SoCs.
Rename it to indicate the origin of that combo.
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/c
Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
dspp sub-block in addition to PCCv4. The other block differ a bit
more, but none of them are supported upstream.
This series adds configures the GCv1.8 on all the relevant SoCs.
Signed-off-by: Konrad Dybcio
---
Konrad Dybcio (2):
On 17/04/2023 23:21, Marijn Suijten wrote:
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts.
Signed-off-by: Marijn Suijten
On 17/04/2023 23:21, Marijn Suijten wrote:
These functions are always called consecutively and are best bundled
together for simplicity, especially when the same structure of callbacks
will be replicated later on the interface block for INTF TE support.
The enable_tearcheck(false) case is now rep
On 17/04/2023 23:21, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. Wire up these interrupts
and IRQ masks on all supported hardware.
Signed-off-by: Marijn Suijten
---
.../gpu/drm/msm/disp/dpu1/catalog
On 20/04/2023 04:01, Konrad Dybcio wrote:
On 20.04.2023 03:00, Dmitry Baryshkov wrote:
On 17/04/2023 23:21, Marijn Suijten wrote:
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part o
On 17/04/2023 23:21, Marijn Suijten wrote:
As the INTF block is going to attain more interrupts that don't share
the same MDP_SSPP_TOP0_INTR register, factor out the _reg argument for
the caller to construct the right interrupt index (register and bit
index) to not make the interrupt bit argument
On 20.04.2023 03:00, Dmitry Baryshkov wrote:
> On 17/04/2023 23:21, Marijn Suijten wrote:
>> Since hardware revision 5.0.0 the TE configuration moved out of the
>> PINGPONG block into the INTF block, including vsync source selection
>> that was previously part of MDP top. Writing to the MDP_VSY
On 17/04/2023 23:21, Marijn Suijten wrote:
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
register has no effect anymore and is omitted down
On 17/04/2023 23:21, Marijn Suijten wrote:
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block. Writing these registers has no
effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
flag. This flag is only added to PINGPONG block
On 17/04/2023 23:21, Marijn Suijten wrote:
This autorefresh disable logic in the physical command-mode encoder
consumes three callbacks to the pingpong block, and will explode in
unnecessary complexity when the same callbacks need to be called on the
interface block instead to accommodate INTF TE
On 17/04/2023 23:21, Marijn Suijten wrote:
This callback was migrated from downstream when DPU1 was first
introduced to mainline, but never used by any component. Drop it to
save some lines and unnecessary confusion.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
---
drivers/g
On 17/04/2023 23:21, Marijn Suijten wrote:
A bunch of registers were appended at the end in e.g. 91143873a05d
("drm/msm/dpu: Add MISR register support for interface") rather than
being inserted in a place that maintains numerical sorting. Restore
that.
Assuming that = "sort order":
Reviewed-b
On 17/04/2023 23:21, Marijn Suijten wrote:
A bunch of registers are indented with two extra spaces, looking as if
these are values corresponding to the previous register which is not the
case, rather these are simply also register offsets and should only have
a single space separating them and th
On 17/04/2023 23:21, Marijn Suijten wrote:
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
---
drivers/
On 17/04/2023 23:21, Marijn Suijten wrote:
SM8550 only comes with a DITHER subblock inside the PINGPONG block,
hence the name and a block length of zero. However, the PP_BLK macro
name was typo'd to DIPHER rather than DITHER.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
Signed-of
On 17/04/2023 23:21, Marijn Suijten wrote:
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off
On 17/04/2023 23:21, Marijn Suijten wrote:
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream. Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent confusi
On 17/04/2023 23:21, Marijn Suijten wrote:
Neither of these SoCs has INTF0, they only have a DSI interface on index
1. Stop enabling an interrupt that can't fire.
Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2290
On 20/04/2023 00:26, Konrad Dybcio wrote:
On 19.04.2023 22:11, Jeykumar Sankaran wrote:
On 4/19/2023 12:48 PM, Konrad Dybcio wrote:
On 19.04.2023 21:06, Jeykumar Sankaran wrote:
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), ther
On 18/04/2023 15:10, Konrad Dybcio wrote:
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
Nit: msm_mdss.c is not DPU1.
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation f
On 18/04/2023 15:10, Konrad Dybcio wrote:
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the CPU<->SLAVE_DIS
On 20/04/2023 03:27, Abhinav Kumar wrote:
On 4/19/2023 5:21 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:17, Abhinav Kumar wrote:
On 4/19/2023 5:11 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, A
On 17/04/2023 18:30, Konrad Dybcio wrote:
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the CPU<->SLAVE_DIS
On 4/19/2023 5:21 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:17, Abhinav Kumar wrote:
On 4/19/2023 5:11 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and
On 17/04/2023 18:30, Konrad Dybcio wrote:
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the CPU<->SLAVE_DIS
On 19/04/2023 23:05, Jeykumar Sankaran wrote:
Resending the question as the previous one was sent only to the
freedreno list. Apologies for spamming!
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be han
On 20/04/2023 03:17, Abhinav Kumar wrote:
On 4/19/2023 5:11 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
msm-
On 18/04/2023 21: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-4.4 kernel. It has been tested
on MSM8998 and p
On 4/19/2023 5:11 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
msm-4.4 driver.
Signed-off-by: Arnaud Vrac
-
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
msm-4.4 driver.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 62
+++
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
msm-4.4 driver.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 62
-
1 fi
On 18/04/2023 21:10, Arnaud Vrac wrote:
When edid has been read after hpd, pass it to the cec adapter so that it
can extract the physical address of the device on the cec bus.
Invalidate the physical address when hpd is low.
If there is another bridge in a chain (e.g. display-connector) which
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
msm-4.4 driver.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 62 -
1 file changed, 61 insertions(+), 1 deletion(-)
I have
On 13/04/2023 20:25, Kandpal, Suraj wrote:
Hi,
Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.
Looks Good to me
Reviewed-by: Suraj Kandpal
And gentle reminder for patches 9-12. We would kindly ask to get this
patches reviewed and ready to be merged into drm-intel after -r
On 19/04/2023 17:41, Arnaud Vrac wrote:
This avoids using lm blocks that support DSPP when not needed, to
keep those resources available.
This will break some of the platforms. Consider qcm2290 which has a
single LM with DSPP. So, _dpu_rm_check_lm_and_get_connected_blks should
be performed in
On 19/04/2023 17:41, Arnaud Vrac wrote:
Change lm blocks pairs so that lm blocks with the same features are
paired together:
LM_0 and LM_1 with PP and DSPP
LM_2 and LM_5 with PP
LM_3 and LM_4
This matches the sdm845 configuration and allows using pp or dspp when 2
lm blocks are needed in the to
On 19/04/2023 17:41, Arnaud Vrac wrote:
This matches the value for both fbdev and sde implementations in the
downstream msm-4.4 repository.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Revie
On 19/04/2023 17:41, Arnaud Vrac wrote:
Now that cursor sspp blocks can be used for cursor planes, enable them
on msm8998. The dma sspp blocks that were assigned to cursor planes can
now be used for overlay planes instead.
While the change is correct, there is more about it. Composers, using
u
On 19/04/2023 17:41, Arnaud Vrac wrote:
Override the default max cursor size reported to userspace of 64x64.
MSM8998 hw cursor planes support 512x512 size, and other chips use DMA
SSPPs.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
1 file changed, 3 inserti
On 19/04/2023 17:41, Arnaud Vrac wrote:
Cursor SSPP must be assigned to the last mixer stage, so we assign an
immutable zpos property with a value higher than primary/overlay planes,
to ensure it will always be on top.
The commit does more than is described in the commit message. Let's do
it s
On 19/04/2023 17:41, Arnaud Vrac wrote:
The max_mixer_blendstages hw catalog property represents the number of
planes that can be blended by the lm mixer, excluding the base stage, so
adjust the check for the number of currently assigned planes accordingly.
Signed-off-by: Arnaud Vrac
---
driv
On 19/04/2023 17:41, Arnaud Vrac wrote:
The dpu backend already handles applying alpha to the base stage, so we
can use it to render the bottom plane in all cases. This allows mixing
one additional plane with the hardware mixer.
Signed-off-by: Arnaud Vrac
This might require additional changes
On 19/04/2023 17:41, Arnaud Vrac wrote:
Do not override the hsync/vsync polarity passed by the encoder when
setting up intf timings. The same logic was used in both the encoder and
intf code to set the DP and DSI polarities, so those interfaces are not
impacted. However for HDMI, the polarities w
On 19/04/2023 17:41, Arnaud Vrac wrote:
This avoids using two LMs instead of one when the display width is lower
than the maximum supported value. For example on MSM8996/MSM8998, the
actual maxwidth is 2560, so we would use two LMs for 1280x720 or
1920x1080 resolutions, while one is enough.
Sign
On 19/04/2023 17:41, Arnaud Vrac wrote:
Match the values found in the downstream msm-4.4 kernel sde driver.
Signed-off-by: Arnaud Vrac
Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.
On 19.04.2023 22:11, Jeykumar Sankaran wrote:
>
>
> On 4/19/2023 12:48 PM, Konrad Dybcio wrote:
>>
>>
>> On 19.04.2023 21:06, Jeykumar Sankaran wrote:
>>>
>>>
>>> On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another pa
On 4/19/2023 12:48 PM, Konrad Dybcio wrote:
On 19.04.2023 21:06, Jeykumar Sankaran wrote:
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "re
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from
Resending the question as the previous one was sent only to the
freedreno list. Apologies for spamming!
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely
On 19.04.2023 21:06, Jeykumar Sankaran wrote:
>
>
> On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
>> Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
>> another path that needs to be handled to ensure MDSS functions properly,
>> namely the "reg bus", a.k.a the CPU-MDSS intercon
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be handled to ensure MDSS functions properly,
namely the "reg bus", a.k.a the CPU-MDSS interconnect.
Gating that path may have a variety of effects.. from
On 4/19/2023 2:28 AM, Marijn Suijten wrote:
On 2023-04-18 09:06:34, Abhinav Kumar wrote:
On 4/17/2023 4:14 PM, Marijn Suijten wrote:
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 vi
From: Sean Paul
Add HDCP 1.x support to msm DP bridges using the new HDCP
helpers.
Cc: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Squash [1] into this patch with the following changes (Stephen)
-Update the sc7180 dtsi fi
From: Sean Paul
Add the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller.
Reviewed-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v3:
-Split off into a new patc
From: Sean Paul
Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.
The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or fully
From: Sean Paul
Add the bindings for the MSM DisplayPort HDCP registers
which are required to write the HDCP key into the display controller as
well as the registers to enable HDCP authentication/key
exchange/encryption.
Cc: Rob Herring
Cc: Stephen Boyd
Reviewed-by: Rob Herring
Reviewed-by: D
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Suraj Kandpal
Signed-off-by: Sean Paul
Signed-off-by: Mark Yaco
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
-Non
From: Sean Paul
Update the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value to DESIRED whi
From: Sean Paul
Expand upon the HDCP helper library to manage HDCP enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could make good dec
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, rename to
drm_hdcp_has_changed and return true if the content protection value
is changing and let the driver decide whether a modeset is required or not.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean
From: Sean Paul
Move the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Signed-off-by: Mar
Hi all,
This is v10 of the HDCP patches. The patches are authored by Sean Paul.
I rebased and addressed the review comments in v6-v10.
Main change in v10 is handling the kernel test bot warnings.
Patches 1-4 focus on moving the common HDCP helpers to common DRM.
This introduces a slight change
On Wed, Apr 19, 2023 at 6:36 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 15:56, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 1:53 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 17/04/2023 21:12, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> Normally this would be the same information that
This avoids using lm blocks that support DSPP when not needed, to
keep those resources available.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/ms
Change lm blocks pairs so that lm blocks with the same features are
paired together:
LM_0 and LM_1 with PP and DSPP
LM_2 and LM_5 with PP
LM_3 and LM_4
This matches the sdm845 configuration and allows using pp or dspp when 2
lm blocks are needed in the topology. In the previous config the
reserva
Cursor SSPP must be assigned to the last mixer stage, so we assign an
immutable zpos property with a value higher than primary/overlay planes,
to ensure it will always be on top.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 19 ++-
drivers/gpu/drm/ms
The dpu backend already handles applying alpha to the base stage, so we
can use it to render the bottom plane in all cases. This allows mixing
one additional plane with the hardware mixer.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
1 file changed, 1 insertio
Do not override the hsync/vsync polarity passed by the encoder when
setting up intf timings. The same logic was used in both the encoder and
intf code to set the DP and DSI polarities, so those interfaces are not
impacted. However for HDMI, the polarities were overriden to static
values based on th
Override the default max cursor size reported to userspace of 64x64.
MSM8998 hw cursor planes support 512x512 size, and other chips use DMA
SSPPs.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dis
This matches the value for both fbdev and sde implementations in the
downstream msm-4.4 repository.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog
The max_mixer_blendstages hw catalog property represents the number of
planes that can be blended by the lm mixer, excluding the base stage, so
adjust the check for the number of currently assigned planes accordingly.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 6 +
Match the values found in the downstream msm-4.4 kernel sde driver.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 8
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 15 +--
2 files changed, 9 insertions(+), 14 deletions(-
Now that cursor sspp blocks can be used for cursor planes, enable them
on msm8998. The dma sspp blocks that were assigned to cursor planes can
now be used for overlay planes instead.
Signed-off-by: Arnaud Vrac
---
.../drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h| 8 +++--
drivers/gpu/drm/msm
This avoids using two LMs instead of one when the display width is lower
than the maximum supported value. For example on MSM8996/MSM8998, the
actual maxwidth is 2560, so we would use two LMs for 1280x720 or
1920x1080 resolutions, while one is enough.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/d
: e3342532ecd39bbd9c2ab5b9001cec1589bc37e9
change-id: 20230419-dpu-tweaks-5475305621d9
Best regards,
--
Arnaud Vrac
On 18/04/2023 15:56, Rob Clark wrote:
On Tue, Apr 18, 2023 at 1:53 AM Tvrtko Ursulin
wrote:
On 17/04/2023 21:12, Rob Clark wrote:
From: Rob Clark
Normally this would be the same information that can be obtained in
other ways. But in some cases the process opening the drm fd is merely
a
On 2023-04-18 09:06:34, Abhinav Kumar wrote:
>
> On 4/17/2023 4:14 PM, Marijn Suijten wrote:
> > 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 sysfs.
>
> This should be debugf
Several people reported getting multiple membership and election emails
recently for the first time when we flushed the queue of messages which
had been unfortunately held in moderation in the eve...@lists.x.org
mailing list queue. Thanks Luc, Laurent and Harald for getting in touch!
Thanks to oth
88 matches
Mail list logo
