Allow supported link rate to be limited to the value specified at
dtsi. If it is not specified, then link rate is derived from dpcd
directly. Below are examples,
link-rate = <162000> for max link rate limited at 1.62G
link-rate = <270000> for max link rate limited at 2.7G
link-rate = <540000> for max link rate limited at 5.4G
link-rate = <810000> for max link rate limited at 8.1G
Changes in V2:
-- allow supported max link rate specified from dtsi
Signed-off-by: Kuogee Hsieh <[email protected]>
---
drivers/gpu/drm/msm/dp/dp_display.c | 1 +
drivers/gpu/drm/msm/dp/dp_panel.c | 7 ++++---
drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
drivers/gpu/drm/msm/dp/dp_parser.c | 13 +++++++++++++
drivers/gpu/drm/msm/dp/dp_parser.h | 1 +
5 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 5a39da6..f633ba6 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -322,6 +322,7 @@ static int dp_display_process_hpd_high(struct dp_display_private *dp)
struct edid *edid;
dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
+ dp->panel->max_link_rate = dp->parser->max_link_rate;
rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
if (rc)
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c b/drivers/gpu/drm/msm/dp/dp_panel.c
index 9cc8166..be7f102 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -76,9 +76,10 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
if (link_info->num_lanes > dp_panel->max_dp_lanes)
link_info->num_lanes = dp_panel->max_dp_lanes;
- /* Limit support upto HBR2 until HBR3 support is added */
- if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
- link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
+ /* Limit support of ink rate if specified */
+ if (dp_panel->max_link_rate &&
+ (link_info->rate > dp_panel->max_link_rate))
+ link_info->rate = dp_panel->max_link_rate;
DRM_DEBUG_DP("version: %d.%d\n", major, minor);
DRM_DEBUG_DP("link_rate=%d\n", link_info->rate);
diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h b/drivers/gpu/drm/msm/dp/dp_panel.h
index 9023e5b..1876f5e 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.h
+++ b/drivers/gpu/drm/msm/dp/dp_panel.h
@@ -51,6 +51,7 @@ struct dp_panel {
u32 vic;
u32 max_pclk_khz;
u32 max_dp_lanes;
+ u32 max_link_rate;
u32 max_bw_code;
};
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c
index 0519dd3..d8b6898 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.c
+++ b/drivers/gpu/drm/msm/dp/dp_parser.c
@@ -87,6 +87,8 @@ static int dp_parser_misc(struct dp_parser *parser)
struct device_node *of_node = parser->pdev->dev.of_node;
int len = 0;
const char *data_lane_property = "data-lanes";
+ const char *link_rate_property = "link-rate";
+ u32 rate = 0;
len = of_property_count_elems_of_size(of_node,
data_lane_property, sizeof(u32));
@@ -97,6 +99,17 @@ static int dp_parser_misc(struct dp_parser *parser)
}
parser->max_dp_lanes = len;
+
+ len = of_property_count_elems_of_size(of_node,
+ link_rate_property, sizeof(u32));
+
+ if (len == 1) {
+ of_property_read_u32_index(of_node,
+ link_rate_property, 0, &rate);
+
+ parser->max_link_rate = rate;
+ }
+
return 0;
}
diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h b/drivers/gpu/drm/msm/dp/dp_parser.h
index 34b4962..7046fce 100644
--- a/drivers/gpu/drm/msm/dp/dp_parser.h
+++ b/drivers/gpu/drm/msm/dp/dp_parser.h
@@ -116,6 +116,7 @@ struct dp_parser {
struct dp_display_data disp_data;
const struct dp_regulator_cfg *regulator_cfg;
u32 max_dp_lanes;
+ u32 max_link_rate;
int (*parse)(struct dp_parser *parser);
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
On Thu 18 Feb 14:55 CST 2021, Kuogee Hsieh wrote:
> Allow supported link rate to be limited to the value specified at
> dtsi. If it is not specified, then link rate is derived from dpcd
> directly. Below are examples,
> link-rate = <162000> for max link rate limited at 1.62G
> link-rate = <270000> for max link rate limited at 2.7G
> link-rate = <540000> for max link rate limited at 5.4G
> link-rate = <810000> for max link rate limited at 8.1G
>
> Changes in V2:
> -- allow supported max link rate specified from dtsi
>
> Signed-off-by: Kuogee Hsieh <[email protected]>
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 1 +
> drivers/gpu/drm/msm/dp/dp_panel.c | 7 ++++---
> drivers/gpu/drm/msm/dp/dp_panel.h | 1 +
> drivers/gpu/drm/msm/dp/dp_parser.c | 13 +++++++++++++
> drivers/gpu/drm/msm/dp/dp_parser.h | 1 +
> 5 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> index 5a39da6..f633ba6 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -322,6 +322,7 @@ static int dp_display_process_hpd_high(struct dp_display_private *dp)
> struct edid *edid;
>
> dp->panel->max_dp_lanes = dp->parser->max_dp_lanes;
> + dp->panel->max_link_rate = dp->parser->max_link_rate;
>
> rc = dp_panel_read_sink_caps(dp->panel, dp->dp_display.connector);
> if (rc)
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c b/drivers/gpu/drm/msm/dp/dp_panel.c
> index 9cc8166..be7f102 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.c
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.c
> @@ -76,9 +76,10 @@ static int dp_panel_read_dpcd(struct dp_panel *dp_panel)
> if (link_info->num_lanes > dp_panel->max_dp_lanes)
> link_info->num_lanes = dp_panel->max_dp_lanes;
>
> - /* Limit support upto HBR2 until HBR3 support is added */
> - if (link_info->rate >= (drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4)))
> - link_info->rate = drm_dp_bw_code_to_link_rate(DP_LINK_BW_5_4);
> + /* Limit support of ink rate if specified */
> + if (dp_panel->max_link_rate &&
Make the parser always initialize max_link_rate to something reasonable
and just compare against that here.
> + (link_info->rate > dp_panel->max_link_rate))
No need for the (), nor for line breaking this.
> + link_info->rate = dp_panel->max_link_rate;
>
> DRM_DEBUG_DP("version: %d.%d\n", major, minor);
> DRM_DEBUG_DP("link_rate=%d\n", link_info->rate);
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.h b/drivers/gpu/drm/msm/dp/dp_panel.h
> index 9023e5b..1876f5e 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.h
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.h
> @@ -51,6 +51,7 @@ struct dp_panel {
> u32 vic;
> u32 max_pclk_khz;
> u32 max_dp_lanes;
> + u32 max_link_rate;
>
> u32 max_bw_code;
> };
> diff --git a/drivers/gpu/drm/msm/dp/dp_parser.c b/drivers/gpu/drm/msm/dp/dp_parser.c
> index 0519dd3..d8b6898 100644
> --- a/drivers/gpu/drm/msm/dp/dp_parser.c
> +++ b/drivers/gpu/drm/msm/dp/dp_parser.c
> @@ -87,6 +87,8 @@ static int dp_parser_misc(struct dp_parser *parser)
> struct device_node *of_node = parser->pdev->dev.of_node;
> int len = 0;
> const char *data_lane_property = "data-lanes";
> + const char *link_rate_property = "link-rate";
There's no reason for stashing these in local variables.
> + u32 rate = 0;
>
> len = of_property_count_elems_of_size(of_node,
> data_lane_property, sizeof(u32));
> @@ -97,6 +99,17 @@ static int dp_parser_misc(struct dp_parser *parser)
> }
>
> parser->max_dp_lanes = len;
> +
> + len = of_property_count_elems_of_size(of_node,
> + link_rate_property, sizeof(u32));
I'm afraid I don't see the reason for this, simply rely on the return
value of of_property_read_u32(), i.e.
ret = of_property_read_u32(node, "link-rate", &rate);
if (!ret)
parser->max_link_rate = rate;
Or if you want to give it some default value:
rate = 1234;
of_property_read_u32(node, "link-rate", &rate);
Which either will overwrite the rate with the value of the property, or
leave it untouched.
Regards,
Bjorn
> +
> + if (len == 1) {
> + of_property_read_u32_index(of_node,
> + link_rate_property, 0, &rate);
> +
> + parser->max_link_rate = rate;
> + }
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_parser.h b/drivers/gpu/drm/msm/dp/dp_parser.h
> index 34b4962..7046fce 100644
> --- a/drivers/gpu/drm/msm/dp/dp_parser.h
> +++ b/drivers/gpu/drm/msm/dp/dp_parser.h
> @@ -116,6 +116,7 @@ struct dp_parser {
> struct dp_display_data disp_data;
> const struct dp_regulator_cfg *regulator_cfg;
> u32 max_dp_lanes;
> + u32 max_link_rate;
>
> int (*parse)(struct dp_parser *parser);
> };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Quoting Kuogee Hsieh (2021-02-18 12:55:04)
> Allow supported link rate to be limited to the value specified at
> dtsi. If it is not specified, then link rate is derived from dpcd
> directly. Below are examples,
> link-rate = <162000> for max link rate limited at 1.62G
> link-rate = <270000> for max link rate limited at 2.7G
> link-rate = <540000> for max link rate limited at 5.4G
> link-rate = <810000> for max link rate limited at 8.1G
>
> Changes in V2:
> -- allow supported max link rate specified from dtsi
Please don't roll this into the patch that removes the limit. The
previous version of this patch was fine. The part that lowers the limit
back down should be another patch.
We rejected link-rate in DT before and we should reject it upstream
again. As far as I can tell, the maximum link rate should be determined
based on the panel or the type-c port on the board. The dp controller
can always achieve HBR3, so limiting it at the dp controller is
incorrect. The driver should query the endpoints to figure out if they
want to limit the link rate. Is that done automatically sometimes by
intercepting the DPCD?
On 2021-02-18 15:02, Stephen Boyd wrote:
> Quoting Kuogee Hsieh (2021-02-18 12:55:04)
>> Allow supported link rate to be limited to the value specified at
>> dtsi. If it is not specified, then link rate is derived from dpcd
>> directly. Below are examples,
>> link-rate = <162000> for max link rate limited at 1.62G
>> link-rate = <270000> for max link rate limited at 2.7G
>> link-rate = <540000> for max link rate limited at 5.4G
>> link-rate = <810000> for max link rate limited at 8.1G
>>
>> Changes in V2:
>> -- allow supported max link rate specified from dtsi
>
> Please don't roll this into the patch that removes the limit. The
> previous version of this patch was fine. The part that lowers the limit
> back down should be another patch.
>
> We rejected link-rate in DT before and we should reject it upstream
> again. As far as I can tell, the maximum link rate should be determined
> based on the panel or the type-c port on the board. The dp controller
> can always achieve HBR3, so limiting it at the dp controller is
> incorrect. The driver should query the endpoints to figure out if they
> want to limit the link rate. Is that done automatically sometimes by
> intercepting the DPCD?
ok, i will roll back to original patch and add the second patch for max
link rate limited purpose.
panel dpcd specified max link rate it supported.
At driver, link rate is derived from dpcd directly since driver will try
to use the maximum supported link rate and less lane to save power.
Therefore it is not possible that limit link rate base on dpcd.
AS i understand we are going to do max link rate limitation is due to
old redriver chip can not support HBR3.
How can I acquire which type-c port on the board so that I can trigger
max link rate limitation?
Quoting [email protected] (2021-02-19 08:39:38)
> On 2021-02-18 15:02, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2021-02-18 12:55:04)
> >> Allow supported link rate to be limited to the value specified at
> >> dtsi. If it is not specified, then link rate is derived from dpcd
> >> directly. Below are examples,
> >> link-rate = <162000> for max link rate limited at 1.62G
> >> link-rate = <270000> for max link rate limited at 2.7G
> >> link-rate = <540000> for max link rate limited at 5.4G
> >> link-rate = <810000> for max link rate limited at 8.1G
> >>
> >> Changes in V2:
> >> -- allow supported max link rate specified from dtsi
> >
> > Please don't roll this into the patch that removes the limit. The
> > previous version of this patch was fine. The part that lowers the limit
> > back down should be another patch.
> >
> > We rejected link-rate in DT before and we should reject it upstream
> > again. As far as I can tell, the maximum link rate should be determined
> > based on the panel or the type-c port on the board. The dp controller
> > can always achieve HBR3, so limiting it at the dp controller is
> > incorrect. The driver should query the endpoints to figure out if they
> > want to limit the link rate. Is that done automatically sometimes by
> > intercepting the DPCD?
>
> ok, i will roll back to original patch and add the second patch for max
> link rate limited purpose.
> panel dpcd specified max link rate it supported.
> At driver, link rate is derived from dpcd directly since driver will try
> to use the maximum supported link rate and less lane to save power.
> Therefore it is not possible that limit link rate base on dpcd.
> AS i understand we are going to do max link rate limitation is due to
> old redriver chip can not support HBR3.
> How can I acquire which type-c port on the board so that I can trigger
> max link rate limitation?
>
>
The driver already seems to support lowering the link rate during link
training. Can't we try to train at the highest rate and then downgrade
the link speed until it trains properly? I sort of fail to see why we
need to introduce a bunch of complexity around limiting the link rate on
certain boards if the driver can figure out that link training doesn't
work at HBR3 so it should try to train at HBR2 instead.
On 2021-02-19 14:46, Stephen Boyd wrote:
> Quoting [email protected] (2021-02-19 08:39:38)
>> On 2021-02-18 15:02, Stephen Boyd wrote:
>> > Quoting Kuogee Hsieh (2021-02-18 12:55:04)
>> >> Allow supported link rate to be limited to the value specified at
>> >> dtsi. If it is not specified, then link rate is derived from dpcd
>> >> directly. Below are examples,
>> >> link-rate = <162000> for max link rate limited at 1.62G
>> >> link-rate = <270000> for max link rate limited at 2.7G
>> >> link-rate = <540000> for max link rate limited at 5.4G
>> >> link-rate = <810000> for max link rate limited at 8.1G
>> >>
>> >> Changes in V2:
>> >> -- allow supported max link rate specified from dtsi
>> >
>> > Please don't roll this into the patch that removes the limit. The
>> > previous version of this patch was fine. The part that lowers the limit
>> > back down should be another patch.
>> >
>> > We rejected link-rate in DT before and we should reject it upstream
>> > again. As far as I can tell, the maximum link rate should be determined
>> > based on the panel or the type-c port on the board. The dp controller
>> > can always achieve HBR3, so limiting it at the dp controller is
>> > incorrect. The driver should query the endpoints to figure out if they
>> > want to limit the link rate. Is that done automatically sometimes by
>> > intercepting the DPCD?
>>
>> ok, i will roll back to original patch and add the second patch for
>> max
>> link rate limited purpose.
>> panel dpcd specified max link rate it supported.
>> At driver, link rate is derived from dpcd directly since driver will
>> try
>> to use the maximum supported link rate and less lane to save power.
>> Therefore it is not possible that limit link rate base on dpcd.
>> AS i understand we are going to do max link rate limitation is due to
>> old redriver chip can not support HBR3.
>> How can I acquire which type-c port on the board so that I can trigger
>> max link rate limitation?
>>
>>
>
> The driver already seems to support lowering the link rate during link
> training. Can't we try to train at the highest rate and then downgrade
> the link speed until it trains properly? I sort of fail to see why we
> need to introduce a bunch of complexity around limiting the link rate
> on
> certain boards if the driver can figure out that link training doesn't
> work at HBR3 so it should try to train at HBR2 instead.
yes, dp driver did support down grade link rate during link training
procedure.
But link training is kind of setting up agreement between host and panel
with assumption that there are no other limitations in between.
The problem we are discussing here is the limitation of usb re driver
link rate support.
Since we do not know how usb re driver behavior, I am not sure link
training will work appropriately for this case.
It may end up link status keep toggling up and down.
Both link-lane and link-rate specified at dtsi are for the limitation of
Trogdor hardware platform.
Both link-lane and link-rate specified at dtsi are NOT for panel since
panel have specified its capability at its DPCD.
On Mon, Feb 22, 2021 at 11:31 AM <[email protected]> wrote:
>
> On 2021-02-19 14:46, Stephen Boyd wrote:
> > Quoting [email protected] (2021-02-19 08:39:38)
> >> On 2021-02-18 15:02, Stephen Boyd wrote:
> >> > Quoting Kuogee Hsieh (2021-02-18 12:55:04)
> >> >> Allow supported link rate to be limited to the value specified at
> >> >> dtsi. If it is not specified, then link rate is derived from dpcd
> >> >> directly. Below are examples,
> >> >> link-rate = <162000> for max link rate limited at 1.62G
> >> >> link-rate = <270000> for max link rate limited at 2.7G
> >> >> link-rate = <540000> for max link rate limited at 5.4G
> >> >> link-rate = <810000> for max link rate limited at 8.1G
> >> >>
> >> >> Changes in V2:
> >> >> -- allow supported max link rate specified from dtsi
> >> >
> >> > Please don't roll this into the patch that removes the limit. The
> >> > previous version of this patch was fine. The part that lowers the limit
> >> > back down should be another patch.
> >> >
> >> > We rejected link-rate in DT before and we should reject it upstream
> >> > again. As far as I can tell, the maximum link rate should be determined
> >> > based on the panel or the type-c port on the board. The dp controller
> >> > can always achieve HBR3, so limiting it at the dp controller is
> >> > incorrect. The driver should query the endpoints to figure out if they
> >> > want to limit the link rate. Is that done automatically sometimes by
> >> > intercepting the DPCD?
> >>
> >> ok, i will roll back to original patch and add the second patch for
> >> max
> >> link rate limited purpose.
> >> panel dpcd specified max link rate it supported.
> >> At driver, link rate is derived from dpcd directly since driver will
> >> try
> >> to use the maximum supported link rate and less lane to save power.
> >> Therefore it is not possible that limit link rate base on dpcd.
> >> AS i understand we are going to do max link rate limitation is due to
> >> old redriver chip can not support HBR3.
> >> How can I acquire which type-c port on the board so that I can trigger
> >> max link rate limitation?
> >>
> >>
> >
> > The driver already seems to support lowering the link rate during link
> > training. Can't we try to train at the highest rate and then downgrade
> > the link speed until it trains properly? I sort of fail to see why we
> > need to introduce a bunch of complexity around limiting the link rate
> > on
> > certain boards if the driver can figure out that link training doesn't
> > work at HBR3 so it should try to train at HBR2 instead.
>
> yes, dp driver did support down grade link rate during link training
> procedure.
> But link training is kind of setting up agreement between host and panel
> with assumption that there are no other limitations in between.
> The problem we are discussing here is the limitation of usb re driver
> link rate support.
> Since we do not know how usb re driver behavior, I am not sure link
> training will work appropriately for this case.
> It may end up link status keep toggling up and down.
>
IMO we should just fail link training if the redriver doesn't support
a link count/rate and fallback to the next count/rate. This should be
handled the same as if there were a cable incapable of achieving a
link rate. Adding the link rate to the device tree (at least on the dp
block) seems suspicious.
If you really wanted to model the redriver's limitations in software,
you'd probably want to introduce a bridge driver/connector which
rejects modes that cannot be achieved by the redriver. This should
prevent the dp driver from trying to train at the unsupported rates.
Sean
> Both link-lane and link-rate specified at dtsi are for the limitation of
> Trogdor hardware platform.
> Both link-lane and link-rate specified at dtsi are NOT for panel since
> panel have specified its capability at its DPCD.
>
>
>
>
>
>
>
>
> _______________________________________________
> Freedreno mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/freedreno
On 2021-02-22 08:55, Sean Paul wrote:
> On Mon, Feb 22, 2021 at 11:31 AM <[email protected]> wrote:
>>
>> On 2021-02-19 14:46, Stephen Boyd wrote:
>> > Quoting [email protected] (2021-02-19 08:39:38)
>> >> On 2021-02-18 15:02, Stephen Boyd wrote:
>> >> > Quoting Kuogee Hsieh (2021-02-18 12:55:04)
>> >> >> Allow supported link rate to be limited to the value specified at
>> >> >> dtsi. If it is not specified, then link rate is derived from dpcd
>> >> >> directly. Below are examples,
>> >> >> link-rate = <162000> for max link rate limited at 1.62G
>> >> >> link-rate = <270000> for max link rate limited at 2.7G
>> >> >> link-rate = <540000> for max link rate limited at 5.4G
>> >> >> link-rate = <810000> for max link rate limited at 8.1G
>> >> >>
>> >> >> Changes in V2:
>> >> >> -- allow supported max link rate specified from dtsi
>> >> >
>> >> > Please don't roll this into the patch that removes the limit. The
>> >> > previous version of this patch was fine. The part that lowers the limit
>> >> > back down should be another patch.
>> >> >
>> >> > We rejected link-rate in DT before and we should reject it upstream
>> >> > again. As far as I can tell, the maximum link rate should be determined
>> >> > based on the panel or the type-c port on the board. The dp controller
>> >> > can always achieve HBR3, so limiting it at the dp controller is
>> >> > incorrect. The driver should query the endpoints to figure out if they
>> >> > want to limit the link rate. Is that done automatically sometimes by
>> >> > intercepting the DPCD?
>> >>
>> >> ok, i will roll back to original patch and add the second patch for
>> >> max
>> >> link rate limited purpose.
>> >> panel dpcd specified max link rate it supported.
>> >> At driver, link rate is derived from dpcd directly since driver will
>> >> try
>> >> to use the maximum supported link rate and less lane to save power.
>> >> Therefore it is not possible that limit link rate base on dpcd.
>> >> AS i understand we are going to do max link rate limitation is due to
>> >> old redriver chip can not support HBR3.
>> >> How can I acquire which type-c port on the board so that I can trigger
>> >> max link rate limitation?
>> >>
>> >>
>> >
>> > The driver already seems to support lowering the link rate during link
>> > training. Can't we try to train at the highest rate and then downgrade
>> > the link speed until it trains properly? I sort of fail to see why we
>> > need to introduce a bunch of complexity around limiting the link rate
>> > on
>> > certain boards if the driver can figure out that link training doesn't
>> > work at HBR3 so it should try to train at HBR2 instead.
>>
>> yes, dp driver did support down grade link rate during link training
>> procedure.
>> But link training is kind of setting up agreement between host and
>> panel
>> with assumption that there are no other limitations in between.
>> The problem we are discussing here is the limitation of usb re driver
>> link rate support.
>> Since we do not know how usb re driver behavior, I am not sure link
>> training will work appropriately for this case.
>> It may end up link status keep toggling up and down.
>>
>
> IMO we should just fail link training if the redriver doesn't support
> a link count/rate and fallback to the next count/rate. This should be
> handled the same as if there were a cable incapable of achieving a
> link rate. Adding the link rate to the device tree (at least on the dp
> block) seems suspicious.
>
> If you really wanted to model the redriver's limitations in software,
> you'd probably want to introduce a bridge driver/connector which
> rejects modes that cannot be achieved by the redriver. This should
> prevent the dp driver from trying to train at the unsupported rates.
>
> Sean
>
I am not familiar with drm arch that well.
Can you elaborate more how bridge can work in this case?
When dp driver received plug-in interrupt, it read panel capability dpcd
and start link training with link rate specified at dpcd.
How bridge can propagate link rate (limited by redriver) before link
training happen?
>
>> Both link-lane and link-rate specified at dtsi are for the limitation
>> of
>> Trogdor hardware platform.
>> Both link-lane and link-rate specified at dtsi are NOT for panel since
>> panel have specified its capability at its DPCD.
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Freedreno mailing list
>> [email protected]
>> https://lists.freedesktop.org/mailman/listinfo/freedreno