On Sat, Dec 02, 2023 at 12:07:49AM +0200, Dmitry Baryshkov wrote:
> The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> encoder for anything other than getting the drm_device instance. The
> function's description talks about checking the writeback connector
> state, not the encod
On Sun, 03 Dec 2023 01:55:52 +0300, 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.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Sun, 3 Dec 2023 03:05:28 +0300, Dmitry Baryshkov wrote:
> The drm_atomic_print_new_state() already prints private object state via
> drm_atomic_private_obj_print_state(). Add private object state dumping
> to __drm_state_dump(), so that it is also included into drm_state_dump()
> output and into
Hi,
On Sun, Dec 03, 2023 at 02:53:13PM +0300, Dmitry Baryshkov wrote:
> Each of connectors and CRTCs used by the DRM device provides debugfs
> directory, which is used by several standard debugfs files and can
> further be extended by the driver. Add such generic debugfs directories
> for encoder.
On Sun, Dec 03, 2023 at 08:10:31PM +0200, Dmitry Baryshkov wrote:
> On Sun, 3 Dec 2023 at 14:15, Simon Ser wrote:
> >
> > On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov
> > wrote:
> >
> > > On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
> > >
> > > > Some drivers support ha
On 2.12.2023 23:42, Dmitry Baryshkov wrote:
> Stop using hand-written reset function for ICC release, use
> devm_of_icc_get() instead.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 2.12.2023 23:42, Dmitry Baryshkov wrote:
> There are just two places where we set the bandwidth: in the resume and
> in the suspend paths. Drop the wrapping function
> msm_mdss_icc_request_bw() and call icc_set_bw() directly.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Konrad Dybcio
On 26.10.2023 21:16, Konrad Dybcio wrote:
>
>
> On 10/23/23 22:20, Rob Clark wrote:
>> On Mon, Oct 23, 2023 at 12:56 PM Konrad Dybcio
>> wrote:
>>>
>>>
>>>
>>> On 10/23/23 21:42, Rob Clark wrote:
On Mon, Oct 23, 2023 at 7:29 AM Konrad Dybcio
wrote:
>
> New GPUs still use the
On Sun, Dec 03, 2023 at 02:43:27PM +0300, Dmitry Baryshkov wrote:
> Greg, could you please ack the last patch to be merged through the
> drm-misc tree? You have acked patch 3, but since that time I've added
> patches 4-6.
That is up to the typec maintainer to ack, not me!
thanks,
greg k-h
On Mon, 4 Dec 2023 at 14:21, Greg Kroah-Hartman
wrote:
>
> On Sun, Dec 03, 2023 at 02:43:27PM +0300, Dmitry Baryshkov wrote:
> > Greg, could you please ack the last patch to be merged through the
> > drm-misc tree? You have acked patch 3, but since that time I've added
> > patches 4-6.
>
> That is
Altough the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI.
Merging it was a fault of mine.
It has neither corresponding open-source userspace implementation nor
the IGT tests coverage. Revert this patchset until userspace obligati
This reverts commit f1e75da5364e780905d9cd6043f9c74cdcf84073.
Altough the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this
This reverts commit 4b64167042927531f4cfaf035b8f88c2f7a05f06.
Altough the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this
This reverts commit 4ba6b7a646321e740c7f2d80c90505019c4e8fce.
Altough the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this
This reverts commit 85863a4e16e77079ee14865905ddc3ef9483a640.
Altough the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this
This reverts commit e86413f5442ee094e66b3e75f2d3419ed0df9520.
Altough the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this
This reverts commit 8283ac7871a959848e09fc6593b8c12b8febfee6.
Altough the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this
This reverts commit e50e5fed41c7eed2db4119645bf3480ec43fec11.
Altough the Solid Fill planes patchset got all reviews and
acknowledgements, it doesn't fulfill requirements for the new uABI. It
has neither corresponding open-source userspace implementation nor the
IGT tests coverage. Reverting this
Acked-by: Simon Ser
On Sun, 03 Dec 2023 14:53:12 +0300, Dmitry Baryshkov wrote:
> Resending, patch 1 needs review from DRM core maintainers, but it got no
> attention since October.
>
> Each of connectors and CRTCs used by the DRM device provides debugfs
> directory, which is used by several standard debugfs files an
On Sun, 03 Dec 2023 14:43:27 +0300, Dmitry Baryshkov wrote:
> Greg, could you please ack the last patch to be merged through the
> drm-misc tree? You have acked patch 3, but since that time I've added
> patches 4-6.
>
> Supporting DP/USB-C can result in a chain of several transparent
> bridges (PH
On Wed, 20 Sep 2023 13:13:58 -0700, Abhinav Kumar wrote:
> While making the changes in [1], it was noted that the documentation
> of the enable_hpd() and disable_hpd() does not make it clear that
> these ops should not try to do hpd state maintenance and should only
> attempt to enable/disable hpd
On Tue, 19 Sep 2023 10:48:12 -0700, Abhinav Kumar wrote:
> drm_bridge_hpd_enable()/drm_bridge_hpd_disable() callbacks call into
> the respective driver's hpd_enable()/hpd_disable() ops. These ops control
> the HPD enable/disable logic which in some cases like MSM can be a
> dedicate hardware block
On Mon, 4 Dec 2023 15:13:47 +0200, Dmitry Baryshkov wrote:
> Altough the Solid Fill planes patchset got all reviews and
> acknowledgements, it doesn't fulfill requirements for the new uABI.
> Merging it was a fault of mine.
>
> It has neither corresponding open-source userspace implementation nor
On 11/29/2023 7:57 PM, Dmitry Baryshkov wrote:
On Wed, 29 Nov 2023 at 22:31, Kuogee Hsieh wrote:
A DCE (Display Compression Engine) contains two DSC hard slice encoders.
Each DCE start with even DSC encoder index followed by an odd DSC encoder
index. Each encoder can work independently. But O
On Mon, 4 Dec 2023 at 18:37, Kuogee Hsieh wrote:
>
>
> On 11/29/2023 7:57 PM, Dmitry Baryshkov wrote:
> > On Wed, 29 Nov 2023 at 22:31, Kuogee Hsieh wrote:
> >> A DCE (Display Compression Engine) contains two DSC hard slice encoders.
> >> Each DCE start with even DSC encoder index followed by an
When pm_runtime_resume_and_get() fails, unlock before returning.
Fixes: 5814b8bf086a ("drm/msm/dp: incorporate pm_runtime framework into DP
driver")
Signed-off-by: Harshit Mogalapalli
---
This is based on static analysis with Smatch. Only compile tested.
---
drivers/gpu/drm/msm/dp/dp_display.c
On 12/3/2023 10:14 AM, Dmitry Baryshkov wrote:
On Sun, 3 Dec 2023 at 16:24, Laurent Pinchart
wrote:
Hi Abhinav,
Thank you for the patch (and thank to Dmitry for pinging me on IRC, this
patch got burried in my inbox).
On Wed, Sep 20, 2023 at 01:13:58PM -0700, Abhinav Kumar wrote:
While ma
Hi Simon
On 12/3/2023 4:15 AM, Simon Ser wrote:
On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov
wrote:
On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
Some drivers support hardware that have optimizations for solid fill
planes. This series aims to expose these capabilit
On 12/4/2023 9:57 AM, Simon Ser wrote:
On Monday, December 4th, 2023 at 18:51, Abhinav Kumar
wrote:
Where are the IGT and userspace for this uAPI addition?
Yes, we made IGT changes to test and validate this. We will post them on
the IGT dev list shortly and CC you.
We do not have a comp
On Monday, December 4th, 2023 at 18:51, Abhinav Kumar
wrote:
> > Where are the IGT and userspace for this uAPI addition?
>
> Yes, we made IGT changes to test and validate this. We will post them on
> the IGT dev list shortly and CC you.
>
> We do not have a compositor change yet for this as we
On 10/3/2023 8:19 PM, Dmitry Baryshkov wrote:
There are no in-kernel users of MSM_ENC_VBLANK wait type. Drop it
together with the corresponding wait_for_vblank callback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 --
.../gpu/drm/msm/disp/dpu1/dp
On 12/3/2023 7:31 PM, Bjorn Andersson wrote:
On Fri, Dec 01, 2023 at 11:43:36AM -0800, Abhinav Kumar wrote:
On 12/1/2023 8:22 AM, Bjorn Andersson wrote:
On Fri, Dec 01, 2023 at 10:34:50AM +0200, Dmitry Baryshkov wrote:
On Fri, 1 Dec 2023 at 05:47, Bjorn Andersson wrote:
On Thu, Nov 30,
On Mon, 4 Dec 2023 at 20:07, Abhinav Kumar wrote:
> On 10/3/2023 8:19 PM, Dmitry Baryshkov wrote:
> > There are no in-kernel users of MSM_ENC_VBLANK wait type. Drop it
> > together with the corresponding wait_for_vblank callback.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/d
On Mon, 04 Dec 2023 15:13:47 +0200, Dmitry Baryshkov wrote:
> Altough the Solid Fill planes patchset got all reviews and
> acknowledgements, it doesn't fulfill requirements for the new uABI.
> Merging it was a fault of mine.
>
> It has neither corresponding open-source userspace implementation nor
On Mon, 4 Dec 2023 at 19:13, Harshit Mogalapalli
wrote:
>
> When pm_runtime_resume_and_get() fails, unlock before returning.
>
> Fixes: 5814b8bf086a ("drm/msm/dp: incorporate pm_runtime framework into DP
> driver")
> Signed-off-by: Harshit Mogalapalli
> ---
> This is based on static analysis wit
On Mon, 04 Dec 2023 09:13:14 -0800, Harshit Mogalapalli wrote:
> When pm_runtime_resume_and_get() fails, unlock before returning.
>
>
Applied, thanks!
[1/1] drm/msm/dp: add a missing unlock in dp_hpd_plug_handle()
https://gitlab.freedesktop.org/lumag/msm/-/commit/801207c18834
Best rega
On 12/4/2023 9:13 AM, Harshit Mogalapalli wrote:
When pm_runtime_resume_and_get() fails, unlock before returning.
Fixes: 5814b8bf086a ("drm/msm/dp: incorporate pm_runtime framework into DP
driver")
Signed-off-by: Harshit Mogalapalli
---
This is based on static analysis with Smatch. Only com
On 12/2/2023 2:42 PM, Dmitry Baryshkov wrote:
Stop using hand-written reset function for ICC release, use
devm_of_icc_get() instead.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_mdss.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
Reviewed-by: A
On 12/2/2023 2:42 PM, Dmitry Baryshkov wrote:
From: Konrad Dybcio
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 s
On 2023-11-14 17:58:30, Jonathan Marek wrote:
> The value returned by msm_dsi_wide_bus_enabled() doesn't match what the
> driver is doing in video mode. Fix that by actually enabling widebus for
> video mode.
>
> Fixes: efcbd6f9cdeb ("drm/msm/dsi: Enable widebus for DSI")
> Signed-off-by: Jonathan
On 12/2/2023 2:42 PM, Dmitry Baryshkov wrote:
There are just two places where we set the bandwidth: in the resume and
in the suspend paths. Drop the wrapping function
msm_mdss_icc_request_bw() and call icc_set_bw() directly.
Signed-off-by: Dmitry Baryshkov
---
Reviewed-by: Abhinav Kumar
On 12/2/2023 2:42 PM, Dmitry Baryshkov 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, fro
On 12/3/2023 3:53 AM, Dmitry Baryshkov wrote:
Now as we have standard per-encoder debugfs directory, move DPU encoder
status file to that directory.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 45 +++--
1 file changed, 6 insertions(+),
On 12/1/2023 3:40 PM, Dmitry Baryshkov wrote:
Three different features, DPU_SSPP_SCALER_QSEED3, QSEED3LITE and QSEED4
are all related to different versions of the same HW scaling block.
Corresponding driver parts use scaler_blk.version to identify the
correct way to program the hardware. In or
On 12/1/2023 3:40 PM, Dmitry Baryshkov wrote:
After folding QSEED3LITE and QSEED4 feature bits into QSEED3_COMPATIBLE
several VIG feature masks became equal. Drop these duplicates.
Signed-off-by: Dmitry Baryshkov
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h| 2 +-
.../gpu/d
A DCE (Display Compression Engine) contains two DSC hard slice
encoders. Each DCE start with even DSC encoder index followed by
an odd DSC encoder index. Each encoder can work independently.
But Only two DSC encoders from same DCE can be paired to work
together to support merge mode. In addition, t
On Tue, 5 Dec 2023 at 01:36, Abhinav Kumar wrote:
>
>
>
> On 12/3/2023 3:53 AM, Dmitry Baryshkov wrote:
> > Now as we have standard per-encoder debugfs directory, move DPU encoder
> > status file to that directory.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/msm/disp/dpu
On Tue, 5 Dec 2023 at 01:55, Kuogee Hsieh wrote:
>
> A DCE (Display Compression Engine) contains two DSC hard slice
> encoders. Each DCE start with even DSC encoder index followed by
> an odd DSC encoder index. Each encoder can work independently.
> But Only two DSC encoders from same DCE can be p
On 04/12/2023 10:38, Maxime Ripard wrote:
On Sat, Dec 02, 2023 at 12:07:49AM +0200, Dmitry Baryshkov wrote:
The drm_atomic_helper_check_wb_encoder_state() function doesn't use
encoder for anything other than getting the drm_device instance. The
function's description talks about checking the wri
The function drm_atomic_helper_check_wb_encoder_state() doesn't use
drm_encoder for anything sensible. Internally it checks
drm_writeback_connector's state. Thus it makes sense to let this
function accept drm_writeback_connector object and the drm_atomic_state
and rename it to drm_atomic_helper_che
The drm_atomic_helper_check_wb_encoder_state() function doesn't use
encoder for anything other than getting the drm_device instance. The
function's description talks about checking the writeback connector
state, not the encoder state. Moreover, there is no such thing as an
encoder state, encoders g
As the renamed drm_atomic_helper_check_wb_connector_state() now accepts
drm_writeback_connector as the first argument (instead of drm_encoder),
move the VKMS writeback atomic_check from drm_encoder_helper_funcs to
drm_connector_helper_funcs. Also drop the vkms_wb_encoder_helper_funcs,
which have be
On Sat, 02 Dec 2023 01:40:24 +0200, Dmitry Baryshkov wrote:
> The handling code also usually knows, which sub-block it is now looking
> at. Drop unused 'id' field and arguments and merge some of sub-block
> declarations.
>
> While we are at it, also fix all VIG subblocks to contain correct scale
On Sun, 03 Dec 2023 01:42:43 +0300, Dmitry Baryshkov wrote:
> Per agreement with Konrad, picked up this patch series.
>
> 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 t
On Mon, 16 Oct 2023 22:18:07 -0400, Richard Acayan wrote:
> Changes since v3 (2023100927.485054-8-mailingrad...@gmail.com):
> - move status properties down (review tag retained) (6/6)
> - accumulate review tag (3/6)
>
> Changes since v2 (20231003012119.857198-9-mailingrad...@gmail.com):
>
On Mon, 30 Oct 2023 11:36:22 +0100, Neil Armstrong wrote:
> The SM8650 MDSS is very close from the MDSS 9.0.0 found
> on the SM8550 SoC, with the following difference:
> - DSI PHY 2.8.8, no significant differences
> - DPU 10.0.0:
> - Enhanced max_linewidth to 8k
> - PINGPONG_8 & PINGPONG_9
>
57 matches
Mail list logo
