Atm, it's possible that the interrupt handler is called when the device
is in D3 or some other low-power state. It can be due to another device
that is still in D0 state and shares the interrupt line with i915, or on
some platforms there could be spurious interrupts even without sharing
the interrupt line. The latter case was reported by Klaus Ethgen using a
Lenovo x61p machine (gen 4). He noticed this issue via a system
suspend/resume hang and bisected it to the following commit:

commit e11aa362
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Jun 18 09:52:55 2014 -0700

    drm/i915: use runtime irq suspend/resume in freeze/thaw

This is a problem, since in low-power states IIR will always read
0xffffffff resulting in an endless IRQ servicing loop.

Fix this by handling interrupts only when the driver explicitly enables
them and so it's guaranteed that the interrupt registers return a valid
value.

Note that this issue existed even before the above commit, since during
runtime suspend/resume we never unregistered the handler.

v2:
- clarify the purpose of smp_mb() vs. synchronize_irq() in the
  code comment (Chris)

v3:
- no need for an explicit smp_mb(), we can assume that synchronize_irq()
  and the mmio read/writes in the install hooks provide for this (Daniel)
- remove code comment as the remaining synchronize_irq() is self
  explanatory (Daniel)

v4:
- drm_irq_uninstall() implies synchronize_irq(), so no need to call it
  explicitly (Daniel)

Reference: https://lkml.org/lkml/2015/2/11/205Reported-and-bisected-by: NKlaus Ethgen <Klaus@Ethgen.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When we walk the list of vma, or even for protecting against concurrent
framebuffer creation, we must hold the struct_mutex or else a second
thread can corrupt the list as we walk it.

Fixes regression from
commit d7f46fc4
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Fri Dec 6 14:10:55 2013 -0800

    drm/i915: Make pin count per VMA

References: https://bugs.freedesktop.org/show_bug.cgi?id=89085Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When converting from implicitly tracked execlist queue items to ref counted
requests, not all frees of requests were replaced with unrefs, and extraneous
refs/unrefs of contexts were added.
Correct the unbalanced refcount & replace the frees.
Remove a noisy warning when hitting the request creation path.

drm_i915_gem_request and intel_context are both kref reference counted
structures. Upon allocation, drm_i915_gem_request's ref count should be
bumped using kref_init. When a context is assigned to the request,
the context's reference count should be bumped using i915_gem_context_reference.
i915_gem_request_reference will reduce the context reference count when
the request is freed.

Problem introduced in
commit 6d3d8274
Author:     Nick Hoath <nicholas.hoath@intel.com>
AuthorDate: Thu Jan 15 13:10:39 2015 +0000

     drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request

v2: Added comments explaining how the ctx pointer and the request object should
be ref-counted. Removed noisy warning.

v3: Cleaned up the language used in the commit & the header
description (Thanks David Gordon)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652Signed-off-by: NNick Hoath <nicholas.hoath@intel.com>
Reviewed-by: NThomas Daniel <thomas.daniel@intel.com>
Reviewed-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Add quirk for Dell Chromebook 11 backlight.
Reported-and-tested-by: NOwen Garland <garland.owen@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93451Acked-by: NDamien Lespiau <damien.lespiau@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

skylake_update_primary_plane() did not handle all pixel formats returned
by skl_format_to_fourcc(). Handle alpha similar to skl_update_plane().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89052Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When reviewing patch that fixes VGA on BDW Halo Jani noticed that
we also had other ULT IDs that weren't listed there.

So this follow-up patch add these pci-ids as halo and fix comments
on i915_pciids.h

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Missing parameter when fetching the real voltage values
from atom.  Fixes problems with dynamic clocking on
certain boards.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=87457Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Don't restrict it to just eDP panels.  Some LVDS bridge chips require
this.  Fixes blank panels on resume on certain laptops.  Noticed
by mrnuke on IRC.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=42960Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Enable at init and disable on fini. Workaround for hardware problems.

v2 (chk): extend commit message
v3: add new function
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com> (v2)
Cc: stable@vger.kernel.org

Emit the EOP twice to avoid cache flushing problems.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Doing so can cause things to become slow.

Print a warning at compile time and an informative message at runtime in
that case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88758
Cc: stable@vger.kernel.org
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

0-255 seems to be the preferred range for the pwm interface.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The efficient frequency (RPe) should stay in the range
RPn <= RPe <= RP0.  The pcode clamps the returned value
internally on Broadwell but not on Haswell.

Fix for missing range check in
commit 93ee2920
Author: Tom O'Rourke <Tom.O'Rourke@intel.com>
Date:   Wed Nov 19 14:21:52 2014 -0800

    drm/i915: Use efficient frequency for HSW/BDW

Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/059802.htmlReported-by: NMichael Auchter <a@phire.org>
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org # v3.19
Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Return IRQ_HANDLED from intel_dp_hpd_pulse() to properly
ignore the long HPD pulse on eDP to avoid the never ending
VDD off->HPD->VDD on->VDD off->HPD... cycle.

This fixes a regression intoduced by
 commit b2c5c181
 Author: Daniel Vetter <daniel.vetter@ffwll.ch>
 Date:   Fri Jan 23 06:00:31 2015 +0100

    drm/i915: Use symbolic irqreturn for ->hpd_pulse

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This patch is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git

DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.

DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)

The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.

The current version of the driver supports video mode displays.

Changelog v2:
- Change config name, DRM_EXYNOS_DECON to DRM_EXYNOS7_DECON.
Signed-off-by: NAkshu Agrawal <akshua@gmail.com>
Signed-off-by: NAjay Kumar <ajaykumar.rs@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

One bit in ->vm_flags is unused now!
Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

LP_OUTPUT_HOLD is only in MIPI_PORT_CTRL(PORT_A) even for PORT_C in case
of dual link. In the dual link implementation, the bit is correctly set
or unset for hardcoded PORT_A, but for bit update the register base value
is read by using MIPI_PORT_CTRL(port) in a loop. The second iteration will
read base value from PORT_C and program for PORT_A. Mostly in case of dual
link all other bit values should be same, but logically we should read from
PORT_A. So hardcode to read initial value from PORT_A as well.
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

This looked like an odd regression from

commit ec5cc0f9
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Jun 12 10:28:55 2014 +0100

    drm/i915: Restrict GPU boost to the RCS engine

but in reality it undercovered a much older coherency bug. The issue that
boosting the GPU frequency on the BCS ring was masking was that we could
wake the CPU up after completion of a BCS batch and inspect memory prior
to the write cache being fully evicted. In order to serialise the
breadcrumb interrupt (and so ensure that the CPU's view of memory is
coherent) we need to perform a post-sync operation in the MI_FLUSH_DW.

v2: Fix all the MI_FLUSH_DW (bsd plus the duplication in execlists).

Also fix the invalidate_domains mask in gen8_emit_flush() for ring !=
VCS.

Testcase: gpuX-rcs-gpu-read-after-write
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Acked-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Nothing in Bspec seems to indicate that we actually needs this, and it
looks like can't work since by this point the pipe is off and so
vblanks won't really happen any more.

Note that Bspec mentions that it takes a vblank for this bit to
change, but _only_ when enabling.

Dropping this code quenches an annoying backtrace introduced by the
more anal checking since

commit 51e31d49
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Sep 15 12:36:02 2014 +0200

    drm/i915: Use generic vblank wait

Note: This fixes the fallout from the above commit, but does not address
the shortcomings of the IBX transcoder select workaround implementation
discussed during review [1].

[1] http://mid.gmane.org/87y4o7usxf.fsf@intel.com

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86095Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org # 3.19
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

There is a case called disable_plane callback function even if
plane->crtc is NULL from exynos_drm_encoder_disable and it will cause
NULL pointer reference error.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The exynos_plane_dpms function handles enabled flag of exynos plane and
calls internal hw driver callback function for hw overlay on/off. But
it causes state disharmory problem currently and is will be obstacle to
apply atomic operation later to keep non-standard per-plane dpms state
like enabled flag.

Let's remove enabled flag, it just stop to recall internal callback
function but hw drivers can handle it properly. And call internal
callback function directly then we can remove unnecessary
exynos_plane_dpms function
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

This was added by commit 3b8d1cf8 ("drm/exynos: add property for
crtc mode"). Currently we can control a plane used for crtc using
primary plane by universal plane feature. Stop to use non-standard
property to control primary plane.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

exynos_plane_dpms(DRM_MODE_DPMS_ON) calls the win_enable()'s callback
from the underlying layer. However neither one of these layers implement
win_enable() - FIMD, Mixer and VIDI. Thus the call to exynos_plane_dpms()
is pointless.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

We added this WARN_ON to guard against using uninitialized
forcewake domains. But forgot blissfully that not all
gens have forcewake domains in the first place.

v2: Move WARN_ON to fw_domains_init (Chris)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88911
Tested-by: Ding Heng <hengx.ding@intel.com> (v1)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[Jani: add comment above WARN_ON as suggested by Chris]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We read the coherent current seqno and actual head from ring.
For hardware access we need to take runtime_pm reference.

Get hardware specific values with runtime reference held
and print them first to emphasize hw state vs bookkeepping.

v2: Reorder output according to hw access (Chris)
    remove superfluous locking (Daniel)

Testcase: igt/pm_rpm/debugfs-read
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88910
Tested-by: Ding Heng <hengx.ding@intel.com> (v1)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target
device and not the source. So PCI_DEVFN(2,0) is not correct. Further the
port ID should be enough to identify devices unless they are MFD. The
SB_DevFn was intended to remove ambiguity in case of these MFD devices.

For non MFD devices the recommendation for the target device IP was to
ignore these fields, but not all of them followed the recommendation.
Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so
does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because
of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0).
It turned out that this did not follow the recommendation and expected 0
in this field.

In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for
all devices except target PCI devices.
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The Exynos DRM driver doesn't follow the correct API when dealing with
dma_{alloc, mmap, free}_attrs functions and the
DMA_ATTR_NO_KERNEL_MAPPING attribute.

When a IOMMU is not available and the DMA_ATTR_NO_KERNEL_MAPPING is
used, the driver should use the pointer returned by dma_alloc_attr() as
a cookie.

The Exynos DRM driver directly uses the non-requested virtual kernel
address returned by the DMA mapping subsystem. This just works now
because the non-IOMMU codepath doesn't obey DMA_ATTR_NO_KERNEL_MAPPING
but we need to fix it before fixing the DMA layer.
Signed-off-by: NCarlo Caione <carlo@caione.org>
Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

For default graphic window, mixer_win_commit() sets display size
register as fb size. Calling setplane with smaller fb size than
mode size to default window causes distorted display result. So
this patch replaces fb size with mode size for display size from
the mixer_win_commit().
Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com>
Acked-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The hdmi outputs black screen only even though under the hood Xorg and
framebuffer console  are fine : devices found and initialized, but
not a pixel out.

Commit 93bca243 ("drm/exynos: remove struct exynos_drm_manager")
changed the call order of mixer_initialize with regards to
 exynos_drm_crtc_create.

This changes breaks hdmi out on Odroid U2 (linux-next with added
 Marek Szyprowski v4 hdmi patchset from linux-samsung-soc ML).

Restore the previous call ordering get hdmi to ouput proper pixels:
ie call mixer_initialize first then exynos_drm_crtc_create.

Fixes: 93bca243 ("drm/exynos: remove struct exynos_drm_manager")
Signed-off-by: NAlban Browaeys <prahal@yahoo.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Use driver internal struct as argument instead of struct exynos_drm_crtc
except functions of exynos_drm_crtc_ops and instead of struct
exynos_drm_display except functions of exynos_drm_display_ops.

It can reduce unnecessary variable declaration.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

We get wrong pipe value for crtc since commit 93bca243 ("drm/exynos:
remove struct exynos_drm_manager"). We should should increase pipe value
before call exynos_drm_crtc_create.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The exynos_drm_dmabuf.c file doesn't include any module feature and it
isn't built to module.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

The exynos drm driver has DRIVER_PRIME capability, then it's reasonable
to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will
prevent that user selects the option unnecessarily.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

If system provides IOMMU feature, Exynos DRM should use it by default,
because the Exynos DRM subdrivers don't work correctly when Exynos IOMMU
driver has been enabled and no IOMMU support has been compiled into Exynos
DRM driver.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Mixed need to have hdmi clock enabled to properly perform power on/off
sequences, so add handling of this clock directly to the mixer driver.
Dependency between hdmi clock and mixer module has been observed on
Exynos4 based boards.
Suggested-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Add a default audio infoframe for HDMI compliance
Signed-off-by: NArnaud Pouliquen <arnaud.pouliquen@st.com>

It's possible for invalidate_range_start mmu notifier callback to race
against userptr object release. If the gem object was released prior to
obtaining the spinlock in invalidate_range_start we're hitting null
pointer dereference.

Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close
Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[Jani: added code comment suggested by Chris]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Use GDP capabilities to support DRM_FORMAT_XBGR8888 (XB24)
Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>

The commit [8975626e: drm/cirrus: allow 32bpp framebuffers for
cirrus drm] broke X modesetting driver because cirrus driver still
provides the full list of modes up to 1280x1024 while the 32bpp can
support only up to 800x600.

We might be able to filter out the invalid modes in mode_valid
callback, but unfortunately the bpp in question can't be referred
there for now (let me know if there is a better way to retrieve the
bpp for the probed fb).

So, instead, this patch adds the bpp module option to specify the
maximal bpp explicitly and limits the resolutions in get_modes
depending on its value.

The default value is set to 24 so that the existing stuff keeps
working.  If you need a new 32bpp feature, specify cirrus.bpp=32
option explicitly.

Fixes: 8975626e ('drm/cirrus: allow 32bpp framebuffers for cirrus drm')
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Use GDP capabilities to support DRM_FORMAT_ABGR8888 (AB24)
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>