summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/drm_edid.c
AgeCommit message (Collapse)AuthorFilesLines
2016-11-30Merge tag 'drm-misc-next-2016-11-29' of ↵Dave Airlie1-12/+54
git://anongit.freedesktop.org/git/drm-misc into drm-next Big thing is that drm-misc is now officially a group maintainer/committer model thing, with MAINTAINERS suitably updated. Otherwise just the usual pile of misc things all over, nothing that stands out this time around. * tag 'drm-misc-next-2016-11-29' of git://anongit.freedesktop.org/git/drm-misc: (33 commits) drm: Introduce drm_framebuffer_assign() drm/bridge: adv7511: Enable the audio data and clock pads on adv7533 drm/bridge: adv7511: Add Audio support drm/edid: Consider alternate cea timings to be the same VIC drm/atomic: Constify drm_atomic_crtc_needs_modeset() drm: bridge: dw-hdmi: add ASoC dependency drm: Fix shift operations for drm_fb_helper::drm_target_preferred() drm: Avoid NULL dereference for DRM_LEGACY debug message drm: Use u64_to_user_ptr() helper for blob ioctls drm: Fix conflicting macro parameter in drm_mm_for_each_node_in_range() drm: Fixup kernel doc for driver->gem_create_object drm/hisilicon/hibmc: mark PM functions __maybe_unused drm/hisilicon/hibmc: Checking for NULL instead of IS_ERR() drm: bridge: add DesignWare HDMI I2S audio support drm: Check against color expansion in drm_mm_reserve_node() drm: Define drm_mm_for_each_node_in_range() drm/doc: Fix links in drm_property.c MAINTAINERS: Add link to drm-misc documentation vgaarb: use valid dev pointer in vgaarb_info() drm/atomic: Unconfuse the old_state mess in commmit_tail ...
2016-11-28drm/edid: Consider alternate cea timings to be the same VICVille Syrjälä1-12/+54
CEA-861 specifies that the vertical front porch may vary by one or two lines for specific VICs. Up to now we've only considered a mode to match the VIC if it matched the shortest possible vertical front porch length (as that is the variant we store in cea_modes[]). Let's allow our VIC matching to work with the other timings variants as well so that that we'll send out the correct VIC if the variant actually used isn't the one with the shortest vertical front porch. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Adam Jackson <ajax@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
2016-11-17Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queuedDaniel Vetter1-2/+2
Tvrtko needs commit b3c11ac267d461d3d597967164ff7278a919a39f Author: Eric Engestrom <eric@engestrom.ch> Date: Sat Nov 12 01:12:56 2016 +0000 drm: move allocation out of drm_get_format_name() to be able to apply his patches without conflicts. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-11-09drm/edid: Remove drm_select_eldMaarten Lankhorst1-26/+0
The only user was i915, which is now gone. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Dave Airlie <airlied@redhat.com> #irc Cc: dri-devel@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/1478609742-13603-9-git-send-email-maarten.lankhorst@linux.intel.com
2016-11-08drm/edid: Add the missing "Hz" to VIC 58,59 commentVille Syrjälä1-2/+2
All the VICs apart from 58 and 59 have the word "Hz" included in the comment. Include it for 59 and 59 as well. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-1-git-send-email-ville.syrjala@linux.intel.com
2016-10-25drm/edid: Only print the bad edid when abortingChris Wilson1-23/+56
Currently, if drm.debug is enabled, we get a DRM_ERROR message on the intermediate edid reads. This causes transient failures in CI which flags up the sporadic EDID read failures, which are recovered by rereading the EDID automatically. This patch combines the reporting done by drm_do_get_edid() itself with the bad block printing from get_edid_block(), into a single warning associated with the connector once all attempts to retrieve the EDID fail. v2: Print the whole EDID, marking up the bad/zero blocks. This requires recording the whole of the raw edid, then a second pass to reduce it to the valid extensions. v3: Fix invalid/valid extension fumble. References: https://bugs.freedesktop.org/show_bug.cgi?id=98228 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161024113821.26263-1-chris@chris-wilson.co.uk
2016-10-17drm/edid: Use block local to refer to the blockChris Wilson1-7/+5
Now that we have the name "block" free once more, we can use it to point to the start of a block within the edid. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161017083514.21772-2-chris@chris-wilson.co.uk
2016-10-17drm/edid: Rename local variable block to edidChris Wilson1-19/+19
The "block" variable points to the entire edid, not individual blocks despite it being named such. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161017083514.21772-1-chris@chris-wilson.co.uk
2016-10-04drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()Ville Syrjälä1-29/+35
drm_edid_to_eld() is just mean to cook up the ELD for the audio driver, so having it parse non-audio related stuff seems just wrong, and potentially could lead to that information not being even filled out if the function doesn't even get called. Let's move that stuff to the place where we parse the color formats and whatnot from the CEA ext block. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-9-git-send-email-ville.syrjala@linux.intel.com
2016-10-04drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDIDVille Syrjälä1-0/+1
It's not a good idea to leave stale cea_rev in the drm_display_info. The current EDID might not even have a CEA ext block in which case we'd end up leaving the stale value in place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-8-git-send-email-ville.syrjala@linux.intel.com
2016-10-04drm/edid: Reduce the number of times we parse the CEA extension blockVille Syrjälä1-97/+88
Instead of parsing parts of the CEA extension block in two places to determine supported color formats and whatnot, let's just consolidate it to one function. This also makes it possible to neatly flatten drm_assign_hdmi_deep_color_info(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-7-git-send-email-ville.syrjala@linux.intel.com
2016-10-04drm/edid: Don't pass around drm_display_info needlesslyVille Syrjälä1-4/+4
We already pass the connector to drm_add_display_info() and drm_assign_hdmi_deep_color_info(), so passing the connector->display_info also is pointless. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-6-git-send-email-ville.syrjala@linux.intel.com
2016-10-04drm/edid: Move dvi_dual/max_tmds_clock to drm_display_infoVille Syrjälä1-6/+8
We have the drm_display_info for storing information about the sink, so let's move dvi_dual and max_tmds_clock in there. v2: Deal with superfluous code shuffling Document dvi_dual and max_tmds_clock too Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> (v1) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-5-git-send-email-ville.syrjala@linux.intel.com
2016-10-04drm/edid: Make max_tmds_clock kHz instead of MHzVille Syrjälä1-1/+1
We generally store clocks in kHz, so let's do that for the HDMI max TMDS clock value as well. Less surpising. v2: Deal with superfluous code shuffling Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> (v1) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-4-git-send-email-ville.syrjala@linux.intel.com
2016-10-04drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDIDVille Syrjälä1-0/+3
Clear out old max_tmds_clock and dvi_dual information (possibly from a previous EDID) before parsing the current EDID. Tne current EDID might not even have these in its HDMI VSDB, which would mean that we'd leave the old stale values in place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-3-git-send-email-ville.syrjala@linux.intel.com
2016-10-04drm/edid: Clear old audio latency values before parsing the new EDIDVille Syrjälä1-0/+7
Clear out stale audio latency information (potentially from a previous EDID) before constructing the ELD from the EDID. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-2-git-send-email-ville.syrjala@linux.intel.com
2016-08-18drm/edid: CEA mode 64 1080p100 vsync pulse width incorrectClint Taylor1-1/+1
In the CEA-861 specification VIC 64 specifies a vsync pulse of 5 and a backporch of 36. Adjust vsync pulse width to match specification. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1471282288-30909-1-git-send-email-clinton.a.taylor@intel.com
2016-08-16drm: document drm_display_infoDaniel Vetter1-19/+4
We seem to have a bit a mess in how to describe the bus formats, with a multitude of competing ways. Might be best to consolidate it all and use MEDIA_BUS_FMT_ also for the hdmi color formats and high color modes. Also move all the display_info related functions into drm_connector.c (there's only one) to group it all together. I did decided against also moving the edid related display info functions, they seem to fit better in drm_edid.c. Instead sprinkle a few cross references around. While at that reduce the kerneldoc for static functions, there's not point in documenting internals with that much detail really. v2: Fix typo and move misplaced hunk (Sean). Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-19-git-send-email-daniel.vetter@ffwll.ch
2016-08-09drm/edid: Set 8 bpc color depth for displays with "DFP 1.x compliant TMDS".Mario Kleiner1-0/+14
According to E-EDID spec 1.3, table 3.9, a digital video sink with the "DFP 1.x compliant TMDS" bit set is "signal compatible with VESA DFP 1.x TMDS CRGB, 1 pixel / clock, up to 8 bits / color MSB aligned". For such displays, the DFP spec 1.0, section 3.10 "EDID support" says: "If the DFP monitor only supports EDID 1.X (1.1, 1.2, etc.) without extensions, the host will make the following assumptions: 1. 24-bit MSB-aligned RGB TFT 2. DE polarity is active high 3. H and V syncs are active high 4. Established CRT timings will be used 5. Dithering will not be enabled on the host" So if we don't know the bit depth of the display from additional colorimetry info we should assume 8 bpc / 24 bpp by default. This patch adds info->bpc = 8 assignement for that case. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-08-09drm/edid: Add 6 bpc quirk for display AEO model 0.Mario Kleiner1-0/+8
Bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=105331 reports that the "AEO model 0" display is driven with 8 bpc without dithering by default, which looks bad because that panel is apparently a 6 bpc DP panel with faulty EDID. A fix for this was made by commit 013dd9e03872 ("drm/i915/dp: fall back to 18 bpp when sink capability is unknown"). That commit triggers new regressions in precision for DP->DVI and DP->VGA displays. A patch is out to revert that commit, but it will revert video output for the AEO model 0 panel to 8 bpc without dithering. The EDID 1.3 of that panel, as decoded from the xrandr output attached to that bugzilla bug report, is somewhat faulty, and beyond other problems also sets the "DFP 1.x compliant TMDS" bit, which according to DFP spec means to drive the panel with 8 bpc and no dithering in absence of other colorimetry information. Try to make the original bug reporter happy despite the faulty EDID by adding a quirk to mark that panel as 6 bpc, so 6 bpc output with dithering creates a nice picture. Tested by injecting the edid from the fdo bug into a DP connector via drm_kms_helper.edid_firmware and verifying the 6 bpc + dithering is selected. This patch should be backported to stable. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-23drm/edid: add displayid detailed 1 timings to the modelist. (v1.1)Dave Airlie1-0/+108
The tiled 5K Dell monitor appears to be hiding it's tiled mode inside the displayid timings block, this patch parses this blocks and adds the modes to the modelist. v1.1: add missing __packed. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95207 Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-23drm/edid: move displayid validation to it's own function.Dave Airlie1-18/+26
We need to use this for validating modeline additions. Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-23drm/displayid: Iterate over all DisplayID blocksTomas Bzatek1-13/+19
This will iterate over all DisplayID blocks found in the buffer. Previously only the first block was parsed. https://bugs.freedesktop.org/show_bug.cgi?id=95207 Signed-off-by: Tomas Bzatek <tomas@bzatek.net> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-23drm/edid: move displayid tiled block parsing into separate function.Dave Airlie1-51/+59
This just makes the code easier to follow. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-05-09Merge tag 'v4.6-rc7' into drm-nextDave Airlie1-5/+5
Merge this back as we've built up a fair few conflicts, and I have some newer trees to pull in.
2016-04-15drm/edid: Add drm_edid_get_monitor_name()Jim Bride1-9/+42
In order to include monitor name information in debugfs output we needed to add a function that would extract the monitor name from the EDID, and that function needed to reside in the file where the rest of the EDID helper functions are implemented. v2: Refactor to have drm_edid_get_monitor_name() and drm_edid_to_eld() use a common helper function to extract the monitor name from the edid. [Jani] + rebase. v3: Minor changes suggested by Jani + rebase. v4: Few more minor changes suggested by Jani + rebase. cc: dri-devel@lists.freedesktop.org cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-1-git-send-email-jim.bride@linux.intel.com
2016-04-05drm/edid: Fix DMT 1024x768@43Hz (interlaced) timingsPaul Parsons1-1/+1
One of the VESA DMT timings in drm_dmt_modes[] is slightly off. 1024x768@43Hz (interlaced) vsync_end should be 776, not 772. This brings it into line with the identical timings in edid_est_modes[]. Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160404193639.8631D6E66B@gabe.freedesktop.org
2016-04-05drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptorPaul Parsons1-1/+1
The EDID 1.4 specification section 3.10.3.9 defines an Established Timings III descriptor (tag #F7h). The parsing of this descriptor by drm_est3_modes() is off by one byte: the offset of the first timing bitmap is 6, not 5. Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160328002258.E75DF6E35D@gabe.freedesktop.org
2016-04-05drm/edid: Fix EDID Established Timings I and IIPaul Parsons1-3/+3
Three of the VESA DMT timings in edid_est_modes[] are slightly off. 1. 640x480@72Hz vsync_end should be 492, not 491. 2. 640x480@60Hz clock should be 25175, not 25200. 3. 1024x768@75Hz clock should be 78750, not 78800. This patch corrects those timings per the VESA DMT specification, and thus brings them into line with the identical timings in drm_dmt_modes[]. Signed-off-by: Paul Parsons <lost.distance@yahoo.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160402100817.B60776E23A@gabe.freedesktop.org
2016-03-13drm/edid: Extract SADs properly from multiple audio data blocksVille Syrjälä1-6/+11
SADs may span multiple CEA audio data blocks in the EDID. CEA-861-E says: "The order of the Data Blocks is not constrained. It is also possible to have more than one of a specific type of data block if necessary to include all of the descriptors needed to describe the sink’s capabilities." Each audio data block can carry up to 10 SADs, whereas the ELD SAD limit is 15 according to HDA 1.0a spec. So we should support at least two data blocks. And apparently some devices take a more liberal interpretation and stuff only one SAD per data block even when they would fit into one. So let's try to extract all the SADs we can fit into the ELD even when they span multiple data blocks. While at it, toss in a comment to explain the 13 byte monitor name string limit which confused me at first. Cc: Arturo Pérez <artur999555@gmail.com> Tested-by: Arturo Pérez <artur999555@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94197 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1457554066-8739-1-git-send-email-ville.syrjala@linux.intel.com
2016-02-09drm/edid: Switch DDC when reading the EDIDLukas Wunner1-0/+26
Originally by Seth Forshee <seth.forshee@canonical.com>, 2012-10-04: Some dual graphics machines support muxing the DDC separately from the display, so make use of this functionality when reading the EDID on the inactive GPU. Also serialize drm_get_edid() with a mutex to avoid races on the DDC mux state. Modified by Dave Airlie <airlied@gmail.com>, 2012-12-22: I can't figure out why I didn't like this, but I rewrote this [...] to lock/unlock the ddc lines [...]. I think I'd prefer something like that otherwise the interface got really ugly. Modified by Lukas Wunner <lukas@wunner.de>, 2015-04 - 2015-09: v3: Move vga_switcheroo calls to a wrapper around drm_get_edid() which drivers can call on muxed machines. This avoids other drivers having to go through the vga_switcheroo motions even though they are never used on a muxed platform (Thierry Reding, Daniel Vetter, Alex Deucher) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115 Tested-by: Pierre Moreau <pierre.morrow@free.fr> [MBP 5,3 2009 nvidia MCP79 + G96 pre-retina 15"] Tested-by: William Brown <william@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] Tested-by: Lukas Wunner <lukas@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"] Cc: Seth Forshee <seth.forshee@canonical.com> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/b898d0da4c134f2642d0122479006863e1830723.1452525860.git.lukas@wunner.de
2016-01-08drm/edid: index CEA/HDMI mode tables using the VICJani Nikula1-41/+53
Add a dummy entry to CEA/HDMI mode tables so they can be indexed directly using the VIC, avoiding a +1/-1 dance here and there. This adds clarity to the error checking for various functions that return the VIC on success and zero on failure; we can now explicitly check for 0 instead of just subtracting one from an unsigned type. Also add drm_valid_cea_vic() and drm_valid_hdmi_vic() helpers for checking valid VICs. v2: add drm_valid_cea_vic and drm_valid_hdmi_vic helpers (Ville) use { } instead of { 0 } for initializing the dummy modes Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452252111-6439-1-git-send-email-jani.nikula@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-12-01drm/edid: Make the detailed timing CEA/HDMI mode fixup accept up to 5kHz ↵Ville Syrjälä1-2/+60
clock difference Rather than using drm_match_cea_mode() to see if the EDID detailed timings are supposed to represent one of the CEA/HDMI modes, add a special version of that function that takes in an explicit clock tolerance value (in kHz). When looking at the detailed timings specify the tolerance as 5kHz due to the 10kHz clock resolution limit inherent in detailed timings. drm_match_cea_mode() uses the normal KHZ2PICOS() matching of clocks, which only allows smaller errors for lower clocks (eg. for 25200 it won't allow any error) and a bigger error for higher clocks (eg. for 297000 it actually matches 296913-297000). So it doesn't really match what we want for the fixup. Using the explicit +-5kHz is much better for this use case. Not sure if we should change the normal mode matching to also use something else besides KHZ2PICOS() since it allows a different proportion of error depending on the clock. I believe VESA CVT allows a maximum deviation of .5%, so using that for normal mode matching might be a good idea? Cc: Adam Jackson <ajax@redhat.com> Tested-by: nathan.d.ciobanu@linux.intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92217 Fixes: fa3a7340eaa1 ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-20drm/edid: Round to closest when computing the CEA/HDMI alternate clockVille Syrjälä1-2/+2
Rounding to the closest kHz seems like the better option that round down or up when computing the alternate clock for CEA/HDMI modes. It'll give us a slightly more accurate clock in some cases. Not sure why I went for the down+up approach originally. Perhaps I was thinking we can go back and forth betwen the two frequencies without introducing errors, but round to closest still maintains that property. Cc: Adam Jackson <ajax@redhat.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Libin Yang <libin.yang@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-20drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timingsVille Syrjälä1-0/+48
EDID detailed timings have a resolution of 10kHz for the pixel clock, so they can't represent certain CEA/HDMI modes accurately. If we see a mode coming in via detailed timings which otherwise matches one of the CEA/HDMI modes except the clock is just a bit off, let's assume that the intention was for that mode to be one of the CEA/HDMI modes and go ahead and fix up the clock to match the CEA/HDMI spec exactly (well, as close as we can get with the 1 kHz resolution we use). This should help code that's looking for an exact clock match (eg. i915 audio N/CTS setup). Cc: Adam Jackson <ajax@redhat.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Libin Yang <libin.yang@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-09drm: Make drm_av_sync_delay() 'mode' argument constVille Syrjälä1-1/+1
drm_av_sync_delay() doesn't change the passed in mode, so make it const. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-09drm: Remove the 'mode' argument from drm_select_eld()Ville Syrjälä1-3/+1
drm_select_eld() doesn't look at the passed in mode, so don't pass it in. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-09drm: Make some modes const when iterating through themVille Syrjälä1-1/+1
valid_inferred_mode() don't change the modes over which it iterates, so make the iterator const. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-11drm/edid: Use ARRAY_SIZE in drm_add_modes_noedidDaniel Vetter1-1/+1
Spotted while reading code for random reasons. Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-22drm: Roll out drm_for_each_connector moreDaniel Vetter1-1/+1
Now that we also grab the connection_mutex and so fixed the race with atomic modeset we can use the iterator there too. The other special case is drm_connector_unplug_all which would have a locking inversion with the sysfs store/show functions if we'd grab the mode_config.mutex around the unplug. We could just grab connection_mutex instead, but that's a bit too much a dirty trick for my taste. Also it's only used by udl, which doesn't do any other kind of connector hotplugging, so should be race-free. Hence just stick with a comment for now. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-05-20Merge tag 'topic/drm-misc-2015-05-19' of ↵Dave Airlie1-87/+119
git://anongit.freedesktop.org/drm-intel into drm-next Scattering of random drm core patches. Bunch of atomic prep work too, but the final bits for blob properties, atomic modesets and lifting the experimental tag on the atomic ioctl are still blocked on Daniel Stone finalizing and testing the weston support for it. I hope that we can get it all ready for 4.2 though. * tag 'topic/drm-misc-2015-05-19' of git://anongit.freedesktop.org/drm-intel: (22 commits) drm/atomic: Allow drivers to subclass drm_atomic_state, v3 drm/atomic: remove duplicated assignment of old_plane_state drm/dp: Fix comment in DP helper drm/atomic: add drm_atomic_get_existing_*_state helpers drm/core: get rid of -Iinclude/drm drm/i915: get rid of -Iinclude/drm drm/atomic-helpers: Export drm_atomic_helper_update_legacy_modeset_state drm/atomic-helpers: Update vblank timestamping constants drm/sysfs: remove unnecessary connector type checks drm/sysfs: split DVI-I and TV-out attributes drm/sysfs: make optional attribute groups per connector type drm/sysfs: add a helper for extracting connector type from kobject drm/edid: Add CEA modes before inferred modes drm/prime: Allow internal imports without import_sg_table drm: Add reference counting to blob properties drm: Introduce blob_lock drm: Introduce helper for replacing blob properties drm: Don't leak path blob property when updating drm/atomic: Don't open-code CRTC state destroy drm/edid: Add DMT modes with ID > 0x50 ...
2015-05-12drm/edid: Add CEA modes before inferred modesVille Syrjälä1-2/+2
Currently we're adding CEA modes after the inferred modes, which means we might get multiple modes that are very close to each other, but slightly different, which seems a bit silly. That's because duplicate mode check that occurs when adding inferred modes would not consider CEA modes as potential duplicates. Reverse the order so that CEA modes get added before inferred modes, and are thus considered potential duplicates. Or as ajax put it on irc: "< ajax> the point of the "pick a timing formula" heuristic was to generate something the sink could _likely_ sink. if it tells us timings it can sink explicitly then second-guessing seems dumb." Cc: Adam Jackson <ajax@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-08drm/edid: Kerneldoc for newly added edid_corruptDaniel Vetter1-4/+4
Also treat it as a proper boolean. Cc: Todd Previte <tprevite@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-05-08drm: Add edid_corrupt flag for Displayport Link CTS 4.2.2.6Todd Previte1-6/+26
Displayport compliance test 4.2.2.6 requires that a source device be capable of detecting a corrupt EDID. The test specification states that the sink device sets up the EDID with an invalid checksum. To do this, the sink sets up an invalid EDID header, expecting the source device to generate the checksum and compare it to the value stored in the last byte of the block data. Unfortunately, the DRM EDID reading and parsing functions are actually too good in this case; the header is fixed before the checksum is computed and thus the test never sees the invalid checksum. This results in a failure to pass the compliance test. To correct this issue, when the EDID code detects that the header is invalid, a flag is set to indicate that the EDID is corrupted. In this case, it sets edid_corrupt flag and continues with its fix-up code. This flag is also set in the case of a more seriously damaged header (fixup score less than the threshold). For consistency, the edid_corrupt flag is also set when the checksum is invalid as well. V2: - Removed the static bool global - Added a bool to the drm_connector struct to reaplce the static one for holding the status of raw edid header corruption detection - Modified the function signature of the is_valid function to take an additional parameter to store the corruption detected value - Fixed the other callers of the above is_valid function V3: - Updated the commit message to be more clear about what and why this patch does what it does. - Added comment in code to clarify the operations there - Removed compliance variable and check_link_status update; those have been moved to a later patch - Removed variable assignment from the bottom of the test handler V4: - Removed i915 tag from subject line as the patch is not i915-specific V5: - Moved code causing a compilation error to this patch where the variable is actually declared - Maintained blank lines / spacing so as to not contaminate the patch V6: - Removed extra debug messages - Added documentation to for the added parameter on drm_edid_block_valid - Fixed more whitespace issues in check_link_status - Added a clear of the header_corrupt flag to the end of the test handler in intel_dp.c - Changed the usage of the new function prototype in several places to use NULL where it is not needed by compliance testing V7: - Updated to account for long_pulse flag propagation V8: - Removed clearing of header_corrupt flag from the test handler in intel_dp.c - Added clearing of header_corrupt flag in the drm_edid_block_valid function V9: - Renamed header_corrupt flag to edid_corrupt to more accurately reflect its value and purpose - Updated commit message V10: - Updated for versioning and patch swizzle - Revised the title to more accurately reflect the nature and contents of the patch - Fixed formatting/whitespace problems - Added set flag when computed checksum is invalid Signed-off-by: Todd Previte <tprevite@gmail.com> Cc: dri-devel@lists.freedesktop.org Acked-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-07drm/edid: Add DMT modes with ID > 0x50Ville Syrjälä1-0/+32
DMT Version 1.0, Rev. 13 lists a bunch of new modes we don't currently have in our dmt mode table. So add them. The order may look a bit weird since it's not sorted based on the DMT ID, but this is the order they appear in the standard. I suppose they are ordered by the resolution, pixel clock, or some such factor. I decided that it's perhaps best to keep the same order as the spec. Cc: "liu,lei" <lei.a.liu@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-07drm/edid: Add the DMT ID in the commentsVille Syrjälä1-80/+80
To help with matching things to spec, include the DMT ID in the comments in out DMT mode table. Cc: "liu,lei" <lei.a.liu@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-07drm/edid: Fix up DMT modesVille Syrjälä1-5/+5
Liu Lei noticed that our 1856x1392@75Hz DMT mode doesn't match the spec. Fix that up, and also fix up a few other inconsistencies I discovered by parsing the spec (DMT version 1.0, revision 13) and comparing the results to our current DMT mode table. Also clean up the indentation mess for the 1024x768i mode. Cc: "liu,lei" <lei.a.liu@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-11Merge tag 'topic/core-stuff-2014-12-10' of ↵Dave Airlie1-15/+28
git://anongit.freedesktop.org/drm-intel into drm-next Merge drm core fixes from Daniel. * tag 'topic/core-stuff-2014-12-10' of git://anongit.freedesktop.org/drm-intel: drm: Zero out DRM object memory upon cleanup drm: fix a typo in a comment drm: fix a word repetition in a comment drm: Fix memory leak at error path of drm_read() drm/Documentation: Fix rowspan value in drm-kms-properties drm/edid: Restore kerneldoc consistency drm/edid: new drm_edid_block_checksum helper function V3 drm/edid: shorten log output in case of all zeroes edid block drm/edid: move drm_edid_is_zero to top, make edid argument const
2014-12-09drm/connector: store tile information from displayid (v3)Dave Airlie1-3/+141
This creates a tile group from DisplayID block, and stores the pieces of parsed info from the DisplayID block into the connector. v2: add missing signoff, add new connector bits to docs. v3: remove some debugging. Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-03drm/edid: Restore kerneldoc consistencyThierry Reding1-1/+1
Commit 18df89fef2d5 ("drm: Decouple EDID parsing from I2C adapter") renamed the adapter parameter of the drm_do_probe_ddc_edid function to data but didn't update the kerneldoc accordingly. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-06 15:13:39 +0000