From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH v5 4/5] drm: Add library for shmem backed GEM objects Date: Mon, 28 Jan 2019 16:19:24 -0800 Message-ID: <87lg34s4c3.fsf@anholt.net> References: <20181017130454.44292-1-noralf@tronnes.org> <20181017130454.44292-5-noralf@tronnes.org> <87k1kzgxve.fsf@anholt.net> <20181127085850.GX4266@phenom.ffwll.local> <87lg5es1bf.fsf@anholt.net> <20181128082251.GI4266@phenom.ffwll.local> <87mupseuo7.fsf@anholt.net> <20181129091707.GD21184@phenom.ffwll.local> <87h8fzjv1y.fsf@anholt.net> <41f032f1-e023-a693-024a-3433e8055ea0@tronnes.org> <5471e418-a942-87f0-a24e-5b0f06df95f8@tronnes.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1527118678==" Return-path: In-Reply-To: <5471e418-a942-87f0-a24e-5b0f06df95f8@tronnes.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Noralf =?utf-8?Q?Tr=C3=B8nnes?= , Rob Herring Cc: David Lechner , Tomeu Vizoso , intel-gfx@lists.freedesktop.org, dri-devel , Sam Ravnborg List-Id: dri-devel@lists.freedesktop.org --===============1527118678== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Noralf Tr=C3=B8nnes writes: > Den 28.01.2019 21.57, skrev Rob Herring: >> On Sun, Dec 2, 2018 at 9:59 AM Noralf Tr=C3=B8nnes = wrote: >>> >>> >>> Den 30.11.2018 00.58, skrev Eric Anholt: >>>> Daniel Vetter writes: >>>> >>>>> On Wed, Nov 28, 2018 at 01:52:56PM -0800, Eric Anholt wrote: >>>>>> Daniel Vetter writes: >>>>>> >>>>>>> On Tue, Nov 27, 2018 at 12:38:44PM -0800, Eric Anholt wrote: >>>>>>>> Daniel Vetter writes: >>>>>>>> >>>>>>>>> On Mon, Nov 26, 2018 at 04:36:21PM -0800, Eric Anholt wrote: >>>>>>>>>> Noralf Tr=C3=B8nnes writes: >>>>>>>>>>> +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma) >>>>>>>>>>> +{ >>>>>>>>>>> + struct drm_gem_object *obj =3D vma->vm_private_data; >>>>>>>>>>> + struct drm_gem_shmem_object *shmem =3D to_drm_gem_shmem_= obj(obj); >>>>>>>>>>> + >>>>>>>>>>> + drm_gem_shmem_put_pages(shmem); >>>>>>>>>>> + drm_gem_vm_close(vma); >>>>>>>>>>> +} >>>>>>>>>>> + >>>>>>>>>>> +const struct vm_operations_struct drm_gem_shmem_vm_ops =3D { >>>>>>>>>>> + .fault =3D drm_gem_shmem_fault, >>>>>>>>>>> + .open =3D drm_gem_vm_open, >>>>>>>>>>> + .close =3D drm_gem_shmem_vm_close, >>>>>>>>>>> +}; >>>>>>>>>>> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_ops); >>>>>>>>>> I just saw a warning from drm_gem_shmem_put_pages() for >>>>>>>>>> !shmem->pages_use_count -- I think drm_gem_vm_open() needs to >>>>>>>>>> drm_gem_shmem_get_pages(). >>>>>>>>> Yeah we need a drm_gem_shmem_vm_open here. >>>>>>>> Adding one of those fixed my refcounting issues, so I've sent out = a v6 >>>>>>>> with it. >>>>>>> Just realized that I've reviewed this patch already, spotted that v= ma >>>>>>> management issue there too. Plus a pile of other things. From readi= ng that >>>>>>> other thread discussion with Noralf concluded with "not yet ready f= or >>>>>>> prime time" unfortunately :-/ >>>>>> I saw stuff about how it wasn't usable for SPI because SPI does weird >>>>>> things with DMA mapping. Was there something else? >>>>> Looking through that mail it was a bunch of comments to improve the >>>>> kerneldoc. Plus a note that buffer sharing/mmap is going to be all >>>>> incoherent and horrible (but I guess for vkms we don't care that much= ). >>>>> I'm just kinda vary of generic buffer handling that turns out to not = be >>>>> actually all that useful. We have lots of deadends and kinda-midlayer= s in >>>>> this area already (but this one here definitely smells plenty better = than >>>>> lots of older ones). >>>> FWIW, I really want shmem helpers for v3d. The fault handling in >>>> particular has magic I don't understand, and this is not my first fault >>>> handler. :/ >>> >>> >>> If you can use it for a "real" hw driver like v3d, I think it makes a l= ot >>> sense to have it as a helper. I believe udl and a future simpledrm can >>> also make use of it. >>=20 >> FWIW, I think etnaviv at least could use this too. >>=20 >> I'm starting to look at panfrost and lima drivers and was trying to >> figure out where to start with the GEM code. So I've been comparing >> etnaviv, freedreno, and vgem implementations. They are all pretty >> similar from what I see. The per driver GEM obj structs certainly are. >> I can't bring myself to just copy etnaviv code over and do a >> s/etnaviv/panfrost/. So searching around a bit, I ended up on this >> thread. This seems to be what I need for panfrost (based on my brief >> study). >>=20 > > I gave up on this due to problems with SPI DMA. > Eric tried to use it with vkms, but it failed. On his blog he speculates > that it might be due to cached CPU mappings: > https://anholt.github.io/twivc4/2018/12/03/twiv/ > > For tinydrm I wanted cached mappings, but it might not work that well > with shmem. Maybe that's why I had problems with SPI DMA. Actually, for tinydrm buffers that are dma-buf exported through prime, I really want tinydrm using WC mappings so that vc4 or v3d rendering (now supported on Mesa master with kmsro) works. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlxPnAwACgkQtdYpNtH8 nuihDg//Rd3tyWqeoj7bF01pK3EimVOsBGuTEVOgDDZvI+MPoUhPjPbsk480ChHZ ROFEHBDVoV9FjMmDr9YP8OOjSNmNBBXe7JH4yvKhiKiYlEXymNzKd+vD5MZ4W1Oz BtjNsuwmlceLjKFgXTD6kwUkbeNYA6gfPwCEBgWGSEfpTsIIDqtfttM12Kmgzdny IS9c8BktgdRYTbGj0hgqfL22N+pCeNOGAYcscmk8wHX7N0a0nhrgutYCv1AqJSQ8 fVIL3CSLppnaYSs4NsMcZMhO9Xr7ghwT7pJEkAnshcjzPrlU4Mq476SeT5F+KMl2 xOGggCwYAUfRCT3VC1FkEIALlWg8+oFm2XLmfdPxn8ZsYz0uSsPBL0P22/KPTYbQ 6XnYv6s9BZLmmEh2ajYkG7y4sYZNUg6ftqC/9uKKKnLQwYuTELkxo24lNVMHT8y4 ixgBWtMXaRVvsEXVXWHJ8wfV3J8apEAc0XmiSX0V1W6DUvOgBeH3YZCsz8khMHyi 6GzP6sHQnu43uHcGLehrmopRWTcMnKX0qoTocM1naFH4FrwvDq7eQf7a8dzSNo+1 XwhyAgcEmY+XzPwPp2AgZlJUZyW1KK5qL34Zfia5g6g8sdTRBpH8S8rTomBt0Fij QsAsqr+hFVs2B0ka1OPUQfS40QDIlaD+6Urp+wfpnuo69Mzny60= =Vk1z -----END PGP SIGNATURE----- --=-=-=-- --===============1527118678== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1527118678==--