From: Ping Gao <ping.a@intel.com>
vGPU capability is handled by GVT-g host driver, not needed to
put extra HW check for vGPU detection. And we'll actually support
vGPU from BDW.
Signed-off-by: Ping Gao <ping.a@intel.com>
Signed-off-by: Zhenyu Wang <zhen...@linux.intel.co
On 2015.09.29 15:39:03 +0100, Robert Bragg wrote:
>
> - Logistically it might be more practical to contain this to the
> graphics stack.
>
> It seems fair to consider that if we can't see a very compelling
> benefit to building on perf, then containing this work to
>
On 2015.07.09 13:50:14 +0800, Zhenyu Wang wrote:
GT-Pin has got new kit release (5923). As GT-Pin team has built auto testing
system for GT-Pin on Linux, we now have aligned kit release regularly.
Please check wiki page for details and the link to download the kit.
https
GT-Pin has got new kit release (5923). As GT-Pin team has built auto testing
system for GT-Pin on Linux, we now have aligned kit release regularly.
Please check wiki page for details and the link to download the kit.
https://wiki.ith.intel.com/display/OTCGFXPERF/GT-Pin+for+Linux
thanks.
--
On 2015.03.06 09:44:07 +, Chris Wilson wrote:
Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example along with
On 2015.02.12 08:41:59 +0800, han...@intel.com wrote:
From: Lu, Han han...@intel.com
This patch adds support for dumping audio registers of Skylake.
Signed-off-by: Lu, Han han...@intel.com
Just pushed this. Thanks.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver
On 2015.01.26 01:15:36 +, Yang, Libin wrote:
Any comments?
Looks fine to me. Reviewed-by: Zhenyu Wang zhen...@linux.intel.com
I will help to push this later.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description
on latest release without crash.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
intel/intel_bufmgr_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
I've done more testings about this on more hosts. No regression found
on older HW with previous emulator with memory type change
On 2015.01.12 01:38:34 +, Yang, Libin wrote:
From ebfde852d9efbd7213c391e91be9d0741813bb16 Mon Sep 17 00:00:00 2001
From: Libin Yang libin.y...@intel.com
Date: Wed, 7 Jan 2015 10:56:18 +0800
Subject: [PATCH] intel_audio_dump: add support for Cherryview
This patch adds support for
On 2014.12.18 12:12:33 -0600, jeff.mc...@intel.com wrote:
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 15dd01d..be38adf 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -340,6 +340,10 @@ typedef struct drm_i915_irq_wait {
#define
on latest fulsim release without crash.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
intel/intel_bufmgr_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 14e92c9..3076111 100644
--- a/intel
On 2014.12.03 15:26:13 +0100, Daniel Vetter wrote:
On Wed, Dec 03, 2014 at 07:11:17PM +0800, Zhenyu Wang wrote:
This makes fill function more general to prepare for other
fill method using GPGPU pipeline.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
Series lgtm, please push
This is simply a copy of gem_media_fill but using new
GPGPU fill operation.
v2: Use general fill func pointer.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
tests/Makefile.sources | 1 +
tests/gem_gpgpu_fill.c | 141 +
2 files changed
This makes fill function more general to prepare for other
fill method using GPGPU pipeline.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
lib/intel_batchbuffer.c | 4 ++--
lib/intel_batchbuffer.h | 24
tests/gem_media_fill.c | 2 +-
3 files changed, 15
for one thread per
thread group on SIMD16 dispatch. So the fill shader just uses thread
group ID for buffer offset.
v2: No new fill func typedef but adapt to igt_fillfunc_t.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
lib/gen7_media.h | 2 +
lib/intel_batchbuffer.c
for one thread per
thread group on SIMD16 dispatch. So the fill shader just uses thread
group ID for buffer offset.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
lib/gen7_media.h | 2 +
lib/intel_batchbuffer.c | 19 +
lib/intel_batchbuffer.h | 25 +++
lib
This is simply a copy of gem_media_fill but using new
GPGPU fill operation.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
tests/Makefile.sources | 1 +
tests/gem_gpgpu_fill.c | 141 +
2 files changed, 142 insertions(+)
create mode
On 2014.09.23 10:38:49 +0200, Daniel Vetter wrote:
On Tue, Sep 23, 2014 at 12:41:50AM +0200, Michał Winiarski wrote:
These registers are used as a temporary storage by MI_MATH command when
performing ALU operations.
Signed-off-by: Michał Winiarski michal.winiar...@intel.com
Needs to
...@intel.com
This was added historically when supporting graphics device passthrough.
Looks qemu upstream can't accept multiple ISA bridge and our PCH is always
on device 31: func0 as far as I know. Looks good to me.
Reviewed-by: Zhenyu Wang zhen...@linux.intel.com
--
Open Source Technology Center, Intel
On 2014.03.28 10:21:50 -0700, bradley.d.vol...@intel.com wrote:
From: Brad Volkin bradley.d.vol...@intel.com
There is some thought that the data from the performance counters enabled
via OACONTROL should only be available to the process that enabled counting.
To limit snooping, require that
On 2014.04.10 08:43:40 +0200, Daniel Vetter wrote:
At least in the case of mesa you _must_ use mesa (or whatever your gl
library is) to insert the MI_PERF cmd at just the rigth spots in the
command stream and ofc flush all outstanding vertices and similar things.
If you want a global perf
On 2014.03.05 18:51:48 +0200, Ville Syrjälä wrote:
entries = (clock / 1000) * pixel_size;
*plane_prec_mult = (entries 256) ?
The threshold should also be reduced to 128 entries.
hmm, I'll double check if this is really required or not.
- DRAIN_LATENCY_PRECISION_32 :
On 2014.02.28 16:42:15 +, Damien Lespiau wrote:
In the future, we need to be able to specify per-pipe number of
planes/sprites. Let's start today!
The number of sprite planes on each pipe is always fixed in our HW.
Do we really need this in the future?
--
Open Source Technology Center,
-off-by: Zhenyu Wang zhen...@linux.intel.com
---
src/sna/sna.h | 5 ++-
src/sna/sna_display.c | 106 ++---
src/sna/sna_video_sprite.c | 87 -
3 files changed, 131 insertions(+), 67 deletions(-)
diff
From spec the drain latency precision multipler is either 32 or 64 for VLV.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 18 +-
drivers/gpu/drm/i915/intel_pm.c | 12 ++--
2 files changed, 15 insertions(+), 15 deletions(-)
diff
If valgrind is not available, current VG_CLEAR() would just ignore
memory clear operation which might make invalid ioctl argument. So
make sure VG_CLEAR() will always clear memory.
---
intel/intel_bufmgr_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 2013.11.20 11:36:20 +, Damien Lespiau wrote:
On Wed, Nov 20, 2013 at 05:22:48PM +0800, Zhenyu Wang wrote:
If valgrind is not available, current VG_CLEAR() would just ignore
memory clear operation which might make invalid ioctl argument. So
make sure VG_CLEAR() will always clear
On 2013.11.20 16:59:22 +, Damien Lespiau wrote:
Right, so the fix is (was) to zero the fields checked by the kernel
explicitely, not change the VG() macro, which is just used in testing
(and it should this way).
That's fine. Thanks.
--
Open Source Technology Center, Intel ltd.
$gpg
On 2013.01.24 19:49:40 +0800, Zhang Rui wrote:
I need some graphics experts' comments before sending it out.
Please send to intel-gfx@lists.freedesktop.org for i915 specific issue.
On Thu, 2013-01-24 at 19:43 +0800, Zhang Rui wrote:
i915 driver needs to do modeset when
1. system resumes
From Ben's AGP dependence removal change, needs_dmar flag has not
been properly setup for new chips using new GTT init function. This
one adds missed setting of that flag to make sure we do pci mappings
with IOMMU enabled.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm
Fix power well control state by reading real register offset.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index
On 2012.05.03 12:16:26 +, lbg_...@bluebottle.com wrote:
Hello everyone,
I'm writing to this list, hoping not to be in the wrong place. The subject is
a GMA 3600 graphic controller which I have on a D2500CC Mini-ITX Intel board.
My operating system is Debian Wheezy with latest stable
On 2011.11.11 16:50:41 +0800, Wu Fengguang wrote:
I still think you should do those in hot_plug(), to call detect() for
current
status, write eld and set specific audio enable/disable bit for all
audio stuff.
Just my sense, you may send RFC patch for other's comment.
those old devices.
Reported-by: Linus Torvalds torva...@linux-foundation.org
Reported-by: Jan Niehusmann j...@gondor.com
Reported-by: Justin P. Mattock justinmatt...@gmail.com
Reported-and-tested-by: Michael brot Groh b...@minad.de
Cc: Zhenyu Wang zhen...@linux.intel.com
Signed-off-by: Chris
I've done more testing with below patches, eliminated some in first
patch set that doesn't affect suspend issue it seems.
The test was done with one rev9 SNB on two boards DH67GD and DQ67SW
with latest bios. And it both passed over 100 cycles of S3 testing.
Without these, upstream kernel still
Some bits should only be set when enable FBC.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h |4 +++-
drivers/gpu/drm/i915/intel_display.c | 27 ++-
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers
DSPARB is reserved on G33 and not available on Gen6.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_suspend.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
Move RC6 enable after we reset rings for all regines, if e.g render ring
is disabled when RC6 enable on Sandybridge, hw won't save render context
image if any chance when enter RC6. Also match the order like we do in
driver load.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu
On 2011.03.23 12:03:41 +0900, Keith Packard wrote:
On Wed, 23 Mar 2011 10:21:07 +0800, Zhenyu Wang zhen...@linux.intel.com
wrote:
DSPARB is reserved on G33 and not available on Gen6.
Does this fix a reported problem? Or just spec compliance?
I didn't verify if this one is really
Below patches aim to fix https://bugs.freedesktop.org/show_bug.cgi?id=35462.
With them I've been able to run many cycles of S3 tests on two SNB/CPT boards
here, which would hang immediately after S3 resume with upstream kernel.
It still needs more testing, I'd like to get them reviewed first.
Some bits should only be set when enable FBC.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h |4 +++-
drivers/gpu/drm/i915/intel_display.c | 27 ++-
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/drivers
we don't use it anywhere.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_suspend.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 0521ecf..422981b
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_suspend.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 422981b..7f00f8b 100644
--- a/drivers/gpu
we don't use it anywhere.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_suspend.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 7f00f8b..11e61a3
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_suspend.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 11e61a3..26387c3 100644
--- a/drivers/gpu/drm
Move FORCEWAKE_ACK == 0 wait after setting force wake to 0. This is
another way to set force wake for GT read from spec. And also this
makes RC6 setting order strictly follow spec.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 11 +++
1 files
Move RC6 enable after we reset rings for all regines, as RC6 on
Sandybridge would setup ring idle state, so I assume we should have
setup rings already.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c |4
drivers/gpu/drm/i915/i915_suspend.c
On 2011.03.21 10:40:51 -0700, Jesse Barnes wrote:
On Mon, 21 Mar 2011 17:27:15 +0800
Zhenyu Wang zhen...@linux.intel.com wrote:
we don't use it anywhere.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_suspend.c |6 --
1 files changed, 0
On 2011.03.21 09:46:20 +, Chris Wilson wrote:
On Mon, 21 Mar 2011 17:27:17 +0800, Zhenyu Wang zhen...@linux.intel.com
wrote:
Move FORCEWAKE_ACK == 0 wait after setting force wake to 0. This is
another way to set force wake for GT read from spec. And also this
makes RC6 setting order
On 2011.03.21 10:36:01 -0700, Jesse Barnes wrote:
On Mon, 21 Mar 2011 17:27:13 +0800
Zhenyu Wang zhen...@linux.intel.com wrote:
we don't use it anywhere.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_suspend.c |4
1 files changed, 0
On 2011.03.21 10:39:54 -0700, Jesse Barnes wrote:
On Mon, 21 Mar 2011 17:27:14 +0800
Zhenyu Wang zhen...@linux.intel.com wrote:
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_suspend.c | 12
1 files changed, 4 insertions(+), 8 deletions
On 2011.03.21 10:46:53 -0700, Jesse Barnes wrote:
On Mon, 21 Mar 2011 17:27:18 +0800
Zhenyu Wang zhen...@linux.intel.com wrote:
Move RC6 enable after we reset rings for all regines, as RC6 on
Sandybridge would setup ring idle state, so I assume we should have
setup rings already.
So
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 21 -
1 files changed, 0 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 65dfe81..fe2a596 100644
--- a/drivers/gpu
It's cleaned before saving and re-initialized after restoring.
So don't need to save/restore it. And also new chip has new address
for hardware status page register, don't write to old address.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_suspend.c |6
On 2011.02.22 09:33:22 -0800, Eric Anholt wrote:
While I originally hacked it up this way where libdrm intuits what kind
of buffer it is from the name of the buffer, it's a bad way to design an
interface. We should really have a command that marks (an area) of a
buffer object as being a
Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
From 804328390488f76c1bda02cdf0a4081e55657ff9 Mon Sep 17 00:00:00 2001
From: Zhenyu Wang zhen...@linux.intel.com
Date: Tue, 22 Feb 2011 14:53:42 +0800
Subject: [PATCH] intel: Add AUB file dump support
This adds AUB
On 2011.02.15 17:41:20 +, Diego Celix wrote:
Hi!,
When I run the intel_audio_dump tool with my laptop (Core i5 Intel HD
Graphics) seems that it is not correctly fetching the data.
This is a piece of the source, in which the HAS_PCH_SPLIT macro is
called (Line 1197, intel_audio_dump.c)
AUB file is the input data for internal GenX GPU simulator,
which has been proved really helpful when debugging for new
GenX architecture. AUB file itself actually contains different
kinds of trace blocks for GPU execution, e.g batch/ring buffer,
surface states, pipeline FF states, etc.
This
This adds AUB file dump support to generate execution
trace for internal GPU simulator.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
intel/Makefile.am|3 +-
intel/intel_bufmgr.h | 38 +
intel/intel_bufmgr_gem.c | 402
New INTEL_DEBUG option to enable aub file dump with intel drm.
---
src/mesa/drivers/dri/intel/intel_context.c | 10 ++
src/mesa/drivers/dri/intel/intel_context.h |2 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c
On 2011.01.05 10:31:48 -0800, Jesse Barnes wrote:
eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
problems. So avoid FDI training and PCH PLL enabling in that case.
Right, I think that's what I did during early eDP enabling.
Yuanhan, please test this on sandybridge
On 2010.12.15 10:05:01 +, Chris Wilson wrote:
On Wed, 15 Dec 2010 11:14:53 +0800, Zhenyu Wang zhen...@linux.intel.com
wrote:
Chris, just notice you removed pipe control notify entirely on -next,
that seems wrong to me. In Ironlake time, we've seen interrupt stall issue
with user
Useful for debugging hang bug that not require GPU auto reset,
to grab INSTDONE bits and make aub dump life easy.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c |3 +++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c |2
On 2010.12.14 21:47:45 +, Chris Wilson wrote:
On Tue, 14 Dec 2010 20:59:09 +, david may david.ma...@ntlworld.com
wrote:
Hello Eric,
Tuesday, December 14, 2010, 5:58:58 PM, you wrote:
Why don't we just keep all of our BOs LLC cached? This was supposed to
be a big win of
On 2010.12.14 19:13:22 +0100, Daniel Vetter wrote:
On Tue, Dec 14, 2010 at 12:55:59PM +0800, Zhenyu Wang wrote:
It appears Sandybridge PIPE_CONTROL write out buffer need
to be set as cached, currently LLC cached, in order to read
back correct counter. Otherwise I can always be possible
Chris, just notice you removed pipe control notify entirely on -next,
that seems wrong to me. In Ironlake time, we've seen interrupt stall issue
with user interrupt, and be warned user interrupt is deprecated, so we moved
on to use pipe control notify, although there's a workaround later covered
Looks from a6963596a13e62f8e65b1cf3403a330ff2db407c, setting
GTT entry on i965-ish totally ignored cached memory flag?
That might break r/w consistent for pages like hw status.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Some BO is required to have cached attribute in GTT, e.g PIPE_CONTROL
store DW buffer used for occlusion query function. This one adds new
flags for that within bo create ioctl.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
drivers/gpu/drm
It appears Sandybridge PIPE_CONTROL write out buffer need
to be set as cached, currently LLC cached, in order to read
back correct counter. Otherwise I can always be possible to
get corrupted 64-bit PS_DEPTH_COUNT from PIPE_CONTROL write.
So below patches try to add new flag during bo create with
Use new interface for cached bo create for query object on Sandybridge,
which is required for PIPE_CONTROL store buffer to be CPU cacheable.
---
src/mesa/drivers/dri/i965/brw_queryobj.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git
On 2010.12.14 11:03:53 +0800, Zhenyu Wang wrote:
Looks from a6963596a13e62f8e65b1cf3403a330ff2db407c, setting
GTT entry on i965-ish totally ignored cached memory flag?
That might break r/w consistent for pages like hw status.
This should recover that.
From
Eric,
Looks the culprit for recent piglit regression on sandybridge
that caused hang is bisected to
commit 9effc1adf1e7ba57fb3b10909762b76c1ae12f61
Author: Eric Anholt e...@anholt.net
Date: Mon Oct 11 16:02:08 2010 -0700
i965: re-enable gen6 IF statements in the fragment shader.
IF
On 2010.11.29 11:02:26 -0800, Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/29/2010 12:52 AM, Zhenyu Wang wrote:
Looks the culprit for recent piglit regression on sandybridge
that caused hang is bisected to
Could you be more specific about the regression
On 2010.11.04 16:52:51 -0700, Carl Worth wrote:
Having the error there was to make sure people noticed and I
could find out just how many SNB revisions failed. I presume you have a
rev 8?
Yes, rev 8 here.
FYI, rev 9 desktop sandybridge doesn't show this issue so far.
It just reads back
On 2010.11.04 13:50:24 +0800, Zhenyu Wang wrote:
On 2010.11.04 02:23:46 +, Chris Wilson wrote:
On Tue, 2 Nov 2010 14:24:22 +0800, Zhenyu Wang zhen...@linux.intel.com
wrote:
I don't think transcoder bpc setting should matter, but sorry that I'm
short
of time to track down which
On 2010.10.29 09:52:31 +0100, Chris Wilson wrote:
On Fri, 29 Oct 2010 10:34:51 +0800, Zhenyu Wang zhen...@linux.intel.com
wrote:
On 2010.10.28 10:50:04 +0100, Chris Wilson wrote:
I've shrunk the patch to just the FDI portion, pushed to staging for
review.
Current drm-intel-staging
This is broken from 97ef1bdd0bc75bce7b2058e9c432b6c277dcf4d3.
Let's set the correct bit for LLC+MLC and LLC only.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/char/agp/intel-gtt.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/agp/intel
to the original behavior now.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/char/agp/intel-gtt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 125cd0b..9272c38 100644
--- a/drivers/char/agp/intel-gtt.c
for uncached binding.
This is based on review and comment from Chris Wilson.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 20
drivers/gpu/drm/i915/intel_display.c | 10 ++
3
We should enable FDI normal training on Sandybridge/CPT system
as well. Also restore back some original register posting read
that got removed. LVDS/VGA/HDMI seems back to life but DP still
fails.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1
On 2010.10.28 10:50:04 +0100, Chris Wilson wrote:
The POSTING_READs you added are no-ops since they are all followed by a
read. The transconf should have the bpc in the register at this point or
else we should have bugged much earlier. The break-exec-wait condition is
still documented for
Display engine on Sandybridge is not coherent with LLC, so
try to always bind display buffer as uncached on Sandybridge.
This fixed screen artifacts seen by using blit engine on Sandybridge.
Cc: stable team sta...@kernel.org
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm
In i2c GPIO fallback, index 6 is reserved for nothing.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/intel_i2c.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index
On 2010.10.13 09:00:37 -0700, Jesse Barnes wrote:
So this gets the display working again with current bits?
No, these two are the fixes coming out during my bisect, as
it looks we have multiple regression commits...
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
include/drm/i915_drm.h |2 ++
intel/intel_bufmgr_gem.c | 12 +---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 7594413..694fb24 100644
--- a/include/drm
On 2010.10.01 22:27:45 +0200, Seblu wrote:
On Fri, Oct 1, 2010 at 3:22 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Fri, 1 Oct 2010 12:55:56 + (UTC), Seblu se...@seblu.net wrote:
I've the same kind trouble with -rc6 and my dell e6410. When module i915 is
loaded screen become
On 2010.09.28 23:13:07 +0100, Chris Wilson wrote:
Just a reminder that I am in the process of checking through -next for any
major outstanding issues before sending it off to Dave Airlie. If you have
any code for 2.6.37 that you have not yet sent to the list, you are
running out of time.
No
to test this set. We got correct DP sound on Eizo EV2333W, and HDMI
audio also worked with no regression found.
Patch is against Chris's drm-intel-next branch.
thanks.
Zhenyu Wang (4):
drm/edid: add helper function to detect monitor audio capability
drm/i915: Enable DisplayPort audio
drm
To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.
Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm
This will turn on DP audio output by checking monitor's audio
capability.
Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 61 +++
1 files changed, 36 insertions(+), 25
Rely on monitor's audio capability to turn on audio output for HDMI.
Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers
On 2010.09.19 08:38:07 +0100, Chris Wilson wrote:
This should be cc'ed for Adam Jackson's attention as well.
yep, I think I cc-ed ajax in git-send-mail command line...I'll amend the commit.
+bool drm_detect_monitor_audio(struct edid *edid)
drm_edid_has_monitor_audio()? That is a little
On 2010.09.16 14:31:31 +0800, Zhenyu Wang wrote:
This will turn on DP audio output by checking monitor's audio
capability.
oops, please ignore this one. Check EDID data after it's already
freed...
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c
To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.
Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm
This will turn on DP audio output by checking monitor's audio
capability.
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915
Rely on monitor's audio capability to turn on audio output for HDMI.
Tested-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Zhenyu Wang zhen...@linux.intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers
On 2010.09.16 15:59:29 +0800, Yuanhan Liu wrote:
Sandybridge uses different address offset(0x10) for fence table registers,
so make sure we save the right fence registers before suspend.
This would fix bug: https://bugs.freedesktop.org/show_bug.cgi?id=30199
Nice catch! But fence reg
On 2010.09.16 10:43:12 +0800, Xiang, Haihao wrote:
This is prepared for video codec ring buffer on Sandybridge. It is
needed to read/write more than one register to move the tail pointer of
the video codec ring on Sandybridge.
Do we really need new 'set_tail'? Isn't advance_ring used for set
On 2010.09.16 13:10:29 +0800, Xiang, Haihao wrote:
Or can't that be done in init function by using advance_ring?
advance_ring uses ring-tail to set TAIL register, i965_reset() also
invokes ring-init() to re-init ring buffer, how to guarantee ring-tail
is 0? BTW advance_ring can be implemented
On 2010.09.03 09:57:37 +0800, Xiang, Haihao wrote:
If I'm not completely mistaken, all these ringbuffer register have the
same offsets over a common base: 0x02000 for the render ring, 0x04000 for
bsd on gen5, 0x12000 for bsd on gen6.
Some registers (e.g. HSW_PGA) don't follow this rule.
601 - 700 of 734 matches
Mail list logo
