On Thu, Jun 23, 2016 at 08:17:49AM +0200, Mario Kleiner wrote: > The following patch implements precise vblank timestamping > for RaspberryPi's VC4, at least for standard progressive > scan display modes. > > It has been tested on the HDMI output with half a dozen different > video modes using special hardware measurement equipment to compare > generated time stamps against reality. According to the tests it > works well in its current form. > > Due to hw limitations of the VC4, timestamps can't be scanline > accurate when taken within vblank, as explained in the patch, > but at least they will never be off by more than 1 vblank > duration, and are typically still accurate to ~0.1 msecs > for the common case when the timestamping is triggered from > vblank interrupt. > > The patch exposed some problems with how the drm core handles > calculation of vblank timestamping constants for interlaced > video modes in drm_calc_timestamping_constants(). Seems it cuts > the expected frame duration framedur_ns into half for interlaced > modes two times, so it ends up expecting a field duration half > of what it should be and then miscalculates vblank counter increments > as soon as vblank timestamping is supported and the core tries to > derive vblank counts from it. To work around this bug, for the > moment the vblank timestamping will disable itself for interlaced > modes and only work for regular progressive scan. The code should be correct for i915. The framedur_ns is actually the duration of a single field (since we get a vblank interrupt for each field). But it's going to be wrong for anyone that populates the crtc_ timings with CRTC_INTERLACE_HALVE_V. So to fix it, you'd need the driver to tell drm_calc_timestamping_constants() whether the vertical timings were already halved or not. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
