Dan Malek wrote: > >David Gibson wrote: > > >> It's becoming easier though, with the __cacheline_aligned macro. Plus >> I think if the buffer is individually kmalloc()ed it will be properly >> aligned. > >Alignment is only half the problem. You have to ensure the object is >modulo cache line size as well. You can't be sharing cache lines subject >to DMA with other DMA or processor core data.
Maybe I need to go drink some coffee, but I'm confused by this thread. The real problem, as I recall, was that cache invalidate routine one in the 405 port didn't respect the addresses handed to it and instead invalidated the entire cache line, even if it went beyond the address range provided. This behavior was different than other ports, specfically the ARM port. I don't think the patch was needed on the ARM. It was just need on the 405. Fixing the usb code is a good idea, but it would just hide the real problem. The original problem was that the USB code was doing DMA off the stack. I don't recommend that, but I can't find any reason why it specifically should not work or not be allowed. (and listen, if you argue that it's philosophically bad I agree - note I said *technically* wrong). When the ohci driver did a cache invalidate on the buffer - in preparation for dma into the buffer - it destroyed part of the stack, the part which had not yet been flushed. On other ports, like the ARM, the cache invalidate routine 'notices' if the address range is not cache line aligned and flushes the parts which are not. I argued long ago (to parties which are present but probably sleeping right now :-)) that this should be changed. I'll make this argument again, now. also, I think the comment in the code is incorrect. I think the code should read that the cache_invalidate routine is broken on some ports. off to make some coffee... -brad ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
