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>

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

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

Currently we use a linear walk to lookup a handle and return a dma-buf,
and vice versa. A long overdue TODO task is to convert that to a
hashtable. Since the initial implementation of dma-buf/prime, we now
have resizeable hashtables we can use (and now a future task is to RCU
enable the lookup!). However, this patch opts to use an rbtree instead
to provide O(lgN) lookups (and insertion, deletion). rbtrees were chosen
over using the RCU backed resizable hashtable to firstly avoid the
reallocations (rbtrees can be embedded entirely within the parent
struct) and to favour simpler code with predictable worst case
behaviour. In simple testing, the difference between using the constant
lookup and insertion of the rhashtable and the rbtree was less than 10%
of the wall time (igt/benchmarks/prime_lookup) - both are dramatic
improvements over the existing linear lists.

v2: Favour rbtree over rhashtable

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94631Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160926204414.23222-1-chris@chris-wilson.co.uk

We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1089:6: warning: no previous prototype for 'mtk_hdmi_audio_enable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1095:6: warning: no previous prototype for 'mtk_hdmi_audio_disable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1101:5: warning: no previous prototype for 'mtk_hdmi_audio_set_param' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1627:5: warning: no previous prototype for 'mtk_hdmi_audio_digital_mute' [-Wmissing-prototypes]

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks both functions with 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
[seanpaul fixed checkpatch warning for argument alignment]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1474789109-22010-2-git-send-email-baoyou.xie@linaro.org

We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c:309:6: warning: no previous prototype for 'rockchip_drm_fb_suspend' [-Wmissing-prototypes]
drivers/gpu/drm/rockchip/rockchip_drm_drv.c:318:6: warning: no previous prototype for 'rockchip_drm_fb_resume' [-Wmissing-prototypes]

In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1474789388-3284-1-git-send-email-baoyou.xie@linaro.org

We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c:130:5: warning: no previous prototype for 'rockchip_drm_fbdev_init' [-Wmissing-prototypes]
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c:173:6: warning: no previous prototype for 'rockchip_drm_fbdev_fini' [-Wmissing-prototypes]

In fact, these functions are declared
in drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h,
so this patch adds missing header dependencies.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1474789109-22010-1-git-send-email-baoyou.xie@linaro.org

Before commit a3257256 ("drm: Lobotomize set_busid nonsense for !pci
drivers"), several DRM drivers for platform devices used to expose an
explicit "drm_driver.set_busid" callback, invariably backed by
drm_platform_set_busid().

Commit a3257256 removed drm_platform_set_busid(), along with the
referring .set_busid field initializations. This was justified because
interchangeable functionality had been implemented in drm_dev_alloc() /
drm_dev_init(), which DRM_IOCTL_SET_VERSION would rely on going forward.

However, commit a3257256 also removed drm_virtio_set_busid(), for
which the same consolidation was not appropriate: this .set_busid callback
had been implemented with drm_pci_set_busid(), and not
drm_platform_set_busid(). The error regressed Xorg/xserver on QEMU's
"virtio-vga" card; the drmGetBusid() function from libdrm would no longer
return stable PCI identifiers like "pci:0000:00:02.0", but rather unstable
platform ones like "virtio0".

Reinstate drm_virtio_set_busid() with judicious use of

  git checkout -p a3257256^ -- drivers/gpu/drm/virtio

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Joachim Frieben <jfrieben@hotmail.com>
Cc: stable@vger.kernel.org # v4.8
Reported-by: NJoachim Frieben <jfrieben@hotmail.com>
Fixes: a3257256
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1366842Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NEmil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I screwed up rebasing of my patch in

commit 43968d7b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Sep 21 10:59:24 2016 +0200

    drm: Extract drm_plane.[hc]

which meant on error paths drm_crtc_vblank_put could be called without
a get, leading to an underrun of the refcount.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98020Reported-and-tested-by: NAndy Furniss <adf.lists@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Michel Dänzer <michel@daenzer.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161003082827.11586-1-daniel.vetter@ffwll.chSigned-off-by: NDave Airlie <airlied@redhat.com>

Commit 43968d7b ("drm: Extract drm_plane.[hc]") was not the simple
cut'n'paste we presumed, somehow it introduced a leak of the page flip
target's framebuffer.

Fixes: 43968d7b ("drm: Extract drm_plane.[hc]")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160928222500.11827-1-chris@chris-wilson.co.ukSigned-off-by: NDave Airlie <airlied@redhat.com>

Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next

This pull request includes,
    - Code refactoring on HDMI DDC and PHY.
    - Regression fixup on deadlock issue with G2D pm integration.
    - Fixup on page fault issue with wait_for_vblank mechianism specific to Exynos drm.
    - And some cleanups.

* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: g2d: simplify g2d_free_runqueue_node()
  drm/exynos: g2d: use autosuspend mode for PM runtime
  drm/exynos: g2d: wait for engine to finish
  drm/exynos: g2d: remove runqueue nodes in g2d_{close,remove}()
  drm/exynos: g2d: move PM management to runqueue worker
  Revert "drm/exynos: g2d: fix system and runtime pm integration"
  drm/exynos: use drm core to handle page-flip event
  drm/exynos: mark exynos_dp_crtc_clock_enable() static
  drm/exynos/fimd: add clock rate checking
  drm/exynos: fix pending update handling
  drm/exynos/vidi: use timer for vblanks instead of sleeping worker
  drm/exynos: g2d: beautify probing message
  drm/exynos: mixer: simplify loop in vp_win_reset()
  drm/exynos: mixer: convert booleans to flags in mixer context
  gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk consumer
  gpu: drm: exynos_hdmi: Move PHY logic into single function
  gpu: drm: exynos_hdmi: Move DDC logic into single function

The function is never called with zero 'runqueue_node'.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The runqueue worker currently issues a get() when a new
node is processed, and a put() once a node is completed.

The corresponding suspend and resume calls currently only
do clock gating, but with the upcoming introduction of
IOMMU runpm also the corresponding IOMMU domain gets
enabled (for get()) and disabled (for put()). This
introduces performance regressions with we mitigate here.

Switch PM runtime to autosuspend, such that clock gating
and IOMMU control only happens when the engine is idle for
a 'long' time.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

While the engine works on a runqueue node it does memory access to
the buffers associated with that node.
Make sure that the engine is idle when g2d_close() and/or
g2d_remove() are called, i.e. buffer associated with the process (for
g2d_close()), or all buffers (for g2d_remove()) can be safely be
unmapped.

We have to take into account that the engine might be in an undefined
state, i.e. it hangs and doesn't become idle. In this case, we issue
a hardware reset to return the hardware and the driver context into a
proper state.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The driver might be closed (and/or removed) while there are still
nodes queued for processing.
Make sure to remove these nodes, which means all of them in
the case of g2d_remove() and only those belonging to the
corresponding process in g2d_close().
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Do all pm_runtime_{get,put}() calls in the runqueue worker.
Also keep track of the engine's idle/busy state.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This reverts commit b05984e2.

The change, i.e. merging the sleep and runpm operations, produces
a deadlock situation:
(1) exynos_g2d_exec_ioctl() prepares a runqueue node and
    calls g2d_exec_runqueue()
(2) g2d_exec_runqueue() calls g2d_dma_start() which gets
    runtime PM sync
(3) runtime PM core calls g2d_runtime_resume()
(4) g2d_runtime_resume() calls g2d_exec_runqueue(), which
    loops back to (2)

Due to mutexes that are in place, a deadlock situation is created.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>