On 17-10-2024 01:12, Taylor, Clinton A wrote:
On Fri, 2024-10-11 at 12:34 +0530, Pottumuttu, Sai Teja wrote:
On 11-10-2024 03:00, Taylor, Clinton A wrote:
On Wed, 2024-10-09 at 22:32 +0530, Pottumuttu, Sai Teja wrote:
On 05-10-2024 02:38, Clint Taylor wrote:
Some devices NAK DPCD writes to the SOURCE OUI (0x300) DPCD registers.
Reduce the log level priority to prevent dmesg noise for these devices.
Signed-off-by: Clint Taylor <clinton.a.taylor@xxxxxxxxx>
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index fbb096be02ad..9920ec1f9c53 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3418,7 +3418,7 @@ intel_edp_init_source_oui(struct intel_dp *intel_dp, bool
careful)
}
if (drm_dp_dpcd_write(&intel_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) <
0)
- drm_err(&i915->drm, "Failed to write source OUI\n");
+ drm_info(&i915->drm, "Failed to write source OUI\n");
Just had one small question here, I think NAK is one case, but in case
of other errors/failures (EINVAL, ENOMEM) would we still want to reduce
the log level?
If EINVAL or ENOMEM occurs there will be plenty of other failures earlier and later
that
will be logged. This function returns void so we don't handle any failure for
SourceOUI
write anyway. This just prevents noise in the dmesg log from known devices that NAK
this
particular DPCD operation. The other option would be to list all known devices that
return
NAK and filter them via a DCPD quirk.
-Clint
Ok, in that case, should we also consider decreasing the log level of
read failure a little above?
Read response should never be NAK'd by the Sink device.
-Clint
Thanks for the clarification, with that,
Reviewed-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@xxxxxxxxx>
Thanks,
Sai Teja
Thanks,
Sai Teja
intel_dp->last_oui_write = jiffies;
}
