[alsa-devel] asihpi: Need help converting volatile to memory barriers

[Eliot Blennerhassett]

Greetings,

first, the meta-help request:
Is there another place that I should be making this request? (lkml, kernel 
newbies, linux driver project etc)?

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

Now the actual question:
Currently I have a driver that uses "volatile" - heres the relevant source.
http://hg.alsa-project.org/alsa-driver/file/89222d702376/pci/asihpi/hpi6205.c

The "volatile" is applied to structures that are either read or written by 
device DMA.  Certainly the driver in its current state doesn't work without 
volatile qualifier. (BTW the device doesn't use host interrupts)

Structures ("interface") used for dma are allocated with dma_alloc_coherent()

In the following, am I using the barriers correctly?

1) Reading something updated by DMA

volatile struct bus_master_interface *interface;
while (interface->ack != OK) { 
	sleep(a while)  	
	[ device changes interface->ack by dma ]
};
=== after conversion
struct bus_master_interface *interface;
while (interface->ack != OK) { 
	sleep(a while);
	rmb(); 
};

Here the volatile or rmb is needed or the loop gets optimised away.

2) Writing to memory, interrupt device

volatile struct bus_master_interface *interface;
interface->cmd = command;
iowrite(device_interrupt, 1);

=== after conversion ===
struct bus_master_interface *interface;
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?


3) 

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);
}


regards

--
Eliot Blennerhassett
www.audioscience.com