Messages in this thread | | | Date | Sun, 11 Nov 2007 15:18:35 +0000 | From | Alan Cox <> | Subject | Re: [PATCH 5/6] MN10300: Add the MN10300/AM33 architecture to the kernel [try #5] |
| |
> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |