Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] drm/tidss: misleading debug message for clock tolerance check --
commit ba6e7e4ea9ca6eb6ee75e88d2391c42dcbb0611c Author: Maxime Ripard <[email protected]> drm/tidss: dispc: Improve mode checking logs This commit adds diagnostic debug messages to dispc_vp_mode_valid and check_pixel_clock to clarify why a display mode is rejected by the hardware. Previously, mode rejection occurred silently without clear attribution. > diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c > b/drivers/gpu/drm/tidss/tidss_dispc.c > index 2a0ec11a6c902..a19b74b0ca302 100644 > --- a/drivers/gpu/drm/tidss/tidss_dispc.c > +++ b/drivers/gpu/drm/tidss/tidss_dispc.c [ ... ] > @@ -1318,8 +1320,10 @@ static int check_pixel_clock(struct dispc_device > *dispc, u32 hw_videoport, > * To keep the check consistent with dispc_vp_set_clk_rate(), we > * use the same 5% check here. > */ > - if (dispc_pclk_diff(clock, round_clock) > 5) > + if (dispc_pclk_diff(clock, round_clock) > 5) { > + drm_dbg(dev, "Mode pixel clock below hardware minimum pixel > clock."); [Severity: Low] Is this debug message accurate for this condition? The dispc_pclk_diff function checks if the requested clock and the rounded clock differ by more than 5%. This means the synthesized clock is out of tolerance (it could be either higher or lower than the requested rate by more than 5%), rather than strictly being below a hardware minimum. Could this mislead developers trying to diagnose mode rejections? > return -EINVAL; > + } > > return 0; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=24
