lkml.org 
[lkml]   [2004]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Unichrome-devel] Dragging window in X causes soundcard interrupts to be lost
From
Date
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/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.047 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site