https://bugs.freedesktop.org/show_bug.cgi?id=76564
--- Comment #46 from jeroen jeroenk61@hotmail.com --- (In reply to comment #45)
(In reply to comment #44)
(In reply to comment #43)
We could also update the adjusted mode clock to the actual clock set by the pll so that drm_calc_timestamping_constants() uses the actual clock value on the PLL. E.g.,
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index daa4dd3..2a2da82 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -1085,6 +1085,7 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, struct drm_display_mode atombios_crtc_program_ss(rdev, ATOM_ENABLE, radeon_crtc->pll_id, radeon_crtc->crtc_id, &radeon_crtc->ss); }
mode->clock = pll_clock * 10;}
static int dce4_crtc_do_set_base(struct drm_crtc *crtc,
I think that would only help if radeon_compute_pll_avivo could not compute an exact match. In the case of 23.976Hz the target clock is 74170kHz and the PLL is set exactly to this value. This does raise another question why the target clock' last digit is always zero? For example, for 23.976Hz the target clock should be 74176kHz (with correct rounding). I looked through the source code, but the target clock seems to come all the way from some deep generic drm code.
74176kHz could be matched by the PLL using fb=927.2, post_div=10 and ref_div=125
You might want to take a look at atombios_adjust_pll which does the mode fixup before a mode is actually used.
Since atombios always works with 10khz pixel clock which always sets the target clocks last digit to zero.
atombios_adjust_pll seems to do nothing to compensate for the 10kHz pixel clock, or didn't you mean that?
When I look at drm_calc_timestamping_constants(), does this mean the vblank moment is calculated by the OSS driver?
What about Alex' idea in comment 43? Would tat help Christian?