summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/drm_edid.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/edid: Check both 60Hz and 59.94Hz when looking for a CEA modeVille Syrjälä2013-04-261-3/+24
| | | | | | | | | | | | | | | | drm_match_cea_mode() should be able to match both the 60Hz version, and the 59.94Hz version of modes. We only store one pixel clock value per mode in edid_cea_modes, so the other value must be calculated. Depending on the mode, edid_cea_modes contains the pixel clock for either the 60Hz version or the 59.94Hz version, so a bit of care is needed so that the calculation produces the correct result. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800 Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Populate vrefresh for CEA modesVille Syrjälä2013-04-261-64/+129
| | | | | | | | | | | | | | Well have use for the vrefresh information of CEA modes later. Just populate the information into the table to avoid having to calculate it. I'm too lazy to check if someone relies on newly allocated CEA modes having 0 vrefresh, so just clear vrefresh back to 0 when adding the mode to the connector's modelist. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: add drm_edid_to_eld helper extracting SADs from EDID (v2)Rafał Miłecki2013-04-231-0/+59
| | | | | | | | | | | | | | | | Some devices (ATI/AMD cards) don't support passing ELD struct to the hardware but just require filling specific registers and then the hardware/firmware does the rest. In such cases we need to read the info from SAD blocks and put them in the correct registers. agd5f: note that the returned pointer needs to be kfreed as per Christian's suggestion. v2: fix warning Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* KMS: fix EDID detailed timing frame rateTorsten Duwe2013-03-231-0/+1
| | | | | | | | | | | | | | | When KMS has parsed an EDID "detailed timing", it leaves the frame rate zeroed. Consecutive (debug-) output of that mode thus yields 0 for vsync. This simple fix also speeds up future invocations of drm_mode_vrefresh(). While it is debatable whether this qualifies as a -stable fix I'd apply it for consistency's sake; drm_helper_probe_single_connector_modes() does the same thing already for all probed modes. Cc: stable@vger.kernel.org Signed-off-by: Torsten Duwe <duwe@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* KMS: fix EDID detailed timing vsync parsingTorsten Duwe2013-03-231-1/+1
| | | | | | | | | | | | | | | | | | EDID spreads some values across multiple bytes; bit-fiddling is needed to retrieve these. The current code to parse "detailed timings" has a cut&paste error that results in a vsync offset of at most 15 lines instead of 63. See http://en.wikipedia.org/wiki/EDID and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why that needs to be a left shift. Cc: stable@vger.kernel.org Signed-off-by: Torsten Duwe <duwe@lst.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* drm: Add HDMI infoframe helpersThierry Reding2013-02-221-0/+33
| | | | | | | | Add a generic helper to fill in an HDMI AVI infoframe with data extracted from a DRM display mode. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* drm: Move mode tables to drm_edid.cThierry Reding2013-02-221-7/+746
| | | | | | | | | | The modes are only used from within drm_edid.c so we move them there to avoid creating duplicates by multiple inclusion of drm_edid_modes.h. As a side-effect we can also get rid of a few variables that keep track of the number of entries in the tables and use ARRAY_SIZE() instead. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* drm: Remove duplicate drm_mode_cea_vic()Thierry Reding2013-02-221-23/+7
| | | | | | | | | The same function had already been merged with a different name. Remove the duplicate one but reuse some of its kerneldoc fragments for the existing implementation. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* drm: don't add inferred modes for monitors that don't support themPaulo Zanoni2013-02-201-1/+2
| | | | | | | | | | | | | | | | | | | If bit 0 of the features byte (0x18) is set to 0, then, according to the EDID spec, "the display is non-continuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in Base EDID and certain Extension Blocks". For more information, please see the EDID spec, check the notes of the table that explains the "Feature Support" byte (18h) and also the notes on the tables of the section that explains "Display Range Limits & Additional Timing Description Definition (tag #FDh)". Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: shut up invalid edid messagesMaarten Lankhorst2013-02-151-1/+5
| | | | | | | | | | My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam every few seconds. I get it the first time that the entire block is all 0xff.. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: stable@vger.kernel.org [v3.7] Signed-off-by: Dave Airlie <airlied@redhat.com>
* Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"Daniel Vetter2013-02-131-3/+0
| | | | | | | | | | | | | | This reverts commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b. The quirk cause a regression, and it looks like the original bug was simply a lack of FIFO bandwidth on the i915G of the reporter. Which should eventually be fixed as soon as we get around to implemented DSPARB FIFO reassignment on gen 3. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281 Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Add drm_rgb_quant_range_selectable()Ville Syrjälä2013-01-201-0/+33
| | | | | | | | | | | | | | drm_rgb_quant_range_selectable() will report whether the monitor claims to support for RGB quantization range selection. The information can be found in the CEA Video capability block. v2: s/quantzation/quantization/ in the comment Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: David Airlie <airlied@linux.ie> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'drm-intel-fixes' of ↵Dave Airlie2012-12-161-0/+19
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: A few leftover fixes for 3.8: - VIC support for hdmi infoframes with the associated drm helper, fixes some black TVs (Paulo Zanoni) - Modeset state check (and fixup if the BIOS messed with the hw) for lid-open. modeset-rework fallout. Somehow the original reporter went awol, so this stalled for way too long until we've found a new victim^Wreporter with broken BIOS. - seqno wrap fixes from Mika and Chris. - Some minor fixes all over from various people. - Another race fix in the pageflip vs. unpin code from Chris. - hsw vga resume support and a few more fdi link fixes (only used for vga on hsw) from Paulo. - Regression fix for DMAR from Zhenyu Wang - I've scavenged memory from my DMAR for a while and it broke right away :( - Regression fix from Takashi Iwai for ivb lvds - some w/a needs to be (partially) moved back into place. Note that these are regressions in -next. - One more fix for ivb 3 pipe support - it now actually seems to work. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (25 commits) drm/i915: Fix missed needs_dmar setting drm/i915: Fix shifted screen on top of LVDS on IVY laptop drm/i915: disable cpt phase pointer fdi rx workaround drm/i915: set the LPT FDI RX polarity reversal bit when needed drm/i915: add lpt_init_pch_refclk drm/i915: add support for mPHY destination on intel_sbi_{read, write} drm/i915: reject modes the LPT FDI receiver can't handle drm/i915: fix hsw_fdi_link_train "retry" code drm/i915: Close race between processing unpin task and queueing the flip drm/i915: fixup l3 parity sysfs access check drm/i915: Clear the existing watermarks for g4x when modifying the cursor sr drm/i915: do not access BLC_PWM_CTL2 on pre-gen4 hardware drm/i915: Don't allow ring tail to reach the same cacheline as head drm/i915: Decouple the object from the unbound list before freeing pages drm/i915: Set sync_seqno properly after seqno wrap drm/i915: Include the last semaphore sync point in the error-state drm/i915: Rearrange code to only have a single method for waiting upon the ring drm/i915: Simplify flushing activity on the ring drm/i915: Preallocate next seqno before touching the ring drm/i915: force restore on lid open ...
| * drm: add drm_mode_cea_vicPaulo Zanoni2012-11-291-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | This function returns the VIC of the mode. This value can be used when creating AVI InfoFrames. Cc: Thierry Reding <thierry.reding@avionic-design.de> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=50371 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Thierry Reding <thierry.reding@avionic-design.de> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/edid: tune down debug message in parse_hdmi_vsdbDaniel Vetter2012-11-281-1/+1
|/ | | | | | | | | | Those tend to be totally not interesting for end-users, and for debugging we tend to dump the entire noise anyway by enabling all debug messages. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57388 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: use memchr_inv()Akinobu Mita2012-11-201-5/+2
| | | | | | | | | Use memchr_inv() to check the specified memory region is filled with zero. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: get cea video id code for a given display modeStephane Marchesin2012-11-201-0/+20
| | | | | | | | | | | | | This patch adds support for getting CEA Video ID Code for a given display mode after matching with edid_cea_modes list. Its index in the list added with one, gives the desired code. This exported function will be used by hdmi drivers for composing AVI info frame data. Signed-off-by: Stephane Marchesin <marcheu@chromium.org> Signed-off-by: Rahul Sharma <rahul.sharma@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'drm-intel-fixes' of ↵Dave Airlie2012-10-071-1/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Daniel writes: Bigger -fixes pile, mostly because I've included Ajax' DP dongle stuff, as discussed on irc. Otherwise just small things: - regression fix to finally make 6bpc auto-dither on dp work (Jani) - reinstate an snb ctx w/a that accidentally got lost in a rework (Chris) - fixup the DP train sequence, logic-goof-up uncovered by Coverty (Chris) - fix set_caching locking (Ben) - fix spurious segfault on con-current gtt mmap faulting (Dimitry and Mika) - some pageflip correctness fixes (still hunting down some issues, but these are the worst offenders of confused code that we've tracked down thus far) from Chris and me - fixup swizzling settings on vlv (Jesse) - gt_mode w/a from Ben added, fixes snb gt1 rc6+hw ctx hangs. * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Fix GT_MODE default value drm/i915: don't frob the vblank ts in finish_page_flip drm/i915: call drm_handle_vblank before finish_page_flip drm/i915: print warning if vmi915_gem_fault error is not handled drm/i915: EBUSY status handling added to i915_gem_fault(). drm/i915: Try harder to complete DP training pattern 1 drm/i915: set swizzling to none on VLV drm/dp: Make sink count DP 1.2 aware drm/dp: Document DP spec versions for various DPCD registers drm/i915/dp: Be smarter about connection sense for branch devices drm/i915/dp: Fetch downstream port info if needed during DPCD fetch drm/dp: Update DPCD defines drm: Export drm_probe_ddc() drm/i915: Flush the pending flips on the CRTC before modification drm/i915: Actually invalidate the TLB for the SandyBridge HW contexts w/a drm/i915: Fix set_caching locking drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag
| * drm: Export drm_probe_ddc()Adam Jackson2012-10-021-1/+2
| | | | | | | | | | | | | | Tested-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Adam Jackson <ajax@redhat.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2012-10-031-65/+143
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm merge (part 1) from Dave Airlie: "So first of all my tree and uapi stuff has a conflict mess, its my fault as the nouveau stuff didn't hit -next as were trying to rebase regressions out of it before we merged. Highlights: - SH mobile modesetting driver and associated helpers - some DRM core documentation - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write combined pte writing, ilk rc6 support, - nouveau: major driver rework into a hw core driver, makes features like SLI a lot saner to implement, - psb: add eDP/DP support for Cedarview - radeon: 2 layer page tables, async VM pte updates, better PLL selection for > 2 screens, better ACPI interactions The rest is general grab bag of fixes. So why part 1? well I have the exynos pull req which came in a bit late but was waiting for me to do something they shouldn't have and it looks fairly safe, and David Howells has some more header cleanups he'd like me to pull, that seem like a good idea, but I'd like to get this merge out of the way so -next dosen't get blocked." Tons of conflicts mostly due to silly include line changes, but mostly mindless. A few other small semantic conflicts too, noted from Dave's pre-merged branch. * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits) drm/nv98/crypt: fix fuc build with latest envyas drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering drm/nv41/vm: fix and enable use of "real" pciegart drm/nv44/vm: fix and enable use of "real" pciegart drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie drm/nouveau: store supported dma mask in vmmgr drm/nvc0/ibus: initial implementation of subdev drm/nouveau/therm: add support for fan-control modes drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules drm/nouveau/therm: calculate the pwm divisor on nv50+ drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster drm/nouveau/therm: move thermal-related functions to the therm subdev drm/nouveau/bios: parse the pwm divisor from the perf table drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices drm/nouveau/therm: rework thermal table parsing drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table drm/nouveau: fix pm initialization order drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it drm/nouveau: log channel debug/error messages from client object rather than drm client drm/nouveau: have drm debugging macros build on top of core macros ...
| * Merge tag 'v3.6-rc7' into drm-intel-next-queuedDaniel Vetter2012-09-241-0/+3
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Manual backmerge of -rc7 to resolve a silent conflict leading to compile failure in drivers/gpu/drm/i915/intel_hdmi.c. This is due to the bugfix in -rc7: commit b98b60167279df3acac9422c3c9820d9ebbcf9fb Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 13 07:43:22 2012 +0800 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug Since this code moved around a lot in -next git put that snippet at the wrong spot. I've tried to fix this by making the conflict explicit by merging a version for next with: commit 3cce574f0190dd149472059fb69267cf83d290f9 Author: Wang Xingchao <xingchao.wang@intel.com> Date: Thu Sep 13 11:19:00 2012 +0800 drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally But that failed to solve the entire problem. To avoid pushing out further -nightly branch to our QA where this is broken, do the backmerge and manually add the stuff git adds to -next from the patch in -fixes. Note that this doesn't show up in git's merge diff (and hence is also not handled by git rerere), which adds to the reasons why I'd like to fix this with a verbose backmerge. The git merge diff only shows a bunch of trivial conflicts of the "code changed in lines next to each another" kind. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/edid: limit printk when facing bad edidJerome Glisse2012-09-171-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Limit printing bad edid information at one time per connector. Connector that are connected to a bad monitor/kvm will likely stay connected to the same bad monitor/kvm and it makes no sense to keep printing the bad edid message. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: edid: add support for E-DDCShirish S2012-09-131-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current logic for probing ddc is limited to 2 blocks (256 bytes), this patch adds support for the 4 block (512) data. To do this, a single 8-bit segment index is passed to the display via the I2C address 30h. Data from the selected segment is then immediately read via the regular DDC2 address using a repeated I2C 'START' signal. Signed-off-by: Shirish S <s.shirish@samsung.com> Reviewed-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: edid: Refactor HDMI VSDB detectionVille Syrjälä2012-09-131-16/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two slightly different pieces of code for HDMI VSDB detection. Unify the code into a single helper function. Also fix a bug where drm_detect_hdmi_monitor() would stop looking for the HDMI VSDB after the first vendor specific block is found, whether or not that block happened to be the HDMI VSDB. The standard allows for any number of vendor specific blocks to be present. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: edid: Add bounds checking to HDMI VSDB parsingVille Syrjälä2012-09-131-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The length of HDMI VSDB must be at least 5 bytes. Other than the minimum, nothing else about the length is specified. Check the length before accessing any additional field beyond the minimum length. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: edid: Add some bounds checkingVille Syrjälä2012-09-131-26/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | Make sure drm_detect_hdmi_monitor() and drm_detect_monitor_audio() don't access beyond the extension block. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm: remove the raw_edid field from struct drm_display_infoJani Nikula2012-08-241-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Neither the drm core nor any of the drivers really need the raw_edid field of struct drm_display_info for anything. Instead of being useful, it creates confusion about who is responsible for freeing the memory it points to and setting the field to NULL afterwards, leading to memory leaks and dangling pointers. Remove the raw_edid field, and fix drivers as necessary. Reported-by: Russell King <linux@arm.linux.org.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells2012-10-021-2/+2
| |/ |/| | | | | | | | | | | | | | | | | | | Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
* | drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222SPaul Menzel2012-08-301-0/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Connecting an ASUS VW222S [1] over VGA a garbled screen is shown with vertical stripes in the top half. In commit bc42aabc [2] commit bc42aabc6a01b92b0f961d65671564e0e1cd7592 Author: Adam Jackson <ajax@redhat.com> Date: Wed May 23 16:26:54 2012 -0400 drm/edid/quirks: ViewSonic VA2026w Adam Jackson added the quirk `EDID_QUIRK_FORCE_REDUCED_BLANKING` which is also needed for this ASUS monitor. All log files and output from `xrandr` is included in the referenced Bugzilla report #17629. Please note that this monitor only has a VGA (D-Sub) connector [1]. [1] http://www.asus.com/Display/LCD_Monitors/VW222S/ [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=bc42aabc6a01b92b0f961d65671564e0e1cd7592 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=17629 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Cc: <dri-devel@lists.freedesktop.org> Cc: Adam Jackson <ajax@redhat.com> Cc: Ian Pilcher <arequipeno@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: edid: Don't add inferred modes with higher resolutionTakashi Iwai2012-07-031-3/+24
| | | | | | | | | | | | | | | | | When a monitor EDID doesn't give the preferred bit, driver assumes that the mode with the higest resolution and rate is the preferred mode. Meanwhile the recent changes for allowing more modes in the GFT/CVT ranges give actually more modes, and some modes may be over the native size. Thus such a mode would be picked up as the preferred mode although it's no native resolution. For avoiding such a problem, this patch limits the addition of inferred modes by checking not to be greater than other modes. Also, it checks the duplicated mode entry at the same time. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: don't return stack garbage from supports_rbDaniel Vetter2012-06-211-1/+1
| | | | | | | | | | | | We need to initialize this to false, because the is_rb callback only ever sets it to true. Noticed while reading through the code. Cc: stable@vger.kernel.org Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Make the header fixup threshold tunableAdam Jackson2012-06-011-2/+9
| | | | | | | | | | | 6 bytes seems to be a reasonable default so far, but for the desperate it's worth exposing this. [airlied: change include to module.h for this] Bugzilla: https://bugzilla.redhat.com/582559 Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid/quirks: ViewSonic VA2026wAdam Jackson2012-05-291-4/+18
| | | | | | | | | Entirely new class of fail for this one. The detailed timings are for normal CVT but the monitor really wanted CVT-R. Bugzilla: http://bugzilla.redhat/com/516471 Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Store vendor IDs directly in the EDID quirk structureIan Pilcher2012-04-271-1/+1
| | | | | | | | | | EDID vendor IDs are always 3 characters long (4 with the terminating 0). It doesn't make any sense to have a (possibly 8-byte) pointer to the ID string in the quirk structure. Signed-off-by: Ian Pilcher <arequipeno@gmail.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Try harder to fix up base EDID blocksAdam Jackson2012-04-271-5/+5
| | | | | | | | | | | | | Requiring the first byte of the EDID base block header to be 0 means we don't fix up as many transfer errors as we could. Instead have the callers specify whether it's meant to be block 0 or not, and conditionally run header fixup based on that. Bugzilla: https://bugzilla.redhat.com/812890 Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Add a workaround for 1366x768 HD panelTakashi Iwai2012-04-231-0/+15
| | | | | | | | | | | | HD panel (1366x768) found most commonly on laptops can't be represented exactly in CVT/DMT expression, which leads to 1368x768 instead, because 1366 can't be divided by 8. Add a hack to convert to 1366x768 manually as an exception. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: add missing NULL checks.Takashi Iwai2012-04-201-0/+6
| | | | | Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Generate modes from extra_modes for range descriptorsAdam Jackson2012-04-201-0/+73
| | | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Do drm_dmt_modes_for_range() for all range descriptor typesAdam Jackson2012-04-201-5/+6
| | | | | | | | | | | | | EDID 1.4 retcons the meaning of the "GTF feature" bit to mean "is continuous frequency", and moves the set of supported timing formulas into the range descriptor itself. In any event, the range descriptor can act as a filter on the DMT list without regard to a specific timing formula. Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: s/drm_gtf_modes_for_range/drm_dmt_modes_for_range/Adam Jackson2012-04-201-2/+2
| | | | | | | | | Slightly more honest naming. Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Remove a misleading commentAdam Jackson2012-04-201-4/+0
| | | | | | | | | mode_in_range() handles what this was warning about. Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Allow drm_mode_find_dmt to hunt for reduced-blanking modesAdam Jackson2012-04-201-13/+24
| | | | | | | | | | | | | | It won't find any, yet. Fix up callers to match: standard mode codes will look prefer r-b modes for a given size if present, EST3 mode codes will look for exactly the r-b-ness mentioned in the mode code. This might mean fewer modes matched for EST3 mode codes between now and when the DMT mode list regrows the r-b modes, but practically speaking EST3 codes don't exist in the wild. Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Rewrite drm_mode_find_dmt search loopAdam Jackson2012-04-201-9/+10
| | | | | | | | | No functional change, but will make an upcoming change clearer. Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: Document drm_mode_find_dmtAdam Jackson2012-04-201-0/+10
| | | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Tested-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Parse color format information in CEA blocksLars-Peter Clausen2012-04-201-10/+21
| | | | | | | | | | | The CEA extension block has a field which describes which YCbCr modes are supported by the device, use it to fill the drm_display_info color_formats fields. Also the existence of a CEA extension block is used as indication that the device supports RGB. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Fix EDID color format parsingLars-Peter Clausen2012-04-201-4/+4
| | | | | | | | | | | The code should obviously check the EDID feature field for EDID feature flags and not the color_formats field of the drm_display_info struct. Also update the color_formats field with new modes instead of overwriting the current mode. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: remove unneeded redefinition of DDC_ADDRMatt Turner2012-03-211-1/+0
| | | | | | | It's already defined in drm_edid.h. Signed-off-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: allow loading an EDID as firmware to override broken monitorCarsten Emde2012-03-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broken monitors and/or broken graphic boards may send erroneous or no EDID data. This also applies to broken KVM devices that are unable to correctly forward the EDID data of the connected monitor but invent their own fantasy data. This patch allows to specify an EDID data set to be used instead of probing the monitor for it. It contains built-in data sets of frequently used screen resolutions. In addition, a particular EDID data set may be provided in the /lib/firmware directory and loaded via the firmware interface. The name is passed to the kernel as module parameter of the drm_kms_helper module either when loaded options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel commandline parameter drm_kms_helper.edid_firmware=edid/1280x1024.bin It is also possible to restrict the usage of a specified EDID data set to a particular connector. This is done by prepending the name of the connector to the name of the EDID data set using the syntax edid_firmware=[<connector>:]<edid> such as, for example, edid_firmware=DVI-I-1:edid/1920x1080.bin in which case no other connector will be affected. The built-in data sets are Resolution Name -------------------------------- 1024x768 edid/1024x768.bin 1280x1024 edid/1280x1024.bin 1680x1050 edid/1680x1050.bin 1920x1080 edid/1920x1080.bin They are ignored, if a file with the same name is available in the /lib/firmware directory. The built-in EDID data sets are based on standard timings that may not apply to a particular monitor and even crash it. Ideally, EDID data of the connected monitor should be used. They may be obtained through the drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory of a correctly working graphics adapter. It is even possible to specify the name of an EDID data set on-the-fly via the /sys/module interface, e.g. echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware The new screen mode is considered when the related kernel function is called for the first time after the change. Such calls are made when the X server is started or when the display settings dialog is opened in an already running X server. Signed-off-by: Carsten Emde <C.Emde@osadl.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/edid: drm modes have to be free with drm_mode_destroySascha Hauer2012-02-031-1/+1
| | | | | | | to add the missing drm_mode_object_put for that mode. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: give up on edid retries when i2c bus is not respondingEugeni Dodonov2012-02-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows to avoid talking to a non-responding bus repeatedly until we finally timeout after 15 attempts. We can do this by catching the -ENXIO error, provided by i2c_algo_bit:bit_doAddress call. Within the bit_doAddress we already try 3 times to get the edid data, so if the routine tells us that bus is not responding, it is mostly pointless to keep re-trying those attempts over and over again until we reach final number of retries. This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall edid detection timing by 10-30% in most cases, and by a much larger margin in case of phantom outputs (up to 30x in one worst case). Timing results for i915-powered machines for 'time xrandr' command: Machine 1: from 0.840s to 0.290s Machine 2: from 0.315s to 0.280s Machine 3: from +/- 4s to 0.184s Timing results for HD5770 with 'time xrandr' command: Machine 4: from 3.210s to 1.060s Reviewed-by: Chris Wilson <chris@hchris-wilson.co.uk> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: Sean Finney <seanius@seanius.net> Tested-by: Soren Hansen <soren@linux2go.dk> Tested-by: Hernando Torque <sirius@sonnenkinder.org> Tested-by: Mike Lothian <mike@fireburn.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059 Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
OpenPOWER on IntegriCloud