Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,
the userptr becomes invalid and this raises a WARN when the clients
tries to unmap its address space. The situation can be even more
complicated when the buffer is passed between processes, between a
client and display server, where the lifetime and hardware access is
even more confusing. Deny it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Apparently writing the DPLL register P1/P2 divider fields won't trigger
an actual change in the DPLL output unless VGA mode is enabled for
prior to the register write that changes the P1/P2 dividers. The write
with the new P1/P2 divider can itself disable VGA mode again without
problems.

I tested the behaviour on my 946GZ, and when manually frobbing the
register with the display on, the behaviour is very clear. However I
can't explain why this machine actually works. The P1/P2 divider
changes caused by normal modesets do seem to make it through to the
hardware somehow since I get a stable picture on the monitor with
any resolution. Maybe it's the "three times for luck" stuff that
somehow masks the problem, or something.

But apparently there are machines (eg. Nick Bowler's G45) where that
isn't the case and we fail to get the correct clock from the DPLL.

Things used to work because we enabled VGA mode for disabled DPLLs,
so when re-enabling the DPLL VGA mode was enabled just prior to the
first register write, and hence the P1/P2 change went through without
a hitch. That got changed in

b8afb911 drm/i915: Keep GMCH DPLL VGA mode always disabled

in the name of consistency. In order to keep the consistency part,
leave VGA mode disabled for disabled DPLLs, but turn it on just prior
to updating the P1/P2 dividers to make sure the hardware picks up
on the new values.

Cc: Nick Bowler <nbowler@draconx.ca>
Reported-by: NNick Bowler <nbowler@draconx.ca>
Tested-by: NNick Bowler <nbowler@draconx.ca>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We accidentally lost the initial DPLL register write in
1c4e0274 drm/i915: Fix DVO 2x clock enable on 830M

The "three times for luck" hack probably saved us from a total
disaster. But anyway, bring the initial write back so that the
code actually makes some sense.
Reported-and-tested-by: NNick Bowler <nbowler@draconx.ca>
References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
Cc: stable@vger.kernel.org
Cc: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

In order to flush the results from in-batch pipecontrol writes (used for
example in glQuery) before declaring the batch complete (and so declaring
the query results coherent), we need to set the FlushEnable bit in our
flushing pipecontrol. The FlushEnable bit "waits until all previous
writes of immediate data from post-sync circles are complete before
executing the next command".

I get GPU hangs on byt without flushing these writes (running ue4).
piglit has examples where the flush is required for correct rendering.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

I've botched this in

commit eb0b44ad
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 18 14:47:59 2015 +0100

    drm/i915: kerneldoc for i915_gem_shrinker.c

so let's fix it.
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This just removes the magic number.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since 9eb1e57f
drm/dp/mst: make sure mst_primary mstb is valid in work function

we validate the mstb structs in the work function, and doing
that takes a reference. So we should never get here with the
work function running using the mstb device, only if the work
function hasn't run yet or is running for another mstb.

So we don't need to sync the work here, this was causing
lockdep spew as below.

[  +0.000160] =============================================
[  +0.000001] [ INFO: possible recursive locking detected ]
[  +0.000002] 3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1 Tainted: G        W      ------------
[  +0.000001] ---------------------------------------------
[  +0.000001] kworker/4:2/1262 is trying to acquire lock:
[  +0.000001]  ((&mgr->work)){+.+.+.}, at: [<ffffffff810b29a5>] flush_work+0x5/0x2e0
[  +0.000007]
but task is already holding lock:
[  +0.000001]  ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
[  +0.000004]
other info that might help us debug this:
[  +0.000001]  Possible unsafe locking scenario:

[  +0.000002]        CPU0
[  +0.000000]        ----
[  +0.000001]   lock((&mgr->work));
[  +0.000002]   lock((&mgr->work));
[  +0.000001]
 *** DEADLOCK ***

[  +0.000001]  May be due to missing lock nesting notation

[  +0.000002] 2 locks held by kworker/4:2/1262:
[  +0.000001]  #0:  (events_long){.+.+.+}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
[  +0.000004]  #1:  ((&mgr->work)){+.+.+.}, at: [<ffffffff810b57e4>] process_one_work+0x1b4/0x710
[  +0.000003]
stack backtrace:
[  +0.000003] CPU: 4 PID: 1262 Comm: kworker/4:2 Tainted: G        W      ------------   3.10.0-320.el7.rhel72.stable.backport.3.x86_64.debug #1
[  +0.000001] Hardware name: LENOVO 20EGS0R600/20EGS0R600, BIOS GNET71WW (2.19 ) 02/05/2015
[  +0.000008] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper]
[  +0.000001]  ffffffff82c26c90 00000000a527b914 ffff88046399bae8 ffffffff816fe04d
[  +0.000004]  ffff88046399bb58 ffffffff8110f47f ffff880461438000 0001009b840fc003
[  +0.000002]  ffff880461438a98 0000000000000000 0000000804dc26e1 ffffffff824a2c00
[  +0.000003] Call Trace:
[  +0.000004]  [<ffffffff816fe04d>] dump_stack+0x19/0x1b
[  +0.000004]  [<ffffffff8110f47f>] __lock_acquire+0x115f/0x1250
[  +0.000002]  [<ffffffff8110fd49>] lock_acquire+0x99/0x1e0
[  +0.000002]  [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0
[  +0.000002]  [<ffffffff810b29ee>] flush_work+0x4e/0x2e0
[  +0.000002]  [<ffffffff810b29a5>] ? flush_work+0x5/0x2e0
[  +0.000004]  [<ffffffff81025905>] ? native_sched_clock+0x35/0x80
[  +0.000002]  [<ffffffff81025959>] ? sched_clock+0x9/0x10
[  +0.000002]  [<ffffffff810da1f5>] ? local_clock+0x25/0x30
[  +0.000002]  [<ffffffff8110dca9>] ? mark_held_locks+0xb9/0x140
[  +0.000003]  [<ffffffff810b4ed5>] ? __cancel_work_timer+0x95/0x160
[  +0.000002]  [<ffffffff810b4ee8>] __cancel_work_timer+0xa8/0x160
[  +0.000002]  [<ffffffff810b4fb0>] cancel_work_sync+0x10/0x20
[  +0.000007]  [<ffffffffa0160d17>] drm_dp_destroy_mst_branch_device+0x27/0x120 [drm_kms_helper]
[  +0.000006]  [<ffffffffa0163968>] drm_dp_mst_link_probe_work+0x78/0xa0 [drm_kms_helper]
[  +0.000002]  [<ffffffff810b5850>] process_one_work+0x220/0x710
[  +0.000002]  [<ffffffff810b57e4>] ? process_one_work+0x1b4/0x710
[  +0.000005]  [<ffffffff810b5e5b>] worker_thread+0x11b/0x3a0
[  +0.000003]  [<ffffffff810b5d40>] ? process_one_work+0x710/0x710
[  +0.000002]  [<ffffffff810beced>] kthread+0xed/0x100
[  +0.000003]  [<ffffffff810bec00>] ? insert_kthread_work+0x80/0x80
[  +0.000003]  [<ffffffff817121d8>] ret_from_fork+0x58/0x90

v2: add flush_work.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

In order to cache the EDID properly for tiled displays, we
need to retrieve it before we register the connector with
userspace, otherwise userspace can call get resources
and try and get the edid before we've even cached it.

This fixes some problems when hotplugging mst monitors,
with X/mutter running. As mutter seems to get 0 modes
for one of the monitors in the tile.

v2: fix warning in radeon
handle tile setting in cached path rather than
get edid path.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Update the state before sending the msg to close it.

v2: reset value if return indicates we haven't send the msg.
v3: just clean the code up.
Pointed out by Adam J Richter on

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91481Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

output ports should always have a connector, unless
in the rare case connector allocation fails in the
driver.

In this case we only need to teardown the pdt,
and free the struct, and there is no need to
send a hotplug msg.

In the case were we add the port to the destroy
list we need to send a hotplug if we destroy
any connectors, so userspace knows to reprobe
stuff.

this patch also handles port->connector allocation
failing which should be a rare event, but makes
the code consistent.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is unnecessary and it makes it easier to see what is needed
from port.

also add blank line to make things nicer.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It was just a wrapper around drm_fb_helper_set_par that
called cursor_set2 in addition.  Now that the core handles
this, drop this radeon specific version.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If a driver uses the cursor_set2 crtc callback rather than
cursor_set, use that.  This fixes the fbdev helper for drivers
that use cursor_set2.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The exynos_drm_gem_mmap_buffer() is not used outside so make it static.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

fimd_dp_clock_enable() was setting the always to enabled,
this patch fix this to actually use the value that is set to 'val'.
Reported-by: NEmilio López <emilio.lopez@collabora.co.uk>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This patch removes unnecessary pm suspend/resume functions.

All kms sub drivers will be controlled by top of Exynos drm driver
and connector dpms so these sub drivers shouldn't have their own
pm interfaces.
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>

When disabling/enabling a crtc the primary area must be updated
independently of which crtc has been disabled/enabled.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1264735Signed-off-by: NFabiano Fidêncio <fidencio@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Port of radeon commit 9b7d786b.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

It was added for completeness, but we don't have any users
for it yet.  Daniel noted that it may be racy. Remove it.

Change-Id: I5f5546f8911a4f294008a62dc86a73f3face38d1
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

drm_kms_helper_poll_enable() is called from a context in
intel_hpd_irq_storm_disable() where the the mode_config mutex is
already locked.
When this function was converted to lock this mutex in
commit 8c4ccc4a ("drm/probe-helper: Grab mode_config.mutex
in poll_init/enable") a deadlock occurred.
Call the newly implemented non-locking version of this function.

Changes since v1:
- use function name suffix '_locked' for the function that
  is to be called from a locked context.
Signed-off-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

drm_kms_helper_poll_enable() was converted to lock the mode_config
mutex in commit 8c4ccc4a
("drm/probe-helper: Grab mode_config.mutex in poll_init/enable").

This disregarded the cases where this function is called from a context
where this mutex is already locked.

Add a non-locking version as well.

Changes since v1:
- use function name suffix '_locked' for the function that
  is to be called from a locked context.
Signed-off-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When we're out of command buffer space, we turn on the command buffer
processed irq without re-checking for finished command buffers afterwards.
This might lead to a missed irq and the command submission process waiting
forever for space.

Fix this by rerunning the command buffer submission handler whenever we're
out of command space. This ensures both that we don't needlessly turn on
the irq, and that if we decide to turn on the irq, we recheck for finished
command buffers before going to sleep.
Reported-and-tested-by: NBryan Li <ldexin@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

CRTC's mode_fixup() isn't used anymore in exynos, remove it.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The only thing mode_fixup was doing was set the adjusted_mode->vrefresh to
60, but it already has the value of 60 when the decon_mode_fixup() is
called. That means this call is actually pointless and can be removed.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The only thing mode_fixup was doing was set the adjusted_mode->vrefresh to
60, but it already has the value of 60 when the fimd_mode_fixup() is
called. That means this call is actually pointless and can be removed.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Protect the rotator_clk_crtl() function with an #ifdef CONFIG_PM guard
to avoid "defined but not used" warnings.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Protect the fimc_clk_ctrl() function with an #ifdef CONFIG_PM guard to
avoid "defined but not used" warnings.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Protect the suspend and resume callbacks with an #ifdef CONFIG_PM_SLEEP
guard to avoid "defined but not used" warnings.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
not, it will call drm_gem_create_mmap_offset whenever user requests
DRM_IOCTL_MODE_MAP_DUMB ioctl.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The drm_gem_object_release() function already performs this cleanup,
so there is no reason to do it explicitly.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

All the user of these functions are inside exynos-drm driver and
you don't need to export the symbols for that case.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The beginning of statement in function is next line of a brace.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

By if statment, some function callings are written twice. It needs
several line feed by indentation in if statment. Make to one function
calling from outside if statment.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The exynos_drm_gem_init() is used only in exynos_drm_gem.c file. Make it
static and don't export it.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

They will be freed right or was freed already, so NULL assignment is
unnecessary.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

When obj->import_attach is existed, code calling drm_prime_gem_destroy()
was removed from commit 67e93c80 ("drm/exynos: stop copying sg
table"), and it's a fault.

The drm_prime_gem_destroy() is cleanup function which GEM drivers need
to call when they use drm_gem_prime_import() to import dma-bufs, so
exynos-drm driver using drm_gem_prime_import() needs calling
drm_prime_gem_destroy().
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

There is no guarantee that DMA addresses are the same as physical
addresses, but dma_to_pfn() knows how to convert a dma_addr_t to a PFN
which can then be converted to a struct page.
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Instead of only enabling the backlight (which seems to set it to max
brightness), just re-set the current backlight level, which also takes
care of enabling the backlight if necessary.

Port of radeon commit:
drm/radeon: Restore LCD backlight level on resume (>= R5xx)
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Instead of only enabling the backlight (which seems to set it to max
brightness), just re-set the current backlight level, which also takes
care of enabling the backlight if necessary.

Only the radeon_atom_encoder_dpms_dig part tested on a Kaveri laptop,
the radeon_atom_encoder_dpms_avivo part is only compile tested.

Cc: stable@vger.kernel.org
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The "i" variable should be signed or it leads to a crash in the error
handling code.

Fixes: 1d263474 ('drm/amdgpu: unwind properly in amdgpu_cs_parser_init()')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>