Re: [Intel-gfx] Playing multiple mpg files simultaneously
I was also using mpg container file(mpeg2 ps file). What files are you using? Hai Lan -Original Message- From: Jyotsana [mailto:jyotsanasi...@tataelxsi.co.in] Sent: Thursday, November 03, 2011 2:55 PM To: Lan, Hai Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] Playing multiple mpg files simultaneously I tried with 2 streams and have this problem only with mpg container. There is no problem with mpegts containing mpeg2 video codec. Lan, Hai wrote: 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 Jyotsana Sent: Wednesday, November 02, 2011 12:38 PM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] Playing multiple mpg files simultaneously Hi, I am trying to run multiple mpg files simultaneously from the command line using mplayer and libva. The videos run fine for a few seconds or so but then the display flickers and becomes black and ultimately the system hangs. This is the log given by mplayer on commad line: Too many video packets in the buffer: (4096 in 1180675 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. A: 25.8 V: 25.4 A-V: 0.399 ct: 2.006 756/756 35% 43% 3.9% 1 0 Multiple mp4/mov files work fine. I have tested this with gstreamer-vaapi and it gives the same result. PS : 1. Platform : SandyBridge 2. OS: 64 bit FC 15 3. Packages : 2011Q3 Packages 4. Mplayer : Downloaded from http://www.splitted-desktop.com/static/libva/mplayer-vaapi/mplayer-vaap i-latest-FULL.tar.bz2 Also tested with 32-bit FC 13 and 2011Q1 Packages but it gives the same result. What could be the problem? I have tried with different mpg files but all give the same result. Thanks and Regards, Jyotsana. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Playing multiple mpg files simultaneously
I tried with 2 streams and have this problem only with mpg container. There is no problem with mpegts containing mpeg2 video codec. Lan, Hai wrote: 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 Jyotsana Sent: Wednesday, November 02, 2011 12:38 PM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] Playing multiple mpg files simultaneously Hi, I am trying to run multiple mpg files simultaneously from the command line using mplayer and libva. The videos run fine for a few seconds or so but then the display flickers and becomes black and ultimately the system hangs. This is the log given by mplayer on commad line: Too many video packets in the buffer: (4096 in 1180675 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. A: 25.8 V: 25.4 A-V: 0.399 ct: 2.006 756/756 35% 43% 3.9% 1 0 Multiple mp4/mov files work fine. I have tested this with gstreamer-vaapi and it gives the same result. PS : 1. Platform : SandyBridge 2. OS: 64 bit FC 15 3. Packages : 2011Q3 Packages 4. Mplayer : Downloaded from http://www.splitted-desktop.com/static/libva/mplayer-vaapi/mplayer-vaap i-latest-FULL.tar.bz2 Also tested with 32-bit FC 13 and 2011Q1 Packages but it gives the same result. What could be the problem? I have tried with different mpg files but all give the same result. Thanks and Regards, Jyotsana. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Playing multiple mpg files simultaneously
Hi, This is the information of the mpg file shown by Elecard: video stream type: MPEG2 resolution: 720x480 profile:level : Main:Main aspect ratio : square pel chroma format: 4:2:0 interlaced : yes frames count : 1 805 duration :00:01:00.193 frame size max : 155 376 avg : 55 457 avg/max (I) :74 511 / 118 872 avg/max (P):72 246 / 112 320 avg/max (B):46 806 / 155 376 min : 9 672 framerate declared : 29.970 real : 29.970 bitrate type : CBR bitrate declared : 12 000 000 bit allocation max: 15 110 394 avg : 13 296 370 min : 13 030 237 Regards, Jyotsana mpg container having mpeg2 video codec. Profile: Level : Main:Main Resolution : 720x480 Lan, Hai wrote: I was also using mpg container file(mpeg2 ps file). What files are you using? Hai Lan -Original Message- From: Jyotsana [mailto:jyotsanasi...@tataelxsi.co.in] Sent: Thursday, November 03, 2011 2:55 PM To: Lan, Hai Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] Playing multiple mpg files simultaneously I tried with 2 streams and have this problem only with mpg container. There is no problem with mpegts containing mpeg2 video codec. Lan, Hai wrote: 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 Jyotsana Sent: Wednesday, November 02, 2011 12:38 PM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] Playing multiple mpg files simultaneously Hi, I am trying to run multiple mpg files simultaneously from the command line using mplayer and libva. The videos run fine for a few seconds or so but then the display flickers and becomes black and ultimately the system hangs. This is the log given by mplayer on commad line: Too many video packets in the buffer: (4096 in 1180675 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. A: 25.8 V: 25.4 A-V: 0.399 ct: 2.006 756/756 35% 43% 3.9% 1 0 Multiple mp4/mov files work fine. I have tested this with gstreamer-vaapi and it gives the same result. PS : 1. Platform : SandyBridge 2. OS: 64 bit FC 15 3. Packages : 2011Q3 Packages 4. Mplayer : Downloaded from http://www.splitted-desktop.com/static/libva/mplayer-vaapi/mplayer-vaap i-latest-FULL.tar.bz2 Also tested with 32-bit FC 13 and 2011Q1 Packages but it gives the same result. What could be the problem? I have tried with different mpg files but all give the same result. Thanks and Regards, Jyotsana. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] DRM planes
On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote: 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, pitch[0] will typically describe the whole buffer, but it's possible to simply string together several planes into a single object where individual pitch components matter. Userland patches are available in the drm-overlays branches of my personal libdrm and xf86-video-intel trees at freedesktop.org. The xf86-video-intel side works well enough to handle clipping (using a new i915 specific ioctl for setting a destination color key) and play videos, albeit without nice flipping. Assuming no major objections, I think this is finally ready for drm-next. Well, the fool I am I've attempted to write a nice little drm plane wrapper for the legacy intel overlay code. Code is totally untested, but I like what it looks like - the drm plane interfaces are a quite natural fit to the existing code. There's one thing though which is imo a bloody mess (and I've given up writing the code for it), namely planar yuv handling with fourcc pixelformats. The current implementation for snb+ doesn't stumble over that rock because it only supports packed yuv. So here goes the rant: The legacy overlay (and my ioctl) accept a set off offset for Y, U and V planes (i.e. it could even accept different bos, but the current ioctl designed for Xv doesn't). The hw has the restriction that the strides for the U and V planes need to be identical, but that's it. Pixelformat is just an enumeration of YUV422,420,411,410 to specify the subsampling ratio of the U/V planes. Now fourcc specifies all these offset implicitly in the pixelformat (at least that's what I've figured out, I might be wrong though): - Some formats have the YUV planes in a special, fixed arrangement, no additional offset needs to be passed in and strides are implicit from the width. - Some have a separate offset somewhere for UV planes, but the UV planes are again in a fixed layout (either interleaved or one after another). - Some fourcc have all three planes independant, i.e. you need an offset for the U and the V plane. No clue what that implies for the stride. In short decoding these fourcc values with all their implicit assumptions about offset, strides and whatnotelse will be one giant switch mess. Not my idea of a nice kernel interface. Also practically guaranteed to result in slightly different behaviour in each driver. So here's the new radical proposal (and yep, I expect heat for this): - Ditch fourcc. Afaics this wheel is square and no amount of sharpening the corners will make it round. - Ditch addfb support for planar yuv formats, at least for the moment. Until we have more than one kms driver for this I don't think we can come up with any sane interface. In conclusion: Ditch the addfb2ioctl and just add a few more kms pixel formats for the new packed yuv layouts that the snb+ sprite code needs. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] DRM planes
On Thu, 3 Nov 2011 15:11:55 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Nov 02, 2011 at 01:03:18PM -0700, Jesse Barnes wrote: 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, pitch[0] will typically describe the whole buffer, but it's possible to simply string together several planes into a single object where individual pitch components matter. Userland patches are available in the drm-overlays branches of my personal libdrm and xf86-video-intel trees at freedesktop.org. The xf86-video-intel side works well enough to handle clipping (using a new i915 specific ioctl for setting a destination color key) and play videos, albeit without nice flipping. Assuming no major objections, I think this is finally ready for drm-next. Well, the fool I am I've attempted to write a nice little drm plane wrapper for the legacy intel overlay code. Code is totally untested, but I like what it looks like - the drm plane interfaces are a quite natural fit to the existing code. There's one thing though which is imo a bloody mess (and I've given up writing the code for it), namely planar yuv handling with fourcc pixelformats. The current implementation for snb+ doesn't stumble over that rock because it only supports packed yuv. So here goes the rant: The legacy overlay (and my ioctl) accept a set off offset for Y, U and V planes (i.e. it could even accept different bos, but the current ioctl designed for Xv doesn't). The hw has the restriction that the strides for the U and V planes need to be identical, but that's it. Pixelformat is just an enumeration of YUV422,420,411,410 to specify the subsampling ratio of the U/V planes. Now fourcc specifies all these offset implicitly in the pixelformat (at least that's what I've figured out, I might be wrong though): - Some formats have the YUV planes in a special, fixed arrangement, no additional offset needs to be passed in and strides are implicit from the width. - Some have a separate offset somewhere for UV planes, but the UV planes are again in a fixed layout (either interleaved or one after another). - Some fourcc have all three planes independant, i.e. you need an offset for the U and the V plane. No clue what that implies for the stride. In short decoding these fourcc values with all their implicit assumptions about offset, strides and whatnotelse will be one giant switch mess. Not my idea of a nice kernel interface. Also practically guaranteed to result in slightly different behaviour in each driver. There may be some v4l code we can share here, or at least refactor, for use by drivers that want to handle planar formats like the old overlay. Did you look for any? So here's the new radical proposal (and yep, I expect heat for this): - Ditch fourcc. Afaics this wheel is square and no amount of sharpening the corners will make it round. - Ditch addfb support for planar yuv formats, at least for the moment. Until we have more than one kms driver for this I don't think we can come up with any sane interface. In conclusion: Ditch the addfb2ioctl and just add a few more kms pixel formats for the new packed yuv layouts that the snb+ sprite code needs. We'll still need the new ioctl though. We don't have enough info today (just bpp and depth) in the existing addfb ioctl to figure out what the actual plane layout is. We can move away from fourcc, but it still seems like we'd end up duplicating it at least a little, as our full set of supported formats would be the superset of what each driver supports. I'm not wedded to fourcc, but I guess we'll have to see what the TI and Samsung guys say to make a decision. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Setting proper video mode
On Thu, 2011-11-03 at 11:17 +0100, jarek wrote: Hi! I've tried to run intel_gpu_dump on running iegd driver, but this driver works without i915. Again: I asked for the output of intel_reg_dumper, not intel_gpu_dump. The former shows us the state of the various registers related to output setup, and has no dependency on any kernel driver. The latter - which you've attached - shows the command buffers the i915 kernel driver submits to the hardware for rendering, which isn't interesting for this problem. If I try to load i915 it restarts computer. I suspect that it is somehow related to ACPI. This computer works with ACPI turned off in BIOS and than it is impossible to load i915. If I enable ACPI that loading of i915 restarts computer. If trying to load i915 restarts the computer with iegd already loaded, I'm not entirely surprised. - ajax signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] [RFC] drm/i915: add interface to simulate gpu hangs
On Wed, Nov 2, 2011 at 09:46, Daniel Vetter daniel.vet...@ffwll.ch wrote: 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 - error capture - actual gpu reset - reset of all the gem bookkeeping - reinitialition of the entire gpu This patch adds a debugfs to selectively stopping rings by ceasing to update the hw tail pointer. This way we can exercise the gpu hang code under controlled conditions without a dying gpu taking down the entire systems. Patch motivated by me forgetting to properly reinitialize ppgtt after a gpu reset. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com Could be handy for debugging, I like it. -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: forcewake warning fixes in debugfs
On Sun, 23 Oct 2011 12:13:43 +0200, Daniel Vetter dan...@ffwll.ch wrote: Hi Keith, This patch isn't in your -next pull request. Please consider merging for 3.2. I've merged this to -next. -- keith.pack...@intel.com pgpWigHouv8wm.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Ivybridge still has fences!
On Sun, 23 Oct 2011 13:35:45 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: On Sun, 23 Oct 2011 14:09:07 +0200, Daniel Vetter dan...@ffwll.ch wrote: Keith, can take a look at patches 1-2 and consider merging them for 3.2? Those two are Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk And merged to -next. -- keith.pack...@intel.com pgpLZmQytizaj.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] DRM planes
Hi all, I've discussed this a bit on irc and consensus seems to be some ugliness due to interface impendance mistmatches in the kernel? who cares I agree that there's not a fundamental problem with fourcc and planar yuv that can't be fixed with a bunch of boilerplate code with the assorted set of inconsistencies between drivers. So if this is the general consensus I'll just look the other way, shut down my shields an recall my battle ship out of LEO ... ;-) Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] DRM planes
On Thu, 3 Nov 2011 18:29:14 +0100 Daniel Vetter dan...@ffwll.ch wrote: Hi all, I've discussed this a bit on irc and consensus seems to be some ugliness due to interface impendance mistmatches in the kernel? who cares I agree that there's not a fundamental problem with fourcc and planar yuv that can't be fixed with a bunch of boilerplate code with the assorted set of inconsistencies between drivers. So if this is the general consensus I'll just look the other way, shut down my shields an recall my battle ship out of LEO ... ;-) Rob, Joonyoung, Inkie, any comment on using fourcc vs rolling our own surface definitions? Thanks, -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm: add an fb creation ioctl that takes a pixel format
On Wed, 2 Nov 2011 13:03:20 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
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.
Updated version.
--
Jesse Barnes, Intel Open Source Technology Center
From 38038767854cead6d65eaa80be79267a5fbbd097 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Tue, 7 Jun 2011 12:32:43 -0700
Subject: [PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
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
---
drivers/gpu/drm/drm_crtc.c| 105 -
drivers/gpu/drm/drm_crtc_helper.c | 50 +-
drivers/gpu/drm/drm_drv.c |1 +
drivers/gpu/drm/i915/intel_display.c | 34 +-
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_fb.c | 11 ++--
drivers/gpu/drm/nouveau/nouveau_display.c |4 +-
drivers/gpu/drm/radeon/radeon_display.c |4 +-
drivers/gpu/drm/radeon/radeon_fb.c| 18 +++--
drivers/gpu/drm/radeon/radeon_mode.h |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |2 +-
drivers/staging/gma500/framebuffer.c |2 +-
include/drm/drm.h |1 +
include/drm/drm_crtc.h|7 ++-
include/drm/drm_crtc_helper.h |4 +-
include/drm/drm_mode.h| 26 +++
include/linux/videodev2.h |1 +
17 files changed, 231 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cea209a..869e177 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1894,6 +1894,42 @@ out:
return ret;
}
+/* Original addfb only supported RGB formats, so figure out which one */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+ uint32_t fmt;
+
+ switch (bpp) {
+ case 8:
+ fmt = V4L2_PIX_FMT_RGB332;
+ break;
+ case 16:
+ if (depth == 15)
+ fmt = V4L2_PIX_FMT_RGB555;
+ else
+ fmt = V4L2_PIX_FMT_RGB565;
+ break;
+ case 24:
+ fmt = V4L2_PIX_FMT_RGB24;
+ break;
+ case 32:
+ if (depth == 24)
+ fmt = V4L2_PIX_FMT_RGB24;
+ else if (depth == 30)
+ fmt = V4L2_PIX_FMT_INTC_RGB30;
+ else
+ fmt = V4L2_PIX_FMT_RGB32;
+ break;
+ default:
+ DRM_ERROR(bad bpp, assuming RGB24 pixel format\n);
+ fmt = V4L2_PIX_FMT_RGB24;
+ break;
+ }
+
+ return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
/**
* drm_mode_addfb - add an FB to the graphics configuration
* @inode: inode from the ioctl
@@ -1914,7 +1950,74 @@ out:
int drm_mode_addfb(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
- struct drm_mode_fb_cmd *r = data;
+ struct drm_mode_fb_cmd *or = data;
+ struct drm_mode_fb_cmd2 r;
+ struct drm_mode_config *config = dev-mode_config;
+ struct drm_framebuffer *fb;
+ int ret = 0;
+
+ /* Use new struct with format internally */
+ r.fb_id = or-fb_id;
+ r.width = or-width;
+ r.height = or-height;
+ r.pitches[0] = or-pitch;
+ r.pixel_format = drm_mode_legacy_fb_format(or-bpp, or-depth);
+ r.handle = or-handle;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ if ((config-min_width r.width) || (r.width config-max_width)) {
+ DRM_ERROR(mode new framebuffer width not within limits\n);
+ return -EINVAL;
+ }
+ if ((config-min_height r.height) || (r.height config-max_height))
{
+ DRM_ERROR(mode new framebuffer height not within limits\n);
+ return -EINVAL;
+ }
+
+ mutex_lock(dev-mode_config.mutex);
+
+ /* TODO check buffer is sufficiently large */
+ /* TODO setup destructor callback */
+
+ fb = dev-mode_config.funcs-fb_create(dev, file_priv, r);
+ if (IS_ERR(fb)) {
+ DRM_ERROR(could not create framebuffer\n);
+ ret = PTR_ERR(fb);
+ goto out;
+ }
+
+ or-fb_id = fb-base.id;
+ list_add(fb-filp_head, file_priv-fbs);
+ DRM_DEBUG_KMS([FB:%d]\n, fb-base.id);
+
+out:
+ mutex_unlock(dev-mode_config.mutex);
+ return
Re: [Intel-gfx] [PATCH 3/5] drm/i915: rename existing overlay support to legacy
On Wed, 2 Nov 2011 13:03:21 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: 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. This one has been dropped. I'm calling things _sprite in the intel code now. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: add SNB and IVB video sprite support
On Wed, 2 Nov 2011 13:03:22 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: 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 --- Updated with -destroy and _sprite naming. -- Jesse Barnes, Intel Open Source Technology Center From 1a87b73677f35b7a31acdbc7ecf2b910f042c5ec Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Fri, 22 Apr 2011 14:55:33 -0700 Subject: [PATCH 3/4] drm/i915: add SNB and IVB video sprite 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 sprite support functions. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/Makefile|1 + drivers/gpu/drm/i915/i915_reg.h | 123 ++ drivers/gpu/drm/i915/intel_display.c | 31 ++- drivers/gpu/drm/i915/intel_drv.h | 23 ++ drivers/gpu/drm/i915/intel_fb.c |6 + drivers/gpu/drm/i915/intel_sprite.c | 447 ++ 6 files changed, 620 insertions(+), 11 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_sprite.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 0ae6a7c..808b255 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -28,6 +28,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \ intel_dvo.o \ intel_ringbuffer.o \ intel_overlay.o \ + intel_sprite.o \ intel_opregion.o \ dvo_ch7xxx.o \ dvo_ch7017.o \ diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 5a09416..b2270fa 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2450,6 +2450,8 @@ #define WM3_LP_ILK 0x45110 #define WM3_LP_EN (131) #define WM1S_LP_ILK0x45120 +#define WM2S_LP_IVB0x45124 +#define WM3S_LP_IVB0x45128 #define WM1S_LP_EN(131) /* Memory latency timer register */ @@ -2666,6 +2668,127 @@ #define _DSPBSURF 0x7119C #define _DSPBTILEOFF 0x711A4 +/* Sprite A control */ +#define _DVSACNTR 0x72180 +#define DVS_ENABLE (131) +#define DVS_GAMMA_ENABLE (130) +#define DVS_PIXFORMAT_MASK (325) +#define DVS_FORMAT_YUV422(025) +#define DVS_FORMAT_RGBX101010(125) +#define DVS_FORMAT_RGBX888 (225) +#define DVS_FORMAT_RGBX161616(325) +#define DVS_SOURCE_KEY (122) +#define DVS_RGB_ORDER_RGBX (120) +#define DVS_YUV_BYTE_ORDER_MASK (316) +#define DVS_YUV_ORDER_YUYV (016) +#define DVS_YUV_ORDER_UYVY (116) +#define DVS_YUV_ORDER_YVYU (216) +#define DVS_YUV_ORDER_VYUY (316) +#define DVS_DEST_KEY (12) +#define DVS_TRICKLE_FEED_DISABLE (114) +#define DVS_TILED(110) +#define _DVSASTRIDE0x72188 +#define _DVSAPOS 0x7218c +#define _DVSASIZE 0x72190 +#define _DVSAKEYVAL0x72194 +#define _DVSAKEYMSK0x72198 +#define _DVSASURF 0x7219c +#define _DVSAKEYMAXVAL 0x721a0 +#define _DVSATILEOFF 0x721a4 +#define _DVSASURFLIVE 0x721ac +#define _DVSASCALE 0x72204 +#define DVS_SCALE_ENABLE (131) +#define DVS_FILTER_MASK (329) +#define DVS_FILTER_MEDIUM(029) +#define DVS_FILTER_ENHANCING (129) +#define DVS_FILTER_SOFTENING (229) +#define _DVSAGAMC 0x72300 + +#define _DVSBCNTR 0x73180 +#define _DVSBSTRIDE0x73188 +#define _DVSBPOS 0x7318c +#define _DVSBSIZE 0x73190 +#define _DVSBKEYVAL0x73194 +#define _DVSBKEYMSK0x73198 +#define _DVSBSURF 0x7319c +#define _DVSBKEYMAXVAL 0x731a0 +#define _DVSBTILEOFF 0x731a4 +#define _DVSBSURFLIVE 0x731ac +#define _DVSBSCALE 0x73204 +#define _DVSBGAMC 0x73300 + +#define DVSCNTR(pipe) _PIPE(pipe, _DVSACNTR, _DVSBCNTR) +#define DVSSTRIDE(pipe) _PIPE(pipe, _DVSASTRIDE, _DVSBSTRIDE) +#define DVSPOS(pipe) _PIPE(pipe, _DVSAPOS, _DVSBPOS) +#define DVSSURF(pipe) _PIPE(pipe, _DVSASURF, _DVSBSURF) +#define DVSSIZE(pipe) _PIPE(pipe, _DVSASIZE, _DVSBSIZE) +#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE) +#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF) + +#define _SPRA_CTL 0x70280 +#define SPRITE_ENABLE(131) +#define SPRITE_GAMMA_ENABLE (130) +#define SPRITE_PIXFORMAT_MASK(725) +#define SPRITE_FORMAT_YUV422 (025) +#define SPRITE_FORMAT_RGBX101010 (125) +#define SPRITE_FORMAT_RGBX888(225) +#define SPRITE_FORMAT_RGBX161616 (325) +#define
Re: [Intel-gfx] [PATCH 5/5] drm/i915: add destination color key support
On Wed, 2 Nov 2011 13:03:23 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
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 jbar...@virtuousgeek.org
---
Updated with changed context due to other changes.
--
Jesse Barnes, Intel Open Source Technology Center
From 00904140838effe4511213c89e887adee5937bd7 Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Tue, 1 Nov 2011 15:13:28 -0700
Subject: [PATCH 4/4] drm/i915: add destination color key support
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 jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers/gpu/drm/i915/intel_drv.h|6 +++
drivers/gpu/drm/i915/intel_sprite.c | 72 +++
include/drm/i915_drm.h | 16
4 files changed, 96 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2eac955..0385a27 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2294,6 +2294,8 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl,
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_DESTKEY, intel_sprite_set_destkey,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GET_SPRITE_DESTKEY, intel_sprite_get_destkey,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
};
int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 785bae7..2f376dc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -407,4 +407,10 @@ extern void intel_write_eld(struct drm_encoder *encoder,
struct drm_display_mode *mode);
extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
+extern int intel_sprite_set_destkey(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
+extern int intel_sprite_get_destkey(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
+
+
#endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index ca0da52..0891bda 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -99,6 +99,7 @@ ivb_update_plane(struct drm_plane *plane, struct
drm_framebuffer *fb,
/* must disable */
sprctl |= SPRITE_TRICKLE_FEED_DISABLE;
sprctl |= SPRITE_ENABLE;
+ sprctl |= SPRITE_DEST_KEY;
/* Sizes are 0 based */
src_w--;
@@ -396,6 +397,77 @@ static void intel_destroy_plane(struct drm_plane *plane)
kfree(intel_plane);
}
+int intel_sprite_set_destkey(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_intel_set_sprite_destkey *set = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_mode_object *obj;
+ struct drm_plane *plane;
+ struct intel_plane *intel_plane;
+ int ret = 0;
+
+ if (!dev_priv)
+ return -EINVAL;
+
+ if (set-value 0xff)
+ return -EINVAL;
+
+ mutex_lock(dev-mode_config.mutex);
+
+ obj = drm_mode_object_find(dev, set-plane_id, DRM_MODE_OBJECT_PLANE);
+ if (!obj) {
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
+ plane = obj_to_plane(obj);
+ intel_plane = to_intel_plane(plane);
+
+ mutex_lock(dev-struct_mutex);
+ I915_WRITE(SPRKEYVAL(intel_plane-pipe), set-value);
+ I915_WRITE(SPRKEYMSK(intel_plane-pipe), 0xff);
+ POSTING_READ(SPRKEYMSK(intel_plane-pipe));
+ mutex_unlock(dev-struct_mutex);
+
+out_unlock:
+ mutex_unlock(dev-mode_config.mutex);
+ return ret;
+}
+
+int intel_sprite_get_destkey(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_intel_get_sprite_destkey *get = data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_mode_object *obj;
+ struct drm_plane *plane;
+ struct intel_plane *intel_plane;
+ int ret = 0;
+
+ if (!dev_priv)
+ return -EINVAL;
+
+
Re: [Intel-gfx] [PATCH] drm/i915: add SNB video sprite support
On Tue, 1 Nov 2011 22:11:43 +0800 Lan, Hai hai@intel.com wrote: Hi Jesse, I hope the function of snb_update_plane can handle crtx_x0 or crtc_y0 just like my patch. What do you think about it? Thanks and best regards. I don't think this is necessary with the latest code; I clamp things in the top level function now. But take a look and see if I'm missing one of the cases you cover here. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] DRM planes
On Thu, Nov 03, 2011 at 05:47:43PM +, Alan Cox wrote: In short decoding these fourcc values with all their implicit assumptions about offset, strides and whatnotelse will be one giant switch mess. Not my idea of a nice kernel interface. Also practically guaranteed to result in slightly different behaviour in each driver. So you'd rather make each applicationa author get it wrong individually and uniquely. That is a bigger mess by far. We're talking about gpus, there's no way an application will talk to them than through some nice cozy abstraction layer like OpenGl, X, ... Even Wayland has gbm to do the low-level kms scanout allocation. In conclusion: Ditch the addfb2ioctl and just add a few more kms pixel formats for the new packed yuv layouts that the snb+ sprite code needs. If you need a decoder for some hardware then fine, write one - share it with the v4l one and put it in a library drivers can call. However - user space is already working in fourcc, v4l has working fourcc and dumping the mess on the user isn't going to be a win. The mess will be dumped onto userspace anyway, but it won't be dumped onto the user - that one should use Xv or some fancy EGLImage extension. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] DRM planes
On Thu, 3 Nov 2011 13:55:50 -0500 Rob Clark rob.cl...@linaro.org wrote: On Thu, Nov 3, 2011 at 12:36 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 3 Nov 2011 18:29:14 +0100 Daniel Vetter dan...@ffwll.ch wrote: Hi all, I've discussed this a bit on irc and consensus seems to be some ugliness due to interface impendance mistmatches in the kernel? who cares I agree that there's not a fundamental problem with fourcc and planar yuv that can't be fixed with a bunch of boilerplate code with the assorted set of inconsistencies between drivers. So if this is the general consensus I'll just look the other way, shut down my shields an recall my battle ship out of LEO ... ;-) Rob, Joonyoung, Inkie, any comment on using fourcc vs rolling our own surface definitions? I tend to think that, even if fourcc's aren't perfect, that it is better than the alternatives.. I *think* the main issue is really about single vs multiple buffer objects? Although I've mostly not been having too much time to follow email this week. I've punted on multi-buffer object fbs anyway. I think those would be better suited to an addfb_multi ioctl. Muxing it into addfb2 seemed unnatural, but I'm not opposed to someone adding one. I just think userspace will have to use one or the other depending on whether all the data is packed into a single bo or not. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job
On Tue, 1 Nov 2011 23:20:27 -0700
Keith Packard kei...@keithp.com wrote:
The panel power sequencing hardware tracks the stages of panel power
sequencing and signals when the panel is completely on or off. Instead
of blindly assuming the panel timings will work, poll the panel power
status register until it shows the correct values.
Modulo what we already discussed on irc about the PP_READY bit, and the
CodingStyle nitpicks (newlines before {? come on, this isn't X :),
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms
On Tue, 1 Nov 2011 23:20:28 -0700
Keith Packard kei...@keithp.com wrote:
Make sure the sequence of operations in all three functions makes
sense:
1) The backlight must be off unless the screen is running
2) The link must be running to turn the eDP panel on/off
3) The CPU eDP PLL must be running until everything is off
A few comments on this one (also, is it strictly required to fix your
bug)?
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d6c6608..6be6a04 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1234,17 +1234,18 @@ static void intel_dp_prepare(struct drm_encoder
*encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ ironlake_edp_backlight_off(intel_dp);
+ ironlake_edp_panel_off(intel_dp);
+
/* Wake up the sink first */
ironlake_edp_panel_vdd_on(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+ intel_dp_link_down(intel_dp);
ironlake_edp_panel_vdd_off(intel_dp, false);
/* Make sure the panel is off before trying to
* change the mode
*/
- ironlake_edp_backlight_off(intel_dp);
- intel_dp_link_down(intel_dp);
- ironlake_edp_panel_off(intel_dp);
}
Ok so you're making sure the panel has power to down the link, I think
that's fine.
static void intel_dp_commit(struct drm_encoder *encoder)
@@ -1276,16 +1277,20 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
uint32_t dp_reg = I915_READ(intel_dp-output_reg);
if (mode != DRM_MODE_DPMS_ON) {
+ ironlake_edp_backlight_off(intel_dp);
+ ironlake_edp_panel_off(intel_dp);
+
ironlake_edp_panel_vdd_on(intel_dp);
- if (is_edp(intel_dp))
- ironlake_edp_backlight_off(intel_dp);
intel_dp_sink_dpms(intel_dp, mode);
intel_dp_link_down(intel_dp);
- ironlake_edp_panel_off(intel_dp);
- if (is_edp(intel_dp) !is_pch_edp(intel_dp))
- ironlake_edp_pll_off(encoder);
ironlake_edp_panel_vdd_off(intel_dp, false);
+
+ if (is_cpu_edp(intel_dp))
+ ironlake_edp_pll_off(encoder);
But here it looks like you're shutting it off, then downing the link?
Should this be reordered?
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training
On Tue, 1 Nov 2011 23:20:29 -0700
Keith Packard kei...@keithp.com 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 seems reasonable to follow suit.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 41 +-
1 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6be6a04..bf20a35 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1576,8 +1576,9 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
ret = intel_dp_aux_native_write(intel_dp,
DP_TRAINING_LANE0_SET,
- intel_dp-train_set, 4);
- if (ret != 4)
+ intel_dp-train_set,
+ intel_dp-lane_count);
+ if (ret != intel_dp-lane_count)
return false;
return true;
Sneaky putting this bug fix into this patch. :)
@@ -1593,7 +1594,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
int i;
uint8_t voltage;
bool clock_recovery = false;
- int tries;
+ int voltage_tries, loop_tries;
u32 reg;
uint32_t DP = intel_dp-DP;
@@ -1620,7 +1621,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DP = ~DP_LINK_TRAIN_MASK;
memset(intel_dp-train_set, 0, 4);
voltage = 0xff;
- tries = 0;
+ voltage_tries = 0;
+ loop_tries = 0;
clock_recovery = false;
for (;;) {
/* Use intel_dp-train_set[0] to set the voltage and pre
emphasis values */
@@ -1663,17 +1665,28 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
for (i = 0; i intel_dp-lane_count; i++)
if ((intel_dp-train_set[i]
DP_TRAIN_MAX_SWING_REACHED) == 0)
break;
- if (i == intel_dp-lane_count)
- break;
-
- /* Check to see if we've tried the same voltage 5 times */
- if ((intel_dp-train_set[0] DP_TRAIN_VOLTAGE_SWING_MASK) ==
voltage) {
- ++tries;
- if (tries == 5)
+ if (i == intel_dp-lane_count) {
+ ++loop_tries;
+ if (loop_tries == 5) {
+ DRM_DEBUG_KMS(too many full retries, give
up\n);
break;
- } else
- tries = 0;
- voltage = intel_dp-train_set[0] DP_TRAIN_VOLTAGE_SWING_MASK;
+ }
+ memset(intel_dp-train_set, 0, 4);
+ voltage_tries = 0;
+ continue;
+ } else {
+
+ /* Check to see if we've tried the same voltage 5 times
*/
+ if ((intel_dp-train_set[0]
DP_TRAIN_VOLTAGE_SWING_MASK) == voltage) {
+ ++voltage_tries;
+ if (voltage_tries == 5) {
+ DRM_DEBUG_KMS(too many voltage
retries, give up\n);
+ break;
+ }
+ } else
+ voltage_tries = 0;
+ voltage = intel_dp-train_set[0]
DP_TRAIN_VOLTAGE_SWING_MASK;
+ }
/* Compute new intel_dp-train_set as requested by target */
intel_get_adjust_train(intel_dp, link_status);
Don't you love the training state machine? I think this looks ok, and
the DP compliance test should catch any grievous errors, so aside from
the bug fix hunk which should be split out:
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Remove trailing white space
On Tue, 1 Nov 2011 23:20:30 -0700
Keith Packard kei...@keithp.com wrote:
Found a couple of bare tabs in intel_dp.c
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf20a35..7ebeb01 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1054,7 +1054,7 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp
*intel_dp, bool sync)
DRM_DEBUG_KMS(Turn eDP VDD off %d\n, intel_dp-want_panel_vdd);
WARN(!intel_dp-want_panel_vdd, eDP VDD not forced on);
-
+
intel_dp-want_panel_vdd = false;
if (sync) {
@@ -2402,7 +2402,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)
cur.t8 = (pp_on PANEL_LIGHT_ON_DELAY_MASK)
PANEL_LIGHT_ON_DELAY_SHIFT;
-
+
cur.t9 = (pp_off PANEL_LIGHT_OFF_DELAY_MASK)
PANEL_LIGHT_OFF_DELAY_SHIFT;
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, Intel Open Source Technology Center
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Fix recursive calls to unmap
The solution here is to add a new flag to the call chain which gives the routines the information they need to possibly defer actions which may cause us to recurse. A macro has been defined to replace i915_gpu_idle which defaults to the old behavior. Kudos to Chris for tracking this one down. So this fixes the non-VTd case, the VT-d case still hits a recursion here, for posterity its below. Okay I take that back, I got my EL6 kernel rock stable with the correct blend of backported bits. So ignore that backtrace, however I did get another IOMMU hang on my upstream kernel with gem_linear_blits, so this should be fine to merge but I'm guessing we have more debugging to do on the VT-d cases. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: properly prefault for pread/pwrite
On Mon, 24 Oct 2011 00:11:57 +0200, Daniel Vetter dan...@ffwll.ch wrote: This patch only fixes things up so that we prefault the entire page range and not just the first PAGE_SIZE bytes (i.e. at most 2 pages). So I don't see the risk of extending the current behaviour to all pages. Userspace can already see these zero writes, but only when doing something stupid. When we posted a patch to instead fix fault_in_pages_writeable, Andrew complained that we'd have modified memory even on a short read, which wasn't considered polite. Could we read/write the same value and avoid that problem? Also, we should be fixing fault_in_pages_* going forward, rather than kludging in more code. And, we'd get to remove the version in ntfs, which should end in a patch that removes more code than it adds... -- keith.pack...@intel.com pgpiOBKK5bSX5.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: enable cacheable objects on Ivybridge
IVB supports these bits as well.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d18b07a..c0d26b1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3613,7 +3613,7 @@ struct drm_i915_gem_object *i915_gem_alloc_object(struct
drm_device *dev,
obj-base.write_domain = I915_GEM_DOMAIN_CPU;
obj-base.read_domains = I915_GEM_DOMAIN_CPU;
- if (IS_GEN6(dev)) {
+ if (IS_GEN6(dev) || IS_GEN7(dev)) {
/* On Gen6, we can have the GPU use the LLC (the CPU
* cache) for about a 10% performance improvement
* compared to uncached. Graphics requests other than
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm/i915: Let panel power sequencing hardware do its job
On Thu, 3 Nov 2011 12:57:08 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Modulo what we already discussed on irc about the PP_READY bit, and the
Right, the PP_READY bit requires that everything needed for PCH eDP be
running, even when you're using a CPU connected eDP panel, and so it's
not actually useful.
CodingStyle nitpicks (newlines before {? come on, this isn't X :),
Ok, I can fix that at least, even if I think it's ugly in kernel style.
I'll clean up the style and attach your R-b.
--
keith.pack...@intel.com
pgpor1NtXxKfl.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: properly prefault for pread/pwrite
On Thu, Nov 03, 2011 at 02:06:55PM -0700, Keith Packard wrote: On Mon, 24 Oct 2011 00:11:57 +0200, Daniel Vetter dan...@ffwll.ch wrote: This patch only fixes things up so that we prefault the entire page range and not just the first PAGE_SIZE bytes (i.e. at most 2 pages). So I don't see the risk of extending the current behaviour to all pages. Userspace can already see these zero writes, but only when doing something stupid. When we posted a patch to instead fix fault_in_pages_writeable, Andrew complained that we'd have modified memory even on a short read, which wasn't considered polite. Could we read/write the same value and avoid that problem? Hm, that might be a solution. My current plan was to ditch the prefault for writing to userspace and beat my pwrite/pread patches into shape for submission - the bug report only concerns -EFAULT due to handing in a gtt mapping in pwrite, afaik. otoh gem objects never change their size and we return -EINVAL if the read would go past the end of it. And userspace should also never see short reads due to signals, because the libdrm ioctl automatically restarts the syscall - and that part is more or less abi. So in practice for our case, I think it just doesn't matter because userspace really only sees these zero writes when doing something buggy. Also, we should be fixing fault_in_pages_* going forward, rather than kludging in more code. And, we'd get to remove the version in ntfs, which should end in a patch that removes more code than it adds... Hm, haven't noticed the version in nfs. The version in pagemap.h does what all the other users of it want, namely prefault at most PAGE_SIZE bytes (from at most two pages, in case the user pointer crosses a page boundary). Which is why I've left it as is. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: enable cacheable objects on Ivybridge
On Thu, Nov 03, 2011 at 02:15:13PM -0700, Jesse Barnes wrote: IVB supports these bits as well. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Oh dear, collective blindness Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Fix recursive calls to unmap
On Thu, 3 Nov 2011 20:19:23 + Dave Airlie airl...@gmail.com wrote: The solution here is to add a new flag to the call chain which gives the routines the information they need to possibly defer actions which may cause us to recurse. A macro has been defined to replace i915_gpu_idle which defaults to the old behavior. Kudos to Chris for tracking this one down. So this fixes the non-VTd case, the VT-d case still hits a recursion here, for posterity its below. Okay I take that back, I got my EL6 kernel rock stable with the correct blend of backported bits. So ignore that backtrace, however I did get another IOMMU hang on my upstream kernel with gem_linear_blits, so this should be fine to merge but I'm guessing we have more debugging to do on the VT-d cases. Dave. Does it pass your original failing case? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] DRM planes
On Thu, 3 Nov 2011 22:20:00 + Alan Cox a...@lxorguk.ukuu.org.uk wrote: We're talking about gpus, there's no way an application will talk to them than through some nice cozy abstraction layer like OpenGl, X, ... Even Wayland has gbm to do the low-level kms scanout allocation. You are talking about scanouts. Nothing more. Nothing in KMS/DRM even requires GPU accelerations. However - user space is already working in fourcc, v4l has working fourcc and dumping the mess on the user isn't going to be a win. The mess will be dumped onto userspace anyway, but it won't be dumped onto the user - that one should use Xv or some fancy EGLImage extension. Or quite likely in many embedded circumstances be working directly with buffers and FourCC. Just like happens now with V4L. FourCC has its ugly corners but its trivial to turn it into a table if you have a driver that requires this. Old hat, old problem. Solved in AmigaOS in the 1980s. Ok now does anyone want to provide reviewed-bys on this stuff so Dave will feel warm fuzzy before applying the patches? Daniel, have you been beaten down enough to acquiesce to that? Alan, does this look usable for your stuff? -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms
On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: A few comments on this one (also, is it strictly required to fix your bug)? I think so; the panel definitely was not happy when I turned the link off while the panel power was on. Having the mode setting and DPMS paths doing things in different orders definitely doesn't seem reasonable though. I nearly managed to share code between the two paths, but there are subtle differences in requirements and so I didn't bother. Ok so you're making sure the panel has power to down the link, I think that's fine. No, I'm turning the panel off *before* turning off the link. The panel goes nuts if you down the link before turning its power off; lots of technicolor. Downing the link doesn't require any communication with the panel, so there's no issue with losing connectivity at this point: ironlake_edp_backlight_off(intel_dp); ironlake_edp_panel_off(intel_dp); = panel off /* Wake up the sink first */ ironlake_edp_panel_vdd_on(intel_dp); intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_link_down(intel_dp); = link down ironlake_edp_panel_vdd_off(intel_dp, false); But here it looks like you're shutting it off, then downing the link? Should this be reordered? Nope, it's in the same order: ironlake_edp_backlight_off(intel_dp); ironlake_edp_panel_off(intel_dp); = panel off ironlake_edp_panel_vdd_on(intel_dp); intel_dp_sink_dpms(intel_dp, mode); intel_dp_link_down(intel_dp); = link down ironlake_edp_panel_vdd_off(intel_dp, false); The only difference in these two code paths is that dp_prepare turns the sink to DPMS_ON, while dp_dpms turns the sink to DPMS_OFF. -- keith.pack...@intel.com pgpqASiQRAx8M.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Try harder during dp pattern 1 link training
On Thu, 3 Nov 2011 13:03:29 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Sneaky putting this bug fix into this patch. :) Ickle already saw that, and I've split it out into a separate patch. I don't think this is necessary, but it seems like a sensible change. Don't you love the training state machine? I think this looks ok, and the DP compliance test should catch any grievous errors, so aside from the bug fix hunk which should be split out: Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org And that chunk has already been split out :-) -- keith.pack...@intel.com pgpNdGxG1REXW.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Remove trailing white space
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org Thanks for your careful patch review here. -- keith.pack...@intel.com pgpgfyj2k2GbD.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms
On Thu, 03 Nov 2011 15:30:57 -0700 Keith Packard kei...@keithp.com wrote: On Thu, 3 Nov 2011 13:00:11 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: A few comments on this one (also, is it strictly required to fix your bug)? I think so; the panel definitely was not happy when I turned the link off while the panel power was on. Having the mode setting and DPMS paths doing things in different orders definitely doesn't seem reasonable though. I nearly managed to share code between the two paths, but there are subtle differences in requirements and so I didn't bother. Ok so you're making sure the panel has power to down the link, I think that's fine. No, I'm turning the panel off *before* turning off the link. The panel goes nuts if you down the link before turning its power off; lots of technicolor. Except for VDD?? That does come on... and shouldn't be any different than a full power sequence as far as link training etc go... Downing the link doesn't require any communication with the panel, so there's no issue with losing connectivity at this point: ironlake_edp_backlight_off(intel_dp); ironlake_edp_panel_off(intel_dp); = panel off /* Wake up the sink first */ ironlake_edp_panel_vdd_on(intel_dp); intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON); intel_dp_link_down(intel_dp); = link down ironlake_edp_panel_vdd_off(intel_dp, false); But here it looks like you're shutting it off, then downing the link? Should this be reordered? Nope, it's in the same order: ironlake_edp_backlight_off(intel_dp); ironlake_edp_panel_off(intel_dp); = panel off ironlake_edp_panel_vdd_on(intel_dp); intel_dp_sink_dpms(intel_dp, mode); intel_dp_link_down(intel_dp); = link down ironlake_edp_panel_vdd_off(intel_dp, false); The only difference in these two code paths is that dp_prepare turns the sink to DPMS_ON, while dp_dpms turns the sink to DPMS_OFF. Oh missed the vdd on, which is in this path too... So I'm still confused by the panel off, vdd on sequence, but at least they're consistent. -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: Remove trailing white space
On Thu, 3 Nov 2011 13:03:49 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org I've updated the pch-edp-fixes branch with your suggestions and attached your R-b: to the reviewed patches. That leaves only the panel power sequencing changes, which could probably use more testing to make sure no existing systems stop working. I've got an ILK eDP system here that I haven't tested yet, so I can do that. I have tested SNB CPU eDP on the MacBook and CPT PCH eDP on the other system. -- keith.pack...@intel.com pgpndP2lORRff.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm: add plane support
On Thu, 3 Nov 2011 11:21:18 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 2 Nov 2011 15:33:04 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 2 Nov 2011 13:03:19 -0700
Jesse Barnes jbar...@virtuousgeek.org 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 git://people.freedesktop.org/~jbarnes/linux has a fixed
version, along with a couple of fixes for issues Chris and Dan pointed
out.
Below is the updated patch with -destroy in case this series passes
muster and Dave is ready to apply.
...and now fixed to include a disable call if an active fb is destroyed
while being used in a plane.
--
Jesse Barnes, Intel Open Source Technology Center
From 94b16917fdd846d54bc8a23765201e32ceda43bf Mon Sep 17 00:00:00 2001
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Thu, 21 Apr 2011 16:58:37 -0700
Subject: [PATCH 1/5] drm: add plane support
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 | 251 +++-
drivers/gpu/drm/drm_drv.c |3 +
include/drm/drm.h |3 +
include/drm/drm_crtc.h | 79 ++-
include/drm/drm_mode.h | 33 ++
5 files changed, 366 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fe738f0..fac8043 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -321,6 +321,7 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
{
struct drm_device *dev = fb-dev;
struct drm_crtc *crtc;
+ struct drm_plane *plane;
struct drm_mode_set set;
int ret;
@@ -337,6 +338,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
}
}
+ list_for_each_entry(plane, dev-mode_config.plane_list, head) {
+ if (plane-fb == fb) {
+ /* should turn off the crtc */
+ ret = plane-funcs-disable_plane(plane);
+ if (ret)
+ DRM_ERROR(failed to disable plane with busy
fb\n);
+ }
+ }
+
drm_mode_object_put(dev, fb-base);
list_del(fb-head);
dev-mode_config.num_fb--;
@@ -535,6 +545,48 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+void drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+ unsigned long possible_crtcs,
+ const struct drm_plane_funcs *funcs,
+ uint32_t *formats, uint32_t format_count)
+{
+ mutex_lock(dev-mode_config.mutex);
+
+ plane-dev = dev;
+ drm_mode_object_get(dev, plane-base, DRM_MODE_OBJECT_PLANE);
+ plane-funcs = funcs;
+ plane-format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+ if (!plane-format_types) {
+ DRM_DEBUG_KMS(out of memory when allocating plane\n);
+ drm_mode_object_put(dev, plane-base);
+ return;
+ }
+
+ memcpy(plane-format_types, formats, format_count);
+ plane-format_count = format_count;
+ plane-possible_crtcs = possible_crtcs;
+
+ list_add_tail(plane-head, dev-mode_config.plane_list);
+ dev-mode_config.num_plane++;
+
+ mutex_unlock(dev-mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane-dev;
+
+ mutex_lock(dev-mode_config.mutex);
+ kfree(plane-format_types);
+ drm_mode_object_put(dev, plane-base);
+ list_del(plane-head);
+ dev-mode_config.num_plane--;
+ mutex_unlock(dev-mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
/**
* drm_mode_create - create a new display mode
* @dev: DRM device
@@ -866,6 +918,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(dev-mode_config.encoder_list);
INIT_LIST_HEAD(dev-mode_config.property_list);
INIT_LIST_HEAD(dev-mode_config.property_blob_list);
+ INIT_LIST_HEAD(dev-mode_config.plane_list);
idr_init(dev-mode_config.crtc_idr);
mutex_lock(dev-mode_config.mutex);
@@ -942,6 +995,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
struct drm_encoder *encoder, *enct;
struct drm_framebuffer *fb, *fbt;
struct drm_property *property, *pt;
+ struct drm_plane *plane, *plt;
list_for_each_entry_safe(encoder, enct, dev-mode_config.encoder_list,
head) {
@@ -966,6 +1020,10 @@ void
Re: [Intel-gfx] [PATCH 1/5] drm: add plane support
On Thu, Nov 03, 2011 at 03:48:52PM -0700, Jesse Barnes wrote: On Thu, 3 Nov 2011 11:21:18 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 2 Nov 2011 15:33:04 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 2 Nov 2011 13:03:19 -0700 Jesse Barnes jbar...@virtuousgeek.org 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 git://people.freedesktop.org/~jbarnes/linux has a fixed version, along with a couple of fixes for issues Chris and Dan pointed out. Below is the updated patch with -destroy in case this series passes muster and Dave is ready to apply. ...and now fixed to include a disable call if an active fb is destroyed while being used in a plane. -- Jesse Barnes, Intel Open Source Technology Center From 94b16917fdd846d54bc8a23765201e32ceda43bf Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Thu, 21 Apr 2011 16:58:37 -0700 Subject: [PATCH 1/5] drm: add plane support 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 Ok, with the drm_framebuffer_cleanup fixed up, this looks code. I've also played around a bit with the legacy i8xx overlay, and the existing code would nicely fit into -update_plane and -disable_plane. Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Make DP prepare/commit consistent with DP dpms
On Thu, 3 Nov 2011 15:41:25 -0700, Jesse Barnes jbar...@virtuousgeek.org wrote: Except for VDD?? That does come on... and shouldn't be any different than a full power sequence as far as link training etc go... Oh, that's a good point. Doing things in this order essentially forces yet another full panel power sequence delay at this point. Hrm. I'll have to test again when I get a chance, but perhaps we can turn the sink DPMS on before we turn the panel power off. Oh missed the vdd on, which is in this path too... So I'm still confused by the panel off, vdd on sequence, but at least they're consistent. Right, I'll try doing the sink_dpms before turning the panel off; that should work just fine, and should make the sequence a bit faster. -- keith.pack...@intel.com pgpm22HqXxRcS.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
Wu Fengguang fengguang.wu at intel.com writes: 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:drm_edid_to_eld], ELD size 13, SAD count 8 It looks all sane to this point. As for where I am getting the EDID dump from, I am getting it from /sys/devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2/edid, which provides direct virtual access to the EDID response of the connected device. I'm completely confident that the device doesn't report too small of a buffer size, and that it's completely compliant with the spec: If you Agreed. have a Windows virtual machine (or if you're masochistic enough - a real machine) you should download the excellent, free Monitor Asset Manager by EnTech Taiwan from http://www.entechtaiwan.com/util/moninfo.shtm. It will let you analyze EDID + ELD + extended timings, etc from an EDID dump, such as the one taken above. It understands every part of EDID. I've put together a small archive containing my exact EDID binary dump (taken from the above device path), the FULL dmesg log, as well as EnTech's interpretation of the EDID dump, showing the full list of supported channels, formats, etc. I'm guessing there is some tiny bug in your interpretation of how to read ELD, maybe an incorrect 1 byte offset or something like that. Here's the pack: http://www.pulseforce.com/node/edid_to_eld.zip Thanks! It's great tool and information! If you do a hex analysis of my EDID dump and compare it to what the edid_to_eld function is trying to do, it will probably show what's wrong. I'd love to have a look at that myself but am really busy with a project over here so I can't help out other than to recompile and test as fast as I can. Would you install the intel-gpu-tools package and run its intel_audio_dump utility? If not shipped with your distribution, the source code is also available in git://anongit.freedesktop.org/git/xorg/app/intel-gpu-tools You'll need to install packages autotools-dev pkg-config libpciaccess-dev libdrm-dev libdrm-intel1 in order to build it from source. intel_audio_dump will dump the ELD data in the hardware buffer for use by the audio driver. By verifying if that data is correct, we are able to analyze whether and how the audio driver goes wrong. Thanks, Fengguang I have a similar receiver to Christopher, an Onkyo TX-SR507, which is the same model year, but fewer speaker outputs (5.1 instead of his I think 7.2). I had been having trouble getting ELD data to read properly, but was able to play sound (for the most part, I'll touch on that below). I have an ECS H55H-I, so the H55 chipset. The alsa generated file /proc/asound/card0/eld#3.0 used to say there was no valid ELD data and just had zeroes in all fields. Following Keith Packard's suggestion, I checked out rev 43672a0784707d795556b1f93925da8b8e797d03 (I forget how much you can truncate a git rev number and still be safe) from Linus's kernel git. git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git . I compiled and restarted and then I did get good ELD. There is a peculiar error at the end of dmesg that says [73093.946346] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 29, but the proc eld file still looks good. Despite all of that, speaker-test only gives good results with the rate set to 44100 or its multiples 88200 and 176400. 32000, 48000, 96000, 192000 do play the pink noise, but drop out intermittently. The problem seems to either cause or be an effect of the receiver losing its mind about what the incoming stream is. While it plays the 44100 speaker-test the front panel lights are locked in to PCM MULTICHANNEL HDMI. When I play 48000 the same lights come on, but every few seconds PCM and MULTICHANNEL will go off at the same time, followed by HDMI. This is when the sound cuts out, the video however remains on screen untouched. The HDMI light will come back on shortly after, followed by the PCM MULTICHANNEL and sound will resume. This was a problem before the patched kernel that I was hoping proper ELD info would clear up. I see no messages in dmesg while the skipping is occurring, nor anything interesting from HDAAnalyzer. Here are some dumps: proc/asound/card0/eld#3.0 http://pastebin.com/d3FsG8fn intel-audio-dump http://pastebin.com/f6M915Ui alsa-info http://pastebin.com/ddwNcLVL Entech output http://pastebin.com/7ENTiBrb Thanks, -Tony Olivo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: add SNB and IVB video sprite support
Hi Jesse,
It sees that there might be an overflow when crtc_w or crtc_h =0.
Following is my patch.
Thanks and best regards.
Hai Lan
From 778327daa3451f3c5f41c5db8bdccdcbf484267b Mon Sep 17 00:00:00 2001
From: Hai Lan hai@intel.com
Date: Fri, 4 Nov 2011 18:08:11 +0800
Subject: [PATCH] drm/i915:fix the overflow for overlay when crtc_w or crtc_h =0
When the crtc_w = 0 or crtc_h = 0, it should not be divided.
Besides, when (crtc_x+crtc_w)0 or (crtc_y+crtc_h)0, it should be handled.
Signed-off-by: Hai Lan hai@intel.com
---
drivers/gpu/drm/i915/intel_sprite.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0891bda..d62e8ca 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -268,17 +268,23 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
* try to scale the source if part of the visible region is offscreen.
* The caller must handle that by adjusting source offset and size.
*/
- if (crtc_x 0) {
+ if ((crtc_x 0) ((crtc_x + crtc_w)0)) {
crtc_w += crtc_x;
crtc_x = 0;
}
+ if ((crtc_x + crtc_w)0) {
+ return -EINVAL;
+ }
if (crtc_x + crtc_w primary_w)
crtc_w = primary_w - crtc_x;
- if (crtc_y 0) {
+ if ((crtc_y 0) ((crtc_y+crtc_h)0)) {
crtc_h += crtc_y;
crtc_y = 0;
}
+ if ((crtc_y+crtc_h)0) {
+ return -EINVAL;
+ }
if (crtc_y + crtc_h primary_h)
crtc_h = primary_h - crtc_y;
@@ -286,7 +292,9 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
* We can take a larger source and scale it down, but
* only so much... 16x is the max on SNB.
*/
- if (((src_w * src_h) / (crtc_w * crtc_h)) intel_plane-max_downscale)
+ if (crtc_w == 0 || crtc_h == 0)
+ return -EINVAL;
+ else if (((src_w * src_h) / (crtc_w * crtc_h))
intel_plane-max_downscale)
return -EINVAL;
/*
--
1.7.4.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
