> As far as I can understand you refer to the non cocherent DMA memory > allocation functions in arch/ppc/kernel/dma-mapping.c, right? Regarding the > BAT mapping: can you give me an example for this or a link to a reference > implementation?, because I'm afraid I can only image for now, what you're > trying to explane me (as I said, I'm a kernel newbie, but I'll try to do > what I can). :-)
(I'm moving this to the linuxppc-dev list) Well, you need consistent alloc functions to really provide you with non-cached memory. Fushing is not enough. Flushing is fine for dma_map etc..., not for consistent alloc. So in theory, you should be able to re-use the existing consistent allocation functions, except that the current implementation has "issues": The main problem I see with the implementation is that it just allocates pages out of the normal kernel allocator and maps them in the "consistent" virtual range without ever unmapping them from the kernel linear mapping. That means that those pages end up being mapped twice: cacheable and non-cacheable, which is absolutely wrong and will explode in colorful ways on a number of CPUs. The pages should at least be unmapped from the kernel linear (& cacheable) mapping. I understand this is probably done to keep the TLB miss handler for the kernel mapping as fast as possible. Unfortunately, it's also incorrect if your processor is capable of any kind of prefetching accross a 4k boundary. Then, remains the BAT mapping problem. In order to improve performances, the kernel uses BATs to map the main memory (to know more about BATs, look at the proccessor docs). That means that unmapping the memory from the linear mapping will not work if that memory happens to be covered by a BAT (there aren't even page tables entries for those pages anyway). Thus, in order to be able to reliably unmap things from the linear mapping (or individually change page attributes) you need to disable BAT mapping of memory, either completely, or by preallocating (and thus actually reserving) memory outside of the BAT mapping for use in the consistent allocator. However, the exception handling of the kernel is designed with the assumption that it will not take hash faults in some critical locations, and this assumption is correct thanks to ... the BAT mapping. You are lucky though that recent kernels have been fixed to be able to recover from such faults provided the instructions are still BAT mapped, so you can probably hack the initialisation of the memory on ppc to not use data BATs but only instruction BATs and still create the page tables for the entire memory. That will allow you to implement proper unmapping of pages in the consistent allocator. However, it will also impact your overall performances ... Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
