On Tue, Apr 22, 2014 at 07:55:42PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and
On Tue, Apr 22, 2014 at 06:25:12PM -0300, Paulo Zanoni wrote:
2014-04-11 6:02 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Thu, Apr 10, 2014 at 10:52:26AM -0700, Ben Widawsky wrote:
On Thu, Apr 10, 2014 at 10:50:43AM -0700, Ben Widawsky wrote:
On Thu, Apr 10, 2014 at 09:04:47AM +0200,
On Wed, Apr 23, 2014 at 01:13:40AM +0300, Imre Deak wrote:
Atm we can end up in the GPU reset deferred work in D3 state if the last
runtime PM reference is dropped between detecting a hang/scheduling the
work and executing the work. At least one such case I could trigger is
the simulated reset
On Tue, Apr 22, 2014 at 10:05:58PM +0100, Chris Wilson wrote:
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit
On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote:
On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
[...]
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
[...]
@@ -502,6 +503,33 @@ static void drm_fb_helper_crtc_free(struct
On Sun, Apr 13, 2014 at 12:00:33PM +0200, Daniel Vetter wrote:
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the
On Tue, Apr 22, 2014 at 10:22:15PM +0100, Chris Wilson wrote:
On Tue, Apr 22, 2014 at 10:17:50PM +0200, Daniel Vetter wrote:
Otherwise we'll end up spamming dmesg on every context creation on snb
with vt-d enabled. This regression was introduced in
commit
On Wed, Apr 23, 2014 at 09:14:41AM +0200, Thierry Reding wrote:
On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote:
On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
[...]
diff --git a/drivers/gpu/drm/drm_fb_helper.c
b/drivers/gpu/drm/drm_fb_helper.c
[...]
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit d978ef14456a38034f6c0e94a794129501f89200
Author: Jesse Barnes
On Tue, Apr 22, 2014 at 10:05:58PM +0100, Chris Wilson wrote:
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit
On Wed, 2014-04-23 at 09:07 +0200, Daniel Vetter wrote:
On Wed, Apr 23, 2014 at 01:13:40AM +0300, Imre Deak wrote:
Atm we can end up in the GPU reset deferred work in D3 state if the last
runtime PM reference is dropped between detecting a hang/scheduling the
work and executing the work. At
On Fri, Apr 18, 2014 at 03:55:04PM +0300, Imre Deak wrote:
While checking the error capture path I noticed that we lacked the
power domain-on check for PIPESTAT so fix this by moving that to where
the rest of pipe registers are captured.
The move also revealed that we actually don't include
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit d978ef14456a38034f6c0e94a794129501f89200
Author: Jesse Barnes
On Fri, Apr 18, 2014 at 04:01:02PM +0300, Imre Deak wrote:
Atm, an invalid enable_rc6 module option will be silently ignored, so
emit an info message about it. Doing an early sanitization we can also
reuse intel_enable_rc6() in a follow-up patch to see if RC6 is actually
enabled. Currently the
On Fri, Apr 18, 2014 at 04:16:23PM +0300, Imre Deak wrote:
This is needed by the next patch moving the call out from platform
specific RPM callbacks to platform independent code.
No functional change.
v2:
- patch introduce in v2 of the patchset
v3:
- simplify platform check condition
On Tue, Apr 22, 2014 at 08:21:07PM +0300, Imre Deak wrote:
During runtime suspend there can be a last pending rps.work, so make
sure it's canceled. Note that in the runtime suspend callback we can't
get any RPS interrupts since it's called only after the GPU goes idle
and we set the minimum
On Fri, Apr 18, 2014 at 04:35:02PM +0300, Imre Deak wrote:
This will be needed by the VLV runtime PM helpers too, so factor it out.
Also add a safety check for the case where the previous force-off is
still pending, since I'm not sure if Punit can handle a new setting
while the previous one
On Sun, Apr 13, 2014 at 12:00:33PM +0200, Daniel Vetter wrote:
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the
On Wed, Apr 23, 2014 at 08:54:31AM +0100, Chris Wilson wrote:
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit
On Tue, 22 Apr 2014, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Otherwise we'll end up spamming dmesg on every context creation on snb
with vt-d enabled. This regression was introduced in
commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
Author: Ben Widawsky benjamin.widaw...@intel.com
Date:
On Wed, 2014-04-23 at 09:13 +0800, Zhao Yakui wrote:
On Tue, 2014-04-22 at 13:44 -0600, Daniel Vetter wrote:
On Tue, Apr 22, 2014 at 02:52:04PM +0300, Imre Deak wrote:
On Tue, 2014-04-15 at 10:38 +0800, Zhao Yakui wrote:
The Broadwell GT3 machine has two independent BSD rings in kernel
On Tue, Apr 22, 2014 at 07:55:43PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This was suggested by Chris on his review to the first version of
drm/i915: get power domain in case the BIOS enabled eDP VDD. Well,
at least that's what I understood from his comment :)
On Tue, Apr 22, 2014 at 07:55:45PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We already call intel_dp_power_get, which will get a power domain, and
every power domain should get a runtime PM reference, which will wake
up the machine.
intel_crt_detect() could use
On Thu, Apr 10, 2014 at 03:08:06PM +0300, Antti Koskipaa wrote:
We can't have the hw cursor enabled during software render tests.
Signed-off-by: Antti Koskipaa antti.koski...@linux.intel.com
---
tests/kms_cursor_crc.c | 54
--
1 file
On Wed, 23 Apr 2014, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return
On Wed, 23 Apr 2014, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Wed, Apr 23, 2014 at 08:54:31AM +0100, Chris Wilson wrote:
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup
On Sun, 13 Apr 2014, Daniel Vetter daniel.vet...@ffwll.ch wrote:
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the
On Thu, Apr 10, 2014 at 03:08:11PM +0300, Antti Koskipaa wrote:
Signed-off-by: Antti Koskipaa antti.koski...@linux.intel.com
---
tests/kms_cursor_crc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index b2498a1..e00abf5
On Tuesday, April 22, 2014 07:20:58 PM Daniel Vetter wrote:
On Tue, Apr 22, 2014 at 04:23:12PM +0100, Chris Wilson wrote:
On Tue, Apr 22, 2014 at 06:16:34PM +0300, Abdiel Janulgue wrote:
This patch series enables resource streamer for xf86-video-intel UXA.
Fixes i965 Mesa driver that
Hi Brad,
On 04/18/2014 12:18 AM, Volkin, Bradley D wrote:
On Wed, Mar 19, 2014 at 04:13:06AM -0700, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also
On 04/18/2014 06:10 PM, Volkin, Bradley D wrote:
On Wed, Mar 19, 2014 at 04:13:04AM -0700, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common
On Wed, Apr 23, 2014 at 09:35:48AM +0200, Daniel Vetter wrote:
On Wed, Apr 23, 2014 at 09:14:41AM +0200, Thierry Reding wrote:
On Tue, Apr 22, 2014 at 05:54:06PM +0200, Daniel Vetter wrote:
On Tue, Apr 22, 2014 at 04:42:20PM +0200, Thierry Reding wrote:
[...]
diff --git
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Dependencies are not available at the moment so it does not build.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/Android.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/Android.mk b/tests/Android.mk
index
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Makes for a little bit less code duplication, especially since
it will be used from more callers in the future.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
lib/drmtest.h | 9 +
lib/media_fill_gen7.c | 2 +-
[snip]
On Wed, Apr 23, 2014 at 06:28:54AM -0700, Tvrtko Ursulin wrote:
On 04/18/2014 12:18 AM, Volkin, Bradley D wrote:
On Wed, Mar 19, 2014 at 04:13:06AM -0700, Tvrtko Ursulin wrote:
+static void **handle_ptr_map;
+static unsigned int num_handle_ptr_map;
I'd prefer that we explicitly
On Wed, Apr 23, 2014 at 06:33:40AM -0700, Tvrtko Ursulin wrote:
On 04/18/2014 06:10 PM, Volkin, Bradley D wrote:
On Wed, Mar 19, 2014 at 04:13:04AM -0700, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
For
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the process address space. Reason
for that is the impact of MMU notifiers on
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
No need for the old test case once the new one was added.
v2:
* Just rebase for lib/ reorganization.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/.gitignore | 1 -
tests/Makefile.sources | 1 -
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some common behaviour from gem_evict_everything and made both
test cases use it to avoid duplicating the code.
Both unsynchronized
On Wed, Apr 23, 2014 at 1:21 PM, Abdiel Janulgue
abdiel.janul...@linux.intel.com wrote:
I've already tried disabling RS at the end of every batch so that next batch
in different context can continue to use older non-RS format. That does not
work either and still causes hangs.
What I've seen
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
On Wed, Apr 23, 2014 at 08:07:55AM -0700, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Makes for a little bit less code duplication, especially since
it will be used from more callers in the future.
Signed-off-by:
The DRM core setplane code should check that the plane is usable on the
specified CRTC before calling into the driver.
Prior to this patch, a plane's possible_crtcs field was purely
informational for userspace and was never actually verified at the
kernel level (aside from the primary plane
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
v5:
- Use new drm_primary_helper_check_update() helper function to check
setplane parameter validity.
- Swap primary plane's pipe for pre-gen4 FBC (caught
Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.
A few of the checks here were also updated based on suggestions by
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
On Wed, Apr 23, 2014 at 09:03:23AM -0700, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
They build fine so give them some exposure.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
Android.mk
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
On Wed, Apr 23, 2014 at 05:38:34PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
No need for the old test case once the new one was added.
v2:
* Just rebase for lib/ reorganization.
Signed-off-by:
On Wed, Apr 23, 2014 at 05:38:35PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This adds a small benchmark for the new userptr functionality.
Apart from basic surface creation and destruction, also tested is the
impact of having userptr surfaces in the
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
On Wed, Apr 23, 2014 at 05:38:33PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
A set of userptr test cases to support the new feature.
For the eviction and swapping stress testing I have extracted
some
On Wed, Apr 23, 2014 at 09:18:03AM +0200, Daniel Vetter wrote:
On Tue, Apr 22, 2014 at 10:22:15PM +0100, Chris Wilson wrote:
On Tue, Apr 22, 2014 at 10:17:50PM +0200, Daniel Vetter wrote:
Otherwise we'll end up spamming dmesg on every context creation on snb
with vt-d enabled. This
On Wed, Apr 23, 2014 at 06:52:09PM +0200, Daniel Vetter wrote:
On Wed, Apr 23, 2014 at 1:21 PM, Abdiel Janulgue
abdiel.janul...@linux.intel.com wrote:
I've already tried disabling RS at the end of every batch so that next batch
in different context can continue to use older non-RS format.
On Wed, Apr 23, 2014 at 08:32:27AM -0700, Volkin, Bradley D wrote:
On Wed, Apr 23, 2014 at 06:33:40AM -0700, Tvrtko Ursulin wrote:
On 04/18/2014 06:10 PM, Volkin, Bradley D wrote:
On Wed, Mar 19, 2014 at 04:13:04AM -0700, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Otherwise we'll end up spamming dmesg on every context creation on snb
with vt-d enabled. This regression was introduced in
commit 246cbfb5fb9a1ca0997fbb135464c1ff5bb9c549
Author: Ben Widawsky benjamin.widaw...@intel.com
Date: Fri Dec 6 14:11:14 2013 -0800
drm/i915: Reorganize
On Wed, Apr 23, 2014 at 11:37:46AM +0300, Jani Nikula wrote:
On Tue, 22 Apr 2014, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Otherwise we'll end up spamming dmesg on every context creation on snb
with vt-d enabled. This regression was introduced in
commit
On Tue, Apr 22, 2014 at 09:51:56PM +0100, Chris Wilson wrote:
On Tue, Apr 22, 2014 at 08:19:41PM +0300, Mika Kuoppala wrote:
Hi,
Here are patches to initialize first render context to a hopefully,
valid state. If pipeline/context is not initialized and we enter rc6 on bdw,
the render
On Wed, Apr 23, 2014 at 10:03:59AM -0700, Matt Roper wrote:
The DRM core setplane code should check that the plane is usable on the
specified CRTC before calling into the driver.
Prior to this patch, a plane's possible_crtcs field was purely
informational for userspace and was never actually
On Wed, Apr 23, 2014 at 08:03:50PM +0200, Daniel Vetter wrote:
On Wed, Apr 23, 2014 at 10:03:59AM -0700, Matt Roper wrote:
The DRM core setplane code should check that the plane is usable on the
specified CRTC before calling into the driver.
Prior to this patch, a plane's possible_crtcs
On Wed, Apr 23, 2014 at 11:26:04AM -0700, Matt Roper wrote:
On Wed, Apr 23, 2014 at 08:03:50PM +0200, Daniel Vetter wrote:
On Wed, Apr 23, 2014 at 10:03:59AM -0700, Matt Roper wrote:
The DRM core setplane code should check that the plane is usable on the
specified CRTC before calling into
On Wed, Apr 23, 2014 at 10:04:00AM -0700, Matt Roper wrote:
Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.
A
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On ILK when we disable a particular watermark level, we must
Just to be clear: do you mean ILK or ILK+ here?
maintain the actual watermark values for that level for some time
(until
This fills all the gaps we've had in our execbuf testing. Overflow
testing of the various arrays is already done by gem_reloc_overflow.
Also add kms_flip_tiling to .gitignore.
This will cause a bunch of failures since current kernels don't catch
all fallout.
Signed-off-by: Daniel Vetter
We need to make sure that userspace keeps on following the contract,
otherwise we won't be able to use the reserved fields at all.
Testcase: igt/gem_exec_params/*-dirt
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 ++
1 file changed, 6
Currently we catch it, but silently succeed. Our userspace is
better than this.
Testcase: igt/gem_exec_params/sol-reset-*
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
A bit tricky since 0 is also a valid constant ...
Testcase: igt/gem_exec_params/rel-constants-*
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On Wed, Apr 23, 2014 at 04:13:25PM -0300, Paulo Zanoni wrote:
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On ILK when we disable a particular watermark level, we must
Just to be clear: do you mean ILK or ILK+ here?
IIRC
Hi!
After update to 3.15-rc2, only top 20% of screen works on X.
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
On Wed, Apr 23, 2014 at 10:22 PM, Pavel Machek pa...@ucw.cz wrote:
After update to 3.15-rc2, only top 20% of screen works on X.
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation 4 Series
On 04/22/2014 12:30 PM, Daniel Vetter wrote:
During testing of i915.ko with working texture sets larger than RAM, we
encounter OOM with plenty of memory still trapped within writeback, e.g:
[ 42.386039] active_anon:10134 inactive_anon:1900781 isolated_anon:32
active_file:33
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make sure we programmed the watermarks correctly, by reading out the
hardware state again after programming and comparing it with the
state we supposedly programmed into hardware. Dump
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Pull the LP0 validate out from intel_compute_pipe_wm() into a separate
function. We will have further need for such a function to validate
both the final watermarks and the
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Split ilk_update_wm() into two parts; one doing the progragramming
and the other the calculations.
There are 1.060 google results for the word progragramming, which
you used above :)
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a mutex to protect most of the watermark state. Will be useful when
we start to update watermarks asynchronously from plane updates, or
when we get finer grained locking for
On Wed 2014-04-23 23:09:45, Daniel Vetter wrote:
On Wed, Apr 23, 2014 at 10:22 PM, Pavel Machek pa...@ucw.cz wrote:
After update to 3.15-rc2, only top 20% of screen works on X.
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
Hi!
After update to 3.15-rc2, only top 20% of screen works on X.
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
This follows Daniel's advice to add the two test cases based on multi drm_fd to
test the ring sync and CPU-GPU sync.
The Broadwell GT3 machine has two independent BSD rings that can be used
to process the video commands. This is implemented in kernel driver and
transparent
to the user-space. But
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the CPU-GPU sync for the second BSD ring.
V1-V2: Follow Daniel's comment to add one subtext instead of one individual
test case, which is used
On Wed, 2014-04-23 at 20:02 -0600, Zhao, Yakui wrote:
It seems that the patch 01 is filter out.
So I will try to resend it again.
Thanks.
Yakui
This follows Daniel's advice to add the two test cases based on multi drm_fd
to
test the ring sync and CPU-GPU sync.
The Broadwell GT3
This follows Daniel's advice to add the two test cases based on multi drm_fd to
test the ring sync and CPU-GPU sync.
The Broadwell GT3 machine has two independent BSD rings that can be used
to process the video commands. This is implemented in kernel driver and
transparent
to the user-space. But
The Broadwell GT3 machine has two independent BSD rings in kernel driver while
it is transparent to the user-space driver. In such case it needs to check
the ring sync between the two BSD rings. At the same time it also needs to
check the sync among the second BSD ring and the other rings.
V2-V3:
On Thu, Apr 24, 2014 at 12:09:52AM +0200, Pavel Machek wrote:
Hi!
After update to 3.15-rc2, only top 20% of screen works on X.
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel
On Wed, Apr 23, 2014 at 02:14:36PM -0700, Dave Hansen wrote:
On 04/22/2014 12:30 PM, Daniel Vetter wrote:
During testing of i915.ko with working texture sets larger than RAM, we
encounter OOM with plenty of memory still trapped within writeback,
e.g:
[ 42.386039]
80 matches
Mail list logo
