[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?


Other related posts: