Quoting Ville Syrjala (2020-10-22 20:42:56) > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > The new >8k CEA modes have dotclocks reaching 5.94 GHz, which > means our clock*1000 will now overflow the 32bit unsigned > integer. Switch to 64bit maths to avoid it. > > Cc: stable@xxxxxxxxxxxxxxx > Reported-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx> > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > --- > An interesting question how many other place might suffer from similar > overflows. I think i915 should be mostly OK. The one place I know we use > Hz instead kHz is the hsw DPLL code, which I would prefer we also change > to use kHz. The other concern is whether we have any potential overflows > before we check this against the platform's max dotclock. > > I do have this unreviewed igt series > https://patchwork.freedesktop.org/series/69531/ which extends the > current testing with some other forms of invalid modes. Could probably > extend that with a mode.clock=INT_MAX test to see if anything else might > trip up. > > No idea about other drivers. > > drivers/gpu/drm/drm_modes.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index 501b4fe55a3d..511cde5c7fa6 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -762,7 +762,7 @@ int drm_mode_vrefresh(const struct drm_display_mode *mode) > if (mode->htotal == 0 || mode->vtotal == 0) > return 0; > > - num = mode->clock * 1000; > + num = mode->clock; > den = mode->htotal * mode->vtotal; You don't want to promote den to u64 while you are here? We are at 8kx4k, throw in dblscan and some vscan, and we could soon have wacky refresh rates. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
