Hi folks，
During the last discussion about glamor’s plan in this list, we got a
conclusion that to extract glamor from xorg and
build a separate glamor library to be used by any possible DDX driver. And
Eric suggested I can incrementally
merge glamor into Intel video driver. Now here is the
Added one configuration option --enable-glamor to control
whether use glamor. Added one new file intel_glamor.c to
wrap glamor egl API for intel driver's usage.
This commit doesn't really change the driver's control path.
It just adds necessary files for glamor and change some
configuration.
If GLAMOR is enabled, we route UXA's fillspans and
polyfillrects to glamor by default. And if glamor
fail to accelerate it, UXA continue to handle it.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
uxa/uxa-accel.c | 13 -
1 files changed, 12 insertions(+), 1
At Fri, 11 Nov 2011 16:22:41 +0800,
Wu Fengguang wrote:
On Fri, Nov 11, 2011 at 03:40:37PM +0800, Takashi Iwai wrote:
At Fri, 11 Nov 2011 10:29:25 +0800,
Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 10:28:19PM +0800, Takashi Iwai wrote:
At Thu, 10 Nov 2011 21:51:50 +0800,
Wu
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.
yeah, mode_set() will only be in normal mode setting path
On Fri, 11 Nov 2011 16:31:21 +0800, Zhigang Gong zhigang.g...@linux.intel.com
wrote:
If GLAMOR is enabled, we route UXA's fillspans and
polyfillrects to glamor by default. And if glamor
fail to accelerate it, UXA continue to handle it.
How is serialisation handled between the UXA and glamor
On Fri, 11 Nov 2011 16:31:20 +0800, Zhigang Gong zhigang.g...@linux.intel.com
wrote:
@@ -965,6 +969,9 @@ void intel_uxa_block_handler(intel_screen_private *intel)
* framebuffer until significantly later.
*/
intel_flush_rendering(intel);
+#ifdef GLAMOR
+
On Fri, Nov 11, 2011 at 04:49:57PM +0800, Takashi Iwai wrote:
At Fri, 11 Nov 2011 16:22:41 +0800,
Wu Fengguang wrote:
On Fri, Nov 11, 2011 at 03:40:37PM +0800, Takashi Iwai wrote:
At Fri, 11 Nov 2011 10:29:25 +0800,
Wu Fengguang wrote:
On Thu, Nov 10, 2011 at 10:28:19PM
At Fri, 11 Nov 2011 17:24:21 +0800,
Wu Fengguang wrote:
On Fri, Nov 11, 2011 at 04:49:57PM +0800, Takashi Iwai wrote:
At Fri, 11 Nov 2011 16:22:41 +0800,
Wu Fengguang wrote:
On Fri, Nov 11, 2011 at 03:40:37PM +0800, Takashi Iwai wrote:
At Fri, 11 Nov 2011 10:29:25 +0800,
Wu
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, November 11, 2011 5:08 PM
To: Zhigang Gong; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 3/3] glamor: Route fillspans and
polyfillrects
to glamor.
On Fri, 11 Nov 2011 16:31:21
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, November 11, 2011 5:12 PM
To: Zhigang Gong; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/3] glamor: turn on glamor.
On Fri, 11 Nov 2011 16:31:20 +0800, Zhigang Gong
At Fri, 11 Nov 2011 19:12:57 +0800,
Wu Fengguang wrote:
(snip)
One note that we don't rely on PD bit because not all (non-Intel)
hardware report it correctly.
Oops. Do you imply ELDV is reliable on all platforms? ;-)
Oh hell, no :)
The driver tries to probe explicitly via
On Fri, Nov 11, 2011 at 07:23:05PM +0800, Takashi Iwai wrote:
At Fri, 11 Nov 2011 19:12:57 +0800,
Wu Fengguang wrote:
(snip)
One note that we don't rely on PD bit because not all (non-Intel)
hardware report it correctly.
Oops. Do you imply ELDV is reliable on all
On Fri, Nov 11, 2011 at 06:31, Zhigang Gong zhigang.g...@linux.intel.comwrote:
Added one configuration option --enable-glamor to control
whether use glamor. Added one new file intel_glamor.c to
wrap glamor egl API for intel driver's usage.
This commit doesn't really change the driver's
On Fri, Nov 11, 2011 at 06:31, Zhigang Gong zhigang.g...@linux.intel.comwrote:
@@ -1109,7 +1127,8 @@ static void I830FreeScreen(int scrnIndex, int flags)
{
ScrnInfoPtr scrn = xf86Screens[scrnIndex];
intel_screen_private *intel = intel_get_screen_private(scrn);
-
+#ifdef
On Fri, 11 Nov 2011 18:52:11 +0800, Zhigang Gong
zhigang.g...@linux.intel.com wrote:
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, November 11, 2011 5:12 PM
To: Zhigang Gong; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx]
On Fri, 2011-11-11 at 14:48 +0100, Joerg Roedel wrote:
+#define intel_iommu_gfx_mapped 1
That ought to be zero; if the IOMMU code isn't present, it's
*definitely* not mapped through the IOMMU :)
But I'm fairly sure this was already noticed and a patch is on its way
upstream already.
It's my
On Thu, 10 Nov 2011 10:51:26 -0200
Eugeni Dodonov eugeni.dodo...@intel.com wrote:
This prevents an in-kernel division by zero which happens when we are
asking for i915_chipset_val too quickly, or within a race condition
between the power monitoring thread and userspace accesses via debugfs.
On 11/10/11 9:12 AM, Paulo J. Matos wrote:
Hi,
I got a new PC DELL Vostro 360. This is an all-in-one which uses the
Optimus setup. An intel GT1 (Sandybridge) couples with an Nvidia 525m.
Ubuntu out of the box shows a black screen unless I add nomodeset to
kernel options.
One of the things I
On Thu, 10 Nov 2011 14:18:07 +0100, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
We have to do this manually. Somebody had a Great Idea.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
People playing with this when not strictly required is scary to me.
Manually swizzling was a world of
On Fri, 11 Nov 2011 18:22:25 +0100, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Nov 11, 2011 at 08:50:30AM -0800, Eric Anholt wrote:
On Thu, 10 Nov 2011 14:18:07 +0100, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
We have to do this manually. Somebody had a Great Idea.
On Fri, 11 Nov 2011 20:51:35 +0100, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Nov 11, 2011 at 20:37, Eric Anholt e...@anholt.net wrote:
I was assuming you were working on this because you were planning on
building something that *used* this swizzling. We removed all the
userland because
After checking the specs and discussing with Jesse, turns out CxSR is not
available on Ironlake and gen5, and its advertisement on the device
description is misleading.
Acked-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
On Fri, Nov 11, 2011 at 20:58, Eric Anholt e...@anholt.net wrote:
Oh, yeah, swap. Good point, sounds like a plan. If you manage to get
reliable swapping of tiled data on 945g, I'll owe you all the beers.
If you mean i945G as in desktop variant, patch 6/9 should fix the
swizzle detection on
On Mon, 19 Sep 2011 21:04:36 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 29 Aug 2011 09:45:28 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
With patch...
It's been a couple of weeks; this patch is ready to merge, yes? Is there
a commit message somewhere?
Yeah higher up
Hi,
A collection of nits below.
Thanks,
-Olof
On Thu, Nov 10, 2011 at 07:48:55PM -0800, Simon Que wrote:
If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz. This is determined using the following
formula:
freq = refclk / (128 *
If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz. This is determined using the following
formula:
freq = refclk / (128 * pwm_max)
The PWM register allows the max PWM value to be set. So we want to use
the formula, where freq = 200:
If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz. This is determined using the following
formula:
freq = refclk / (128 * pwm_max)
The PWM register allows the max PWM value to be set. So we want to use
the formula, where freq = 200:
On Fri, Nov 11, 2011 at 02:12:58PM -0800, Simon Que wrote:
If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz. This is determined using the following
formula:
freq = refclk / (128 * pwm_max)
The PWM register allows the max PWM value
On Fri, Nov 11, 2011 at 02:17:20PM -0800, Olof Johansson wrote:
On Fri, Nov 11, 2011 at 02:12:58PM -0800, Simon Que wrote:
If the firmware did not initialize the backlight PWM registers, set up a
default PWM frequency of 200 Hz. This is determined using the following
formula:
freq =
(snip)
And I'm not sure whether HDMI audio is played
while DPMS is off. I haven't tested it.
It will go silence on DPMS. I noticed this while doing long term HDMI
audio playback tests. This should better be fixed in future on the
graphics side.
Hm, but I wonder
A bunch of cleanups, fixes and new fields to intel_audio_dump, tested OK on
G45, Ironlake and IvyBridge.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
11:00:39.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c
Convert  (Hex 00ad) to - (Hex 2d), the former leads to ugly outputs
in some situations.
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c | 70 ++---
1 file changed, 35 insertions(+), 35 deletions(-)
---
The raw channel count is not user friendly and may be misleading.
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-09
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-09
10:35:34.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2011-11-09
- no need to show the 1-bit AUD_OUT_DIG_CNVT_* as hex value
- show the Connection_select_Control_* bits as hex values
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
---
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-09
10:35:35.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2011-11-09
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-09
10:35:34.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2011-11-09
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c | 47 +
1 file changed, 27 insertions(+), 20 deletions(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
10:19:06.0 +0800
+++
The original test mistakenly calls dump_cpt() for Ironlake,
due to HAS_PCH_SPLIT := IS_GEN5 || IS_GEN6 || IS_GEN7.
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |8
1 file changed, 8 insertions(+)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
10:52:47.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2011-11-12
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |2 ++
1 file changed, 2 insertions(+)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
10:52:48.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2011-11-12 10:52:48.0
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
10:52:50.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2011-11-12
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |4
1 file changed, 4 insertions(+)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
10:52:50.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2011-11-12 10:52:50.0
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
10:52:46.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
10:52:39.0 +0800
+++
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c | 47 +
1 file changed, 47 insertions(+)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
11:11:41.0 +0800
+++
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c | 18 ++
1 file changed, 18 insertions(+)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
10:52:49.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c2011-11-12
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
tools/intel_audio_dump.c | 30 ++
1 file changed, 30 insertions(+)
--- intel-gpu-tools.orig/tools/intel_audio_dump.c 2011-11-12
10:52:40.0 +0800
+++ intel-gpu-tools/tools/intel_audio_dump.c
Am Samstag, den 12.11.2011, 11:12 +0800 schrieb Wu Fengguang:
A bunch of cleanups, fixes and new fields to intel_audio_dump, tested OK on
G45, Ironlake and IvyBridge.
Christopher White mentioned some lacks in the documentation like missing
dependencies. Could you update that too, please?
Am Samstag, den 12.11.2011, 11:12 +0800 schrieb Wu Fengguang:
A bunch of cleanups, fixes and new fields to intel_audio_dump, tested OK on
G45, Ironlake and IvyBridge.
Christopher White mentioned the last release or tag happened a long time
ago.
Is a new release planned? Most of the time
52 matches
Mail list logo
