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 rep
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
On Wed, 14 Jan 2015 11:20:55 +
Chris Wilson 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 int i810_insert_dcache
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 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
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
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 Syrjä
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:
[] drm_atomic_check_only+0x35d/0x510 [drm]
[] drm_atomic_commit+0x17/0x60 [drm]
[] drm_atomic_helper_plane_set_property+0x8d/0xd0
[drm_kms_helper]
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
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_
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:
[] dump_stack+0x4f/0x7b
[] warn_slowpath_common+0xaa/0xd0
[] warn_slowpath_null+0x1a/0x20
[] drm_framebuffer_reference+0x6c/0x80 [drm]
[]
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:
> >
> >
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:
> [] dump_stack+0x4f/0x7b
> [] warn_slowpath_common+0xaa/0xd0
> []
On Thu, Feb 05, 2015 at 10:47:25AM +, Nick Hoath wrote:
> From: "Hoath, Nicholas"
>
> Add:
> WaEnableForceRestoreInCtxtDescForVCS
>
> v1: Add stepping check.
>
> Signed-off-by: Nick Hoath
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 15 ---
> 1 file changed, 12 insertions(+), 3
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:
>
> [] drm_atomic_check_only+0x35d/0x510 [drm]
> [] drm_atomic_commit+0x17/0
On Thu, Feb 05, 2015 at 10:47:24AM +, Nick Hoath wrote:
> From: "Hoath, Nicholas"
>
> Add:
> WaForceEnableNonCoherent
>
> v1: Don't add WaHdcDisableFetchWhenMasked. Add stepping check for
> WaForceEnableNonCoherent
>
> Signed-off-by: Nick Hoath
Reviewed-by: Damien Lespiau
--
Damien
>
On Thu, Feb 05, 2015 at 10:47:23AM +, Nick Hoath wrote:
> From: "Hoath, Nicholas"
>
> Move Wa4x4STCOptimizationDisable to gen9_init_workarounds
>
> v1: rebase
>
> Signed-off-by: Nick Hoath
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4
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:22AM +, Nick Hoath wrote:
> Move WaEnableYV12BugFixInHalfSliceChicken7 to gen9_init_workarounds
>
> v1: Add stepping check.
>
> Signed-off-by: Nick Hoath
Reviewed-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 +++
> drivers/gpu/drm/i
On Thu, Feb 05, 2015 at 10:47:21AM +, Nick Hoath wrote:
> From: "Hoath, Nicholas"
>
> Add stepping check for WaDisableSDEUnitClockGating.
>
> Signed-off-by: Nick Hoath
Reviewed-by: Damien Lespiau
--
Damien
> ---
> drivers/gpu/drm/i915/intel_pm.c | 14 --
> 1 file changed,
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
For the record, this W/A has no name nor documentation. So well...
Reviewed-by: Damien Lespiau
--
Damien
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 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
> ---
> drivers/gpu/drm/i915/intel_pm.c | 8
>
On Thu, Feb 05, 2015 at 10:47:18AM +, Nick Hoath wrote:
> From: "Hoath, Nicholas"
>
> 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 and mention SKL:
d
On Thu, Feb 05, 2015 at 10:47:17AM +, Nick Hoath wrote:
> From: "Hoath, Nicholas"
>
> Add Skylake stepping Revision IDs definitions.
>
> v1: Use existing revision id.
>
> Signed-off-by: Nick Hoath
Namespacing is usually NAMESPACE_VALUE, so I guess it'd be SKL_REVID_A0,
but meh.
Also:
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 282/283
On Thu, Feb 05, 2015 at 10:47:16AM +, Nick Hoath wrote:
> From: "Hoath, Nicholas"
>
> 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
Reviewed-by: Damien Lespiau
> ---
> drivers/gpu/
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:
[] drm_atomic_check_only+0x35d/0x510 [drm]
[] drm_atomic_commit+0x17/0x60 [drm]
[] drm_atomic_helper_plane_set_property+0x8d/0xd0
[drm_kms_helper]
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
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 th
At least here, the following commit introduced 2 warnings when loading the
driver:
commit 706dc7b549175e47f23e913b7f1e52874a7d0f56
Author: Matt Roper
Date: Tue Feb 3 13:10:04 2015 -0800
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
The series
The code look slightly better this way and will ease the next commit,
changing where we take the fb pointer from.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_di
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:
[] dump_stack+0x4f/0x7b
[] warn_slowpath_common+0xaa/0xd0
[] warn_slowpath_null+0x1a/0x20
[] drm_framebuffer_reference+0x6c/0x80 [drm]
[]
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 i
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 h
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 bo
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: https
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)
remove
Daniel Vetter writes:
> 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 behavio
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 (v1)
Sign
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 5 February 2015 at 14:41, Tvrtko Ursulin
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
> gem-create ioctl to pass arou
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
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
---
lib/io
From: Tvrtko Ursulin
Let the DRM core know we can handle it.
v2: Change to boolean true. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/in
From: Tvrtko Ursulin
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 object is set for display. Th
From: Rob Clark
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.
The proposal is to
From: Tvrtko Ursulin
To be used from the new addfb2 extension.
Signed-off-by: Tvrtko Ursulin
---
include/uapi/drm/i915_drm.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 6eed16b..e4c09e2 100644
--- a/includ
From: Tvrtko Ursulin
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 fb->modifier[0] directly at call s
On Tue, 03 Feb 2015, Daniel Vetter 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 the gem
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 probl
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 b
On Wed, Feb 04, 2015 at 04:42:14PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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
> ---
> lib/ioctl_wrappers.c | 45 ++
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:
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 282/283
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
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
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 wrote:
> >>Dear maintainers,
> >>
> >>On an Asus Zenbook UX32VD laptop with an i5-3317U CPU and Intel HD4000
> >>graphics, I'm experiencing the follow
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
until
Added:
Syncing dependencies between camera and graphics
v1: Added missing register bitmap
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
From: "Hoath, Nicholas"
Add:
WaForceEnableNonCoherent
v1: Don't add WaHdcDisableFetchWhenMasked. Add stepping check for
WaForceEnableNonCoherent
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/
From: "Hoath, Nicholas"
Add stepping check for WaDisableSDEUnitClockGating.
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2
From: "Hoath, Nicholas"
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
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/in
Move WaEnableYV12BugFixInHalfSliceChicken7 to gen9_init_workarounds
v1: Add stepping check.
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915
From: "Hoath, Nicholas"
Add:
WaDisablePartialInstShootdown
v1: Dont add WaDisableThreadStallDopClockGating as not SKL WA. (Found by Damien
Lespiau)
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm
From: "Hoath, Nicholas"
Add Skylake stepping Revision IDs definitions.
v1: Use existing revision id.
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index
From: "Hoath, Nicholas"
Add:
WaEnableForceRestoreInCtxtDescForVCS
v1: Add stepping check.
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915
From: "Hoath, Nicholas"
Move Wa4x4STCOptimizationDisable to gen9_init_workarounds
v1: rebase
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 4
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/
Move WaDisableDgMirrorFixInHalfSliceChicken5 to gen9_init_workarounds
v1: Added stepping check
v2: Removed unused register bitmap
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 8
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++
2 files changed, 10 in
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
> T
On Thu, 05 Feb 2015, Stéphane ANCELOT 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 has not t
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 probl
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
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i91
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 loc
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 h
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
Au
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 t
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
78 matches
Mail list logo
