On Mon, Dec 02, 2024 at 04:40:05PM +0800, Xiangxu Yin wrote:
>
>
> On 11/29/2024 9:50 PM, Dmitry Baryshkov wrote:
> > On Fri, 29 Nov 2024 at 09:59, Xiangxu Yin <quic_xiangxuy@xxxxxxxxxxx> wrote:
> >>
> >> Add the ability to configure lane mapping for the DP controller. This is
> >> required when the platform's lane mapping does not follow the default
> >> order (0, 1, 2, 3). The mapping rules are now configurable via the
> >> `data-lane` property in the devicetree. This property defines the
> >> logical-to-physical lane mapping sequence, ensuring correct lane
> >> assignment for non-default configurations.
> >>
> >> Signed-off-by: Xiangxu Yin <quic_xiangxuy@xxxxxxxxxxx>
> >> ---
> >> drivers/gpu/drm/msm/dp/dp_catalog.c | 11 +++++------
> >> drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +-
> >> drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
> >> drivers/gpu/drm/msm/dp/dp_panel.c | 13 ++++++++++---
> >> drivers/gpu/drm/msm/dp/dp_panel.h | 3 +++
> >> 5 files changed, 20 insertions(+), 11 deletions(-)
> >>
> >> @@ -461,6 +460,7 @@ static int msm_dp_panel_parse_dt(struct msm_dp_panel *msm_dp_panel)
> >> struct msm_dp_panel_private *panel;
> >> struct device_node *of_node;
> >> int cnt;
> >> + u32 lane_map[DP_MAX_NUM_DP_LANES] = {0, 1, 2, 3};
> >>
> >> panel = container_of(msm_dp_panel, struct msm_dp_panel_private, msm_dp_panel);
> >> of_node = panel->dev->of_node;
> >> @@ -474,10 +474,17 @@ static int msm_dp_panel_parse_dt(struct msm_dp_panel *msm_dp_panel)
> >> cnt = drm_of_get_data_lanes_count(of_node, 1, DP_MAX_NUM_DP_LANES);
> >> }
> >>
> >> - if (cnt > 0)
> >> + if (cnt > 0) {
> >> + struct device_node *endpoint;
> >> +
> >> msm_dp_panel->max_dp_lanes = cnt;
> >> - else
> >> + endpoint = of_graph_get_endpoint_by_regs(of_node, 1, -1);
> >> + of_property_read_u32_array(endpoint, "data-lanes", lane_map, cnt);
> >> + } else {
> >> msm_dp_panel->max_dp_lanes = DP_MAX_NUM_DP_LANES; /* 4 lanes */
> >> + }
> >
> > Why? This sounds more like dp_catalog or (after the refactoring at
> > [1]) dp_ctrl. But not the dp_panel.
> >
> > [1] https://patchwork.freedesktop.org/project/freedreno/series/?ordering=-last_updated
> >
> We are used the same prop 'data-lanes = <3 2 0 1>' in mdss_dp_out to keep similar behaviour with dsi_host_parse_lane_data.
> From the modules used, catalog seems more appropriate, but since the max_dp_lanes is parsed at dp_panel, it has been placed here.
> Should lane_map parsing in msm_dp_catalog_get, and keep max_dp_lanes parsing at the dp_panel?
msm_dp_catalog_get() is going to be removed. Since the functions that
are going to use it are in dp_ctrl module, I thought that dp_ctrl.c is
the best place. A better option might be to move max_dp_lanes and
max_dp_link_rate to dp_link.c as those are link params. Then
lane_mapping also logically becomes a part of dp_link module.
But now I have a more important question (triggered by Krishna's email
about SAR2130P's USB): if the lanes are swapped, does USB 3 work on that
platform? Or is it being demoted to USB 2 with nobody noticing that?
If lanes 0/1 and 2/3 are swapped, shouldn't it be handled in the QMP
PHY, where we handle lanes and orientation switching?
> >> +
> >> + memcpy(msm_dp_panel->lane_map, lane_map, msm_dp_panel->max_dp_lanes * sizeof(u32));
> >>
> >> msm_dp_panel->max_dp_link_rate = msm_dp_panel_link_frequencies(of_node);
> >> if (!msm_dp_panel->max_dp_link_rate)
> >> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h b/drivers/gpu/drm/msm/dp/dp_panel.h
> >> index 0e944db3adf2f187f313664fe80cf540ec7a19f2..7603b92c32902bd3d4485539bd6308537ff75a2c 100644
> >> --- a/drivers/gpu/drm/msm/dp/dp_panel.h
> >> +++ b/drivers/gpu/drm/msm/dp/dp_panel.h
> >> @@ -11,6 +11,8 @@
> >> #include "dp_aux.h"
> >> #include "dp_link.h"
> >>
> >> +#define DP_MAX_NUM_DP_LANES 4
> >> +
> >> struct edid;
> >>
> >> struct msm_dp_display_mode {
> >> @@ -46,6 +48,7 @@ struct msm_dp_panel {
> >> bool video_test;
> >> bool vsc_sdp_supported;
> >>
> >> + u32 lane_map[DP_MAX_NUM_DP_LANES];
> >> u32 max_dp_lanes;
> >> u32 max_dp_link_rate;
> >>
> >>
> >> --
> >> 2.25.1
> >>
> >
> >
>
>
> --
> linux-phy mailing list
> linux-phy@xxxxxxxxxxxxxxxxxxx
> https://lists.infradead.org/mailman/listinfo/linux-phy
--
With best wishes
Dmitry
