On Mon, 2018-02-05 at 12:49 -0800, Rodrigo Vivi wrote: > On Mon, Feb 05, 2018 at 08:37:13PM +0000, Dave Airlie wrote: > > On 6 February 2018 at 06:32, Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> wrote: > > > On Sat, Feb 03, 2018 at 08:14:48AM +0000, Keith Packard wrote: > > >> Dhinakaran Pandiyan <dhinakaran.pandiyan@xxxxxxxxx> writes: > > >> > > >> > From: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@xxxxxxxxx> > > >> > > > >> > drm_vblank_count() has an u32 type returning what is a 64-bit vblank count. > > >> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user > > >> > space requested vblank sequence using this clipped 32-bit count(when the > > >> > value is >= 2^32) as reference, the requested sequence remains a 32-bit > > >> > value and gets queued like that. However, the code that checks if the > > >> > requested sequence has passed compares this against the 64-bit vblank > > >> > count. > > >> > > >> For patches 1-7: > > >> > > >> Reviewed-by: Keith Packard <keithp@xxxxxxxxxx> > > > > > > Dave, ack to merge them through drm-intel-next-queued ? > > > > Ack. do we know if any of those need to be in -fixes? > > > > or too early to tell? > > I didn't checked the drm one close enough yet to decide for that. > DK or Keith? do you guys see anyone suitable for fixes? I was thinking patch 1 would be a candidate. But, it'd need the crtc to be active continuously for > 2.2 years at 60 frames/s to trigger this. The problem is exacerbated with PSR and PSR is disabled. So, I think we can skip -fixes. > > For the other work on top I believe we don't need to move to fixes > since psr is still disabled. > > > > > Dave. > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
