Re: [linuxsh-dev] mmap caching problem

[peter g. <pga...@li...>]

Hi,
Although I abandoned the shared memory approach to that particular device driver, I would say that the following occurred.

I allocated some memory in a driver and using mmap, passed it to a user space program. An interrupt routine in the driver modified the memory, but changes were not immediately reflected in the memory seen by the user space program, even when the mmap used uncached memory.

I believe that the reason for this was that the kernel driver accessed the memory using a P1 address, which is no address translation, caching on. I think that the SH4 uses different caching for the same memory but with different addresses, in this case user space and P1 area.

I believe that a useful test would have been to try accessing the memory in the kernel driver using the P2 area, by just adding 0x20000000 to the address of the ram. The P2 area is no address translation, no caching. If the kernel driver had no caching, and also user space had no caching, it should have worked.

Instead of using the P2 area, a special SH4 instruction OCBWB to flush the cache at a particular address could also have been used by the kernel driver after modifying the memory area.

I do not know how to specify non-caching for kernel space access in a reasonably portable manner though. The user space memory sets the VM_IO bit in the vm_flags field in the mmap operation. The kernel driver allocates the memory using the call get_zeroed_pages(GFP_KERNEL). I have just tested this call right now and in returns an address at 0x8cea4000, which is in the P1 area, which is cacheable.

So I conclude that all that is necessary is some way to specify non-cacheable memory when allocating pages in a kernel device driver.

  Cheers.
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze