This reverts commit 355a7018.

This had some bad side effects under normal operation, and should
have been dropped earlier.
Signed-off-by: NDave Airlie <airlied@redhat.com>

nouveau userspace back at 1.0.1 used to call the X server
DRIOpenDRMMaster interface even for DRI2 (doh!), this attempts
to map the sarea and fails if it can't.

Since 884c6dab from Daniel,
this fails, but only ancient drivers would see it.

Revert the nouveau bits of that fix.
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org>  # 3.18
Signed-off-by: NDave Airlie <airlied@redhat.com>

Disable the HPD interrupt when acking it, to avoid spurious
interrupt.
Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>

HPD regulators need to be enabled before clocks, otherwise clock
driver will report warning.
Signed-off-by: NJilai Wang <jilaiw@codeaurora.org>

If crtc <-> encoder linkage changes, we could end up with the CRTC
listening for the wrong error or vsync irqs.  Generally this problem
would correct itself relatively quickly, since we update the global
irqmask after dispatching irqs, but to be sure let the CRTC trigger
update_irq().
Signed-off-by: NRob Clark <robdclark@gmail.com>

We can't have multiple updates pending on a given CRTC, and we don't
want a sync update to race w/ an async update that preceeded it.  So
keep track of which CRTCs have updates in flight, and block later
updates that would conflict.
Signed-off-by: NRob Clark <robdclark@gmail.com>

When a plane is being enabled, plane->crtc has not been set yet.  Use
plane->state->crtc.
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The release_firmware() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The functions framebuffer_release() and vunmap() perform also input
parameter validation. Thus the test around the call is not needed.

This issue was detected by using the Coccinelle software.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In finish pageflip, the driver was not selecting the root window when
dispatching events. This exposed a race where a plane update would
change the window selection and cause tegra_dc_finish_page_flip to check
the wrong base address.

This patch also protects access to the window selection register as well
as the registers affected by it.
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>

If the requested buffer size wasn't a multiple of the page size, the
IOMMU code would round down the size to the next multiple of the page
size, thereby causing translation errors. To fix this we no longer pass
around the requested size but reuse the computed size of the GEM object.
This is already rounded to the next page boundary, so mapping that size
works out fine.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Buffers obtained via shmem may still have associated cachelines. If they
aren't properly flushed they may cause framebuffer corruption if the
cache gets flushed after the application has drawn to it.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Page-flip completion could race with page-flip submission, so extend the
critical section to include all accesses to page-flip related data.
Reported-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The hardware pipe numbers don't always match the DRM CRTC indices. This
can happen for example if the first display controller defers probe,
causing it to be registered with DRM after the second display
controller. When that happens the hardware pipe numbers and DRM CRTC
indices become different. Make sure that the CRTC index is always used
when accessing per-CRTC VBLANK data. This can be ensured by using the
drm_crtc_vblank_*() API, which will do the right thing automatically
given a struct drm_crtc *.
Signed-off-by: NThierry Reding <treding@nvidia.com>

This function is the KMS native variant of drm_vblank_count(). It takes
a struct drm_crtc * instead of a struct drm_device * and an index of the
CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This function is the KMS native variant of drm_handle_vblank(). It takes
a struct drm_crtc * instead of a struct drm_device * and an index of the
CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

This function is the KMS native variant of drm_send_vblank_event(). It
takes a struct drm_crtc * instead of a struct drm_device * and an index
of the CRTC.

Eventually the goal is to access vblank data through the CRTC only so
that the per-CRTC data can be moved to struct drm_crtc.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NThierry Reding <treding@nvidia.com>

There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang.  Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.

Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.

v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NPeter Frühberger <fritsch@xbmc.org>
Reviewed-by: NDaniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

In order to act as a full command barrier by itself, we need to tell the
pipecontrol to actually stall the command streamer while the flush runs.
We require the full command barrier before operations like
MI_SET_CONTEXT, which currently rely on a prior invalidate flush.

References: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

In the gen7 pipe control there is an extra bit to flush the media
caches, so let's set it during cache invalidation flushes.

v2: Rename to MEDIA_STATE_CLEAR to be more inline with spec.

Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-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>

Atm, we don't disable RPS interrupts and related work items before
resetting the GPU. This may interfere with the following GPU
initialization and cause RPS interrupts to show up in PM_IIR too early
before calling gen6_enable_rps_interrupts() (triggering a WARN there).

Solve this by disabling RPS interrupts and flushing any related work
items before resetting the GPU.

v2:
- split out the common parts of the gt suspend and the new gt reset
  functions (Paulo)
v3:
- remove the check for UMS, it's a NOP nowadays (Daniel)
Reported-by: NHe, Shuang <shuang.he@intel.com>
Testcase: igt/gem_reset_stats/ban-render
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86644Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Paulo noticed that we don't enable RPS interrupts via PM_IER in
gen6_enable_rps_interrupts(). This wasn't a problem so far, since the
only place we disabled RPS interrupts was during system/runtime suspend
and after that we reenable all interrupts in the IRQ pre/postinstall
hooks.

In the next patch we'll disable/reenable RPS interrupts during GPU reset
too, but not call IRQ uninstall, pre/postinstall hooks, so there the
above wouldn't work. The logical place for programming PM_IER is
gen6_enable_rps_interrupts() and this also makes the function more
symmetric with gen6_disable_rps_interrupts(), so move the programming
there from the postinstall hooks.

Note that these changes don't affect the ILK RPS interrupt code, which
could be sanitized in a similar way. But that can be done as a
follow-up.

Credits-to: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When compiling in module some symbol aren't missing,
export them correctly.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

irq_mask should include all IRQ bits that we want to mask, but atm we
set it incorrectly to the inverse of this. If the mask is used
subsequently to enable/disable some IRQ bits, we may unintentionally
unmask unrelated IRQs. I can't see any way that this can lead to a real
problem in the current -nightly code, since the first place the mask
will be used next (after a suspend/resume cycle) is in
valleyview_irq_postinstall(), but the mask is reset there to its proper
value.

This causes a problem in the upstream kernel though, where - due to another
issue - the mask is used in the above way to disable only the display IRQs.
This other issue is fixed by:

commit 950eabaf
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Sep 8 15:21:09 2014 +0300

    drm/i915: vlv: fix display IRQ enable/disable

Interestingly, even with the above two bugs, we shouldn't in theory have
any real problems (arguably a famous last sentence:). That's because
even if we unmask something unintentionally via the VLV_IMR/VLV_IER
register the master IRQ masking bit in VLV_MASTER_IER is still set and
should prevent all i915 interrupts. According to my testing on an ASUS
T100 with DSI output this isn't the case at least with the
MIPIA_INTERRUPT. Leaving this one unmasked in IMR/IER, while having
VLV_MASTER_IER set to 0 may lead to a lockup during system suspend as
shown in the bugzilla ticket below. This fix should get rid of the
problem reported there in upstream and older kernels.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85920
Cc: stable@vger.kernel.org (v3.15+)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Should probably just init this in the GMbus code all the time, based on
the cdclk and HPLL like we do on newer platforms.  Ville has code for
that in a rework branch, but until then we can fix this bug fairly
easily.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76301Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NNikolay <mar.kolya@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When bind failed make sure that CRTC and planes are
completely clean up to avoid properties duplication.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

High Quality Video Data Plane is hardware IP dedicated
to video rendering. Compare to GPD (graphic planes) it
have better scaler capabilities.

HQVDP use VID layer to push data into hardware compositor
without going into DDR. From data flow point of view HQVDP
and VID are nested so HQVPD update/disable VID.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

stih407 SoC have a dedicated hardware cursor plane,
this patch enable it.
The hardware have a color look up table, fix it to
be able to use ARGB8888.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

For stih407 SoC enable the second mixer to get two CRTC.
Allow GPD planes and encoders to be connected to this new CRTC.
Cursor plane can only be set on first CRTC.
GPD clocks needed change the parent clock depending on which
CRTC GPD are used.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

The HDMI path introduce a delay of 6 pixels.
This delay should be take into account while programming
VTG for the HDMI. Without this delay, the HDMI active
window area is shift of 6 pixel on the right.

Set also timing for DVO output.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

Change some functions prototype to prepare the introduction of
auxiliary crtc. It will also help to have a DVO encoder.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

Make sure that vblank is enabled when crtc commit is call.
Replace drm_vblank_off() by drm_crtc_vblank_off()
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

The hardware expect to have the infoframe checksum in the first byte.
In consequence shift all infoframe on one byte.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

Stop use event_lock in vblank disable function.
This was creating a dead lock.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

Store the physical address at node creation time
to avoid use of virt_to_dma and dma_to_virt everywhere
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

Make sure that mixer control register is correctly reset
before use it.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

gpio used for HDMI hot plug detection is useless,
HDMI_STI register contains an hot plug detection status bit.
Fix binding documentation.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

Depending of the board configuration i2c for ddc could change,
this patch allow to use a phandle to specify which i2c controller to use.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>

We may be hidding bugs by doing that, so let remove it and have the
actual mask value shine through, for better or worse.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

While trying to unify the order of those arguments throughout the
driver, Daniel noticed what we were inverting them in this part of the
code.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>