Messages in this thread | | | Subject | Re: [Unichrome-devel] Dragging window in X causes soundcard interrupts to be lost | From | Lee Revell <> | Date | Wed, 01 Sep 2004 14:57:10 -0400 |
| |
On Sat, 2004-07-31 at 19:37, Alan Cox wrote: > On Sul, 2004-08-01 at 01:25, Lee Revell wrote: > > Do you have the original driver source from VIA handy? This is looking > > more and more like a hardware bug - 2D acceleration engine activity > > causes interrupts from the PCI slot to be disabled for long periods. > > I do. There is no code in the 2D engine that touches interrupt control > at all. > > > Maybe it disables interrupts to prevent other processes writing to the > > shared video/system RAM as it DMAs. I would like to verify that the > > problem still occurs with their driver, before I try to convince them > > there's a hardware issue with the EPIA boards. > > A similar problem occurs with some other chips when you write enough > data to the chip that the FIFO fills and the PCI bus locks until the > write can complete. Various vendors implemented this at one point for > benchmarketing reasons and that would have a similar effect if so. > > The 2D driver source is essentially the same as the source in Xorg CVS > barring cleanups and the accelerator code has not changed at all. You > might want to take a look at the fifo management side of things in that > code.
OK, turns out that my (and your, and Thomas Hellstrom, the Unichrome maintainer's) theory was correct - this is exactly what is happening:
On Wed, 2004-09-01 at 03:53, Thomas Hellström wrote: > > I've think I've found an answer to this, and it seems to be related to > what I mentioned earlier, namely that any attemt to write over PCI to a > busy video engine will halt the processor until the video accepts new > data. > > The wait-for-idle loop seems only to be used as a flush-and-sync, to make > sure that accelerated rendering has completed. There is probably no check > for ongoing engine activity before writing to the 2d engine. Same as for > VIA's own mpeg2 code. Such a check will be implemented and will cause a > very slight overhead compared to today's code. > > I'm starting to fix this as part of compatibility with the new drm with > AGP DMA transfers, when available. This will not go into "production" for > about least two or three weeks, but if you are interested, I could send > you an updated via_accel.c sooner to see if it cures your problem. > > Regards > Thomas >
So, it looks like vendors are still up to the same tricks...
Lee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |