[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).
Rene.
More information about the Alsa-devel
mailing list