2013/9/29 Inki Dae <inki.dae@xxxxxxxxxxx>
2013/9/26 Al Viro <viro@xxxxxxxxxxxxxxxxxx>On Wed, Sep 25, 2013 at 01:34:30PM +0900, Inki Dae wrote:Could you describe what are you trying to achieve with that ioctl() and
> It seems that we can use a new anon file instead of using drm file to
> resolve the issue.
what semantics do you want from normal mmap()?Ok, The reason that we are using ioctl mmap is that I thought it doesn't need demand paging mechanism for drm driver for ARM SoCs: they have no iommu so need physically continuous memory for DMA.
Sorry, there was a wrong comment. it's not all ARM SoC have no iommu. Exynos also has the iommu, and maybe recently most SoCs.
And another reason is that dumb* interface - it seems that you say this interface is a normal mmap but this is a fake mmap - has more steps against ioctl mmap. So to map some user space with physical pages, first, application should request a gem allocation, and then request a hash key of the allcated gem, and then fake mmap. This fake mmap system call doesn't map a given user space with the physical pages. And then the user space will be mapped with the physical pages by page fault handler when cpu tries to access the user space. On the other hand, the ioctl mmap call will map the user space with physical pages, and I thought this way would have better performance than normal mmap at least in case of ARM based SoC.And last, the reason I had implemented the normal mmap is that dumb* interfaces are required as default. i.e. modetest app of libdrm uses only dumb interfaces for buffer management.Anyway,we have faced with some issues by using ioctl mmap and normal mmap together, and these issues should be fixed.Thanks,Inki Dae_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
