> So you would say change the global h/w register variables[*] to be addresses > instead, and change all the references to be readX and writeX? I'm wary of
Ok so these are not addresses but magic registers in the processor ? Then I guess volatile makes complete sense. > > Similarly spin_lock/unlock are store barriers so for ring buffers should > > be sufficient unless you have cache management requirements in which case > > the dma_* APIs will handle those bits. > > I don't actually need locks, but sticking smp_rmb()/smp_wmb() is probably the > right thing to do now that I know how to use them. This code was written five > or six years ago and I haven't really thought about changing that since. > > I don't see how the dma_* APIs would help. The buffer is filled by a higher > priority interrupt routine that does 'virtual DMA'. It's not actually done by > real DMA. Normal interrupt disablement doesn't really disable interrupts, it > justs excludes normal priority interrupts. For real DMA the dma_ APIs keep coherency > The virtual DMA is done is ASM as it has to be really quick. It's > unfortunate, > but, the on-chip serial ports don't have a FIFO. For PIO (virtual DMA or otherwise) the locking does that. Because spin_unlock and spin_lock are compiler barriers the need to use volatile shouldn't normally be there. If you are doing it via asm without locks then I would expect atomic_t because the sematics of volatile are horribly vague on their own ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
