All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Pierre Yves MORDRET <pierre-yves.mordret@st.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: drm_gem_dumb_map_offset patch
Date: Mon, 3 Jun 2019 15:42:14 +0200	[thread overview]
Message-ID: <CAKMK7uG5ZLBqW5cQw6rsy8Lhm2avVpVsDRe3zsrcDFa=y7qpfA@mail.gmail.com> (raw)
In-Reply-To: <e6985208-b386-d522-e433-91d8013eb531@st.com>

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

      reply	other threads:[~2019-06-03 13:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKMK7uG5ZLBqW5cQw6rsy8Lhm2avVpVsDRe3zsrcDFa=y7qpfA@mail.gmail.com' \
    --to=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=pierre-yves.mordret@st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.