Hi, All
We met question about dmac_map_area & dmac_flush_range from user addr. mcr would not return on armv7 processor.
Existing ion carveout heap does not support partial cache flush. Total cache will be flushed at all.
There is only one dirty bit for carveout heap, as well as sg_table->nents. drivers/gpu/ion/ion_carveout_heap.c ion_carveout_heap_map_dma -> sg_alloc_table(table, 1, GFP_KERNEL); ion_buffer_alloc_dirty -> pages = buffer->sg_table->nents;
We want to support partial cache flush. Align to cache line, instead of PAGE_SIZE, for efficiency consideration. We have considered extended dirty bit, but looks like only align to PAGE_SIZE.
For experiment we modify ioctl ION_IOC_SYNC on armv7. And directly use dmac_map_area & dmac_flush_range with add from user space. However, we find dmac_map_area can not work with this addr from user space. In fact, it is mcr can not work with addr from user space, it would hung. Also, ion_vm_falut would happen twice. The first time is from __dabt_usr, when we access the mmaped buffer, it is fine. The second is from __davt_svc, it is caused by mcr, it is strange?
ION malloc carveout heap addr = user mmap user access addr, ion_vm_fault (__dabt_usr), build page table, and vm_insert_page. dmac_map_area & dmac_flush_range with addr -> ion_vm_fault (__davt_svc) mcr hung.
Not understand why ion_vm_fault happen twice, where page table has been build. Why mcr will hung with addr from user space.
Besides, no problem with ION on 3.0, which do not use ion_vm_fault.
Any suggestion?
Thanks