On 9/25/2024 12:23 AM, Maxime Ripard wrote:
On Tue, Sep 24, 2024 at 03:59:18PM GMT, Jessica Zhang wrote:
Check that all encoders attached to a given CRTC are valid
possible_clones of each other.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/drm_atomic_helper.c | 23
On 11/22/2024 1:56 AM, Fange Zhang wrote:
From: Li Liu
Add definitions for the display hardware used on the Qualcomm SM6150
platform.
Signed-off-by: Li Liu
Signed-off-by: Fange Zhang
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_5_3_sm6150.h | 263 +
drivers/gpu/drm/msm
On 12/3/2024 5:58 AM, Dmitry Baryshkov wrote:
On Tue, Dec 03, 2024 at 03:41:53PM +0800, Xiangxu Yin wrote:
On 12/2/2024 5:32 PM, Dmitry Baryshkov wrote:
On Mon, 2 Dec 2024 at 11:05, Xiangxu Yin wrote:
On 11/29/2024 9:52 PM, Dmitry Baryshkov wrote:
On Fri, 29 Nov 2024 at 09:59, Xiangx
+*/
+ if (!dpu_kms->catalog->caps->has_3d_merge
+ && mode->hdisplay > dpu_kms->catalog->caps->max_mixer_width)
+ return MODE_BAD;
/*
* max crtc width is equal to the max mixer width * 2 and max height is
4K
*
On 6.12.2024 5:32 AM, Abhinav Kumar wrote:
> From: Yongxing Mou
>
> Populate the pixel clock for stream 1 for DP0 for sa8775p DP controller.
>
> Signed-off-by: Yongxing Mou
> Signed-off-by: Abhinav Kumar
> ---
> arch/arm64/boot/dts/qcom/sa8775p.dtsi | 12
> 1 file changed, 8 inse
On Thu, Dec 05, 2024 at 08:31:44PM -0800, Abhinav Kumar wrote:
> dp_display_prepare() only prepares the link in case its not
> already ready before dp_display_enable(). Hence separate it into
> its own API.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 24 +++
Hi Dmitry,
On Wed, Nov 20, 2024 at 09:39:27AM +0100, Johan Hovold wrote:
> On Fri, Aug 02, 2024 at 10:47:33PM +0300, Dmitry Baryshkov wrote:
> > During suspend/resume process all connectors are explicitly disabled and
> > then reenabled. However resume fails because of the connector_status check:
On Thu, Dec 05, 2024 at 08:32:02PM -0800, Abhinav Kumar wrote:
> Add a new file dp_mst_drm to manage the DP MST bridge operations
> similar to the dp_drm file which manages the SST bridge operations.
> Each MST encoder creates one bridge and each bridge is bound to its
> own dp_panel abstraction to
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Reviewed-by: Jani Nikula
Acked-by: Jani Nikula
Signed-off-by: Dmitry Baryshko
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/amd/display/amdgpu_dm/amd
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++--
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Acked-by: Raphael Gallais-Pou
Signed-off-by: Dmitry Baryshkov
---
drivers/gp
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 2
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/radeon/radeon_audio.c | 2
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Acked-by: Abhinav Kumar
Reviewed-by: Abhinav Kumar
Signed-off-by: Dmitry Bary
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/analogix/anx7625.c
Reading access to connector->eld can happen at the same time the
drm_edid_to_eld() updates the data. Take the newly added eld_mutex in
order to protect connector->eld from concurrent access.
Reviewed-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/ite-it66121.c | 2
The connector->eld is accessed by the .get_eld() callback. This access
can collide with the drm_edid_to_eld() updating the data at the same
time. Add drm_connector.eld_mutex to protect the data from concurrenct
access. Individual drivers are not updated (to reduce possible issues
while applying the
The connector->eld is accessed by the .get_eld() callback. This access
can collide with the drm_edid_to_eld() updating the data at the same
time. Add drm_connector.eld_mutex to protect the data from concurrenct
access.
The individual drivers were just compile tested. I propose to merge the
drm_con
On Thu, Dec 05, 2024 at 08:31:47PM -0800, Abhinav Kumar wrote:
> p1 register block is needed for the second mst stream.
> Add support in the catalog to be able to program this block.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dp/dp_catalog.c | 29 +
>
On Thu, Dec 05, 2024 at 08:31:47PM -0800, Abhinav Kumar wrote:
> p1 register block is needed for the second mst stream.
> Add support in the catalog to be able to program this block.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dp/dp_catalog.c | 29 +
>
On Thu, Dec 05, 2024 at 08:32:00PM -0800, Abhinav Kumar wrote:
> For MST cases, EDID is handled through AUX sideband messaging.
> Skip the EDID read during hotplug handle for MST cases.
But why? Isn't EDID being read at the hotplug time to update
drm_connector's data?
>
> Signed-off-by: Abhinav
On Thu, Dec 05, 2024 at 08:32:08PM -0800, Abhinav Kumar wrote:
> Hook up the mst framework APIs with atomic_commit_setup() and
> atomic_commit_tail() APIs to handle non-blocking commits.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/msm_atomic.c | 2 ++
> drivers/gpu/drm/msm/msm_d
On Thu, Dec 05, 2024 at 08:32:12PM -0800, Abhinav Kumar wrote:
> Use msm_dp_get_mst_intf_id() to get the intf id for the DP MST
> controller as the intf_id is unique for each MST stream of each
> DP controller.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
On Thu, Dec 05, 2024 at 08:32:11PM -0800, Abhinav Kumar wrote:
> Each DP controller capable of MST can support multiple streams
> and each of the streams maps to an interface block ID which can
> vary based on chipset. Add a stream to interface map for MST capable
> DP controllers.
>
> Signed-off-
On Thu, Dec 05, 2024 at 08:31:42PM -0800, Abhinav Kumar wrote:
> Split dp_ctrl_off() into stream and link parts so that for MST
> cases we can control the link and pixel parts separately.
Please start by describing the problem.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dp/dp
On Thu, Dec 05, 2024 at 08:31:38PM -0800, Abhinav Kumar wrote:
> dp_display_enable() currently re-trains the link if needed
> and then enables the pixel clock, programs the controller to
> start sending the pixel stream. Break up these two parts into
> separate APIs to distinguish these two parts b
On Thu, Dec 05, 2024 at 08:31:41PM -0800, Abhinav Kumar wrote:
> Enable/Disable of DP pixel clock happens in multiple code paths
> leading to code duplication. Move it into individual helpers so that
> the helpers can be called wherever necessary.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers
On Thu, Dec 05, 2024 at 08:31:40PM -0800, Abhinav Kumar wrote:
> Currently, the dp_ctrl stream APIs operate on their own dp_panel
> which is cached inside the dp_ctrl's private struct. However with MST,
> the cached panel represents the fixed link and not the sinks which
> are hotplugged. Allow the
On Thu, Dec 05, 2024 at 08:31:37PM -0800, Abhinav Kumar wrote:
> dp_display caches the current display mode and then passes it onto
> the panel to be used for programming the panel params. Remove this
> two level passing and directly populated the panel's dp_display_mode
> instead.
Remove both and
On Thu, Dec 05, 2024 at 08:31:36PM -0800, Abhinav Kumar wrote:
> Add a helper to check whether a dp_panel is mst capable.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/dp/dp_aux.h | 1 +
> drivers/gpu/drm/msm/dp/dp_panel.c | 14 ++
> drivers/gpu/drm/msm/dp/dp_panel.
On Thu, Dec 05, 2024 at 08:31:35PM -0800, Abhinav Kumar wrote:
> In preparation of DP MST where link caps are read for the
> immediate downstream device and the edid is read through
> sideband messaging, split the msm_dp_panel_read_sink_caps() into
> two parts which read the link parameters and the
On Thu, Dec 05, 2024 at 08:31:34PM -0800, Abhinav Kumar wrote:
> Interface type of MST interfaces is currently INTF_NONE.
> Fix this to INTF_DP.
Neither subject nor commit message tell that this is limited to sa8775p
only. Please consider toggling all catalog files which are supposed to
handle MST
On Thu, Dec 05, 2024 at 08:31:33PM -0800, Abhinav Kumar wrote:
> dp_ctrl_off_link() was created to handle a case where we received
> a cable connect and then get a cable disconnect without the corresponding
> dp_display_enable(). For such cases the pixel clock will be off but the
> link clock will
34 matches
Mail list logo