[alsa-devel] [PATCH] wss_lib: do not mess mixer settings during probe

Rene Herman rene.herman at keyaccess.nl
Mon Aug 25 02:23:52 CEST 2008

On 25-08-08 00:37, Rene Herman wrote:

> On 24-08-08 21:48, Krzysztof Helt wrote:
>> From the Documentation/memory-barriers.txt
>> "
>> (*) inX(), outX():
>> ...
>>     They are guaranteed to be fully ordered with respect to each other.
>>     They are not guaranteed to be fully ordered with respect to other 
>> types of
>>      memory and I/O operation.
>> ...
>> "
>> No barriers are needed in this case. 
> On x86 certainly not and I would expect these barriers are there for 
> cases/architectures where inb() and outb() are redefined to memory 
> mapped I/O or there would just be no point at all.
> In that case, the first outb() writes an index and we'd better make sure 
> that it hits the hardware before we write the value. Hence my suspicion 
> that if at all, the mb() should be in between.
> No idea who added those and why...

Well, thinking about this more, I guess it actually makes some sense.

No need for a wmb() in between because we know that the outbs are fully 
ordered (supposedly even when redefined) but being a general accessor 
function we pretend we don't know that the next access is going to be 
through an inb/outb again -- we are supposedly being careful to allow 
combining using this accessor with direct MMIO access on other and/or 
virtualized architectures.

That is... as far as I understand this in the first place. Takashi or 
Jaroslav, do you perhaps remember barriers being added to cs4231_lib() 
and why? Could we just get rid of them?

(context was snipped, but this question is about the mb() in 
snd_cs4231_dout; snd_wss_dout in the new wss_lib form).


More information about the Alsa-devel mailing list