media: rockchip: hdmirx: quiet signal-not-lock polling spam#515
Conversation
When a source is reported present but never produces a lockable signal, hdmirx_wait_lock_and_get_timing logs two v4l2_err lines on every poll, flooding the kernel log every few seconds. Demote them to v4l2_dbg like the pull-out path just above, keeping the log clean while the receiver keeps retrying. Signed-off-by: SuperKali <hello@superkali.me>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis change modifies the logging behavior in the HDMI RX driver's signal lock timeout handling. Previously, when the signal failed to lock within the timeout period, two error-level log messages (reporting tmds_clk_ratio and a register dump of mu_st/scdc_st/dma_st10) were emitted unconditionally via v4l2_err. These are now emitted as debug-level messages via v4l2_dbg, gated by the debug flag. Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
When the HDMI-RX detect reports a source but the receiver never gets a lockable signal, hdmirx_wait_lock_and_get_timing logged two v4l2_err lines on every poll, flooding the log every few seconds.
On the YY3588 the detect reads "present" even with nothing attached, so the poll runs continuously and the log fills with:
Demote both to v4l2_dbg, matching the pull-out path right above. Verified on a YY3588: with a source the receiver still locks and captures 1080p60, with none the log stays clean.