> > > 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.

>
> > 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.

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.

                            best

                               Vladimir Dergachev

>
>
> --
> 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
>
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel

Reply via email to