From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs Date: Wed, 06 Mar 2019 17:11:49 -0800 Message-ID: <87ef7jqyi2.fsf@anholt.net> References: <20190306152339.5340-1-yuq825@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0376511935==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Rob Herring , Qiang Yu Cc: Marek Vasut , Simon Shields , lima@lists.freedesktop.org, Andreas Baierl , Maxime Ripard , Christian =?utf-8?Q?K=C3=B6nig?= , Neil Armstrong , dri-devel , Sam Ravnborg , David Airlie , Vasily Khoruzhick , Sean Paul , Erico Nunes List-Id: dri-devel@lists.freedesktop.org --===============0376511935== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rob Herring writes: > On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu wrote: >> >> - Mali 4xx GPUs have two kinds of processors GP and PP. GP is for >> OpenGL vertex shader processing and PP is for fragment shader >> processing. Each processor has its own MMU so prcessors work in >> virtual address space. >> - There's only one GP but multiple PP (max 4 for mali 400 and 8 >> for mali 450) in the same mali 4xx GPU. All PPs are grouped >> togather to handle a single fragment shader task divided by >> FB output tiled pixels. Mali 400 user space driver is >> responsible for assign target tiled pixels to each PP, but mali >> 450 has a HW module called DLBU to dynamically balance each >> PP's load. >> - User space driver allocate buffer object and map into GPU >> virtual address space, upload command stream and draw data with >> CPU mmap of the buffer object, then submit task to GP/PP with >> a register frame indicating where is the command stream and misc >> settings. >> - There's no command stream validation/relocation due to each user >> process has its own GPU virtual address space. GP/PP's MMU switch >> virtual address space before running two tasks from different >> user process. Error or evil user space code just get MMU fault >> or GP/PP error IRQ, then the HW/SW will be recovered. >> - Use GEM+shmem for MM. Currently just alloc and pin memory when >> gem object creation. GPU vm map of the buffer is also done in >> the alloc stage in kernel space. We may delay the memory >> allocation and real GPU vm map to command submission stage in the >> furture as improvement. >> - Use drm_sched for GPU task schedule. Each OpenGL context should >> have a lima context object in the kernel to distinguish tasks >> from different user. drm_sched gets task from each lima context >> in a fair way. >> >> mesa driver can be found here before upstreamed: >> https://gitlab.freedesktop.org/lima/mesa >> >> v7: >> - remove lima_fence_ops with default value >> - move fence slab create to device probe >> - check pad ioctl args to be zero >> - add comments for user/kernel interface >> >> v6: >> - fix comments by checkpatch.pl >> >> v5: >> - export gp/pp version to userspace >> - rebase on drm-misc-next >> >> v4: >> - use get param interface to get info >> - separate context create/free ioctl >> - remove unused max sched task param >> - update copyright time >> - use xarray instead of idr >> - stop using drmP.h >> >> v3: >> - fix comments from kbuild robot >> - restrict supported arch to tested ones >> >> v2: >> - fix syscall argument check >> - fix job finish fence leak since kernel 5.0 >> - use drm syncobj to replace native fence >> - move buffer object GPU va map into kernel >> - reserve syscall argument space for future info >> - remove kernel gem modifier >> - switch TTM back to GEM+shmem MM >> - use time based io poll >> - use whole register name >> - adopt gem reservation obj integration >> - use drm_timeout_abs_to_jiffies >> >> Cc: Eric Anholt >> Cc: Rob Herring >> Cc: Christian K=C3=B6nig >> Cc: Daniel Vetter >> Cc: Alex Deucher >> Cc: Sam Ravnborg >> Cc: Rob Clark >> Signed-off-by: Andreas Baierl >> Signed-off-by: Erico Nunes >> Signed-off-by: Heiko Stuebner >> Signed-off-by: Marek Vasut >> Signed-off-by: Neil Armstrong >> Signed-off-by: Simon Shields >> Signed-off-by: Vasily Khoruzhick >> Signed-off-by: Qiang Yu >> --- >> drivers/gpu/drm/Kconfig | 2 + >> drivers/gpu/drm/Makefile | 1 + >> drivers/gpu/drm/lima/Kconfig | 10 + >> drivers/gpu/drm/lima/Makefile | 21 ++ >> drivers/gpu/drm/lima/lima_bcast.c | 47 +++ >> drivers/gpu/drm/lima/lima_bcast.h | 14 + >> drivers/gpu/drm/lima/lima_ctx.c | 97 ++++++ >> drivers/gpu/drm/lima/lima_ctx.h | 30 ++ >> drivers/gpu/drm/lima/lima_device.c | 385 +++++++++++++++++++++++ >> drivers/gpu/drm/lima/lima_device.h | 131 ++++++++ >> drivers/gpu/drm/lima/lima_dlbu.c | 58 ++++ >> drivers/gpu/drm/lima/lima_dlbu.h | 18 ++ >> drivers/gpu/drm/lima/lima_drv.c | 376 +++++++++++++++++++++++ >> drivers/gpu/drm/lima/lima_drv.h | 45 +++ >> drivers/gpu/drm/lima/lima_gem.c | 381 +++++++++++++++++++++++ >> drivers/gpu/drm/lima/lima_gem.h | 25 ++ >> drivers/gpu/drm/lima/lima_gem_prime.c | 47 +++ >> drivers/gpu/drm/lima/lima_gem_prime.h | 13 + >> drivers/gpu/drm/lima/lima_gp.c | 283 +++++++++++++++++ >> drivers/gpu/drm/lima/lima_gp.h | 16 + >> drivers/gpu/drm/lima/lima_l2_cache.c | 80 +++++ >> drivers/gpu/drm/lima/lima_l2_cache.h | 14 + >> drivers/gpu/drm/lima/lima_mmu.c | 142 +++++++++ >> drivers/gpu/drm/lima/lima_mmu.h | 16 + >> drivers/gpu/drm/lima/lima_object.c | 122 ++++++++ >> drivers/gpu/drm/lima/lima_object.h | 36 +++ >> drivers/gpu/drm/lima/lima_pmu.c | 60 ++++ >> drivers/gpu/drm/lima/lima_pmu.h | 12 + >> drivers/gpu/drm/lima/lima_pp.c | 427 ++++++++++++++++++++++++++ >> drivers/gpu/drm/lima/lima_pp.h | 19 ++ >> drivers/gpu/drm/lima/lima_regs.h | 298 ++++++++++++++++++ >> drivers/gpu/drm/lima/lima_sched.c | 404 ++++++++++++++++++++++++ >> drivers/gpu/drm/lima/lima_sched.h | 104 +++++++ >> drivers/gpu/drm/lima/lima_vm.c | 282 +++++++++++++++++ >> drivers/gpu/drm/lima/lima_vm.h | 62 ++++ >> include/uapi/drm/lima_drm.h | 164 ++++++++++ >> 36 files changed, 4242 insertions(+) > > Reviewed-by: Rob Herring > > I can apply this if you want, though I'm not completely sure whether > folks want the mesa bits to go upstream first. They'd need to hide the Mesa usage of the ABI until the kernel merges anyway, so it's enough that it's public in a way that targets Mesa. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE/JuuFDWp9/ZkuCBXtdYpNtH8nugFAlyAb9UACgkQtdYpNtH8 nuifwg/+PXqomWPqBEuwe6OwkZJS4PV2ag87vlYuF3+3RynBwjBa5vOrFR48PUk8 R0aDfBUuNz9D+Z8D1Q8JvWELgwhkrSddPTz7aQR9XPGFtYYdUg/A88owajGNj33o fOMf1StoDezQLEsHcB02HI5UYkuLshmXr4GGyPzRqxsK2bnO7tkDdHjQaW5jLRdv zET1UGzYxeGeRflHvLFXJwtzpTDAO6l+JU8M2qLUa/k06adBZnZlQa/hTLVXU4CR 9TTf7UI3TgWrH/Zbqj/L4HmY1NCgGkjEKgYAyNaFCWhs24s6GBFbTYh3pNEBWKdn Q4pBsFiEJFy1aB4ks4bEsX+k0kFECtpLAaZ5qrodsririxx1vUW8kX96lwWSJVd5 k09Qi0vSgzxYKosVzmpqVUq2PfTaIKZVpMtB8oybsU+lghKlOsquubw6LJVnktjU b0AuGjCUuPTmX9Y+aJJSri0/SWASWMi63pzV+SwbkHOFlEbJDLpea8kwwz2f5qXd WlCQxiADZiY+dX0ReDtSZMi0GNcOkxEYJFBTqsytoYx7rRBZGGOr4ggJZSxdrdW7 jnx4P//A6QMhPhZ2lTL0KcU25L4ObA7o4rGsSJf/kwkh6QG60szpQWbkrNNLQHPF yqMuICMwAV4nqpXtv/ROv/i6HhjQZGu7e+oQ7udqcFPkdmljve4= =79tv -----END PGP SIGNATURE----- --=-=-=-- --===============0376511935== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============0376511935==--