From: Yongxing Mou <quic_yongmou@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Rob Clark <robin.clark@oss.qualcomm.com>,
Abhinav Kumar <abhinav.kumar@linux.dev>,
Jessica Zhang <jessica.zhang@oss.qualcomm.com>,
Sean Paul <sean@poorly.run>,
Marijn Suijten <marijn.suijten@somainline.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
<linux-arm-msm@vger.kernel.org>,
<dri-devel@lists.freedesktop.org>,
<freedreno@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>,
"Abhinav Kumar" <quic_abhinavk@quicinc.com>
Subject: Re: [PATCH v2 02/38] drm/msm/dp: remove dp_display's dp_mode and use dp_panel's instead
Date: Wed, 6 Aug 2025 17:22:32 +0800 [thread overview]
Message-ID: <d55c1d20-fd55-4b43-b0cf-bcb2e7e3368e@quicinc.com> (raw)
In-Reply-To: <26f21464-022b-460a-92f2-0ea626cfd262@oss.qualcomm.com>
On 2025/6/27 20:44, Dmitry Baryshkov wrote:
> On 27/06/2025 11:40, Yongxing Mou wrote:
>>
>>
>> On 2025/6/25 22:03, Dmitry Baryshkov wrote:
>>> On Wed, Jun 25, 2025 at 08:34:18PM +0800, Yongxing Mou wrote:
>>>>
>>>>
>>>> On 2025/6/9 20:48, Dmitry Baryshkov wrote:
>>>>> On Mon, Jun 09, 2025 at 08:21:21PM +0800, Yongxing Mou wrote:
>>>>>> From: Abhinav Kumar <quic_abhinavk@quicinc.com>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> - Why do we need to cache / copy it anyway? Can't we just pass the
>>>>> corresponding drm_atomic_state / drm_crtc_state /
>>>>> drm_display_mode ?
>>>>>
>>>> This part works as follows: .mode_set() copies the adjusted_mode into
>>>> msm_dp_display_private->msm_dp_display_mode, and also parses and stores
>>>> variables such as v_active_low/h_active_low/out_fmt_is_yuv_420
>>>> and ... When
>>>> @drm_bridge_funcs.atomic_enable() is called, it copies
>>>> msm_dp_display->msm_dp_mode into dp_panel->msm_dp_mode and initializes
>>>> panel_info in msm_dp_display_set_mode(). Then when go to
>>>> msm_dp_ctrl_on_stream(), the parameters are updated into the
>>>> corresponding
>>>> hardware registers.
>>>
>>> So, if we do everything during .atomic_enable(), there would be no need
>>> to store and/or copy anything. All the data is available and can be used
>>> as is.
>>>
>> Got it. Let me confirm—can we keep msm_dp_mode or drm_display_mode in
>> msm_dp_panel? Mabey debug node will use this ..
>
> Please don't. I really dislike storing drm_atomic_state-related
> variables in a non-state structure. I think it makes it easier to
> mistakenly update or to use a stale value.
>
> Debug code already prints modes in debugfs/dri/N/state. If we need any
> other state-related prints, they should go to the same file.
>
Hi, I got this point.. i go through the driver. since lots of funcs used
msm_dp_mode cached. so maybe it is not a very small change.. I’d like to
prioritize MST first, and then submit this patch once I got time..
>>>>
>>>> This design has been in place since the first version of the DP
>>>> driver and
>>>> has remained largely unchanged.
>>>
>>> Yes... The point is that you are touching this piece of code anyway,
>>> let's make it nicer.
>>>
>> Agree with this point.
>>>> Originally, the drm_mode would be passed in
>>>> two stages: from msm_dp_display->msm_dp_mode to dp_panel-
>>>> >msm_dp_mode. Since
>>>> in MST mode each stream requires its own drm_mode and stored in
>>>> dp_panel, we
>>>> simplified the two-stage transfer into a single step (.mode_set() do
>>>> all
>>>> things and store in msm_dp_panel). Meanwhile we modified the
>>>> msm_dp_display_set_mode function to accept a msm_dp_panel parameter,
>>>> allowing the MST bridge funcs' mode_set() to reuse this part code.
>>>>
>>>> The following patches:
>>>> https://patchwork.freedesktop.org/patch/657573/?series=142207&rev=2 and
>>>> https://patchwork.freedesktop.org/patch/657593/?series=142207&rev=2,
>>>> introduce msm_dp_display_*_helper functions to help reuse common
>>>> code across
>>>> MST/SST/eDP drm_bridge_funcs.
>>>>
>>>> If we drop msm_dp_mode from dp_panel and use drm_display_mode, it might
>>>> introduce a large number of changes that are not directly related to
>>>> MST.
>>>> Actually i think the presence of msm_dp_display_mode seems to
>>>> simplify the
>>>> work in msm_dp_panel_timing_cfg(), this patch series we want to
>>>> focus on MST
>>>> parts, so would we consider optimizing them later?
>>>
>>> Sure... But then you have to change two places. If you optimize it
>>> first, you have to touch only place. And it can be even submitted
>>> separately.
>>>
>> Understood, that’s indeed the case. I just want to prioritize the MST
>> patch and have it merged first, since it involves changes to lots of
>> files. Thanks~~
>>>>
>>>> Thanks~
>>>>>>
>>>>>> Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
>>>>>> Signed-off-by: Yongxing Mou <quic_yongmou@quicinc.com>
>>>>>> ---
>>>>>> drivers/gpu/drm/msm/dp/dp_display.c | 76 +++++++++++++
>>>>>> +-----------------------
>>>>>> 1 file changed, 29 insertions(+), 47 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/
>>>>>> drm/ msm/dp/dp_display.c
>>>>>> index
>>>>>> 4a9b65647cdef1ed6c3bb851f93df0db8be977af..9d2db9cbd2552470a36a63f70f517c35436f7280 100644
>>>>>> --- a/drivers/gpu/drm/msm/dp/dp_display.c
>>>>>> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
>>>>>> @@ -92,7 +92,6 @@ struct msm_dp_display_private {
>>>>>> struct msm_dp_panel *panel;
>>>>>> struct msm_dp_ctrl *ctrl;
>>>>>> - struct msm_dp_display_mode msm_dp_mode;
>>>>>> struct msm_dp msm_dp_display;
>>>>>> /* wait for audio signaling */
>>>>>> @@ -806,16 +805,29 @@ static int msm_dp_init_sub_modules(struct
>>>>>> msm_dp_display_private *dp)
>>>>>> }
>>>>>> static int msm_dp_display_set_mode(struct msm_dp *msm_dp_display,
>>>>>> - struct msm_dp_display_mode *mode)
>>>>>> + const struct drm_display_mode *adjusted_mode,
>>>>>> + struct msm_dp_panel *msm_dp_panel)
>>>>>> {
>>>>>> - struct msm_dp_display_private *dp;
>>>>>> + u32 bpp;
>>>>>> - dp = container_of(msm_dp_display, struct
>>>>>> msm_dp_display_private, msm_dp_display);
>>>>>> + drm_mode_copy(&msm_dp_panel->msm_dp_mode.drm_mode,
>>>>>> adjusted_mode);
>>>>>> +
>>>>>> + if (msm_dp_display_check_video_test(msm_dp_display))
>>>>>> + bpp = msm_dp_display_get_test_bpp(msm_dp_display);
>>>>>> + else
>>>>>> + bpp = msm_dp_panel->connector->display_info.bpc * 3;
>>>>>> +
>>>>>> + msm_dp_panel->msm_dp_mode.bpp = bpp;
>>>>>> +
>>>>>> + msm_dp_panel->msm_dp_mode.v_active_low =
>>>>>> + !!(adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC);
>>>>>> + msm_dp_panel->msm_dp_mode.h_active_low =
>>>>>> + !!(adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC);
>>>>>> + msm_dp_panel->msm_dp_mode.out_fmt_is_yuv_420 =
>>>>>> + drm_mode_is_420_only(&msm_dp_panel->connector-
>>>>>> >display_info, adjusted_mode) &&
>>>>>> + msm_dp_panel->vsc_sdp_supported;
>>>>>> - drm_mode_copy(&dp->panel->msm_dp_mode.drm_mode, &mode-
>>>>>> >drm_mode);
>>>>>> - dp->panel->msm_dp_mode.bpp = mode->bpp;
>>>>>> - dp->panel->msm_dp_mode.out_fmt_is_yuv_420 = mode-
>>>>>> >out_fmt_is_yuv_420;
>>>>>> - msm_dp_panel_init_panel_info(dp->panel);
>>>>>> + msm_dp_panel_init_panel_info(msm_dp_panel);
>>>>>> return 0;
>>>>>> }
>>>>>> @@ -1431,10 +1443,13 @@ bool msm_dp_needs_periph_flush(const
>>>>>> struct msm_dp *msm_dp_display,
>>>>>> bool msm_dp_wide_bus_available(const struct msm_dp
>>>>>> *msm_dp_display)
>>>>>> {
>>>>>> struct msm_dp_display_private *dp;
>>>>>> + struct msm_dp_panel *dp_panel;
>>>>>> dp = container_of(msm_dp_display, struct
>>>>>> msm_dp_display_private, msm_dp_display);
>>>>>> - if (dp->msm_dp_mode.out_fmt_is_yuv_420)
>>>>>> + dp_panel = dp->panel;
>>>>>> +
>>>>>> + if (dp_panel->msm_dp_mode.out_fmt_is_yuv_420)
>>>>>> return false;
>>>>>> return dp->wide_bus_supported;
>>>>>> @@ -1496,10 +1511,6 @@ void msm_dp_bridge_atomic_enable(struct
>>>>>> drm_bridge *drm_bridge,
>>>>>> bool force_link_train = false;
>>>>>> msm_dp_display = container_of(dp, struct
>>>>>> msm_dp_display_private, msm_dp_display);
>>>>>> - if (!msm_dp_display->msm_dp_mode.drm_mode.clock) {
>>>>>> - DRM_ERROR("invalid params\n");
>>>>>> - return;
>>>>>> - }
>>>>>> if (dp->is_edp)
>>>>>> msm_dp_hpd_plug_handle(msm_dp_display, 0);
>>>>>> @@ -1517,15 +1528,6 @@ void msm_dp_bridge_atomic_enable(struct
>>>>>> drm_bridge *drm_bridge,
>>>>>> return;
>>>>>> }
>>>>>> - rc = msm_dp_display_set_mode(dp, &msm_dp_display->msm_dp_mode);
>>>>>> - if (rc) {
>>>>>> - DRM_ERROR("Failed to perform a mode set, rc=%d\n", rc);
>>>>>> - mutex_unlock(&msm_dp_display->event_mutex);
>>>>>> - return;
>>>>>> - }
>>>>>
>>>>> It should be done other way around: keep this call and drop
>>>>> msm_dp_bridge_mode_set().
>>>>>
>>>> Emm as reply in last comments..
>>>
>>> Yep. Drop .mode_set, the callback is even described as deprecated.
>>>
>> Thanks, the documentation does state that.
>>>>>> -
>>>>>> - hpd_state = msm_dp_display->hpd_state;
>>>>>> -
>>>>>> if (hpd_state == ST_CONNECTED && !dp->power_on) {
>>>>>> msm_dp_display_host_phy_init(msm_dp_display);
>>>>>> force_link_train = true;
>>>>>> @@ -1604,33 +1606,13 @@ void msm_dp_bridge_mode_set(struct
>>>>>> drm_bridge *drm_bridge,
>>>>>> msm_dp_display = container_of(dp, struct
>>>>>> msm_dp_display_private, msm_dp_display);
>>>>>> msm_dp_panel = msm_dp_display->panel;
>>>>>> - memset(&msm_dp_display->msm_dp_mode, 0x0, sizeof(struct
>>>>>> msm_dp_display_mode));
>>>>>> -
>>>>>> - if (msm_dp_display_check_video_test(dp))
>>>>>> - msm_dp_display->msm_dp_mode.bpp =
>>>>>> msm_dp_display_get_test_bpp(dp);
>>>>>> - else /* Default num_components per pixel = 3 */
>>>>>> - msm_dp_display->msm_dp_mode.bpp = dp->connector-
>>>>>> >display_info.bpc * 3;
>>>>>> -
>>>>>> - if (!msm_dp_display->msm_dp_mode.bpp)
>>>>>> - msm_dp_display->msm_dp_mode.bpp = 24; /* Default bpp */
>>>>>> -
>>>>>> - drm_mode_copy(&msm_dp_display->msm_dp_mode.drm_mode,
>>>>>> adjusted_mode);
>>>>>> -
>>>>>> - msm_dp_display->msm_dp_mode.v_active_low =
>>>>>> - !!(msm_dp_display->msm_dp_mode.drm_mode.flags &
>>>>>> DRM_MODE_FLAG_NVSYNC);
>>>>>> -
>>>>>> - msm_dp_display->msm_dp_mode.h_active_low =
>>>>>> - !!(msm_dp_display->msm_dp_mode.drm_mode.flags &
>>>>>> DRM_MODE_FLAG_NHSYNC);
>>>>>> -
>>>>>> - msm_dp_display->msm_dp_mode.out_fmt_is_yuv_420 =
>>>>>> - drm_mode_is_420_only(&dp->connector->display_info,
>>>>>> adjusted_mode) &&
>>>>>> - msm_dp_panel->vsc_sdp_supported;
>>>>>> + msm_dp_display_set_mode(dp, adjusted_mode, msm_dp_panel);
>>>>>> /* populate wide_bus_support to different layers */
>>>>>> - msm_dp_display->ctrl->wide_bus_en =
>>>>>> - msm_dp_display->msm_dp_mode.out_fmt_is_yuv_420 ? false :
>>>>>> msm_dp_display->wide_bus_supported;
>>>>>> - msm_dp_display->catalog->wide_bus_en =
>>>>>> - msm_dp_display->msm_dp_mode.out_fmt_is_yuv_420 ? false :
>>>>>> msm_dp_display->wide_bus_supported;
>>>>>> + msm_dp_display->ctrl->wide_bus_en = msm_dp_panel-
>>>>>> >msm_dp_mode.out_fmt_is_yuv_420 ?
>>>>>> + false : msm_dp_display->wide_bus_supported;
>>>>>> + msm_dp_display->catalog->wide_bus_en = msm_dp_panel-
>>>>>> >msm_dp_mode.out_fmt_is_yuv_420 ?
>>>>>> + false : msm_dp_display->wide_bus_supported;
>>>>>> }
>>>>>> void msm_dp_bridge_hpd_enable(struct drm_bridge *bridge)
>>>>>>
>>>>>> --
>>>>>> 2.34.1
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
next prev parent reply other threads:[~2025-08-06 9:22 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 12:21 [PATCH v2 00/38] drm/msm/dp: Add MST support for MSM chipsets Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 01/38] drm/msm/dp: split msm_dp_panel_read_sink_caps() into two parts and drop panel drm_edid Yongxing Mou
2025-06-09 12:41 ` Dmitry Baryshkov
2025-06-25 8:43 ` Yongxing Mou
2025-06-25 13:32 ` Dmitry Baryshkov
2025-06-27 7:49 ` Yongxing Mou
2025-06-27 12:40 ` Dmitry Baryshkov
2025-08-06 9:03 ` Yongxing Mou
2025-08-06 10:39 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 02/38] drm/msm/dp: remove dp_display's dp_mode and use dp_panel's instead Yongxing Mou
2025-06-09 12:48 ` Dmitry Baryshkov
2025-06-25 12:34 ` Yongxing Mou
2025-06-25 14:03 ` Dmitry Baryshkov
2025-06-27 8:40 ` Yongxing Mou
2025-06-27 12:44 ` Dmitry Baryshkov
2025-08-06 9:22 ` Yongxing Mou [this message]
2025-08-06 10:41 ` Dmitry Baryshkov
2025-06-27 13:37 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 03/38] drm/msm/dp: break up dp_display_enable into two parts Yongxing Mou
2025-06-09 12:59 ` Dmitry Baryshkov
2025-08-06 9:24 ` Yongxing Mou
2025-08-13 9:36 ` Yongxing Mou
2025-08-13 12:59 ` Dmitry Baryshkov
2025-08-14 8:14 ` Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 04/38] drm/msm/dp: re-arrange dp_display_disable() into functional parts Yongxing Mou
2025-06-09 13:05 ` Dmitry Baryshkov
2025-08-06 9:30 ` Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 05/38] drm/msm/dp: allow dp_ctrl stream APIs to use any panel passed to it Yongxing Mou
2025-06-09 13:12 ` Dmitry Baryshkov
2025-08-13 9:52 ` Yongxing Mou
2025-08-13 13:20 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 06/38] drm/msm/dp: move the pixel clock control to its own API Yongxing Mou
2025-06-09 13:16 ` Dmitry Baryshkov
2025-08-13 11:56 ` Yongxing Mou
2025-08-13 13:05 ` Dmitry Baryshkov
2025-08-13 13:21 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 07/38] drm/msm/dp: split dp_ctrl_off() into stream and link parts Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 08/38] drm/msm/dp: make bridge helpers use dp_display to allow re-use Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 09/38] drm/msm/dp: separate dp_display_prepare() into its own API Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 10/38] drm/msm/dp: introduce the max_streams for dp controller Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 11/38] drm/msm/dp: introduce stream_id for each DP panel Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 12/38] drm/msm/dp: add support for programming p1/p2/p3 register block Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 13/38] drm/msm/dp: use stream_id to change offsets in dp_catalog Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 14/38] drm/msm/dp: Add catalog support for 3rd/4th stream MST Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 15/38] drm/msm/dp: add support to send ACT packets for MST Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 16/38] drm/msm/dp: add support to program mst support in mainlink Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 17/38] drm/msm/dp: no need to update tu calculation for mst Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 18/38] drm/msm/dp: add support for mst channel slot allocation Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 19/38] drm/msm/dp: add support to send vcpf packets in dp controller Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 20/38] drm/msm/dp: always program MST_FIFO_CONSTANT_FILL for MST Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 21/38] drm/msm/dp: abstract out the dp_display stream helpers to accept a panel Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 22/38] drm/msm/dp: move link related operations to dp_display_unprepare() Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 23/38] drm/msm/dp: replace power_on with active_stream_cnt for dp_display Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 24/38] drm/msm/dp: make the SST bridge disconnected when mst is active Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 25/38] drm/msm/dp: add an API to initialize MST on sink side Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 26/38] drm/msm/dp: skip reading the EDID for MST cases Yongxing Mou
2025-06-09 15:58 ` Dmitry Baryshkov
2025-08-14 8:22 ` Yongxing Mou
2025-08-14 9:27 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 27/38] drm/msm/dp: add dp_display_get_panel() to initialize DP panel Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 28/38] drm/msm/dp: add dp_mst_drm to manage DP MST bridge operations Yongxing Mou
2025-06-09 15:57 ` Dmitry Baryshkov
2025-06-11 11:39 ` Yongxing Mou
2025-06-11 14:27 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 29/38] drm/msm/dp: add connector abstraction for DP MST Yongxing Mou
2025-06-09 15:44 ` Dmitry Baryshkov
2025-06-11 12:06 ` Yongxing Mou
2025-06-11 14:31 ` Dmitry Baryshkov
2025-06-16 14:09 ` Yongxing Mou
2025-06-16 14:47 ` Dmitry Baryshkov
[not found] ` <bd0fba5c-9e38-4a40-adf9-cc70fa2d0f57@oss.qualcomm.com>
[not found] ` <ad1db558-c33e-4788-9f25-cac6c21713f1@quicinc.com>
2025-06-19 11:33 ` Dmitry Baryshkov
2025-06-24 9:56 ` Yongxing Mou
2025-06-24 22:25 ` Dmitry Baryshkov
2025-06-09 15:51 ` Dmitry Baryshkov
2025-06-16 12:43 ` Yongxing Mou
2025-06-16 13:48 ` Dmitry Baryshkov
2025-06-17 7:52 ` Yongxing Mou
2025-06-17 10:04 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 30/38] drm/msm/dp: add HPD callback for dp MST Yongxing Mou
2025-06-09 15:01 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 31/38] drm/msm/dp: propagate MST state changes to dp mst module Yongxing Mou
2025-06-09 14:56 ` Dmitry Baryshkov
2025-08-14 8:24 ` Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 32/38] drm/msm: add support for non-blocking commits Yongxing Mou
2025-06-09 14:50 ` Dmitry Baryshkov
2025-08-14 8:54 ` Yongxing Mou
2025-08-14 9:28 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 33/38] drm/msm: initialize DRM MST encoders for DP controllers Yongxing Mou
2025-06-09 14:17 ` Dmitry Baryshkov
2025-08-14 9:11 ` Yongxing Mou
2025-08-14 9:29 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 34/38] drm/msm/dp: initialize dp_mst module for each DP MST controller Yongxing Mou
2025-06-09 14:27 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 35/38] drm/msm/dpu: use msm_dp_get_mst_intf_id() to get the intf id Yongxing Mou
2025-06-09 14:44 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 36/38] drm/msm/dp: mark ST_DISCONNECTED only if all streams are disabled Yongxing Mou
2025-06-09 12:21 ` [PATCH v2 37/38] drm/msm/dp: fix the intf_type of MST interfaces Yongxing Mou
2025-06-09 14:45 ` Dmitry Baryshkov
2025-06-09 12:21 ` [PATCH v2 38/38] drm/msm/dp: Add MST stream support for SA8775P DP controller 0 and 1 Yongxing Mou
2025-06-09 14:47 ` Dmitry Baryshkov
2025-06-09 12:36 ` [PATCH v2 00/38] drm/msm/dp: Add MST support for MSM chipsets Dmitry Baryshkov
2025-06-10 4:47 ` Yongxing Mou
2025-06-10 8:30 ` Dmitry Baryshkov
2025-06-11 12:08 ` Yongxing Mou
2025-06-11 14:35 ` Dmitry Baryshkov
2025-06-09 16:07 ` Dmitry Baryshkov
2025-06-10 4:31 ` Yongxing Mou
2025-06-10 8:31 ` Dmitry Baryshkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d55c1d20-fd55-4b43-b0cf-bcb2e7e3368e@quicinc.com \
--to=quic_yongmou@quicinc.com \
--cc=abhinav.kumar@linux.dev \
--cc=airlied@gmail.com \
--cc=dmitry.baryshkov@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jessica.zhang@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marijn.suijten@somainline.org \
--cc=quic_abhinavk@quicinc.com \
--cc=robin.clark@oss.qualcomm.com \
--cc=sean@poorly.run \
--cc=simona@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®