* Re: drm_gem_dumb_map_offset patch [not found] <96fb4e89-2721-90bb-ce76-69667c2cf78a@st.com> @ 2019-05-31 11:28 ` Noralf Trønnes 2019-05-31 11:36 ` Daniel Vetter 0 siblings, 1 reply; 4+ messages in thread From: Noralf Trønnes @ 2019-05-31 11:28 UTC (permalink / raw) To: Pierre Yves MORDRET, Daniel Vetter; +Cc: DRI Development 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. > > 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/ Noralf. > Many thanks in advance. > Best Regards > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: drm_gem_dumb_map_offset patch 2019-05-31 11:28 ` drm_gem_dumb_map_offset patch Noralf Trønnes @ 2019-05-31 11:36 ` Daniel Vetter 2019-06-03 12:25 ` Pierre Yves MORDRET 0 siblings, 1 reply; 4+ messages in thread From: Daniel Vetter @ 2019-05-31 11:36 UTC (permalink / raw) To: Noralf Trønnes; +Cc: DRI Development, Pierre Yves MORDRET On Fri, May 31, 2019 at 1:28 PM Noralf Trønnes <noralf@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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: drm_gem_dumb_map_offset patch 2019-05-31 11:36 ` Daniel Vetter @ 2019-06-03 12:25 ` Pierre Yves MORDRET 2019-06-03 13:42 ` Daniel Vetter 0 siblings, 1 reply; 4+ messages in thread From: Pierre Yves MORDRET @ 2019-06-03 12:25 UTC (permalink / raw) To: Daniel Vetter, Noralf Trønnes; +Cc: DRI Development 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 <noralf@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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: drm_gem_dumb_map_offset patch 2019-06-03 12:25 ` Pierre Yves MORDRET @ 2019-06-03 13:42 ` Daniel Vetter 0 siblings, 0 replies; 4+ messages in thread From: Daniel Vetter @ 2019-06-03 13:42 UTC (permalink / raw) To: Pierre Yves MORDRET; +Cc: DRI Development On Mon, Jun 3, 2019 at 2:25 PM Pierre Yves MORDRET <pierre-yves.mordret@st.com> wrote: > > 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. Please note that with dma-buf you need to call the begin/end cpu access ioctl, or depending upon driver/platform the mmap access might be incoherent. -Daniel > > 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 <noralf@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 > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-06-03 13:42 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <96fb4e89-2721-90bb-ce76-69667c2cf78a@st.com> 2019-05-31 11:28 ` drm_gem_dumb_map_offset patch Noralf Trønnes 2019-05-31 11:36 ` Daniel Vetter 2019-06-03 12:25 ` Pierre Yves MORDRET 2019-06-03 13:42 ` Daniel Vetter
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.