Ralf Baechle <ralf@xxxxxxxxxxxxxx> writes: > That's fine. You just need to ensure that there are no virtual > aliases. Does this include virtual aliasing between a 4 KB TLB-mapped page and a kseg0 address? I don't really have two TLBs pointing to the same page. > One way to do so is to increase the page size to 16kB. Right, this way we will have a unique mapping from the virtual address to the data cache, as the cache size (per way) is 8 KB here. Is it the correct fix in this situation? > Note that there is a variant of the 24K which has a VIPT cache but uses > hardware to resolve cache aliases. That is, from a kernel cache management > perspective it behaves like a PIPT cache. It seems it's not the case here. What I have here is: CPU revision is: 00019374 (MIPS 24Kc) SoC: Atheros AR7161 rev 2 Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes > However as I understand what you're mapping to userspace is actually > device memory, right? Not exactly - I'm using PCI DMA to userspace SG buffers in RAM. The userspace first allocates the buffers in normal RAM (with vmalloc() or something, there is an mmap ioctl() for this), the address returned is 0x7xxxxxxx. Then the buffers (which consist of several pages each) are presented to the hw driver which obtains separate (kernel) mapping for each page (kseg0) and does dma_map_sg() and so on. The driver also simply writes to the buffers. This isn't a problem, though - only the incoherence between TLB and kseg0 is. The problem is the userspace doesn't see the kernel writes - The 0x7xxxxxxx TLB-mapped pages are read-cached and not invalidated while the kernel writes to the same pages using kseg0 addresses. Thanks for looking at this. -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
