Comment # 46
on bug 76564
from jeroen
(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?
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
