Generated using semantic patch:

@@
expression E;
@@

- drm_get_connector_name(E)
+ E->name

[airlied: regenerated]
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.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: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex 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: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This issue was reported by coccicheck using the semantic patch
at scripts/coccinelle/api/memdup.cocci
Signed-off-by: NBenoit Taine <benoit.taine@lip6.fr>
Signed-off-by: NDave 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: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel 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: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel 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: NVandana 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: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Squash in fixup for htmldocs.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We allocate memory in drm_display_mode_from_vic_index() and use it
without checking the pointer is valid. Fix that.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's a neat FIXME asking whether this is really need. I'd
say really no.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Also do s/RETURNS/Returns/, less yelling in docs is always good.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel 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: NDaniel Drake <drake@endlessm.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel 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: NVandana Kannan <vandana.kannan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Data Block.

v2: Use an offset value depending on 3D_Multi_present and add
    detail_present. (Ville Syrjälä)
v3: Make sure the list is parsed even if 3D_Structure_ALL/MASK is not
    present. (Ville Syrjälä)
    Fix one length check and remove another. (Ville Syrjälä)
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This bug in EDID was exposed by:

commit eccea792
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Mon Mar 26 15:12:54 2012 -0400

    drm/radeon/kms: improve bpc handling (v2)

Which resulted in kind of regression in 3.5. This fixes
https://bugs.freedesktop.org/show_bug.cgi?id=70934Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Ensure the side-by-side (half) flag is added to any existing flags when
adding modes from 3D_Structure_ALL.
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The vrefresh field of the mode is 0 for most modes
fetched from the EDID (e.g., established timings).
When dealing with monitors that have a bogus preferred
mode, we may not always select the mode we want because
we compare the target refresh to the mode's vrefresh which
is 0 in a lot of cases.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

New helper function to set the preferred video mode.  Can be called
after drm_add_modes_noedid if you don't want the largest supported
video mode be used by default.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I got very confused when I tried to compare the EST modes with the spec.
Bring over a comment from xf86EdidModes.c that actually describes some
of history where these things came from.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Also check the est3 modes whose presence is indicated by bit 0.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The correct refresh rate for this mode is 75, not 85.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.

v2: Use (1 << 0) for consistency. (Ville Syrjälä)
    Skip adding any modes if 3D_MASK is indicated as being present but
    the length only includes 3D_Structure_ALL. (Ville Syrjälä)
    Check that the value of HDMI_3D_LEN is large enough to include
    3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä)
v3: Increment offset before the length checks. (Ville Syrjälä)
Signed-off-by: NThomas Wood <thomas.wood@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Return -ENOMEM if the allocation fails.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>

This allows us to use fewer bits in the mode structure, leaving room for
future work while allowing more stereo layouts types than we could have
ever dreamt of.

I also exposed the previously private DRM_MODE_FLAG_3D_MASK to set in
stone that we are using 5 bits for the stereo layout enum, reserving 32
values.

Even with that reservation, we gain 3 bits from the previous encoding.

The code adding the mandatory stereo modes needeed to be adapted as it was
relying or being able to or stereo layouts together.
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This allows to expose the alternate clock versions of the stereo modes.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When scanning out a stereo mode, the AVI infoframe vic field has to be
the underlyng 2D VIC. Before that commit, we weren't matching the CEA
mode because of the extra stereo flag and then were setting the VIC
field in the AVI infoframe to 0.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When scanning out a 3D mode on HDMI, we need to send an HDMI infoframe
with the corresponding layout to the sink.

v2: Make s3d_structure_from_display_mode() less subtle (Ville Syrjälä)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So we respect a nice design of having similar functions at the same
level, in this case:

do_hdmi_vsdb_modes()
  - add_hdmi_mandatory_stereo_modes()
  - add_hdmi_mode()
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.

See the HDMI 1.4a 3D extraction for detail:
  http://www.hdmi.org/manufacturer/specification.aspx

v2: Rename freq to vrefresh, make the mandatory structure a bit more
    compact, fix some white space issues and add a couple of const
    (Ville Syrjälä)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Return -ENOMEM if the allocation fails.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We have some code duplication related to EDID duplication. Add a helper.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds a helper function to extract the speaker allocation
data block from the EDID.  This data block describes what speakers
are present on the display device.

v2: update per Ville Syrjälä's comments
v3: fix copy/paste typo in memory allocation
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NRafał Miłecki <zajec5@gmail.com>

This LCD monitor (1280x1024 native) has a completely
bogus detailed timing (640x350@70hz).  User reports that
1280x1024@60 has waves so prefer 1280x1024@75.

Manufacturer: MED  Model: 7b8  Serial#: 99188
Year: 2005  Week: 5
EDID Version: 1.3
Analog Display Input,  Input Voltage Level: 0.700/0.700 V
Sync:  Separate
Max Image Size [cm]: horiz.: 34  vert.: 27
Gamma: 2.50
DPMS capabilities: Off; RGB/Color Display
First detailed timing is preferred mode
redX: 0.645 redY: 0.348   greenX: 0.280 greenY: 0.605
blueX: 0.142 blueY: 0.071   whiteX: 0.313 whiteY: 0.329
Supported established timings:
720x400@70Hz
640x480@60Hz
640x480@72Hz
640x480@75Hz
800x600@56Hz
800x600@60Hz
800x600@72Hz
800x600@75Hz
1024x768@60Hz
1024x768@70Hz
1024x768@75Hz
1280x1024@75Hz
Manufacturer's mask: 0
Supported standard timings:
Supported detailed timing:
clock: 25.2 MHz   Image Size:  337 x 270 mm
h_active: 640  h_sync: 688  h_sync_end 784 h_blank_end 800 h_border: 0
v_active: 350  v_sync: 350  v_sync_end 352 v_blanking: 449 v_border: 0
Monitor name: MD30217PG
Ranges: V min: 56 V max: 76 Hz, H min: 30 H max: 83 kHz, PixClock max 145 MHz
Serial No: 501099188
EDID (in hex):
          00ffffffffffff0034a4b80774830100
          050f010368221b962a0c55a559479b24
          125054afcf00310a0101010101018180
          000000000000d60980a0205e63103060
          0200510e1100001e000000fc004d4433
          3032313750470a202020000000fd0038
          4c1e530e000a202020202020000000ff
          003530313039393138380a2020200078
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reported-by: friedrich@mailstation.de
Cc: stable@vger.kernel.org

HDMI_IDENTIFIER was felt too generic, rename it to what it is, the IEEE
OUI corresponding to HDMI Licensing, LLC.

http://standards.ieee.org/develop/regauth/oui/oui.txt

Cc: Thierry Reding <thierry.reding@gmail.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

This can then be used by DRM drivers to setup their vendor infoframes.

v2: Fix hmdi typo (Simon Farnsworth)
v3: Adapt to the hdmi_vendor_infoframe rename
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

We'll need the HDMI OUI for the HDMI vendor infoframe data, so let's
move the DRM one to hdmi.h, might as well use the hdmi header to store
some hdmi defines.

(Note that, in fact, infoframes are part of the CEA-861 standard, and
only the HDMI vendor specific infoframe is special to HDMI, but
details..)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

To set the active aspect ratio value in the AVI infoframe today, you not
only have to set the active_aspect field, but also the active_info_valid
bit. Out of the 1 user of this API, we had 100% misuse, forgetting the
_valid bit. This was fixed in:

  Author: Damien Lespiau <damien.lespiau@intel.com>
  Date:   Tue Aug 6 20:32:17 2013 +0100

      drm: Don't generate invalid AVI infoframes for CEA modes

We can do better and derive the _valid bit from the user wanting to set
the active aspect ratio.

v2: Fix multi-lines comment style (Thierry Reding)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

v2: Fix hmdi typo (Simon Farnsworth, Ville Syrjälä)
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

HDMI 1.4 adds 4 "4k x 2k" modes in the the CEA vendor specific block.

With this commit, we now parse this block and expose the 4k modes that
we find there.

v2: Fix the "4096x2160" string (nice catch!), add comments about
    do_hdmi_vsdb_modes() arguments and make it clearer that offset is
    relative to the end of the required fields of the HDMI VSDB
    (Ville Syrjälä)

v3: Fix 'Unknow' typo (Simon Farnsworth)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Tested-by: NCancan Feng <cancan.feng@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>