kernel/linux.git/drivers/gpu/drm/Kconfig, branch v4.10.9

Merge tag 'meson-drm-for-4.10' of github.com:superna9999/linux into drm-next

2016-12-08T00:35:52+00:00

Add support for the Amlogic Meson Video Processing Unit - Only CVBS/Composite output for Amlogic Meson GXBB/GXL/GXM SoCs - Add MAINTAINERS entry - Add DT bindings documentation * tag 'meson-drm-for-4.10' of github.com:superna9999/linux: MAINTAINERS: add entry for Amlogic DRM drivers dt-bindings: display: add Amlogic Meson DRM Bindings drm: Add support for Amlogic Meson Graphic Controller

drm: Add new driver for MXSFB controller

2016-12-06T02:02:26+00:00

Add new driver for the MXSFB controller found in i.MX23/28/6SX . The MXSFB controller is a simple framebuffer controller with one parallel LCD output. Unlike the MXSFB fbdev driver that is used on these systems now, this driver uses the DRM/KMS framework. Signed-off-by: Marek Vasut Cc: Lucas Stach Cc: Fabio Estevam Cc: Shawn Guo

drm: Add support for Amlogic Meson Graphic Controller

2016-12-01T09:07:20+00:00

The Amlogic Meson Display controller is composed of several components : DMC|---------------VPU (Video Processing Unit)----------------|------HHI------| | vd1 _______ _____________ _________________ | | D |-------| |----| | | | | HDMI PLL | D | vd2 | VIU | | Video Post | | Video Encoders |<---|-----VCLK | R |-------| |----| Processing | | | | | | osd2 | | | |---| Enci ----------|----|-----VDAC------| R |-------| CSC |----| Scalers | | Encp ----------|----|----HDMI-TX----| A | osd1 | | | Blenders | | Encl ----------|----|---------------| M |-------|______|----|____________| |________________| | | ___|__________________________________________________________|_______________| VIU: Video Input Unit --------------------- The Video Input Unit is in charge of the pixel scanout from the DDR memory. It fetches the frames addresses, stride and parameters from the "Canvas" memory. This part is also in charge of the CSC (Colorspace Conversion). It can handle 2 OSD Planes and 2 Video Planes. VPP: Video Post Processing -------------------------- The Video Post Processing is in charge of the scaling and blending of the various planes into a single pixel stream. There is a special "pre-blending" used by the video planes with a dedicated scaler and a "post-blending" to merge with the OSD Planes. The OSD planes also have a dedicated scaler for one of the OSD. VENC: Video Encoders -------------------- The VENC is composed of the multiple pixel encoders : - ENCI : Interlace Video encoder for CVBS and Interlace HDMI - ENCP : Progressive Video Encoder for HDMI - ENCL : LCD LVDS Encoder The VENC Unit gets a Pixel Clocks (VCLK) from a dedicated HDMI PLL and clock tree and provides the scanout clock to the VPP and VIU. The ENCI is connected to a single VDAC for Composite Output. The ENCI and ENCP are connected to an on-chip HDMI Transceiver. This driver is a DRM/KMS driver using the following DRM components : - GEM-CMA - PRIME-CMA - Atomic Modesetting - FBDev-CMA For the following SoCs : - GXBB Family (S905) - GXL Family (S905X, S905D) - GXM Family (S912) The current driver only supports the CVBS PAL/NTSC output modes, but the CRTC/Planes management should support bigger modes. But Advanced Colorspace Conversion, Scaling and HDMI Modes will be added in a second time. The Device Tree bindings makes use of the endpoints video interface definitions to connect to the optional CVBS and in the future the HDMI Connector nodes. HDMI Support is planned for a next release. Acked-by: Daniel Vetter Signed-off-by: Neil Armstrong

drm/fence: add in-fences support

2016-11-16T08:55:27+00:00

There is now a new property called IN_FENCE_FD attached to every plane state that receives sync_file fds from userspace via the atomic commit IOCTL. The fd is then translated to a fence (that may be a fence_array subclass or just a normal fence) and then used by DRM to fence_wait() for all fences in the sync_file to signal. So it only commits when all framebuffers are ready to scanout. v2: Comments by Daniel Vetter: - remove set state->fence = NULL in destroy phase - accept fence -1 as valid and just return 0 - do not call fence_get() - sync_file_fences_get() already calls it - fence_put() if state->fence is already set, in case userspace set the property more than once. v3: WARN_ON if fence is set but state has no FB v4: Comment from Maarten Lankhorst - allow set fence with no related fb v5: rename FENCE_FD to IN_FENCE_FD v6: Comments by Daniel Vetter: - rename plane_state->in_fence back to "fence" - re-introduce WARN_ON if fence set but no fb - rebase after fence -> dma_fence rename v7: Comments by Brian Starkey - set state->fence to NULL when duplicating the state - fail if IN_FENCE_FD was already set v8: rebase against latest drm-misc Signed-off-by: Gustavo Padovan Reviewed-by: Brian Starkey Reviewed-by: Sean Paul Tested-by: Robert Foss [danvet: Rebase onto extracted drm_mode_config.[hc].] Signed-off-by: Daniel Vetter

Merge tag 'zxdrm-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into drm-next

2016-11-11T00:09:13+00:00

ZTE zxdrm driver support for 4.10: This is the initial ZTE VOU display controller DRM/KMS driver. There are still some features to be added, like overlay plane, scaling, and more output devices support. But it's already useful with dual CRTCs and HDMI display working. [airlied: use drm_format_plane_cpp instead of legacy api] * tag 'zxdrm-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: MAINTAINERS: add an entry for ZTE ZX DRM driver drm: zte: add initial vou drm driver dt-bindings: add bindings doc for ZTE VOU display controller

drm: Make DRM_DEBUG_MM depend on STACKTRACE_SUPPORT

2016-11-09T16:27:54+00:00

0day continues to complain about trying to save a stacktrace for the users of the drm_mm range allocator. This time, it is that m68k has no save_stack_trace(), which is apparently guarded by STACKTRACE_SUPPORT. Make it depend so! Reported-by: kbuild test robot Signed-off-by: Chris Wilson Cc: Daniel Vetter Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161109143906.11057-1-chris@chris-wilson.co.uk

drm: Restrict stackdepot usage to builtin drm.ko

2016-11-09T01:13:43+00:00

I misread the kbuild result thinking that we had missed the include (which we had for completeness anyway), what kbuild was actually warning me about was that depot_save_stack was not exported. Temporarily fix this by only selecting STACKDEPOT iff drm.ko is builtin Reported-by: kbuild test robot Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on shutdown") Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161108131917.6253-2-chris@chris-wilson.co.uk

drm: Track drm_mm allocators and show leaks on shutdown

2016-11-08T09:35:29+00:00

We can use the kernel's stack tracer and depot to record the allocation site of every drm_mm user. Then on shutdown, as well as warning that allocated nodes still reside with the drm_mm range manager, we can display who allocated them to aide tracking down the leak. v2: Move Kconfig around so it lies underneath the DRM options submenu. Signed-off-by: Chris Wilson Reviewed-by: Christian König Signed-off-by: Daniel Vetter Link: http://patchwork.freedesktop.org/patch/msgid/20161031090806.20073-1-chris@chris-wilson.co.uk

drm: zte: add initial vou drm driver

2016-11-07T03:02:31+00:00

It adds the initial ZTE VOU display controller DRM driver. There are still some features to be added, like overlay plane, scaling, and more output devices support. But it's already useful with dual CRTCs and HDMI monitor working. Signed-off-by: Shawn Guo

Revert "drm: make DRI1 drivers depend on BROKEN"

2016-08-31T20:16:12+00:00

This reverts commit d10571fc4fba7d57fb8157f0be61dcbe4a7965ca. This isn't how we get to do this unfortunately. Signed-off-by: Dave Airlie