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. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
