[PATCH] amdgpu: use NULL instead of 0 for pointer

Am 15.06.2016 um 22:15 schrieb Arnd Bergmann: > In the AMD powerplay driver, a pointer is checked for validity by > comparing against an integer '0', which causes a harmless warning > when building with "make W=1": > > drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/processpptables.c:1502:16: >

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 10:05 PM, Russell King - ARM Linux wrote: > On Wed, Jun 15, 2016 at 09:29:38PM +0200, Daniel Vetter wrote: >> On Wed, Jun 15, 2016 at 7:21 PM, Liviu Dudau wrote: >> > Could be the tda998x_drv fault, but I'm getting this splat: >> >> Yeah, tda9998x needs to be fixed to

[PATCH] amdgpu: use NULL instead of 0 for pointer

In the AMD powerplay driver, a pointer is checked for validity by comparing against an integer '0', which causes a harmless warning when building with "make W=1": drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/processpptables.c:1502:16: error: ordered comparison of pointer with integer zero

[PATCH v2 09/11] net: skfb: remove obsolete -I cflag

From: Arnd Bergmann Date: Wed, 15 Jun 2016 17:45:51 +0200 > The skfp driver has been moved to drivers/net/fddi/skfp a long time > ago, but we still attempt to include headers from the old location, > which causes a warning when building with W=1: > > cc1: error:

[Intel-gfx] [PATCH 12/14] drm: Move master pointer from drm_minor to drm_device

On Wed, Jun 15, 2016 at 6:33 PM, Chris Wilson wrote: > On Wed, Jun 15, 2016 at 06:01:41PM +0200, Daniel Vetter wrote: >> On Wed, Jun 15, 2016 at 01:10:35PM +0100, Chris Wilson wrote: >> > On Tue, Jun 14, 2016 at 08:51:07PM +0200, Daniel Vetter wrote: >> > > There can only be one current master,

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 7:21 PM, Liviu Dudau wrote: > On Wed, Jun 15, 2016 at 07:13:15PM +0200, Daniel Vetter wrote: >> On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote: >> > On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote: >> >> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu

[PATCH 3/3] ARM: dts: rockchip: enable hdmi audio on rk3036-kylin

Enable the basic hdmi audio function on rk3036 kylin board. Signed-off-by: Yakir Yang --- arch/arm/boot/dts/rk3036-kylin.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/rk3036-kylin.dts b/arch/arm/boot/dts/rk3036-kylin.dts index 1df1557..070cfe1 100644 ---

[PATCH 2/3] ARM: dts: rockchip: add simple sound card for RK3036 SoCs

Using I2S as the audio input source, and force the mclk_fs to 256. Signed-off-by: Yakir Yang --- arch/arm/boot/dts/rk3036.dtsi | 22 ++ 1 file changed, 22 insertions(+) diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi index 843d2be..ecff071 100644

[PATCH 1/3] drm/rockchip: inno_hdmi: add audio support

Using the common hdmi-codec driver to support hdmi audio function. Signed-off-by: Yakir Yang --- drivers/gpu/drm/rockchip/inno_hdmi.c | 237 ++- drivers/gpu/drm/rockchip/inno_hdmi.h | 2 + 2 files changed, 237 insertions(+), 2 deletions(-) diff --git

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 06:21:04PM +0100, Liviu Dudau wrote: > Could be the tda998x_drv fault, but I'm getting this splat: > > [1.347687] kobject_add_internal failed for card0-HDMI-A-1 (error: -2 > parent: card0) Right, so this is -ENOENT - I expect that it's complaining that the parent

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 09:29:38PM +0200, Daniel Vetter wrote: > On Wed, Jun 15, 2016 at 7:21 PM, Liviu Dudau wrote: > > Could be the tda998x_drv fault, but I'm getting this splat: > > Yeah, tda9998x needs to be fixed to _not_ register it's connector > before the overall (componentized) driver

[PATCH v3 6/6] iommu/rockchip: enable rockchip iommu on ARM64 platform

From: Simon Xue This patch makes it possible to compile the rockchip-iommu driver on ARM64 platform to be used with 64-bit SoCs equipped with this type of IOMMU. Signed-off-by: Simon Xue Signed-off-by: Shunqian Zheng Reviewed-by: Tomasz Figa --- drivers/iommu/Kconfig |

[PATCH v3 5/6] iommu/rockchip: use DMA API to map, to flush cache

Use DMA API instead of architecture internal functions like __cpuc_flush_dcache_area() etc. To support the virtual device like DRM the virtual slave iommu added in the previous patch, attaching to which the DRM can use it own domain->dev for dma_map_*(), dma_sync_*() even VOP is disabled. With

[PATCH v3 4/6] drm: rockchip: use common iommu api to attach iommu

Rockchip DRM used the arm special API, arm_iommu_*(), to attach iommu for ARM32 SoCs. This patch convert to common iommu API so it would support ARM64 like RK3399. The general idea is domain_alloc(), attach_device() and arch_setup_dma_ops() to set dma_ops manually for DRM at the last.

[PATCH v3 3/6] iommu/rockchip: support virtual iommu slave device

An virtual master device like DRM need to attach to iommu domain to share the mapping with VOPs(the one with actual iommu slaves). DRM attaches to iommu and allocates buffers before VOPs enabled, which means there may have not real iommu devices can be used to do dma mapping. This patch creates a

[PATCH v3 2/6] iommu/rockchip: add map_sg callback for rk_iommu_ops

From: Simon Xue The iommu_dma_alloc() in iommu/dma-iommu.c calls iommu_map_sg() that requires the callback iommu_ops .map_sg(). Adding the default_iommu_map_sg() to rockchip iommu accordingly. Signed-off-by: Simon Xue Signed-off-by: Shunqian Zheng Reviewed-by: Tomasz Figa

[PATCH v3 1/6] iommu/rockchip: fix devm_{request,free}_irq parameter

From: Simon Xue Even though the iommu shares irq with its master, using the *dev of iommu instead of master's *dev for devm_{request,free}_irq makes things clear. Signed-off-by: Simon Xue Signed-off-by: Shunqian Zheng Reviewed-by: Tomasz Figa ---

[PATCH v3 0/6] fix bugs; enable iommu for ARM64

This series patches mainly for ARM64 supporting. To do this, it first add virtual iommu slave device which DRM can attach to, convert DRM driver to use common iommu API instead of the ARM32 functions, and then use DMA API in iommu driver to map, to flush cache. Mainly changes of V3: - Instead

[pull] radeon and amdgpu drm-fixes-4.7

Hi Dave, radeon and amdgpu fixes for 4.7. Highlights: - fixes for GPU VM passthrough - fixes for powerplay on Polaris GPUs - pll fixes for rs780/880 The following changes since commit 27bf60db2485c09eba3b473ce5ffbaa4bba0c24e: Merge tag 'drm-amdkfd-fixes-2016-06-03' of

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 7:13 PM, Daniel Vetter wrote: > On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote: >> On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote: >>> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote: >>> > Add support for the new family of Display

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote: > On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote: >> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote: >> > Add support for the new family of Display Processors from ARM Ltd. >> > This commit adds basic support for Mali

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 06:35:37PM +0100, Chris Wilson wrote: > On Wed, Jun 15, 2016 at 06:21:04PM +0100, Liviu Dudau wrote: > > On Wed, Jun 15, 2016 at 07:13:15PM +0200, Daniel Vetter wrote: > > > On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau > > > wrote: > > > > On Wed, Jun 15, 2016 at

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 06:21:04PM +0100, Liviu Dudau wrote: > On Wed, Jun 15, 2016 at 07:13:15PM +0200, Daniel Vetter wrote: > > On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote: > > > On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote: > > >> On Wed, Jun 15, 2016 at 03:51:34PM

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 07:13:15PM +0200, Daniel Vetter wrote: > On Wed, Jun 15, 2016 at 6:17 PM, Liviu Dudau wrote: > > On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote: > >> On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote: > >> > Add support for the new family of

[PATCH v5 3/3] MAINTAINERS: Add entry for Mali-DP driver

On Wed, Jun 15, 2016 at 04:35:24PM +0100, Eric Engestrom wrote: > On Wed, Jun 15, 2016 at 03:51:35PM +0100, Liviu Dudau wrote: > > Add MAINTAINERS entry for ARM Mali-DP driver and update the > > HDLCD file matching pattern to cover only HDLCD rather than > > the whole drivers/gpu/drm/arm

[Intel-gfx] [PATCH 12/14] drm: Move master pointer from drm_minor to drm_device

On Wed, Jun 15, 2016 at 01:10:35PM +0100, Chris Wilson wrote: > On Tue, Jun 14, 2016 at 08:51:07PM +0200, Daniel Vetter wrote: > > There can only be one current master, and it's for the overall device. > > Render/control minors don't support master-based auth at all. > > > > This simplifies the

[Intel-gfx] [PATCH 09/14] drm: Protect authmagic with master_mutex

On Wed, Jun 15, 2016 at 12:54:24PM +0100, Chris Wilson wrote: > On Tue, Jun 14, 2016 at 08:51:04PM +0200, Daniel Vetter wrote: > > Simplifies cleanup, and there's no reason drivers should ever care > > about authmagic at all - it's all handled in the core. > > > > And with that, Ladies and

[Intel-gfx] [PATCH 07/14] drm: Only do the hw.lock cleanup in master_relase for !MODESET

On Wed, Jun 15, 2016 at 12:48:23PM +0100, Chris Wilson wrote: > On Tue, Jun 14, 2016 at 08:51:02PM +0200, Daniel Vetter wrote: > > Another place gone where modern drivers could have hit > > dev->struct_mutex. > > > > To avoid too deeply nesting control flow rework it a bit. > > > >

[Intel-gfx] [PATCH 04/14] drm: Move master functions into drm_auth.c

On Wed, Jun 15, 2016 at 12:31:20PM +0100, Chris Wilson wrote: > On Tue, Jun 14, 2016 at 08:50:59PM +0200, Daniel Vetter wrote: > > For modern drivers pretty much the only thing drm_master does is > > handling authentication for the primary/legacy drm_minor node. Instead > > of having it all over

[PATCH v2 11/11] [EXPERIMENTAL] Kbuild: enable -Wmissing-include-dirs by default

I have fixed up all -Wmissing-include-dirs on ARM randconfig builds, so we could make this the default, but I have not tested this at all on other architectures. This enables it anyway, just to see what other warnings we get when the build bot analyses the branch. Don't apply (yet).

[PATCH v2 10/11] rtlwifi: don't add include path for rtl8188ee

For rtl8188ee, we pass -Idrivers/net/wireless/rtlwifi/ to gcc, however that directy no longer exists, so evidently this option is no longer required here and can be removed to avoid a warning when building with 'make W=1' or 'gcc -Wmissing-include-dirs' Signed-off-by: Arnd Bergmann ---

[PATCH v2 09/11] net: skfb: remove obsolete -I cflag

The skfp driver has been moved to drivers/net/fddi/skfp a long time ago, but we still attempt to include headers from the old location, which causes a warning when building with W=1: cc1: error: /git/arm-soc/drivers/net/skfp: No such file or directory [-Werror=missing-include-dirs] cc1: error:

[PATCH v2 08/11] drm: amd: remove broken include path

The AMD ACP driver adds "-I../acp -I../acp/include" to the gcc command line, which makes no sense, since these are evaluated relative to the build directory. When we build with "make W=1", they instead cause a warning: cc1: error: ../acp/: No such file or directory [-Werror=missing-include-dirs]

[PATCH v2 07/11] ARM: hide mach-*/ include for ARM_SINGLE_ARMV7M

The machine specific header files are exported for traditional platforms, but not for the ones that use ARCH_MULTIPLATFORM, as they could conflict with one another. In case of ARM_SINGLE_ARMV7M, we end up also exporting them, but that appears to be a mistake, and we should treat it the same way

[Intel-gfx] [PATCH 03/14] drm: Link directly from drm_master to drm_device

On Wed, Jun 15, 2016 at 01:50:02PM +0100, Emil Velikov wrote: > On 14 June 2016 at 19:50, Daniel Vetter wrote: > > Master-based auth only exists for the legacy/primary drm_minor, hence > > there can only be one per device. The goal here is to untangle the > > epic dereference games of

[PATCH v2 06/11] ARM: don't include removed directories

Three platforms used to have header files in include/mach that are now all gone, but the removed directories are still being included, which leads to -Wmissing-include-dirs warnings. This removes the extra -I flags. Signed-off-by: Arnd Bergmann --- arch/arm/mach-mvebu/Makefile| 3 +--

[PATCH v2 05/11] Kbuild: don't add obj tree in additional includes

When building with separate object directories and driver specific Makefiles that add additional header include paths, Kbuild adjusts the gcc flags so that we include both the directory in the source tree and in the object tree. However, due to another bug I fixed earlier, this did not actually

[PATCH v2 04/11] Kbuild: arch: look for generated headers in obtree

There are very few files that need add an -I$(obj) gcc for the preprocessor or the assembler. For C files, we add always these for both the objtree and srctree, but for the other ones we require the Makefile to add them, and Kbuild then adds it for both trees. As a preparation for changing the

[PATCH v2 03/11] Kbuild: always prefix objtree in LINUXINCLUDE

When $(LINUXINCLUDE) is added to the cflags of a target that normall doesn't have it (e.g. HOSTCFLAGS), each entry in the list is expanded so that we search both $(objtree) and $(srctree), which is a bit silly, as we already know which of the two we want for each entry in LINUXINCLUDE. Also, a

[PATCH v2 02/11] Kbuild: avoid duplicate include path

arch/$(hdr-arch)/include/generated/uapi is included twice in the header search path, which is unnecessary, so this changes the top-level Makefile to drop the second instance by filtering out everything from USERINCLUDE that was already part of LINUXINCLUDE. This should have very little effect

[PATCH v2 01/11] Kbuild: don't add ../../ to include path

When we build with O=objdir and objdir is directly below the source tree, $(srctree) becomes '..'. When a Makefile adds a CFLAGS option like -Ipath/to/headers and we are building with a separate object directory, Kbuild tries to add two -I options, one for the source tree and one for the object

[PATCH v2 00/11] Kbuild: fix -Wmissing-include-path warnings

This warning is enabled at "make W=1" level, and found a bunch of actual problems in code that adds -I flags to nonexisting directories. All of these are harmless, but clearly wrong. Kbuild itself also adds a bunch of extra directories, including in some cases those outside of the kernel tree

[PULL] topic/drm-misc

On Tue, Jun 14, 2016 at 11:48:31PM +0200, Daniel Vetter wrote: > Hi Dave, > > More misc stuff all over: > - best_encoder cleanup from Boris. > - drm_simple_display_pipe helpers from Noralf. Looks really neat imo, and > there's 2-3 in-flight drivers which look like they could/should use it. >

[GIT PULL][drm-next] Please pull new drm/arm/malidp driver

Hi Dave, I would like to add the Mali DP driver to the drm-next tree. It has got several reviews and now the Acks from the relevant people. The tree is based on drm-intel/topic/drm-misc tree with tag topic/drm-misc-2016-06-14 and also needs two patches from Daniel to function correctly [1][2].

[Intel-gfx] [PATCH 12/14] drm: Move master pointer from drm_minor to drm_device

On Wed, Jun 15, 2016 at 06:01:41PM +0200, Daniel Vetter wrote: > On Wed, Jun 15, 2016 at 01:10:35PM +0100, Chris Wilson wrote: > > On Tue, Jun 14, 2016 at 08:51:07PM +0200, Daniel Vetter wrote: > > > There can only be one current master, and it's for the overall device. > > > Render/control minors

[PATCH] amdgpu: use NULL instead of 0 for pointer

On Wed, Jun 15, 2016 at 4:32 PM, Christian König wrote: > Am 15.06.2016 um 22:15 schrieb Arnd Bergmann: >> >> In the AMD powerplay driver, a pointer is checked for validity by >> comparing against an integer '0', which causes a harmless warning >> when building with "make W=1": >> >>

[PATCH] drm/atomic-helpers: Clear up cleanup_done a bit

On Wed, Jun 15, 2016 at 03:29:16PM +0100, Liviu.Dudau at arm.com wrote: > On Wed, Jun 15, 2016 at 12:24:26PM +0200, Daniel Vetter wrote: > > It's not obvious at first sight that this is a fastpath, make that > > clearer with a goto. Fallout from a discussion with Liviu on irc. > > > > v2: Drop

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote: > Add support for the new family of Display Processors from ARM Ltd. > This commit adds basic support for Mali DP500, DP550 and DP650 > parts, with only the display engine being supported at the moment. > > Cc: David Brown > Cc: Brian

[PATCH v5 3/3] MAINTAINERS: Add entry for Mali-DP driver

On Wed, Jun 15, 2016 at 06:12:08PM +0200, Daniel Vetter wrote: > On Wed, Jun 15, 2016 at 04:35:24PM +0100, Eric Engestrom wrote: > > On Wed, Jun 15, 2016 at 03:51:35PM +0100, Liviu Dudau wrote: > > > Add MAINTAINERS entry for ARM Mali-DP driver and update the > > > HDLCD file matching pattern to

Mali DP tree for linux-next

On Wed, Jun 15, 2016 at 04:03:04PM +0100, Liviu Dudau wrote: > Hi Stephen, > > I would like to add the Mali DP DRM driver tree to linux-next. I'm planning > to send a pull request for inclusion into v4.8 and I hope that getting a > wider exposure for a few weeks is beneficial. > > Please add the

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

On Wed, Jun 15, 2016 at 05:23:10PM +0200, Daniel Vetter wrote: > On Wed, Jun 15, 2016 at 03:51:34PM +0100, Liviu Dudau wrote: > > Add support for the new family of Display Processors from ARM Ltd. > > This commit adds basic support for Mali DP500, DP550 and DP650 > > parts, with only the display

[PULL] topic/drm-misc

On Tue, Jun 14, 2016 at 11:48:31PM +0200, Daniel Vetter wrote: > Hi Dave, > > More misc stuff all over: > - best_encoder cleanup from Boris. > - drm_simple_display_pipe helpers from Noralf. Looks really neat imo, and > there's 2-3 in-flight drivers which look like they could/should use it. >

Mali DP tree for linux-next

On Wed, Jun 15, 2016 at 05:21:02PM +0200, Daniel Vetter wrote: > On Wed, Jun 15, 2016 at 04:03:04PM +0100, Liviu Dudau wrote: > > Hi Stephen, > > > > I would like to add the Mali DP DRM driver tree to linux-next. I'm planning > > to send a pull request for inclusion into v4.8 and I hope that

[PATCH v2 00/15] Runtime pm ref leak bonanza

On Wed, Jun 15, 2016 at 01:37:35PM +0200, Lukas Wunner wrote: > On Tue, Jun 14, 2016 at 04:18:00PM -0400, Alex Deucher wrote: > > On Thu, Jun 9, 2016 at 2:50 AM, Daniel Vetter wrote: > > > On Wed, Jun 08, 2016 at 06:47:27PM +0200, Lukas Wunner wrote: > > >> Second iteration of my endeavour to rid

[PATCH 4/5] drm/amdgpu: Wait for end of last waited-for vblank before programming flip

On 14.06.2016 17:06, Daniel Vetter wrote: > On Tue, Jun 14, 2016 at 04:25:28PM +0900, Michel Dänzer wrote: >> On 14.06.2016 14:53, Daniel Vetter wrote: >>> On Tue, Jun 14, 2016 at 11:09:10AM +0900, Michel Dänzer wrote: On 06/13/16 23:06, Daniel Vetter wrote: > On Mon, Jun 13, 2016 at

[Bug 96512] Portal Stories Mel: Player's hands appear black at high shader quality

attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/b9ec4dd4/attachment.html>

[PATCH v8 1/2] drm/bridge: Add sii902x driver

On 06/14/2016 01:12 PM, Boris Brezillon wrote: > Add basic support for the sii902x RGB -> HDMI bridge. > This driver does not support audio output yet. > Thanks for incorporating the comments. Acked-by: Archit Taneja > Signed-off-by: Boris Brezillon > Tested-by: Nicolas Ferre > --- >

[Bug 96360] [bisected: 3d02b7] VM fault with kernel 4.7-rc1 on Alien: Isolation

bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/55109b45/attachment.html>

[PATCH v5 3/3] MAINTAINERS: Add entry for Mali-DP driver

On Wed, Jun 15, 2016 at 03:51:35PM +0100, Liviu Dudau wrote: > Add MAINTAINERS entry for ARM Mali-DP driver and update the > HDLCD file matching pattern to cover only HDLCD rather than > the whole drivers/gpu/drm/arm directory. > > Signed-off-by: Liviu Dudau > --- > MAINTAINERS | 10 +-

[PATCH 1/3] RFC: drm: Restrict vblank ioctl to master

On 14.06.2016 18:35, Daniel Vetter wrote: > On Tue, Jun 14, 2016 at 11:09 AM, Michel Dänzer > wrote: >> On 14.06.2016 18:03, Daniel Vetter wrote: >>> Somehow this escaped us, this is a KMS ioctl which should only be used >>> by the master (which is the thing that's also in control of kms >>>

Mali DP tree for linux-next

Hi Stephen, I would like to add the Mali DP DRM driver tree to linux-next. I'm planning to send a pull request for inclusion into v4.8 and I hope that getting a wider exposure for a few weeks is beneficial. Please add the following git tree: git://linux-arm.org/linux-ld for-upstream/mali-dp

[PATCH v5 3/3] MAINTAINERS: Add entry for Mali-DP driver

Add MAINTAINERS entry for ARM Mali-DP driver and update the HDLCD file matching pattern to cover only HDLCD rather than the whole drivers/gpu/drm/arm directory. Signed-off-by: Liviu Dudau --- MAINTAINERS | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS

[PATCH v5 2/3] drm/arm: Add support for Mali Display Processors

Add support for the new family of Display Processors from ARM Ltd. This commit adds basic support for Mali DP500, DP550 and DP650 parts, with only the display engine being supported at the moment. Cc: David Brown Cc: Brian Starkey Signed-off-by: Liviu Dudau --- drivers/gpu/drm/arm/Kconfig

[PATCH v5 1/3] dt/bindings: display: Add DT bindings for Mali Display Processors.

Add DT bindings documentation for the Mali Display Processor. The bindings describe the Mali DP500, DP550 and DP650 processors from ARM Ltd. Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Signed-off-by: Liviu Dudau Acked-by: Rob Herring

[PATCH v5 0/3] Add support for ARM Mali Display Processors

Hello, This is the fifth revision of the driver for the Mali Display Processors (Mali DP). Currently, the driver supports the Display Engine found in Mali DP500, DP550 and DP650, with up to 3 planes that can be rotated by the hardware. There are features that the hardware supports that are not

[Bug 95427] gem_userptr_blits@mlocked-* should skip due to memory pre-condition not met

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/fc59c57a/attachment.html>

[Bug 90400] [KBL APL SKL BSW BDW]igt/gem_ppgtt/flink-and-close-vma-leak fails

still a kernel bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/b2a32da6/attachment-0001.html>

[Bug 90400] [KBL APL SKL BSW BDW]igt/gem_ppgtt/flink-and-close-vma-leak fails

-- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/6f4d1276/attachment-0001.html>

[PATCH v2 3/3] iommu: convert DT component matching to component_match_add_release()

On Fri, Jun 03, 2016 at 03:21:30PM +0100, Russell King wrote: > Convert DT component matching to use component_match_add_release(). > > Signed-off-by: Russell King > --- > drivers/iommu/mtk_iommu.c | 14 ++ > 1 file changed, 6 insertions(+), 8

[PATCH] drm/atomic-helpers: Clear up cleanup_done a bit

On Wed, Jun 15, 2016 at 12:24:26PM +0200, Daniel Vetter wrote: > It's not obvious at first sight that this is a fastpath, make that > clearer with a goto. Fallout from a discussion with Liviu on irc. > > v2: Drop bogus hunks that crept in. > > Cc: Liviu.Dudau at arm.com > Acked-by: Liviu.Dudau

[PATCH v2 0/6] drm/tilcdc Fixes and cleanups

On 06/15/16 11:39, Jyri Sarha wrote: > Some fixes and cleanups that should get merged to tilcdc even if my > atomic changes are still a work in progress. > I forgot to add changelog. So here it is: Changes since first version: - "drm/tilcdc: Restore old dpms state in pm_resume()" - Fix typos

[PATCH 1/6] drm/ttm: remove no_gpu_wait param from ttm_bo_move_accel_cleanup

Alex do you want to pull that in through your branches or should I send Dave a separate pull request for the TTM changes? BTW: I'm trying to enable this on radeon as well. In theory it should work out of the box. Regards, Christian. Am 15.06.2016 um 13:44 schrieb Christian König: > From:

[PATCH] drm/atomic-helpers: Stall on the right commit

On Tue, Jun 14, 2016 at 07:50:58PM +0200, Daniel Vetter wrote: > stall_checks carefully picked out the right commit to stall on, then > promptly used the wrong variable. Due to the break in the next loop > iteration this could be the 3rd commit, or if the list only has 2 > entries commit would now

[Bug 96512] Portal Stories Mel: Player's hands appear black at high shader quality

because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160615/6f957803/attachment.html>

[PATCH 3/5] drm/dp/mst: change MST detection scheme

On 15 June 2016 at 13:49, Dave Airlie wrote: > Excuse me for top posting. > > So I finally got back to this patch, still don't like it. > > Apart from the doing 3 things in once which is just annoying, current > userspace for tiled monitors > relies on the behaviour that the cached edids are

[RESEND PATCH v3 2/2] PM / Domains: Remove redundant wrapper functions for system PM

Ulf Hansson writes: > Due to the previous changes to genpd, which removed the suspend_power_off > flag, several of the system PM callbacks is no longer doing any additional > checks but only invoking a corresponding pm_generic_* helper function. > > To clean up the code let's remove these

[RESEND PATCH v3 1/2] PM / Domains: Allow genpd to power on during the system PM phases

Ulf Hansson writes: > If the PM domain is powered off when the first device starts its system PM > prepare phase, genpd prevents any further attempts to power on the PM > domain during the following system PM phases. Not until the system PM > complete phase is finalized for all devices in the PM

[PATCH] drm/vmwgfx: use *_32_bits() macros

On 06/15/2016 01:11 PM, Daniel Vetter wrote: > On Wed, Jun 15, 2016 at 10:37:24AM +0200, Paul Bolle wrote: >> [Added Sinclair, Thomas, and "VMware Graphics".] >> >> On do, 2016-04-14 at 07:34 -0700, Joe Perches wrote: >>> On Thu, 2016-04-14 at 13:32 +0200, Paul Bolle wrote: On do, 2016-03-03

[Intel-gfx] [PATCH 03/14] drm: Link directly from drm_master to drm_device

On 14 June 2016 at 19:50, Daniel Vetter wrote: > Master-based auth only exists for the legacy/primary drm_minor, hence > there can only be one per device. The goal here is to untangle the > epic dereference games of minor->master and master->minor which is > just massively confusing. > Good

[PATCH 3/5] drm/dp/mst: change MST detection scheme

Excuse me for top posting. So I finally got back to this patch, still don't like it. Apart from the doing 3 things in once which is just annoying, current userspace for tiled monitors relies on the behaviour that the cached edids are retrieved before the connector is show to userspace. This is

[PATCH 6/6] drm/amdgpu: pipeline evictions as well

From: Christian König This boosts Xonotic from 38fps to 47fps when artificially limiting VRAM to 256MB for testing. It should improve all CPU bound rendering situations where we have a lot of swapping to/from VRAM. Signed-off-by: Christian König ---

[PATCH 5/6] drm/amdgpu: save the PD addr before scheduling the job

From: Christian König When we pipeline evictions the page directory could already be moving somewhere else when grab_id is called. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++ 2

[PATCH 4/6] drm/ttm: add the infrastructur for pipelined evictions

From: Christian König Free up the memory immediately, remember the last eviction for each domain and make new allocations depend on the last eviction to be completed. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 49 ++---

[PATCH 3/6] drm/ttm: simplify ttm_bo_wait

From: Christian König As far as I can see no need for a custom implementation any more. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 37 - 1 file changed, 4 insertions(+), 33 deletions(-) diff --git

[PATCH 2/6] drm/ttm: remove TTM_BO_PRIV_FLAG_MOVING

From: Christian König Instead of using the flag just remember the fence of the last move operation. This avoids waiting for command submissions pipelined after the move, but before accessing the BO with the CPU again. Signed-off-by: Christian König ---

[PATCH 1/6] drm/ttm: remove no_gpu_wait param from ttm_bo_move_accel_cleanup

From: Christian König It isn't used and not waiting for the GPU after scheduling a move is actually quite dangerous. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 +-- drivers/gpu/drm/nouveau/nouveau_bo.c| 1 -

[PATCH v2 00/15] Runtime pm ref leak bonanza

On Tue, Jun 14, 2016 at 04:18:00PM -0400, Alex Deucher wrote: > On Thu, Jun 9, 2016 at 2:50 AM, Daniel Vetter wrote: > > On Wed, Jun 08, 2016 at 06:47:27PM +0200, Lukas Wunner wrote: > >> Second iteration of my endeavour to rid nouveau, radeon and amdgpu of > >> runtime pm ref leaks. > >> > >>

[PATCH 13/44] drm: Minimally initialise drm_dp_aux

When trying to split up the initialisation phase and the registration phase, one immediate problem encountered is trying to use our own i2c devices before registration with userspace (to read EDID during device discovery). drm_dp_aux in particular only offers an interface for setting up the device

[PATCH 12/44] drm: Pass the drm_dp_aux->hw_mutex to i2c for its locking

Rather than have both drm_dp_aux lock within its transfer, and i2c to lock around the transfer, use the same lock by filling in the locking callbacks that i2c wants to use. We require our own hw_mutex as we bypass i2c_transfer for drm_dp_dpcd_access(). Signed-off-by: Chris Wilson Cc: Dave Airlie

[PATCH 11/44] drm/rcar-du: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility

[PATCH 10/44] drm/msm: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility

[PATCH 09/44] drm/mediatek: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility

[PATCH 08/44] drm/hisilicon: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility

[PATCH 07/44] drm/atmel-hlcdc: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility

[PATCH 06/44] drm/arc: Remove redundant calls to drm_connector_register_all()

Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register() and not suffer from any backwards compatibility

[PATCH 05/44] drm: Automatically register/unregister all connectors

As the drm_connector is now safe for multiple calls to register/unregister, automatically perform a registration on all known connectors drm drv_register (and unregister from drm_drv_unregister). Drivers can still call drm_connector_register() and drm_connector_unregister() individually, or defer

[PATCH 04/44] drm: Automatically unregister the connector during cleanup

As we now can call drm_connector_unregister() multiple times, provide a failsafe unregister for a connector when cleaning it up. v2: Add a WARN to catch any connectors that are still visible to userspace when we come to destoy them. Signed-off-by: Chris Wilson Cc: Dave Airlie Cc: dri-devel at

[PATCH 03/44] drm: Make drm_connector_register() safe against multiple calls

Protect against drivers that may try to register the connector more than once, or who try to unregister it multiple times. Signed-off-by: Chris Wilson Cc: Dave Airlie Cc: dri-devel at lists.freedesktop.org Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 9 +

[PATCH 02/44] drm: Add a callback from connector registering

If a driver wants to more precisely control its initialisation and in particular, defer registering its interfaces with userspace until after everything is setup, it also needs to defer registering the connectors. As some devices need more work during registration, add a callback so that drivers

[PATCH 01/44] drm: Export drm_dev_init() for subclassing

In order to allow drivers to pack their privates and drm_device into one struct (e.g. for subclassing), export the initialisation routines for struct drm_device. v2: Missed return ret. That error path had only one job to do! v3: Cross-referencing drm_dev_init/drm_dev_alloc in kerneldoc, fix

  1   2   >