2013/9/29 Inki Dae <inki....@samsung.com> > > > 2013/9/26 Al Viro <v...@zeniv.linux.org.uk> > >> On Wed, Sep 25, 2013 at 01:34:30PM +0900, Inki Dae wrote: >> >> > It seems that we can use a new anon file instead of using drm file to >> > resolve the issue. >> >> Could you describe what are you trying to achieve with that ioctl() and >> 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@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> > >
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
