On Fri, May 31, 2019 at 1:28 PM Noralf Trønnes <noralf@xxxxxxxxxxx> 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel