[PATCH v7] drm/vc4: update cursors asynchronously through atomic

From: Gustavo Padovan Add support for async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what vc4_update_plane() did but through atomic. v7: Place the drm_atomic_set_fb_for_plane() call after the new FB

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

https://bugzilla.kernel.org/show_bug.cgi?id=199101 --- Comment #8 from Thorsten Leemhuis (regressi...@leemhuis.info) --- @Michel Dänzer: Any progress with this? It's on the list of regressions for 4.16 -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 100400] [Solved] Game Valhalla Hills crash on startup

https://bugs.freedesktop.org/show_bug.cgi?id=100400 Timothy Arceri changed: What|Removed |Added Version|17.0|git

[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

https://bugs.freedesktop.org/show_bug.cgi?id=105218 --- Comment #1 from Timothy Arceri --- To complete the bug report can you report which LLVM are you testing with? You can find it easily with: glxinfo | grep OpenGL -- You are receiving this mail because: You are the

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote: > dma_map_resource() is the right API (thought its current implementation > is fill with x86 assumptions). So i would argue that arch can decide to > implement it or simply return dma error address which trigger fallback > path into

Re: [PATCH 3/3] drm/omap: remove unused function

On 29/03/18 17:44, Sebastian Reichel wrote: >> * omap_fb.c:326: condition 0 is always false >> * omap_fb.c:326: condition 0 is always false >> * omap_fb.c:327: condition connector!=from is always false > > Looks like list_for_each_entry_from() is not properly understood > by the static

[PATCH libdrm 2/2] headers: Update README

Nouveau has made a very deliberate choice to hide its actual kernel ABI behind libdrm. i915 is no longer out of date. Signed-off-by: Daniel Stone --- include/drm/README | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/include/drm/README

[PATCH libdrm 1/2] headers: Sync with drm-next

Taken from the drm-next pull for 4.17-rc1 (694f54f680f7), and manually reconciled: core: - Dropped DRM_MODE_TYPE_ALL and DRM_MODE_FLAG_ALL; these are purely internal details of the bits accepted by the currently running kernel, and can not be generally relied on by userspace

[PATCH 09/24] drm/mtk: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: CK Hu

[PATCH 06/24] drm/omap: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Tomi

[PATCH 15/24] drm/tegra: Use drm_gem_fb_destroy

Now that our destroy function is the same as the helper, use that directly. Signed-off-by: Daniel Stone Cc: Thierry Reding Cc: linux-te...@vger.kernel.org --- drivers/gpu/drm/tegra/fb.c | 17 + 1 file changed, 1 insertion(+), 16

[PATCH 07/24] drm/omap: Move buffer pitch/offset to drm_framebuffer

drm_framebuffer already holds per-plane pitch and offsets, which is filled out for us when we create the framebuffer. Nuke our local copy in the plane struct. Signed-off-by: Daniel Stone Cc: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fb.c | 22

[PATCH 24/24] drm/amdgpu: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Alex

[PATCH 04/24] drm/rockchip: Place GEM BOs in drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Sandy

[PATCH 11/24] drm/tegra: Remove duplicate framebuffer num_planes

drm_framebuffer already stores num_planes for us. Signed-off-by: Daniel Stone Cc: Thierry Reding Cc: linux-te...@vger.kernel.org --- drivers/gpu/drm/tegra/drm.h | 1 - drivers/gpu/drm/tegra/fb.c | 6 ++ 2 files changed, 2 insertions(+), 5

[PATCH 22/24] drm/radeon: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Alex

[PATCH 03/24] drm/virtio: Place GEM BOs in drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Dave

[PATCH] drm/atomic: Add sanity checks to drm_atomic_helper_async_commit()

->atomic_async_update() requires that drivers update the plane->state object before returning. Make sure at least common properties have been updated. Cc: Gustavo Padovan Signed-off-by: Boris Brezillon --- Hello, This is a problem I had when

Re: [PATCH 00/24] drm_framebuffer boilerplate removal

Hi Alex, On 30 March 2018 at 15:47, Alex Deucher wrote: > On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote: >> I intend to remove create_handle when all drivers are converted over >> to placing BOs directly inside drm_framebuffer. For most

[PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the first 4k by passing 4096 as start of the address range passed to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and reserve the firmware framebuffer so that we can inherit it would always fail,

[PATCH] drm/imx: Remove last traces of struct imx_drm_crtc

When the definition of this struct was removed a forward declaration and an unused struct member were still left around. Remove them because they serve no purpose. Fixes 44b460cfe554 ("drm: imx: remove struct imx_drm_crtc and imx_drm_crtc_helper_funcs") Signed-off-by: Leonard Crestez

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 28/03/18 10:02 AM, Christian König wrote: > Yeah, that looks very similar to what I picked up from the older > patches, going to read up on that after my vacation. Yeah, I was just reading through your patchset and there are a lot of similarities. Though, I'm not sure what you're trying to

Re: [PATCH] drm/atmel-hlcdc: add command line option to specify preferred depth

On 2018-03-28 09:34, Boris Brezillon wrote: > Hi Peter, > > On Mon, 26 Mar 2018 09:35:02 +0200 > Peter Rosin wrote: > >> I have an sama5d31-based system with 64MB of memory and a 1920x1080 >> LVDS display wired for 16-bpp. When I enable legacy fbdev support, >> the contiguous

[PATCH v3 2/2] drivers: remove force dma flag from buses

With each bus implementing its own DMA configuration callback, there is no need for bus to explicitly have force_dma in its global structure. This patch modifies of_dma_configure API to accept an input parameter which specifies if implicit DMA configuration is required even when it is not

Re: [PATCH 3/3] drm/omap: remove unused function

Hi, On Thu, Mar 29, 2018 at 02:24:40PM +0100, Emil Velikov wrote: > On 29 March 2018 at 13:31, Sebastian Reichel > wrote: > > Hi, > > > > On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote: > >> On 29 March 2018 at 11:40, Tomi Valkeinen

[PATCH -next] drm/tegra: dc: Using NULL instead of plain integer

Fixes the following sparse warnings: drivers/gpu/drm/tegra/dc.c:2181:69: warning: Using plain integer as NULL pointer Signed-off-by: Wei Yongjun --- drivers/gpu/drm/tegra/dc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

It is bus specific aspect to map a given device on the bus and relevant firmware description of its DMA configuration. So, this change introduces 'dma_configure' as bus callback giving flexibility to busses for implementing its own dma configuration function. The change eases the addition of new

Re: [PATCH 3/3] drm/omap: remove unused function

Hi, On Thu, Mar 29, 2018 at 03:49:08PM +0300, Tomi Valkeinen wrote: > On 29/03/18 15:31, Sebastian Reichel wrote: > > Hi, > > > > On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote: > >> On 29 March 2018 at 11:40, Tomi Valkeinen wrote: > >>>

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 28/03/18 09:07 AM, Christian König wrote: > Am 28.03.2018 um 14:38 schrieb Christoph Hellwig: >> On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote: >>> From: "wda...@nvidia.com" >>> >>> Add an interface to find the first device which is upstream of both >>>

Re: [PATCH] drm/mxsfb: add poll_changed event handler to set_par on startup

On Tue, Mar 27, 2018 at 01:30:04PM +0200, Michael Grzeschik wrote: > On Mon, Mar 26, 2018 at 06:17:44PM +0200, Michael Grzeschik wrote: > > We move drm_kms_helper_poll_init behind the drm_fbdev_cma_init so the > > set_par will be called and fb will be active. > > > > As this commit message is

Re: [PATCH 3/3] drm/omap: remove unused function

Hi, On Thu, Mar 29, 2018 at 12:00:18PM +0100, Emil Velikov wrote: > On 29 March 2018 at 11:40, Tomi Valkeinen wrote: > > omap_framebuffer_get_next_connector() is not used, remove it. > > > Seems to have been unused for a few years now. > Namely since commit

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 28/03/18 12:28 PM, Christian König wrote: > I'm just using amdgpu as blueprint because I'm the co-maintainer of it > and know it mostly inside out. Ah, I see. > The resource addresses are translated using dma_map_resource(). As far > as I know that should be sufficient to offload all the

[Bug 105170] Radeon R9 Nano failed testing IB on GFX ring (-110). [amd64, kernel 4.15.4]

https://bugs.freedesktop.org/show_bug.cgi?id=105170 --- Comment #6 from erhar...@mailbox.org --- Created attachment 138443 --> https://bugs.freedesktop.org/attachment.cgi?id=138443=edit journalctl -k (kernel 4.16_rc7) -- You are receiving this mail because: You are the assignee for the

Re: [PATCH libdrm 1/2] headers: Sync with drm-next

On 30 March 2018 at 14:30, Alex Deucher wrote: > On Fri, Mar 30, 2018 at 8:28 AM, Daniel Stone wrote: >> Taken from the drm-next pull for 4.17-rc1 (694f54f680f7), and manually > > Reviewed-by: Alex Deucher Both pushed,

Re: [RFC 1/2] drm/vc4: Handle async page flips in the atomic_commit() path

On Fri, 30 Mar 2018 17:09:03 +0200 Boris Brezillon wrote: > Rework the atomic commit logic to handle async page flip requests in > the atomic update path. > > Async page flips are a bit more complicated than async cursor updates > (already handled in the

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 29/03/18 05:44 AM, Christian König wrote: > Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe: >> >> On 28/03/18 01:44 PM, Christian König wrote: >>> Well, isn't that exactly what dma_map_resource() is good for? As far as >>> I can see it makes sure IOMMU is aware of the access route and >>>

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

https://bugzilla.kernel.org/show_bug.cgi?id=199101 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC|

Re: [PATCH libdrm 2/2] headers: Update README

On Fri, Mar 30, 2018 at 8:28 AM, Daniel Stone wrote: > Nouveau has made a very deliberate choice to hide its actual kernel ABI > behind libdrm. i915 is no longer out of date. > > Signed-off-by: Daniel Stone Acked-by: Alex Deucher

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Quoting Hans de Goede (2018-03-30 13:37:40) > Hi, > > On 30-03-18 14:30, Chris Wilson wrote: > > Quoting Hans de Goede (2018-03-30 13:27:15) > >> Before this commit the WaSkipStolenMemoryFirstPage workaround code was > >> skipping the first 4k by passing 4096 as start of the address range passed

[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

https://bugs.freedesktop.org/show_bug.cgi?id=105218 --- Comment #2 from Timothy Arceri --- I built from source and for me the Terrain sample crashes with: An exception has occured: OGRE EXCEPTION(5:ItemIdentityException): Compute Job with name Terra/ShadowGenerator not

[PATCH] drm/tilcdc: Defer probe if there are no connectors

During probe there may not be any connectors yet if e.g. the panel failed or hasn't been probed yet. I hitting this in practice the panels probing was being delayed due to using a gpio backlight. Fix this by returning -EPROBE_DEFER so the probing will be retried. Signed-off-by: Sjoerd Simons

[Bug 105170] Radeon R9 Nano failed testing IB on GFX ring (-110). [amd64, kernel 4.15.4]

https://bugs.freedesktop.org/show_bug.cgi?id=105170 Alex Deucher changed: What|Removed |Added Attachment #137452|text/x-log |text/plain

Re: [PATCH 00/24] drm_framebuffer boilerplate removal

On Fri, Mar 30, 2018 at 11:00 AM, Daniel Stone wrote: > Hi Alex, > > On 30 March 2018 at 15:47, Alex Deucher wrote: >> On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote: >>> I intend to remove create_handle when all drivers

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Hi, On 30-03-18 14:44, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:37:40) Hi, On 30-03-18 14:30, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:27:15) Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the first 4k by passing 4096 as start

[Bug 105170] Radeon R9 Nano failed testing IB on GFX ring (-110). [amd64, kernel 4.15.4]

https://bugs.freedesktop.org/show_bug.cgi?id=105170 --- Comment #5 from erhar...@mailbox.org --- Still no luck with kernel 4.15.14 or 4.16_rc7. The 2nd card in this system got no problems with the ring test (R9 290). # lspci | grep -i vga 01:00.0 VGA compatible controller: Advanced Micro

[PATCH 21/24] drm/msm: Move GEM BOs to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle function the same as the GEM framebuffer helper, we can reuse that. Signed-off-by: Daniel Stone Cc: Rob Clark

[PATCH 16/24] drm/exynos: Move GEM BOs to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Inki

[PATCH 17/24] drm/exynos: Move dma_addr out of exynos_drm_fb

This can be calculated from the GEM BO DMA address as well as the offset stored in the base framebuffer. Signed-off-by: Daniel Stone Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin

[PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we can remove it. Signed-off-by: Daniel Stone Cc: Sandy Huang Cc: Heiko Stübner --- drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54 ++---

[PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Russell

[PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer

Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can just delete it. Signed-off-by: Daniel Stone Cc: CK Hu Cc: Philipp Zabel --- drivers/gpu/drm/mediatek/mtk_drm_fb.c | 40 ---

[PATCH 13/24] drm/tegra: tegra_fb -> drm_framebuffer

Since tegra_fb is now the same as drm_framebuffer, we can just replace the type completely. Signed-off-by: Daniel Stone Cc: Thierry Reding Cc: linux-te...@vger.kernel.org --- drivers/gpu/drm/tegra/drm.h | 6 +- drivers/gpu/drm/tegra/fb.c |

[PATCH 14/24] drm/tegra: Move fbdev unmap special case

User framebuffers are created with either bo->pages or bo->vaddr set, depending on whether or not an IOMMU is present. On the other hand, the framebuffer created for fbdev emulation has a vaddr mapping made if bo->pages is set after creation. This is set up in fbdev probe. Remove the special case

[PATCH 08/24] drm/mtk: Promote impossible internal error to WARN_ON

A FB with no object is something we should be shouting very loudly about, not quietly logging as debug. Signed-off-by: Daniel Stone Cc: CK Hu Cc: Philipp Zabel --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 + 1 file

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Thu, Mar 29, 2018 at 11:33:34PM -0700, Christoph Hellwig wrote: > On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote: > > dma_map_resource() is the right API (thought its current implementation > > is fill with x86 assumptions). So i would argue that arch can decide to > > implement

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Hi, On 30-03-18 14:30, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:27:15) Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the first 4k by passing 4096 as start of the address range passed to drm_mm_init(). This means that calling

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

https://bugzilla.kernel.org/show_bug.cgi?id=199101 --- Comment #10 from Thomas Crider (tcride...@gmail.com) --- just fyi I do not get the flicker on 4.16 rc3, this may help to shorten the time it takes to bisect -- You are receiving this mail because: You are watching the assignee of the bug.

Re: [PATCH libdrm 1/2] headers: Sync with drm-next

On Fri, Mar 30, 2018 at 8:28 AM, Daniel Stone wrote: > Taken from the drm-next pull for 4.17-rc1 (694f54f680f7), and manually > reconciled: > > core: > - Dropped DRM_MODE_TYPE_ALL and DRM_MODE_FLAG_ALL; these are purely > internal details of the bits accepted by

[PATCH 02/24] drm/cirrus: cirrus_framebuffer -> drm_framebuffer

Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer, we can drop it. Signed-off-by: Daniel Stone Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org ---

[PATCH 20/24] drm/gma500: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Patrik

[PATCH 23/24] drm/radeon: radeon_framebuffer -> drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Alex

[PATCH 01/24] drm/cirrus: Place GEM BOs in drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle and destroy functions the same as the GEM framebuffer helper, we can reuse those. Signed-off-by: Daniel Stone Cc: Dave

[PATCH 18/24] drm/exynos: exynos_drm_fb -> drm_framebuffer

Now exynos_drm_fb is just an empty wrapper around drm_framebuffer, we can drop it. Signed-off-by: Daniel Stone Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park

[PATCH 12/24] drm/tegra: Move GEM BOs to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them there rather than in our own subclass. As this makes the framebuffer create_handle function the same as the GEM framebuffer helper, we can reuse that. Signed-off-by: Daniel Stone Cc: Thierry Reding

[PATCH -next] drm/amdkfd: Make function kfd_dev_is_large_bar() static

Fixes the following sparse warning: drivers/gpu/drm/amd/amdkfd/kfd_chardev.c:1150:6: warning: symbol 'kfd_dev_is_large_bar' was not declared. Should it be static? Signed-off-by: Wei Yongjun --- drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +- 1 file changed, 1

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 28/03/18 01:44 PM, Christian König wrote: > Well, isn't that exactly what dma_map_resource() is good for? As far as > I can see it makes sure IOMMU is aware of the access route and > translates a CPU address into a PCI Bus address. > I'm using that with the AMD IOMMU driver and at least

[PATCH -next] drm/amdgpu: fix error return code in amdgpu_amdkfd_gpuvm_create_process_vm()

Fix to return error code -ENOMEM from the eviction fence create fail error handling case instead of 0, as done elsewhere in this function. Fixes: a46a2cd103a8 ("drm/amdgpu: Add GPUVM memory management functions for KFD") Signed-off-by: Wei Yongjun ---

[PATCH -next] drm/amdkfd: Fix the error return code in kfd_ioctl_unmap_memory_from_gpu()

Passing NULL pointer to PTR_ERR will result in return value of 0 indicating success which is clearly not what it is intended here. This patch returns -EINVAL instead. Fixes: 5ec7e02854b3 ("drm/amdkfd: Add ioctls for GPUVM memory management") Signed-off-by: Wei Yongjun ---

[PATCH v2] drm/mxsfb: add output_poll_changed handler for initial configuration

The driver registers the poll helper but has no output plug handler registered. Therefor kms_hotplug_event doesn't trigger any configuration changes on the framebuffer. The initial configuration setup, after drm_kms_helper_poll_init is started, will also be missed. This is running the framebuffer

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On 29/03/18 10:10 AM, Christian König wrote: > Why not? I mean the dma_map_resource() function is for P2P while other > dma_map_* functions are only for system memory. Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping P2P. Though it's a bit odd seeing we've been working

[Bug 105170] Radeon R9 Nano failed testing IB on GFX ring (-110). [amd64, kernel 4.15.4]

https://bugs.freedesktop.org/show_bug.cgi?id=105170 --- Comment #7 from Alex Deucher --- Does anything change if you try the cards in different slots in the motherboard? -- You are receiving this mail because: You are the assignee for the

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Hi, On 30-03-18 15:25, Hans de Goede wrote: Hi, On 30-03-18 14:44, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:37:40) Hi, On 30-03-18 14:30, Chris Wilson wrote: Quoting Hans de Goede (2018-03-30 13:27:15) Before this commit the WaSkipStolenMemoryFirstPage workaround code was

Re: [PATCH 00/24] drm_framebuffer boilerplate removal

On Fri, Mar 30, 2018 at 10:11 AM, Daniel Stone wrote: > Hi, > I've been working on a getfb2[0] ioctl, which amongst other things > supports multi-planar framebuffers as well as modifiers. getfb > currently calls the framebuffer's handle_create hook, which doesn't > support

[RFC 0/2] drm/vc4: Async page flip cleanup

Hello, This is an attempt at simplifying the async page flip handling in VC4 in order to get rid of vc4_queue_seqno_cb() and its dependencies and rely on fences instead. The reason I'm sending this as an RFC is because I'm pretty sure we can put some of the code added in patch 1 in

[RFC 2/2] drm/vc4: Get rid of vc4_queue_seqno_cb() and its dependencies

The last user of vc4_queue_seqno_cb() (async page flip handling code) is gone. Get rid of this function and all the related structs and fields. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/vc4/vc4_drv.h | 14 -- drivers/gpu/drm/vc4/vc4_gem.c | 39

[RFC 1/2] drm/vc4: Handle async page flips in the atomic_commit() path

Rework the atomic commit logic to handle async page flip requests in the atomic update path. Async page flips are a bit more complicated than async cursor updates (already handled in the vc4_atomic_commit() function) in that you need to wait for fences on the new framebuffers to be signaled

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

Quoting Hans de Goede (2018-03-30 13:27:15) > Before this commit the WaSkipStolenMemoryFirstPage workaround code was > skipping the first 4k by passing 4096 as start of the address range passed > to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and > reserve the firmware

[PATCH 00/24] drm_framebuffer boilerplate removal

Hi, I've been working on a getfb2[0] ioctl, which amongst other things supports multi-planar framebuffers as well as modifiers. getfb currently calls the framebuffer's handle_create hook, which doesn't support multiple planes. Thanks to Noralf's recent work, drivers can just store GEM objects

[Bug 105760] [4.17-drm-wip] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

https://bugs.freedesktop.org/show_bug.cgi?id=105760 --- Comment #1 from taij...@posteo.de --- OK, I think I've managed to narrow this one down a bit. If I build the kernel from commit 09695ad78f1f5f315c7e9c5090f0c7b846a43690, which is also tagged as 'drm-next-4.17', then everything is shiny.

[Bug 105760] [4.17-drm-wip] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

https://bugs.freedesktop.org/show_bug.cgi?id=105760 taij...@posteo.de changed: What|Removed |Added See Also||https://bugs.freedesktop.or

[Bug 104854] smu7_populate_single_firmware_entry fails to load powerplay firmware.

https://bugs.freedesktop.org/show_bug.cgi?id=104854 taij...@posteo.de changed: What|Removed |Added See Also||https://bugs.freedesktop.or

[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #13 from Alex Deucher --- Created attachment 138450 --> https://bugs.freedesktop.org/attachment.cgi?id=138450=edit possible fix Thanks for looking into this. Good start! The attached patch should fix it.

[Bug 104063] (DC 4.15-rc2) [drm:dm_logger_write [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out!

https://bugs.freedesktop.org/show_bug.cgi?id=104063 taij...@posteo.de changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

https://bugs.freedesktop.org/show_bug.cgi?id=105218 --- Comment #3 from Matias N. Goldberg --- Hi! Thanks for starting to look into this! First: glxinfo | grep OpenGL OpenGL vendor string: X.Org OpenGL renderer string: Radeon RX 560 Series (POLARIS11 / DRM 3.19.0 /

Re: [Intel-gfx] [PATCH v3 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source

On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote: > For Geminilake and Cannonlake+ the Y-coordinate support must be > enabled in PSR2_CTL too. > > Spec: 7713 and 7720 > > Cc: Dhinakaran Pandiyan > Reviewed-by: Rodrigo Vivi

[Bug 105819] Window system hang due to GPU Fault

https://bugs.freedesktop.org/show_bug.cgi?id=105819 Bug ID: 105819 Summary: Window system hang due to GPU Fault Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [PATCH] drm/i915: Promote .format_mod_supported() to the lead role

Ville Syrjala writes: > From: Ville Syrjälä > > Up to now we've used the plane's modifier list as the primary > source of information for which modifiers are supported by a > given plane. In order to allow auxiliary metadata to be

[Bug 105725] WARNING: CPU: 0 PID: 487 at drivers/gpu/drm/amd/amdgpu/../display /dc/gpio/gpio_base.c:64 dal_gpio_open_ex+0xc/0x30 [amdgpu]

https://bugs.freedesktop.org/show_bug.cgi?id=105725 --- Comment #5 from hjpries...@gmail.com --- Created attachment 138448 --> https://bugs.freedesktop.org/attachment.cgi?id=138448=edit dmesg of drm-next-4.17-wip (date of clone 2018-03-29) -- You are receiving this mail because: You are the

[PATCH] drm/amd/display: fix spelling mistake: "Usupported" -> "Unsupported"

From: Colin Ian King Trivial fix to spelling mistake in DRM_ERROR error message text Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH v2 3/4] drm/vc4: Add color transformation matrix (CTM) support

Stefan Schake writes: > The hardware supports a CTM with S0.9 values. We therefore only allow > a value of 1.0 or fractional only and reject all others with integer > parts. This restriction is mostly inconsequential in practice since > commonly used transformation matrices

[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

https://bugs.freedesktop.org/show_bug.cgi?id=105218 --- Comment #4 from Matias N. Goldberg --- This is an example of how JSON settings look in my CMake setup: https://i.imgur.com/mj77iEz.png -- You are receiving this mail because: You are the assignee for the

[PATCH] MAINTAINERS: drm: fsl-dcu: Update to NXP email address

From: Fabio Estevam The freescale.com domain will stop working soon, so use the nxp.com domain instead. Signed-off-by: Fabio Estevam --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS

[Bug 199101] AMDGPU Fury X random screen flicker on Linux kernel 4.16rc5

https://bugzilla.kernel.org/show_bug.cgi?id=199101 Samuel Grahn (samuel.gr...@outlook.com) changed: What|Removed |Added CC|

[Bug 105725] WARNING: CPU: 0 PID: 487 at drivers/gpu/drm/amd/amdgpu/../display /dc/gpio/gpio_base.c:64 dal_gpio_open_ex+0xc/0x30 [amdgpu]

https://bugs.freedesktop.org/show_bug.cgi?id=105725 --- Comment #4 from hjpries...@gmail.com --- Harry, I have build a kernel using the: git clone -b drm-next-4.17-wip git://people.freedesktop.org/~agd5f/linux I did the clone about 2018-29-03 20:00 UTC The warnings are still there.

Re: [Intel-gfx] [PATCH v3 09/10] drm/i915/psr: Set DPCD PSR2 enable bit when needed

On Wed, Mar 28, 2018 at 03:30:45PM -0700, José Roberto de Souza wrote: > In the 2 eDP1.4a pannels tested set or not set bit have no effect > but is better set it and comply with specification. > > Signed-off-by: José Roberto de Souza > Cc: Dhinakaran Pandiyan

Re: [Intel-gfx] [PATCH v3 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source

On Fri, 2018-03-30 at 10:36 -0700, Pandiyan, Dhinakaran wrote: > > > On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote: > > For Geminilake and Cannonlake+ the Y-coordinate support must be > > enabled in PSR2_CTL too. > > > > Spec: 7713 and 7720 > > > > Cc: Dhinakaran Pandiyan

Re: [PATCH v7] drm/vc4: update cursors asynchronously through atomic

Boris Brezillon writes: > From: Gustavo Padovan > > Add support for async updates of cursors by using the new atomic > interface for that. Basically what this commit does is do what > vc4_update_plane() did but through atomic. My r-b

Re: [PATCH] drm/atomic: Add sanity checks to drm_atomic_helper_async_commit()

Boris Brezillon writes: > ->atomic_async_update() requires that drivers update the plane->state > object before returning. Make sure at least common properties have been > updated. > > Cc: Gustavo Padovan > Signed-off-by: Boris Brezillon

[Bug 105218] Regresion in 847d0a393d7f0f967f39302900d5330f32b804c8

https://bugs.freedesktop.org/show_bug.cgi?id=105218 --- Comment #6 from Timothy Arceri --- (In reply to Timothy Arceri from comment #5) > Ok built it correctly this time. > > No crash with Mesa git and LLVM 7 the sample runs fine on my RX580. Possible > there is a bug in

Re: [Intel-gfx] [PATCH v3 10/10] drm/i915/debugfs: Print sink PSR status

On Fri, 2018-03-30 at 11:28 -0700, Pandiyan, Dhinakaran wrote: > On Wed, 2018-03-28 at 15:30 -0700, José Roberto de Souza wrote: > > IGT tests could be improved with sink status, knowing for sure that > > hardware have activate or exit PSR. > > > > Cc: Dhinakaran Pandiyan

  1   2   >