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
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
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
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>
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: fa3a7340ea ("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>
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>
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>
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>
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>
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>
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>
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
...
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>
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>
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>
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>
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>
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>
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
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>
Commit 18df89fef2 ("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>
drm-intel-next-2014-11-21:
- infoframe tracking (for fastboot) from Jesse
- start of the dri1/ums support removal
- vlv forcewake timeout fixes (Imre)
- bunch of patches to polish the rps code (Imre) and improve it on bdw (Tom
O'Rourke)
- on-demand pinning for execlist contexts
- vlv/chv backlight improvements (Ville)
- gen8+ render ctx w/a work from various people
- skl edp programming (Satheeshakrishna et al.)
- psr docbook (Rodrigo)
- piles of little fixes and improvements all over, as usual
* tag 'drm-intel-next-2014-11-21-fixed' of git://anongit.freedesktop.org/drm-intel: (117 commits)
drm/i915: Don't pin LRC in GGTT when dumping in debugfs
drm/i915: Update DRIVER_DATE to 20141121
drm/i915/g4x: fix g4x infoframe readout
drm/i915: Only call mod_timer() if not already pending
drm/i915: Don't rely upon encoder->type for infoframe hw state readout
drm/i915: remove the IRQs enabled WARN from intel_disable_gt_powersave
drm/i915: Use ggtt error obj capture helper for gen8 semaphores
drm/i915: vlv: increase timeout when setting idle GPU freq
drm/i915: vlv: fix cdclk setting during modeset while suspended
drm/i915: Dump hdmi pipe_config state
drm/i915: Gen9 shadowed registers
drm/i915/skl: Gen9 multi-engine forcewake
drm/i915: Read power well status before other registers for drpc info
drm/i915: Pin tiled objects for L-shaped configs
drm/i915: Update ring freq for full gpu freq range
drm/i915: change initial rps frequency for gen8
drm/i915: Keep min freq above floor on HSW/BDW
drm/i915: Use efficient frequency for HSW/BDW
drm/i915: Can i915_gem_init_ioctl
drm/i915: Sanitize ->lastclose
...
The function will also be used by a later patch, so factor it out.
V2: make raw_edid const, define/declare before first use
V3: fix erroneuos removal of csum variable
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no need to dump the whole EDID block in case it contains no
information. Just print a single line stating the block is empty instead
of 8 lines containing only zeroes.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_edid_is_zero will be used by drm_edid_block valid, move it up.
raw_edid argument can be const.
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The drm_get_edid() function performs direct I2C accesses to read EDID
blocks, assuming that the monitor DDC interface is directly connected to
the I2C bus. It can't thus be used with HDMI encoders that control the
DDC bus and expose EDID blocks through a different interface.
Refactor drm_do_get_edid() to take a block read callback function
instead of an I2C adapter, and export it for direct use by drivers.
As in the general case the DDC bus is accessible by the kernel at the
I2C level, drivers must make all reasonable efforts to expose it as an
I2C adapter and use drm_get_edid() instead of abusing this function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Baseline_ELD_Len field does not include ELD Header Block size.
From High Definition Audio Specification, Revision 1.0a:
The header block is a fixed size of 4 bytes. The baseline block
is variable size in multiple of 4 bytes, and its size is defined
in the header block Baseline_ELD_Len field (in number of
DWords).
Do not include the header size in Baseline_ELD_Len field. Fix all known
users of eld[2].
While at it, switch to DIV_ROUND_UP instead of open coding it.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Dave Airlie <airlied@linux.ie>
[danvet: Fix compile fail in nouveau.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CEA VICs 44 and 45 were missing DRM_MODE_FLAG_INTERLACE.
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pixel replicated modes should be non-2x horizontal timings and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently fails for all pixel replicated modes. This change will
allow HDMI certification with 480i/576i modes once pixel replication
is turned on.
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use c99 initializers for structures.
Drop 0 initializers in drivers/gpu/drm/sti/sti_vtac.c. A 0x0 initializer
is left in vtac_mode_aux in drivers/gpu/drm/sti/sti_vtac.c to highlight the
relation to vtac_mode_main.
A simplified version of the semantic match that finds the first problem is
as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@
struct i1 {
fs
T fld;
...};
@bad@
identifier decl.i1,i2;
expression e;
initializer list[decl.n] is;
@@
struct i1 i2 = { is,
+ .fld = e
- e
,...};
// </smpl>
v2: Drop 0 initializers and add trailing commas at the suggestions of Josh
Triplett.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bunch of small leftovers spotted by looking at the make htmldocs output.
I've left out dp mst, there's too much amiss there.
v2: Also add the missing parameter docbook in the dp mst code - Dave
Airlie correctly pointed out that we don't actually want kerneldoc for
the missing structure members in header files.
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull in drm-next with Dave's DP MST support so that I can merge some
conflicting patches which also touch the driver load sequencing around
interrupt handling.
Conflicts:
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_dp.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In case user has specified an input for aspect ratio through the property,
then the user space value for PAR would take preference over the value from
CEA mode list.
v2: Thierry's review comments.
- Modified the comment "Populate..." as per review comments
v3: Thierry's review comments.
- Modified the comment to block comment format.
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm_select_eld should check for mode_config.connection_mutex as
well as mode_config.mutex: We need that since this function checks
conector->encoder links.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
[danvet: Pimp commit message slightly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HDMI deep color setup must know which modes are supported if
it needs to degrade gracefully, as only 12 bpc / dc_36 is
guaranteed, but 10 bpc / dc_30 is optional. The maximum bpc
is not sufficient for this.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
After the split-out of crtc locks from the big mode_config.mutex
there's still two major areas it protects:
- Various connector probe states, like connector->status, EDID
properties, probed mode lists and similar information.
- The links from connector->encoder and encoder->crtc and other
modeset-relevant connector state (e.g. properties which control the
panel fitter).
The later is used by modeset operations. But they don't really care
about the former since it's allowed to e.g. enable a disconnected VGA
output or with a mode not in the probed list.
Thus far this hasn't been a problem, but for the atomic modeset
conversion Rob Clark needs to convert all modeset relevant locks into
w/w locks. This is required because the order of acquisition is
determined by how userspace supplies the atomic modeset data. This has
run into troubles in the detect path since the i915 load detect code
needs _both_ protections offered by the mode_config.mutex: It updates
probe state and it needs to change the modeset configuration to enable
the temporary load detect pipe.
The big deal here is that for the probe/detect users of this lock a
plain mutex fits best, but for atomic modesets we really want a w/w
mutex. To fix this lets split out a new connection_mutex lock for the
modeset relevant parts.
For simplicity I've decided to only add one additional lock for all
connector/encoder links and modeset configuration states. We have
piles of different modeset objects in addition to those (like bridges
or panels), so adding per-object locks would be much more effort.
Also, we're guaranteed (at least for now) to do a full modeset if we
need to acquire this lock. Which means that fine-grained locking is
fairly irrelevant compared to the amount of time the full modeset will
take.
I've done a full audit, and there's just a few things that justify
special focus:
- Locking in drm_sysfs.c is almost completely absent. We should
sprinkle mode_config.connection_mutex over this file a bit, but
since it already lacks mode_config.mutex this patch wont make the
situation any worse. This is material for a follow-up patch.
- omap has a omap_framebuffer_flush function which walks the
connector->encoder->crtc links and is called from many contexts.
Some look like they don't acquire mode_config.mutex, so this is
already racy. Again fixing this is material for a separate patch.
- The radeon hot_plug function to retrain DP links looks at
connector->dpms. Currently this happens without any locking, so is
already racy. I think radeon_hotplug_work_func should gain
mutex_lock/unlock calls for the mode_config.connection_mutex.
- Same applies to i915's intel_dp_hot_plug. But again, this is already
racy.
- i915 load_detect code needs to acquire this lock. Which means the
w/w dance due to Rob's work will be nicely contained to _just_ this
function.
I've added fixme comments everywhere where it looks suspicious but in
the sysfs code. After a quick irc discussion with Dave Airlie it
sounds like the lack of locking in there is due to sysfs cleanup fun
at module unload.
v1: original (only compile tested)
v2: missing mutex_init(), etc (from Rob Clark)
v3: i915 needs more care in the conversion:
- Protect the edp pp logic with the connection_mutex.
- Use connection_mutex in the backlight code due to
get_pipe_from_connector.
- Use drm_modeset_lock_all in suspend/resume paths.
- Update lock checks in the overlay code.
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
The Sony PVM-2541A OLED high precision color display supports
both 10 bpc and 12 bpc hdmi deep color input, but its edid
does not signal any deep color support.
Add a quirk to force it being treated as a 12 bpc panel.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Check the HDMI cea block for deep color mode bits. If available,
assign the highest supported bpc for a hdmi display, corresponding
to the given deep color modes.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This issue was reported by coccicheck using the semantic patch
at scripts/coccinelle/api/memdup.cocci
Signed-off-by: Benoit Taine <benoit.taine@lip6.fr>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes up a couple of inconsistencies with kerneldoc comments for
the EDID related functions. Functions that return a value now use the
"Return" section consistently. For some exported symbols the kernel-doc
comments were not in the appropriate format and therefore not included
in the generated documentation. Others had no kernel-doc at all.
While at it, fix a couple of whitespace issues and capitalize common
abbreviations (i2c -> I2C, edid -> EDID, ...).
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This argument is used to pass in the revision of the EDID, but since the
EDID is passed in as well, we can just as well get the revision from the
EDID structure directly.
While at it, update the kerneldoc comment.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Populate PAR in infoframe structure. If there is a user setting for PAR, then
that value is set. Else, value is taken from CEA mode list if VIC is found.
Else, PAR is calculated from resolution. If none of these conditions are
satisfied, PAR is NONE as per initialization.
v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.
A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.
v2: Removed the part which sets PAR according to user input, based on
Daniel's review comments.
v3: Removed calculation of PAR for non-CEA modes as per discussion with
Ville.
A separate patch will be submitted to create a property that would enable a
user space app to set aspect ratio for AVI infoframe.
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Cc: Jesse Barnes <jesse.barnes@intel.com>
Cc: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Squash in fixup for htmldocs.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Merge straggling core drm patches.
* 'topic/core-stuff' of git://git.freedesktop.org/git/drm-intel:
drm: Fix use-after-free in the shadow-attache exit code
drm/fb-helper: Do the 'max_conn_count' zero check
drm: Check if the allocation has succeeded before dereferencing newmode
drm/fb-helper: Use drm_fb_helper_restore_fbdev_mode() in drm_fb_helper_set_par()
drm/edid: request HDMI underscan by default
We allocate memory in drm_display_mode_from_vic_index() and use it
without checking the pointer is valid. Fix that.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's a neat FIXME asking whether this is really need. I'd
say really no.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Also do s/RETURNS/Returns/, less yelling in docs is always good.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Working with HDMI TVs is a real pain as they tend to overscan by
default, meaning that the pixels around the edge of the framebuffer
are not displayed. This is well explained here:
http://mjg59.dreamwidth.org/8705.html
There is a bit in the HDMI info frame that can request that the
remote display shows the full pixel data ("underscan"). For the
remote display, the HDMI spec states that this is optional - it
doesn't have to listen. That means that most TVs will probably ignore
this.
But, maybe there are a handful of TVs for which this would help
the situation. As we live in a digital world, ask the remote
display not to overscan by default.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
CEA-861E Table 4. This is useful for filling up the detail in AVI
infoframe.
v2: Ville's review comments incorporated
Added picture aspect ratio as part of edid_cea_modes instead of DRM_MODE
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
