* Re: [Unichrome-devel] Dragging window in X causes soundcard interrupts to be lost
2004-07-31 23:37 ` Alan Cox
@ 2004-08-01 0:56 ` Lee Revell
2004-09-01 18:57 ` Lee Revell
1 sibling, 0 replies; 4+ messages in thread
From: Lee Revell @ 2004-08-01 0:56 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
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.
>
Yes, I saw that. This basically means it has to be a hardware bug,
correct?
> > 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.
>
This was the first thing that occurred to me, but I am not really a
video driver expert, and looking at the code it's just banging bits. I
have hacked device drivers, just not video, and I don't have the
bandwidth to learn right now.
> 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.
>
> > On that note, assuming I verify the bug, does anyone have any
> > recommendations for getting VIA to take me seriously? The problem is
> > very easy to reproduce.
>
> I have some contact with VIA however you need to understand that the
> graphics world moves rapidly. I would be suprised if the CLE266 saw any
> more development given the CN400 has been demoed, although I certainly
> can't speak for VIA on this matter.
>
Yes, I would be happy to just get an acknowledgement of the issue.
Actually I don't even need that, I just want to know if it's fixed in
the newer ones. I have a perfectly acceptable workaround. The 2D
acceleration is pretty shoddy anyway, many things seem to work better
with NoAccel. I still love the EPIA board.
Maybe you could forward this on to them? Off the record is fine.
Lee
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Unichrome-devel] Dragging window in X causes soundcard interrupts to be lost
2004-07-31 23:37 ` Alan Cox
2004-08-01 0:56 ` Lee Revell
@ 2004-09-01 18:57 ` Lee Revell
1 sibling, 0 replies; 4+ messages in thread
From: Lee Revell @ 2004-09-01 18:57 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 4+ messages in thread