From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [RFC] dma-buf: Implement test module Date: Sat, 14 Dec 2013 13:37:10 +0100 Message-ID: <20131214123709.GE17467@mithrandir> References: <1386858989-1487-1-git-send-email-treding@nvidia.com> <52AA0FC4.3090606@vmware.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0207950026==" Return-path: Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by gabe.freedesktop.org (Postfix) with ESMTP id 2F423FA7D4 for ; Sat, 14 Dec 2013 04:37:13 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id e11so1725498bkh.23 for ; Sat, 14 Dec 2013 04:37:12 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org To: Daniel Vetter Cc: "linaro-mm-sig@lists.linaro.org" , Greg Kroah-Hartman , Thomas Hellstrom , Linux Kernel Mailing List , dri-devel List-Id: dri-devel@lists.freedesktop.org --===============0207950026== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UnaWdueM1EBWVRzC" Content-Disposition: inline --UnaWdueM1EBWVRzC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote: > On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom = wrote: > > On 12/12/2013 03:36 PM, Thierry Reding wrote: > >> > >> This is a simple test module that can be used to allocate, export and > >> delete DMA-BUF objects. It can be used to test DMA-BUF sharing in > >> systems that lack a real second driver. > >> > >> > > > > Looks nice. I wonder whether this could be extended to create a "stream= ing" > > dma-buf from a user space mapping. That could be used as a generic way = to > > implement streaming (user) buffer objects, rather than to add explicit > > support for those in, for example, TTM. >=20 > Atm there's no way to get gpus to unbind their dma-buf mappings, so > their essentially pinned forever from first use on. Shouldn't this work by simply calling the GEM_CLOSE IOCTL on the handle returned by drmPrimeFDToHandle()? I mean that should drop the last reference on the GEM object and cause it to be cleaned up (which should include detaching the DMA-BUF). Thierry --UnaWdueM1EBWVRzC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSrFD1AAoJEN0jrNd/PrOhkOcQAIU6mAIRpiWsMNzIRAxEVmSM 0Ny2doua3ABovzlUfSzyliCBp/Dyu9AX3G0oEJK5hDTaNpE5ExBEEAIRhJ6zOIq9 oIBTgsI5Q3fYs8GvugzxbiiUXwhJQS2t8kjLIig9SdIB5rwwnpZBB2bUz2w7XAg+ zg+duUnRUzISHPJqslcob1Va62XzGIAVG1enGpJCRlsROIxwtoihq+31y2kFA7xt IKsl0f/60vebHVNTWqyhd6d07saxExH+gDZ34fhU7Z8kfAFZf49/ZrCiuR5Z78Ak Jugllj86buGjCMfVO4Z5xdkJ27zoNunFdZ6dk3rKFgtM/MrDhP+MK4j2YPUL5u8+ p8SMB1cTX6lT8rlD5v2MFg4RnL/td9vqsZydhrNLKrRYFThvQqW3ZRISYaPDI3yq vxVGd6apBOwkfikwlomD9meuV4pOHLoNXoK7Urz20eRZp2wzn2hrNneKeYei6WJi 7vjQIh2BUFlIB3xd5a81kKJO7Px3z9gs/2+mxMtO4KYOuhw7wCaIT5Nm7JmkQVvu mRWlYA7x3LMRt2d6RQoJianKidV1J6xzIpW6S0IhvE6jOxUoLlXzmi/0vD6EpLz8 BmfaDFRreL2Rf7RQ/Aw0h0cNuCLAB/0I67bmiGkQbxvVe3sgoLibCwoeGAi9xIpp VWtxBzqfg3wiEKuzn+lx =8jiv -----END PGP SIGNATURE----- --UnaWdueM1EBWVRzC-- --===============0207950026== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel --===============0207950026==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753557Ab3LNMhP (ORCPT ); Sat, 14 Dec 2013 07:37:15 -0500 Received: from mail-bk0-f52.google.com ([209.85.214.52]:34458 "EHLO mail-bk0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753053Ab3LNMhN (ORCPT ); Sat, 14 Dec 2013 07:37:13 -0500 Date: Sat, 14 Dec 2013 13:37:10 +0100 From: Thierry Reding To: Daniel Vetter Cc: Thomas Hellstrom , "linaro-mm-sig@lists.linaro.org" , Greg Kroah-Hartman , dri-devel , Linux Kernel Mailing List Subject: Re: [RFC] dma-buf: Implement test module Message-ID: <20131214123709.GE17467@mithrandir> References: <1386858989-1487-1-git-send-email-treding@nvidia.com> <52AA0FC4.3090606@vmware.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UnaWdueM1EBWVRzC" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --UnaWdueM1EBWVRzC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote: > On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom = wrote: > > On 12/12/2013 03:36 PM, Thierry Reding wrote: > >> > >> This is a simple test module that can be used to allocate, export and > >> delete DMA-BUF objects. It can be used to test DMA-BUF sharing in > >> systems that lack a real second driver. > >> > >> > > > > Looks nice. I wonder whether this could be extended to create a "stream= ing" > > dma-buf from a user space mapping. That could be used as a generic way = to > > implement streaming (user) buffer objects, rather than to add explicit > > support for those in, for example, TTM. >=20 > Atm there's no way to get gpus to unbind their dma-buf mappings, so > their essentially pinned forever from first use on. Shouldn't this work by simply calling the GEM_CLOSE IOCTL on the handle returned by drmPrimeFDToHandle()? I mean that should drop the last reference on the GEM object and cause it to be cleaned up (which should include detaching the DMA-BUF). Thierry --UnaWdueM1EBWVRzC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJSrFD1AAoJEN0jrNd/PrOhkOcQAIU6mAIRpiWsMNzIRAxEVmSM 0Ny2doua3ABovzlUfSzyliCBp/Dyu9AX3G0oEJK5hDTaNpE5ExBEEAIRhJ6zOIq9 oIBTgsI5Q3fYs8GvugzxbiiUXwhJQS2t8kjLIig9SdIB5rwwnpZBB2bUz2w7XAg+ zg+duUnRUzISHPJqslcob1Va62XzGIAVG1enGpJCRlsROIxwtoihq+31y2kFA7xt IKsl0f/60vebHVNTWqyhd6d07saxExH+gDZ34fhU7Z8kfAFZf49/ZrCiuR5Z78Ak Jugllj86buGjCMfVO4Z5xdkJ27zoNunFdZ6dk3rKFgtM/MrDhP+MK4j2YPUL5u8+ p8SMB1cTX6lT8rlD5v2MFg4RnL/td9vqsZydhrNLKrRYFThvQqW3ZRISYaPDI3yq vxVGd6apBOwkfikwlomD9meuV4pOHLoNXoK7Urz20eRZp2wzn2hrNneKeYei6WJi 7vjQIh2BUFlIB3xd5a81kKJO7Px3z9gs/2+mxMtO4KYOuhw7wCaIT5Nm7JmkQVvu mRWlYA7x3LMRt2d6RQoJianKidV1J6xzIpW6S0IhvE6jOxUoLlXzmi/0vD6EpLz8 BmfaDFRreL2Rf7RQ/Aw0h0cNuCLAB/0I67bmiGkQbxvVe3sgoLibCwoeGAi9xIpp VWtxBzqfg3wiEKuzn+lx =8jiv -----END PGP SIGNATURE----- --UnaWdueM1EBWVRzC--