Hello Experts,
I have Intel D2700DC board with Cedarview Atom and GMA 3650. It seems that some
support for GMA36xx was added to Linux kernel in 3.3.x but I cannot make it
work. Here is all information I managed to gather:
kernel:3.3.5
xf86-video-intel:2.18.0
libva:1.0.15
intel-vaapi-driver:1.0.
On 05/11/2012 05:54 PM, Ben Widawsky wrote:
Insert a wait parameter in the code so we can possibly timeout on a
seqno wait if need be. The code should be functionally the same as
before because all the callers will continue to retry if an arbitrary
timeout elapses.
We'd like to have nanosecond g
On 05/11/2012 05:54 PM, Ben Widawsky wrote:
@@ -1800,6 +1800,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_COLORKEY, intel_sprite_set_colorkey,
On 05/11/2012 05:54 PM, Ben Widawsky wrote:
Wait request is poorly named IMO. After working with these functions for
some time, I feel it's much clearer to name the functions more
appropriately.
Of course we must update the callers to use the new name as well.
This leaves room within our namesp
On 05/11/2012 04:48 PM, Paulo Zanoni wrote:
From: Paulo Zanoni
- Changed the coding style of auxiliary infoframe functions to make
them smaller
- Fixed the column alignment of some function definitions
- Remove definition of "struct drm_crtc" in some places as they're
used only to retrieve
On 05/11/2012 04:48 PM, Paulo Zanoni wrote:
From: Paulo Zanoni
Both the control and data registers are completely different now.
Signed-off-by: Paulo Zanoni
Haswell for the win! :)
Just some comments below, but nothing too critical.
+static u32 hsw_infoframe_enable(struct dip_infoframe *fr
Assures that signals interrupting the wait works properly. Because of
the scheduling around signals, interrupted waits will *seem* faster as
the GPU continues to work while all the CPU scheduling stuff happens.
Signed-off-by: Ben Widawsky
---
tests/Makefile.am |3 +
tests/gem_w
drm_intel_gem_bo_wait(bo, &timeout in ns)
Signed-off-by: Ben Widawsky
---
include/drm/i915_drm.h | 10 ++
intel/intel_bufmgr.h |1 +
intel/intel_bufmgr_gem.c | 26 ++
3 files changed, 37 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/dr
This helps implement GL_ARB_sync but stops short of allowing full blown
sync objects. Finally we can use the new timed seqno waiting function
to allow userspace to wait on a buffer object with a timeout. This
implements that interface.
The IOCTL will take as input a buffer object handle, and a tim
Wait request is poorly named IMO. After working with these functions for
some time, I feel it's much clearer to name the functions more
appropriately.
Of course we must update the callers to use the new name as well.
This leaves room within our namespace for a *real* wait request function
at some
The trace events adds whether or not the wait was blocking. Blocking in
this case means to hold struct_mutex (ie. no new work can be submitted
during the wait). The information is inherently racy.
The blocking information is racy since mutex_is_locked doesn't check
that the current thread holds th
Insert a wait parameter in the code so we can possibly timeout on a
seqno wait if need be. The code should be functionally the same as
before because all the callers will continue to retry if an arbitrary
timeout elapses.
We'd like to have nanosecond granularity, but the only way to do this is
wit
On Fri, 11 May 2012 12:58:14 -0700, Ben Widawsky wrote:
> On Fri, 11 May 2012 14:29:32 +0100
> Chris Wilson wrote:
>
> > When userspace asks whether the driver supports the BLT or BSD rings for
> > this chip, simply report whether those particular rings are initialised
> >
>
> This was the one
On Fri, 11 May 2012 14:29:32 +0100
Chris Wilson wrote:
> When userspace asks whether the driver supports the BLT or BSD rings for
> this chip, simply report whether those particular rings are initialised
>
This was the one place where I felt HAS_BLT and HAS_BSD was sort of
nice to keep around t
On Fri, 11 May 2012 14:29:31 +0100
Chris Wilson wrote:
> Rather than use the magic feature tests HAS_BLT/HAS_BSD just check
> whether the ring we are about to dispatch the execbuffer on is
> initialised.
>
> v2: Use intel_ring_initialized()
>
> Signed-off-by: Chris Wilson
Reviewed-by: Ben Wida
From: Paulo Zanoni
- Changed the coding style of auxiliary infoframe functions to make
them smaller
- Fixed the column alignment of some function definitions
- Remove definition of "struct drm_crtc" in some places as they're
used only to retrieve "struct intel_crtc"
Signed-off-by: Paulo Zano
From: Paulo Zanoni
Both the control and data registers are completely different now.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h |4 +++
drivers/gpu/drm/i915/intel_hdmi.c | 68 +
2 files changed, 66 insertions(+), 6 deletions(-)
On Fri, 11 May 2012 14:29:30 +0100
Chris Wilson wrote:
> In many places we wish to iterate over the rings associated with the
> GPU, so refactor them to use a common macro.
>
> Along the way, there are a few code removals that should be side-effect
> free and some rearrangement which should only
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 19 +--
drivers/gpu/drm/i915/i915_reg.h | 11 ---
drivers/gpu/drm/i915/intel_sdvo.c | 17 +
3 files changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i91
Similar to g4x_dp_detect() we should probe the PORT_HOTPLUG_STATUS as to
whether the connector is active prior to attempting to retrieve the EDID.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_hdmi.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/
The status bits corresponding to the interrupt enable bits are the
"live" hotplug status bits, and reflect the current status of the port
(high for a detected connection, low for a disconnect). The actual bits
corresponding to the interrupt source are elsewhere. The actual event is
then determined
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_dp.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5341a57..aa9262c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/
Also as we set the HOTPLUG_EN to 0 during pre-install, we can simply set
it during post-install, and nor do we wish to enable unwanted hotplug
events.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 75 ---
1 file changed, 31 insertions(+),
Rather than use the magic feature tests HAS_BLT/HAS_BSD just check
whether the ring we are about to dispatch the execbuffer on is
initialised.
v2: Use intel_ring_initialized()
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +
1 file changed, 5 inse
In many places we wish to iterate over the rings associated with the
GPU, so refactor them to use a common macro.
Along the way, there are a few code removals that should be side-effect
free and some rearrangement which should only have a cosmetic impact,
such as error-state.
v2: Pull in a couple
When userspace asks whether the driver supports the BLT or BSD rings for
this chip, simply report whether those particular rings are initialised
v2: Use intel_ring_initialized()
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c |4 ++--
1 file changed, 2 insertions(+), 2 delet
On Thu, May 10, 2012 at 11:37 PM, 袁竞杰 wrote:
> **
> System environment:
>
> xf86-video-intel:2.17.0
> intel-driver(for vaapi):1.0.15
> libva:1.0.15
> libdrm:2.4.32
> xserver:11.0
> Mesa:8.0.2
> kernel version:3.3.4
> system: ubuntu 12.04
> VGA:intel Ivy Bridge Graphics Controller
>
> Bug descript
On Fri, 11 May 2012 11:00:12 +0200, Daniel Vetter wrote:
> On Thu, May 10, 2012 at 03:39:32PM -0700, Ben Widawsky wrote:
> > Sneaky way to get rid of the warning you never liked... I won't forget
> > this.
>
> I concur that killing that warnings is sneaky ;-) Can't we just keep them
> - the ring-
Hi, perhaps one of the experts can answer this in a few words...
SandyBridge can prevent tearing only by using pageflipping.
pageflipping on Xorg always flips the whole framebuffer, so it can only
be synced to one output device.
The vaapi-enabled MPlayer plays nice in fullscreen mode (via vaa
On Thu, May 10, 2012 at 11:21:25PM +0100, Chris Wilson wrote:
> Rather than use the magic feature tests HAS_BLT/HAS_BSD just check
> whether the ring we are about to dispatch the execbuffer on is
> initialised.
>
> Signed-off-by: Chris Wilson
I like these two, but I think with the intel_ring_ini
On Thu, May 10, 2012 at 03:39:32PM -0700, Ben Widawsky wrote:
> On Thu, 10 May 2012 22:21:50 +0100
> Chris Wilson wrote:
>
> > In many places we wish to iterate over the rings associated with the
> > GPU, so refactor them to use a common macro.
> >
> > Along the way, there are a few code removal
Cc: Jesse Barnes
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8d55dc9..12dba60 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
32 matches
Mail list logo
