linux/drivers/gpu, branch v3.0.4

drm/radeon: Extended DDC Probing for Toshiba L300D Radeon Mobility X1100 HDMI-A Connector

2011-08-29T20:29:15Z

commit f2b60717e692550bf753a5d64a5b69ea430fc832 upstream. Toshiba Satellite L300D with ATI Mobility Radeon X1100 sends data to i2c bus for a HDMI connector that is not implemented/existent on the notebook's board. Fix by applying extented DDC probing for this connector. Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC Lines Tested for kernel 2.6.38 on Toshiba Satellite L300D notebook BugLink: http://bugs.launchpad.net/bugs/826677 Signed-off-by: Thomas Reim Acked-by: Chris Routh Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/ttm: fix ttm_bo_add_ttm(user) failure path

2011-08-29T20:29:15Z

commit 7c4c3960dff109bc5db4c35da481c212dadb5eb5 upstream. ttm_tt_destroy kfrees passed object, so we need to nullify a reference to it. Signed-off-by: Marcin Slusarz Reviewed-by: Thomas Hellstrom Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: don't try to be smart in the hpd handler

2011-08-17T17:55:54Z

commit d5811e8731213f80c80d89e980505052f16aca1c upstream. Attempting to try and turn off disconnected display hw in the hotput handler lead to more problems than it helped. For now just register an event and only attempt the do something interesting with DP. Other connectors are just too problematic: - Some systems have an HPD pin assigned to LVDS, but it's rarely if ever connected properly and we don't really care about hpd events on LVDS anyway since it's always connected. - The HPD pin is wired up correctly for eDP, but we don't really have to do anything since the events since it's always connected. - Some HPD pins fire more than once when you connect/disconnect - etc. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=39882 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: fix regression is handling >2 heads on cedar/caicos

2011-08-17T17:55:54Z

commit 33ae1827d6c3c79c5957536ec29d5a8780623147 upstream. Need to add support for 4 crtcs when setting the possible crtcs for the encoders. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: don't enable connectors that are off in the hotplug handler

2011-08-17T17:55:54Z

commit 73104b5cfe3067d68f2c2de3f3d4d4964c55873e upstream. If we get a hotplug event on an connector that is off, don't attempt to turn it on or off, it should already be off. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=728228 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/i915: Fixup for 'Hold mode_config->mutex during hotplug'

2011-08-16T01:31:35Z

commit 40ee3381dd1010432acc13e907329029096c5bfc upstream. drm_helper_hpd_irq_event queues another work proc to go and deliver the user-space event, and that function also wants to hold the config mutex, so we shouldn't hold the mutex across the drm_helper_hpd_irq_event call. Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman

drm/i915: Hold mode_config->mutex during hotplug processing

2011-08-16T01:31:35Z

commit a65e34c79c88895766ab1f8a5afa451eed26622b upstream. Hotplug detection is a mode setting operation and must hold the struct_mutex or risk colliding with other mode setting operations. In particular, the display port hotplug function attempts to re-train the link if the monitor is supposed to be running when plugged back in. If that happens while mode setting is underway, the link will get scrambled, leaving it in an inconsistent state. This is a special case -- usually the driver mode setting entry points are covered by the upper level DRM code, but in this case the function is invoked as a work function not under the control of DRM. Signed-off-by: Keith Packard Reviewed-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri

2011-08-16T01:31:35Z

commit f3234706a77bd6e1592ae71fb3268e04cb030dba upstream. Physically-addressed hardware status pages are initialized early in the driver load process by i915_init_phys_hws. For UMS environments, the ring structure is not initialized until the X server starts. At that point, the entire ring structure is re-initialized with all new values. Any values set in the ring structure (including ring->status_page.page_addr) will be lost when the ring is re-initialized. This patch moves the initialization of the status_page.page_addr value to intel_render_ring_init_dri. Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman

drm/i915: load the LUT before pipe enable on ILK+

2011-08-16T01:31:34Z

commit 9c54c0dd948d715ccfd79e97d852f80eeb53254a upstream. Per the specs and to address https://bugs.freedesktop.org/show_bug.cgi?id=36888. Signed-off-by: Jesse Barnes Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman

drm/i915/pch: Fix integer math bugs in panel fitting

2011-08-16T01:31:34Z

commit 302983e9059e9ef5de3ca7671918eeb237c5971e upstream. Consider a 1600x900 panel, upscaling a 1360x768 mode, full-aspect. The old math would give you: scaled_width = 1600 * 768; /* 1228800 */ scaled_height = 1360 * 900; /* 1224000 */ if (scaled_width > scaled_height) { /* pillarbox, and true */ width = 1224000 / 768; /* int(1593.75) = 1593 */ x = (1600 - 1593 + 1) / 2; /* 4 */ y = 0; height = 768; } /* ... */ This is broken. The total width of scanout would then be 1593 + 4 + 4, or 1601, which is wider than the panel itself. The hardware very dutifully implements this, and you end up with a black 45° diagonal from the top-left corner to the bottom edge of the screen. It's a cool effect and all, but not what you wanted. Similar things happen for the letterbox case. The problem is that you have an integer number of pixels, which means it's usually impossible to upscale equally on both axes. 1360/768 is 1.7708, 1600/900 is 1.7777. Since we're constrained on the one axis, the other one wants to come out as an even number of pixels (the panel is almost certainly even on both axes, and the x/y offsets will be applied on both sides). In the math above, if 'width' comes out even, rounding down is correct; if it's odd, you'd rather round up. So just increment width/height in those cases. Tested on a Lenovo T500 (Ironlake). Signed-off-by: Adam Jackson Tested-By: Daniel Manrique Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851 Reviewed-by: Chris Wilson Signed-off-by: Keith Packard Signed-off-by: Greg Kroah-Hartman