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
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
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
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
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Noralf Trønnes -
Pierre Yves MORDRET