I have tried it with 6 streams MPEG2 1080P files but don't find this issue. How
many streams are you playing?
Hai Lan
> -Original Message-
> From: intel-gfx-bounces+hai.lan=intel@lists.freedesktop.org
> [mailto:intel-gfx-bounces+hai.lan=intel@lists.freedesktop.org] On
> Behalf Of
On Wed, Nov 02, 2011 at 07:29:53PM +, Dave Airlie wrote:
> On Mon, Oct 31, 2011 at 3:16 AM, Ben Widawsky wrote:
> > After the ILK vt-d workaround patches it became clear that we had
> > introduced a bug. Chris tracked down the issue to recursive calls to
> > unmap. This happens because we try
On Wed, 2 Nov 2011 13:03:19 -0700
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.
Accidentally left out the ->destroy hook in this one. The drm-overlays
branch at gi
On 11/2/11 5:13 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson wrote:
It is? The DP 1.1a text for lane count is "For Rev.1.1, only the
following three values are supported. All other values are reserved."
Yeah, if you look at the MAX_LINK_RATE field, we assume tha
On Wed, 02 Nov 2011 16:35:51 -0400, Adam Jackson wrote:
> It is? The DP 1.1a text for lane count is "For Rev.1.1, only the
> following three values are supported. All other values are reserved."
Yeah, if you look at the MAX_LINK_RATE field, we assume that it has a
useful value. I'll bet they w
On 11/2/11 4:05 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson wrote:
The VBT is going to be crap.
The only question then is what to do with hardware that doesn't have the
DPCD value -- that's "new" in revision 0x11, after all.
It is? The DP 1.1a text for lane c
On Wed, 02 Nov 2011 15:36:20 -0400, Adam Jackson wrote:
> The VBT is going to be crap.
The only question then is what to do with hardware that doesn't have the
DPCD value -- that's "new" in revision 0x11, after all.
How about this:
commit 34ebe02cc78f20ae6b7865c5087c3b5ac7810185
Author: Keith
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
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 | 123
Add new ioctls for getting and setting the current destination color
key. This allows for simple overlay display control by matching a color
key value in the primary plane before blending the overlay on top.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers
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 |
In response to feedback, I've adjusted the new addfb2 ioctl to take per
component pitch and offset args. Generally, the offset[0] field will be
0, but it's conceivable that some metadata could be stored at the start
of a given buffer, and an offset[0] allows the client to skip past that.
Similarly
On 11/2/11 1:31 PM, Keith Packard wrote:
On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson wrote:
Given the choice of trusting DPCD or the VBT, I'd definitely prefer
DPCD.
Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the platform which may ne
On Mon, Oct 31, 2011 at 3:16 AM, Ben Widawsky wrote:
> After the ILK vt-d workaround patches it became clear that we had
> introduced a bug. Chris tracked down the issue to recursive calls to
> unmap. This happens because we try to optimize waiting on requests by
> calling retire requests after t
On Tue, 1 Nov 2011 23:20:26 -0700, Keith Packard wrote:
> intel_dp = enc_to_intel_dp(encoder);
> - if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
> + if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT ||
> is_pch_edp(intel_dp)) {
>
On Tue, Nov 1, 2011 at 7:54 PM, Matthew Garrett wrote:
> Again, adding arbitrary constants without any explanation for why you're
> making this the default really isn't acceptable. We have no way to
> determine whether fixing one machine is worth making things worse for
> another.
The default is
On Wed, 2 Nov 2011 16:52:46 +0800, Wu Fengguang wrote:
> In fact Linux 3.1 does not have the ELD patch yet. It should go into
> the upcoming 3.2.
The ELD patch is on Linus' master branch.
--
keith.pack...@intel.com
pgprsJ9jvJTLR.pgp
Description: PGP signature
On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson
wrote:
> This would seem to be a separate chunk to initiate training on only the
> lanes we intend to use.
> -Chris
Here's that patch separated out:
commit e7fecae483754ca9a42312be18f58ceb454702fe
Author: Keith Packard
Date: Wed Nov 2 10:17:5
On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes
wrote:
> Note that PP_READY will incorrectly depend on some other register
> values, so in some configs the panel will happily power up even if
> PP_READY isn't set yet...
Here's the new version of that chunk:
@@ -906,32 +905,56 @@ intel_dp_mode_
On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson wrote:
> Redundant. You've already done the link_configuration |= above in the
> common code. You can drop the second if chunk altogether.
Here's the new version of that chunk of patch:
@@ -850,32 +864,45 @@ intel_dp_mode_set(struct drm_encode
On Wed, 02 Nov 2011 13:13:52 -0400, Adam Jackson wrote:
> Given the choice of trusting DPCD or the VBT, I'd definitely prefer
> DPCD.
Except that the DPCD is coded into the monitor while the VBT is done by
the platform. And, it's the platform which may neglect to connect some
of the wires. In an
On Wed, 02 Nov 2011 09:12:13 +, Chris Wilson
wrote:
> This would seem to be a separate chunk to initiate training on only the
> lanes we intend to use.
Yeah, this got left in during some debugging; it might be a good thing
to do, but it's completely separate. I've pulled it out into a separ
On Wed, 2 Nov 2011 09:23:10 -0700, Jesse Barnes
wrote:
> Note that PP_READY will incorrectly depend on some other register
> values, so in some configs the panel will happily power up even if
> PP_READY isn't set yet...
Yeah, I'd like to understand why PP_READY isn't getting set; we should
have
On 11/2/11 12:20 PM, Jesse Barnes wrote:
@@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
drm_display_mode *mode,
continue;
intel_dp = enc_to_intel_dp(encoder);
- if (intel_dp->base.type == INTEL_OUTPUT_DISPLAYPORT) {
+
On Wed, 2 Nov 2011 09:20:19 -0700, Jesse Barnes
wrote:
> But I was curious about this hunk:
>
> @@ -766,10 +766,10 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct
> drm_display_mode *mode,
> continue;
>
> intel_dp = enc_to_intel_dp(encoder);
> -
On Wed, 02 Nov 2011 11:29:53 -0400, Adam Jackson wrote:
> Redundant. You've already done the link_configuration |= above in the
> common code. You can drop the second if chunk altogether.
Thanks for catching this mistake; cut&paste programming without the cut part...
> In related news, the c
On Wed, 02 Nov 2011 00:31:40 -0700
Keith Packard wrote:
> On Tue, 1 Nov 2011 23:20:27 -0700, Keith Packard wrote:
>
> > -static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
> > +#define IDLE_ON_MASK (PP_ON | PP_READY | PP_SEQUENCE_MASK |
> > 0 | PP
On Tue, 1 Nov 2011 23:20:26 -0700
Keith Packard wrote:
> PCH eDP has many of the same needs as regular PCH DP connections,
> including the DP_CTl bit settings, the TRANS_DP_CTL register.
>
> Signed-off-by: Keith Packard
> ---
> drivers/gpu/drm/i915/intel_display.c |3 +-
> drivers/gpu/drm
On Tue, 1 Nov 2011 23:20:25 -0700
Keith Packard wrote:
> No persistent data was ever stored here, so link_status is instead
> allocated on the stack as needed.
>
> Signed-off-by: Keith Packard
> ---
I like this cleanup.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technolo
On Wed, 2 Nov 2011 09:02:55 -0700, Jesse Barnes
wrote:
> Can't we just set UNLOCK_REGS at load time and have asserts sprinkled
> here and there?
I think we'd need it at resume time as well; it seemed easier to just
set it every time we touch the register.
--
keith.pack...@intel.com
pgp9aTPX
On Tue, 1 Nov 2011 23:20:24 -0700
Keith Packard wrote:
> Every usage of PCH_PP_CONTROL sets the PANEL_UNLOCK_REGS value to
> ensure that writes will be respected, move this to a common function
> to make the driver cleaner.
>
> No functional changes.
>
> Signed-off-by: Keith Packard
> ---
>
On Wed, 2 Nov 2011 05:56:56 + (UTC)
Inki Dae wrote:
> Hi, Jesse.
>
> drm_plane structure has format_types and format_conunt that they was set at
> booting time. but they aren't used anywhere. at intel_update_plane(), I guess
> they could be used to check if the format type(fb->pixel_format
On Wed, 2 Nov 2011 02:20:58 + (UTC)
Inki Dae wrote:
> Sorry, there is my missing point. please, ignor step 6 ~ 9.
> if user requests setplane then drm_mode_setplane function gets fb and crtc
> object to update the overlay corresponding to plane id. at that time I think
> we could know which
On 11/2/11 2:20 AM, Keith Packard wrote:
+ if (intel_dp->link_configuration [1] &
DP_LANE_COUNT_ENHANCED_FRAME_EN)
+ intel_dp->DP |= DP_ENHANCED_FRAMING;
+
+ /*
+* Check for DPCD version> 1.1 and enhanced framing support
+
On 11/2/11 6:46 AM, jarek wrote:
Hi!
I've tried to run intel_gpu_dump on running iegd driver, but this
driver works without i915.
I said intel_reg_dumper, not intel_gpu_dump.
- ajax
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Wed, Nov 2, 2011 at 6:17 AM, Sander Jansen wrote:
> On Wed, Nov 2, 2011 at 2:35 AM, Paul Menzel
> wrote:
>> Dear Sander,
>>
>>
>> Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen:
>>> On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang wrote:
>>
>>> >> The log does confirm that the drm
GPU reset is a very important piece of our infrastructure.
Unfortunately we only really test it by actually hanging the gpu,
which often has bad side-effects for the entire system. And the gpu
hang handling code is one of the rather complicated pieces of code we
have, consisting of
- hang detection
All r/w debugfs files are created equal.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 53 ++
1 files changed, 16 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
ind
Only forcewake has an open with special semantics, the other r/w
debugfs only assign the file private pointer.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 +-
1 files changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i
On Wed, Nov 2, 2011 at 2:35 AM, Paul Menzel
wrote:
> Dear Sander,
>
>
> Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen:
>> On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang wrote:
>
>> >> The log does confirm that the drm_edid_to_eld function is running, and
>> >> that we're not far fr
On Tue, 1 Nov 2011 23:20:29 -0700, Keith Packard wrote:
> Instead of going through the sequence just once, run through the whole
> set up to 5 times to see if something can work. This isn't part of the
> DP spec, but the BIOS seems to do it, and given that link training
> failure is so bad, it se
Hi Sander,
> On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang wrote:
> > Hi Christopher,
> >
> >> The log does confirm that the drm_edid_to_eld function is running, and
> >> that we're not far from a solution:
> >> [ 21.061417] [drm:drm_edid_to_eld], ELD monitor TX-SR607
> >> [ 21.061421] [drm:dr
Dear Sander,
Am Mittwoch, den 02.11.2011, 01:10 -0500 schrieb Sander Jansen:
> On Tue, Nov 1, 2011 at 8:45 PM, Wu Fengguang wrote:
> >> The log does confirm that the drm_edid_to_eld function is running, and
> >> that we're not far from a solution:
> >> [ 21.061417] [drm:drm_edid_to_eld], ELD
On Tue, 1 Nov 2011 23:20:27 -0700, Keith Packard wrote:
> -static void ironlake_wait_panel_off(struct intel_dp *intel_dp)
> +#define IDLE_ON_MASK (PP_ON | PP_READY | PP_SEQUENCE_MASK | 0
> | PP_SEQUENCE_STATE_MASK)
> +#define IDLE_ON_VALUE(PP_ON | PP_READY |
45 matches
Mail list logo
