Re: [PATCH v8] drm/lima: driver for ARM Mali4xx GPUs

[Heiko Stuebner <heiko@sntech.de>]

Hi,

Am Dienstag, 12. März 2019, 02:54:57 CET schrieb Qiang Yu:
> On Mon, Mar 11, 2019 at 11:37 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Sat, Mar 9, 2019 at 6:21 AM Qiang Yu <yuq825@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
> > >
> > > v8:
> > > - add comments for in_sync
> > > - fix ctx free miss mutex unlock
> > >
> > > 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@anholt.net>
> > > Cc: Rob Herring <robh@kernel.org>
> > > Cc: Christian König <ckoenig.leichtzumerken@gmail.com>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Alex Deucher <alexdeucher@gmail.com>
> > > Cc: Sam Ravnborg <sam@ravnborg.org>
> > > Cc: Rob Clark <robdclark@gmail.com>
> > > Cc: Dave Airlie <airlied@gmail.com>
> > > Signed-off-by: Andreas Baierl <ichgeh@imkreisrum.de>
> > > Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
> > > Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > > Signed-off-by: Simon Shields <simon@lineageos.org>
> > > Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> > > Signed-off-by: Qiang Yu <yuq825@gmail.com>
> > > Reviewed-by: Eric Anholt <eric@anholt.net>
> > > Reviewed-by: Rob Herring <robh@kerrnel.org>
> > > ---
> >
> > [...]
> 
> I thought get your RB last time, should I remove it?

I read Rob's comment as "if you need to resent for any other reason
then you could modify for that patch, but no need to resend everything
just for this", so a RB can probably stay as it is.


Heiko

> > Not to make you keep shooting for a moving target, Eric just posted a
> > patch[1] a few days ago that can replace these 2 functions. Would be
> > good to use if you respin, but otherwise can be a follow-on patch.
> 
> Thanks for the remind.
> 
> Regards,
> Qiang




_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel