dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Starkey <brian.starkey@arm.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: narmstrong@baylibre.com, daniel.vetter@ffwll.ch,
	liviu.dudau@arm.com, dri-devel@lists.freedesktop.org,
	thierry.reding@gmail.com, laurent.pinchart@ideasonboard.com,
	daniel.vetter@intel.com, marex@denx.de,
	boris.brezillon@free-electrons.com, abrodkin@synopsys.com,
	linux@armlinux.org.uk, z.liuxinliang@hisilicon.com,
	kong.kongxinwei@hisilicon.com, tomi.valkeinen@ti.com,
	airlied@redhat.com, puck.chen@hisilicon.com, jsarha@ti.com,
	vincent.abriou@st.com, alison.wang@freescale.com,
	sw0312.kim@samsung.com, philippe.cornu@st.com,
	yannick.fertre@st.com, kyungmin.park@samsung.com,
	zourongrong@gmail.com, maxime.ripard@free-electrons.com,
	shawnguo@kernel.org, kraxel@redhat.com
Subject: Re: [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf
Date: Tue, 29 Aug 2017 17:03:19 +0100	[thread overview]
Message-ID: <20170829160318.GA38369@e107564-lin.cambridge.arm.com> (raw)
In-Reply-To: <20170825133433.kninmowvl2u2vs5a@phenom.ffwll.local>

On Fri, Aug 25, 2017 at 03:34:33PM +0200, Daniel Vetter wrote:
>On Thu, Aug 24, 2017 at 11:04:01AM +0100, Brian Starkey wrote:
>> Hi,
>>
>> Thanks for the CC.
>>
>> On Fri, Aug 18, 2017 at 06:13:14PM +0200, Noralf Tr??nnes wrote:
>> > (cc affected parties)
>> >
>> >
>> > Den 18.08.2017 09.46, skrev Daniel Vetter:
>> > > On Thu, Aug 17, 2017 at 06:21:30PM +0200, Noralf Tr??nnes wrote:
>> > > > Reject mapping an imported dma-buf since is's an invalid use-case.
>> > > >
>> > > > Cc: Philipp Zabel <p.zabel@pengutronix.de>
>> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> > > > Cc: Sean Paul <seanpaul@chromium.org>
>> > > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > > > Signed-off-by: Noralf Tr??nnes <noralf@tronnes.org>
>> > > I think acks from someone using mali would be good too. amdgpu already has
>> > > such checks, so I think on the desktop side we're ok.
>> > >
>>
>> This looks like it would break anyone running the Mali-4xx series GPUs
>> with the Arm graphics stack (e.g. Hikey board).
>>
>> I don't know where that sits in terms of policy.
>
>Why would this break this use-case? Is the mali blob somehow using dumb
>mmap for it's own buffers it shares with display? That would be rather
>backwards ...

If it's running with a DRM display driver (which may or may not be
Mali-DP, they are separate IPs), then its window system code always
uses dumb mmap if it needs a pointer. That might be a native DRM
buffer that the display driver allocated, or a dma-buf which it PRIME
imported (which would now fail).

-Brian

>
>Either way, blob -> meh, not a concern really.
>-Daniel
>
>>
>> Cheers,
>> -Brian
>>
>> > > Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> > >
>> > > But I think this one here definitely needs a few more acks. I could break
>> > > uabi if we're unlucky, so let's not rush it.
>> >
>> > Ok, I've CC'ed the affected parties to increase the odds that they look
>> > at this. These are the drivers using drm_gem_dumb_map_offset()
>> > (hopefully I got the list right):
>> >
>> > arc
>> > atmel-hlcdc
>> > cirrus
>> > exynos
>> > fsl-dcu
>> > gma500
>> > hdlcd
>> > imx
>> > kirin
>> > mali-dp
>> > mediatek
>> > meson
>> > mxsfb
>> > pl111
>> > rcar-du
>> > rockchip
>> > shmobile
>> > sti
>> > stm
>> > sun4i
>> > tegra
>> > tilcd
>> > vc4
>> > zte
>> >
>> >
>> > Noralf.
>> >
>> > > -Daniel
>> > >
>> > > > ---
>> > > >  drivers/gpu/drm/drm_gem.c | 6 ++++++
>> > > >  1 file changed, 6 insertions(+)
>> > > >
>> > > > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>> > > > index ad4e9cf..8da5801 100644
>> > > > --- a/drivers/gpu/drm/drm_gem.c
>> > > > +++ b/drivers/gpu/drm/drm_gem.c
>> > > > @@ -333,6 +333,12 @@ int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device *dev,
>> > > >  	if (!obj)
>> > > >  		return -ENOENT;
>> > > > +	/* Don't allow imported objects to be mapped */
>> > > > +	if (obj->import_attach) {
>> > > > +		ret = -EINVAL;
>> > > > +		goto out;
>> > > > +	}
>> > > > +
>> > > >  	ret = drm_gem_create_mmap_offset(obj);
>> > > >  	if (ret)
>> > > >  		goto out;
>> > > > --
>> > > > 2.7.4
>> > > >
>> >
>
>-- 
>Daniel Vetter
>Software Engineer, Intel Corporation
>http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-08-29 16:03 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-17 16:21 [PATCH v3 0/2] drm/dumb-buffers: Add defaults for .dumb_map_offset and .dumb_destroy Noralf Trønnes
2017-08-17 16:21 ` [PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf Noralf Trønnes
2017-08-17 17:56   ` Laurent Pinchart
2017-08-17 18:30     ` Chris Wilson
2017-08-17 19:01       ` Laurent Pinchart
2017-08-17 19:09         ` Chris Wilson
2017-08-17 19:40           ` Laurent Pinchart
2017-08-17 20:01             ` Chris Wilson
2017-08-17 22:35               ` Laurent Pinchart
2017-08-18  7:45                 ` Daniel Vetter
2017-08-18  8:01                   ` Laurent Pinchart
2017-08-18  8:21                     ` Chris Wilson
2017-08-18  7:46   ` Daniel Vetter
2017-08-18 16:13     ` Noralf Trønnes
2017-08-18 17:41       ` Eric Anholt
2017-08-18 20:17         ` Daniel Vetter
2017-08-18 20:34           ` Eric Anholt
2017-08-18 21:01             ` Daniel Vetter
2017-08-18 23:37               ` Eric Anholt
2017-08-24 10:04       ` Brian Starkey
2017-08-25 13:34         ` Daniel Vetter
2017-08-29 16:03           ` Brian Starkey [this message]
2017-08-30  7:44             ` Daniel Vetter
2017-08-30  8:38               ` Brian Starkey
2017-09-02 12:42       ` Noralf Trønnes
2017-08-21  5:26   ` Thierry Reding
2017-08-17 16:21 ` [PATCH v3 2/2] drm/armada: Use .dumb_map_offset and .dumb_destroy defaults Noralf Trønnes
2017-08-18  7:47   ` Daniel Vetter
2017-08-30  8:25     ` Daniel Vetter

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=20170829160318.GA38369@e107564-lin.cambridge.arm.com \
    --to=brian.starkey@arm.com \
    --cc=abrodkin@synopsys.com \
    --cc=airlied@redhat.com \
    --cc=alison.wang@freescale.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=kong.kongxinwei@hisilicon.com \
    --cc=kraxel@redhat.com \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux@armlinux.org.uk \
    --cc=liviu.dudau@arm.com \
    --cc=marex@denx.de \
    --cc=maxime.ripard@free-electrons.com \
    --cc=narmstrong@baylibre.com \
    --cc=philippe.cornu@st.com \
    --cc=puck.chen@hisilicon.com \
    --cc=shawnguo@kernel.org \
    --cc=sw0312.kim@samsung.com \
    --cc=thierry.reding@gmail.com \
    --cc=tomi.valkeinen@ti.com \
    --cc=vincent.abriou@st.com \
    --cc=yannick.fertre@st.com \
    --cc=z.liuxinliang@hisilicon.com \
    --cc=zourongrong@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox