From: Rob Herring <robh@kernel.org>
To: Qiang Yu <yuq825@gmail.com>
Cc: "Marek Vasut" <marex@denx.de>,
"Simon Shields" <simon@lineageos.org>,
lima@lists.freedesktop.org,
"Maxime Ripard" <maxime.ripard@bootlin.com>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>,
"Neil Armstrong" <narmstrong@baylibre.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
"Sam Ravnborg" <sam@ravnborg.org>,
"David Airlie" <airlied@linux.ie>,
"Vasily Khoruzhick" <anarsoul@gmail.com>,
"Sean Paul" <sean@poorly.run>,
"Andreas Baierl" <ichgeh@imkreisrum.de>,
"Erico Nunes" <nunes.erico@gmail.com>
Subject: Re: [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs
Date: Wed, 6 Mar 2019 17:45:55 -0600 [thread overview]
Message-ID: <CAL_Jsq+TzeMfi29HM1MF+MKtSDJ1VWF=+DyGUemdTZr4877cOA@mail.gmail.com> (raw)
In-Reply-To: <20190306152339.5340-1-yuq825@gmail.com>
On Wed, Mar 6, 2019 at 9:24 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
>
> 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>
> 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>
> ---
> 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@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.
Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-03-06 23:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 15:23 [PATCH v7 2/2] drm/lima: driver for ARM Mali4xx GPUs Qiang Yu
2019-03-06 17:37 ` Eric Anholt
2019-03-06 23:45 ` Rob Herring [this message]
2019-03-07 0:08 ` Dave Airlie
2019-03-07 1:43 ` Qiang Yu
2019-03-07 1:11 ` Eric Anholt
2019-03-07 2:20 ` Qiang Yu
2019-03-07 0:15 ` Dave Airlie
2019-03-07 1:52 ` Qiang Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL_Jsq+TzeMfi29HM1MF+MKtSDJ1VWF=+DyGUemdTZr4877cOA@mail.gmail.com' \
--to=robh@kernel.org \
--cc=airlied@linux.ie \
--cc=anarsoul@gmail.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ichgeh@imkreisrum.de \
--cc=lima@lists.freedesktop.org \
--cc=marex@denx.de \
--cc=maxime.ripard@bootlin.com \
--cc=narmstrong@baylibre.com \
--cc=nunes.erico@gmail.com \
--cc=sam@ravnborg.org \
--cc=sean@poorly.run \
--cc=simon@lineageos.org \
--cc=yuq825@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).