Message ID | 20230525090124.11614-3-mika.westerberg@linux.intel.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 3fe95742af29b8b4eccab2ba94bc521805c6e10c |
Headers | show |
Series | thunderbolt: Two fixes for reported display issues | expand |
On Thu, May 25, 2023 at 12:01 PM Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > > If the boot firmware has already established tunnels, especially ones > that have special requirements from the link such as DisplayPort, we > should not blindly enable CL states (nor change the TMU configuration). > Otherwise the existing tunnels may not work as expected. > > For this reason, skip the CL state enabling when we go over the existing > topology. This will als keep the TMU settings untouched because we do ^ also > not change the TMU configururation when CL states are not enabled. ^ configuration For the both patches in the series: Acked-By: Yehezkel Bernat <YehezkelShB@gmail.com>
On Sun, May 28, 2023 at 11:06:16AM +0300, Yehezkel Bernat wrote: > On Thu, May 25, 2023 at 12:01 PM Mika Westerberg > <mika.westerberg@linux.intel.com> wrote: > > > > If the boot firmware has already established tunnels, especially ones > > that have special requirements from the link such as DisplayPort, we > > should not blindly enable CL states (nor change the TMU configuration). > > Otherwise the existing tunnels may not work as expected. > > > > For this reason, skip the CL state enabling when we go over the existing > > topology. This will als keep the TMU settings untouched because we do > ^ also > > > not change the TMU configururation when CL states are not enabled. > ^ configuration > > For the both patches in the series: > > Acked-By: Yehezkel Bernat <YehezkelShB@gmail.com> Thanks! Fixed the typos and applied both to thunderbolt.git/fixes.
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c index 7bfbc9ca9ba4..c1af712ca728 100644 --- a/drivers/thunderbolt/tb.c +++ b/drivers/thunderbolt/tb.c @@ -737,6 +737,7 @@ static void tb_scan_port(struct tb_port *port) { struct tb_cm *tcm = tb_priv(port->sw->tb); struct tb_port *upstream_port; + bool discovery = false; struct tb_switch *sw; int ret; @@ -804,8 +805,10 @@ static void tb_scan_port(struct tb_port *port) * tunnels and know which switches were authorized already by * the boot firmware. */ - if (!tcm->hotplug_active) + if (!tcm->hotplug_active) { dev_set_uevent_suppress(&sw->dev, true); + discovery = true; + } /* * At the moment Thunderbolt 2 and beyond (devices with LC) we @@ -835,10 +838,14 @@ static void tb_scan_port(struct tb_port *port) * CL0s and CL1 are enabled and supported together. * Silently ignore CLx enabling in case CLx is not supported. */ - ret = tb_switch_enable_clx(sw, TB_CL1); - if (ret && ret != -EOPNOTSUPP) - tb_sw_warn(sw, "failed to enable %s on upstream port\n", - tb_switch_clx_name(TB_CL1)); + if (discovery) { + tb_sw_dbg(sw, "discovery, not touching CL states\n"); + } else { + ret = tb_switch_enable_clx(sw, TB_CL1); + if (ret && ret != -EOPNOTSUPP) + tb_sw_warn(sw, "failed to enable %s on upstream port\n", + tb_switch_clx_name(TB_CL1)); + } if (tb_switch_is_clx_enabled(sw, TB_CL1)) /*
If the boot firmware has already established tunnels, especially ones that have special requirements from the link such as DisplayPort, we should not blindly enable CL states (nor change the TMU configuration). Otherwise the existing tunnels may not work as expected. For this reason, skip the CL state enabling when we go over the existing topology. This will als keep the TMU settings untouched because we do not change the TMU configururation when CL states are not enabled. Reported-by: Koba Ko <koba.ko@canonical.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7831 Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> --- drivers/thunderbolt/tb.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)