On 8/24/06, Joe Hsu <[EMAIL PROTECTED]> wrote:
When the driver thinking DMA is still running and
then trying to update the "tail" pointer, at the almost
same time, DMA might be thinking the "tail" pointer is
the same as old one. Then the DMA engine stops.
And when it stops, it issues an interrupt. We'll wrap some kind of
mutex around the access to the tail pointer so that this race
condition doesn't happen.
I think there may be some condition in the following:
1. CPU check if the DMA engine stops ==> NO
2. GPU check if the tail pounter updated
before letting DMA stopped ==> same old tail pointer, DMA stops
3. CPU update tail pointer
Then we have to add work-around in the driver to
fix the condition, right?
We have two possible race conditions:
- interrupt
- write pointer
or
- write pointer
- interrupt
If the interrupt is going to happen first, this is the sequence of events:
- interrupt
- lock
- set "idle" flag
- unlock
- write pointer
- lock
- modify pointer
- if idle flag set, PIO write to GPU to get it started again
- unlock
If the interrupt is going to happen during or after the write pointer:
- write pointer
- lock
- modify pointer
- set "has commands" flag
- unlock
- interrupt
- lock
- check "has commands" flag
- if flag set, PIO write to GPU to get it started again
- unlock
The real routines would be a combination of those two.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
