[PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
Qiang Yu
yuq825 at gmail.com
Thu Mar 7 02:20:59 UTC 2019
On Thu, Mar 7, 2019 at 9:11 AM Eric Anholt <eric at anholt.net> wrote:
>
> Rob Herring <robh at kernel.org> writes:
>
> > On Wed, Mar 6, 2019 at 9:24 AM Qiang Yu <yuq825 at gmail.com> 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 <eric at anholt.net>
> >> Cc: Rob Herring <robh at kernel.org>
> >> Cc: Christian König <ckoenig.leichtzumerken at gmail.com>
> >> Cc: Daniel Vetter <daniel at ffwll.ch>
> >> Cc: Alex Deucher <alexdeucher at gmail.com>
> >> Cc: Sam Ravnborg <sam at ravnborg.org>
> >> Cc: Rob Clark <robdclark at gmail.com>
> >> Signed-off-by: Andreas Baierl <ichgeh at imkreisrum.de>
> >> Signed-off-by: Erico Nunes <nunes.erico at gmail.com>
> >> Signed-off-by: Heiko Stuebner <heiko at sntech.de>
> >> Signed-off-by: Marek Vasut <marex at denx.de>
> >> Signed-off-by: Neil Armstrong <narmstrong at baylibre.com>
> >> Signed-off-by: Simon Shields <simon at lineageos.org>
> >> Signed-off-by: Vasily Khoruzhick <anarsoul at gmail.com>
> >> Signed-off-by: Qiang Yu <yuq825 at gmail.com>
> >> ---
> >> 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 <robh at kerrnel.org>
> >
> > 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.
I'd like to get this merged first if accepted instead of maintain a
separate branch when mesa upstream process. mesa part could
have a kernel driver when the upstream gets reviewed too.
Regards,
Qiang
More information about the dri-devel
mailing list