This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.

V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: Rebase
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NShashank Sharma <shashank.sharma@intel.com>
Reviewed-by: NJose Abreu <joabreu@synopsys.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-3-git-send-email-shashank.sharma@intel.com

Use a more common logging style.

Miscellanea:

o Coalesce formats and realign arguments
Signed-off-by: NJoe Perches <joe@perches.com>
[danvet: Resolve minor conflict in drm_edid.c]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Skip DDC probe for forced connector status. Don't try to read the EDID
if the connector is forced off. Skipping probe for forced on connectors
will make more sense when drm_do_get_edid() will handle override and
firmware EDIDs.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487344854-18777-4-git-send-email-jani.nikula@intel.com

Make the drm_edid_to_eld() function useful for resetting, not just
setting, the ELD and HDMI VSDB data, without debug warnings about
missing CEA extensions.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487344854-18777-3-git-send-email-jani.nikula@intel.com

The warnings from parsing the EDID are not driver errors, but the
"normal but significant" conditions from the external device. As such,
they do not need the ferocity of an *ERROR*, but can use the less harsh
DRM_NOTE instead.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170210195913.9878-1-chris@chris-wilson.co.uk

It's common to share screens within CI labs, and it's also common for
KVM switches to alter the contents of the CEA block but leave the
checksum outdated.

So in this case, print a debug message instead of an error.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Tested-by: NJari Tahvanainen <jari.tahvanainen@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1481202716-31317-1-git-send-email-tomeu.vizoso@collabora.com

This is just a cleanup, no functional change.

The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is
basically a copy of the existing code in drm_edid.c.  Make the latter
code public so that it can be called from the former function.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170117164329.10551-1-tiwai@suse.deReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[vsyrjala: include drm_crtc_internal.h to make sparse happy]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

CEA-861-F tells us:
"When transmitting any RGB colorimetry, the Source should set the
 YQ-field to match the RGB Quantization Range being transmitted
 (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
 set YQ=1) and the Sink shall ignore the YQ-field."

So let's go ahead and do that. Perhaps there are sinks that don't
ignore the YQ as they should for RGB?

I wasn't able to find similar text in CEA-861-E, so it would seem
to be a fairly "recent" addition.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-6-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

HDMI 2.0 recommends that we set the Q bits in the AVI infoframe
even when the sink does not support quantization range selection (QS=0).
According to CEA-861 we can do that as long as the Q we send matches
the default quantization range for the mode.

Previously I think I had misread the spec as saying that you can't
send a non-zero Q at all when QS=0. But that's not what the spec
actually says.

v2: Fix typo in commit message (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-5-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

Pull the logic to populate the quantization range information
in the AVI infoframe into a small helper. We'll be adding a bit
more logic to it, and having it in a central place seems like a
good idea since it's based on the CEA-861 spec.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111125725.8086-4-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

Make the code selecting the RGB quantization range a little less magicy
by wrapping it up in a small helper.

v2: s/adjusted_mode/mode in vc4 to make it actually compile
v3: Add a comment proposed by Eric
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111141835.25369-1-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NEric Anholt <eric@anholt.net>

No reason not to be const.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1482923186-22430-1-git-send-email-jani.nikula@intel.com

<drm/drm_crtc.h> used to define most of the in-kernel KMS API. It has
now been split into separate files for each object type, but still
includes most other KMS headers to avoid breaking driver compilation.

As a step towards fixing that problem, remove the inclusion of
<drm/drm_encoder.h> from <drm/drm_crtc.h> and include it instead where
appropriate. Also remove the forward declarations of the drm_encoder and
drm_encoder_helper_funcs structures from <drm/drm_crtc.h> as they're not
needed in the header.

<drm/drm_encoder.h> now has to include <drm/drm_mode.h> and contain a
forward declaration of struct drm_encoder in order to allow including it
as the first header in a compilation unit.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Sinclair Yeh <syeh@vmware.com> # For vmwgfx
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1481709550-29226-2-git-send-email-laurent.pinchart+renesas@ideasonboard.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAndrzej Hajda <a.hajda@samsung.com>

The only user was i915, which is now gone.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille 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

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1478177609-16762-1-git-send-email-ville.syrjala@linux.intel.com

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=98228Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161024113821.26263-1-chris@chris-wilson.co.uk

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: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161017083514.21772-2-chris@chris-wilson.co.uk

The "block" variable points to the entire edid, not individual blocks
despite it being named such.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161017083514.21772-1-chris@chris-wilson.co.uk

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-9-git-send-email-ville.syrjala@linux.intel.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-8-git-send-email-ville.syrjala@linux.intel.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-7-git-send-email-ville.syrjala@linux.intel.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-6-git-send-email-ville.syrjala@linux.intel.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-5-git-send-email-ville.syrjala@linux.intel.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-4-git-send-email-ville.syrjala@linux.intel.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-3-git-send-email-ville.syrjala@linux.intel.com

Clear out stale audio latency information (potentially from a previous
EDID) before constructing the ELD from the EDID.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-2-git-send-email-ville.syrjala@linux.intel.com

  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: NClint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1471282288-30909-1-git-send-email-clinton.a.taylor@intel.com

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: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1471034937-651-19-git-send-email-daniel.vetter@ffwll.ch

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: NMario 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: NDave Airlie <airlied@redhat.com>

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 013dd9e0
("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: NMario 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: NDave Airlie <airlied@redhat.com>

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=95207Signed-off-by: NDave Airlie <airlied@redhat.com>

We need to use this for validating modeline additions.
Signed-off-by: NDave Airlie <airlied@redhat.com>

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=95207Signed-off-by: NTomas Bzatek <tomas@bzatek.net>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This just makes the code easier to follow.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

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: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJim Bride <jim.bride@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-1-git-send-email-jim.bride@linux.intel.com

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: NPaul Parsons <lost.distance@yahoo.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160404193639.8631D6E66B@gabe.freedesktop.org

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: NPaul Parsons <lost.distance@yahoo.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160328002258.E75DF6E35D@gabe.freedesktop.org

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: NPaul Parsons <lost.distance@yahoo.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani 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: NArturo Pérez <artur999555@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94197Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1457554066-8739-1-git-send-email-ville.syrjala@linux.intel.com