[wdmaudiodev] WavePCI issue with multiple processors
- From: "Jeff Pages" <jeff@xxxxxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Mon, 26 Mar 2007 16:48:54 +1000
Looking at the AC97 WavePCI example in the WDK, it would appear that GetMapping
can be called in response to a system call to Service, MappingAvailable or
SetState (setting the state to KSSTATE_RUN). Since GetMapping must be called
without any spin locks held, it's quite possible in a multiprocessor system for
GetMapping to be called more or less simultaneously from any of these sources.
This leads to the problem of acquiring mappings out of order, since the order
in which they are placed into the hardware DMA queue is essentially the order
in which the driver's spin lock is reacquired after the calls to GetMapping.
According to the WDK documentation, MappingAvailable is only supposed to be
called after a previous call to GetMapping has failed, so on this basis it
ought to be possible to prevent this problem by only calling GetMapping in
response to a call to Service if the previous call to GetMapping succeeded,
using InterlockedXxx operations. Thus at any given time, GetMapping will be
called in response to MappingAvailable or Service but not both.
However, on Windows XP and Vista (but not 2000) there's an undocumented
pre-emptive call to MappingAvailable when the stream is first started. This is
okay if I then don't call GetMapping from SetState (instead relying on this
pre-emptive call to start the ball rolling) but then my driver doesn't work on
Windows 2000. In any case I don't want to rely on undocumented functionality.
So what's the story with this pre-emptive call to MappingAvailable? Is it
supposed to happen, and if so, under what circumstances? It looks like it's
happening in the transition from KSSTATE_PAUSE to KSSTATE_ACQUIRE, but is this
always the case? Can this behaviour be documented, please?
Jef
Other related posts:
