On 3/28/2024 7:05 PM, yfliu2008 wrote:
Yes the user land only use standard file operations like "mmap()/read()/write()/munmap()/ioctl()" etc to access the device memory and interruption status via the exposed device files like "/dev/uio3" etc.
Sorry it took me so long to catch on.
My original question was about things in Nuttx Kernel side to support implement the required "mmap()/munmap()" operations. It seems that we need: A way to mark the user address regions so that to distinguish free and in use mapped regions. We also need separate this space from existing user space regions like TEXT, DATA, HEAP, SHM etc as it is for UIO purposes. A way to set the user space mappings via "int up_addrenv_uio_map(va, pa, length, flags)" and the counter part. These mainly operates the MMU page table entries with proper flags. Add an UIO component in "drivers/uio/uio.c" which exposes the "int uio_register(path, paddr, length, irq)" method for BSP to use to instantiate the needed devices. My purpose wasn't about video display, but this is what I got from the "fb" example in kernel mode now: ...
You might also want to look at the (fake) file mapping. It doesn't do much.
... Currently the video device driver returns physical address directly in the "mmap()", which should be mapped in the user space for kernel build however.
The driver level should return the virtual address. The actual framebuffer driver is in drivers/video/fb.c. It is a character driver that is more-or-less an upper half for the lcd driver. It gets the "planeinfo" from the lcd driver getplaneinfo() method which includes the virtual address of the framebuffer (line 1184) and eventually returns that address with the offset in the fb_mmap method (line 1035). [The offset means something different in UIO]
On all platforms that I am aware of, the virtual address of the framebuffer is just a configurable constant. This makes sense if the framebuffer is in a fixed virtual address in every process. The kernel can manage the virtual address space anyway that it likes. A fixed virtual position for the framebuffer is a reasonable decision. More logic is need to manage the virtual address space to handle things like pthread stacks, heap, shared libraries, framebuffers, etc. The logic and virtual memory layout in Linux is quite complex even though all of these are at fixed virtual addresses in every process.
I would do the same. It is more efficient and guarantees no virtual address overlap.
I am unsure if video display is a good use case for UIO but that is what I can test now with "rv-virt".
It is not a bad case either. It does a lot of what you want to do.
