Re: asihpi: Need help converting volatile to memory barriers

[Clemens Ladisch <clemens@ladisch.de>]

Eliot Blennerhassett wrote:
> Theres quite a bit written about barriers, but most seems to be assuming SMP
> situation or memory mapped devices. Not much about devices doing DMA.
> I.e I have read Documentation/memory-barriers.txt

See also <Documentation/DMA-mapping.txt>.

> interface->cmd = command;
> wmb();
> iowrite(device_interrupt, 1);
> [device reads interface->cmd by dma]
>
> Is the wmb() a guarantee that the command will be in memory visible to the
> device when the driver informs it of a new command?

Yes.  Please not that accesses to I/O space have an implicit barrier, so
you don't even need the wmb() in this case.

> One assumption I am making is that the compiler is not going to optimise
> across functions
> E.g. in the following scenario, is the compiler going to optimise the loop
> away without a rmb()?  If not, is this because of something inherent in the C
> standard, or just because the optimiser isn't yet smart enough to see it?
> I.e. it might work now, but when whole-file-optimisation is introduced, it
> will fail?
>
> int get_ack(interface) { return interface->ack }
> ...
> while (get_ack(interface) != OK) {
> 	sleep(a while);
> }

The get_ack() function is an obvious candidate for inlining.  The C
standard definitely allows it to be optimized away (if the compiler can
prove that sleep() doesn't write to interface->ack).  Both gcc an icc
are able to do (or plan to introduce) this optimization.


HTH
Clemens