Re: [bug report] adlp_tc_phy_connect [i915] floods logs with drm_WARN_ON(tc->mode == TC_PORT_LEGACY) call traces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 24, 2024 at 07:03:51PM +0300, Jani Nikula wrote:
> [...]
> Imre, I'm looking at the warnings in intel_tc.c in general, and
> adlp_tc_phy_connect() in particular, and I think this is too hard to
> parse:
> 
> 	if (!adlp_tc_phy_take_ownership(tc, true) &&
> 	    !drm_WARN_ON(&i915->drm, tc->mode == TC_PORT_LEGACY)) {
> 		drm_dbg_kms(&i915->drm, "Port %s: can't take PHY ownership\n",
> 			    tc->port_name);
> 		goto out_put_port_power;
> 	}
> 
> 	if (!tc_phy_is_ready(tc) &&
> 	    !drm_WARN_ON(&i915->drm, tc->mode == TC_PORT_LEGACY)) {
> 		drm_dbg_kms(&i915->drm, "Port %s: PHY not ready\n",
> 			    tc->port_name);
> 		goto out_release_phy;
> 	}
> 
> There are warnings in the logs, but they are for tc->mode ==
> TC_PORT_LEGACY. Why is that warning duplicated in both if conditions,
> and negated?! 

The WARNs' conditions are unexpected on legacy ports, but the connect
sequence should not be aborted on those (as there is nothing else that
could use the port/PHY in that case). The debug message could be
printed for legacy ports as well..

> Too hard for my poor brain to follow. Don't know which one
> happened, don't know what's going on.

It's the second 'PHY not ready' check based on the WARN's line number /
kernel version.

> BR,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux