At the point of creating the hibernation image, the runtime power manage
core is disabled - and using the rpm functions triggers a warn.
i915_gem_shrink_all() tries to unbind objects, which requires device
access and so tries to how an rpm reference triggering a warning:

[   44.235420] ------------[ cut here ]------------
[   44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235426] WARN_ON_ONCE(ret < 0)
[   44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci
[   44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ #130
[   44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015
[   44.235450] Workqueue: events_unbound async_run_entry_fn
[   44.235453]  0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8
[   44.235454]  0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0
[   44.235456]  ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840
[   44.235456] Call Trace:
[   44.235459]  [<ffffffff81306c2f>] dump_stack+0x4d/0x6e
[   44.235461]  [<ffffffff81056c01>] __warn+0xd1/0xf0
[   44.235464]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235465]  [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60
[   44.235468]  [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0
[   44.235469]  [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0
[   44.235471]  [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360
[   44.235473]  [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90
[   44.235475]  [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30
[   44.235476]  [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30
[   44.235478]  [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90
[   44.235479]  [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40
[   44.235481]  [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130
[   44.235483]  [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0
[   44.235484]  [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0
[   44.235486]  [<ffffffff81077557>] async_run_entry_fn+0x37/0x150
[   44.235488]  [<ffffffff8106f518>] process_one_work+0x148/0x3f0
[   44.235490]  [<ffffffff8106f8eb>] worker_thread+0x12b/0x490
[   44.235491]  [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0
[   44.235492]  [<ffffffff81074d09>] kthread+0xc9/0xe0
[   44.235495]  [<ffffffff816e257f>] ret_from_fork+0x1f/0x40
[   44.235496]  [<ffffffff81074c40>] ? kthread_park+0x60/0x60
[   44.235497] ---[ end trace e438706b97c7f132 ]---

Alternatively, to actually shrink everything we have to do so slightly
earlier in the hibernation process.

To keep lockdep silent, we need to take struct_mutex for the shrinker
even though we know that we are the only user during the freeze.

Fixes: 7aab2d53 ("drm/i915: Shrink objects prior to hibernation")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-2-chris@chris-wilson.co.uk
(cherry picked from commit 6a800eab)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Following commit 821ed7df ("drm/i915: Update reset path to fix
incomplete requests") we no longer mark the context as lost on reset as
we keep the requests (and contexts) alive. However, RPS remains reset
and we need to restore the current state to match the in-flight
requests.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824
Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-1-chris@chris-wilson.co.uk
(cherry picked from commit f2a91d1a)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Reapply the PPS register unlock workaround after GPU reset on platforms
where the reset clobbers the display HW state. This at least gets rid of
the related WARN during LVDS encoder enabling on PNV.

Fixes: ed6143b8 ("drm/i915/lvds: Restore initial HW state during encoder enabling")
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473847453-4771-1-git-send-email-imre.deak@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 51f59205)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.

v2 by Jani, rebase on the patch caching alt increment

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486
References: https://bugs.freedesktop.org/show_bug.cgi?id=67454
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Wei Shun Chen <wei.shun.chang@intel.com>
Cc: Gary C Wang <gary.c.wang@intel.com>
Cc: stable@vger.kernel.org # v4.4+ 16e1203d drm/i915/backlight: setup and cache...
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShawn Lee <shawn.c.lee@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/8265f5935bd31c039ddfc82819d26c2ca1ae9cba.1474281249.git.jani.nikula@intel.com
(cherry picked from commit e29aff05)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This will also be needed later on when setting up the alternate
increment in backlight enable.

Cc: Shawn Lee <shawn.c.lee@intel.com>
Cc: <stable@vger.kernel.org>
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/9984b20bc59aee90b83caf59ce91f3fb122c9627.1474281249.git.jani.nikula@intel.com
(cherry picked from commit 32b421e7)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Just some misc bug fixes for 4.9.

* 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux:
  drm/amdgpu: revert "use more than 64KB fragment size if possible"
  drm/amdgpu: warn if dp aux is still attached on free
  drm/amdgpu/dce11: add missing drm_mode_config_cleanup call
  drm/amdgpu: also track late init state
  drm/amdgpu/virtual_dce: adjust config ifdef
  drm/amdgpu/vce: add support for hw config packet (v2)
  drm/amdgpu: clean up to set fw_offset as 0 twice
  drm/amdgpu: remove DRM_AMD_POWERPLAY
  drm/radeon: Prevent races on pre DCE4 between flip submission and completion.
  drm/radeon: Slightly more robust flip completion handling for < DCE-4

Another attempt, this time rebased and without the pipe crc patches:
- display_info cleanups from Ville
- make prime/gem lookups faster with rbtrees (Chris)
- misc stuff all over

* tag 'topic/drm-misc-2016-10-05' of git://anongit.freedesktop.org/drm-intel:
  drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support it
  drm/bridge: analogix_dp: Add analogix_dp_psr_supported
  drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm: Document caveats around atomic event handling
  uapi: add missing install of sync_file.h
  drm: Simplify drm_printk to reduce object size quite a bit
  drm/i915: Account for sink max TMDS clock when checking the port clock
  drm/i915: Replace a bunch of connector->base.display_info with a local variable
  drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld()
  drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID
  drm/edid: Reduce the number of times we parse the CEA extension block
  drm/edid: Don't pass around drm_display_info needlessly
  drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info
  drm/edid: Make max_tmds_clock kHz instead of MHz
  drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID
  drm/edid: Clear old audio latency values before parsing the new EDID
  drm: Convert prime dma-buf <-> handle to rbtree
  drm/mediatek: mark symbols static where possible
  drm/rockchip: mark symbols static where possible
  drm/rockchip: add missing header dependencies

This pull request brings in several fixes for drm-next, mostly for
HDMI.

* tag 'drm-vc4-next-2016-10-06' of https://github.com/anholt/linux:
  drm/vc4: Add support for double-clocked modes.
  drm/vc4: Set up the AVI and SPD infoframes.
  drm/vc4: Fix support for interlaced modes on HDMI.
  drm/vc4: Increase timeout for HDMI_SCHEDULER_CONTROL changes.
  drm/vc4: Fall back to using an EDID probe in the absence of a GPIO.
  drm/vc4: Enable limited range RGB output on HDMI with CEA modes.
  drm/vc4: Fix races when the CS reads from render targets.
  drm/vc4: cleanup with list_first_entry_or_null()

Now that we have infoframes to report the pixel repeat flag, we can
start using it.  Fixes locking the 720x480i and 720x576i modes on my
Dell 2408WFP.  Like the 1920x1080i case, they don't fit properly on
the screen, though.
Signed-off-by: NEric Anholt <eric@anholt.net>

Fixes a purple bar on the left side of the screen with my Dell
2408WFP.  It will also be required for supporting the double-clocked
video modes.
Signed-off-by: NEric Anholt <eric@anholt.net>

We really do need to be using the halved V fields.  I had been
confused by the code I was using as a reference because it stored
halved vsync fields but not halved vdisplay, so it looked like I only
needed to divide vdisplay by 2.

This reverts part of Mario's timestamping fixes that prevented
CRTC_HALVE_V from applying, and instead adjusts the timestamping code
to not use the crtc field in that case.

Fixes locking of 1920x1080x60i on my Dell 2408WFP.  There are black
bars on the top and bottom, but I suspect that might be an
under/overscan flags problem as opposed to video timings.
Signed-off-by: NEric Anholt <eric@anholt.net>

Fixes occasional debug spew at boot when connected directly through
HDMI, and probably confusing the HDMI state machine when we go trying
to poke registers for the enable sequence too soon.
Signed-off-by: NEric Anholt <eric@anholt.net>

On Pi0/1/2, we use an external GPIO line for hotplug detection, since
the HDMI_HOTPLUG register isn't connected to anything.  However, with
the Pi3 the HPD GPIO line has moved off to a GPIO expander that will
be tricky to get to (the firmware is constantly polling the expander
using i2c0, so we'll need to coordinate with it).

As a stop-gap, if we don't have a GPIO line, use an EDID probe to
detect connection.  Fixes HDMI display on the pi3.
Signed-off-by: NEric Anholt <eric@anholt.net>

Fixes broken grayscale ramps on many HDMI monitors, where large areas
at the ends of the ramp would all appear as black or white.
Signed-off-by: NEric Anholt <eric@anholt.net>

With the introduction of bin/render pipelining, the previous job may
not be completed when we start binning the next one.  If the previous
job wrote our VBO, IB, or CS textures, then the binning stage might
get stale or uninitialized results.

Fixes the major rendering failure in glmark2 -b terrain.
Signed-off-by: NEric Anholt <eric@anholt.net>
Fixes: ca26d28b ("drm/vc4: improve throughput by pipelining binning and rendering jobs")
Cc: stable@vger.kernel.org

The combo of list_empty() check and return list_first_entry()
can be replaced with list_first_entry_or_null().
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This reverts commit 1dcd32fb9c54334ec948a0f18174a748d6b14364.

The block size is indeed an equal match, so this can cause performance regressions.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

If this happens (and it recently did), we free a structure while part of
it is still in use, which results in non-obvious crashes. The way it's
detached is not trivial (DRM core has to call the connector .destroy
callback and things must be torn down in the right order), so better
detect it and warn early.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

All other amdgpu/dce_v* files have this call, it's only mysteriously
missing from dce_v11_0.c since the file was added and causes leaks.

Fixes: aaa36a97 ("drm/amdgpu: Add initial VI support")
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Successful sw_init() and hw_init() states are tracked, but not
late_init(). Various error paths may result in amdgpu_fini() being
called before .late init is done, so late_init needs to be tracked
to avoid unexpected or multiple .late_fini() calls.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Include the CIK asics in the ifdef.
Reviewed-By: NEmily Deng <Emily.Deng@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This is needed for proper VCE DPM on some APUs.

v2: fix the asic list
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NHuang Rui <ray.huang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Powerplay is no longer optional after the recently cleanups
Reviewed-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Pre DCE4 hw doesn't have reliable pageflip completion
interrupts, so instead polling for flip completion is
used from within the vblank irq handler to complete
page flips.

This causes a race if pageflip ioctl is called close to
vblank:

1. pageflip ioctl queues execution of radeon_flip_work_func.

2. vblank irq fires, radeon_crtc_handle_vblank checks for
   flip_status == FLIP_SUBMITTED finds none, no-ops.

3. radeon_flip_work_func runs inside vblank, decides to
   set flip_status == FLIP_SUBMITTED and programs the
   flip into hw.

4. hw executes flip immediately (because in vblank), but
   as 2 already happened, the flip completion routine only
   emits the flip completion event one refresh later ->
   wrong vblank count/timestamp for completion and no
   performance gain, as instead of delaying the flip until
   next vblank, we now delay the next flip by 1 refresh
   while waiting for the delayed flip completion event.

Given we often don't gain anything due to this race, but
lose precision, prevent the programmed flip from executing
in vblank on pre DCE4 asics to avoid this race.

On pre-AVIVO hw we can't program the hw for edge-triggered
flips, they always execute anywhere in vblank. Therefore delay
the actual flip programming until after vblank on pre-AVIVO.
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Pre DCE4 hardware doesn't have (reliable) pageflip completion
irqs, therefore we have to use the old polling method for flip
completion handling in vblank irq.

As vblank irqs fire a bit before start of vblank (when the
linebuffer fifo read position reaches end of scanout), we
have some fudge for flip completion handling in the last
lines of active scanout. Old code assumed the threshold to
be 99% of active scanout height, a ballpark estimate which
worked ok. Since we know since a while how to calculate the
actual threshold from linebuffer size, lets make use of it
to get a more accurate threshold.

This completion path is still prone to some races in corner
cases, especially on pre-AVIVO hardware, so document them
a bit better in the code comments.
Acked-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NMario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

There's no point in enabling PSR when the panel doesn't support it.

This also avoids a problem when PSR gets enabled when a CRTC is being
disabled, because sometimes in that situation the DSP_HOLD_VALID_INTR
interrupt on which we wait will never arrive. This was observed on
RK3288 with a panel without PSR (veyron-jaq Chromebook).

It's very easy to reproduce by running the kms_rmfb test in IGT a few
times.

Cc: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1474639600-30090-2-git-send-email-tomeu.vizoso@collabora.com

So users know whether PSR should be enabled or not.

Cc: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1474639600-30090-1-git-send-email-tomeu.vizoso@collabora.com

The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
implementations for functions in struct fb_ops. A drm driver can use it
like:

    static struct fb_ops drm_fbdev_cma_ops = {
        .owner          = THIS_MODULE,
        DRM_FB_HELPER_DEFAULT_OPS,
        /* driver specific implementations */
    };
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NStefan Christ <contact@stefanchrist.eu>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475182136-15191-2-git-send-email-contact@stefanchrist.eu

It's not that obvious how a driver can all race the atomic commit with
handling the completion event. And there's unfortunately a pile of
drivers with rather bad event handling which misdirect people into the
wrong direction.

Try to remedy this by documenting everything better.

v2: Type fixes Alex spotted.

v3: More typos Alex spotted.

Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475229896-6047-1-git-send-email-daniel.vetter@ffwll.ch

As part of the sync framework destaging, the sync_file.h header
was moved, but an entry was not added on Kbuild to install it.
This patch resolves this omission so that "make headers_install"
installs this header.

Fixes: 460bfc41 ("dma-buf/sync_file: de-stage sync_file headers")
Reported-by: NMichael Ellerman <mpe@ellerman.id.au>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NEmilio López <emilio.lopez@collabora.co.uk>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20160927143142.8975-1-emilio.lopez@collabora.co.uk

Remove function name and special " *ERROR*" from argument list

$ size drivers/gpu/drm/built-in.o* (x86-32 defconfig, most drm selected)
   text	   data	    bss	    dec	    hex	filename
5635366	 182579	  14328	5832273	 58fe51	drivers/gpu/drm/built-in.o.new
5779552	 182579	  14328	5976459	 5b318b	drivers/gpu/drm/built-in.o.old

Using "%ps", __builtin_return_address(0) is the same as "%s", __func__
except for static inlines, but it's more or less the same output.

Miscellanea:

o Convert args... to ##__VA_ARGS__
o The equivalent DRM_DEV_<FOO> macros are rarely used and not
  worth conversion
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/01f976d5ab93c985756fc1b2e83656fb0a2a28c8.1474856262.git.joe@perches.com

It's perfectly legal for the sink to support 12bpc only for
some lower resolution modes, while the higher resolution modes
can only be used with 8bpc. So let's take the sink's max TMDS clock
into account before we go and decide that a particular mode can
be used with 12bpc.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-11-git-send-email-ville.syrjala@linux.intel.com

Reduce the eyesore with a local variable.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1475070703-6435-10-git-send-email-ville.syrjala@linux.intel.com

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