From: Michel <mi...@da...> - 2005-01-19 15:59:38
|
On Wed, 2005-01-19 at 13:32 +0100, Roland Scheidegger wrote: > Michel D=C3=A4nzer wrote: > > On Tue, 2005-01-18 at 20:43 +0100, Roland Scheidegger wrote: > >=20 > >>>> The DRM could update the register in the vblank interrupt > >>>> handler? > >=20 > >=20 > > [...] > >=20 > >=20 > >> How would you do that in-kernel? There is vblank interrupt related > >> stuff (radeon_driver_vblank_wait for instance), but that only is > >> called when a user has requested a wait for vblank, as far as I can > >> see (which is all the time with dri clients). > >=20 > >=20 > > You'd have to do it in radeon_driver_irq_handler() or a bottom half > > (but I don't know if these will meet the timing requirements either, > > in particular the latter...). > What about the 2nd head? I guess it would be necessary to update its > offset at a different time, is there something like a=20 > RADEON_CRTC2_VBLANK_STAT bit? Yeah. BTW, how to do sync-to-vblank correctly for MergedFB is a whole other issue... > Also, this looks like it would get really ugly. Use an ioctl to tell drm=20 > it needs to update the offsets, then it will update them in the irq=20 > handler? That would mean we need something different for dispatch_flip=20 > (since more flips can happen while waiting for vblanks, in that time the=20 > old offsets have to be used),=20 Or you could say that if the flips aren't synchronized to the refresh, it might not matter for panning either... > and furthermore there needs to be some code to deal with disabled irqs. > Is this such a big issue? I'm happy to leave it broken. I don't know, you brought it up, I just brainstormed how it could be done. :) > >> Also, if doing that in the drm, we'd need to mess with OFFSET_CNTL > >> there too (i.e. messy calculation or another field in the sarea). > >=20 > >=20 > > You mean CRTC_OFFSET? I'm not sure the calculation is that big an=20 > > issue... it'll never happen more than a couple thousand times per > > second anyway. ;) > Well, both CRTC_OFFSET and CRTC_OFFSET_CNTL.=20 The latter shouldn't matter if the writes are synchronized to the refresh anyway? Unless the update triggers at the same time the interrupt is generated without FLIP_CNTL... > It's not really the time which the calculation uses, but I just don't=20 > like additional ugly code. Well, you could always hide it in a function or something. ;) > Well, the most important issue with that is that RADEON_WAIT_CRTC_PFLIP=20 > doesn't actually wait for a pageflip! It made absolutely no difference.=20 > Maybe with FLIP_CNTL set, it now considers it as a pageflip whenever it=20 > hits a new line, dunno. Sure. There's a way to wait for a certain scanline instead, if you want to explore that... --=20 Earthling Michel D=C3=A4nzer | Debian (powerpc), X and DRI develop= er Libre software enthusiast | http://svcs.affero.net/rm.php?r=3Ddaenzer |