On Tue, 21 Jan 2014, Thierry Reding thierry.red...@gmail.com wrote:
This is a superset of the current i2c_dp_aux bus functionality and can
be used to transfer native AUX in addition to I2C-over-AUX messages.
Helpers are provided to read and write the DPCD, either blockwise or
byte-wise. Many
On Tue, 21 Jan 2014, Thierry Reding thierry.red...@gmail.com wrote:
Implements an I2C-over-AUX I2C adapter on top of the generic drm_dp_aux
infrastructure. It extracts the retry logic from existing drivers, which
should help in porting those drivers to this new helper.
Reviewed-by: Alex
On Mon, Feb 03, 2014 at 03:00:19PM -0800, Volkin, Bradley D wrote:
Ping. Daniel or Chris, can one of you clarify this request? Thanks.
I've been enjoying fosdem ...
On Thu, Jan 30, 2014 at 10:05:27AM -0800, Volkin, Bradley D wrote:
On Thu, Jan 30, 2014 at 03:07:15AM -0800, Daniel Vetter
On Thu, Jan 30, 2014 at 09:28:25AM -0800, Volkin, Bradley D wrote:
On Thu, Jan 30, 2014 at 01:20:57AM -0800, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 02:26:12PM -0800, Volkin, Bradley D wrote:
On Wed, Jan 29, 2014 at 02:13:21PM -0800, Chris Wilson wrote:
On Wed, Jan 29, 2014 at
On Mon, Feb 03, 2014 at 09:13:17AM +0530, Vandana Kannan wrote:
Again, everywhere else in intel_bios.c we use panel_type, directly as it
is in VBT, 0-based. Are you saying it's all wrong? panel_type can't be
1-based in this one instance, and 0-based in all other instances, right?
This
On Fri, Jan 31, 2014 at 08:05:37AM -0500, Rodrigo Vivi wrote:
Both registers must be programmed for the Mode bit to be valid. DevIVB:GT2 ...
So I also agree ;)
Maybe you should improve the commit message now that we are sure, but anyway:
I've added a little not to the commit message when
On Sat, Feb 01, 2014 at 11:34:02AM +, Chris Wilson wrote:
On Wed, Jan 29, 2014 at 08:21:41PM +0100, Daniel Vetter wrote:
On Wed, Jan 29, 2014 at 12:55:35PM -0200, Rodrigo Vivi wrote:
This patch adds PSR Support to Baytrail.
Baytrail cannot easily detect screen updates and force
On Thu, Jan 30, 2014 at 03:01:08PM -0200, Rodrigo Vivi wrote:
On Thu, Jan 30, 2014 at 11:02 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Jan 29, 2014 at 01:50:06PM -0200, Rodrigo Vivi wrote:
@@ -7501,6 +7501,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
On Fri, Jan 31, 2014 at 02:57:35PM +, rafael.barba...@intel.com wrote:
From: Rafael Barbalho rafael.barba...@intel.com
IGT in android still had some hang-ups from the initial porting, we were
re-compiling the lib directory every time for each tool or test binary. It
also could get its
On Mon, Feb 03, 2014 at 03:28:37PM +, Tvrtko Ursulin wrote:
On 01/29/2014 08:34 PM, Daniel Vetter wrote:
Actually I've found something else to complain about:
On Tue, Jan 28, 2014 at 2:16 PM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+#define I915_USERPTR_READ_ONLY 0x1
This
On Thu, Jan 30, 2014 at 07:04:44PM +0200, Mika Kuoppala wrote:
As we seek the guilty batch using request and hangcheck
score, this code is not needed anymore.
v2: Rebase. Passing dev_priv instead of getting it from last_ring
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
On Fri, Jan 31, 2014 at 11:09:47PM +0530, S, Deepak wrote:
On 1/31/2014 10:40 PM, Ville Syrjälä wrote:
On Thu, Jan 30, 2014 at 11:08:16PM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When
On Wed, Jan 29, 2014 at 04:17:37PM +, Damien Lespiau wrote:
+static void run_test(data_t *data, enum ring r1, enum ring r2, enum test
test)
+{
+ struct ring_ops *r1_ops = ops[r1];
+ struct ring_ops *r2_ops = ops[r2];
+ drm_intel_bo *a, *b, *c;
+
+ a = bo_create(data,
On Fri, Jan 31, 2014 at 11:34:58AM +, Chris Wilson wrote:
Since a purged buffer is one without any associated pages, attempting to
use it should generate EFAULT rather than EINVAL, as it is not strictly
an invalid parameter.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Care to
On Mon, Feb 03, 2014 at 11:59:05AM +0530, Sagar Arun Kamble wrote:
On Fri, 2014-01-31 at 22:38 +0200, Ville Syrjälä wrote:
On Sat, Feb 01, 2014 at 12:40:36AM +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
With these patches 180 degree rotation for
On Fri, Jan 31, 2014 at 05:14:02PM +0200, Mika Kuoppala wrote:
Found with smatch.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
Both smatch patches merged to dinq, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
This test will verify the 180 degree rotation of sprite and crtc planes.
It will allow user to control rotation separately for crtc and sprite
planes.
Signed-off-by: Sagar
On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
This test will verify the 180 degree rotation of sprite and crtc planes.
It will allow user to control
On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
This test will verify the 180 degree rotation of sprite and crtc planes.
It will allow user to control
On Fri, Jan 31, 2014 at 03:42:47PM -0600, jeff.mc...@intel.com wrote:
From: Jeff McGee jeff.mc...@intel.com
This series has recently been accepted into the Haswell Android kernel and
helps with debugging and profiling these power features. I would like it
to be considered for upstream
On Fri, Jan 31, 2014 at 03:42:48PM -0600, jeff.mc...@intel.com wrote:
From: Jeff McGee jeff.mc...@intel.com
RPS manual mode disables/ignores load-based inputs and allows render
performance state to be controlled externally. The enabling of manual
mode and setting of desired frequency is done
On Sat, Feb 01, 2014 at 05:14:22PM +, Chris Wilson wrote:
On Fri, Jan 31, 2014 at 03:42:47PM -0600, jeff.mc...@intel.com wrote:
From: Jeff McGee jeff.mc...@intel.com
This series has recently been accepted into the Haswell Android kernel and
helps with debugging and profiling these
On Tue, 2014-02-04 at 11:25 +, Damien Lespiau wrote:
On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
This test will verify the 180 degree rotation
On Tue, Feb 04, 2014 at 12:05:13PM +0100, Daniel Vetter wrote:
On Fri, Jan 31, 2014 at 11:34:58AM +, Chris Wilson wrote:
Since a purged buffer is one without any associated pages, attempting to
use it should generate EFAULT rather than EINVAL, as it is not strictly
an invalid parameter.
On Tue, Feb 04, 2014 at 12:31:37PM +0100, Daniel Vetter wrote:
On Fri, Jan 31, 2014 at 03:42:48PM -0600, jeff.mc...@intel.com wrote:
From: Jeff McGee jeff.mc...@intel.com
RPS manual mode disables/ignores load-based inputs and allows render
performance state to be controlled externally.
On Tue, Feb 04, 2014 at 05:05:47PM +0530, Sagar Arun Kamble wrote:
On Tue, 2014-02-04 at 11:25 +, Damien Lespiau wrote:
On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
From: Sagar Kamble
On Tue, Feb 04, 2014 at 11:46:46AM +, Damien Lespiau wrote:
On Tue, Feb 04, 2014 at 05:05:47PM +0530, Sagar Arun Kamble wrote:
On Tue, 2014-02-04 at 11:25 +, Damien Lespiau wrote:
On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
On Sat, Feb 01, 2014 at 12:43:48AM
Bunch of explicit include paths needed adjustments and
eviction_common.c needs to be added to the dist files.
This has been broken in the following three commits:
commit 42bcd05eb3f1545fbf9c397c3f37c3f6a27c5da4
Author: Tvrtko Ursulin tvrtko.ursu...@intel.com
Date: Mon Feb 3 10:59:41 2014 +
On Tue, Feb 04, 2014 at 02:08:27PM +0200, Ville Syrjälä wrote:
On Tue, Feb 04, 2014 at 11:46:46AM +, Damien Lespiau wrote:
On Tue, Feb 04, 2014 at 05:05:47PM +0530, Sagar Arun Kamble wrote:
On Tue, 2014-02-04 at 11:25 +, Damien Lespiau wrote:
On Tue, Feb 04, 2014 at 12:18:24PM
We get a large number of bugs which have a, hey I have that too
because they see a GPU hang in dmesg. While two machines of the same
model having a GPU hang is indeed a coincidence, it is far from enough
evidence to suggest they are the same.
In order to reduce this effect, and hopefully get
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
v3: Added EDP
On Mon, Feb 03, 2014 at 10:59:41AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Make sure selection loop does not generate duplicates
when it picks a subset of objects for a single exec buffer.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
I've
On Tue, Feb 4, 2014 at 1:18 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
We get a large number of bugs which have a, hey I have that too
because they see a GPU hang in dmesg. While two machines of the same
model having a GPU hang is indeed a coincidence, it is far from enough
evidence
Hi x86 folks,
Ping on getting the gen2 stolen memory early quirk patches into the x86
tree.
From our side Daniel and Chris both seemed happy with them, so I'd like
to get them in at some point.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
The main differences are:
* Many of the native aux differences mentioned in the relevant commit
apply.
* Native aux and i2c-over-aux defer timeouts are increased to be safe
for all use cases instead of depending on DP device type and
properties.
* i2c start/stop/reset are not done.
* i2c
The main differences are:
* Native aux has retry limit of 7 instead of infinite retry.
* Sleep in native reply defer increases from udelay(100) to
usleep_range(400, 500).
* Unknown native reply results in retry instead of -EIO.
* Lower level -EBUSY results in retry instead of fail.
* Write
This is prep work for conversion to generic drm i2c-over-aux helpers
where we won't have the function to do this at.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
Introduce _edp_panel_vdd_on() that returns true if the call enabled vdd,
and a matching disable is needed. Keep edp_panel_vdd_on() as a helper
for when it is expected the vdd is off.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 22
There's some confusion between ints and bools.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 45 ++-
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 835f16da80af..0a8a2b189ed0
intel_dp_aux_native_read_retry() is only needed when the sink might be
asleep. Use the regular read without retries otherwise.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 33 +
1 file changed, 13 insertions(+), 20
These are based on drm-intel-nightly plus Thierry's aux channel
infrastructure patches [1], and supersede my dp aux fixes [2].
Patches 1-4 are prep work and fixes to our current code.
Patches 5 and 7 do the actual conversion for native aux and i2c over
aux, respectively. Patch 6 is minor cleanup
In the case of a moving cursor that means indefinitely.
That's true... So I think we really need a work queue delaying the enable.
Or do you have any better idea?
Yeah, sounds like we need a delayed work-queue to re-enable psr, also for
gtt mmap writes. See Chris' latest crazy example of
Inserting additional PTEs has no side-effect for us as the pfn are fixed
for the entire time the object is resident in the global GTT. The
downside is that we pay the entire cost of faulting the object upon the
first hit, for which we in return receive the benefit of removing the
per-page faulting
On Tue, Feb 04, 2014 at 01:30:19PM +, Chris Wilson wrote:
Inserting additional PTEs has no side-effect for us as the pfn are fixed
for the entire time the object is resident in the global GTT. The
downside is that we pay the entire cost of faulting the object upon the
first hit, for which
On Tue, Feb 04, 2014 at 03:15:26PM +0100, Daniel Vetter wrote:
On Tue, Feb 04, 2014 at 03:12:49PM +0100, Daniel Vetter wrote:
On Tue, Feb 04, 2014 at 01:30:19PM +, Chris Wilson wrote:
Inserting additional PTEs has no side-effect for us as the pfn are fixed
for the entire time the
On Tue, Feb 04, 2014 at 03:40:44PM +0200, Jani Nikula wrote:
intel_dp_aux_native_read_retry() is only needed when the sink might be
asleep. Use the regular read without retries otherwise.
I guess I should repeat here what I mentioned to Jani:
The DP spec seems to indicate that AUX transactions
This test demonstrates the performance cliff clients face when they
unwittingly use too many fenced surfaces in a looped upload.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
Note that pass/fail here is based on arbitrary value, and passing the test
is a wishlist item. Is it worthwhile
On Tue, Feb 04, 2014 at 03:12:49PM +0100, Daniel Vetter wrote:
On Tue, Feb 04, 2014 at 01:30:19PM +, Chris Wilson wrote:
Inserting additional PTEs has no side-effect for us as the pfn are fixed
for the entire time the object is resident in the global GTT. The
downside is that we pay the
On Tue, Feb 04, 2014 at 11:03:25AM -0200, Rodrigo Vivi wrote:
In the case of a moving cursor that means indefinitely.
That's true... So I think we really need a work queue delaying the enable.
Or do you have any better idea?
Yeah, sounds like we need a delayed work-queue to re-enable
On Tue, Feb 04, 2014 at 11:36:39AM +, Chris Wilson wrote:
On Tue, Feb 04, 2014 at 12:05:13PM +0100, Daniel Vetter wrote:
On Fri, Jan 31, 2014 at 11:34:58AM +, Chris Wilson wrote:
Since a purged buffer is one without any associated pages, attempting to
use it should generate EFAULT
On Mon, Feb 03, 2014 at 10:59:42AM +, 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 behaviour from gem_evict_everything and made both
Exercise that calling madvise produces expected results
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/gem_madvise.c| 155 +
3 files changed, 157 insertions(+)
On Tue, Feb 04, 2014 at 11:40:20AM +, Chris Wilson wrote:
On Tue, Feb 04, 2014 at 12:31:37PM +0100, Daniel Vetter wrote:
On Fri, Jan 31, 2014 at 03:42:48PM -0600, jeff.mc...@intel.com wrote:
From: Jeff McGee jeff.mc...@intel.com
RPS manual mode disables/ignores load-based inputs
On Tue, Feb 04, 2014 at 02:14:31PM +, Chris Wilson wrote:
Exercise that calling madvise produces expected results
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Thanks a lot for the testcase and patches, all pulled in.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
On Fri, Jan 24, 2014 at 10:15 AM, Imre Deak imre.d...@intel.com wrote:
Atm we try to remove the connector's i2c sysfs entry too late in the
encoder's destroy callback. By that time the kobject used as the parent
for all connector sysfs entries is already removed when we do an early
removal of
On Tue, 2014-02-04 at 17:13 +0100, Daniel Vetter wrote:
On Fri, Jan 24, 2014 at 10:15 AM, Imre Deak imre.d...@intel.com wrote:
Atm we try to remove the connector's i2c sysfs entry too late in the
encoder's destroy callback. By that time the kobject used as the parent
for all connector sysfs
From: Jeff McGee jeff.mc...@intel.com
A check of rps/rc6 state after i915_reset determined that the ring
MAX_IDLE registers were returned to their hardware defaults and that
the GEN6_PMIMR register was set to mask all interrupts. This change
restores those values to their pre-reset states by
From: Jeff McGee jeff.mc...@intel.com
sysfs changes to rps min and max delay were only triggering an update
of the rps interrupt limits if the active delay required an update.
This change ensures that interrupt limits are always updated.
v2: correct compile issue missed on rebase
v3: add igt
On Tue, Feb 04, 2014 at 02:22:24PM +0200, Antti Koskipaa wrote:
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
On Tue, Feb 04, 2014 at 02:20:36AM -0800, Daniel Vetter wrote:
On Mon, Feb 03, 2014 at 03:00:19PM -0800, Volkin, Bradley D wrote:
Ping. Daniel or Chris, can one of you clarify this request? Thanks.
I've been enjoying fosdem ...
On Thu, Jan 30, 2014 at 10:05:27AM -0800, Volkin, Bradley D
Moved to a common location so that Jani also can push to it, to avoid
moving it every time I go on vacation. Please update autobuilders and
everything else pointing at the drm-intel.git repo, the old one won't
be updated any more.
Cc: Dave Airlie airl...@gmail.com
Cc: Jani Nikula
It's not signal safe and I got kms_flip in hung state with the backtrace
below, while the parent process waiting for the signal helper to exit.
It was quite easy to reproduce the bug by running
kms_flip --run-subtest=flip-vs-dpms-off-vs-modeset
With the change I couldn't reproduce it.
0
On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Moved to a common location so that Jani also can push to it, to avoid
moving it every time I go on vacation. Please update autobuilders and
everything else pointing at the drm-intel.git repo, the old one won't
be
Atm on VLV we handle any pending pipestat interruts, whether or not
these were actually enabled explicitly with i915_enable_pipestat(). This
may or may not cause any real problem, but for consistency it's worth
fixing. See the last patch for more details.
I also need this as a dependency for the
At least on VLV we can't get at the pipestat status bits by simply right
shifting the corresponding enable bits. The mapping between enable and
status bits for the sprite0,1 flip done and the PSR events don't follow
this rule, so we need to map them separately.
The PSR enable for pipe A is
This will be used by other platforms too, so factor it out.
The only functional change is the reordeing of gmbus_irq_handler() wrt.
the hotplug handling, but since it only schedules a work, it isn't an
issue.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 76
s/FLIPDONE/FLIP_DONE/ to make all FLIP_DONE macro names consistent.
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 18 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff
There isn't any PSR interrupt enable bit for pipe A, so we couldn't
enable it through the current API. Passing the corresponding status bits
solves this and also makes the mapping between enable and status bits
simpler on VLV (addressed in an upcoming patch).
Except of checking for invalid status
On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Moved to a common location so that Jani also can push to it, to avoid
moving it every time I go on vacation. Please update autobuilders and
everything else pointing at the drm-intel.git repo, the old one won't
be
Atm we call the handlers for pending pipestat interrupt events even if
they aren't explicitly enabled by i915_enable_pipestat(). This isn't an
issue for events other than the vblank start event, since those are
always enabled anyways. Otoh, we enable the vblank start event
on-demand, so we'll end
On Tue, Feb 04, 2014 at 10:45:45AM -0800, Volkin, Bradley D wrote:
The current table structure is that we have tables per-ring and per-gen (plus
the table
for common MI commands) and all tables are treated as blacklist/greylist. The
proposed
flow here would indicate that we need tables
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b5524ea..e0e5190 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++
Bspec and the code suggests that the interrupt signaled by IIR[7,5]
(DISPLAY_PIPE_A/B_VBLANK) is a first level IRQ flag for the second
level PIPEA/BSTAT[2] (Start of Vertical Blank) interrupt. Measuring
the relative timings of when IIR[7] and PIPEASTAT[1,2] get set and
checking the effect of
From: Ville Syrjälä ville.syrj...@linux.intel.com
So I accidentally looked at gen6_init_clock_gating() and noticed a few
weird things that should have gotten cleaned up years ago. So I did that.
While doing that I also noticed the WIZ hashing bits, and the fact that
we weren't following the
From: Ville Syrjälä ville.syrj...@linux.intel.com
BSpec recommends using 8x4 hashing mode when MSAA is used. But in
practice 16x4 seems to have a slight edge in performance (on IVB and
HSW at least). So just use 16x4.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
On SNB we set up WaSetupGtModeTdRowDispatch:snb early in
gen6_init_clock_gating(). That sets a bit in the GEN6_GT_MODE register.
However later we go and disable all the bits in the same register. And
then we go on to set some other bit. So
From: Ville Syrjälä ville.syrj...@linux.intel.com
BSpec recommends using 8x4 hashing mode when MSAA is used. But in
practice 16x4 seems to have a slight edge in performance (on IVB and
HSW at least). So just use 16x4.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
BSpec recommends using 8x4 hashing mode when MSAA is used. But in
practice 16x4 seems to have a slight edge in performance (on IVB and
HSW at least). So just use 16x4.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
From: Ville Syrjälä ville.syrj...@linux.intel.com
The need to set all of the mask bits for 3D_CHICKEN3 was required
only for pre-production hardware.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 5 ++---
1 file changed, 2 insertions(+), 3
From: Ville Syrjälä ville.syrj...@linux.intel.com
According to Bspec we need to disable SF pipelined attribute fetch
whenever SF outputs exceed 16 and normal clip mode is used. A quick
glance at Mesa suggests that these conditions could happen. So let's
just always set the magic bit.
From: Ville Syrjälä ville.syrj...@linux.intel.com
Based on the name, the workaround we implement is
WaStripsFansDisableFastClipPerformanceFix. Unfortunately there's no
description in the w/a database, so this is just a guess.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Hi,
I see a *lot* of these warning in 3.13.1.
3.12.x never showed this problem.
Any ideas?!
[ 9373.175179] WARNING: CPU: 0 PID: 7715 at
drivers/gpu/drm/i915/i915_irq.c:1240 i965_irq_handler+0x4ee/0x670()
[ 9373.175181] Received HPD interrupt although disabled
[ 9373.175183] Modules linked in:
On Fri, Jan 31, 2014 at 01:48:39PM +, Chris Wilson wrote:
On Fri, Jan 31, 2014 at 03:49:08PM +0200, Jani Nikula wrote:
The WARN_ONCE is a bit too verbose, make it a DRM_INFO_ONCE.
While at it, add a #define for MAX_DSLP and make the message a bit more
informative.
v2: use
On Tue, Feb 04, 2014 at 08:37:02PM +0100, Thomas Meyer wrote:
Hi,
I see a *lot* of these warning in 3.13.1.
3.12.x never showed this problem.
Any ideas?!
Can you please try latest the drm-intel-nightly git branch from
git://anongit.freedesktop.org/drm-intel ?
If that one's still affected
On Tue, Feb 04, 2014 at 09:59:15PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
On SNB we set up WaSetupGtModeTdRowDispatch:snb early in
gen6_init_clock_gating(). That sets a bit in the GEN6_GT_MODE register.
However later we go and disable
On Tue, Feb 04, 2014 at 09:15:14PM +0200, Imre Deak wrote:
It's not signal safe and I got kms_flip in hung state with the backtrace
below, while the parent process waiting for the signal helper to exit.
It was quite easy to reproduce the bug by running
kms_flip
On Tue, 2014-02-04 at 21:29 +, Chris Wilson wrote:
On Tue, Feb 04, 2014 at 09:15:14PM +0200, Imre Deak wrote:
It's not signal safe and I got kms_flip in hung state with the backtrace
below, while the parent process waiting for the signal helper to exit.
It was quite easy to reproduce
Hi Daniel,
On Tue, 4 Feb 2014 20:15:03 +0100 Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Moved to a common location so that Jani also can push to it, to avoid
moving it every time I go on vacation. Please update
On Wed, Feb 05, 2014 at 12:04:46AM +0200, Imre Deak wrote:
On Tue, 2014-02-04 at 21:29 +, Chris Wilson wrote:
On Tue, Feb 04, 2014 at 09:15:14PM +0200, Imre Deak wrote:
It's not signal safe and I got kms_flip in hung state with the backtrace
below, while the parent process waiting for
On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wangyij...@huawei.com wrote:
Since acpi_evaluate_object() returns acpi_status and not plain int,
ACPI_FAILURE() should be used for checking its return value. Also
add some detailed debug info when acpi_evaluate_object() failed.
Reviewed-by: Jani
On Mon, Jan 20, 2014 at 7:46 PM, Yijing Wang wangyij...@huawei.com wrote:
Since acpi_evaluate_object() returns acpi_status and not plain int,
ACPI_FAILURE() should be used for checking its return value.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Yijing Wang
On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki r...@rjwysocki.net
wrote:
On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
On Wed, Jan
On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wangyij...@huawei.com wrote:
Since acpi_evaluate_object() returns acpi_status and not plain int,
On 01/21/2014 12:24 PM, Thierry Reding wrote:
Add support for eDP functionality found on Tegra124 and later SoCs. Only
fast link training is currently supported.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
.../bindings/gpu/nvidia,tegra20-host1x.txt | 42 +
This part
On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
Hi All,
I'm seeing the oops below on my MacBookPro 10,2 machine using i915
graphics. It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
but we seem to have one report[1] of this happening well before that,
in
None of these files are actually using any __init type directives
and hence don't need to include linux/init.h. Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Cc: David Airlie airl...@linux.ie
Cc: Daniel Vetter
Hi,
I am installing a DELL Inspiron 7737 with an Intel HD 4400.
PCI Device (8086:0a16). So it should be a HD 4400.
The Operating System is SLES 11 SP1.
I tried to install the sources, but the are so many dependencies.
From the one package to the next package an so on.
Do you have an
And I have a question: how to assure the audio/gfx client find its
right peer?
On a x86 platform, there can be an integrated GPU and an discrete GPU.
So there can be two audio controllers and two GPUs.
We need to assure audio controller find the proper GPU, and vice
versa. Maybe we need the
Hi,
What is the current status for DP MST support on Haswell? Are there
experimental patches that can be tested? If not, what can be done to
help progress?
Supposing the kernel parts are figured, will userland need updates
accordingly, or would the existing multi-head support work as-is?
1 - 100 of 104 matches
Mail list logo
