On Tue, Oct 25, 2011 at 09:15:58AM +0200, Jesse Barnes wrote:
On Mon, 24 Oct 2011 19:43:44 -0700
Kenneth Graunke kenn...@whitecape.org wrote:
On 10/24/2011 05:58 PM, James R. Leu wrote:
Debug output attached
You're in luck! I fixed this GPU hang today in Mesa master.
This
I've given up waiting for someone to implement support for these ioctls
on another platform before they're merged, but I have received a lot of
feedback on the interfaces, and it sounds like they're ok. I've also
fixed all the remaining issues I'm aware of on SNB platforms and things
are working
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/drm_crtc.c | 236 +++-
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
This avoids the need to unpin on the error path.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_overlay2.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay2.c
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4f599ce..cd7e04d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
To avoid the object being destroyed before our disable hook is called,
take a private reference on it. This will guarantee that we can still
access the object at disable time.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_overlay2.c | 27
Split things out a little and add the IVB reg definitions.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h | 59
drivers/gpu/drm/i915/intel_overlay2.c | 168 ++--
2 files changed, 216 insertions(+), 11
If we try to scan a sprite outside of the parent CRTC area, the display
engine will underflow and potentially blank the framebuffer. So clamp
the position + size to the viewable area.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_overlay2.c | 12
On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shim jy0922.s...@samsung.com wrote:
10/25/2011 06:46 PM, Jesse Barnes 쓴 글:
I've given up waiting for someone to implement support for these
ioctls on another platform before they're merged, but I have
received a lot of feedback on the interfaces,
On Tue, 25 Oct 2011 19:53:02 +0900
Joonyoung Shim jy0922.s...@samsung.com wrote:
+/**
+ * drm_plane - central DRM plane control structure
+ * @dev: DRM device this plane belongs to
+ * @kdev: kernel device
+ * @attr: kdev attributes
+ * @head: for list management
+ * @base: base mode
On Tue, 25 Oct 2011 11:46:55 +0200
Jesse Barnes jbar...@virtuousgeek.org wrote:
I've given up waiting for someone to implement support for these
ioctls on another platform before they're merged, but I have received
a lot of feedback on the interfaces, and it sounds like they're ok.
I've also
The video sprites support various video surface formats natively and can
handle scaling as well. So add support for them using the new DRM core
overlay support functions.
v2: collapse patches and fix plane disable vs unpin ordering bug
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
From 13efc0a405d522aad8250fce2dbd05fefb8b8ab0 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Fri, 22 Apr 2011 14:55:33 -0700
Subject: [PATCH] drm/i915: add SNB video sprite support
The video sprites support various video surface formats natively and can
handle scaling
Maybe add your nice example from the series intro to the commit msg to
show how this is supposed to be used. Otherwise for both patches:
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
As discussed with Jesse
On Tue, 25 Oct 2011 13:58:55 +0200
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Oct 25, 2011 at 11:46:56AM +0200, Jesse Barnes wrote:
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the
core KMS code.
On Tue, 25 Oct 2011 14:26:07 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
As discussed with Jesse on irc, drm fb handling is fragile. Current
rules:
- fbs are not reference counted, hence when destroying we need to
disable all crtcs (and now also planes) that use them.
On Tue, Oct 25, 2011 at 02:26:07PM +0100, Alan Cox wrote:
As discussed with Jesse on irc, drm fb handling is fragile. Current rules:
- fbs are not reference counted, hence when destroying we need to disable
all crtcs (and now also planes) that use them. drm_framebuffer_cleanup
does
Here's a diff I can roll in if it looks ok. It adds the ability to
specify multiple handles for a single fb to better accommodate planar
configs. I think Rob has convinced me that this is a good idea...
comments appreciated.
Thanks,
Jesse
diff --git a/drivers/gpu/drm/drm_crtc.c
On Mon, 2011-10-10 at 16:33 -0400, Adam Jackson wrote:
This fixes a rather irritating limitation of active dp-foo converters.
Many such (including all DP-VGA chips I can find on the market) come
equipped with only 2 DP lanes, which clips your dotclock to 144MHz at
8bpc. Of the standard DMT
On Tue, 25 Oct 2011 12:25:45 -0400, Adam Jackson a...@redhat.com wrote:
I can respin patch 2 if there's still interest, but it might be
difficult to find a monitor to test against. Patch 1 is still valid
though.
I've applied patch 1. I don't have a monitor to test patch 2 against, so
if
On Tue, Oct 25, 2011 at 11:43:09AM -0500, Rob Clark wrote:
On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 34a0d22..dafe8df 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
From: Duncan Laurie dlau...@chromium.org
This is the method used to override LVDS in intel_lvds and appears to be
an effective way to ensure that the driver does not enable VGA hotplug.
This is the same patch from 2.6.32 kernel in R12 but ported to 2.6.38,
will send upstream next.
Hi, could I get some feedback on this patch, please?
Simon
On Fri, Oct 14, 2011 at 4:46 PM, Simon Que s...@chromium.org wrote:
In the native backlight driver, use 4096 (0x1000) as the default backlight
period, and use the period as the default max brightness.
The default brightness is
26 matches
Mail list logo
