Re: [Intel-gfx] 4500MHD driver crash
On July 16, 2010, Thomas Fjellstrom wrote: On July 16, 2010, Thomas Fjellstrom wrote: On July 16, 2010, Paul Menzel wrote: Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas Fjellstrom: I've been having this little problem with the intel-gfx driver for a couple months at least. Basically the xorg intel driver crashes with these errors: (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808] 1: /usr/bin/X (0x40+0x67c79) [0x467c79] 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60) [0x7ff19b2a5f60] 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x34684) [0x7ff1979ba684] 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3524a) [0x7ff1979bb24a] 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3547a) [0x7ff1979bb47a] 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X (0x40+0xd4750) [0x4d4750] 8: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x319a2) [0x7ff1979b79a2] 9: /usr/bin/X (0x40+0xd4a7e) [0x4d4a7e] 10: /usr/bin/X (0x40+0xca92e) [0x4ca92e] 11: /usr/bin/X (0x40+0x4c7a4) [0x44c7a4] 12: /usr/bin/X (0x40+0x25b4a) [0x425b4a] 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d] 14: /usr/bin/X (0x40+0x256f9) [0x4256f9] Segmentation fault at address 0x29 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting After a little google, I've found the following, seemingly similar issues: http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.html http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html This crash happens every few days, most of the time when I'm not even using the laptop, and the lid is closed, but today it happened while I was working. Was somewhat interesting to see things just disappear. I've been trying to track this issue down for a while, someone said it might be an app leaking pixmaps, but I haven't seen xrestop show more than 80MB of pixmaps for quite a while. Also, it usually occurs some time after graphics start getting really slow (though this last time I didn't really notice things getting slow). Talking a second or two for window or desktop switching. At no time was there any errors or warnings in dmesg related to this, nor was I running out of memory according to free or the plasma system load viewer applet. Usually I had 1-2GB of ram available (not including cache). At least information about the versions of the X stack you are using are missing. Doh. Yeah, I must be tired. xserver-xorg/sid uptodate 1:7.5+6 xserver-xorg-core/sid uptodate 2:1.7.7-2 xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1 libgl1-mesa-dri/experimental uptodate 7.8.2-1 libdrm-intel1/experimental uptodate 2.4.21-1 linux-kernel 2.6.34 Using debian sid+experimental to get recent intel drivers. If you do not get any answer from the developers, I recommend to proceed as documented in [1]. Thanks, Paul [1] http://intellinuxgraphics.org/how_to_report_bug.html Will do. A nice fellow on the irc channel suggested I keep an eye on the gem_objects file. It seems that when the computer is left alone, especially with the lid closed, the number of objects increases a bit: 20212 objects 325713920 object bytes 6 pinned 8445952 pin bytes 137027584 gtt bytes 234881024 gtt total Just last night, probably about 14 hours ago, X crashed (which is what prompted the first mail), and was started back up again. The number of objects then was around 19056. I just came back to my laptop to find it hung. switching to a terminal gave me a bunch of gpu hung messages, several a second. It never managed to fix
[Intel-gfx] [PATCH 1/2] drm/i915: Remove the redundant check for a fixed_panel_mode
We already checked just a couple of lines above that we have found a
fixed_panel_mode for the LVDS, so remove the surplus check.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_lvds.c | 32 +++-
1 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 0eab8df..6ef9388 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -200,27 +200,25 @@ static bool intel_lvds_mode_fixup(struct drm_encoder
*encoder,
if (dev_priv-panel_fixed_mode == NULL)
return true;
/*
-* If we have timings from the BIOS for the panel, put them in
+* 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,
* with the panel scaling set up to source from the H/VDisplay
* of the original mode.
*/
- if (dev_priv-panel_fixed_mode != NULL) {
- adjusted_mode-hdisplay = dev_priv-panel_fixed_mode-hdisplay;
- adjusted_mode-hsync_start =
- dev_priv-panel_fixed_mode-hsync_start;
- adjusted_mode-hsync_end =
- dev_priv-panel_fixed_mode-hsync_end;
- adjusted_mode-htotal = dev_priv-panel_fixed_mode-htotal;
- adjusted_mode-vdisplay = dev_priv-panel_fixed_mode-vdisplay;
- adjusted_mode-vsync_start =
- dev_priv-panel_fixed_mode-vsync_start;
- adjusted_mode-vsync_end =
- dev_priv-panel_fixed_mode-vsync_end;
- adjusted_mode-vtotal = dev_priv-panel_fixed_mode-vtotal;
- adjusted_mode-clock = dev_priv-panel_fixed_mode-clock;
- drm_mode_set_crtcinfo(adjusted_mode, CRTC_INTERLACE_HALVE_V);
- }
+ adjusted_mode-hdisplay = dev_priv-panel_fixed_mode-hdisplay;
+ adjusted_mode-hsync_start =
+ dev_priv-panel_fixed_mode-hsync_start;
+ adjusted_mode-hsync_end =
+ dev_priv-panel_fixed_mode-hsync_end;
+ adjusted_mode-htotal = dev_priv-panel_fixed_mode-htotal;
+ adjusted_mode-vdisplay = dev_priv-panel_fixed_mode-vdisplay;
+ adjusted_mode-vsync_start =
+ dev_priv-panel_fixed_mode-vsync_start;
+ adjusted_mode-vsync_end =
+ dev_priv-panel_fixed_mode-vsync_end;
+ adjusted_mode-vtotal = dev_priv-panel_fixed_mode-vtotal;
+ adjusted_mode-clock = dev_priv-panel_fixed_mode-clock;
+ drm_mode_set_crtcinfo(adjusted_mode, CRTC_INTERLACE_HALVE_V);
/* Make sure pre-965s set dither correctly */
if (!IS_I965G(dev)) {
--
1.7.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Refactor panel fitting on the LVDS.
Move the common routines into separate functions to not only increase
readability, but also throwaway surplus code.
In doing so, we review the calculation of the aspect preserving scaling
and avoid the use of fixed-point until we need to calculate the accurate
scale factor.
1 files changed, 128 insertions(+), 194 deletions(-)
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_lvds.c | 322 +++--
1 files changed, 128 insertions(+), 194 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 6ef9388..eab6a3a 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -156,31 +156,92 @@ static int intel_lvds_mode_valid(struct drm_connector
*connector,
return MODE_OK;
}
+static void
+centre_horizontally(struct drm_display_mode *mode,
+ int width)
+{
+ u32 border, sync_pos, blank_width, sync_width;
+
+ sync_width = mode-crtc_hsync_end - mode-crtc_hsync_start;
+ blank_width = mode-crtc_hblank_end - mode-crtc_hblank_start;
+
+ border = (mode-hdisplay - width) / 2;
+
+ if (mode-hdisplay 1) /* odd resolutions */
+ border++;
+
+ /* keep the border be even */
+ if (border 1)
+ border++;
+
+ mode-crtc_hdisplay = width;
+ mode-crtc_hblank_start = width + border;
+ /* keep the hblank width constant */
+ mode-crtc_hblank_end =
+ mode-crtc_hblank_start + blank_width;
+
+ /* get the hsync start pos relative to hblank start */
+ sync_pos = (blank_width - sync_width) / 2;
+ /* keep the hsync_pos be even */
+ if (sync_pos 1)
+ sync_pos++;
+
+ /* keep hsync width constant */
+ mode-crtc_hsync_start = mode-crtc_hblank_start + sync_pos;
+ mode-crtc_hsync_end = mode-crtc_hsync_start + sync_width;
+}
+
+static void
+centre_vertically(struct drm_display_mode *mode,
+ int height)
+{
+ u32 border, sync_pos, blank_width, sync_width;
+
+ sync_width = mode-crtc_vsync_end - mode-crtc_vsync_start;
+ blank_width = mode-crtc_vblank_end - mode-crtc_vblank_start;
+
+ border = (mode-vdisplay - height) / 2;
+
+ if (mode-vdisplay 1)
+ border++;
+
+ mode-crtc_vdisplay = height;
+ mode-crtc_vblank_start = height + border;
+ /* keep the vblank width constant */
+ mode-crtc_vblank_end = mode-crtc_vblank_start + blank_width;
+
+ /* get the vsync start pos relative to vblank start */
+ sync_pos = (blank_width - sync_width) / 2;
+
+ /* keep the vsync width constant */
+ mode-crtc_vsync_start = mode-crtc_vblank_start + sync_pos;
+ mode-crtc_vsync_end = mode-crtc_vsync_start + sync_width;
+}
+
+static inline u32 panel_fitter_scaling(u32 source, u32 target)
+{
+ /*
+* Floating point operation is not supported. So the FACTOR
+* is defined, which can avoid the floating point computation
+* when calculating the panel ratio.
+*/
+#define ACCURACY 12
+#define FACTOR (1 ACCURACY)
+ u32 ratio = source * FACTOR / target;
+ return (FACTOR * (ratio + FACTOR/2)) / FACTOR;
+}
+
static bool intel_lvds_mode_fixup(struct drm_encoder *encoder,
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_encoder *intel_encoder = enc_to_intel_encoder(encoder);
struct intel_lvds_priv *lvds_priv = intel_encoder-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;
- u32 hsync_width, vsync_width;
- u32 hblank_width, vblank_width;
- u32 hsync_pos, vsync_pos;
+ u32 pfit_control = 0, pfit_pgm_ratios = 0, border = 0;
/* Should never happen!! */
if (!IS_I965G(dev) intel_crtc-pipe == 0) {
@@ -228,11 +289,8 @@ static bool intel_lvds_mode_fixup(struct drm_encoder
*encoder,
/* Native modes don't need fitting */
if (adjusted_mode-hdisplay == mode-hdisplay
- adjusted_mode-vdisplay == mode-vdisplay) {
- pfit_pgm_ratios = 0;
- border = 0;
+
[Intel-gfx] [PATCH 2/2] drm/i915: Remove extraneous variables from intel_crtc_page_flip()
Reduce the number of variables used and improve readability by scoping.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 31 +++
1 files changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b3b5ff0..bb3941e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4879,15 +4879,12 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
{
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj_priv;
struct drm_gem_object *obj;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_unpin_work *work;
unsigned long flags;
- int pipesrc_reg = (intel_crtc-pipe == 0) ? PIPEASRC : PIPEBSRC;
- int ret, pipesrc;
- u32 flip_mask;
+ int ret;
work = kzalloc(sizeof *work, GFP_KERNEL);
if (work == NULL)
@@ -4895,8 +4892,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
work-event = event;
work-dev = crtc-dev;
- intel_fb = to_intel_framebuffer(crtc-fb);
- work-old_fb_obj = intel_fb-obj;
+ work-old_fb_obj = to_intel_framebuffer(crtc-fb)-obj;
INIT_WORK(work-work, intel_unpin_work_fn);
/* We borrow the event spin lock for protecting unpin_work */
@@ -4911,8 +4907,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
intel_crtc-unpin_work = work;
spin_unlock_irqrestore(dev-event_lock, flags);
- intel_fb = to_intel_framebuffer(fb);
- obj = intel_fb-obj;
+ obj = to_intel_framebuffer(fb)-obj;
mutex_lock(dev-struct_mutex);
ret = intel_pin_and_fence_fb_obj(dev, obj);
@@ -4936,24 +4931,28 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
atomic_inc(obj_priv-pending_flip);
work-pending_flip_obj = obj;
- if (intel_crtc-plane)
- flip_mask = I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
- else
- flip_mask = I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT;
+ if (IS_GEN3(dev)) {
+ u32 flip_mask;
+
+ if (intel_crtc-plane)
+ flip_mask = I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT;
+ else
+ flip_mask = I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT;
- /* Wait for any previous flip to finish */
- if (IS_GEN3(dev))
+ /* Wait for any previous flip to finish */
while (I915_READ(ISR) flip_mask)
;
+ }
BEGIN_LP_RING(4);
if (IS_I965G(dev)) {
+ int pipesrc_reg = (intel_crtc-pipe == 0) ? PIPEASRC : PIPEBSRC;
+
OUT_RING(MI_DISPLAY_FLIP |
MI_DISPLAY_FLIP_PLANE(intel_crtc-plane));
OUT_RING(fb-pitch);
OUT_RING(obj_priv-gtt_offset | obj_priv-tiling_mode);
- pipesrc = I915_READ(pipesrc_reg);
- OUT_RING(pipesrc 0x0fff0fff);
+ OUT_RING(I915_READ(pipesrc_reg) 0x0fff0fff);
} else {
OUT_RING(MI_DISPLAY_FLIP_I915 |
MI_DISPLAY_FLIP_PLANE(intel_crtc-plane));
--
1.7.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 4500MHD driver crash
On July 17, 2010, Thomas Fjellstrom wrote: On July 16, 2010, Thomas Fjellstrom wrote: On July 16, 2010, Thomas Fjellstrom wrote: On July 16, 2010, Paul Menzel wrote: Am Freitag, den 16.07.2010, 01:50 -0600 schrieb Thomas Fjellstrom: I've been having this little problem with the intel-gfx driver for a couple months at least. Basically the xorg intel driver crashes with these errors: (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory (WW) intel(0): i830_uxa_prepare_access: gtt bo map failed: Cannot allocate memory Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x466808] 1: /usr/bin/X (0x40+0x67c79) [0x467c79] 2: /lib/libpthread.so.0 (0x7ff19b297000+0xef60) [0x7ff19b2a5f60] 3: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x34684) [0x7ff1979ba684] 4: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3524a) [0x7ff1979bb24a] 5: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x3547a) [0x7ff1979bb47a] 6: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x36a1b) [0x7ff1979bca1b] 7: /usr/bin/X (0x40+0xd4750) [0x4d4750] 8: /usr/lib/xorg/modules/drivers/intel_drv.so (0x7ff197986000+0x319a2) [0x7ff1979b79a2] 9: /usr/bin/X (0x40+0xd4a7e) [0x4d4a7e] 10: /usr/bin/X (0x40+0xca92e) [0x4ca92e] 11: /usr/bin/X (0x40+0x4c7a4) [0x44c7a4] 12: /usr/bin/X (0x40+0x25b4a) [0x425b4a] 13: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ff199d9bc4d] 14: /usr/bin/X (0x40+0x256f9) [0x4256f9] Segmentation fault at address 0x29 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting After a little google, I've found the following, seemingly similar issues: http://www.pubbs.net/201001/mandriva/43247-cooker-x-crashing.html http://lists.opensuse.org/opensuse-bugs/2010-04/msg01805.html This crash happens every few days, most of the time when I'm not even using the laptop, and the lid is closed, but today it happened while I was working. Was somewhat interesting to see things just disappear. I've been trying to track this issue down for a while, someone said it might be an app leaking pixmaps, but I haven't seen xrestop show more than 80MB of pixmaps for quite a while. Also, it usually occurs some time after graphics start getting really slow (though this last time I didn't really notice things getting slow). Talking a second or two for window or desktop switching. At no time was there any errors or warnings in dmesg related to this, nor was I running out of memory according to free or the plasma system load viewer applet. Usually I had 1-2GB of ram available (not including cache). At least information about the versions of the X stack you are using are missing. Doh. Yeah, I must be tired. xserver-xorg/sid uptodate 1:7.5+6 xserver-xorg-core/sid uptodate 2:1.7.7-2 xserver-xorg-video-intel/experimental uptodate 2:2.12.0-1 libgl1-mesa-dri/experimental uptodate 7.8.2-1 libdrm-intel1/experimental uptodate 2.4.21-1 linux-kernel 2.6.34 Using debian sid+experimental to get recent intel drivers. If you do not get any answer from the developers, I recommend to proceed as documented in [1]. Thanks, Paul [1] http://intellinuxgraphics.org/how_to_report_bug.html Will do. A nice fellow on the irc channel suggested I keep an eye on the gem_objects file. It seems that when the computer is left alone, especially with the lid closed, the number of objects increases a bit: 20212 objects 325713920 object bytes 6 pinned 8445952 pin bytes 137027584 gtt bytes 234881024 gtt total Just last night, probably about 14 hours ago, X crashed (which is what prompted the first mail), and was started back up again. The number of objects
Re: [Intel-gfx] [PATCH 1/2] drm: Return EBUSY if the framebuffer is unbound when flipping.
On Sat, 17 Jul 2010 20:23:26 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: It looks like there is a race condition between unbinding a framebuffer on a hotplug event and user space trying to flip: Nice, yeah that would definitely be a problem. Alternately we could solder everyone's configuration into something they couldn't change. :) Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix panel fitting regression since 734b4157
On Sat, 17 Jul 2010 12:46:08 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: The crtc mode fixup is run after the encoders adjust the mode to fit on their output, so don't reset the mode! Fixes: Bug 29057 - display corruption under 800x600 on netbook (1024x600) with 'Full Aspect' scaling https://bugs.freedesktop.org/show_bug.cgi?id=29057 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_display.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 68dcf36..77e1c75 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2356,8 +2356,6 @@ static bool intel_crtc_mode_fixup(struct drm_crtc *crtc, if (mode-clock * 3 27000 * 4) return MODE_CLOCK_HIGH; } - - drm_mode_set_crtcinfo(adjusted_mode, 0); return true; } Wow old breakage, I guess we don't test the other fitting modes very well. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ 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: Refactor panel fitting on the LVDS.
On Sat, 17 Jul 2010 13:38:44 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: Move the common routines into separate functions to not only increase readability, but also throwaway surplus code. In doing so, we review the calculation of the aspect preserving scaling and avoid the use of fixed-point until we need to calculate the accurate scale factor. 1 files changed, 128 insertions(+), 194 deletions(-) Nice cleanups, that function was getting too big... misc nitpicks below. + /* keep the border be even */ + if (border 1) + border++; May as well fix the comment here or combine it with the above. There are a few other comments like this elsewhere too. While you're in there it would also be cool to write a small CRTC mode verification function that checks the htotal/vtotal/etc against the constraints documented in the manual (e.g. sync before end, active divisible by 2 in ganged mode, etc). If you're feeling adventurous anyway. :) Other than that: Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
