Re: [PATCH] exynos: add C++ support to exynos_drmif header

Emil Velikov wrote: > FTR, only the installed headers (~50) need the extern C guard. > None of that is not a blocker for this patch, so I've just pushed it to > master. Thanks Emil. I'll see what I can do about the other ones. - Tobias > Thanks! > Emil >

[Bug 100593] corruption in total war warhammer when using mesa 17.1 - git

https://bugs.freedesktop.org/show_bug.cgi?id=100593 --- Comment #4 from Gašper Sedej --- Hi. I also found some "shader color corruptions" on r9 270. I am using ubuntu 16.04 + kernel 4.11 + oibaf-ppa Having issues with unigine (valley/heaven), The long dark and compiz window

Re: [Intel-gfx] [PATCH 06/11] drm: create hdmi output property

/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170408-190651 reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) arch/x86/inclu

Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G

Thierry/Rob, On Tue, Feb 7, 2017 at 10:48 PM, Fabio Estevam wrote: > On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote: > >> Except I have no way of knowing whether: a) you omitted a supply >> because you don't (yet) care, b) the panel has a single supply

Re: [PATCH] exynos: add C++ support to exynos_drmif header

On 5 April 2017 at 17:23, Tobias Jakobi wrote: > Hello Eric, > > > Eric Engestrom wrote: >> On Wednesday, 2017-04-05 16:22:24 +0200, Tobias Jakobi wrote: >>> Add the usual extern "C" when compiling in C++ mode. >> >> Thanks, but why specifically this header? The

[ANNOUNCE] libdrm 2.4.79

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marek Olšák (1): configure.ac: bump version for release Samuel Pitoiset (1): amdgpu: allow to query GPU sensor related information git tag: libdrm-2.4.79 https://dri.freedesktop.org/libdrm/libdrm-2.4.79.tar.bz2 MD5:

Re: [PATCH libdrm v2 1/2] etnaviv: sync uapi header

On 7 April 2017 at 13:06, Philipp Zabel wrote: > Import the etnaviv header changes from kernel commits 9ad59fea162c > ("drm/etnaviv: submit support for in-fences") and 78ec187f64fa > ("drm/etnaviv: submit support for out-fences") for fence fd support. > > The

[Bug 92432] GPU HANG: ecode 6:0:0x00675c57, in Xorg [1341], reason: Ring hung, action: reset

https://bugs.freedesktop.org/show_bug.cgi?id=92432 Chris Wilson changed: What|Removed |Added Assignee|intel-gfx-bugs@lists.freede

Re: [PATCH libdrm v2 2/2] etnaviv: add fence fd support

On 7 April 2017 at 13:06, Philipp Zabel wrote: > Add etna_cmd_stream_flush2 with in-fence fd and out-fence fd support for > explicit fencing. > > Signed-off-by: Philipp Zabel > Reviewed-by: Eric Engestrom > Reviewed-by:

Re: [Intel-gfx] [PATCH 05/11] drm: parse ycbcr 420 deep color information

/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170408-190651 reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) arch/x86/inclu

Re: [PATCHv3 17/22] staging: android: ion: Collapse internal header files

Hi Laura, Couple of trivial nitpicks below. On 3 April 2017 at 19:57, Laura Abbott wrote: > --- a/drivers/staging/android/ion/ion.h > +++ b/drivers/staging/android/ion/ion.h > @@ -1,5 +1,5 @@ > /* > - * drivers/staging/android/ion/ion.h > + *

Re: [PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token

On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote: > Am 08.04.2017 um 18:26 schrieb Chris Wilson: > >Reserve 0 for general use a token meaning that the fence doesn't belong > >to an ordered timeline (fence context). > > NAK, we kept context allocation cheap to avoid exactly that.

Re: [PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token

Am 08.04.2017 um 18:26 schrieb Chris Wilson: Reserve 0 for general use a token meaning that the fence doesn't belong to an ordered timeline (fence context). NAK, we kept context allocation cheap to avoid exactly that. Please elaborate further why it should be necessary now. Regards,

Re: [PATCH 04/11] drm: parse ycbcr420 vcb block

Hi Shashank, On 7 April 2017 at 17:39, Shashank Sharma wrote: > + u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map; > > for (i = 0; i < len; i++) { > struct drm_display_mode *mode; > mode =

[Bug 195295] USB device insertion turns on discrete Radeon GPU

https://bugzilla.kernel.org/show_bug.cgi?id=195295 Eugene Shalygin (eugene.shaly...@gmail.com) changed: What|Removed |Added Regression|No |Yes --

[Bug 195295] New: USB device insertion turns on discrete Radeon GPU

https://bugzilla.kernel.org/show_bug.cgi?id=195295 Bug ID: 195295 Summary: USB device insertion turns on discrete Radeon GPU Product: Drivers Version: 2.5 Kernel Version: 4.10.8 Hardware: x86-64 OS: Linux

drm-tip/drm-tip boot: 112 boots: 4 failed, 107 passed with 1 offline (v4.11-rc5-1802-g102e51aa6d5b)

drm-tip/drm-tip boot: 112 boots: 4 failed, 107 passed with 1 offline (v4.11-rc5-1802-g102e51aa6d5b) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1802-g102e51aa6d5b/ Full Build Summary:

[Bug 71789] [r300g] Visuals not found in (default) depth = 24

https://bugs.freedesktop.org/show_bug.cgi?id=71789 --- Comment #37 from Marek Olšák --- You can try "git am -3 ...". If that doesn't help, then I don't know. -- You are receiving this mail because: You are the assignee for the

Re: DRM Display driver for Intel FPGA Video and Image Processing Suite

On Sat, Apr 8, 2017 at 7:41 AM, Ong, Hean Loong wrote: > Hi Daniel > > Thanks for the time and patience for reviewing my changes. I would ensure > that subsequent patches will not have the same mail problems. > > I have some question on the validation methods. Since my

[PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token

Reserve 0 for general use a token meaning that the fence doesn't belong to an ordered timeline (fence context). Signed-off-by: Chris Wilson Cc: Sumit Semwal Cc: Gustavo Padovan Cc: Joonas Lahtinen

[PATCH 3/3] drm/i915: Squash repeated awaits on the same fence

Track the latest fence waited upon on each context, and only add a new asynchronous wait if the new fence is more recent than the recorded fence for that context. This requires us to filter out unordered timelines, which are noted by DMA_FENCE_NO_CONTEXT. Signed-off-by: Chris Wilson

[PATCH 2/3] drm/i915: Mark up clflushes as belonging to an unordered timeline (NO_CONTEXT)

2 clflushes on two different objects are not ordered, and so do not belong to the same timeline (context). Either we use a unique context for each, or we reserve a special context (0 / DMA_FENCE_NO_CONTEXT) to mean unordered. Signed-off-by: Chris Wilson Cc: Sumit Semwal

Re: [PATCH v2 1/2] drm/exynos: mixer: simplify mixer_cfg_rgb_fmt()

2017-03-29 20:55 GMT+09:00 Tobias Jakobi : > Hello Daniel, > > I'm not getting any response from the Exynos DRM maintainer concerning > this patch. Since this is just a simple cleanup, and Andrzej has already > review, could you perhaps merge it through drm-misc? >

Re: [PATCH v3] drm/exynos: mixer: document YCbCr magic numbers

2017-03-29 20:56 GMT+09:00 Tobias Jakobi : > Hello Daniel, > > same question here. Patch doesn't introduce any functional changes (just > adds code documentation), so can you merge it through drm-misc? > Sorry for late. Confirmed just now. I will check it on next

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

2017-04-07 20:40 GMT+09:00 Tobias Jakobi : > Hello Inki, > > > Inki Dae wrote: >> Hello Tobias, >> >> >> 2017년 04월 07일 02:10에 Tobias Jakobi 이(가) 쓴 글: >>> Hello Inki, >>> >>> >>> Inki Dae wrote: This patch removes unnecessary descriptions on exynos_drm_crtc

Re: [PATCH 04/11] drm: parse ycbcr420 vcb block

/0day-ci/linux/commits/Shashank-Sharma/HDMI-YCBCR-output-handling-in-DRM-layer/20170408-190651 reproduce: make htmldocs All warnings (new ones prefixed by >>): WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) arch/x86/inclu

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1802-g102e51aa6d5b)

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 204 warnings (v4.11-rc5-1802-g102e51aa6d5b) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc5-1802-g102e51aa6d5b/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc5-1802-g102e51aa6d5b Git Commit:

[Bug 71789] [r300g] Visuals not found in (default) depth = 24

https://bugs.freedesktop.org/show_bug.cgi?id=71789 --- Comment #36 from richard --- wheezy only have mesa 8 available, but videoplayback would be very nice please. don't know how to change colour depth as there is no xorg.conf. thank you very much -- You are receiving

[Bug 71789] [r300g] Visuals not found in (default) depth = 24

https://bugs.freedesktop.org/show_bug.cgi?id=71789 --- Comment #35 from richard --- Hello , how can i apply this patch? I am using Powermac G5 7,3 with Radeon9650, Debian Wheezy, kernel 3.2.6 it gives dmesg | grep -E 'drm|radeon' | grep -iE 'firmware|microcode' [

Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

On 04/08/2017 12:11 PM, Hans Verkuil wrote: > Hi Tomi, > > On 05/10/2016 01:36 PM, Tomi Valkeinen wrote: >> Hi Hans, >> >> On 29/04/16 12:39, Hans Verkuil wrote: >>> From: Hans Verkuil >>> >>> As long as there is a valid physical address in the EDID and the omap >>> CEC

Re: [PATCHv3 00/22] Ion clean up in preparation in moving out of staging

On Mon, Apr 03, 2017 at 11:57:42AM -0700, Laura Abbott wrote: > Hi, > > This is v3 of the series to do some serious Ion cleanup in preparation for > moving out of staging. I didn't hear much on v2 so I'm going to assume > people are okay with the series as is. I know there were still some open >

[Bug 100618] Dead Island crash after starting a new game

https://bugs.freedesktop.org/show_bug.cgi?id=100618 at...@t-online.de changed: What|Removed |Added See Also||https://bugs.freedesktop.or

[Bug 100618] Dead Island crash after starting a new game

https://bugs.freedesktop.org/show_bug.cgi?id=100618 at...@t-online.de changed: What|Removed |Added Summary|Dead Island |Dead Island crash after

[Bug 100618] Dead Island

https://bugs.freedesktop.org/show_bug.cgi?id=100618 Bug ID: 100618 Summary: Dead Island Product: Mesa Version: 17.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal

Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid

Hi Tomi, On 05/10/2016 01:36 PM, Tomi Valkeinen wrote: > Hi Hans, > > On 29/04/16 12:39, Hans Verkuil wrote: >> From: Hans Verkuil >> >> As long as there is a valid physical address in the EDID and the omap >> CEC support is enabled, then we keep ls_oe_gpio on to ensure

[Bug 100593] corruption in total war warhammer when using mesa 17.1 - git

https://bugs.freedesktop.org/show_bug.cgi?id=100593 tarp...@gmx.de changed: What|Removed |Added Attachment #130714|0 |1 is obsolete|

Re: drm_modeset_lock oops in next

Hey, Op 07-04-17 om 17:56 schreef Tony Lindgren: > Hi, > > Looks like current next now oopses at least for omapdrm > when starting X. Reverting commit d20afeb3e2f9 ("Merge > remote-tracking branch 'drm-misc/for-linux-next'") makes > things work again. > > Any ideas what might be causing the oops