On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
Add support for handling and allocting SSPP blocks through the resource
manager. Handling code is not converted to use it though.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 10 +++
drivers/gpu/drm/msm/disp
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
Stop limiting zpos property values, we use normalized_zpos anyway. And
nothing stops userspace from assigning several planes to a single zpos
(it is a userspace bug, but the kernel is forgiving about it).
Signed-off-by: Dmitry Baryshkov
Reviewed-
On 2/9/2022 9:24 AM, Dmitry Baryshkov wrote:
Master/virtual planes were used for multirect support. In preparation to
reworking DPU planes, drop support for master planes (which was not used
anyway).
Signed-off-by: Dmitry Baryshkov
Agreed, master planes were unused today anyway.
hence,
Rev
Quoting Vinod Polimera (2022-04-25 23:02:11)
> Avoid clearing irqs and derefernce hw_intr when hw_intr is null.
Presumably this is only the case when the display driver doesn't fully
probe and something probe defers? Can you clarify how this situation
happens?
>
> BUG: Unable to handle kernel NUL
Hi,
On Tue, Apr 26, 2022 at 2:12 PM Kuogee Hsieh wrote:
>
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
> However there is possible circular locking happen (see blow stack trace)
> after edp
Quoting Kuogee Hsieh (2022-04-26 14:12:14)
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
[...]
>
> Changes in v6:
> -- fix Fixes commit ID
>
> Fixes: 8b2c181e3dcf ("drm/msm/dp: add fail safe m
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is execu
Hi linux-firmware maintainers,
Please pull the firmware for several generation of Adreno GPU (A220, A330,
A405/A420/A430).
The firmware files come from Dragonboard 820c BSP available at [1] or directly
from Qualcomm at [2] (registration is required).
[1]
http://releases.linaro.org/96boards/drag
Hi,
On Tue, Apr 26, 2022 at 1:30 PM Kuogee Hsieh wrote:
>
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
> However there is possible circular locking happen (see blow stack trace)
> after edp
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is execu
On 26/04/2022 23:04, Kuogee Hsieh wrote:
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_hand
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is execu
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is execu
On Tue, Apr 26, 2022 at 11:02 AM Christian König
wrote:
>
> Am 26.04.22 um 19:40 schrieb Chia-I Wu:
> > [SNIP]
> Well I just send a patch to completely remove the trace point.
>
> As I said it absolutely doesn't make sense to use this for
> visualization, that's what the trace_
Hi,
On Mon, Apr 25, 2022 at 10:56 PM Kuogee Hsieh wrote:
>
> Current DP driver implementation has adding safe mode done at
> dp_hpd_plug_handle() which is expected to be executed under event
> thread context.
>
> However there is possible circular locking happen (see blow stack trace)
> after edp
Hi,
On Tue, Apr 26, 2022 at 8:37 AM Abhinav Kumar wrote:
>
> > Can you provide the exact EDID from the failing test case? Maybe that
> > will help shed some light on what's going on. I looked at the original
> > commit and it just referred to 4.2.2.1, which I assume is "EDID Read
> > upon HPD Plu
Hello everyone!
The X.org board is soliciting proposals to host XDC in 2023. Since
XDC 2022 is being held in North America this year, XDC 2023 is expected
to be in Europe. However, the board is open to other locations,
especially if there's an interesting co-location with another
conference.
If y
Hello!
The 2022 X.Org Developers Conference is being held in conjunction with
the 2022 Wine Developers Conference. This is a meeting to bring
together developers working on all things open graphics (Linux kernel,
Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine
Project, a key con
On 26/04/2022 20:56, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:44 AM Dmitry Baryshkov
wrote:
On 26/04/2022 20:11, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
On 26/04/2022 18:37, Abhinav Kumar wrote:
Hi Doug
On 4/26/2022 8:20 AM, Doug And
On 4/26/2022 10:56 AM, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:44 AM Dmitry Baryshkov
wrote:
On 26/04/2022 20:11, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
On 26/04/2022 18:37, Abhinav Kumar wrote:
Hi Doug
On 4/26/2022 8:20 AM, Dou
At normal operation, transmit phy test pattern has to be terminated before
DP controller switch to video ready state. However during phy compliance
testing, transmit phy test pattern should not be terminated until end of
compliance test which usually indicated by unplugged interrupt.
Only stop sen
DP controller state can not switch from video ready state to
transmit phy pattern state at run time. DP mainlink has to be
teared down followed by reset controller to default state to have
DP controller switch to transmit phy test pattern state and start
generate specified phy test pattern to sinke
Current DP phy compliance test failed due to test pattern generation was
terminated premature.
Kuogee Hsieh (2):
drm/msm/dp: reset DP controller before transmit phy test pattern
drm/msm/dp: do not stop transmitting phy test pattern during DP phy
compliance test
drivers/gpu/drm/msm/dp/dp_
Hi,
On Tue, Apr 26, 2022 at 10:44 AM Dmitry Baryshkov
wrote:
>
> On 26/04/2022 20:11, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
> > wrote:
> >>
> >> On 26/04/2022 18:37, Abhinav Kumar wrote:
> >>> Hi Doug
> >>>
> >>> On 4/26/2022 8:20 AM, Doug Anderso
On 26/04/2022 20:11, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
On 26/04/2022 18:37, Abhinav Kumar wrote:
Hi Doug
On 4/26/2022 8:20 AM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
wrote:
On 4/25/2022 7:18 PM, Doug Anders
On Tue, Apr 26, 2022 at 10:20 AM Christian König
wrote:
>
> Am 26.04.22 um 19:16 schrieb Rob Clark:
> > On Tue, Apr 26, 2022 at 10:08 AM Christian König
> > wrote:
> >> Am 26.04.22 um 19:05 schrieb Rob Clark:
> >>> On Tue, Apr 26, 2022 at 9:42 AM Christian König
> >>> wrote:
> Am 26.04.22 u
On 4/25/2022 11:00 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-04-25 22:56:35)
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow st
On 4/26/2022 10:11 AM, Doug Anderson wrote:
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
On 26/04/2022 18:37, Abhinav Kumar wrote:
Hi Doug
On 4/26/2022 8:20 AM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
wrote:
On 4/25/2022 7:18 PM, Doug A
On Tue, Apr 26, 2022 at 10:08 AM Christian König
wrote:
>
> Am 26.04.22 um 19:05 schrieb Rob Clark:
> > On Tue, Apr 26, 2022 at 9:42 AM Christian König
> > wrote:
> >> Am 26.04.22 um 18:32 schrieb Chia-I Wu:
> >>> On Tue, Apr 12, 2022 at 2:26 PM Chia-I Wu wrote:
> In practice, trace_dma_fen
Hi,
On Tue, Apr 26, 2022 at 10:01 AM Dmitry Baryshkov
wrote:
>
> On 26/04/2022 18:37, Abhinav Kumar wrote:
> > Hi Doug
> >
> > On 4/26/2022 8:20 AM, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
> >> wrote:
> >>>
> >>> On 4/25/2022 7:18 PM, Doug Anderson w
On 26/04/2022 17:41, Abhinav Kumar wrote:
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
changes in v4:
- squash dpu_encoder pieces from [1]
changes in v5:
- none
changes in v6:
- fix the comment about intf_idx and wb_idx
On Tue, Apr 26, 2022 at 9:42 AM Christian König
wrote:
>
> Am 26.04.22 um 18:32 schrieb Chia-I Wu:
> > On Tue, Apr 12, 2022 at 2:26 PM Chia-I Wu wrote:
> >> In practice, trace_dma_fence_init called from dma_fence_init is good
> >> enough and almost no driver calls trace_dma_fence_emit. But drm_s
On 26/04/2022 18:37, Abhinav Kumar wrote:
Hi Doug
On 4/26/2022 8:20 AM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar
wrote:
On 4/25/2022 7:18 PM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 6:42 PM Abhinav Kumar
wrote:
2) When there was a valid EDID bu
Quoting Dmitry Baryshkov (2022-04-25 17:41:28)
> Add missing dependency on the AUX bus implementation.
>
> Fixes: 82c59ed16695 ("drm/msm/dp: Add eDP support via aux_bus")
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Kuogee Hsieh (2022-04-25 17:16:53)
> At normal operation, transmit phy test pattern has to be terminated before
> DP controller switch to video ready state. However during phy compliance
> testing, transmit phy test pattern should not be terminated until end of
> compliance test which usual
On Tue, Apr 12, 2022 at 2:26 PM Chia-I Wu wrote:
>
> In practice, trace_dma_fence_init called from dma_fence_init is good
> enough and almost no driver calls trace_dma_fence_emit. But drm_sched
> and virtio both have cases where trace_dma_fence_init and
> trace_dma_fence_emit can be apart. It is
Hi Doug
On 4/26/2022 8:20 AM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar wrote:
On 4/25/2022 7:18 PM, Doug Anderson wrote:
Hi,
On Mon, Apr 25, 2022 at 6:42 PM Abhinav Kumar wrote:
2) When there was a valid EDID but no 640x480 mode
This is the equipment spec
Hi,
On Mon, Apr 25, 2022 at 8:35 PM Abhinav Kumar wrote:
>
> On 4/25/2022 7:18 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Apr 25, 2022 at 6:42 PM Abhinav Kumar
> > wrote:
> >>
> 2) When there was a valid EDID but no 640x480 mode
>
> This is the equipment specific case and t
On 4/26/2022 7:56 AM, Laurent Pinchart wrote:
On Tue, Apr 26, 2022 at 05:11:41AM +0300, Dmitry Baryshkov wrote:
On 26/04/2022 03:32, Laurent Pinchart wrote:
On Sun, Apr 24, 2022 at 05:32:06PM -0700, Abhinav Kumar wrote:
Initialize dpu encoder and connector for writeback if the
target suppor
On Tue, Apr 26, 2022 at 05:11:41AM +0300, Dmitry Baryshkov wrote:
> On 26/04/2022 03:32, Laurent Pinchart wrote:
> > On Sun, Apr 24, 2022 at 05:32:06PM -0700, Abhinav Kumar wrote:
> >> Initialize dpu encoder and connector for writeback if the
> >> target supports it in the catalog.
> >>
> >> change
Introduce the dpu_encoder_phys_* for the writeback interface
to handle writeback specific hardware programming.
changes in v4:
- squash the encoder_phys_wb bits from [1]
- since its a trivial change of a previously acked change
preserving the ack
[1] https://patchwork.fr
Add wb_idx to existing DRM prints in dpu_encoder and also
print the intf_mode so that its clear that for any INTF_CMD/VID
there will be a valid intf_idx and any INTF_WB_* there will be a
valid wb_idx.
Update the debugfs to add the same information. Here is a sample
output with this change:
root:/
Change the DRM traces to include both the intf_mode
and wb_idx similar to the DRM prints in the previous change.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 26 ++
Initialize dpu encoder and connector for writeback if the
target supports it in the catalog.
changes in v2:
- start initialing the encoder for writeback since we
have migrated to using drm_writeback_connector_init_with_encoder()
- instead of checking for WB_2 inside _dpu_km
Add writeback block information while capturing the display
snapshot.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/di
kms_writeback test cases also verify with a null fb for the
writeback connector job. In addition there are also other
commit paths which can result in kickoffs without a valid
framebuffer like while closing the fb which results in the
callback to drm_atomic_helper_dirtyfb() which internally
trigger
Introduce the dpu_writeback module which serves as the
interface between dpu operations and the drm_writeback.
This module manages the connector related operations for
dpu writeback.
changes in v2:
- start using drm_writeback_connector_init_with_encoder()
- drop unnecessary argume
_dpu_plane_get_qos_lut() is not specific to just dpu_plane.
It can take any fill level and return the LUT matching it.
This can be used even for other modules like dpu_writeback.
Move _dpu_plane_get_qos_lut() to the common dpu_hw_util file
and rename it to _dpu_hw_get_qos_lut().
Signed-off-by: Ab
add dpu encoder APIs to prepare and cleanup writeback job
for the writeback encoder. These shall be invoked from the
prepare_wb_job/cleanup_wb_job hooks of the drm_writeback
framework.
changes in v3:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/
Make changes to dpu_encoder to support virtual encoder needed
to support writeback for dpu.
changes in v4:
- squash dpu_encoder pieces from [1]
changes in v5:
- none
changes in v6:
- fix the comment about intf_idx and wb_idx
- add the condition for valid phys_enc
Add an API to reset the encoder related hw blocks to ensure
a proper teardown of the pipeline. At the moment this is being
used only for the writeback encoder but eventually we can start
using this for all interfaces.
changes in v4:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry
Add writeback blocks to DPU resource manager so that
the encoders can directly request them through RM.
changes in v4:
- absorb dpu_rm.h header change from [1]
- since its a trivial change absorbed from an approved
patch, preserving the previous ack on this
[1] https://p
Add writeback blocks to the sm8250 DPU hardware catalog. Other
chipsets support writeback too but add it to sm8250 to prototype
the feature so that it can be easily extended to other chipsets.
changes in v4:
- fix the copyright year order
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry
Add changes to support writeback module in the dpu_hw_ctl
interface.
changes in v4:
- fix the copyright year order
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 52 --
drivers/gpu/drm/msm/disp/dpu
Add a reset_intf_cfg operation for dpu_hw_ctl to reset the
entire CTL path by disabling each component namely layer mixer,
3d-merge and interface blocks.
changes in v3:
- none
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 32
This series adds support for writeback block on DPU. Writeback
block is extremely useful to validate boards having no physical displays
in addition to many other use-cases where we want to get the output
of the display pipeline to examine whether issue is with the display
pipeline or with the panel
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
an
Clients of drm_writeback_connector_init() initialize the
possible_crtcs and then invoke the call to this API.
To simplify things, allow passing possible_crtcs as a parameter
to drm_writeback_connector_init() and make changes to the
other drm drivers to make them compatible with this change.
chang
Rename dpu_hw_pipe_cdp_cfg to dpu_hw_cdp_cfg and move it
to dpu_hw_utils file so that other modules in addition to
SSPP such as writeback can use it as all the fields can
be used by writeback as well.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
Add the dpu_hw_wb abstraction to program registers related to the
writeback block. These will be invoked once all the configuration
is set and ready to be programmed to the registers.
changes in v3:
- start using the common struct dpu_hw_cdp_cfg
- leave a comment about DPU non-DPU_
Fix following coccicheck warning:
drivers/gpu/drm/msm/msm_gpu_devfreq.c:72:1-7: WARNING: do_div() does a 64-by-32
division, please consider using div64_ul instead.
Use div64_ul instead of do_div to avoid a possible truncation.
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/msm/msm_gpu_devfreq.
61 matches
Mail list logo
