On Die, 2003-02-04 at 15:43, Vladimir Dergachev wrote:
> > > > RADEONWaitForVerticalSync() polls for. I'm working on a fix, basically
> > > > my plan is to use the DRM vertical blank ioctl when appropriate.
> > >
> > > There is a patch I posted a while ago for the same problem that waits for
> > > retrace with a timeout - so even if the bit is cleared we timeout after
> > > 1/60 of sec (approx) and everything is fine anyway.
> >
> > I don't like that. Polling for CRTC{,2}_VBLANK_SAVE should be foolproof,
> > or am I missing something?
>
> But these bits are cleared by DRM driver to acknowledge an interrupt.
No, the RADEON_GEN_INT_STATUS register is used for interrupts.
You asked how CRTC{,2}_VBLANK_SAVE work, here you go: you clear those
bits by setting CRTC{,2}_VBLANK_SAVE_CLEAR in RADEON_CRTC{,2}_STATUS,
and they go back up on the next vertical blank.
> > > Also, Michel, while you are at it - could you modify the irq handler in
> > > DRM to *only* clear bits that it is actually interested it ? Otherwise it
> > > clears capture and gui_dma IRQs which GATOS km driver needs and which are
> > > not used by drm at all.
> >
> > I wouldn't mind doing that at all, in fact that's how I did it
> > initially, but the code has since been changed with the following
> > comment:
> >
> > /* Acknowledge all the bits in GEN_INT_STATUS -- seem to get
> > * more than we asked for...
> > */
> >
> > Your argument makes a lot of sense so I'll probably change it back in
> > DRI CVS, but I don't know if it'll make it for 4.3.0...
>
> The thing is that we should not be getting any extra bits unless we (or
> someone else like GATOS km) has asked for them. This makes sense as if
> there was a bit set causing an interrupt before drm driver loaded and
> nobody was servicing it the system would lock up.
>
> The reason there are "extra" interrupts without km loaded is likely due to
> IRQ sharing.
What do you mean?
> The simplest way would be to define a mask of interrupts and AND it with
> the current values of GEN_INT_CNTL before clearing acknowledge bits.
Yes, I've committed a fix along those lines to the DRI trunk and mesa-4-0-4-branch,
so it will hopefully go into 4.3.0.
--
Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
