Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5723
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 282/283
Hi Dave,
Flushing out my drm-misc queue with a few oddball things all over.
Cheers, Daniel
The following changes since commit b7703726251191cd9f3ef3a80b2d9667901eec95:
drm/probe-helper: clamp unknown connector status in the poll work (2015-01-22
06:11:39 +0100)
are available in the git
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5714
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Wed, Feb 04, 2015 at 03:44:58PM +, Tvrtko Ursulin wrote:
On 02/04/2015 03:33 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 03:09:38PM +, Tvrtko Ursulin wrote:
On 02/04/2015 02:25 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 10:01:45AM +, Tvrtko Ursulin wrote:
On
On Wed, Feb 04, 2015 at 04:42:14PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Just a few basic tests to make sure fb modifiers can be used and
behave sanely when mixed with the old set_tiling API.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
On Thu, Feb 05, 2015 at 10:06:05AM +, Chris Wilson wrote:
On Thu, Feb 05, 2015 at 12:04:27PM +0200, Jani Nikula wrote:
The check for previously reserved stolen space size for FBC in
i915_gem_stolen_setup_compression() did not take the compression
threshold into account. Fix this by
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5715
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -6 282/283
On Thu, Feb 05, 2015 at 12:04:27PM +0200, Jani Nikula wrote:
The check for previously reserved stolen space size for FBC in
i915_gem_stolen_setup_compression() did not take the compression
threshold into account. Fix this by storing and comparing to
uncompressed size instead.
The bug has
We read the coherent current seqno and actual head from ring.
For hardware access we need to take runtime_pm reference, which brings in
locking. As this debugfs entry is for debugging hangcheck behaviour,
including locking problems, we need to be flexible on taking them.
Try to see if we get a
From: Hoath, Nicholas nicholas.ho...@intel.com
Move Wa4x4STCOptimizationDisable to gen9_init_workarounds
v1: rebase
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 4
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
2 files changed, 3
Move WaDisableDgMirrorFixInHalfSliceChicken5 to gen9_init_workarounds
v1: Added stepping check
v2: Removed unused register bitmap
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 8
drivers/gpu/drm/i915/intel_ringbuffer.c | 10
From: Hoath, Nicholas nicholas.ho...@intel.com
Add:
WaEnableForceRestoreInCtxtDescForVCS
v1: Add stepping check.
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git
From: Hoath, Nicholas nicholas.ho...@intel.com
Add framework for gen 9 HW WAs
v1: Changed SOC specific WA function to gen 9 common function (Req: Damien
Lespiau)
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 8
1 file changed, 8
Move WaEnableYV12BugFixInHalfSliceChicken7 to gen9_init_workarounds
v1: Add stepping check.
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 ++
2 files changed, 9 insertions(+)
diff --git
From: Hoath, Nicholas nicholas.ho...@intel.com
Add:
WaDisablePartialInstShootdown
v1: Dont add WaDisableThreadStallDopClockGating as not SKL WA. (Found by Damien
Lespiau)
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
1 file
From: Hoath, Nicholas nicholas.ho...@intel.com
Add Skylake stepping Revision IDs definitions.
v1: Use existing revision id.
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
1 file changed, 6 insertions(+)
diff --git
Implement a subset of known HardWare WorkArounds for gen 9.
v1: Make gen 9 common patchset, remove non-common w/a's, tidy up
patch names, tidy up register names (Req: Damien Lespiau).
Removed invalid WA (Found by
Arun Siluvery). Removed WaSetHdcUnitClockGatingDisableInUcgctl6
Added:
Syncing dependencies between camera and graphics
v1: Added missing register bitmap
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 4
2 files changed, 5 insertions(+)
diff --git
From: Hoath, Nicholas nicholas.ho...@intel.com
Add:
WaForceEnableNonCoherent
v1: Don't add WaHdcDisableFetchWhenMasked. Add stepping check for
WaForceEnableNonCoherent
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 11 +++
1 file
From: Hoath, Nicholas nicholas.ho...@intel.com
Add stepping check for WaDisableSDEUnitClockGating.
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
We added this WARN_ON to guard against using uninitialized
forcewake domains. But forgot blissfully that not all
gens have forcewake domains in the first place.
v2: Move WARN_ON to fw_domains_init (Chris)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88911
Tested-by: Ding Heng
On Thu, Feb 05, 2015 at 07:35:13PM +, Damien Lespiau wrote:
We don't want to end up in a state where we track that the pipe has its
primary plane enabled when primary plane registers are programmed with
values that look possible but the plane actually disabled.
Refuse to read out the fb
On Thu, Feb 05, 2015 at 06:58:06PM +, Damien Lespiau wrote:
On Thu, Feb 05, 2015 at 10:10:26AM -0800, Matt Roper wrote:
On Thu, Feb 05, 2015 at 05:22:19PM +, Damien Lespiau wrote:
Right now, we get a warning when taking over the firmware fb:
[drm:drm_atomic_plane_check] FB
On Thu, Feb 05, 2015 at 11:12:20AM -0800, Matt Roper wrote:
I think the only thing we need to close on is Ville's concern about the
plane winding up with non-NULL fb and crtc pointers even though a crazy
firmware or bootloader somehow left the plane turned off. I'm not super
familiar with the
Right now, we get a warning when taking over the firmware fb:
[drm:drm_atomic_plane_check] FB set but no CRTC
with the following backtrace:
[a010339d] drm_atomic_check_only+0x35d/0x510 [drm]
[a0103567] drm_atomic_commit+0x17/0x60 [drm]
[a00a6ccd]
On Tue, 03 Feb 2015, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Feb 03, 2015 at 03:08:17PM +, Chris Wilson wrote:
On Tue, Feb 03, 2015 at 03:48:17PM +0100, Michał Winiarski wrote:
It's possible for invalidate_range_start mmu notifier callback to race
against userptr object release. If
On 5 February 2015 at 14:41, Tvrtko Ursulin
tvrtko.ursu...@linux.intel.com wrote:
In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats. Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
On 02/05/2015 02:21 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 04:42:14PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Just a few basic tests to make sure fb modifiers can be used and
behave sanely when mixed with the old set_tiling API.
Signed-off-by:
On Thu, Feb 05, 2015 at 12:16:32PM +0200, Mika Kuoppala wrote:
We read the coherent current seqno and actual head from ring.
For hardware access we need to take runtime_pm reference, which brings in
locking. As this debugfs entry is for debugging hangcheck behaviour,
including locking
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
To be used from the new addfb2 extension.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
include/uapi/drm/i915_drm.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Start using frame buffer modifiers instead of object tiling mode
for display purposes.
To ensure compatibility with old userspace which is using set_tiling
and does not know about frame buffer modifiers, the latter are faked
internally when tile
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Instead of using driver private set tiling ioctl, use the proposed addfb2 ioctl
extension to tell the driver about display buffer special formatting.
Lightly tested only with a hacked up igt/testdisplay.
v2:
* Refactor the series to use
From: Rob Clark robdcl...@gmail.com
In DRM/KMS we are lacking a good way to deal with tiled/compressed
formats. Especially in the case of dmabuf/prime buffer sharing, where
we cannot always rely on under-the-hood flags passed to driver specific
gem-create ioctl to pass around these extra flags.
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Let the DRM core know we can handle it.
v2: Change to boolean true. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5719
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV +1 282/283
On Wed, 14 Jan 2015 11:20:55 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
diff --git a/drivers/char/agp/intel-gtt.c
b/drivers/char/agp/intel-gtt.c index 92aa43fa8d70..15685ca39193 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -225,7 +225,7 @@ static
On Thu, Feb 05, 2015 at 05:10:56PM +0530, Shobhit Kumar wrote:
As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target
device and not the source. So PCI_DEVFN(2,0) is not correct. Further the
port ID should be enough to identify devices unless they are MFD. The
SB_DevFn was
At the moment we use crtc-base.primary-fb to hold the initial
framebuffer allocation, disregarding if it's valid or not.
This lead to believe we were actually updating the fb at this point, but
it's not true and we haven't even called drm_framebuffer_init() on this
fb.
Instead, let's store the
Right now, we get a warning when taking over the firmware fb:
[drm:drm_atomic_plane_check] FB set but no CRTC
with the following backtrace:
[a010339d] drm_atomic_check_only+0x35d/0x510 [drm]
[a0103567] drm_atomic_commit+0x17/0x60 [drm]
[a00a6ccd]
update_state_fb() at the end of intel_find_plane_obj() is misleading as
it leads us to believe the update is done for all code path.
A successful call to intel_alloc_plane_obj() will return and
update_state_fb() is then only needed when we share a fb from another
CRTC. Put the update() function
On Thu, Feb 05, 2015 at 10:47:16AM +, Nick Hoath wrote:
From: Hoath, Nicholas nicholas.ho...@intel.com
Add framework for gen 9 HW WAs
v1: Changed SOC specific WA function to gen 9 common function (Req: Damien
Lespiau)
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
Reviewed-by:
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5717
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Thu, Feb 05, 2015 at 12:04:27PM +0200, Jani Nikula wrote:
The check for previously reserved stolen space size for FBC in
i915_gem_stolen_setup_compression() did not take the compression
threshold into account. Fix this by storing and comparing to
uncompressed size instead.
The bug has
Tvrtko noticed a new warning on boot:
WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47
drm_framebuffer_reference+0x6c/0x80 [drm]()
Call Trace:
[8161f10c] dump_stack+0x4f/0x7b
[81052caa] warn_slowpath_common+0xaa/0xd0
[81052d8a] warn_slowpath_null+0x1a/0x20
At least here, the following commit introduced 2 warnings when loading the
driver:
commit 706dc7b549175e47f23e913b7f1e52874a7d0f56
Author: Matt Roper matthew.d.ro...@intel.com
Date: Tue Feb 3 13:10:04 2015 -0800
drm/i915: Ensure plane-state-fb stays in sync
On Thu, Feb 05, 2015 at 06:41:48PM +0200, Mika Kuoppala wrote:
We read the coherent current seqno and actual head from ring.
For hardware access we need to take runtime_pm reference.
Get hardware specific values with runtime reference held
and print them first to emphasize hw state vs
On Thu, Feb 05, 2015 at 05:45:42PM +0200, Mika Kuoppala wrote:
We added this WARN_ON to guard against using uninitialized
forcewake domains. But forgot blissfully that not all
gens have forcewake domains in the first place.
v2: Move WARN_ON to fw_domains_init (Chris)
Bugzilla:
We read the coherent current seqno and actual head from ring.
For hardware access we need to take runtime_pm reference.
Get hardware specific values with runtime reference held
and print them first to emphasize hw state vs bookkeepping.
v2: Reorder output according to hw access (Chris)
Hi
I don't know if it is the right place... but I will explain my problem :
I am using an ATOM INTEL E3826 platform.
I have got flickering problems at bottom of my tty console, using 3.16.2
kernel.
I tried kernel 3.18 and it has not the problem. For some technical
reasons, I can not switch
On Thu, Feb 05, 2015 at 12:44:21PM +0200, Sakari Kapanen wrote:
On 02/04/2015 11:26 AM, Jani Nikula wrote:
On Mon, 02 Feb 2015, Sakari Kapanen sakari.m.kapa...@student.jyu.fi wrote:
Dear maintainers,
On an Asus Zenbook UX32VD laptop with an i5-3317U CPU and Intel HD4000
graphics, I'm
On Tue, Feb 03, 2015 at 02:16:53PM +0100, Thierry Reding wrote:
On Wed, Jan 21, 2015 at 04:48:12PM +0530, Shobhit Kumar wrote:
diff --git a/drivers/gpu/drm/i915/intel-panel-crystalcove.c
b/drivers/gpu/drm/i915/intel-panel-crystalcove.c
[...]
+#define PMIC_PANEL_EN 0x52
As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target
device and not the source. So PCI_DEVFN(2,0) is not correct. Further the
port ID should be enough to identify devices unless they are MFD. The
SB_DevFn was intended to remove ambiguity in case of these MFD devices.
For non MFD
On Thu, Feb 05, 2015 at 12:21:11PM +0200, Mika Kuoppala wrote:
We added this WARN_ON to guard against using uninitialized
forcewake domains. But forgot blissfully that not all
gens have forcewake domains in the first place.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88911
On Thu, Feb 05, 2015 at 12:16:32PM +0200, Mika Kuoppala wrote:
We read the coherent current seqno and actual head from ring.
For hardware access we need to take runtime_pm reference, which brings in
locking. As this debugfs entry is for debugging hangcheck behaviour,
including locking
LP_OUTPUT_HOLD is only in MIPI_PORT_CTRL(PORT_A) even for PORT_C in case
of dual link. In the dual link implementation, the bit is correctly set
or unset for hardcoded PORT_A, but for bit update the register base value
is read by using MIPI_PORT_CTRL(port) in a loop. The second iteration will
read
The check for previously reserved stolen space size for FBC in
i915_gem_stolen_setup_compression() did not take the compression
threshold into account. Fix this by storing and comparing to
uncompressed size instead.
The bug has been introduced in
commit 5e59f7175f96550ede91f58d267d2b551cb6fbba
On Thu, 05 Feb 2015, Stéphane ANCELOT sance...@free.fr wrote:
Hi
I don't know if it is the right place... but I will explain my problem :
I am using an ATOM INTEL E3826 platform.
I have got flickering problems at bottom of my tty console, using 3.16.2
kernel.
I tried kernel 3.18 and it
On Thu, Feb 05, 2015 at 10:47:17AM +, Nick Hoath wrote:
From: Hoath, Nicholas nicholas.ho...@intel.com
Add Skylake stepping Revision IDs definitions.
v1: Use existing revision id.
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
Namespacing is usually NAMESPACE_VALUE, so I guess
On Thu, Feb 05, 2015 at 10:47:18AM +, Nick Hoath wrote:
From: Hoath, Nicholas nicholas.ho...@intel.com
Add:
WaDisablePartialInstShootdown
Just an editor note: that's not really additional information compared
to the subject of the patch. Also subject message could be a bit more
direct
On Thu, Feb 05, 2015 at 10:47:19AM +, Nick Hoath wrote:
Move WaDisableDgMirrorFixInHalfSliceChicken5 to gen9_init_workarounds
v1: Added stepping check
v2: Removed unused register bitmap
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c
On Thu, Feb 05, 2015 at 05:55:06PM +, Damien Lespiau wrote:
+ if (INTEL_REVID(dev) == SKL_A0_REVID) {
for SKL, I read B0 only.
Well B0 only in the W/A db, but A0 and B0 in BSpec. I'd trust BSpec on
those.
--
Damien
___
Intel-gfx mailing
On Thu, Feb 05, 2015 at 05:22:19PM +, Damien Lespiau wrote:
Right now, we get a warning when taking over the firmware fb:
[drm:drm_atomic_plane_check] FB set but no CRTC
with the following backtrace:
[a010339d] drm_atomic_check_only+0x35d/0x510 [drm]
[a0103567]
On Thu, Feb 05, 2015 at 05:22:17PM +, Damien Lespiau wrote:
Tvrtko noticed a new warning on boot:
WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47
drm_framebuffer_reference+0x6c/0x80 [drm]()
Call Trace:
[8161f10c] dump_stack+0x4f/0x7b
[81052caa]
On Thu, Feb 05, 2015 at 10:10:26AM -0800, Matt Roper wrote:
On Thu, Feb 05, 2015 at 05:22:19PM +, Damien Lespiau wrote:
Right now, we get a warning when taking over the firmware fb:
[drm:drm_atomic_plane_check] FB set but no CRTC
with the following backtrace:
We added this WARN_ON to guard against using uninitialized
forcewake domains. But forgot blissfully that not all
gens have forcewake domains in the first place.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88911
Tested-by: Ding Heng hengx.d...@intel.com
Signed-off-by: Mika Kuoppala
On Thu, Feb 05, 2015 at 10:47:20AM +, Nick Hoath wrote:
Added:
Syncing dependencies between camera and graphics
v1: Added missing register bitmap
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
For the record, this W/A has no name nor documentation. So well...
Reviewed-by: Damien
On Thu, Feb 05, 2015 at 10:47:21AM +, Nick Hoath wrote:
From: Hoath, Nicholas nicholas.ho...@intel.com
Add stepping check for WaDisableSDEUnitClockGating.
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
---
On Thu, Feb 05, 2015 at 10:47:22AM +, Nick Hoath wrote:
Move WaEnableYV12BugFixInHalfSliceChicken7 to gen9_init_workarounds
v1: Add stepping check.
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
---
On Thu, Feb 05, 2015 at 10:47:23AM +, Nick Hoath wrote:
From: Hoath, Nicholas nicholas.ho...@intel.com
Move Wa4x4STCOptimizationDisable to gen9_init_workarounds
v1: rebase
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5716
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV +1 282/283
On Thu, Feb 05, 2015 at 10:47:24AM +, Nick Hoath wrote:
From: Hoath, Nicholas nicholas.ho...@intel.com
Add:
WaForceEnableNonCoherent
v1: Don't add WaHdcDisableFetchWhenMasked. Add stepping check for
WaForceEnableNonCoherent
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
On Thu, Feb 05, 2015 at 10:47:25AM +, Nick Hoath wrote:
From: Hoath, Nicholas nicholas.ho...@intel.com
Add:
WaEnableForceRestoreInCtxtDescForVCS
v1: Add stepping check.
Signed-off-by: Nick Hoath nicholas.ho...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 15 ---
On Thu, Feb 05, 2015 at 10:10:26AM -0800, Matt Roper wrote:
On Thu, Feb 05, 2015 at 05:22:19PM +, Damien Lespiau wrote:
Right now, we get a warning when taking over the firmware fb:
[drm:drm_atomic_plane_check] FB set but no CRTC
with the following backtrace:
Tvrtko noticed a new warning on boot:
WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47
drm_framebuffer_reference+0x6c/0x80 [drm]()
Call Trace:
[8161f10c] dump_stack+0x4f/0x7b
[81052caa] warn_slowpath_common+0xaa/0xd0
[81052d8a] warn_slowpath_null+0x1a/0x20
We don't want to end up in a state where we track that the pipe has its
primary plane enabled when primary plane registers are programmed with
values that look possible but the plane actually disabled.
Refuse to read out the fb state when the primary plane isn't enabled.
Suggested-by: Ville
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5718
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -8 282/283
76 matches
Mail list logo
