[Bug 93281] Kernel modesetting causes the kernel to lock up during boot on a late 2011 MacBook Pro

https://bugzilla.kernel.org/show_bug.cgi?id=93281 --- Comment #15 from Alex Jordan --- So sorry, I don't know why I never followed up on this. If I understand correctly, I need to file a bug against GRUB, right? -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

ing this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/999b0daa/attachment.html>

[Bug 91221] UVD: GPU lockup with BARTS

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/88d0c4e3/attachment.html>

[Bug 91221] UVD: GPU lockup with BARTS

-22)! are shown. Nothing unusual in the Xorg.0.log. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/3a083ef4/attachment-0001.html>

4.2rc0 "bo don't have a message" flood.

Yeah, known issue. Mostly fixed already. Just wait for the next -rc. Regards, Christian. On 03.07.2015 18:23, Dave Jones wrote: > I was just browsing with chrome, and X locked up. > When I flipped to tty1, I saw a flood of these message.. > > kernel: [ 6800.937575] radeon :01:00.0: bo

[Bug 100871] radeon fails to initialize one DisplayPort monitor

https://bugzilla.kernel.org/show_bug.cgi?id=100871 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1

[Bug 61529] [r600g][kms][ATI RV710] r600_pcie_gart_tlb_flush+0xf5/0x110

<http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/66545145/attachment.html>

[Bug 90378] [LLVM][bisected] GPU lockups in Left 4 Dead 2

ady had a look at some of the LLVM parts in bug #88978. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/0f

[PATCH 4/4] drm/radeon: unpin cursor BOs before suspend

On 03.07.2015 17:16, Grigori Goronzy wrote: > On 2015-07-03 05:30, Michel Dänzer wrote: >> >> On resume, the cursor BO is currently pinned again by >> radeon_cursor_reset -> radeon_set_cursor. However, radeon_cursor_reset >> is also called when changing the video mode, in which case it causes the

[PATCH v2 3/5] drm/rockchip: vop: support plane scale

On Fri, Jul 3, 2015 at 6:17 PM, Mark yao wrote: >>> +static void _vop_cal_scl_fac(struct vop *vop, const struct vop_win_data >>> *win, >>> +uint32_t src_w, uint32_t src_h, uint32_t >>> dst_w, >>> +uint32_t dst_h, uint32_t pixel_format) >>>

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

tch fixes the issue? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/14daf66e/attachment.html>

[PATCH v2 5/5] drm/rockchip: default enable win2/3 area0 bit

On Fri, Jul 3, 2015 at 5:19 PM, Mark yao wrote: > On 2015年07月03日 16:02, Tomasz Figa wrote: >> >> Hi Mark, >> >> Please see my comments inline. >> >> On Fri, Jun 26, 2015 at 7:10 PM, Mark Yao wrote: >>> >>> Win2/3 support 4 area display, but now havn't found a suitable >>> way to use it,

[PATCH v2 3/5] drm/rockchip: vop: support plane scale

On 2015年07月03日 17:58, Tomasz Figa wrote: >>> >>Aren't the scl_modes for CbCr planes always the same as for Y plane? >> > >> > >> >No, such as src(1920 x 1080) -> dst(1280x800), yuv format is NV12. >> >so Y plane horizontal and vertical is scale down. >> > >> >but src_w = 1920 / 2 = 960 <

[PATCH v2 5/5] drm/rockchip: default enable win2/3 area0 bit

On 2015年07月03日 17:24, Tomasz Figa wrote: > On Fri, Jul 3, 2015 at 5:19 PM, Mark yao wrote: >> On 2015年07月03日 16:02, Tomasz Figa wrote: >>> Hi Mark, >>> >>> Please see my comments inline. >>> >>> On Fri, Jun 26, 2015 at 7:10 PM, Mark Yao >>> wrote: Win2/3 support 4 area display,

[PATCH 19/23] drm/exynos: remove extra call to exynos_dp_commit()

Hi Hyungwon, On 07/02/2015 09:39 PM, Joonyoung Shim wrote: > +Cc Hyungwon, > > On 06/24/2015 06:35 AM, Gustavo Padovan wrote: >> From: Gustavo Padovan >> >> exynos_dp_commit() was getting called twice by exynos encoder core, once >> inside the .enable() call and another time by .commit()

[PATCH v2 3/5] drm/rockchip: vop: support plane scale

On 2015年07月03日 15:46, Tomasz Figa wrote: > Hi Mark, > > Please see my comments inline. > > On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao wrote: >> Win_full support 1/8 to 8 scale down/up engine, support >> all format scale. > [snip] > >> @@ -351,6 +412,15 @@ static inline void

[PATCH v2 5/5] drm/rockchip: default enable win2/3 area0 bit

Hi Mark, Please see my comments inline. On Fri, Jun 26, 2015 at 7:10 PM, Mark Yao wrote: > Win2/3 support 4 area display, but now havn't found a suitable > way to use it, and it enable by win gate and area gate, > so default enable area0 gate, so that its behaviour just like a > win. So I

[PATCH v2 4/5] drm/rockchip: vop: switch cursor plane to window 3

On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao wrote: > Window 1 support scale and yuv format, it's waste use it for a > cursor, use window 3 is enough. > > Signed-off-by: Mark Yao > --- > Changes in v2: None > > drivers/gpu/drm/rockchip/rockchip_drm_vop.c |7 --- > 1 file changed, 4

[PATCH v2 3/5] drm/rockchip: vop: support plane scale

Hi Mark, Please see my comments inline. On Fri, Jun 26, 2015 at 7:07 PM, Mark Yao wrote: > Win_full support 1/8 to 8 scale down/up engine, support > all format scale. [snip] > @@ -351,6 +412,15 @@ static inline void vop_mask_write_relaxed(struct vop > *vop, uint32_t offset, > } > }

[PATCH] intel: wrap intel_bufmgr.h C code for C++ compilation/linking

On 01/07/15 12:37, Tapani Pälli wrote: > (We need this include in porting changes for the OpenGL ES > conformance suite.) > > Signed-off-by: Tapani Pälli > --- > intel/intel_bufmgr.h | 8 > 1 file changed, 8 insertions(+) > > diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h

[PATCH v2 5/5] drm/rockchip: default enable win2/3 area0 bit

On 2015年07月03日 16:02, Tomasz Figa wrote: > Hi Mark, > > Please see my comments inline. > > On Fri, Jun 26, 2015 at 7:10 PM, Mark Yao wrote: >> Win2/3 support 4 area display, but now havn't found a suitable >> way to use it, and it enable by win gate and area gate, >> so default enable area0

[PATCH v2 12/12] JUST FOR TEST: Add one-shot trigger to update display

Oh.. understood. Thanks. Mark On 07/03/2015 04:03 PM, Daniel Vetter wrote: > On Fri, Jul 03, 2015 at 03:57:55PM +0800, Mark Zhang wrote: >> On 07/01/2015 10:55 PM, Daniel Vetter wrote: >>> On Wed, Jul 01, 2015 at 08:43:01PM +0800, Mark Zhang wrote: On 07/01/2015 06:34 PM, Daniel Vetter

[Bug 100871] radeon fails to initialize one DisplayPort monitor

https://bugzilla.kernel.org/show_bug.cgi?id=100871 Charles R. Anderson changed: What|Removed |Added See Also||https://bugzilla.redhat.com

[Bug 100871] New: radeon fails to initialize one DisplayPort monitor

https://bugzilla.kernel.org/show_bug.cgi?id=100871 Bug ID: 100871 Summary: radeon fails to initialize one DisplayPort monitor Product: Drivers Version: 2.5 Kernel Version: v3.19-7478-g796e1c55717e Hardware: All OS: Linux

[PATCH v2 12/12] JUST FOR TEST: Add one-shot trigger to update display

On 07/01/2015 10:55 PM, Daniel Vetter wrote: > On Wed, Jul 01, 2015 at 08:43:01PM +0800, Mark Zhang wrote: >> On 07/01/2015 06:34 PM, Daniel Vetter wrote: [...] >>> >> >> Alright, this makes sense. I have no idea about qxl, what I have now is >> an ubuntu running on Tegra114. So I'm wondering what

[Bug 89228] Regression with left for dead 2

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/3883e4c5/attachment.html>

[Intel-gfx] [PATCH 04/12] drm: Add structures for querying color capabilities

On Fri, Jul 03, 2015 at 11:28:41AM +0100, Damien Lespiau wrote: > On Fri, Jul 03, 2015 at 08:41:31AM +0200, Daniel Vetter wrote: > > > Yeah. My first idea for the gamma stuff was that we'd simply have the > > > blob property for the data, and then a separate enum property which > > > decides how

[Bug 90378] [LLVM][bisected] GPU lockups in Left 4 Dead 2

es/dri-devel/attachments/20150703/71a765b4/attachment.html>

[PATCH] drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL

On Thu, Jul 2, 2015 at 9:02 PM, Michel Dänzer wrote: > From: Michel Dänzer > > This can be the case when the GPU is powered off, e.g. via vgaswitcheroo > or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin > flushes the TLB after setting rdev->gart.ptr to non-NULL. > > Fixes

4.2rc0 "bo don't have a message" flood.

On Fri, Jul 3, 2015 at 1:56 PM, Christian König wrote: > Yeah, known issue. Mostly fixed already. Just wait for the next -rc. Merged yesterday: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.2=b13e22aeba06aea2acdae657e988c93c22080858 Alex > > Regards, > Christian. > > > On

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

ail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/a073af81/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/08f2a1e4/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/3766e948/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

bed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/16ad7be3/attachment.html>

[Bug 76490] Hang during boot when DPM is on (R9 270X)

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/21113ea1/attachment-0001.html>

[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

led kernel to be used but disable the fbdev code if desired. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/9e15b2b1/attachment.sig>

[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/153188f4/attachment.html>

[PATCH v2] drm: remove redundant code form drm_ioc32.c

The compat ioctl handler ends up calling access_ok() twice: first indirectly inside compat_alloc_user_space() and then after returning from that function. This patch fixes issue. v2: there were three invalid removals of access_ok() that I've fixed. Also went through all the changes couple of

[PATCH] drm: remove redundant code form drm_ioc32.c

On 07/02/2015 11:10 AM, Jani Nikula wrote: > On Wed, 01 Jul 2015, Jarkko Sakkinen > wrote: >> The compat ioctl handler ends up calling access_ok() twice: first >> indirectly inside compat_alloc_user_space() and then after returning >> from that function. This patch fixes issue. >> >>

[PATCH] drm: remove redundant code form drm_ioc32.c

On 07/02/2015 10:32 AM, Daniel Vetter wrote: > On Wed, Jul 01, 2015 at 12:24:37PM +0300, Jarkko Sakkinen wrote: >> The compat ioctl handler ends up calling access_ok() twice: first >> indirectly inside compat_alloc_user_space() and then after returning >> from that function. This patch fixes

[Intel-gfx] [PATCH 09/12] drm/i915: Add pipe level Gamma correction for CHV/BSW

Kausal On Friday 03 July 2015 01:33 PM, Jani Nikula wrote: > On Thu, 02 Jul 2015, Damien Lespiau wrote: >> On Wed, Jul 01, 2015 at 09:18:19PM +0530, Kausal Malladi wrote: >>> From: Kausal Malladi > I didn't get the series at all, and it's not in the moderation queue > either. The same happened

[PATCH v2] drm: remove redundant code form drm_ioc32.c

On Fri, Jul 03, 2015 at 02:17:29PM +0300, Jarkko Sakkinen wrote: > The compat ioctl handler ends up calling access_ok() twice: first > indirectly inside compat_alloc_user_space() and then after returning > from that function. This patch fixes issue. > > v2: there were three invalid removals of

[PATCH v2] drm: remove redundant code form drm_ioc32.c

On Fri, Jul 03, 2015 at 02:17:29PM +0300, Jarkko Sakkinen wrote: > The compat ioctl handler ends up calling access_ok() twice: first > indirectly inside compat_alloc_user_space() and then after returning > from that function. This patch fixes issue. > > v2: there were three invalid removals of

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/cf5c8b93/attachment.html>

[PATCH] drm/tilcdc: Allocate register storage based on the actual number registers

Allocate suspend/resume register storage based on the actual number registers the driver is aware of. The static allocation for register storage had falen behind badly. Reported-by: Michael Bode Signed-off-by: Jyri Sarha --- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 20 +++-

[PATCH 4/4] drm/radeon: unpin cursor BOs before suspend

[ Dropping stable at vger.kernel.org from Cc; the patch will be picked up for stable after it lands in Linus' tree ] On 03.07.2015 08:54, Grigori Goronzy wrote: > Everything is evicted from VRAM before suspend, so we need to make > sure all BOs are unpinned and re-pinned after resume. Fixes

4.2rc0 "bo don't have a message" flood.

I was just browsing with chrome, and X locked up. When I flipped to tty1, I saw a flood of these message.. kernel: [ 6800.937575] radeon :01:00.0: bo 88080859ec00 don't has a mapping in vm 8808085c6600 kernel: [ 6800.948242] radeon :01:00.0: bo 88080859ec00 don't has a

[Intel-gfx] [PATCH 09/12] drm/i915: Add pipe level Gamma correction for CHV/BSW

On Fri, 03 Jul 2015, "Malladi, Kausal" wrote: > On Friday 03 July 2015 01:33 PM, Jani Nikula wrote: >> I didn't get the series at all, and it's not in the moderation queue >> either. The same happened to the last series from Kausal. What gives? >> >> BR, >> Jani. > Yesterday I realized what was

[patch] drm/radeon: fix underflow in r600_cp_dispatch_texture()

The "if (pass_size > buf->total)" can underflow so I have changed the type of size and pass_size to unsigned to avoid this problem. Signed-off-by: Dan Carpenter --- This code is on the way out, but whatever. I may as well send this patch since I already wrote the patch. diff --git

[PATCH 1/2] drm/radeon: Handle irqs only based on irq ring, not irq status regs.

On 03.07.2015 06:03, Mario Kleiner wrote: > Trying to resolve issues with missed vblanks and impossible > values inside delivered kms pageflip completion events showed > that radeon's irq handling sometimes doesn't handle valid irqs, > but silently skips them. This was observed for vblank

[PATCH] drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL

On 03.07.2015 03:02, Michel Dänzer wrote: > From: Michel Dänzer > > This can be the case when the GPU is powered off, e.g. via vgaswitcheroo > or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin > flushes the TLB after setting rdev->gart.ptr to non-NULL. > > Fixes panic on

[PATCH 1/4] drm/radeon: use RCU query for GEM_BUSY syscall

On 03.07.2015 01:54, Grigori Goronzy wrote: > We don't need to call the (expensive) radeon_bo_wait, checking the > fences via RCU is much faster. The reservation done by radeon_bo_wait > does not save us from any race conditions. > > Signed-off-by: Grigori Goronzy Patche #1-#3 are Reviewed-by:

[Bug 91193] [290x] Dota2 reborn ingame rendering breaks with git-af4b9c7

URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/24138744/attachment.html>

[patch] drm/radeon: fix underflow in r600_cp_dispatch_texture()

On 03.07.2015 10:54, Dan Carpenter wrote: > The "if (pass_size > buf->total)" can underflow so I have changed the > type of size and pass_size to unsigned to avoid this problem. > > Signed-off-by: Dan Carpenter Reviewed-by: Christian König > --- > This code is on the way out, but whatever. I

[Intel-gfx] [PATCH 04/12] drm: Add structures for querying color capabilities

On Fri, Jul 03, 2015 at 08:41:31AM +0200, Daniel Vetter wrote: > > Yeah. My first idea for the gamma stuff was that we'd simply have the > > blob property for the data, and then a separate enum property which > > decides how we interpret the blob contents. The default for the enum > > would be the

[GIT PULL] omapdrm fixes for 4.2

signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/36951c91/attachment.sig>

[PATCH v2 3/5] drm/rockchip: vop: support plane scale

On Fri, Jul 03, 2015 at 06:58:44PM +0900, Tomasz Figa wrote: > On Fri, Jul 3, 2015 at 6:17 PM, Mark yao wrote: > >> Aren't the scl_modes for CbCr planes always the same as for Y plane? > > > > > > No, such as src(1920 x 1080) -> dst(1280x800), yuv format is NV12. > > so Y plane horizontal and

[Intel-gfx] [PATCH 09/12] drm/i915: Add pipe level Gamma correction for CHV/BSW

On Thu, 02 Jul 2015, Damien Lespiau wrote: > On Wed, Jul 01, 2015 at 09:18:19PM +0530, Kausal Malladi wrote: >> From: Kausal Malladi I didn't get the series at all, and it's not in the moderation queue either. The same happened to the last series from Kausal. What gives? BR, Jani. >> >>

[PATCH 4/4] drm/radeon: unpin cursor BOs before suspend

On 2015-07-03 05:30, Michel Dänzer wrote: > > This could be done in the same loop as the front buffers. > Sure, I just thought it looks cleaner this way. > On resume, the cursor BO is currently pinned again by > radeon_cursor_reset -> radeon_set_cursor. However, radeon_cursor_reset > is also

[PATCH] drm/msm/dsi: Save/Restore PLL status across PHY reset

Reset DSI PHY silently changes its PLL registers to reset status, which will make cached status in clock driver invalid and result in wrong output rate of link clocks. The current restore mechanism in DSI PLL does not cover all the cases. This change is to recover PLL status after PHY reset to

[PATCH v2 12/12] JUST FOR TEST: Add one-shot trigger to update display

On Fri, Jul 03, 2015 at 03:57:55PM +0800, Mark Zhang wrote: > On 07/01/2015 10:55 PM, Daniel Vetter wrote: > > On Wed, Jul 01, 2015 at 08:43:01PM +0800, Mark Zhang wrote: > >> On 07/01/2015 06:34 PM, Daniel Vetter wrote: > [...] > >>> > >> > >> Alright, this makes sense. I have no idea about qxl,

[PATCH] drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL

From: Michel Dänzer This can be the case when the GPU is powered off, e.g. via vgaswitcheroo or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin flushes the TLB after setting rdev->gart.ptr to non-NULL. Fixes panic on powering off R7xx GPUs.

[RFC 1/6] drm: Add top level Kconfig option for DRM fbdev emulation

On Fri, Jul 3, 2015 at 8:32 AM, Thierry Reding wrote: > On Tue, Jun 30, 2015 at 11:04:45AM +0200, Daniel Vetter wrote: >> On Tue, Jun 30, 2015 at 10:31 AM, Benjamin Gaignard >> wrote: >> > I think that what have been done by Rob with module_param is also a good >> > idea: >> >

[PATCH 12/12] drm/i915: Add CSC correction for CHV/BSW

CHV/BSW supports Color Space Conversion (CSC) using a 3x3 matrix that needs to be programmed into CGM (Color Gamut Mapping) registers. This patch does the following: 1. Adds the core function to program CSC correction values for CHV/BSW platform 2. Adds CSC correction macros/defines

[PATCH 11/12] drm: Add structure for set/get a CTM color property

Color Manager framework defines a color correction property for color space transformation and Gamut mapping. This property called CTM (Color Transformation Matrix). This patch adds a new structure in DRM layer for CTM color correction. This structure will be used by all user space agents to

[PATCH 10/12] drm/i915: Add DeGamma correction for CHV/BSW

CHV/BSW supports DeGamma color correction feature, which linearizes all the non-linear color values. This will be applied before Color Transformation. This patch does the following: 1. Adds the core function to program DeGamma correction values for CHV/BSW platform 2. Adds DeGamma correction

[PATCH 09/12] drm/i915: Add pipe level Gamma correction for CHV/BSW

CHV/BSW platform supports various Gamma correction modes, which are: 1. Legacy 8-bit mode 2. 10-bit CGM (Color Gamut Mapping) mode This patch does the following: 1. Adds the core function to program Gamma correction values for CHV/BSW platform 2. Adds Gamma correction macros/defines

[PATCH 08/12] drm: Export drm_property_replace_global_blob function

drm_property_replace_global_blob() is getting used by many wrapper functions to replace an existing blob with new values. Because this function was static, modules are forced to create wrapper functions in same file. Exporting this function will remove need for such wrapper functions. This patch

[PATCH 07/12] drm: Add structures to set/get a palette color property

This patch adds new structures in DRM layer for Palette color correction. These structures will be used by user space agents to configure appropriate number of samples and Palette LUT for a platform. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi --- include/uapi/drm/drm.h | 12

[PATCH 06/12] drm/i915: Add atomic set property interface for CRTC

This patch adds atomic set property interface for Intel CRTC. This interface will be used to set color correction DRM properties. Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi --- drivers/gpu/drm/i915/intel_atomic.c | 11 +++ drivers/gpu/drm/i915/intel_display.c | 2 ++

[PATCH 05/12] drm/i915: Load color capabilities for CHV CRTC

As per Color Manager design, each driver is responsible to load its color correction and enhancement capabilities in the form of a DRM blob property, so that user space can query and read. This patch loads all CHV platform specific color capabilities for CRTC into a blob that can be accessible by

[PATCH 04/12] drm: Add structures for querying color capabilities

The DRM color management framework is targeting various hardware platforms and drivers. Different platforms can have different color correction and enhancement capabilities. A commom user space application can query these capabilities using the DRM property interface. Each driver can fill this

[PATCH 03/12] drm/i915: Attach color properties to CRTC

This patch does the following: 1. Adds new files intel_color_manager(.c/.h) 2. Attaches color properties to CRTC while initialization Signed-off-by: Shashank Sharma Signed-off-by: Kausal Malladi --- drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/intel_color_manager.c

[PATCH 02/12] drm: Create Color Management DRM properties

Color Management is an extension to Kernel display framework. It allows abstraction of hardware color correction and enhancement capabilities by virtue of DRM properties. This patch initializes color management framework by : 1. Introducing new pointers in DRM mode_config structure to carry

[PATCH 01/12] drm/i915: Atomic commit path fix for CRTC properties

From: Matt Roper The intel_atomic_check() function had some simple testing to make sure that an atomic update isn't updating more than one CRTC at a time. The logic assumed that a plane was always being updated, so it figured out the "nuclear pipe" from the first plane

[PATCH 00/12] Color Manager Implementation

NOTE: Re-sending the same series for more feedback, as we realized the mails didn't reach the dri-devel and intel-gfx lists because of some problem. This patch set adds Color Manager implementation in DRM layer. Color Manager is an extension in DRM framework to support color

[DRM] Fix a regression caused by a typo

On Fri, Jul 03, 2015 at 08:44:41AM +0200, Daniel Vetter wrote: > On Thu, Jul 02, 2015 at 02:57:19PM -0400, Shixin Zeng wrote: > > From: Shixin Zeng > > > > The length of each EDID block is EDID_LENGTH, and number of blocks is (1 > > + edid->extensions) > > > > This causes wrong EDID to be

[DRM] Fix a regression caused by a typo

On Thu, Jul 02, 2015 at 02:57:19PM -0400, Shixin Zeng wrote: > From: Shixin Zeng > > The length of each EDID block is EDID_LENGTH, and number of blocks is (1 > + edid->extensions) > > This causes wrong EDID to be passed on, and is a regression introduced > by d2ed34362a52 (drm: Introduce helper

[Intel-gfx] [PATCH 04/12] drm: Add structures for querying color capabilities

On Thu, Jul 02, 2015 at 08:04:40PM +0300, Ville Syrjälä wrote: > On Thu, Jul 02, 2015 at 05:45:32PM +0100, Damien Lespiau wrote: > > On Thu, Jul 02, 2015 at 05:20:45PM +0100, Damien Lespiau wrote: > > > On Wed, Jul 01, 2015 at 09:18:14PM +0530, Kausal Malladi wrote: > > > > From: Kausal Malladi

[DRM] Fix a regression caused by a typo

Hi, > On 2 Jul 2015, at 7:57 pm, Shixin Zeng wrote: > > From: Shixin Zeng > > The length of each EDID block is EDID_LENGTH, and number of blocks is (1 > + edid->extensions) > > This causes wrong EDID to be passed on, and is a regression introduced > by d2ed34362a52 (drm: Introduce helper for

[Intel-gfx] [PATCH] drm: reset empty state in transitional helpers

Vetter > > Reviewed-by: Daniel Stone -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/153e9861/attachment-0001.html>

[Bug 61529] [r600g][kms][ATI RV710] r600_pcie_gart_tlb_flush+0xf5/0x110

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/8d34c6b9/attachment.html>

[PATCH 2/2] drm/amdgpu: Handle irqs only based on irq ring, not irq status regs.

This is a translation of the patch ... "drm/radeon: Handle irqs only based on irq ring, not irq status regs." ... for the vblank irq handling, to fix the same problem described in that patch on the new driver. Only compile tested due to lack of suitable hw. Signed-off-by: Mario Kleiner CC:

[PATCH 1/2] drm/radeon: Handle irqs only based on irq ring, not irq status regs.

Trying to resolve issues with missed vblanks and impossible values inside delivered kms pageflip completion events showed that radeon's irq handling sometimes doesn't handle valid irqs, but silently skips them. This was observed for vblank interrupts. Although those irqs have corresponding events

[Bug 91141] Lots of *ERROR* Couldn't update BO_VA (-22) since drm/radeon: stop using addr to check for BO move

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/5b62b6a4/attachment.html>

[PATCH 4/4] drm/radeon: unpin cursor BOs before suspend

Everything is evicted from VRAM before suspend, so we need to make sure all BOs are unpinned and re-pinned after resume. Fixes broken mouse cursor after resume introduced by commit b9729b17. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100541 Cc: stable at vger.kernel.org Signed-off-by:

[PATCH 3/4] drm/radeon: default to 2048 MB GART size on SI+

Newer ASICs have more VRAM on average and allocating more GART as well can have advantages. Also see commit edcd26e8. Ideally, we should scale GART size based on actual VRAM size, but that requires significant restructuring of initialization. v2: extract small helper, apply to error paths

[PATCH 2/4] drm/radeon: fix HDP flushing

This was regressed by commit 39e7f6f8, although I don't know of any actual issues caused by it. The storage domain is read without TTM locking now, but the lock never helped to prevent any races. Cc: stable at vger.kernel.org Signed-off-by: Grigori Goronzy ---

[PATCH 1/4] drm/radeon: use RCU query for GEM_BUSY syscall

We don't need to call the (expensive) radeon_bo_wait, checking the fences via RCU is much faster. The reservation done by radeon_bo_wait does not save us from any race conditions. Signed-off-by: Grigori Goronzy --- drivers/gpu/drm/radeon/radeon_gem.c | 11 --- 1 file changed, 8

[Bug 91202] output to DVI-I is blank

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/eca9a263/attachment.html>

[Bug 91202] output to DVI-I is blank

You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/ccec68af/attachment.html>

[pull] radeon and amdgpu drm-next-4.2

On 2015-07-02 16:18, Alex Deucher wrote: > On Wed, Jul 1, 2015 at 11:08 PM, Michel Dänzer > wrote: >> On 02.07.2015 06:20, Alex Deucher wrote: >>> >>> Alex Deucher (4): >> [...] >>> Revert "drm/radeon: dont switch vt on suspend" >> >> Do we have a plan for re-enabling this? It seems to

[Bug 61529] [r600g][kms][ATI RV710] r600_pcie_gart_tlb_flush+0xf5/0x110

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/e0e625cd/attachment.html>

[Bug 91193] [290x] Dota2 reborn ingame rendering breaks with git-af4b9c7

You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/b85d5acc/attachment.html>

[Bug 91193] [290x] Dota2 reborn ingame rendering breaks with git-af4b9c7

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150703/60bf9cbc/attachment.html>

[PATCH 00/00] JUST_FOR_TEST: Sending patches to dri-devel

I suspect some problem, because when I try sending patches to dri-devel, they are neither getting delivered nor are waiting in moderation queue. Testing, based on suggestions from #dri-devel IRC chat. My apologies for spamming. -- 2.4.5