drm: fix returning -EINVAL on setmaster if another master is active

We link every DRM "file_priv" to a "drm_master" structure. Currently, the
drmSetMaster() call returns 0 when there is _any_ active master associated
with the "drm_master" structure of the calling "file_priv". This means,
that after drmSetMaster() we are not guaranteed to be DRM-Master and might
not be able to perform mode-setting.

A way to reproduce this is by starting weston with the DRM backend from
within an X-console (eg., xterm). Because the xserver's "drm_master" is
currently active, weston is assigned to the same master but is inactive
because its VT is inactive and the xserver is still active. But when
"fake-activating" weston, it calls drmSetMaster(). With current behavior
this returns "0/success" and weston thinks that it is DRM-Master, even
though it is not (as the xserver is still DRM-Master).
Expected behavior would be drmSetMaster() to return -EINVAL, because the
xserver is still DRM-Master. This patch changes exactly that.

The only way this bogus behavior would be useful is for clients to check
whether their associated "drm_master" is currently the active DRM-Master.
But this logic fails if no DRM-Master is currently active at all. Because
then the client itself would become DRM-Master (if it is root) and this
makes this whole thing useles.

Also note that the second "if-condition":
  file_priv->minor->master != file_priv->master
is always true and can be skipped.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel into drm-next

Daniel writes:
Highlights of this -next round:
- ivb fdi B/C fixes
- hsw sprite/plane offset fixes from Damien
- unified dp/hdmi encoder for hsw, finally external dp support on hsw
  (Paulo)
- kill-agp and some other prep work in the gtt code from Ben
- some fb handling fixes from Ville
- massive pile of patches to align hsw VGA with the spec and make it
  actually work (Paulo)
- pile of workarounds from Jesse, mostly for vlv, but also some other
  related platforms
- start of a dev_priv reorg, that thing grew out of bounds and chaotic
- small bits&pieces all over the place, down to better error handling for
  load-detect on gen2 (Chris, Jani, Mika, Zhenyu, ...)

On top of the previous pile (just copypasta):
- tons of hsw dp prep patches form Paulo
- round scheduled work items and timers to nearest second (Chris)
- some hw workarounds (Jesse&Damien)
- vlv dp support and related fixups (Vijay et al.)
- basic haswell dp support, not yet wired up for external ports (Paulo)
- edp support (Paulo)
- tons of refactorings to prepare for the above (Paulo)
- panel rework, unifiying code between lvds and edp panels (Jani)
- panel fitter scaling modes (Jani + Yuly Novikov)
- panel power improvements, should now work without the BIOS setting it up
- extracting some dp helpers from radeon/i915 and move them to
  drm_dp_helper.c
- randome pile of workarounds (Damien, Ben, ...)
- some cleanups for the register restore code for suspend/resume
- secure batchbuffer support, should enable tear-free blits on gen6+
  Chris)
- random smaller fixlets and cleanups.

* 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (231 commits)
  drm/i915: Restore physical HWS_PGA after resume
  drm/i915: Report amount of usable graphics memory in MiB
  drm/i915/i2c: Track users of GMBUS force-bit
  drm/i915: Allocate the proper size for contexts.
  drm/i915: Update load-detect failure paths for modeset-rework
  drm/i915: Clear unused fields of mode for framebuffer creation
  drm/i915: Always calculate 8xx WM values based on a 32-bpp framebuffer
  drm/i915: Fix sparse warnings in from AGP kill code
  drm/i915: Missed lock change with rps lock
  drm/i915: Move the remaining gtt code
  drm/i915: flush system agent TLBs on SNB
  drm/i915: Kill off now unused gen6+ AGP code
  drm/i915: Calculate correct stolen size for GEN7+
  drm/i915: Stop using AGP layer for GEN6+
  drm/i915: drop the double-OP_STOREDW usage in blt_ring_flush
  drm/i915: don't rewrite the GTT on resume v4
  drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex
  drm/i915: put ring frequency and turbo setup into a work queue v5
  drm/i915: don't block resume on fb console resume v2
  drm/i915: extract l3_parity substruct from dev_priv
  ...

drm/i915: Restore physical HWS_PGA after resume

By always setting up the HWS register for both physical and virtual
address variations during render ring we can reduce the number of
different special cases that get set up at varying different times
during module load.

Fixes regression from

commit c630119f43471a8ece356b01dabf07f944f453b3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Oct 17 11:32:57 2012 +0200

    drm/i915: don't save/restore HWS_PGA reg for kms

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Report amount of usable graphics memory in MiB

...rather than kilo-PTE.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Apply s/Usabel/usable/ bikeshed suggested by Ben Widawsky.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/i2c: Track users of GMBUS force-bit

This fixes a regression for SDVO from

commit fbfcc4f3a0cf8bbde87646b74241faa8e37426bf
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Mon Oct 22 16:12:18 2012 +0300

    drm/i915/sdvo: restore i2c adapter config on intel_sdvo_init() failures

As SDVOB and SDVOC are multiplexed on the same pin, if a chipset does
not have the second SDVO encoder, it will then remove the force-bit
setting on the common i2c adapter during teardown. All subsequent
attempts of trying to use GMBUS with SDVOB then fail.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: fixup inversion in the debug printout, noticed by Jani
Nikulai.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Allocate the proper size for contexts.

Whoops. This was fixed previously, but not sure how it got lost. It's
not needed for -fixes or stable because at the moment
drm_i915_file_private is way bigger than i915_hw_context (by 120 bytes
on my 64b build).

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update load-detect failure paths for modeset-rework

After the rework, intel_set_mode() became a little better behaved in
restoring the current mode if we failed to apply the requested modeline.
However, the failure path for load-detect would clobber the existing
state, leading to an oops during BIOS takeover on older machines.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Clear unused fields of mode for framebuffer creation

With the stricter checks introduced in
commit ac911edae5960d7dccd9883f5fa5d25b591520de
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Oct 31 17:50:19 2012 +0200

    drm/i915: Check the framebuffer offset

(and friends), it became especially prudent to make sure that the
additional fields inside the mode were cleared before attempting to
create a framebuffer. In particular, the fb created for load detection
failed to do so and hence failed.

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>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Always calculate 8xx WM values based on a 32-bpp framebuffer

The specs for gen2 say that the watermark values "should always be set
assuming a 32bpp display mode, even though the display mode may be 15 or
16 bpp."

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix sparse warnings in from AGP kill code

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Missed lock change with rps lock

Fixes a WARN_ON in igt/tests/debugfs_reader

CC: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Move the remaining gtt code

It's pretty much all consolidated now that we've killed AGP. We can move
the one outlier, and defines too.

(Kill some unused defines in the process)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: flush system agent TLBs on SNB

This allows us to map the PTEs WC. I've not done thorough testing or
performance measurements with this patch, but it should be decent.

This is based on a patch from Jesse with the original commit message
> I've only lightly tested this so far, but the corruption seems to be
> gone if I write the GFX_FLSH_CNTL reg after binding an object.  This
> register should control the TLB for the system agent, which is what CPU
> mapped objects will go through.

It has been updated for the new AGP-less code by me, and included with
it is feedback from the original patch.

v2: Updated to reflect paranoia on pte updates/register posting reads.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by [v1]: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Kill off now unused gen6+ AGP code

v2: Accidently removed an ILK case in i9xx_setup (Nicely found by Chris)

CC: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by [v1] : Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Calculate correct stolen size for GEN7+

This bug existed in the old code, but was easier to fix here in the
rework. Unfortunately gen7 doesn't have a nice way to figure out the
size and we must use a lookup table.

As Jesse pointed out, there is some confusion in the docs about these
definitions. We're picking the one which seems more accurate, but we
really aren't certain.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Stop using AGP layer for GEN6+

As a quick hack we make the old intel_gtt structure mutable so we can
fool a bunch of the existing code which depends on elements in that data
structure. We can/should try to remove this in a subsequent patch.

This should preserve the old gtt init behavior which upon writing these
patches seems incorrect. The next patch will fix these things.

The one exception is VLV which doesn't have the preserved flush control
write behavior. Since we want to do that for all GEN6+ stuff, we'll
handle that in a later patch. Mainstream VLV support doesn't actually
exist yet anyway.

v2: Update the comment to remove the "voodoo"
Check that the last pte written matches what we readback

v3: actually kill cache_level_to_agp_type since most of the flags will
disappear in an upcoming patch

v4: v3 was actually not what we wanted (Daniel)
Make the ggtt bind assertions better and stricter (Chris)
Fix some uncaught errors at gtt init (Chris)
Some other random stuff that Chris wanted

v5: check for i==0 in gen6_ggtt_bind_object to shut up gcc (Ben)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by [v4]: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Make the cache_level -> agp_flags conversion for pre-gen6 a
tad more robust by mapping everything != CACHE_NONE to the cached agp
flag - we have a 1:1 uncached mapping, but different modes of
cacheable (at least on later generations). Suggested by Chris Wilson.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drop the double-OP_STOREDW usage in blt_ring_flush

This has been introduced in "drm/i915: TLB invalidation with
MI_FLUSH_DW requires a post-sync op".

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't rewrite the GTT on resume v4

The BIOS shouldn't be touching this memory across suspend/resume, so
just leave it alone.  This saves us ~6ms on resume on my T420 (retested
with write combined PTEs).

v2: change gtt restore default on pre-gen4 (Chris)
    move needs_gtt_restore flag into dev_priv
v3: make sure we restore GTT on resume from hibernate (Daniel)
    use opregion support as the cutoff for restore from resume (Chris)
v4: use a better check for opregion (Chris)

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Kill the needs_gtt_restore indirection and check directly for
OpRegion. Also explain in a comment what's going on.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex

This allows the power related code to run independently of the rest of
the pipeline, extending the resume and init time improvements into
userspace, which would otherwise have been blocked on the struct mutex
if we were doing PCU communication.

v2: Also convert the locking for the rps sysfs interface.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: put ring frequency and turbo setup into a work queue v5

Communicating via the mailbox registers with the PCU can take quite
awhile.  And updating the ring frequency or enabling turbo is not
something that needs to happen synchronously, so take it out of our init
and resume paths to speed things up (~200ms on my T420).

v2: add comment about why we use a work queue (Daniel)
    make sure work queue is idle on suspend (Daniel)
    use a delayed work queue since there's no hurry (Daniel)
v3: make cleanup symmetric and just call cancel work directly (Daniel)
v4: schedule the work using round_jiffies_up to batch work better (Chris)
v5: fix the right schedule_delayed_work call (Chris)

References: https://bugs.freedesktop.org/show_bug.cgi?id=54089

Signed-of-by: Jesse Barnes <jbarnes@virtuougseek.org>
[danvet: bikeshed the placement of the new delayed work, move it to
all the other gen6 power mgmt stuff.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't block resume on fb console resume v2

The console lock can be contended, so rather than prevent other drivers
after us from being held up, queue the console suspend into the global
work queue that can happen anytime.  I've measured this to take around
200ms on my T420.  Combined with the ring freq/turbo change, we should
save almost 1/2 a second on resume.

v2: use console_trylock() to try to resume the console immediately (Chris)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: move dev_priv->console_resume_work next to the fbdev
pointer.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: extract l3_parity substruct from dev_priv

Pretty astonishing how far apart these two members landed ... Especially since
I've already removed almost 200 lines in between.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move dri1 dungeon out of dev_priv

Also, move dev_priv->counter there, it's only used in i915_dma.c

And also move the dri1 dungeon at the end of dev_priv where no one
cares about it.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move pwrctx/renderctx to the other ilk power state

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move dev_priv->(rps|ips) out of line

And give the structs slightly more generic names. I've decided to keep
the short rps/ips prefix, since that's just easier and less churn.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move the suspend/resume register file out of dev_priv

dev_priv has grown way too big, and grouping memebers into substructs
and moving them out of line helps re-gain some overview.

Unfortunatley I couldn't just call the substruct save and drop the prefix, since
that will make most member names clash with registers #defines. Changes in
i915_drv.h done by hand, everything else changed with
s/\<save\([A-Z]*\)/regfile.save\1/ in vim.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add clock gating regs to VLV offset check function

So we can write them properly.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: PIPE_CONTROL TLB invalidate requires CS stall

"If ENABLED, PIPE_CONTROL command will flush the in flight data  written
out by render engine to Global Observation point on flush done. Also
Requires stall bit ([20] of DW1) set."

So set the stall bit to ensure proper invalidation.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: TLB invalidation with MI_FLUSH_DW requires a post-sync op v3

So store into the scratch space of the HWS to make sure the invalidate
occurs.

v2: use GTT address space for store, clean up #defines (Chris)
v3: use correct #define in blt ring flush (Chris)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1063252
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement WaDisablePSDDualDispatchEnable on IVB & VLV

Workaround for dual port PS dispatch on GT1.

v2: pull in register definition & offset handling
v3: use IVB GT1 macro to get the right regs (Ben)
v4: add for VLV too (Ben)
v5: don't read the reg, it's masked so we'll only enable the one extra bit (Chris)
v6: use a _GT2 suffix for the second reg (Chris)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement WaDisableVLVClockGating_VBIIssue on VLV

This allows us to get the right vblank interrupt frequency.

v2: pull in register definition

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement WaForceL3Serialization on VLV and IVB

References: https://bugs.freedesktop.org/show_bug.cgi?id=50250
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement WaDisableDopClockGatingisable on VLV and IVB

v2: use correct register
v3: remove extra hunks, pull in register definitions & offset check directly
v4: add GT1 vs GT2 distinction for IVB portion (Ben)

References: https://bugs.freedesktop.org/show_bug.cgi?id=50233
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement WaDisableL3CacheAging on VLV

Needs to be set on every context restore as well, so set it as part of
the initial state so we can save/restore it.  Note this removes the IVB
workaround value from VLV and uses the default value, just adding in the
L3 cache aging disable bit, since the IVB value is wrong for VLV.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Antti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix Haswell FDI link disable path

This covers the "Disable FDI" section from the CRT mode set sequence.
This disables the FDI receiver and also the FDI pll.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix Haswell FDI link training code

This commit makes hsw_fdi_link_train responsible for implementing
everything described in the "Enable and train FDI" section from the
Hawell CRT mode set sequence documentation. We completely rewrite
hsw_fdi_link_train to match the documentation and we also call it in
the right place.

This patch was initially sent as a series of tiny patches fixing every
little problem of the function, but since there were too many patches
fixing the same function it got a little difficult to get the "big
picture" of how the function would be in the end, so here we amended
all the patches into a single big patch fixing the whole function.

Problems we fixed:

  1 - Train Haswell FDI at the right time.

    We need to train the FDI before enabling the pipes and planes, so
    we're moving the call from lpt_pch_enable to haswell_crtc_enable
    directly.

    We are also removing ironlake_fdi_pll_enable since the PLL
    enablement on Haswell is completely different and is also done
    during the link training steps.

  2 - Use the right FDI_RX_CTL register on Haswell

    There is only one PCH transcoder, so it's always _FDI_RXA_CTL.
    Using "pipe" here is wrong.

  3 - Don't rely on DDI_BUF_CTL previous values

    Just set the bits we want, everything else is zero. Also
    POSTING_READ the register before sleeping.

  4 - Program the FDI RX TUSIZE register on hsw_fdi_link_train

    According to the mode set sequence documentation, this is the
    right place. According to the FDI_RX_TUSIZE register description,
    this is the value we should set.

    Also remove the code that sets this register from the old
    location: lpt_pch_enable.

  5 - Properly program FDI_RX_MISC pwrdn lane values on HSW

  6 - Wait only 35us for the FDI link training

    First we wait 30us for the FDI receiver lane calibration, then we
    wait 5us for the FDI auto training time.

  7 - Remove an useless indentation level on hsw_fdi_link_train

    We already "break" when the link training succeeds.

  8 - Disable FDI_RX_ENABLE, not FDI_RX_PLL_ENABLE

    When we fail the training.

  9 - Change Haswell FDI link training error messages

    We shouldn't call DRM_ERROR when still looping through voltage
    levels since this is expected and not really a failure. So in this
    commit we adjust the error path to only DRM_ERROR when we really
    fail after trying everything.

    While at it, replace DRM_DEBUG_DRIVER with DRM_DEBUG_KMS since
    it's what we use everywhere.

  10 - Try each voltage twice at hsw_fdi_link_train

    Now with Daniel Vetter's suggestion to use "/2" instead of ">>1".

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Applied tiny bikesheds:
- mention in comment that we test each voltage/emphasis level twice
- realing arguments of the only untouched reg write, it spilled over
  the 80 char limit ...]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove HAS_eDP as unnecessary and inconsistent indirection

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: set the correct number of FDI lanes on Haswell

We had 2 places using X2 and one place using X1.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: kill pch_init_clock_gating indirection

Now that we no longer pretend to have flexibility in matching any
north display block with any pch, we can ditch this.

v2: Fix the embarassing rebase fail that Paulo Zanoni spotted.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement WADP0ClockGatingDisable

Found in Bspec vol4h South Display Engine Registers [CPT, PPT],
section "5.3.1  TRANS_CHICKEN_1—Transcoder Chicken Bits 1"

v2: Make it compile.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: CPT+ pch transcoder workaround

We need to set the timing override chicken bit after fdi link training
has completed and before we enable the transcoder. We also have to
clear that bit again after disabling the pch transcoder.

See "Graphics BSpec: vol4g North Display Engine Registers [IVB],
Display Mode Set Sequence" and "Graphics BSpec: vol4h South Display
Engine Registers [CPT, PPT], South Display Engine Transcoder and FDI
Control, Transcoder Debug and DFT, TRANS_CHICKEN_2" bit 31:

"Workaround : Enable the override prior to enabling the transcoder.
Disable the override after disabling the transcoder."

While at it, use the _PIPE macro for the other TRANS_DP register.

v2: Keep the w/a as-is, but kill the original (but wrongly placed)
workaround introduced in

commit 3bcf603f6d5d18bd9d076dc280de71f48add4101
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Jul 27 11:51:40 2011 -0700

    drm/i915: apply timing generator bug workaround on CPT and PPT

and

commit d4270e57efe9e2536798c59e1ed2fd0a1e5cdfcf
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Oct 11 10:43:02 2011 -0700

    drm/i915: export a CPT mode set verification function

Note that this old code has unconditionally set the w/a, which might
explain why fdi link training sometimes silently fails, and especially
why the auto-train did not seem to work properly.

v3: Paulo Zanoni pointed out that this workaround is also required on
the LPT PCH. And Arthur Ranyan confirmed that this workaround is
requierd for all ports on the pch, not just DP: The important part
is that the bit is set whenever the pch transcoder is enabled, and
that it is _not_ set while the fdi link is trained. It is also
important that the pch transcoder is fully disabled, i.e. we have to
wait for bit 30 to clear before clearing the w/a bit.

Hence move to workaround into enable/disable_transcoder, where the pch
transcoder gets enabled/disabled.

v4: Whitespace changes dropped.

v5: Don't run the w/a on IBX, we only need it on CPT/PPT and LPT.

v6:
- resolve conflicts with Paulo's big hsw vga rework
- s/!IBX/CPT since hsw paths are now all separate, and Paulo's patch
  to implement the equivalent w/a for LPT is already merged.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Arthur Ranyan <arthur.j.runyan@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v5)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v5)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drop unnecessary check from fdi_link_train code

They are all written for a specific north disaplay->pch combination.
So stop pretending otherwise.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: check whether the pch is the soulmate of the cpu

We don't really support fancy north display/pch combinations, so
put a big yelling WARN_ON in there. It /should/ be impossible, but
alas, the rumours don't stop (mostly due to really early silicon
sometimes using older PCHs).

v2: Fixup the logic fumble noticed by Paulo Zanoni. I should actually
try to test run the patch next time around ...

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move panel connectors to the front

This essentially reverts

commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson <ajax@redhat.com>
Date:   Fri Jul 16 14:46:29 2010 -0400

    drm/i915: Initialize LVDS and eDP outputs before anything else

simply because it doesn't scale: It misses SDVO and DVO panels,
and now with DDI encoders on haswell this is becoming unmanageable.

Instead we simply sort the connector list after everything is
set up.

Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: add helper to sort panels to the head of the connector list

Userspace seems to like this, see

commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
Author: Adam Jackson <ajax@redhat.com>
Date:   Fri Jul 16 14:46:29 2010 -0400

    drm/i915: Initialize LVDS and eDP outputs before anything else

    This makes them sort to the front in X, which makes them likely to be
    the primary outputs if you haven't specified a preference in your DE,
    which is likely to be what you want.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Sorting the connector list after the fact is much easier than trying
to be clever with the init sequence.

Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't assert disabled FDI before disabling the FDI

On Haswell/LPT we must disable the PCH transcoder before we disable
the FDI, so don't check for disabled FDI there.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't call intel_disable_pch_pll on Haswell/LPT

This function is only for the previous gens.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement timing override workarounds on LPT

These workarounds are documented on the CRT mode set sequence.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use CPU and PCH transcoders on lpt_disable_pch_transcoder

... instead of "pipe", which is wrong.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add SURFLIVE register definitions

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use PIPECONF_INTERLACE_MASK_HSW on lpt_enable_pch_transcoder

... instead of PIPECONF_INTERLACE_MASK.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: applied the change by hand due to patch reorder.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't assert_pch_ports_disabled on LPT

That function is made for IBX. Running it on LPT will trigger tons of
"unclaimed register" errors. The only port remaining on LPT is
PCH_ADPA.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't rely on previous values when setting LPT TRANSCONF

Because we already set all the bits we can set.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: apply by hand due to dropped patch. Also, obey my OCD a bit
and do a s/_TRANSACONF/TRANSCONF(TRANSCODER_A)/, makes it more
consisten with other lpt pch code imnsho ...]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use CPU and PCH transcoders on lpt_enable_pch_transcoder

... instead of using "pipe". As already explained in previous commits,
since Haswell/LPT cpu_transcoder, pch_transcoder and pipe are not the
same thing.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't assert_pch_pll_enabled on lpt_enable_pch_transcoder

These asserts are specific to IBX/CPT/PPT. Inside the assert_pch_pll
function we even "return" in case we detect LPT, but I prefer to just
not call it. In the future we might rename to something like
ibx_assert_pch_pll.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove IBX code from lpt_enable_pch_transcoder

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove Haswell code from ironlake_enable_pch_transcoder

Since now we have lpt_enable_pch_transcoder.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fork lpt version of ironlake_{en, dis}able_pch_transcoder

For now the new functions are just copies. Differences will be added
later.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: rename intel_{en, dis}able_transcoder

To ironlake_{en,dis}able_pch_transcoder since these functions will be
different on Haswell/LPT and since the "transcoder" they {en,dis}able
is on the PCH.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: again a small conflict because the fdi disable sequenc looks
a bit different here.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use the CPU and PCH transcoders on lpt_pch_enable

On Haswell/LPT, pipe, cpu_transcoder and pch_transcoder are different
things with different values, unlinke the previous gens. So here we
use the right thing at the right place.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: apply the patch by hand due to the reorder patch sequence. We
also can't kill all uses of pipe where we should, since the fdi link
train code isn't fixed up yet on this baselin.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't assert_panel_unlocked on LPT

There is no LVDS, so don't poke the LVDS registers.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't call ironlake_enable_pch_pll on lpt_pch_enable

This is just wrong. The lpt_program_iclkip should disable the PCH
pixel clocks (and yes, we plan to rename it later).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: rename intel_enable_pch_pll to ironlake_enable_pch_pll

Because this function is only for the older PCHs, not the newer ones.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove ironlake bits from lpt_pch_enable

Since this function will only run on Haswell/LPT and newer.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove Haswell/LPT bits from ironlake_pch_enable

Since now we have lpt_pch_enable for them.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add lpt_pch_enable

For now it's just a fork of ironlake_pch_enable. The next commits will
change this.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use intel_ddi_get_hw_state on CRT encoder too

Because things changed on Haswell/LPT and the bits checked by
intel_crt_get_hw_state have moved to other registers.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: don't set ADPA pipe select on LPT

Those bits just don't exist on LPT. The CRT DAC, PCH transcoder and
FDI RX are always connected to DDI E.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move encoder->mode_set calls to crtc_mode_set

Makes more sense to group the entire mode_set stage into one function.
Noticed while discussiing the rather confusing set of function names
with Paulo Zanoni. Unfortunately I don't have an idea to make the
function names lesss confusion.

v2: Use for_each_encoder_on_crtc as suggested by Chris Wilson.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Introduce intel_crtc_update_sarea_pos()

Refactor the code that stores the panning x/y position into the sarea.

This also changes the code so that it won't mistakenly update
sareaB_x/y for pipe >= C.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Bad pixel formats can't reach the sprite code

The framebuffer pixel format is already checked by the common code.
So there's no way an invalid format could reach the driver. So instead
of falling back to a default format, call BUG().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: pixel_size == cpp

Use drm_format_plane_cpp() to get 'pixel_size' in the sprite code.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Check the framebuffer offset

The current code can't deal with framebuffers with an offset. Return an
error when trying to create such a framebuffer until the rest of the
code is fixed to handle them.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Check framebuffer stride more thoroughly

Make sure the the framebuffer stride is smaller than 32k. That
seems to be the limit on recent hardware. Not quite sure if
<=Gen4 has smaller limits.

Also when using a tiled memory make sure the object stride matches
the framebuffer stride.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix display pixel format handling

Fix support for all RGB/BGR pixel formats (except the 16:16:16:16 float
format).

Fix intel_init_framebuffer() to match hardware and driver limitations:
* RGB332 is not supported at all
* CI8 is supported
* XRGB1555 & co. are supported on Gen3 and earlier
* XRGB210101010 & co. are supported from Gen4 onwards
* BGR formats are supported from Gen4 onwards
* YUV formats are supported from Gen5 onwards (driver limitation)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move more pte encoding to pte encode

In order to handle differences in pte encoding between architectures it
is desirable to have one helper function, pte_encode, do it all for us.
As such, this commit moves the code around so we're in good shape to do
that.

Luckily the ppgtt pte and the ggtt pte look very similar.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Extract PPGTT pte encoding

HSW will change the PTE encoding, and laying this out now will be
helpful when we're ready to implement that. More importantly, GGTT and
PPGTT PTE encoding is quite similar, so moving this out into a helper
function will enable us to lance the AGP layer.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: introduce gtt_pte_t

This will make the calculations of size easier to read instead of just
assuming uint32_t everywhere.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add dev to ppgtt

Some subsequent commits will need to know what generation we're running
on to do different pte encoding for the ppgtt. Since it's not much
hassle or overhead to store it in the ppgtt structure, do that.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: No LLC_MLC for HSW.

The mid-level cache or as it's more commonly referred to now as L3, is
not setup this way on HSW.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/ringbuffer: exclude last 2 cachelines on 845g on all callpaths

Make intel_render_ring_init_dri and intel_init_ring_buffer symmetrical
with regards of workaround introduced by:

commit 27c1cbd06a7620b354cbb363834f3bb8df4f410d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Apr 9 13:59:46 2012 +0100

    drm/i915/ringbuffer: Exclude last 2 cachlines of ring on 845g

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: create the DDI encoder

Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it
inits the encoder and then calls the proper init_connector functions.
Notice that for non-eDP ports we call both HDMI and DP connector init,
so we have 2 connectors attached to each DDI encoder.

After this change, intel_hdmi_init and intel_dp_init are only called
by Ivy Bridge and earlier, while hardware containing DDI outputs
should call intel_ddi_init.

Also added/removed quite a few "static" keywords due to the fact that
some function pointers were moved from intel_dp.c and intel_hdmi.c to
intel_ddi.c.

DP finally works on Haswell now! \o/

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add intel_ddi_connector_get_hw_state

We need this since now on DDI we will have 2 connectors on each
encoder.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add port field to intel_digital_port

Both "intel_dp" and "intel_hdmi" structs had a "port" field, which
always had the same value. It makes more sense to move this to
intel_digital_port, so we can know the port independently of the
connector type.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: reset intel_encoder->type when DP or HDMI is detected

When intel_hdmi_detect detects a monitor, set intel_encoder->type with
INTEL_OUTPUT_HDMI. Same for DP.

This should not break the current code because these variables never
change. This will be used after we create the DDI encoder because it
will have both DP and HDMI connectors.

We won't support eDP+HDMI on the same port, so if an encoder is eDP we
should expect it to always remain eDP and never change.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: split intel_dp_init into encoder and connector pieces

Same reason as the previous HDMI commit: the DDI code will have its
own encoder init function but still use the DP and HDMI connectors.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: kill the unnecessarily added line that Damien spotted in
review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: split intel_hdmi_init into encoder and connector pieces

We want to split the HDMI connector and encoder initialization because
in the future the DDI code will have its own "encoder init" function,
but it will still call intel_hdmi_init_connector. The DDI encoder will
actually have two connectors attached to it: HDMI and DP.

The best way to look at this patch is to imagine that we're renaming
intel_hdmi_init to intel_hdmi_init_connector and removing the
encoder-specific pieces and placing them into intel_hdmi_init.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: create intel_digital_port and use it

The goal is to have one single encoder capable of controlling both DP
and HDMI outputs. This patch just adds the initial infrastructure, no
functional changes.

Previously, both intel_dp and intel_hdmi were intel_encoders. Now,
these 2 structs do not have intel_encoder as members anymore. The new
struct intel_digital_port has intel_encoder as a member, and it also
includes intel_dp and intel_hdmi as members. In other words: see the
changes inside intel_drv.h: it's the most important change, everything
else is only to make it compile and work.

For now, each intel_digital_port is still only able to control one of
HDMI or DP, but not both together.

In the future we should also try to merge the common fields from
intel_dp and intel_hdmi (e.g., port).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Add the missing ' ' spotted by Damien Lespiau.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add intel_dp_to_dev and intel_hdmi_to_dev

When we add struct intel_digital_port, there will be no direct way of
going from intel_{dp,hdmi} to drm_device: we will need to call
container_of().

This patch adds functions to go from intel_{dp,hdmi} to drm_device.
The main goal here is to greatly reduce the size of the next patch,
where we will change the implementation of the functions we just
added here (among other things).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: simplify assignments inside intel_dp.c

 - Replace container_of with enc_to_intel_dp.
 - Walk through less structures when making assignments.
 - Rename some variables to keep our naming standards.

As a bonus, this will reduce the usage of "struct intel_dp", making
the future patch that introduces intel_digital_port smaller and easier
to review.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix HSW power well control state read

Fix power well control state by reading real register offset.

Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Flush using only the correct base address register

We were writing DSP_ADDR and DSP_SURF unconditionally. This did not
trigger an unclaimed write before HSW as the address of DSP_ADDR has
been repurposed as DSP_LINOFF.

On HSW, though, DSP_LINOFF has been removed and then writting to it
triggers an unclaimed write.

This patch writes to DSP_ADDR or DSP_SURF to flush the display plane
configuration depending on the gen we're running on.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement WaDisableRenderCachePipelinedFlush

Comment says for eaglelake/cantiga, but it's listed in the ilk table,
too. So apply it to both.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement WaIssueDummyWriteToWakeupFromRC6

Or at least our best understanding of it.

v2: Fixup commit message and put the wa name into the comment block.
And actually update the commit, too.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: adjust sprite base address

Just like in:

commit c2c75131244507c93f812862fdbd4f3a37139401
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jul 5 12:17:30 2012 +0200

    drm/i915: adjust framebuffer base address on gen4+

but this time, for the sprite planes. This ensures that the
sprite offset are always inside the supported hardware limits since it
becomes the offset into a page and we adjust the base address to a page
boundary.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix sprite offset on HSW

HSW consolidates SPRTILEOFF and SPRLINOFF into a single SPROFFSET
register.

v2: Remove a useless level of indentation (Paulo Zanoni)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix primary plane offset on HSW

Haswell consolidates DSP_TILEOFF and DSP_LINOFF into DSP_OFFSET (aka
PRI_OFFSET).

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Error out when trying to set a y-tiled as a sprite

v2: Use a switch for consistency (Chris Wilson)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/tv: Use intel_flush_display_plane() to flush the primary plane

Instead of writing to the DSP_ADDR ourselves. This will do the right
thing on gen >= 4 as well.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: check fdi B/C lane sharing constraint

And properly toggle the chicken bit in the pch to enable/disable fdi C
rx. If we don't set this bit correctly, the rx gets confused in link
training, which can result in an fdi link that silently fails to train
the link (since the corresponding register reports success). Note that
both fdi link B and C can suffer when this bit is not set correctly.

The code as-is has a few deficiencies:
- We presume all pipes use the pch which is not the case for cpu edp.
- We don't bother with disabling both pipes when we could make things
  work, e.g. when pipe B switched from 4 to 2 lanes due to a mode
  change, we don't bother updating the w/a bit.
- It's ugly.

All of these are because we compute ->fdi_lanes way too late, when
we're already setting up individual pipes. We need to have this
information in ->modeset_global_resources already, to set things up
correctly. But that is a much larger reorg of the code.

Note that we actually hit the 2 lanes limit in practice rather
quickly: Even though the 1920x1200 mode native mode of my screen fits
into 2 lanes, it needs 3 lanes for the 1920x1080 (since that somehow
has much more blanking ...). Not obeying this restriction seems to
results in cute-looking digital noise.

v2: Only ever clear the chicken bit when both pipes are off.

v3: Use the new ->modeset_global_resources callback.

v4: Move the WARNs to the right place. Oh how I hate hacks.

v5: Fix spelling, noticed by Paulo Zanoni.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>