| Message ID | 20171106102115.5929bed7@endymion (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c +++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c @@ -168,8 +168,10 @@ radeon_dp_aux_transfer_native(struct drm goto done; } if (tmp & AUX_RX_ERROR_FLAGS) { - DRM_DEBUG_KMS_RATELIMITED("dp_aux_ch flags not zero: %08x\n", - tmp); + /* + * aux transfers always fail with non-zero status flags when + * there's nothing connected on the port + */ ret = -EIO; goto done; }
Hi all, commit 92c177b7947d9c889ea7b024871445015ea74221 Author: Lyude Date: Wed Feb 22 16:34:53 2017 -0500 drm/radeon/dp_auxch: Ratelimit aux transfer debug messages does more harm than good in my opinion. Since this commit, I see several occurrences of the following message in my kernel log daily: radeon_dp_aux_transfer_native: 74 callbacks suppressed I never got to see the "callback" in question though, not even once, as this is a debug message which is off by default. Before the change, I would not get any such message in the kernel log (as I would expect when everything works as intended.) Does this debug message really have any practical value? If not, the easiest solution would be to simply drop it: I can resend this as a formal patch if you agree with this solution. The actual cause of the problem is that ___ratelimit() prints its message at KERN_WARNING level regardless of the level of the message being suppressed. This makes ratelimiting debug, info or notice messages awkward. Looks like a design overlook to me, maybe it should be fixed, but that's a much bigger and intrusive change than the proposal above.