summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAgeFilesLines
...
* drm/radeon: Extended DDC Probing for Connectors with Improperly Wired DDC ↵Thomas Reim2011-08-044-12/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lines (here: Asus M2A-VM HDMI) Some integrated ATI Radeon chipset implementations with add-on HDMI card (e. g. Asus M2A-VM HDMI) indicate the availability of a DDC even when the add-on card is not plugged in or HDMI is disabled in BIOS setup. In this case, drm_get_edid() and drm_edid_block_valid() periodically dump data and kernel errors into system log files and onto terminals. For these connectors DDC probing is extended by a check for a correct EDID header. Only in case a valid EDID header is also found, the (HDMI or DVI) connector will be used by the Radeon driver. This prevents the kernel driver from useless flooding of logs and terminal sessions with EDID dumps and error messages. This patch adds a flag 'requires_extended_probe' to the radeon_connector structure. In function radeon_connector_needs_extended_probe() this flag can be set on a chipset family/vendor/connector type specific basis. In addition, function radeon_ddc_probe() has been adapted to perform extended DDC probing if required by the connector's flag. Requires function drm_edid_header_is_valid() in DRM module provided by [PATCH] drm: Separate EDID Header Check from EDID Block Check. Tested for kernel 2.6.35, 2.6.38 and 3.0 on Asus M2A-VM HDMI board BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=668196 BugLink: http://bugs.launchpad.net/bugs/7228066 Cc: <stable@kernel.org> Signed-off-by: Thomas Reim <reimth@gmail.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Separate EDID Header Check from EDID Block CheckThomas Reim2011-08-041-6/+18
| | | | | | | | | | | | | | | | Provides function drm_edid_header_is_valid() for EDID header check and replaces EDID header check part of function drm_edid_block_valid() by a call of drm_edid_header_is_valid(). This is a prerequisite to extend DDC probing, e. g. in function radeon_ddc_probe() for Radeon devices, by a central EDID header check. Tested for kernel 2.6.35, 2.6.38 and 3.0 Cc: <stable@kernel.org> Signed-off-by: Thomas Reim <reimth@gmail.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Add NULL check about irq functionsJoonyoung Shim2011-08-041-8/+15
| | | | | | | | | | The struct drm_driver has some function pointers for irq. They are gpu specific and some functions aren't essential things. This can prevents creation of unnecessary dummy function for irq. Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Fix irq install error handlingJoonyoung Shim2011-08-041-0/+3
| | | | | | | | | | | | The registered irq should be unregistered by free_irq() if irq_postinstall() returns the error after request_irq() is called successfully. [airlied: add vga switcheroo disable] Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon: fix potential NULL dereference in drivers/gpu/drm/radeon/atom.cBojan Prtvar2011-08-041-0/+3
| | | | | | | kzalloc() can return NULL, so I added check for it Signed-off-by: Bojan Prtvar <prtvar.b@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon: clean reg header filesFernando Luis Vázquez Cao2011-08-041-0/+1
| | | | | | | | Reg header files are generated so they are not cleaned automagically. They need to be added to the clean-files list. Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/debugfs: Initialise empty variableEmil Velikov2011-08-041-1/+3
| | | | | | | [airlied: move char declaration] Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'drm-intel-next' of ↵Dave Airlie2011-08-0416-104/+591
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6 into drm-fixes * 'drm-intel-next' of ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6: (42 commits) drm/i915: allow cache sharing policy control drm/i915/hdmi: HDMI source product description infoframe support drm/i915/hdmi: split infoframe setting from infoframe type code drm: track CEA version number if present drm/i915: Try enabling RC6 by default (again) Revert "drm/i915/dp: Zero the DPCD data before connection probe" drm/i915/dp: wait for previous AUX channel activity to clear drm/i915: don't use uninitialized EDID bpc values when picking pipe bpp drm/i915/pch: Save/restore PCH_PORT_HOTPLUG across suspend drm/i915: apply phase pointer override on SNB+ too drm/i915: Add quirk to disable SSC on Sony Vaio Y2 drm/i915: provide more error output when mode sets fail drm/i915: add GPU max frequency control file i915: add Dell OptiPlex FX170 to intel_no_lvds drm/i915: Ignore GPU wedged errors while pinning scanout buffers drm/i915/hdmi: send AVI info frames on ILK+ as well drm/i915: fix CB tuning check for ILK+ drm/i915: Flush other plane register writes drm/i915: flush plane control changes on ILK+ as well drm/i915: apply timing generator bug workaround on CPT and PPT ...
| * drm/i915: allow cache sharing policy controlJesse Barnes2011-08-032-0/+107
| | | | | | | | | | | | | | | | | | | | Expose the SNB+ cache sharing policy register in debugfs. The new file, i915_cache_sharing, has 4 values, 0-3, with 0 being "max uncore resources" and 3 being the minimum. Exposing this control should make benchmarking easier and help us choose a good default. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/hdmi: HDMI source product description infoframe supportJesse Barnes2011-08-032-0/+37
| | | | | | | | | | | | | | Set an SPD infoframe if the sink supports it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915/hdmi: split infoframe setting from infoframe type codeJesse Barnes2011-08-033-46/+106
| | | | | | | | | | | | | | | | This makes it easier to add support for other infoframes (e.g. SPD, vendor specific). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm: track CEA version number if presentJesse Barnes2011-08-031-0/+9
| | | | | | | | | | | | | | | | | | | | Drivers need to know the CEA version number in addition to other display info (like whether the display is an HDMI sink) before enabling certain features. So track the CEA version number in the display info structure. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Try enabling RC6 by default (again)Keith Packard2011-08-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Jesse Barnes and I found a couple of issues where incorrect mode setting would cause problems with RC6 enabled. We're hopeful that fixing those will resolve the outstanding issues with a few machines that had trouble before 3.0 with rc6. Cc: Pekka Enberg <penberg@kernel.org> Cc: Francesco Allertsen <fallertsen@gmail.com> Cc: Ted Phelps <phelps@gnusto.com> Cc: Gu Rui <chaos.proton@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38332 Signed-off-by: Keith Packard <keithp@keithp.com>
| * Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-08-031-4/+11
| |\
| | * Revert "drm/i915/dp: Zero the DPCD data before connection probe"Keith Packard2011-08-031-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 97cdd7101079adc3c626d159c62d43de949516c8. Clearing the dpcd data means that if the fetch fails, any previous data will be lost. On eDP, this is no fun as we only fetch dpcd at init time, so the memset will destroy that the next time through.
| | * drm/i915/dp: wait for previous AUX channel activity to clearJesse Barnes2011-08-011-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before initiating a new read or write on the DP AUX channel, wait for any outstanding activity to complete. This may happen during normal retry behavior. If the wait fails (i.e. after 1ms the AUX channel is still busy) dump a backtrace to make the caller easier to spot. v2: use msleep instead, and timeout after 3ms (only ever saw 1 retry with msleep in testing) v3: fix backtrace check to trigger if the 3ms wait times out Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38136. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915: don't use uninitialized EDID bpc values when picking pipe bppJesse Barnes2011-08-011-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EDID parser will zero out the bpc value, and the driver needs to handle that case. In our picker, we'll just ignore 0 values as far as bpp picking goes. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39323. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-297-2/+193
| |\ \ | | |/
| | * drm/i915/pch: Save/restore PCH_PORT_HOTPLUG across suspendAdam Jackson2011-07-292-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least on a Lenovo X220 the HPD bits of this are enabled at boot but cleared after resume, which means plug interrupts stop working. This also happens to fix DP displays re-lighting on resume. I'm quite certain that's an accident: the first DP link train inevitably fails on that machine, and it's only serendipity that we're getting multiple plug interrupts and the second train works. But I shall take my victories where I get them. Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Keith Packard <keithp@keithp.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: apply phase pointer override on SNB+ tooJesse Barnes2011-07-292-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These bits moved around on SNB and above. v2: again with the git send-email fail v3: add macros for getting per-pipe override & enable bits v4: enable phase sync pointer on SNB and IVB configs as well Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: Add quirk to disable SSC on Sony Vaio Y2Michel Alexandre Salim2011-07-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the new quirk added to support disabling SSC on Lenovo U160 (#36656, commit 435793dfb8aec7b2e19f72d5bce8a22fd0b57839), also register the Vaio as a special case and disable SSC for it. This patch fixes #34437 on fdo bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34437 Signed-off-by: Michel Alexandre Salim <salimma@fedoraproject.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: provide more error output when mode sets failJesse Barnes2011-07-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a mode set fails we may get a message from drm_crtc_helper if we're lucky, but it won't tell us anything about *why* we failed to set a mode. So add a few DRM_ERRORs for the cases that shouldn't happen so we can debug things more easily. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: add GPU max frequency control fileJesse Barnes2011-07-291-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mainly for use in debugging and benchmarking, this file allows the user to control the max frequency used by the GPU. Frequency may still vary based on workload (if the frequency is set to higher than the minimum) but won't go over the newly set value. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * i915: add Dell OptiPlex FX170 to intel_no_lvdsPieterjan Camerlynck2011-07-291-0/+8
| | | | | | | | | | | | | | | | | | | | | The Dell OptiPlex FX170 claims to have LVDS, but doesn't. Signed-off-by: Pieterjan Camerlynck <pieterjan.camerlynck@gmail.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: Ignore GPU wedged errors while pinning scanout buffersKeith Packard2011-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Failing to pin a scanout buffer will most likely lead to a black screen, so if the GPU is wedged, then just let the pin happen and hope that things work out OK. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
| | * drm/i915/hdmi: send AVI info frames on ILK+ as wellJesse Barnes2011-07-292-1/+52
| | | | | | | | | | | | | | | | | | | | | | | | On Ironlake and above, we have per-transcoder DIP registers, so use them for sending DIPs like AVI infoframes on ILK and above. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: fix CB tuning check for ILK+Jesse Barnes2011-07-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CB tuning is needed to handle potential process variations that might cause clock jitter for certain PLL settings. However, we were setting it incorrectly since we were using the wrong M value as a check (M1 when we needed to use the whole M value). Fix it up, making my HDMI attached display a little prettier (used to have occasional dots crawl across the display). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-284-51/+98
| |\ \ | | |/
| | * drm/i915: Flush other plane register writesKeith Packard2011-07-281-13/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Writes to the plane control register are buffered in the chip until a write to the DSPADDR (pre-965) or DSPSURF (post-965) register occurs. This patch adds flushes in: intel_enable_plane gen6_init_clock_gating ivybridge_init_clock_gating Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: flush plane control changes on ILK+ as wellJesse Barnes2011-07-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After writing to the plane control reg we need to write to the surface reg to trigger the double buffered register latch. On previous chipsets, writing to DSPADDR was enough, but on ILK+ DSPSURF is the reg that triggers the double buffer latch. v2: write DSPADDR too to cover pre-965 chipsets v3: use flush_display_plane instead, that's what it's for v4: send the right patch Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Keith Packard <keithp@keithp.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: apply timing generator bug workaround on CPT and PPTJesse Barnes2011-07-282-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On CougarPoint and PantherPoint PCH chips, the timing generator may fail to start after DP training completes. This is due to a bug in the FDI autotraining detect logic (which will stall the timing generator and re-enable it once training completes), so disable it to avoid silent DP mode setting failures. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915: Set crtc DPMS mode to ON in intel_crtc_mode_setKeith Packard2011-07-281-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | This corrects the DPMS mode tracking so that the DPMS code will actually turn the CRTC off the next time the screen saves. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| | * Revert and fix "drm/i915/dp: remove DPMS mode tracking from DP"Keith Packard2011-07-281-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 885a50147f00a8a80108904bf58a18af357717f3. We actually *do* need to track DPMS state so that on hotplug, we don't retrain the link until DPMS is disabled. However, that code had avery small bug -- it wouldn't set the dpms_mode at mode set time, and so link retraining would not actually occur on monitor hotplug until the monitor had gone through a DPMS off/DPMS on cycle. Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Andrew Lutomirski <luto@mit.edu>
| | * drm/i915: DP_PIPE_ENABLED must check transcoder on CPTKeith Packard2011-07-282-14/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Display port pipe selection on CPT is not done with a bit in the output register, rather it is controlled by a couple of bits in the separate transcoder register which indicate which display port output is connected to the transcoder. This patch replaces the simplistic macro DP_PIPE_ENABLED with the rather more complicated function dp_pipe_enabled which checks the output register to see if that is enabled, and then goes on to either check the output register pipe selection bit (on non-CPT) or the transcoder DP selection bits (on CPT). Before this patch, any time the mode of pipe A was changed, any display port outputs on pipe B would get disabled as intel_disable_pch_ports would ensure that the mode setting operation could occur on pipe A without interference from other outputs connected to that pch port Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Adam Jackson <ajax@redhat.com>
| | * drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcdKeith Packard2011-07-281-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Eliminates an open-coded read and also gains the retry behaviour of intel_dp_get_dpcd, which seems like a good idea. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Adam Jackson <ajax@redhat.com>
| | * drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcdKeith Packard2011-07-281-9/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | This describes the function better, allowing it to be used where the DPCD value is relevant. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Adam Jackson <ajax@redhat.com>
| | * drm/i915: Use dp_detect_common in hotplug helper functionKeith Packard2011-07-281-20/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses the common dpcd reading routine, i915_dp_detect_common, instead of open-coding a call to intel_dp_aux_native_read. Besides reducing duplicated code, this also gains the read retries which may be necessary when a cable is first plugged back in and the link needs to be retrained. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Adam Jackson <ajax@redhat.com>
| | * drm/i915: Fixup for 'Hold mode_config->mutex during hotplug'Keith Packard2011-07-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <keithp@keithp.com>
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-252-6/+18
| |\ \ | | |/
| | * drm/i915/dp: Don't turn CPT DP ports on too earlyAdam Jackson2011-07-251-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The docs say the port has to come on in training pattern 1; at this point, though, ->DP is in normal mode. The intent here is to wait until the port is in fact sending data, but that doesn't happen since we've broken the sequence the hardware expects, and the vblank wait will time out and kvetch in the log. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Explicitly disable symbol scrambling while trainingAdam Jackson2011-07-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DP spec says training patterns 1 and 2 are to be sent non-scrambled, and the GPU docs claim that happens (or at least, there's no explicit scrambling control). But the sink may be confused if we don't explicitly tell it what we're doing, so play it safe. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/pch: Fix integer math bugs in panel fittingAdam Jackson2011-07-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <ajax@redhat.com> Tested-By: Daniel Manrique <daniel.manrique@canonical.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38851 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by: Keith Packard <keithp@keithp.com>
| * | Merge branch 'drm-intel-fixes' into drm-intel-nextKeith Packard2011-07-252-21/+27
| |\ \ | | |/
| | * drm/i915: Hold mode_config->mutex during hotplug processingKeith Packard2011-07-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <keithp@keithp.com> Cc: stable@kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| | * drm/i915/dp: Explicitly request 8/10 channel codingAdam Jackson2011-07-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's not clear what a sink would do if you wrote zero to this register - which I guess would mean "I don't support any channel encodings, good luck" - but let's not find out. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Retry DPCD fetch on G4X tooAdam Jackson2011-07-251-18/+15
| | | | | | | | | | | | | | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Better hexdump of DPCDAdam Jackson2011-07-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | %hx alone prints 0 as "0", not "00". Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Read more DPCD registers on connection probeAdam Jackson2011-07-251-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | For parity with radeon and nouveau, and also because I suspect we're going to need it to get format-conversion dongles right. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Move DPCD dump to common code instead of PCH-onlyAdam Jackson2011-07-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | No reason not to see this on g4x, after all. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
| | * drm/i915/dp: Zero the DPCD data before connection probeAdam Jackson2011-07-251-0/+1
| | | | | | | | | | | | | | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
OpenPOWER on IntegriCloud