Re: [PATCH 14/19] drm/tegra: Remove tegra_debugfs_cleanup()

On Thu, Jan 26, 2017 at 11:56:16PM +0100, Noralf Trønnes wrote: > drm_debugfs_cleanup() now removes all minor->debugfs_list entries > automatically, so the drm_driver.debugfs_cleanup callback is not > needed. > > Cc: thierry.red...@gmail.com > Signed-off-by: Noralf Trønnes

Re: [PATCH 09/19] drm/msm: Remove drm_debugfs_remove_files() calls

On Thu, Jan 26, 2017 at 11:56:11PM +0100, Noralf Trønnes wrote: > drm_debugfs_cleanup() now removes all minor->debugfs_list entries > automatically, so it's not necessary to call > drm_debugfs_remove_files(). Additionally it uses > debugfs_remove_recursive() to clean up the debugfs files, so no

Re: [PATCH 00/19] drm: debugfs: Remove all files automatically on cleanup

On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote: > This patchset removes the need for drivers to clean up their debugfs > files on exit. It is done automatically in drm_debugfs_cleanup(). > This funtion is also called should the driver error out in it's > drm_driver.debugfs_init

Re: [PATCH libdrm] tests/util: Add support for meson module

On Thu, Jan 26, 2017 at 04:14:56PM +, Emil Velikov wrote: > On 26 January 2017 at 15:49, Thierry Reding wrote: > > On Fri, Jan 20, 2017 at 06:28:39PM +, Emil Velikov wrote: > >> On 20 January 2017 at 16:17, Thierry Reding wrote: > >> > On Fri, Jan

[Bug 193341] New: AMDGPU: kernel NULL pointer dereferenced with hybrid graphics

https://bugzilla.kernel.org/show_bug.cgi?id=193341 Bug ID: 193341 Summary: AMDGPU: kernel NULL pointer dereferenced with hybrid graphics Product: Drivers Version: 2.5 Kernel Version: 4.9.6 Hardware: x86-64

Re: [PATCH 1/4] drm: qxl: Drop misleading comment

On Thu, Jan 26, 2017 at 11:05:45PM -0200, Gabriel Krisman Bertazi wrote: > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 > output"). qxl_num_crtc defaults to 4 and is configurable as a module > parameter. > > Signed-off-by: Gabriel Krisman Bertazi

Re: [PATCH 1/4] drm: qxl: Drop misleading comment

On Thu, Jan 26, 2017 at 11:05:45PM -0200, Gabriel Krisman Bertazi wrote: > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 > output"). qxl_num_crtc defaults to 4 and is configurable as a module > parameter. > > Signed-off-by: Gabriel Krisman Bertazi

Re: [PATCH] drm/fourcc: add vivante tiled layout format modifiers

On Thu, Jan 26, 2017 at 07:29:13PM +0100, Wladimir J. van der Laan wrote: > > Reviewed-By: Wladimir J. van der Laan > > I do wonder whether we'll need the split formats in practice - > e.g. the GC3000 on the i.MX6qp, for which I suppose this is being done because > of tiled

Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable

On Fri, Jan 27, 2017 at 07:23:58AM +0100, Thomas Hellstrom wrote: > On 01/27/2017 03:29 AM, Michel Dänzer wrote: > > On 26/01/17 09:46 AM, Sinclair Yeh wrote: > >> On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote: > >>> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom: > On

[PATCH libdrm] tests: Use -pthread in CFLAGS instead of -lpthread

-lpthread is not always a valid flag to pull pthread support, especially on Android it will fail to link due to a missing libpthread.so. The more generic way to build-in pthread support is to use the -pthread CFLAG, so let's use it instead. Signed-off-by: Tomasz Figa ---

Re: RFC: drm-misc for small drivers?

On Thu, Jan 26, 2017 at 9:48 PM, Liviu Dudau wrote: >> I'm not certain number of people is a good metric, TBH. There are cases >> where a lot of people are working on a driver, but the patches are not being >> merged to the maintainer tree. In these cases, it makes sense to

Re: RFC: drm-misc for small drivers?

On Thu, Jan 26, 2017 at 8:48 PM, Eric Anholt wrote: >> - Should we require review or at least acks for patches committed by >> the author? We have a bunch of drivers with effectively just 1 person >> working on it, where getting real review is hard. But otoh a few of >> those

Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable

On 01/27/2017 03:29 AM, Michel Dänzer wrote: > On 26/01/17 09:46 AM, Sinclair Yeh wrote: >> On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote: >>> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom: On 01/25/2017 09:21 AM, Michel Dänzer wrote: > From: Michel Dänzer

Re: RFC: drm-misc for small drivers?

On Thu, Jan 26, 2017 at 8:11 PM, Sean Paul wrote: > On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote: >> - Should it be an entire separate tree for soc drivers? Problem here >> is that we lack a volunteer group (and imo it really should be a group >> to avoid

Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable

On 26/01/17 09:46 AM, Sinclair Yeh wrote: > On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote: >> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom: >>> On 01/25/2017 09:21 AM, Michel Dänzer wrote: From: Michel Dänzer The current caching state

[git pull] drm fixes for 4.10-rc6

Hi Linus, This is the main request for rc6, since really the one earlier was the rc5 one :-) The main thing are the nouveau specific race fixes for the connector locking bug we fixed in -next and reverted here as it has quite large prereqs. These two fixes should solve the problem at that level

Re: [PATCH] drm/prime: Clarify DMA-BUF/GEM Object lifetime

Thank you for comments, I will update the patch and send v1. On 01/26/2017 12:36 PM, Daniel Vetter wrote: On Thu, Jan 26, 2017 at 09:22:46AM +0200, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko From the description of the "DMA-BUF/GEM Object

[PATCH] drm: Fix the .fault functions

Commit 25d3db7600b87a4 ("mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite to take only vmf") causes the following build failure with arm allmodconfig: drivers/gpu/drm/armada/armada_gem.c:38:11: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]

Re: [PATCH] drm: Don't race connector registration

On 01/25/2017 07:38 AM, Daniel Vetter wrote: > On Wed, Jan 25, 2017 at 07:20:45AM -0800, Dave Hansen wrote: >> On 01/24/2017 10:21 PM, Daniel Vetter wrote: >>> Hi Dave, >>> >>> Still waiting for your testing results on this one here ... >> >> It's definitely stable with that patch applied. No

Re: [PATCH] fixup! mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite to take only vmf

Hi, On Wed, Jan 25, 2017 at 11:35:05PM +0100, Arnd Bergmann wrote: > I ran into a couple of build problems on ARM, these are the changes that > should be folded into the original patch that changed all the ->fault() > prototypes > > Fixes: mmtom ("mm, fs: reduce fault, page_mkwrite, and

[PATCH] drm/prime: Clarify DMA-BUF/GEM Object lifetime

From: Oleksandr Andrushchenko From the description of the "DMA-BUF/GEM Object references and lifetime overview" it is not clear when exactly dma_buf gets destroyed and memory freed: only driver .release function mentioned which makes confusion on the real

Re: [PATCH] drm/prime: Clarify DMA-BUF/GEM Object lifetime

On 01/26/2017 12:45 PM, Chris Wilson wrote: On Thu, Jan 26, 2017 at 11:36:05AM +0100, Daniel Vetter wrote: On Thu, Jan 26, 2017 at 09:22:46AM +0200, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko From the description of the "DMA-BUF/GEM

[PATCH] drm/i915: fix use-after-free in page_flip_completed()

page_flip_completed() dereferences 'work' variable after executing queue_work(). This is not safe as the 'work' item might be already freed by queued work: BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr 8803dc010f90 Call Trace:

Re: [PATCH] drm: Fix the .fault functions

On 01/26/2017 06:36 AM, Fabio Estevam wrote: > Commit 25d3db7600b87a4 ("mm, fs: reduce fault, page_mkwrite, and > pfn_mkwrite to take only vmf") causes the following build failure with > arm allmodconfig: > > drivers/gpu/drm/armada/armada_gem.c:38:11: error: initialization from > incompatible

Re: [PATCH 2/4] drm: qxl: Drop duplicated device pointer attribute

On 27 January 2017 at 01:23, Emil Velikov wrote: > On 27 January 2017 at 01:05, Gabriel Krisman Bertazi > wrote: >> qxl_device duplicates a pointer to struct device, which is not needed >> since we already have it in the drm_device structure.

Re: [PATCH 2/4] drm: qxl: Drop duplicated device pointer attribute

On 27 January 2017 at 01:05, Gabriel Krisman Bertazi wrote: > qxl_device duplicates a pointer to struct device, which is not needed > since we already have it in the drm_device structure. Clean it up. > > Signed-off-by: Gabriel Krisman Bertazi >

[PATCH 1/4] drm: qxl: Drop misleading comment

No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1 output"). qxl_num_crtc defaults to 4 and is configurable as a module parameter. Signed-off-by: Gabriel Krisman Bertazi --- drivers/gpu/drm/qxl/qxl_fb.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 3/4] drm: qxl: Drop duplicated pci_device pointer attribute

qxl_device duplicates the pointer to struct pci_dev, which is not needed since we already have it in the drm_device structure. Clean it up. Signed-off-by: Gabriel Krisman Bertazi --- drivers/gpu/drm/qxl/qxl_drv.h | 1 - drivers/gpu/drm/qxl/qxl_ioctl.c | 2 +-

[PATCH 4/4] drm: qxl: Embed drm_device into driver structure

This is the recommended way to create the drm_device structure, according to DRM documentation. Signed-off-by: Gabriel Krisman Bertazi --- drivers/gpu/drm/qxl/qxl_debugfs.c | 6 +++--- drivers/gpu/drm/qxl/qxl_display.c | 32

[PATCH 2/4] drm: qxl: Drop duplicated device pointer attribute

qxl_device duplicates a pointer to struct device, which is not needed since we already have it in the drm_device structure. Clean it up. Signed-off-by: Gabriel Krisman Bertazi --- drivers/gpu/drm/qxl/qxl_drv.h| 1 - drivers/gpu/drm/qxl/qxl_kms.c| 1 -

[PATCH 1/3] [v3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

Originally based off of a patch by Kristian. This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information about the modifiers that will work with each format. It's modified from Kristian's patch in that the modifiers and formats are setup by the driver, and then a callback is used to

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 --- Comment #1 from darkbasic --- It would be easier to track the few apps which work, unfortunately :( -- You are receiving this mail because: You are the assignee for the

[PATCH 12/19] drm/radeon: Remove drm_debugfs_remove_files() call

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so it's not necessary to call drm_debugfs_remove_files(). Cc: alexander.deuc...@amd.com Cc: christian.koe...@amd.com Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/radeon/radeon_device.c | 16

[PATCH 11/19] drm/omap: Remove omap_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: tomi.valkei...@ti.com Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/omapdrm/omap_debugfs.c | 9 -

[PATCH 14/19] drm/tegra: Remove tegra_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: thierry.red...@gmail.com Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/tegra/drm.c | 7 --- 1 file changed, 7 deletions(-)

[PATCH 15/19] drm/tilcdc: Remove tilcdc_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Also remove the unused tilcdc_module_ops.debugfs_cleanup() callback. drm_debugfs_cleanup() removes all debugfs files using debugfs_remove_recursive(), so there

[PATCH 13/19] drm/sti: Remove drm_debugfs_remove_files() calls

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so it's not necessary to call drm_debugfs_remove_files(). Additionally it uses debugfs_remove_recursive() to clean up the debugfs files, so no need for adding fake drm_info_node entries. Cc:

[PATCH 16/19] drm/vc4: Remove vc4_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: e...@anholt.net Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/vc4/vc4_debugfs.c | 6 -- drivers/gpu/drm/vc4/vc4_drv.c |

[PATCH 18/19] drm/qxl: Remove qxl_debugfs_takedown()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: airl...@linux.ie Cc: kra...@redhat.com Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/qxl/qxl_debugfs.c | 9 -

[PATCH 19/19] drm/i915: Remove i915_debugfs_unregister()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so no need to do this explicitly. Additionally it uses debugfs_remove_recursive() to clean up the debugfs files, so no need for adding fake drm_info_node entries. Cc: daniel.vet...@intel.com Cc:

[PATCH 10/19] drm/nouveau: Remove nouveau_drm_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Additionally it uses debugfs_remove_recursive() to clean up the debugfs files, so no need for adding fake drm_info_node entries. Cc: bske...@redhat.com

[PATCH 17/19] drm/virtio: Remove virtio_gpu_debugfs_takedown()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: airl...@linux.ie Cc: kra...@redhat.com Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/virtio/virtgpu_debugfs.c | 8

[PATCH 00/19] drm: debugfs: Remove all files automatically on cleanup

This patchset removes the need for drivers to clean up their debugfs files on exit. It is done automatically in drm_debugfs_cleanup(). This funtion is also called should the driver error out in it's drm_driver.debugfs_init callback. Two drivers still use drm_debugfs_remove_files(): - tegra in

[PATCH 04/19] drm/amd/amdgpu: Remove drm_debugfs_remove_files() call

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so no need to call drm_debugfs_remove_files(). Also remove empty drm_driver.debugfs_cleanup callback. Cc: alexander.deuc...@amd.com Cc: christian.koe...@amd.com Signed-off-by: Noralf Trønnes ---

[PATCH 03/19] drm/atomic: Remove drm_atomic_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so no need to call drm_debugfs_remove_files(). Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_atomic.c| 7 --- drivers/gpu/drm/drm_crtc_internal.h | 1 -

[PATCH 06/19] drm/etnaviv: allow build with COMPILE_TEST

Make it possible to compile test the driver on other platforms. Cc: l.st...@pengutronix.de Cc: linux+etna...@armlinux.org.uk Cc: christian.gmei...@gmail.com Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/etnaviv/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 07/19] drm/etnaviv: Remove etnaviv_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: l.st...@pengutronix.de Cc: linux+etna...@armlinux.org.uk Cc: christian.gmei...@gmail.com Signed-off-by: Noralf Trønnes ---

[PATCH 08/19] drm/hdlcd: Remove hdlcd_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so the drm_driver.debugfs_cleanup callback is not needed. Cc: liviu.du...@arm.com Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/arm/hdlcd_drv.c | 7 --- 1 file changed, 7 deletions(-)

[PATCH 01/19] drm: debugfs: Remove all files automatically on cleanup

Instead of having the drivers call drm_debugfs_remove_files() in their drm_driver->debugfs_cleanup hook, do it automatically by traversing minor->debugfs_list. Also use debugfs_remove_recursive() so drivers who add their own debugfs files don't have to keep track of them for removal.

[PATCH 05/19] drm/armada: Remove armada_drm_debugfs_cleanup()

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so no need to do this explicitly. Additionally it uses debugfs_remove_recursive() to clean up the debugfs files, so no need for adding fake drm_info_node entries. And finally there's no need to clean up on error,

[PATCH 09/19] drm/msm: Remove drm_debugfs_remove_files() calls

drm_debugfs_cleanup() now removes all minor->debugfs_list entries automatically, so it's not necessary to call drm_debugfs_remove_files(). Additionally it uses debugfs_remove_recursive() to clean up the debugfs files, so no need to do that. Cc: robdcl...@gmail.com Signed-off-by: Noralf Trønnes

[PATCH 02/19] drm: drm_minor_register(): Clean up debugfs on failure

Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to cover for failure in the drm_driver.debugfs_init callback. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c

Re: [RFC] drm/msm/adreno: clean up gpu bindings

On Thu, Jan 26, 2017 at 4:09 PM, Rob Herring wrote: > On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark wrote: >> On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring wrote: >>> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote:

Re: [RFC] drm/msm/adreno: clean up gpu bindings

On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark wrote: > On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring wrote: >> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote: >>> So, cleaning up the GPU bindings is something that has been on my TODO >>>

Re: RFC: drm-misc for small drivers?

On Thu, Jan 26, 2017 at 02:12:16PM -0500, Sean Paul wrote: > On Thu, Jan 26, 2017 at 05:42:12PM +, Liviu Dudau wrote: > > On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote: > > > Hi all, > > > > Hi Daniel, > > > > > > > > We've discussed this a bit at LCA (with Dave and Eric),

Re: RFC: drm-misc for small drivers?

On Thu, Jan 26, 2017 at 08:57:25PM +0100, Daniel Vetter wrote: > Hi Liviu > > On Thu, Jan 26, 2017 at 05:42:12PM +, Liviu Dudau wrote: > > On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote: > > > We've discussed this a bit at LCA (with Dave and Eric), and it's > > > probably best

[Bug 99555] LIBGL_ALWAYS_INDIRECT=1 causes all opengl programms to crash on second frame

https://bugs.freedesktop.org/show_bug.cgi?id=99555 Bug ID: 99555 Summary: LIBGL_ALWAYS_INDIRECT=1 causes all opengl programms to crash on second frame Product: Mesa Version: git Hardware: x86-64 (AMD64) OS:

Re: RFC: drm-misc for small drivers?

Hi Liviu On Thu, Jan 26, 2017 at 05:42:12PM +, Liviu Dudau wrote: > On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote: > > We've discussed this a bit at LCA (with Dave and Eric), and it's > > probably best if I just summarize all the questions and opens and > > throw them out

Re: [RFC] drm/msm/adreno: clean up gpu bindings

On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring wrote: > On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote: >> So, cleaning up the GPU bindings is something that has been on my TODO >> list for a while, but always $bigger_fires. Existing bindings are a bit >>

Re: RFC: drm-misc for small drivers?

Daniel Vetter writes: > Hi all, > > We've discussed this a bit at LCA (with Dave and Eric), and it's > probably best if I just summarize all the questions and opens and > throw them out here for discussions: > > - When's a driver small enough for a shared tree, and when

[Bug 77907] OpenCL test 'Arithm/Absdiff.Mat/20' from OpenCV hangs HD5470M

https://bugs.freedesktop.org/show_bug.cgi?id=77907 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced

[Bug 99552] Make Advanced Simulation Library (ASL) OpenCL GPU support work on Clover and RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=99552 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced

[Bug 74973] [radeonsi] Gimp OpenCL does not work

https://bugs.freedesktop.org/show_bug.cgi?id=74973 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced

[Bug 74974] [radeonsi] x264 OpenCL does not work

https://bugs.freedesktop.org/show_bug.cgi?id=74974 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced

[Bug 99488] [r600g]OpenCL driver causes process to hang in ImageMagick's Gaussian Blur kernel

https://bugs.freedesktop.org/show_bug.cgi?id=99488 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced

[Bug 64201] bfgminer OpenCL usage result segmentation fault on r600g with HD6850

https://bugs.freedesktop.org/show_bug.cgi?id=64201 Vedran Miletić changed: What|Removed |Added Blocks||99553 Referenced

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Vedran Miletić changed: What|Removed |Added Depends on||97250, 99552,

[Bug 64201] bfgminer OpenCL usage result segmentation fault on r600g with HD6850

https://bugs.freedesktop.org/show_bug.cgi?id=64201 Vedran Miletić changed: What|Removed |Added Summary|OpenCL usage result |bfgminer OpenCL

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug ID: 99553 Summary: Tracker bug for runnning OpenCL applications on Clover Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity:

[Bug 99552] Make Advanced Simulation Library (ASL) OpenCL GPU support work on Clover and RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=99552 Bug ID: 99552 Summary: Make Advanced Simulation Library (ASL) OpenCL GPU support work on Clover and RadeonSI Product: Mesa Version: git Hardware: All OS:

Re: [PATCH] drm: Silence the compiler for drm_mode_get_hv_timings()

On Thu, Jan 26, 2017 at 04:54:37PM +0100, Daniel Vetter wrote: > On Thu, Jan 26, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote: > > On Thu, Jan 26, 2017 at 11:44:09AM +, Chris Wilson wrote: > > > Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler > > > has been able to get

Re: [RFC] drm/msm/adreno: clean up gpu bindings

On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote: > So, cleaning up the GPU bindings is something that has been on my TODO > list for a while, but always $bigger_fires. Existing bindings are a bit > ugly, but served a purpose when too many of the other drivers the GPU >

Re: RFC: drm-misc for small drivers?

On Thu, Jan 26, 2017 at 05:42:12PM +, Liviu Dudau wrote: > On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote: > > Hi all, > > Hi Daniel, > > > > > We've discussed this a bit at LCA (with Dave and Eric), and it's > > probably best if I just summarize all the questions and opens

Re: RFC: drm-misc for small drivers?

On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote: > Hi all, > > We've discussed this a bit at LCA (with Dave and Eric), and it's > probably best if I just summarize all the questions and opens and > throw them out here for discussions: > > - When's a driver small enough for a shared

Re: [PATCH 0/5] drm/edid: Improve RGB limited range handling a bit

On Wed, Jan 11, 2017 at 02:57:20PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > While reading the HDMI 2.0 spec I noticed some new things related to > the RGB quantization range stuff, and after cross checking with > CEA-861-F I spotted a

Re: [PATCH 4/4] drm: Resurrect atomic rmfb code, v2

On Thu, Jan 26, 2017 at 10:55:51AM +0100, Maarten Lankhorst wrote: > Op 25-01-17 om 19:05 schreef Sinclair Yeh: > > On Wed, Jan 25, 2017 at 09:36:36AM +0100, Maarten Lankhorst wrote: > >> Op 25-01-17 om 09:09 schreef Thomas Hellstrom: > >>> On 01/25/2017 05:54 AM, Daniel Vetter wrote: > On

Re: [PATCH v2 5/5] drm: zte: add tvenc driver support

On Thu, Jan 26, 2017 at 11:20:53PM +0800, Shawn Guo wrote: > From: Shawn Guo > > It adds the TV Encoder driver to support video output in PAL and NTSC > format. The driver uses syscon/regmap interface to configure register > bit sitting in SYSCTRL module for DAC power

Re: [PATCH v2 1/5] drm: zte: add interlace mode support

On Thu, Jan 26, 2017 at 11:20:49PM +0800, Shawn Guo wrote: > From: Shawn Guo > > It adds interlace mode support in VOU TIMING_CTRL and channel control > block, so that VOU driver gets ready to support output device in > interlace mode like TV Encoder. > Reviewed-by: Sean

Re: [PATCH 2/3] drm/i915: Wait for pending modesets to complete before trying link training

On Mon, Jan 09, 2017 at 06:06:57PM +0100, Maarten Lankhorst wrote: > We're protected by the connection_mutex lock against blocking modesets, > but nonblocking modesets are performed without any locking. This is > causing WARN in drm_wait_for_vblank and in general it's better to wait > before

Re: [PATCH] drm/fourcc: add vivante tiled layout format modifiers

Reviewed-By: Wladimir J. van der Laan I do wonder whether we'll need the split formats in practice - e.g. the GC3000 on the i.MX6qp, for which I suppose this is being done because of tiled buffers support in the PRE, has the "single buffer" feature which allows rendering to a

Re: [Intel-gfx] [PATCH 1/3] drm/atomic: move waiting for hw_done to a helper

On Mon, Jan 09, 2017 at 06:06:56PM +0100, Maarten Lankhorst wrote: > This will allow i915 to perform a wait on pending modeset using the > same code. I don't like commit messages that refer to the subject like this. I can't even see the subject when I'm replying so I have approximately zero idea

Re: [PATCH libdrm 5/5] android: silence ~550 warnings

On Sun, Jan 22, 2017 at 12:34 PM, Emil Velikov wrote: > Analogous to the autoconf build add the following to the build > >-Wno-unused-parameter >-Wno-missing-field-initializers > > Cc: Chih-Wei Huang > Cc: Rob Herring >

Re: RFC: drm-misc for small drivers?

On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote: > Hi all, Hi Daniel, > > We've discussed this a bit at LCA (with Dave and Eric), and it's > probably best if I just summarize all the questions and opens and > throw them out here for discussions: > > - When's a driver small enough

Re: [PATCH] drm/fourcc: add vivante tiled layout format modifiers

On Thu, Jan 26, 2017 at 04:32:17PM +0100, Philipp Zabel wrote: > Vivante GC hardware uses simple 4x4 tiled and nested 64x64 supertiled > formats as well as so-called split-tiled variants for dual-pipe > hardware, where even and odd tiles start at different base addresses. > > Signed-off-by:

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote: > Despite all the careful planing of the kernel, a link may become > insufficient to handle the currently-set mode. At this point, the > kernel should mark this particular configuration as being broken > and potentially prune the mode

Re: [PATCH v2] drm: Clean up the 1366x768 fixup codes

On Thu, Jan 26, 2017 at 04:48:45PM +0200, Ville Syrjälä wrote: > On Mon, Jan 23, 2017 at 09:23:52AM +0100, Daniel Vetter wrote: > > On Fri, Jan 20, 2017 at 09:46:17PM +0200, Ville Syrjälä wrote: > > > On Tue, Jan 17, 2017 at 05:43:29PM +0100, Takashi Iwai wrote: > > > > This is just a cleanup, no

RFC: drm-misc for small drivers?

Hi all, We've discussed this a bit at LCA (with Dave and Eric), and it's probably best if I just summarize all the questions and opens and throw them out here for discussions: - When's a driver small enough for a shared tree, and when is a separate tree a good idea? i915 and amdgpu are

Re: [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.

On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > When writing some testcases for nonblocking modesets. I found out that the > infinite wait on the old fb was causing issues. > > A nonblocking modeset with a hang on the old fb, followed by a blocking > update was enough to

Re: [PATCH] drm: Fix the .fault functions

Am Donnerstag, den 26.01.2017, 09:29 -0700 schrieb Dave Jiang: > > On 01/26/2017 06:36 AM, Fabio Estevam wrote: > > Commit 25d3db7600b87a4 ("mm, fs: reduce fault, page_mkwrite, and > > pfn_mkwrite to take only vmf") causes the following build failure with > > arm allmodconfig: > > > >

Re: [PATCH libdrm] tests/util: Add support for meson module

On 26 January 2017 at 15:49, Thierry Reding wrote: > On Fri, Jan 20, 2017 at 06:28:39PM +, Emil Velikov wrote: >> On 20 January 2017 at 16:17, Thierry Reding wrote: >> > On Fri, Jan 20, 2017 at 02:13:00PM +, Emil Velikov wrote: >> >> On 19 January

Re: 4.10-rc5+ WARNING: CPU: 3 PID: 1 at ./include/drm/drm_crtc.h:857 drm_kms_helper_poll_enable.part.4+0xa8/0xc0

On Thu, Jan 26, 2017 at 05:26:00PM +0200, Jani Nikula wrote: > IIUC the alt fix should be for nouveau, and just the revert should be > enough for i915. I see. /me goes and reverts 3846fd9b86001bea171943cc3bb9222cb6da6b42, builds, boots... Yap, looks good, thanks. :-) -- Regards/Gruss,

[PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.

When writing some testcases for nonblocking modesets. I found out that the infinite wait on the old fb was causing issues. A nonblocking modeset with a hang on the old fb, followed by a blocking update was enough to trigger it. For old platforms patch 2 is needed else

[PATCH 3/3] drm/i915: Skip modeset locking when atomic pageflips are used.

With the atomic helper for pageflips there are no CS flips when that require resetting, so on most platforms we can completely skip the locking. Because we may end up reverting the page_flip patch add an explicit function pointer check so that if someone reverts the page flip patch there will not

[PATCH 1/3] drm/atomic: Bump timeout for waiting for hw_done to 90s in swap_state

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index b535f782b2c0..34338678db26

[PATCH 2/3] drm/i915: Set a timeout when waiting for fence on the old fb

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 7c19b3c7a4ee..35d25e58a37e 100644

Re: [PATCH] drm: Silence the compiler for drm_mode_get_hv_timings()

On Thu, Jan 26, 2017 at 02:46:55PM +0200, Ville Syrjälä wrote: > On Thu, Jan 26, 2017 at 11:44:09AM +, Chris Wilson wrote: > > Since moving drm_crtc_get_hv_timings() into drm_modes.c, the compiler > > has been able to get smarter and spots that drm_mode_copy() is trying to > > preserve garbage

Re: [PATCH libdrm] tests/util: Add support for meson module

On Fri, Jan 20, 2017 at 06:28:39PM +, Emil Velikov wrote: > On 20 January 2017 at 16:17, Thierry Reding wrote: > > On Fri, Jan 20, 2017 at 02:13:00PM +, Emil Velikov wrote: > >> On 19 January 2017 at 09:19, Thierry Reding wrote: > >> > On Wed, Jan

[GIT PULL] arm/mali-dp fixes for v4.11

Hi Dave, Hope I'm not too late before the cutoff for the v4.11 with these patches. Mostly an asorted set of fixes that we have discovered while playing with the code and preparing for the next set of features. Best regards, Liviu The following changes since commit

[PATCH] drm/fourcc: add vivante tiled layout format modifiers

Vivante GC hardware uses simple 4x4 tiled and nested 64x64 supertiled formats as well as so-called split-tiled variants for dual-pipe hardware, where even and odd tiles start at different base addresses. Signed-off-by: Philipp Zabel --- include/uapi/drm/drm_fourcc.h | 41

[PATCH 1/2] drm: mali-dp: Add plane offset to the plane's physical start address register

Add the fb->offset[] value to the plane's physical start address registe. Without that, packed formats are rendered incorrectly. Signed-off-by: Liviu Dudau --- drivers/gpu/drm/arm/malidp_planes.c | 1 + 1 file changed, 1 insertion(+) diff --git

  1   2   >