gpu: ipu-v3: Select GENERIC_IRQ_CHIP to fix build error

This driver uses GENERIC_IRQ_CHIP, so it needs to select GENERIC_IRQ_CHIP to
avoid build error.

Fixes below build errors:
ERROR: "irq_alloc_domain_generic_chips" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined!
ERROR: "irq_gc_mask_clr_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined!
ERROR: "irq_gc_mask_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined!
ERROR: "irq_generic_chip_ops" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined!
ERROR: "irq_gc_ack_set_bit" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined!
ERROR: "irq_get_domain_generic_chip" [drivers/gpu/ipu-v3/imx-ipu-v3.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
gpu: ipu-v3: Return proper error on ipu_add_client_devices error path

Avoid returning an uninitialized variable in the error path.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
gpu: ipu-v3: ipu-smfc: Do not leave DEBUG defined

Let's only define DEBUG for debugging purpose and not by default to avoid
printing debugging message unnecessarily.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
drm/i915: Fix DVO 2x clock enable on 830M

The spec says:
"For the correct operation of the muxed DVO pins (GDEVSELB/ I2Cdata,
GIRDBY/I2CClk) and (GFRAMEB/DVI_Data, GTRDYB/DVI_Clk): Bit 31
(DPLL VCO Enable) and Bit 30 (2X Clock Enable) must be set to “1” in
both the DPLL A Control Register (06014h-06017h) and DPLL B Control
Register (06018h-0601Bh)."

The pipe A and B force quirks take care of DPLL_VCO_ENABLE, so we
just need a bit of special care to handle DPLL_DVO_2X_MODE.

v2: Recompute num_dvo_pipes on the spot, use PIPE_A/PIPE_B instead
    of pipe/!pipe for the register offsets in disable (Daniel)
    Add a comment about the ordering in enable and another one
    about filtering out the DVO 2x bit in state readout

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Thomas Richter <richter@rus.uni-stuttgart.de> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Limit the watermark to at least 8 entries on gen2/3

830 is very unhappy of the watermark value is too low (indicating a very
high watermark in fact, ie. memory fetch will occur with an almost full
FIFO). Limit the watermark value to at least 8 cache lines.

That also matches the burst size we use on most platforms. BSpec seems
to indicate we should limit the watermark to 'burst size + 1'. But on
gen4 we already use a hardcoded 8 as the watermark value (as the spec
says we should), so just use 8 as the limit on gen2/3 as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915/hdmi, dp: Do not dereference the encoder in the connector destroy

Oops, apparently intel_hdmi/intel_dp is the encoder - an object with a
distinct lifetime to the connector, and so we cannot simply reuse the
common function to unset and free the edid.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915/dp: add missing \n in the TPS3 debug message

This goes back to

commit 06ea66b6bb445043dc25a9626254d5c130093199
Author: Todd Previte <tprevite@gmail.com>
Date:   Mon Jan 20 10:19:39 2014 -0700

    drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices

Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Pimp commit message a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915/edp: use lane count and link rate from DPCD for eDP

eDP panels are generally designed to support only a single clock and
lane configuration.

commit 56071a207602a451f0c46d3dcc8379b59ef576e2
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Tue May 6 14:56:52 2014 +0300

    drm/i915: use lane count and link rate from VBT as minimums for eDP

should have started using the optimal link parameters for eDP
panels. Turns out a certain other OS uses DPCD instead of VBT, which
means trusting VBT on this may not be so reliable after all. Follow
suit.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81647
Tested-by: Adam Jirasek <libm3l@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79386
Tested-by: Narthana Epa <narthana.epa+freedesktop@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Objects on the unbound list may still have an active reference

Due to the lazy retirement semantics, even though we have unbound an
object, it may still hold onto an active reference. So in the debug code,
play safe.

v2: Export i915_gem_shrink() rather than opencoding it.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Drop any active reference before unbinding

Before we process the final unbind on an object and move it to the
unbound list, it is semantically cleaner if there are no more active
references to the object. (An active reference would imply that it was
still being accessed by the GPU after it became inaccessible.) The
caveat is that all callsites must be prepared for the object to
disappeared during the unbind - i.e. they must hold their own reference.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Wrap -EIO send-vblank event for failed pageflip in spinlock

drm_send_vblank_event() demands that we hold the event spinlock whilst
calling it, so do so.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fix the double lock as requested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Don't reinit hpd interrupts after gpu reset

Somehow I've overlooked this when simplifying the irq reinit
scheme on gen4.5+ in

commit 78ad455fd229c6f6cc2f390ccbe0d8f1a62d55a9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu May 22 22:18:21 2014 +0200

    drm/i915: Improve irq handling after gpu resets

Since display interrups in general survive a gpu reset on those
platforms there's also no need to reinit the hotplug settings.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: fix another use-after-free in i915_gem_evict_everything

Also here, i915_gem_evict_vm causes an unbind, which can end up dropping
the last ref to the ppgtt.

Triggered by igt gem_evict_everything test.

Testcase: igt/gem_evict_everything
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Chris Wilson <chris@cris-wilsonc.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: add cherryview specfic forcewake in execlists_elsp_write

In chv, we have two power wells Render & Media. We need to use
corresponsing forcewake count. If we dont follow this we are getting
error "*ERROR*: Timed out waiting for forcewake old ack to clear" due to
multiple entry into __vlv_force_wake_get.

Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Requested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: HSW always use GGTT selector for secure batches

gen6 and earlier conflate address space selection (ppgtt vs ggtt) with
the security bit (i.e. only privileged batches were allowed to run from
ggtt). From Haswell only, you are able to select the security bit
separate from the address space - and we always requested to use ppgtt.
This breaks the golden render state batch execution with full-ppgtt as
that is only present in the global GTT and more generally any secure
batch that is not colocated in the ppgtt and ggtt. So we need to
disable the use of the ppgtt selector bit for secure batches, or else we
hang immediately upon boot and thence after every GPU reset...

v2: Only HSW differentiates between secure dispatch and ggtt, so simply
ignore the differentiation and always use secure==ggtt.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Rectify commit message as noted by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Match GTT space sanity checker with implementation

If we believe that the device can cross cache domains in its prefetcher
(i.e. we allow neighbouring pages in different domains), we don't supply
a color_adjust callback. Use the presence of this callback to better
determine when we should be verifying that the GTT space we just
used is valid.

v2: Remove the superfluous struct drm_device function param as well.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Also adjust the comment per irc discussion with Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Extend BIOS stolen mem handling to all platform

Based upon a patch from Deepak, but reworked to only apply on gen7+
and with the logic a bit clarified.

v2: Fix s/SHIFT/MASK/ fumble that Ville spotted.

Cc: Deepak S <deepak.s@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Use EIO instead of EAGAIN for sink CRC error.

If something while getting panel CRC this means that probably hw I/O error
so hw is busted and try again shouldn't help much.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915/bdw: Cleanup pre prod workarounds

as these have been fixed in production hw and hurt performance
if applied.

v2: adjust requested ring space (Ville)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83482
Tested-by: zhoujian <jianx.zhou@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm: Don't update vblank timestamp when the counter didn't change

If we already have a timestamp for the current vblank counter, don't
update it with a new timestmap. Small errors can creep in between two
timestamp queries for the same vblank count, which could be confusing to
userspace when it queries the timestamp for the same vblank sequence
number twice.

This problem gets exposed when the vblank disable timer is not used
(or is set to expire quickly) and thus we can get multiple vblank
disable<->enable transition during the same frame which would all
attempt to update the timestamp with the latest estimate.

Testcase: igt/kms_flip/flip-vs-expired-vblank
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>

v2:Mario: Trivial rebase on top of current drm-next (13-Sep-2014)
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>