Hallo all,
I was not testing intel drm git for some moths now,
what is the actual current correct git?
This one seems to be down:
http://git.kernel.org/?p=linux/kernel/git/keithp/linux-2.6.git;a=summary
Regards,
Alexey
___
Intel-gfx mailing list
Intel
On Wed, 2011-10-12 at 14:09 +1100, Bojan Smojver wrote:
> Bug #41705.
Just to follow up on this a bit, I cloned Linus' tree as of today (i.e.
currently staged stuff for 3.2) then pulled Keith's tree
(git://people.freedesktop.org/~keithp/linux drm-intel-next) over the top
and compiled. Did 26 hiber
Hi, could I get some feedback on this patch, please?
Simon
On Fri, Oct 14, 2011 at 4:46 PM, Simon Que 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 defined in a separa
From: Duncan Laurie
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.
Signed-off-by: Duncan Laurie
BUG
On Tue, Oct 25, 2011 at 11:43:09AM -0500, Rob Clark wrote:
> On Tue, Oct 25, 2011 at 9:09 AM, Jesse Barnes
> 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
> > @@ -272,8 +2
On Tue, 25 Oct 2011 12:25:45 -0400, Adam Jackson 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 someone does mana
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 D
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 b/drivers/gpu/dr
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
> > d
On Tue, 25 Oct 2011 14:26:07 +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 t
On Tue, 25 Oct 2011 13:58:55 +0200
Daniel Vetter 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.
> >
> > Signe
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
As discussed with Jesse on irc, drm fb handli
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 Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing
From 13efc0a405d522aad8250fce2dbd05fefb8b8ab0 Mon Sep 17 00:00:00 2001
From: Jesse Barnes
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 as well. So add support
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
---
drivers/gpu/drm/i915/Makef
On Tue, 25 Oct 2011 11:46:55 +0200
Jesse Barnes 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 fixed all the remaini
On Tue, 25 Oct 2011 19:53:02 +0900
Joonyoung Shim 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 object
>
On Tue, 25 Oct 2011 19:47:13 +0900
Joonyoung Shim 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, and it sounds li
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
---
drivers/gpu/drm/i915/intel_overlay2.c | 12 +++-
1 files changed, 11
If the source and destination size are different, try to scale the sprite on the
corresponding CRTC.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_overlay2.c | 14 --
2 files changed, 17 insertions(+), 2 deletions(-)
Split things out a little and add the IVB reg definitions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h | 59
drivers/gpu/drm/i915/intel_overlay2.c | 168 ++--
2 files changed, 216 insertions(+), 11 deletions(-)
diff --git a/d
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
---
drivers/gpu/drm/i915/intel_overlay2.c | 27 ++-
1 files chang
Make sure the object exists (it may not if the plane was previously disabled)
and make sure we zero it out in the disable path to avoid trouble later.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_overlay2.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git
---
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
+++ b/drivers/gpu/drm/i9
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.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52
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
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |
This avoids the need to unpin on the error path.
Signed-off-by: Jesse Barnes
---
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
b/drivers/gpu/drm/i915/intel_overlay2.c
index 2e38b15..e583
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
---
drivers/gpu/drm/drm_crtc.c
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
---
drivers/gpu/drm/drm_crtc.c | 236 +++-
drivers/gpu/drm/drm_drv.c |3
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 w
On Tue, Oct 25, 2011 at 09:15:58AM +0200, Jesse Barnes wrote:
> On Mon, 24 Oct 2011 19:43:44 -0700
> Kenneth Graunke 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 commit fixe
On Mon, 24 Oct 2011 19:43:44 -0700
Kenneth Graunke 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 commit fixes the hang:
>
> commit 3cc0a7be23ab603ed40d602595f673a44e079885
> Author: Kenne
32 matches
Mail list logo
