[PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs

Thu Mar 7 00:08:40 UTC 2019

On Thu, 7 Mar 2019 at 09:46, Rob Herring <robh at kernel.org> wrote:
>
> 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.
>

We generally want the kernel bits upstream first.

We'd want the upstream mesa bits reviewed though and having a mesa MR
with those bits reviewed should be a prereq of this landing.

Then we land this, and then land that.

Dave.