Re: [PATCH 6/6] drm/i915: Fix lock order reversal in GEM relocation entry copying. -- makes X hang
On Tue, 31 Mar 2009 12:36:56 -0700 Eric Anholt e...@anholt.net wrote: Ouch. Could you file a bug report using: http://intellinuxgraphics.org/how_to_report_bug.html so I've got the information I need to try to reproduce this? shure. done. http://bugs.freedesktop.org/show_bug.cgi?id=20985 thx, Florian p.s. hope i didn't miss some vital piece of information? signature.asc Description: PGP signature -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20856] X hangs after idle time on GM45
http://bugs.freedesktop.org/show_bug.cgi?id=20856 --- Comment #2 from David John david...@mail.com 2009-03-31 23:37:34 PST --- (In reply to comment #1) Bugs like this have been fixed recently in libdrm, Mesa and the kernel. But you can also work around the problem by creating a driconf file and setting the vblank_mode (googling around should show you how). I'll try that. Thanks, Jesse. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12899] Crash in i915.ko: i915_driver_irq_handler
http://bugzilla.kernel.org/show_bug.cgi?id=12899 --- Comment #4 from Helge Bahmann helge.bahm...@secunet.com 2009-04-01 11:40:40 --- To my knowledge, the code is unchanged, but maybe I can invest some time into investigating further tomorrow to produce a patch I am more confident of -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 + buffer creation
Am Dienstag, 31. März 2009 22:03:45 schrieb Ian Romanick: Errthis is a bandaid on a bigger problem. What about 24-bit depth with 16-bit color? What about when we start to support multisampling? Etc. If the DDX needs the fbconfig information, why not just give it the fbconfig? Right? Some cards even support floating point depth buffers afaik. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 20954] mesa/drm(git): kernel panic with radeon driver (Radeon 9500 Pro )
http://bugs.freedesktop.org/show_bug.cgi?id=20954 --- Comment #2 from Rafael Antonio Porras Samaniego sp...@distrobit.net 2009-04-01 11:36:22 PST --- (In reply to comment #1) I just moved the vblank_cleanup after lastclose, give that a try and see if it is resolved. No, the same kernel panic still appears. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: cache the EDID information of the LVDS
On Fri, 2009-03-27 at 22:01 -0700, Arjan van de Ven wrote: On Fri, 27 Mar 2009 16:08:18 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: return ret; I definitely like the idea of caching the LVDS EDID, but rather than adding it to the intel_output struct I'd rather see it stored with the rest of the LVDS stuff in i915_private (though that stuff should be pulled out into an output private at some point). We could also just open code the intel_ddc_get_modes stuff in intel_lvds_init, getting the EDID just once, storing the property once, and adding the mode list once. intel_lvds_get_modes would need to be fixed too... that gets a bit messy though, esp if other output types decide to also want to cache. Remember that some of this code gets called from DRM or even userland, so the edid will end up being stored in a generic structure Ack. SDVO LVDS and eDP would also want to do this, and i915_private then seems like the wrong place. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Cache the EDID value for a short time in i915
On Mon, 2009-03-16 at 19:36 -0700, Arjan van de Ven wrote: From 8ad1bd63c097f9f6948439c1ce7c0b17b8caa64a Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 16 Mar 2009 19:31:39 -0700 Subject: [PATCH] drm: Cache the EDID value for a short time in i915 during the boot process we have several places that want to make sure we have EDID information in a short time. An EDID probe for me takes 0.23 seconds, so doing multiple of them is not very nice. This patch caches the EDID result for upto 1 second to avoid repeated delays. Signed-off-by: Arjan van de Ven ar...@linux.intel.com I'm holding off on this one. I'm applying the LVDS caching (makes complete sense) but I think someone needs to take a serious look at the requests for modes on outputs by the kernel and be sure that we've separated I want you go to reprobe and then tell me the current data from tell me what the current set of modes is. Once that's done, I expect this patch goes away. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 1/3_v2]: [DRM/I915] : Sync the mode validation for INTERLACE/DBLSCAN
On Mon, 2009-03-23 at 11:15 +0800, yakui_zhao wrote:
Subject: [DRM/I915]: Sync the mode validation for INTERLACE/DBLSCAN
From: Zhao Yakui yakui.z...@intel.com
Sync the mode validation for INTERLACE/DBLSCAN
This covers:
Check whether the INTERLACE/DBLSCAN is supported by output device. If
not, the mode containing the flag of INTERLACE/DBLSCAN will be marked
as unsupported.
Fix the code-style based on Eric's suggestion
Signed-off-by: Zhao Yakui yakui.z...@intel.com
The commit message here should look like:
drm: Sync the mode validation for INTERLACE/DBLSCAN
Check whether the INTERLACE/DBLSCAN is supported by output device. If
not, the mode containing the flag of INTERLACE/DBLSCAN will be marked
as unsupported.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
(drm: not drm/i915: since it doesn't touch i915 at all, and you've got
lines duplicated, strangely indented, and a line about a change in this
commit to the previous revision of the commit instead of about what this
code does compared to the code it's changing)
The drm versus drm/i915: is an important signal to me for whether it
should go through my tree or airlied's.
---
drivers/gpu/drm/drm_crtc_helper.c | 29 +
1 file changed, 29 insertions(+)
Index: linux-2.6/drivers/gpu/drm/drm_crtc_helper.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_crtc_helper.c 2009-03-23
09:29:59.0 +0800
+++ linux-2.6/drivers/gpu/drm/drm_crtc_helper.c 2009-03-23
11:13:43.0 +0800
@@ -42,6 +42,25 @@
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
};
+static void drm_mode_validate_flag(struct drm_connector *connector,
+int flags)
+{
+ struct drm_display_mode *mode, *t;
Usually we put a blank line between declarations and code.
+ if (flags == (DRM_MODE_FLAG_DBLSCAN | DRM_MODE_FLAG_INTERLACE))
+ return;
+
+ list_for_each_entry_safe(mode, t, connector-modes, head) {
+ if ((mode-flags DRM_MODE_FLAG_INTERLACE)
+ !(flags DRM_MODE_FLAG_INTERLACE))
+ mode-status = MODE_NO_INTERLACE;
+ if ((mode-flags DRM_MODE_FLAG_DBLSCAN)
+ !(flags DRM_MODE_FLAG_DBLSCAN))
+ mode-status = MODE_NO_DBLESCAN;
+ }
+
+ return;
+}
+
/**
* drm_helper_probe_connector_modes - get complete set of display modes
* @dev: DRM device
@@ -72,6 +91,7 @@
struct drm_connector_helper_funcs *connector_funcs =
connector-helper_private;
int count = 0;
+ int mode_flags = 0;
DRM_DEBUG(%s\n, drm_get_connector_name(connector));
/* set all modes to the unverified state */
@@ -96,6 +116,15 @@
if (maxX maxY)
drm_mode_validate_size(dev, connector-modes, maxX,
maxY, 0);
+
+ {
+ if (connector-interlace_allowed)
+ mode_flags |= DRM_MODE_FLAG_INTERLACE;
+ if (connector-doublescan_allowed)
+ mode_flags |= DRM_MODE_FLAG_DBLSCAN;
+ drm_mode_validate_flag(connector, mode_flags);
+ }
+
Why is this mysteriously in a new block?
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 3/3_v2]: [DRM/I915] : Sync the default modes for LVDS output device
On Mon, 2009-03-23 at 11:30 +0800, yakui_zhao wrote: Subject: [DRM/I915]: Sync the default modes for LVDS output device From: Zhao Yakui yakui.z...@intel.com Sync the default modes for the LVDS output device This covers: Add the default modes for the LVDS output device. The bit of edid-feature.msc indicates whether the display device is not continous-frequency. And it is used to determine whether the default modes will be added to the output device. But for the LVDS output device the edid-feature.msc will always be set.Even when there is no edid, the correponding bit in the fake edid will be set. In such case the default modes will be added to LVDS output device. If not, the different modes are obtained by using KMS/UMS. Signed-off-by: Zhao Yakui yakui.z...@intel.com These giant tables of modes are insane. Especially having a bunch of different refresh rates when the LVDS actually has a fixed refresh rate. Just generate a mode at each appropriate size using GTF or CVT. I'm not really sold on the whole idea of the kernel generating these fake modes for LVDS, given that we can support any size and that the refresh rate is a lie since we're always using the fixed mode. Any other opinions on this? -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 2/3_v2]: [DRM/I915] : Sync the panel fitting property with 2D driver
On Mon, 2009-03-23 at 11:21 +0800, yakui_zhao wrote:
Subject: DRM/I915: Sync the panel fitting property with 2D driver
From: Zhao Yakui yakui.z...@intel.com
Sync the panel fitting property with 2D driver
This covers:
a. create the scaling mode property and attach it to LVDS
b. add the support of panel fitting property for LVDS
c. update the display mode according to the panel fitting mode
Fix the code-style based on Eric's suggestion.
checkpatch.pl, commit message in your email is mangled (compare your
output to git send-email. Or just use git send-email), and please keep
using kzalloc/kfree.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 16 ++
drivers/gpu/drm/i915/intel_lvds.c | 282
+++---
2 files changed, 277 insertions(+), 21 deletions(-)
Index: linux-2.6/drivers/gpu/drm/i915/i915_reg.h
===
--- linux-2.6.orig/drivers/gpu/drm/i915/i915_reg.h2009-03-23
11:08:45.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/i915_reg.h 2009-03-23 11:09:37.0
+0800
@@ -808,9 +808,25 @@
#define HORIZ_INTERP_MASK (3 6)
#define HORIZ_AUTO_SCALE (1 5)
#define PANEL_8TO6_DITHER_ENABLE (1 3)
+#define PFIT_FILTER_FUZZY (0 24)
+#define PFIT_SCALING_AUTO (0 26)
+#define PFIT_SCALING_PROGRAMMED (1 26)
+#define PFIT_SCALING_PILLAR(2 26)
+#define PFIT_SCALING_LETTER(3 26)
#define PFIT_PGM_RATIOS 0x61234
#define PFIT_VERT_SCALE_MASK 0xfff0
#define PFIT_HORIZ_SCALE_MASK 0xfff0
+/* Pre-965 */
+#define PFIT_VERT_SCALE_SHIFT 20
+#define PFIT_VERT_SCALE_MASK0xfff0
+#define PFIT_HORIZ_SCALE_SHIFT 4
+#define PFIT_HORIZ_SCALE_MASK 0xfff0
+/* 965+ */
+#define PFIT_VERT_SCALE_SHIFT_965 16
+#define PFIT_VERT_SCALE_MASK_9650x1fff
+#define PFIT_HORIZ_SCALE_SHIFT_965 0
+#define PFIT_HORIZ_SCALE_MASK_965 0x1fff
+
#define PFIT_AUTO_RATIOS 0x61238
/* Backlight control */
Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===
--- linux-2.6.orig/drivers/gpu/drm/i915/intel_lvds.c 2009-03-23
11:08:45.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/intel_lvds.c 2009-03-23
11:19:40.0 +0800
@@ -37,6 +37,21 @@
#include i915_drm.h
#include i915_drv.h
+/*
+ * the following four scaling options are defined.
+ * #define DRM_MODE_SCALE_NON_GPU0
+ * #define DRM_MODE_SCALE_FULLSCREEN 1
+ * #define DRM_MODE_SCALE_NO_SCALE 2
+ * #define DRM_MODE_SCALE_ASPECT 3
+ */
+
+/* Private structure for the integrated LVDS support */
+struct intel_lvds_priv {
+ int fitting_mode;
+ u32 pfit_control;
+ u32 pfit_pgm_ratios;
+};
+
/**
* Sets the backlight level.
*
@@ -160,10 +175,24 @@
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
{
+ /*
+ * float point operation is not supported . So the PANEL_RATIO_FACTOR
+ * is defined, which can avoid the float point computation when
+ * calculating the panel ratio.
+ */
+#define PANEL_RATIO_FACTOR 8192
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder-crtc);
struct drm_encoder *tmp_encoder;
+ struct intel_output *intel_output = enc_to_intel_output(encoder);
+ struct intel_lvds_priv *lvds_priv = intel_output-dev_priv;
+ u32 pfit_control = 0, pfit_pgm_ratios = 0;
+ int left_border = 0, right_border = 0, top_border = 0;
+ int bottom_border = 0;
+ bool border = 0;
+ int panel_ratio, desired_ratio, vert_scale, horiz_scale;
+ int horiz_ratio, vert_ratio;
/* Should never happen!! */
if (!IS_I965G(dev) intel_crtc-pipe == 0) {
@@ -179,7 +208,9 @@
return false;
}
}
-
+ /* If we don't have a panel mode, there is nothing we can do */
+ if (dev_priv-panel_fixed_mode == NULL)
+ return true;
/*
* If we have timings from the BIOS for the panel, put them in
* to the adjusted mode. The CRTC will be set up for this mode,
@@ -203,6 +234,191 @@
drm_mode_set_crtcinfo(adjusted_mode, CRTC_INTERLACE_HALVE_V);
}
+ /* Make sure pre-965s set dither correctly */
+ if (!IS_I965G(dev)) {
+ if (dev_priv-panel_wants_dither || dev_priv-lvds_dither)
+ pfit_control |= PANEL_8TO6_DITHER_ENABLE;
+ }
+
+ /* Native modes don't need
Re: [Patch 3/3_v2]: [DRM/I915] : Sync the default modes for LVDS output device
On 4/1/09, Eric Anholt e...@anholt.net wrote: On Mon, 2009-03-23 at 11:30 +0800, yakui_zhao wrote: Subject: [DRM/I915]: Sync the default modes for LVDS output device From: Zhao Yakui yakui.z...@intel.com Sync the default modes for the LVDS output device This covers: Add the default modes for the LVDS output device. The bit of edid-feature.msc indicates whether the display device is not continous-frequency. And it is used to determine whether the default modes will be added to the output device. But for the LVDS output device the edid-feature.msc will always be set.Even when there is no edid, the correponding bit in the fake edid will be set. In such case the default modes will be added to LVDS output device. If not, the different modes are obtained by using KMS/UMS. Signed-off-by: Zhao Yakui yakui.z...@intel.com These giant tables of modes are insane. Especially having a bunch of different refresh rates when the LVDS actually has a fixed refresh rate. Just generate a mode at each appropriate size using GTF or CVT. I'm not really sold on the whole idea of the kernel generating these fake modes for LVDS, given that we can support any size and that the refresh rate is a lie since we're always using the fixed mode. Any other opinions on this? Maybe a common drm mode function helper that will add a bunch of common (4:3 and 16:9) modes that fixed mode encoders like LVDS can call. We certainly don't need to add modes with differing refresh rates. Alex -- Eric Anholt e...@anholt.net eric.anh...@intel.com -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch 3/3_v2]: [DRM/I915] : Sync the default modes for LVDS output device
On Wed, 01 Apr 2009 13:27:02 -0700 Eric Anholt e...@anholt.net wrote: On Mon, 2009-03-23 at 11:30 +0800, yakui_zhao wrote: Subject: [DRM/I915]: Sync the default modes for LVDS output device From: Zhao Yakui yakui.z...@intel.com Sync the default modes for the LVDS output device This covers: Add the default modes for the LVDS output device. The bit of edid-feature.msc indicates whether the display device is not continous-frequency. And it is used to determine whether the default modes will be added to the output device. But for the LVDS output device the edid-feature.msc will always be set.Even when there is no edid, the correponding bit in the fake edid will be set. In such case the default modes will be added to LVDS output device. If not, the different modes are obtained by using KMS/UMS. Signed-off-by: Zhao Yakui yakui.z...@intel.com These giant tables of modes are insane. Especially having a bunch of different refresh rates when the LVDS actually has a fixed refresh rate. Just generate a mode at each appropriate size using GTF or CVT. I'm not really sold on the whole idea of the kernel generating these fake modes for LVDS, given that we can support any size and that the refresh rate is a lie since we're always using the fixed mode. Any other opinions on this? Yeah, having a bunch of hard coded modes seems like the wrong way to do things here. We can support arbitrary sizes with panel fitting and/or borders, so using CVT or GTF seems like a good idea. Question is, how do we indicate this to userland? Ideally we'd just export a CVT/GTF flag and allow just about any mode to be sent down at mode set time, but that would probably mean changes to the way we handle modes in the DRM core. Alternately, we could export the flag and let userland load custom modes before using them (that would match the mode list handling we have). -- Jesse Barnes, Intel Open Source Technology Center -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [Patch 3/3_v2]: [DRM/I915] : Sync the default modes for LVDS output device
On Wed, 2009-04-01 at 13:27 -0700, Eric Anholt wrote: I'm not really sold on the whole idea of the kernel generating these fake modes for LVDS, given that we can support any size and that the refresh rate is a lie since we're always using the fixed mode. Any other opinions on this? It would be nice if KMS could expose the hardware a bit more accurately; knowing that the device has a scaler with specific size limits would allow user space to know what was possible far more succinctly than a huge list of modes. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Cache the EDID value for a short time in i915
On Wed, 01 Apr 2009 12:38:17 -0700 Eric Anholt e...@anholt.net wrote: On Mon, 2009-03-16 at 19:36 -0700, Arjan van de Ven wrote: From 8ad1bd63c097f9f6948439c1ce7c0b17b8caa64a Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 16 Mar 2009 19:31:39 -0700 Subject: [PATCH] drm: Cache the EDID value for a short time in i915 during the boot process we have several places that want to make sure we have EDID information in a short time. An EDID probe for me takes 0.23 seconds, so doing multiple of them is not very nice. This patch caches the EDID result for upto 1 second to avoid repeated delays. Signed-off-by: Arjan van de Ven ar...@linux.intel.com I'm holding off on this one. I'm applying the LVDS caching (makes complete sense) but I think someone needs to take a serious look at the requests for modes on outputs by the kernel and be sure that we've separated I want you go to reprobe and then tell me the current data from tell me what the current set of modes is. Once that's done, I expect this patch goes away. for me the caching patch obsoletes this one, so absolutely fine by me. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
