From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Zimmermann Subject: Re: [PATCH 40/59] drm/vram-helper: Drop drm_gem_prime_export/import Date: Thu, 27 Jun 2019 10:27:32 +0200 Message-ID: References: <20190614203615.12639-1-daniel.vetter@ffwll.ch> <20190614203615.12639-41-daniel.vetter@ffwll.ch> <20190617082438.s5eypq5lf6s33nyz@sirius.home.kraxel.org> <20190617135912.GB12905@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0487227923==" Return-path: In-Reply-To: <20190617135912.GB12905@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter , Gerd Hoffmann Cc: Maxime Ripard , Daniel Vetter , Intel Graphics Development , DRI Development , David Airlie , Daniel Vetter List-Id: intel-gfx@lists.freedesktop.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============0487227923== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wMydacYR0DTQCWxiVGYgvSXJgc07WuHFA" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wMydacYR0DTQCWxiVGYgvSXJgc07WuHFA Content-Type: multipart/mixed; boundary="Z0SImBY5s1zzeVZowdbaaQby8g0UAEa7n"; protected-headers="v1" From: Thomas Zimmermann To: Daniel Vetter , Gerd Hoffmann Cc: Maxime Ripard , Daniel Vetter , Intel Graphics Development , DRI Development , David Airlie , Daniel Vetter , Sean Paul Message-ID: Subject: Re: [PATCH 40/59] drm/vram-helper: Drop drm_gem_prime_export/import References: <20190614203615.12639-1-daniel.vetter@ffwll.ch> <20190614203615.12639-41-daniel.vetter@ffwll.ch> <20190617082438.s5eypq5lf6s33nyz@sirius.home.kraxel.org> <20190617135912.GB12905@phenom.ffwll.local> In-Reply-To: <20190617135912.GB12905@phenom.ffwll.local> --Z0SImBY5s1zzeVZowdbaaQby8g0UAEa7n Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Am 17.06.19 um 15:59 schrieb Daniel Vetter: > On Mon, Jun 17, 2019 at 10:24:38AM +0200, Gerd Hoffmann wrote: >> Hi, >> >>> Aside: Would be really nice to switch the others over to >>> drm_gem_object_funcs. >> >> While most callbacks are pretty straight forward (just hook the same >> callbacks into the drm_gem_object_funcs. struct) the mmap bits are a >> bit more obscure. >> >> First, there seem to be two ways to mmap a gem buffer: >> >> (1) drm_driver->fops->mmap, and >> (2) drm_driver->gem_prime_mmap. >> >> drm_gem_object_funcs has just a single vm_ops ... >> >> Also it is not obvious how one would convert something which basically= >> calls ttm_bo_mmap() in drm_driver->fops->mmap to the new interface. >=20 > Yeah the mmap side is still a mess, but my series here was getting a bi= t > too long already. There's a bunch of problems here: >=20 > drm_driver->gem_prime_mmap could be nuked and instead we use > drm_gem_prime_mmap everywhere. Especially the various versions in helpe= rs > really don't add much. >=20 > The trouble is that removing the hook outright isn't quite right, becau= se > it also signals "is mmap allowed on this dma-buf". I'm kinda tempted to= > just make that a hard requirement, and force people who can't support m= map > on the dma-buf (or who need begin/end_cpu_access hooks) to supply their= > own set of dma_buf_ops. >=20 > Second one is drm_driver->fops->mmap. That one we need to keep, but thi= s > isn't mmap on a buffer, but mmap on the entire drm_device. The one whic= h > should be replaced by drm_gem_object_funcs.vm_ops is > drm_driver->gem_vm_ops. =46rom what I've seen in fbdev drivers, it's an mmap of the framebuffer memory, which typically is the same as the device's memory but doesn't have to. And it's only valid for/while the current display mode (e.g., mgafb doesn't set fixes.smem_length until you configure a mode). I guess it should be legal to just mmap the shadow FB from the fbcon emulation. Best regards Thomas > Hope that explains a bit better what's going on here. Step one here for= > mmap is definitely to roll out drm_gem_prime_mmap as far as possible, s= o > it's easier to understand where the exceptions are. >=20 > Cheers, Daniel >=20 --=20 Thomas Zimmermann Graphics Driver Developer SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany GF: Felix Imend=C3=B6rffer, Mary Higgins, Sri Rasiah HRB 21284 (AG N=C3=BCrnberg) --Z0SImBY5s1zzeVZowdbaaQby8g0UAEa7n-- --wMydacYR0DTQCWxiVGYgvSXJgc07WuHFA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEchf7rIzpz2NEoWjlaA3BHVMLeiMFAl0UffQACgkQaA3BHVML eiNbewf7BwzOgKKoTeMAagNJnmeGtX1Is2UMCJZKkDH8tg2onQusCJBMiZGdskDt kK58CrnznuFthJl2amFWXvqKh5iuBJ/30AinPuAGW0MJeuUgYPenGX9kIvLIeruV kOpKYC8EiHKUtcqSWF6ay8f5ooYcEibL6ucm01MlBo4v4WiWGdkMIvqdlRig7D7I 4dNsTiMNsOdHoJHswrg/rcoN8YegcY6WqFUistZfRUrIto4XSx6iUwBbI493StuB G9+oskgAzIDP1N7Yvi59///RLUWt16uyecRV56bkzgOWqqH5uBQ0EFjZ6VqIR+Bm +7rqLZr7ftCCEAXR5z+AeoioAI4QgQ== =izsP -----END PGP SIGNATURE----- --wMydacYR0DTQCWxiVGYgvSXJgc07WuHFA-- --===============0487227923== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4 --===============0487227923==--