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
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
---
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
+++
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
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
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
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
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
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
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
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 +++-
drivers
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
b/drivers/gpu/drm/i915
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
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 jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm
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 jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_overlay2.c |6 ++
1 files changed, 6 insertions(+), 0
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
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
If the source and destination size are different, try to scale the sprite on the
corresponding CRTC.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_overlay2.c | 14 --
2 files changed, 17
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 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
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.
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 Thu, 15 Sep 2011 01:31:00 +0200
Mario Kleiner wrote:
> On Sep 15, 2011, at 12:54 AM, Francisco Jerez wrote:
>
> > Mario Kleiner writes:
> >
> >> On Sep 14, 2011, at 6:02 PM, Keith Packard wrote:
> >>
> >>> On Wed, 14 Sep 2011 10:05:29 -0500, J
into this. cc'ing dri-devel, all that was said is in this
mail.
What's the latest here? I still think we need the swap limit API...
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel
On Mon, 03 Oct 2011 16:18:48 -0700
Keith Packard wrote:
> On Mon, 3 Oct 2011 14:14:23 -0700, Jesse Barnes
> wrote:
>
> > Now... is keeping the various refclks enabled costing us any power?
> > IOW, should we be trying to disable them when everything has been
> >
ning things, but I believe patch 7
> includes whitespace errors.
Yay excellent.
Now... is keeping the various refclks enabled costing us any power?
IOW, should we be trying to disable them when everything has been
DPMS'd off too?
--
Jesse Barnes, Intel Open Source Technology Center
id you get confirmation that the
"wavy VGA" bug was fixed with this series? Overall seems like a good
improvement over our old PCH refclk code...
--
Jesse Barnes, Intel Open Source Technology Center
s pretty much the
> same as people are getting under Mac OS.
As long as you enable RC6. :)
--
Jesse Barnes, Intel Open Source Technology Center
> /* Returns true if the panel was already on when called */
> -static bool ironlake_edp_panel_on (struct intel_dp *intel_dp)
> +static void ironlake_edp_panel_on (struct intel_dp *intel_dp)
> {
Remove the comment too?
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, 29 Sep 2011 18:09:42 -0700
Keith Packard wrote:
> Talking to the eDP DDC channel requires that the panel be powered
> up. Wrap both the EDID and modes fetch code with calls to turn the vdd
> power on and back off.
>
These VDD AUX changes look good, ack on all of them.
--
pp_status,
> + I915_READ(PCH_PP_CONTROL));
> + }
> +}
I'd call it "intel_dp_assert_dp_power" or something more descriptive
(or just assert_panel_power to match the other asserts in
intel_display.c), but other than that this is a nice sanity check.
--
Jesse Barnes, Intel Open Source Technology Center
tarts and use that if present. But, that might mean that
> you'd get different modes depending on whether the machine booted with
> the lid closed or open, which seems like a bad plan.
More than that, I think eDP *requires* an EDID, and it sounds like even
the Air has one (and if any machine didn
dresses
> for PCH regs ...
> Reviewed-by: Daniel Vetter
Yep, I like it too:
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
...
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Yep, I like it too:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
(or just assert_panel_power to match the other asserts in
intel_display.c), but other than that this is a nice sanity check.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
On Tue, 20 Sep 2011 21:51:33 -0700
Keith Packard wrote:
> Yes, making it cleaner would help a ton. There are some basic problems
> with the DRM API that make this hard though -- intel_dp_prepare may
> not ever be followed by a call to intel_dp_commit. That's why I had
> the VDD AUX stuff get
On Tue, 20 Sep 2011 21:45:54 -0700
Keith Packard wrote:
> On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes
> wrote:
>
> > This one mixes up lots of cleanups plus the EDID read with the power
> > changes.
>
> I think the cleanups are;
>
> 1) edp checks
On Tue, 20 Sep 2011 21:45:54 -0700
Keith Packard kei...@keithp.com wrote:
On Wed, 21 Sep 2011 09:20:01 +0530, Jesse Barnes
jbar...@virtuousgeek.org wrote:
This one mixes up lots of cleanups plus the EDID read with the power
changes.
I think the cleanups are;
1) edp checks inside
On Tue, 20 Sep 2011 21:51:33 -0700
Keith Packard kei...@keithp.com wrote:
Yes, making it cleaner would help a ton. There are some basic problems
with the DRM API that make this hard though -- intel_dp_prepare may
not ever be followed by a call to intel_dp_commit. That's why I had
the VDD AUX
On Mon, 19 Sep 2011 15:22:03 -0700
Keith Packard wrote:
> There's no good reason to turn off the eDP force VDD bit synchronously
> while probing devices; that just sticks a huge delay into all mode
> setting paths. Instead, queue a delayed work proc to disable the VDD
> force bit and then
On Mon, 19 Sep 2011 15:22:00 -0700
Keith Packard wrote:
> The eDP panel may not be able to respond to aux channel communications
> unless it has power supplied. During mode setting, power may be
> cut-off during panel power sequencing. Make sure that any aux channel
> communications will work by
On Mon, 19 Sep 2011 15:22:00 -0700
Keith Packard kei...@keithp.com wrote:
The eDP panel may not be able to respond to aux channel communications
unless it has power supplied. During mode setting, power may be
cut-off during panel power sequencing. Make sure that any aux channel
communications
On Mon, 19 Sep 2011 15:22:03 -0700
Keith Packard kei...@keithp.com wrote:
There's no good reason to turn off the eDP force VDD bit synchronously
while probing devices; that just sticks a huge delay into all mode
setting paths. Instead, queue a delayed work proc to disable the VDD
force bit
NTROL;
Hah yeah that's a good one, thanks for the fix.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
for the fix.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, 08 Aug 2011 13:24:12 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes
> wrote:
> > On Mon, 08 Aug 2011 12:53:31 -0700
> > Keith Packard wrote:
> >
> > > On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes > > virtuousge
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
> wrote:
>
> > Yep, it's safe and possible to do on pre-PCH as well. For panel
> > fitting we do need to do an actual power cycle when going from
> > non
On Mon, 08 Aug 2011 11:40:06 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes
> wrote:
>
> > ...to catch places like this where the wrong register gets used. :)
>
> Ouch! There are only two places we *should* have these loops, one when
>
On Mon, 08 Aug 2011 11:42:56 -0700
Keith Packard wrote:
> On Mon, 8 Aug 2011 09:30:10 -0700, Jesse Barnes
> wrote:
>
> > Yep, looks fine. The only think we might want to sprinkle about are
> > checks for panel off so we can avoid visible corruption if we whack
> &g
On Sat, 6 Aug 2011 10:54:08 -0700
Keith Packard wrote:
> Just an extra parameter which isn't actually needed.
>
> Signed-off-by: Keith Packard
> ---
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
rd
> ---
> drivers/gpu/drm/i915/i915_reg.h | 13 ++-
> drivers/gpu/drm/i915/intel_display.c | 60 ++---
> 2 files changed, 58 insertions(+), 15 deletions(-)
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
think we might want to sprinkle about are
checks for panel off so we can avoid visible corruption if we whack
timing or fb stuff while the panel is on.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
r this...
> I915_WRITE(ctl_reg, I915_READ(ctl_reg) & ~POWER_TARGET_ON);
> + if (wait_for((I915_READ(stat_reg) & PP_ON) == 0, 1000))
> + DRM_ERROR("timed out waiting for panel to power off status
> 0x%08x control 0x%08x\n",
> +
))
+ DRM_ERROR(timed out waiting for panel to power off status
0x%08x control 0x%08x\n,
+ I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
...to catch places like this where the wrong register gets used. :)
--
Jesse Barnes, Intel Open Source Technology Center
fine. The only think we might want to sprinkle about are
checks for panel off so we can avoid visible corruption if we whack
timing or fb stuff while the panel is on.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
/gpu/drm/i915/i915_reg.h | 13 ++-
drivers/gpu/drm/i915/intel_display.c | 60 ++---
2 files changed, 58 insertions(+), 15 deletions(-)
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
On Sat, 6 Aug 2011 10:54:08 -0700
Keith Packard kei...@keithp.com wrote:
Just an extra parameter which isn't actually needed.
Signed-off-by: Keith Packard kei...@keithp.com
---
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 08 Aug 2011 11:40:06 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 09:27:19 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
...to catch places like this where the wrong register gets used. :)
Ouch! There are only two places we *should* have these loops, one
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yep, it's safe and possible to do on pre-PCH as well. For panel
fitting we do need to do an actual power cycle when going from
non
On Mon, 08 Aug 2011 13:24:12 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 13:01:28 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, 08 Aug 2011 12:53:31 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 8 Aug 2011 11:49:54 -0700, Jesse Barnes
jbar
gle to my HDMI TV.
Does the HDMI HDA codec need any special parameters to work?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
HDMI TV.
Does the HDMI HDA codec need any special parameters to work?
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, 27 Jul 2011 02:21:24 -0700
Keith Packard wrote:
> On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes virtuousgeek.org> wrote:
>
> > I'd like to amend my reviewed by and say the lock shouldn't be held
> > around the call to the drm helper function. It queues some wor
On Wed, 27 Jul 2011 02:21:24 -0700
Keith Packard kei...@keithp.com wrote:
On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
I'd like to amend my reviewed by and say the lock shouldn't be held
around the call to the drm helper function. It queues some work
internal driver
callbacks but missed that the lock was held across the helper too.
--
Jesse Barnes, Intel Open Source Technology Center
t interference from other outputs
> connected to that pch port
>
> Signed-off-by: Keith Packard
> ---
Ah nice catch. I expect one day we'll have all the chipset and PCH
differences coded...
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
p->dpcd)) {
> + if (ret) {
> if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
> dev_priv->no_aux_handshake =
> intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
Reviewed-by: Jesse Barnes
On Mon, 25 Jul 2011 23:36:31 -0700
Keith Packard wrote:
> This describes the function better, allowing it to be used where the
> DPCD value is relevant.
>
> Signed-off-by: Keith Packard
> ---
Ah I see you've addressed my previous comment already. :)
You can add my
Reviewed-b
output_reg);
> }
>
> +static enum drm_connector_status
> +i915_dp_detect_common(struct intel_dp *intel_dp)
Maybe you can fix the prefix of this function while you're at it since
it's not i915 or even i9xx specific?
--
Jesse Barnes, Intel Open Source Technology Center
my
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org to 1/5 and 2/5.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
)
dev_priv-no_aux_handshake =
intel_dp-dpcd[DP_MAX_DOWNSPREAD]
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Now we just have to enable fast link training in the eDP case (and
optionally when we know the DP monitor hasn't changed, just
drm_connector_status
+i915_dp_detect_common(struct intel_dp *intel_dp)
Maybe you can fix the prefix of this function while you're at it since
it's not i915 or even i9xx specific?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri
to that pch port
Signed-off-by: Keith Packard kei...@keithp.com
---
Ah nice catch. I expect one day we'll have all the chipset and PCH
differences coded...
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
was held across the helper too.
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
ce tell us what to do */
> drm_helper_hpd_irq_event(dev);
> }
yay, sounds like this will fix Andrew's problem and probably lots of
other random DP related failures.
Looks like the ->detect function is similarly protected at the call
site (though one level up in ->fill_modes),
and probably lots of
other random DP related failures.
Looks like the -detect function is similarly protected at the call
site (though one level up in -fill_modes), so it should be safe.
Looks like all the call sites in the link_status function are safe too.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
On Thu, 30 Jun 2011 08:37:09 +0200
Olaf Freyer wrote:
> Am 29.06.2011 00:06, schrieb Jesse Barnes:
> > On Wed, 29 Jun 2011 00:01:58 +0200
> > Olaf Freyer wrote:
> >
> >> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> >>> Ok interesting, did
On Fri, 22 Jul 2011 08:52:52 -0500
Rob Clark wrote:
> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes
> wrote:
> > ?/**
> > + * drm_plane_funcs - driver plane control functions
> > + * @update_plane: update the plane configuration
> > + */
> > +stru
On Fri, 22 Jul 2011 08:52:52 -0500
Rob Clark robdcl...@gmail.com wrote:
On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
/**
+ * drm_plane_funcs - driver plane control functions
+ * @update_plane: update the plane configuration
+ */
+struct
On Thu, 30 Jun 2011 08:37:09 +0200
Olaf Freyer aaron...@gmx.net wrote:
Am 29.06.2011 00:06, schrieb Jesse Barnes:
On Wed, 29 Jun 2011 00:01:58 +0200
Olaf Freyer aaron...@gmx.net wrote:
Am 28.06.2011 23:18, schrieb Jesse Barnes:
Ok interesting, didn't realize X startup was so GPU
On Thu, 21 Jul 2011 19:15:24 +0900
Joonyoung Shim wrote:
> Hi,
>
> 2011/6/16 Jesse Barnes :
> > On Tue, ?7 Jun 2011 13:07:38 -0700
> > Jesse Barnes wrote:
> >
> >> This patchset updates the previous one, incorporating the feedback I
> >>
On Thu, 21 Jul 2011 19:30:00 +0900
Joonyoung Shim wrote:
> Hi,
>
> simple questions :)
>
> 2011/6/21 Jesse Barnes :
> > 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
&
On Thu, 21 Jul 2011 19:30:00 +0900
Joonyoung Shim dofm...@gmail.com wrote:
Hi,
simple questions :)
2011/6/21 Jesse Barnes jbar...@virtuousgeek.org:
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them
On Thu, 21 Jul 2011 19:15:24 +0900
Joonyoung Shim dofm...@gmail.com wrote:
Hi,
2011/6/16 Jesse Barnes jbar...@virtuousgeek.org:
On Tue, 7 Jun 2011 13:07:38 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
This patchset updates the previous one, incorporating the feedback I
On Sat, 2 Jul 2011 17:55:53 +0200
Wolfram Sang wrote:
> On Mon, Jun 20, 2011 at 10:38:54AM -0700, Jesse Barnes wrote:
> > On Mon, 20 Jun 2011 19:36:11 +0200
> > Wolfram Sang wrote:
> >
> > > Commit 6067aa (drm/i915: split clock gating init into per-chips
On Sat, 2 Jul 2011 17:55:53 +0200
Wolfram Sang w.s...@pengutronix.de wrote:
On Mon, Jun 20, 2011 at 10:38:54AM -0700, Jesse Barnes wrote:
On Mon, 20 Jun 2011 19:36:11 +0200
Wolfram Sang w.s...@pengutronix.de wrote:
Commit 6067aa (drm/i915: split clock gating init into per-chipset
Chad Versace (1):
Add attachment token DRI2BufferHiz
Jesse Barnes (2):
Revert "dri2proto: make DRI2 swap event match GLX spec"
dri2proto: add a new DRI2BufferSwapComplete struct that matches the spec
git tag: dri2proto-2.6
http://xorg.freedesktop.org/archive/indivi
Chad Versace (1):
Add attachment token DRI2BufferHiz
Jesse Barnes (2):
Revert dri2proto: make DRI2 swap event match GLX spec
dri2proto: add a new DRI2BufferSwapComplete struct that matches the spec
git tag: dri2proto-2.6
http://xorg.freedesktop.org/archive/individual/proto
On Wed, 29 Jun 2011 00:01:58 +0200
Olaf Freyer wrote:
> Am 28.06.2011 23:18, schrieb Jesse Barnes:
> > On Tue, 28 Jun 2011 23:09:45 +0200
> > Olaf Freyer wrote:
> >>>>> I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> >>>&
resting, didn't realize X startup was so GPU intensive. :)
The patch you reverted will definitely cause the GPU to ramp up its
frequency much faster than before, but it sounds like on your system
you might also see it with the revert if you run something GPU
intensive like nexuiz.
The CPU (and by ex
6b690f2a
> > bdd92c9ad287e03a2ec52f5a89c470cd5caae1c2
> >
> >
> >
> > I'd guess ccab5c82759e2ace74b2e84f82d1e0eedd932571 could be the
> > cause. Can you check if the appended revert of that commit makes
> > things disappear?
> It seems like you guessed perfectly correct - reverting the commit makes
> those notifications go away at once.
>
Without this reverted you see messages? I missed the earlier stuff,
what message are you seeing?
--
Jesse Barnes, Intel Open Source Technology Center
the commit makes
those notifications go away at once.
Without this reverted you see messages? I missed the earlier stuff,
what message are you seeing?
--
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel
401 - 500 of 836 matches
Mail list logo
