Hi,
This serie aims at adding the support for pixel blend modes represent the
alpha blending equation selection in the driver. It also introduces to use
it in the malidp driver.
Let me know what you think,
Lowry
Changes for v2:
- Moves the blending equation into the DOC comment
- Refines the comments of drm_plane_create_blend_mode_property to not
enumerate the #defines, but instead the string values
- Uses fg.* instead of pixel.* and plane_alpha instead of plane.alpha
- Introduces to …
[View More]use it in the malidp driver, which depends on the plane
alpha patch
Changes from v1:
- v1 is just the core changes to request for commments
- Adds a pixel_blend_mode to drm_plane_state and a blend_mode_property to
drm_plane, and related support functions
- Defines three blend modes in drm_blend.h
- Rebased on current drm-next
Lowry Li (2):
drm/blend: Add per-plane pixel blend mode property
drm/mali-dp: Implement plane alpha and pixel blend on malidp
drivers/gpu/drm/arm/malidp_planes.c | 76 ++++++++++++++-----------
drivers/gpu/drm/drm_atomic.c | 4 ++
drivers/gpu/drm/drm_atomic_helper.c | 1 +
drivers/gpu/drm/drm_blend.c | 110 ++++++++++++++++++++++++++++++++++++
include/drm/drm_blend.h | 6 ++
include/drm/drm_plane.h | 6 ++
6 files changed, 171 insertions(+), 32 deletions(-)
--
1.9.1
[View Less]
So drivers don't need dummy functions just returning NULL.
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
---
include/linux/dma-buf.h | 4 ++--
drivers/dma-buf/dma-buf.c | 4 ++++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 085db2fee2..88917fa796 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -39,12 +39,12 @@ struct dma_buf_attachment;
/**…
[View More]
* struct dma_buf_ops - operations possible on struct dma_buf
- * @map_atomic: maps a page from the buffer into kernel address
+ * @map_atomic: [optional] maps a page from the buffer into kernel address
* space, users may not block until the subsequent unmap call.
* This callback must not sleep.
* @unmap_atomic: [optional] unmaps a atomically mapped page from the buffer.
* This Callback must not sleep.
- * @map: maps a page from the buffer into kernel address space.
+ * @map: [optional] maps a page from the buffer into kernel address space.
* @unmap: [optional] unmaps a page from the buffer.
* @vmap: [optional] creates a virtual mapping for the buffer into kernel
* address space. Same restrictions as for vmap and friends apply.
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d78d5fc173..4c45e31258 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -872,6 +872,8 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long page_num)
{
WARN_ON(!dmabuf);
+ if (!dmabuf->ops->map_atomic)
+ return NULL;
return dmabuf->ops->map_atomic(dmabuf, page_num);
}
EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
@@ -907,6 +909,8 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num)
{
WARN_ON(!dmabuf);
+ if (!dmabuf->ops->map)
+ return NULL;
return dmabuf->ops->map(dmabuf, page_num);
}
EXPORT_SYMBOL_GPL(dma_buf_kmap);
--
2.9.3
[View Less]
From: Ong, Hean Loong <hean.loong.ong(a)intel.com>
The FPGA FrameBuffer Soft IP could be seen as the GPU and the DRM driver patch here is allocating memory for information to be streamed from the ARM/Linux to the display port.
Basically the driver just wraps the information such as the pixels to be drawn by the FPGA FrameBuffer 2.
The piece of hardware in discussion is the SoC FPGA where Linux runs on the ARM chip and the FGPA is driven by its NIOS soft core with its own proprietary …
[View More]firmware.
For example the application from the ARM Linux would have to write information on the /dev/fb0 with the information stored in the SDRAM to be fetched by the FPGA framebuffer IP and displayed on the Display Port Monitor.
Ong Hean Loong (3):
ARM:dt-bindings:display Intel FPGA Video and Image Processing Suite
ARM:socfpga-defconfig Intel FPGA Video and Image Processing Suite
ARM:drm ivip Intel FPGA Video and Image Processing Suite
.../devicetree/bindings/display/altr,vip-fb2.txt | 112 +++++++++++
arch/arm/configs/socfpga_defconfig | 5 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/ivip/Kconfig | 14 ++
drivers/gpu/drm/ivip/Makefile | 9 +
drivers/gpu/drm/ivip/intel_vip_conn.c | 96 ++++++++++
drivers/gpu/drm/ivip/intel_vip_core.c | 162 ++++++++++++++++
drivers/gpu/drm/ivip/intel_vip_drv.h | 52 ++++++
drivers/gpu/drm/ivip/intel_vip_of.c | 193 ++++++++++++++++++++
10 files changed, 646 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
create mode 100644 drivers/gpu/drm/ivip/Kconfig
create mode 100644 drivers/gpu/drm/ivip/Makefile
create mode 100644 drivers/gpu/drm/ivip/intel_vip_conn.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_core.c
create mode 100644 drivers/gpu/drm/ivip/intel_vip_drv.h
create mode 100644 drivers/gpu/drm/ivip/intel_vip_of.c
[View Less]
From: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com>
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed solution,
can greatly benefit as well.
RFC for this series was published and discussed [9], comments addressed.
The original rationale behind this work was to …
[View More]enable zero-copying
use-cases while working with Xen para-virtual display driver [4]:
when using Xen PV DRM frontend driver then on backend side one will
need to do copying of display buffers' contents (filled by the
frontend's user-space) into buffers allocated at the backend side.
Taking into account the size of display buffers and frames per
second it may result in unneeded huge data bus occupation and
performance loss.
The helper driver [4] allows implementing zero-copying use-cases
when using Xen para-virtualized frontend display driver by implementing
a DRM/KMS helper driver running on backend's side.
It utilizes PRIME buffers API (implemented on top of Linux dma-buf)
to share frontend's buffers with physical device drivers on
backend's side:
- a dumb buffer created on backend's side can be shared
with the Xen PV frontend driver, so it directly writes
into backend's domain memory (into the buffer exported from
DRM/KMS driver of a physical display device)
- a dumb buffer allocated by the frontend can be imported
into physical device DRM/KMS driver, thus allowing to
achieve no copying as well
Finally, it was discussed and decided ([1], [5]) that it is worth
implementing such use-cases via extension of the existing Xen gntdev
driver instead of introducing new DRM specific driver.
Please note, that the support of dma-buf is Linux only,
as dma-buf is a Linux only thing.
Now to the proposed solution. The changes to the existing Xen drivers
in the Linux kernel fall into 2 categories:
1. DMA-able memory buffer allocation and increasing/decreasing memory
reservation of the pages of such a buffer.
This is required if we are about to share dma-buf with the hardware
that does require those to be allocated with dma_alloc_xxx API.
(It is still possible to allocate a dma-buf from any system memory,
e.g. system pages).
2. Extension of the gntdev driver to enable it to import/export dma-buf’s.
The first four patches are in preparation for Xen dma-buf support,
but I consider those usable regardless of the dma-buf use-case,
e.g. other frontend/backend kernel modules may also benefit from these
for better code reuse:
0001-xen-grant-table-Make-set-clear-page-private-code-sha.patch
0002-xen-balloon-Move-common-memory-reservation-routines-.patch
0003-xen-grant-table-Allow-allocating-buffers-suitable-fo.patch
0004-xen-gntdev-Allow-mappings-for-DMA-buffers.patch
The next three patches are Xen implementation of dma-buf as part of
the grant device:
0005-xen-gntdev-Add-initial-support-for-dma-buf-UAPI.patch
0006-xen-gntdev-Implement-dma-buf-export-functionality.patch
0007-xen-gntdev-Implement-dma-buf-import-functionality.patch
The last patch makes it possible for in-kernel use of Xen dma-buf API:
0008-xen-gntdev-Expose-gntdev-s-dma-buf-API-for-in-kernel.patch
The corresponding libxengnttab changes are available at [6].
All the above was tested with display backend [7] and its accompanying
helper library [8] on Renesas ARM64 based board.
*To all the communities*: I would like to ask you to review the proposed
solution and give feedback on it, so I can improve and send final
patches for review (this is still work in progress, but enough to start
discussing the implementation).
Thank you in advance,
Oleksandr Andrushchenko
[1] https://lists.freedesktop.org/archives/dri-devel/2018-April/173163.html
[2] https://elixir.bootlin.com/linux/v4.17-rc5/source/Documentation/driver-api/…
[3] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg01202.html
[4] https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/xen
[5] https://patchwork.kernel.org/patch/10279681/
[6] https://github.com/andr2000/xen/tree/xen_dma_buf_v1
[7] https://github.com/andr2000/displ_be/tree/xen_dma_buf_v1
[8] https://github.com/andr2000/libxenbe/tree/xen_dma_buf_v1
[9] https://lkml.org/lkml/2018/5/17/215
Oleksandr Andrushchenko (8):
xen/grant-table: Make set/clear page private code shared
xen/balloon: Move common memory reservation routines to a module
xen/grant-table: Allow allocating buffers suitable for DMA
xen/gntdev: Allow mappings for DMA buffers
xen/gntdev: Add initial support for dma-buf UAPI
xen/gntdev: Implement dma-buf export functionality
xen/gntdev: Implement dma-buf import functionality
xen/gntdev: Expose gntdev's dma-buf API for in-kernel use
drivers/xen/Kconfig | 23 +
drivers/xen/Makefile | 1 +
drivers/xen/balloon.c | 71 +--
drivers/xen/gntdev.c | 1025 ++++++++++++++++++++++++++++++++-
drivers/xen/grant-table.c | 176 +++++-
drivers/xen/mem-reservation.c | 134 +++++
include/uapi/xen/gntdev.h | 106 ++++
include/xen/grant_dev.h | 37 ++
include/xen/grant_table.h | 28 +
include/xen/mem_reservation.h | 29 +
10 files changed, 1527 insertions(+), 103 deletions(-)
create mode 100644 drivers/xen/mem-reservation.c
create mode 100644 include/xen/grant_dev.h
create mode 100644 include/xen/mem_reservation.h
--
2.17.0
[View Less]
Kernel DRM driver for ARM Mali 400/450 GPUs.
This implementation mainly take amdgpu DRM driver as reference.
- 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 …
[View More]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 TTM as MM. TTM_PL_TT type memory is used as the content of
lima buffer object which is allocated from TTM page pool. all
lima buffer object gets pinned with TTM_PL_FLAG_NO_EVICT when
allocation, so there's no buffer eviction and swap for now. We
need reverse engineering to see if and how GP/PP support MMU
fault recovery (continue execution). Otherwise we have to
pin/unpin each envolved buffer when task creation/deletion.
- 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.
Not implemented:
- Dump buffer support
- Power management
- Performance counter
This patch serial just pack a pair of .c/.h files in each patch.
For whole history of this driver's development, see:
https://github.com/yuq/linux-lima/commits/lima-4.17-rc4
Mesa driver is still in development and not ready for daily usage,
but can run some simple tests like kmscube and glamrk2, see:
https://github.com/yuq/mesa-lima
Andrei Paulau (1):
arm64/dts: add switch-delay for meson mali
Lima Project Developers (10):
drm/lima: add mali 4xx GPU hardware regs
drm/lima: add lima core driver
drm/lima: add GPU device functions
drm/lima: add PMU related functions
drm/lima: add PP related functions
drm/lima: add MMU related functions
drm/lima: add GPU virtual memory space handing
drm/lima: add GEM related functions
drm/lima: add GEM Prime related functions
drm/lima: add makefile and kconfig
Qiang Yu (12):
dt-bindings: add switch-delay property for mali-utgard
arm64/dts: add switch-delay for meson mali
Revert "drm: Nerf the preclose callback for modern drivers"
drm/lima: add lima uapi header
drm/lima: add L2 cache functions
drm/lima: add GP related functions
drm/lima: add BCAST related function
drm/lima: add DLBU related functions
drm/lima: add TTM subsystem functions
drm/lima: add buffer object functions
drm/lima: add GPU schedule using DRM_SCHED
drm/lima: add context related functions
Simon Shields (1):
ARM: dts: add gpu node to exynos4
.../bindings/gpu/arm,mali-utgard.txt | 4 +
arch/arm/boot/dts/exynos4.dtsi | 33 ++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 1 +
.../boot/dts/amlogic/meson-gxl-mali.dtsi | 1 +
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_file.c | 8 +-
drivers/gpu/drm/lima/Kconfig | 9 +
drivers/gpu/drm/lima/Makefile | 19 +
drivers/gpu/drm/lima/lima_bcast.c | 65 +++
drivers/gpu/drm/lima/lima_bcast.h | 34 ++
drivers/gpu/drm/lima/lima_ctx.c | 143 +++++
drivers/gpu/drm/lima/lima_ctx.h | 51 ++
drivers/gpu/drm/lima/lima_device.c | 407 ++++++++++++++
drivers/gpu/drm/lima/lima_device.h | 136 +++++
drivers/gpu/drm/lima/lima_dlbu.c | 75 +++
drivers/gpu/drm/lima/lima_dlbu.h | 37 ++
drivers/gpu/drm/lima/lima_drv.c | 466 ++++++++++++++++
drivers/gpu/drm/lima/lima_drv.h | 77 +++
drivers/gpu/drm/lima/lima_gem.c | 459 ++++++++++++++++
drivers/gpu/drm/lima/lima_gem.h | 41 ++
drivers/gpu/drm/lima/lima_gem_prime.c | 66 +++
drivers/gpu/drm/lima/lima_gem_prime.h | 31 ++
drivers/gpu/drm/lima/lima_gp.c | 293 +++++++++++
drivers/gpu/drm/lima/lima_gp.h | 34 ++
drivers/gpu/drm/lima/lima_l2_cache.c | 98 ++++
drivers/gpu/drm/lima/lima_l2_cache.h | 32 ++
drivers/gpu/drm/lima/lima_mmu.c | 154 ++++++
drivers/gpu/drm/lima/lima_mmu.h | 34 ++
drivers/gpu/drm/lima/lima_object.c | 120 +++++
drivers/gpu/drm/lima/lima_object.h | 87 +++
drivers/gpu/drm/lima/lima_pmu.c | 85 +++
drivers/gpu/drm/lima/lima_pmu.h | 30 ++
drivers/gpu/drm/lima/lima_pp.c | 418 +++++++++++++++
drivers/gpu/drm/lima/lima_pp.h | 37 ++
drivers/gpu/drm/lima/lima_regs.h | 304 +++++++++++
drivers/gpu/drm/lima/lima_sched.c | 497 ++++++++++++++++++
drivers/gpu/drm/lima/lima_sched.h | 126 +++++
drivers/gpu/drm/lima/lima_ttm.c | 409 ++++++++++++++
drivers/gpu/drm/lima/lima_ttm.h | 44 ++
drivers/gpu/drm/lima/lima_vm.c | 312 +++++++++++
drivers/gpu/drm/lima/lima_vm.h | 73 +++
include/drm/drm_drv.h | 23 +-
include/uapi/drm/lima_drm.h | 195 +++++++
44 files changed, 5565 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/lima/Kconfig
create mode 100644 drivers/gpu/drm/lima/Makefile
create mode 100644 drivers/gpu/drm/lima/lima_bcast.c
create mode 100644 drivers/gpu/drm/lima/lima_bcast.h
create mode 100644 drivers/gpu/drm/lima/lima_ctx.c
create mode 100644 drivers/gpu/drm/lima/lima_ctx.h
create mode 100644 drivers/gpu/drm/lima/lima_device.c
create mode 100644 drivers/gpu/drm/lima/lima_device.h
create mode 100644 drivers/gpu/drm/lima/lima_dlbu.c
create mode 100644 drivers/gpu/drm/lima/lima_dlbu.h
create mode 100644 drivers/gpu/drm/lima/lima_drv.c
create mode 100644 drivers/gpu/drm/lima/lima_drv.h
create mode 100644 drivers/gpu/drm/lima/lima_gem.c
create mode 100644 drivers/gpu/drm/lima/lima_gem.h
create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
create mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
create mode 100644 drivers/gpu/drm/lima/lima_gp.c
create mode 100644 drivers/gpu/drm/lima/lima_gp.h
create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.c
create mode 100644 drivers/gpu/drm/lima/lima_l2_cache.h
create mode 100644 drivers/gpu/drm/lima/lima_mmu.c
create mode 100644 drivers/gpu/drm/lima/lima_mmu.h
create mode 100644 drivers/gpu/drm/lima/lima_object.c
create mode 100644 drivers/gpu/drm/lima/lima_object.h
create mode 100644 drivers/gpu/drm/lima/lima_pmu.c
create mode 100644 drivers/gpu/drm/lima/lima_pmu.h
create mode 100644 drivers/gpu/drm/lima/lima_pp.c
create mode 100644 drivers/gpu/drm/lima/lima_pp.h
create mode 100644 drivers/gpu/drm/lima/lima_regs.h
create mode 100644 drivers/gpu/drm/lima/lima_sched.c
create mode 100644 drivers/gpu/drm/lima/lima_sched.h
create mode 100644 drivers/gpu/drm/lima/lima_ttm.c
create mode 100644 drivers/gpu/drm/lima/lima_ttm.h
create mode 100644 drivers/gpu/drm/lima/lima_vm.c
create mode 100644 drivers/gpu/drm/lima/lima_vm.h
create mode 100644 include/uapi/drm/lima_drm.h
--
2.17.0
[View Less]