Hi all, Many thanks for your valuable support and answers.
Since Dumb mmap is for buffer created using dumb_create ioctl we won't use it anymore. In place a mmap/ummap is called with DMA Buf FD. After some tests it seems working in our side. Many thanks again. Regards. On 5/31/19 1:36 PM, Daniel Vetter wrote: > On Fri, May 31, 2019 at 1:28 PM Noralf Trønnes <nor...@tronnes.org> wrote: >> >> Hi, >> >> [add Daniel Vetter] >> [cc dri-devel] >> >> Den 29.05.2019 15.09, skrev Pierre Yves MORDRET: >>> Hello Noralf, >>> >>> Sorry for bothering you with question but I need to better understand the >>> rational about a patch you did in DRM/GEM. >>> >>> First of all, let me introduce myself. >>> I'm currently employee to STMicroelectronics company and in charge of GPU >>> integration within STM32 MPU (Cortex A7 + Cortex M4) >>> >>> On Cortex A7 is running a Linux Kernel 4.19 as for today. >>> >>> We came across some trouble when we switch from Kernel 4.14 to 4.19 for GPU >>> stack. On august you submit this commit : >>> >>> 90378e58919285637aa0f063c04ba0c6449d98b1 >>> drm/gem: drm_gem_dumb_map_offset(): reject dma-buf >>> >>> Reject mapping an imported dma-buf since is's an invalid use-case. >>> >>> In Userland GPU stack we have such statements : >>> bo_map_fd >>> DRM_IOCTL_MODE_MAP_DUMB >>> mmap (offset) >>> >>> With the patch above, ioctl returns an error EINVAL and prevents the nmap. >>> As for today we revert this patch and it works fine in our end. > > Link to source code would be good. > >>> Thus the questions are : >>> - what is the rational behind this fix ? >>> - What we doing wrong this situation ? >>> - What do we need in such situation ? >>> >> >> I need to pass those on to Daniel Vetter (DRM maintainer) since he >> wanted the change. The details were never clear to me. >> Some of the discussion is here: >> https://patchwork.freedesktop.org/patch/172242/ > > Dumb mmap is for buffer created using dumb_create ioctl, and nothing > else. Anything else really has at best undefined behaviour. E.g. for > dma-buf you really need to call the begin/end_cpu_access ioctl, and > dumb buffers simply have no provision for that. Hence why we can't > support this in general. > > Thanks, Daniel > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
