The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
  gets closed.
- Kernel fbs (for fbdev emulation) get cleaned up by the driver code
  at module unload time.

But now i915 also reconstructs the bios fbs for a smooth transition.
And that fb is purely transitional and should get removed immmediately
once all crtcs stop using it. Of course if the i915 fbdev code decides
to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
in that case the fbdev code will grab it's own reference.

The problem is now that we also want to register that takeover fb in
the idr, so that userspace can do a smooth transition (animated maybe
even!) itself. But currently we have no one who will clean up the idr
reference once that fb isn't useful any more, and so essentially leak
it.

Fix this by no longer holding a full fb reference for the idr, but
instead just have a weak reference using kref_get_unless_zero. But
that requires us to synchronize and clean up with the idr and fb_lock
in drm_framebuffer_free, so add that. It's a bit ugly that we have to
unconditionally grab the fb_lock, but without that someone might creep
through a race.

This leak was caught by the fb leak check in drm_mode_config_cleanup.
Originally the leak was introduced in

commit 46f297fb
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Fri Mar 7 08:57:48 2014 -0800

    drm/i915: add plane_config fetching infrastructure v2

Cc:  Jesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77511Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In my review of

commit 98f75de4
Author: Rob Clark <robdclark@gmail.com>
Date:   Fri May 30 11:37:03 2014 -0400

    drm: add object property typ

I asked for a check to make sure that we never leak an fb from the
generic mode object lookup since those have completely different
lifetime rules. Rob added it, but outside of the idr mutex, which
means that our dereference of obj->type can already chase free'd
memory.

Somehow I didn't spot this, so fix this asap.

v2: Simplify the conditionals as suggested by Chris.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In order to prevent external observers walking the list of open DRM
files from seeing an invalid drm_file_private in the process of being
torndown, the first operation we need to take is to unlink the
drm_file_private from that list.

	general protection fault: 0000 [#1] PREEMPT SMP
	Modules linked in: i915 i2c_algo_bit drm_kms_helper drm lpc_ich mfd_core nls_iso8859_1 i2c_hid video hid_generic usbhid hid e1000e ahci ptp libahci pps_core
	CPU: 3 PID: 8220 Comm: cat Not tainted 3.16.0-rc6+ #4
	Hardware name: Intel Corporation Shark Bay Client platform/WhiteTip Mountain 1, BIOS HSWLPTU1.86C.0119.R00.1303230105 03/23/2013
	task: ffff8800219642c0 ti: ffff880047024000 task.ti: ffff880047024000
	RIP: 0010:[<ffffffffa0137c70>]  [<ffffffffa0137c70>] per_file_stats+0x110/0x160 [i915]
	RSP: 0018:ffff880047027d48  EFLAGS: 00010246
	RAX: 6b6b6b6b6b6b6b6b RBX: ffff880047027e30 RCX: 0000000000000000
	RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88003a05cd00
	RBP: ffff880047027d58 R08: 0000000000000001 R09: 0000000000000000
	R10: ffff8800219642c0 R11: 0000000000000000 R12: ffff88003a05cd00
	R13: 0000000000000000 R14: ffff88003a05cd00 R15: ffff880047027d88
	FS:  00007f5f73a13740(0000) GS:ffff88014e380000(0000) knlGS:0000000000000000
	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 00000000023ff038 CR3: 0000000021a4b000 CR4: 00000000001407e0
	Stack:
	 0000000000000001 000000000000ffff ffff880047027dc8 ffffffff813438e4
	 ffff880047027e30 ffffffffa0137b60 ffff880021a8af58 ffff880021a8f1a0
	 ffff8800a2061fb0 ffff8800a2062048 ffff8800a2061fb0 ffff8800a1e23478
	Call Trace:
	 [<ffffffff813438e4>] idr_for_each+0xf4/0x180
	 [<ffffffffa0137b60>] ? i915_gem_stolen_list_info+0x1f0/0x1f0 [i915]
	 [<ffffffffa013a17a>] i915_gem_object_info+0x5ca/0x6a0 [i915]
	 [<ffffffff81193ec5>] seq_read+0xf5/0x3a0
	 [<ffffffff8116d950>] vfs_read+0x90/0x150
	 [<ffffffff8116e509>] SyS_read+0x49/0xb0
	 [<ffffffff815d8622>] tracesys+0xd0/0xd5
	Code: 01 00 00 49 39 84 24 08 01 00 00 74 55 49 8b 84 24 b8 00 00 00 48 01 43 18 31 c0 5b 41 5c 5d c3 0f 1f 00 49 8b 44 24 08 4c 89 e7 <48> 8b 70 28 48 81 c6 48 80 00 00 e8 80 14 01 00 84 c0 74 bc 49
	RIP  [<ffffffffa0137c70>] per_file_stats+0x110/0x160 [i915]
	RSP <ffff880047027d48>
Reported-by: N"Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81712Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added
deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free()
are currently doing GFP_KERNEL allocation.

But these functions did not get updated to receive gfp_t argument.
This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions,
and removes the deadlock warning.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL
allocation, ttm_pool_shrink_scan() does not do it. This can result in stack
overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to
memory pressure.

  shrink_slab()
  => ttm_pool_shrink_scan()
     => ttm_page_pool_free()
        => kmalloc(GFP_KERNEL)
           => shrink_slab()
              => ttm_pool_shrink_scan()
                 => ttm_page_pool_free()
                    => kmalloc(GFP_KERNEL)

Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

I can observe that RHEL7 environment stalls with 100% CPU usage when a
certain type of memory pressure is given. While the shrinker functions
are called by shrink_slab() before the OOM killer is triggered, the stall
lasts for many minutes.

One of reasons of this stall is that
ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and
are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with
_manager->lock held causes someone (including kswapd) to deadlock when
these functions are called due to memory pressure. This patch changes
"mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to
avoid deadlock.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

We can use "unsigned int" instead of "atomic_t" by updating start_pool
variable under _manager->lock. This patch will make it possible to avoid
skipping when choosing a pool to shrink in round-robin style, after next
patch changes mutex_lock(_manager->lock) to !mutex_trylock(_manager->lork).
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

list_empty(&_manager->pools) being false before taking _manager->lock
does not guarantee that _manager->npools != 0 after taking _manager->lock
because _manager->npools is updated under _manager->lock.
Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

HDMI_MUX_EN gpio is requested. If an error occurs, the same name
should be printed (HDMI_MUX_EN) instead of HDMI_MUX_SEL (typo).
Signed-off-by: NBeeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NRob Clark <robdclark@gmail.com>

lpm-mux is programmed to enable HDMI connector
on the docking station for S805 chipset based
devices.
Signed-off-by: NBeeresh Gopal <gbeeresh@codeaurora.org>
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

MDP5 has several functional blocks (ie: VIG/RGB pipes, LMs, ...).
From one revision to another, these blocks' base addresses might
change due to the number of instances present in the MDP5 hw.
A way of dealing with these offset changes is to introduce
dynamic offsets 'per block'.

This change adds support for the new revision of MDP5: v1.3.
The idea is to define one hw config per MDP version and select
either one of them at runtime, after reading the MDP5 version.

Once the MDP version is known, 'per block' dynamic offsets
are initialized through a global pointer, which is then used for
read/write register access.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Somewhere along the way, the firmware loader sprouted another lock
dependency, resulting in possible deadlock scenario:

 &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem

which is problematic vs things like gem mmap.

So introduce a separate mutex to synchronize gpu init.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Downstream kernel IOMMU had a non-standard way of dealing with multiple
devices and multiple ports/contexts.  We don't need that on upstream
kernel, so rip out the crazy.

Note that we have to move the pinning of the ringbuffer to after the
IOMMU is attached.  No idea how that managed to work properly on the
downstream kernel.

For now, I am leaving the IOMMU port name stuff in place, to simplify
things for folks trying to backport latest drm/msm to device kernels.
Once we no longer have to care about pre-DT kernels, we can drop this
and instead backport upstream IOMMU driver.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>

Downstream kernel holds this clk via a fake-parent relationship.
Upstream clock framework requires that we hold it explicitly.
Signed-off-by: NRob Clark <robdclark@gmail.com>

On downstream kernel the clk driver directly bangs hdmi phy registers.
For upstream kernel, we need to model this as a clock and register with
the clock framework.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>

Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
add necessary DT support so that we can use drm/msm on upstream kernel.

v2: update for review comments
v3: rebase on component helper changes
Signed-off-by: NRob Clark <robdclark@gmail.com>

This change implements msm drm specific fb_mmap function for fb device
to properly map the fb address to userspace.
Signed-off-by: NHai Li <hali@codeaurora.org>
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com> (+ minor comment tweak)

This changes activates the iommu support for MDP5, through the
platform config structure.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Mutex is already grabbed in show_locked().. somehow this slipped
through.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Daniel pointed out with hotplug that userspace could be trying to oops us
as root for lols, and that to be correct we shouldn't register the object
with the idr before we have fully set the connector object up.

His proposed solution was a lot more life changing, this seemed like a simpler
proposition to me, get the connector object id from the idr, but don't
register the object until the drm_connector_register callback.

The open question is whether the drm_mode_object_register needs a bigger lock
than just the idr one, but I can't see why it would, but I can be locking
challenged.

v2: fix bool noreg into sane - add comment.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On HSW+, the digital encoders are shared between HDMI and DP outputs,
with one encoder masquerading as both. The VBT should tell us if we need
to have DP or HDMI support on a particular port, but if we don't have DP
support and we enable the DP hpd pulse handler then we cause an oops.

Don't hook up the DP hpd handling if we don't have a DP port.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81856
Reported-by: Intel QA Team.
Signed-off-by: Dave Airlie <airlied@redhat.com> # v1
[ickle: Fix the error handling after a malloc failure]
Reviewed-by: NDave Airlie <airlied@redhat.com>
Cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Currently the DRM_IOCTL_EXYNOS_G2D_GET_VER ioctl always succeeds, even
if no G2D support is available. Let the ioctl fail when this is the
case, so that userspace can accurately probe for G2D support.

This also fixes the exynos tests in libdrm. There 'g2d_init' doesn't
fail when G2D is absent, leading to a segfault later.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NINki Dae <inki.dae@samsung.com>

Both exynos_g2d_set_cmdlist_ioctl and exynos_g2d_exec_ioctl don't check
if the G2D was succesfully probe. If that is not the case, then g2d_priv
is just NULL and extracting 'dev' from it in the next step  is going to
produce a kernel oops.

Add proper checks and return ENODEV if the G2D is not available.
Signed-off-by: NTobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: NINki Dae <inki.dae@samsung.com>

The hdmiphy can be apb and hdmiphy_port can be null. So before
accessing hdmiphy_port, it should be checked.
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The mixer graphic layer 0 isn't blended as default by commit
0377f4ed(drm/exynos: Don't blend mixer
layer 0). But it needs to be blended with graphic layer 0 if video layer
is enabled by vp because video layer is bottom.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Add MODULE_DEVICE_TABLE calls for the various OF match tables that
currently don't have one. This allows the module to be
autoloaded based on devicetree information.
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This reverts commit d0896218 was
original to prevent multiple MODULE_DEVICE_TABLE in one module.
Which, as a side-effect broke autoloading of the module.

Since 21bdd17b it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so the patch can be
reverted to restore support for autoloading
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Since 21bdd17b it is possible to have
multiple calls to MODULE_DEVICE_TABLE, so the patch can be
reverted to restore support for autoloading

Conflicts:
	drivers/gpu/drm/exynos/exynos_drm_fimd.c
	drivers/gpu/drm/exynos/exynos_drm_g2d.c
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The patch puts repeated code sequence into one function, removes verbose
comments and decreases log verbosity.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

There is no gain in passing id by pointer to be filled.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

In case of error callback prints already corresponding message.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The patch simplifies ipp_find_obj and removes debug messages.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Argument checks are redundant, clients always check ippdrv before calling
these functions.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The only thing function should check is if there are buffers in respective
queues.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

list_first_entry does not return NULL on empty list so this check
does not make sense. Moreover there is already code which prevents calling
list_first_entry on empty lists.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>