The routine to query the base of stolen memory was using the wrong
registers and the wrong encodings on virtually every platform.

It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then, one has to look at the BIOS memory maps to
find the Top of Memory. Alas that is not exported by arch/x86 and so we
have to resort to disabling stolen memory on gen2 for the time being.

Then SandyBridge enlarged the PCI register to a full 32-bits and change
the encoding of the address, so even though we happened to be querying
the right register, we read the wrong bits and ended up using address 0
for our stolen data, i.e. notably FBC.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

spinlock_t should always be used.

  LD      drivers/gpu/drm/i915/built-in.o
  CHECK   drivers/gpu/drm/i915/i915_drv.c
  CC [M]  drivers/gpu/drm/i915/i915_drv.o
  CHECK   drivers/gpu/drm/i915/i915_dma.c
  CC [M]  drivers/gpu/drm/i915/i915_dma.o
  CHECK   drivers/gpu/drm/i915/i915_irq.c
  CC [M]  drivers/gpu/drm/i915/i915_irq.o
  CHECK   drivers/gpu/drm/i915/i915_debugfs.c
drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression
drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression
  CC [M]  drivers/gpu/drm/i915/i915_debugfs.o
  CHECK   drivers/gpu/drm/i915/i915_suspend.c
  CC [M]  drivers/gpu/drm/i915/i915_suspend.o
  CHECK   drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types)
drivers/gpu/drm/i915/i915_gem.c:3703:14:    expected unsigned int [unsigned] [usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3703:14:    got restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: &=
drivers/gpu/drm/i915/i915_gem.c:3706:22:    left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3706:22:    right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |=
drivers/gpu/drm/i915/i915_gem.c:3707:22:    left side has type unsigned int
drivers/gpu/drm/i915/i915_gem.c:3707:22:    right side has type restricted gfp_t
drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types)
drivers/gpu/drm/i915/i915_gem.c:3711:39:    expected restricted gfp_t [usertype] mask
drivers/gpu/drm/i915/i915_gem.c:3711:39:    got unsigned int [unsigned] [usertype] mask
  CC [M]  drivers/gpu/drm/i915/i915_gem.o
  CHECK   drivers/gpu/drm/i915/i915_gem_context.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_context.o
  CHECK   drivers/gpu/drm/i915/i915_gem_debug.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_debug.o
  CHECK   drivers/gpu/drm/i915/i915_gem_evict.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_evict.o
  CHECK   drivers/gpu/drm/i915/i915_gem_execbuffer.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_execbuffer.o
  CHECK   drivers/gpu/drm/i915/i915_gem_gtt.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_gtt.o
  CHECK   drivers/gpu/drm/i915/i915_gem_stolen.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_stolen.o
  CHECK   drivers/gpu/drm/i915/i915_gem_tiling.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_tiling.o
  CHECK   drivers/gpu/drm/i915/i915_sysfs.c
  CC [M]  drivers/gpu/drm/i915/i915_sysfs.o
  CHECK   drivers/gpu/drm/i915/i915_trace_points.c
  CC [M]  drivers/gpu/drm/i915/i915_trace_points.o
  CHECK   drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types
drivers/gpu/drm/i915/intel_display.c:1736:9:     int enum transcoder  versus
drivers/gpu/drm/i915/intel_display.c:1736:9:     int enum pipe
drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types
drivers/gpu/drm/i915/intel_display.c:3659:48:     int enum pipe  versus
drivers/gpu/drm/i915/intel_display.c:3659:48:     int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_display.o
  CHECK   drivers/gpu/drm/i915/intel_crt.c
  CC [M]  drivers/gpu/drm/i915/intel_crt.o
  CHECK   drivers/gpu/drm/i915/intel_lvds.c
  CC [M]  drivers/gpu/drm/i915/intel_lvds.o
  CHECK   drivers/gpu/drm/i915/intel_bios.c
drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:706:60:    expected struct vbt_header *vbt
drivers/gpu/drm/i915/intel_bios.c:706:60:    got void [noderef] <asn:2>*vbt
drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces)
drivers/gpu/drm/i915/intel_bios.c:726:42:    expected void const *<noident>
drivers/gpu/drm/i915/intel_bios.c:726:42:    got unsigned char [noderef] [usertype] <asn:2>*
drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression
drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression
  CC [M]  drivers/gpu/drm/i915/intel_bios.o
  CHECK   drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static?
drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types
drivers/gpu/drm/i915/intel_ddi.c:1036:34:     int enum pipe  versus
drivers/gpu/drm/i915/intel_ddi.c:1036:34:     int enum transcoder
  CC [M]  drivers/gpu/drm/i915/intel_ddi.o
drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_ddi_setup_hw_pll_state’:
drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/gpu/drm/i915/intel_ddi.c:1111:12: note: ‘port’ was declared here
  CHECK   drivers/gpu/drm/i915/intel_dp.c
  CC [M]  drivers/gpu/drm/i915/intel_dp.o
  CHECK   drivers/gpu/drm/i915/intel_hdmi.c
  CC [M]  drivers/gpu/drm/i915/intel_hdmi.o
  CHECK   drivers/gpu/drm/i915/intel_sdvo.c
  CC [M]  drivers/gpu/drm/i915/intel_sdvo.o
  CHECK   drivers/gpu/drm/i915/intel_modes.c
  CC [M]  drivers/gpu/drm/i915/intel_modes.o
  CHECK   drivers/gpu/drm/i915/intel_panel.c
  CC [M]  drivers/gpu/drm/i915/intel_panel.o
  CHECK   drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/i915/intel_pm.c:2173:1: warning: symbol 'mchdev_lock' was not declared. Should it be static?
  CC [M]  drivers/gpu/drm/i915/intel_pm.o
  CHECK   drivers/gpu/drm/i915/intel_i2c.c
  CC [M]  drivers/gpu/drm/i915/intel_i2c.o
  CHECK   drivers/gpu/drm/i915/intel_fb.c
  CC [M]  drivers/gpu/drm/i915/intel_fb.o
  CHECK   drivers/gpu/drm/i915/intel_tv.c
  CC [M]  drivers/gpu/drm/i915/intel_tv.o
  CHECK   drivers/gpu/drm/i915/intel_dvo.c
  CC [M]  drivers/gpu/drm/i915/intel_dvo.o
  CHECK   drivers/gpu/drm/i915/intel_ringbuffer.c
  CC [M]  drivers/gpu/drm/i915/intel_ringbuffer.o
  CHECK   drivers/gpu/drm/i915/intel_overlay.c
  CC [M]  drivers/gpu/drm/i915/intel_overlay.o
  CHECK   drivers/gpu/drm/i915/intel_sprite.c
  CC [M]  drivers/gpu/drm/i915/intel_sprite.o
  CHECK   drivers/gpu/drm/i915/intel_opregion.c
  CC [M]  drivers/gpu/drm/i915/intel_opregion.o
  CHECK   drivers/gpu/drm/i915/dvo_ch7xxx.c
  CC [M]  drivers/gpu/drm/i915/dvo_ch7xxx.o
  CHECK   drivers/gpu/drm/i915/dvo_ch7017.c
  CC [M]  drivers/gpu/drm/i915/dvo_ch7017.o
  CHECK   drivers/gpu/drm/i915/dvo_ivch.c
  CC [M]  drivers/gpu/drm/i915/dvo_ivch.o
  CHECK   drivers/gpu/drm/i915/dvo_tfp410.c
  CC [M]  drivers/gpu/drm/i915/dvo_tfp410.o
  CHECK   drivers/gpu/drm/i915/dvo_sil164.c
  CC [M]  drivers/gpu/drm/i915/dvo_sil164.o
  CHECK   drivers/gpu/drm/i915/dvo_ns2501.c
  CC [M]  drivers/gpu/drm/i915/dvo_ns2501.o
  CHECK   drivers/gpu/drm/i915/i915_gem_dmabuf.c
  CC [M]  drivers/gpu/drm/i915/i915_gem_dmabuf.o
  CHECK   drivers/gpu/drm/i915/i915_ioc32.c
  CC [M]  drivers/gpu/drm/i915/i915_ioc32.o
  CHECK   drivers/gpu/drm/i915/intel_acpi.c
  CC [M]  drivers/gpu/drm/i915/intel_acpi.o
  LD [M]  drivers/gpu/drm/i915/i915.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      drivers/gpu/drm/i915/i915.mod.o
  LD [M]  drivers/gpu/drm/i915/i915.ko

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Reported-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And use it whenever we call code that uses the DDIs. We already have
intel_ddi.c and prefix every function with intel_ddi_something instead of
haswell_something, so I think replacing the checks with HAS_DDI makes more
sense. Just a cosmetical change, yes I know, but I have this OCD...
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Yeah, all users (both the clock selection special cases and the lvds
pin pair stuff) are still in common code, but this will change.

v2: Rebase on top of Jani Nikula's panel rework.

v3: Incorporate review from Paulo Zanoni:
- s/__is_dual_link_lvds/compute_is_dual_link_lvds
- kill dev_priv->lvds_val
- drop spurious whitespace change

v4: Add a debug printk to display the dual-link status, as suggested
by Paulo Zanoni in review.

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

Should be useful to know what the driver thought the other ring's seqno
was when it last used a semaphore.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Based on the work by Mika Kuoppala, we realised that we need to handle
seqno wraparound prior to committing our changes to the ring. The most
obvious point then is to grab the seqno inside intel_ring_begin(), and
then to reuse that seqno for all ring operations until the next request.
As intel_ring_begin() can fail, the callers must already be prepared to
handle such failure and so we can safely add further checks.

This patch looks like it should be split up into the interface
changes and the tweaks to move seqno wrapping from the execbuffer into
the core seqno increment. However, I found no easy way to break it into
incremental steps without introducing further broken behaviour.

v2: Mika found a silly mistake and a subtle error in the existing code;
inside i915_gem_retire_requests() we were resetting the sync_seqno of
the target ring based on the seqno from this ring - which are only
related by the order of their allocation, not retirement. Hence we were
applying the optimisation that the rings were synchronised too early,
fortunately the only real casualty there is the handling of seqno
wrapping.

v3: Do not forget to reset the sync_seqno upon module reinitialisation,
ala resume.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=863861
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [v2]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There seem to be indeed some awkwards machines around, mostly those
without OpRegion support, where the firmware changes the display hw
state behind our backs when closing the lid.

This force-restore logic has been originally introduced in

commit c1c7af60
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Sep 10 15:28:03 2009 -0700

    drm/i915: force mode set at lid open time

but after the modeset-rework we've disabled it in the vain hope that
it's no longer required:

commit 3b7a89fc
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Sep 17 22:27:21 2012 +0200

    drm/i915: fix OOPS in lid_notify

Alas, no.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54677
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434Tested-by: NKrzysztof Mazur <krzysiek@podlesie.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For now, this code is just used by the eDP AUX channel frequency.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to enable a special bit, otherwise none of the DP functions
requiring the PCH will work.

Version 2: store the PCH ID inside dev_priv, as suggested by Daniel
Vetter.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we always restore the HWS registers (both physical and GTT
virtual addresses) when re-initialising the rings, we can eliminate the
superfluous save/restore of the register across suspend and resume.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

drivers/gpu/drm/i915/i915_drv.h:1545:2: warning: '______f' is static but
declared in inline function 'i915_gem_chipset_flush' which is not static
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
dri-devel-Reference: <50a4d41c.586VhmwghPuKZbkB%fengguang.wu@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fixes a regression for SDVO from

commit fbfcc4f3
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: NChris 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: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NBen 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: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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=54089Signed-of-by: NJesse 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: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: move dev_priv->console_resume_work next to the fbdev
pointer.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pretty astonishing how far apart these two members landed ... Especially since
I've already removed almost 200 lines in between.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

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: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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=50233Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NAntti Koskipää <antti.koskipaa@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

After all relevant pipes are disabled and after we've updated all the
state with the staged state, but before we call the per-crtc
->mode_set functions there's a very natural point to set up any
shared/global resources like
- shared plls (obviously only the setup, the enabling needs to be
  separately handling with a separate refcount)
- global watermark state like the DSPARB on gmch platforms
- workaround bits that depend upon the exact global output
  configuration
- enabling the right set of refclocks
- enabling/disabling manual power wells.

Now for a lot of these things we can't move them into this function
yet, most often because we only compute the required information in
the per-crtc ->mode_set callback. Which is too late. But due to a
bunch of reasons (check-only atomic modeset, fastboot&hw state checks,
...) we need to separate the computation of that state from the actual
hw frobbery anyway. So we can move things into this new callback step-
by-step.

Others can't be moved here (or implemented at all) because our code
lacks the smarts to properly update them. E.g. the DSPARB can only be
updated when all pipes are disabled, so if we decide to change it's
value, we need to disable _all_ pipes. The infrastructure for that is
already in place (with the various pipe masks that driver the modeset
logic). But again we need to move a few things out of ->mode_set
first before we can even implement the correct decision making.

In any case, we need to start somewhere, so let's start with the
callback: Some small follow-up patches will make immediate good use of
it.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Before Haswell we used to have the CPU pipes and the PCH transcoders.
We had the same amount of pipes and transcoders, and there was a 1:1
mapping between them. After Haswell what we used to call CPU pipe was
split into CPU pipe and CPU transcoder. So now we have 3 CPU pipes (A,
B and C), 4 CPU transcoders (A, B, C and EDP) and 1 PCH transcoder
(only used for VGA).

For all the outputs except for EDP we have an 1:1 mapping on the CPU
pipes and CPU transcoders, so if you're using CPU pipe A you have to
use CPU transcoder A. When have an eDP output you have to use
transcoder EDP and you can attach this CPU transcoder to any of the 3
CPU pipes. When using VGA you need to select a pair of matching CPU
pipes/transcoders (A/A, B/B, C/C) and you also need to enable/use the
PCH transcoder.

For now we're just creating the cpu_transcoder definitions and setting
cpu_transcoder to TRANSCODER_EDP on DDI eDP code, but none of the
registers was ported to use transcoder instead of pipe. The goal is to
keep the code backwards-compatible since on all cases except when
using eDP we must have pipe == cpu_transcoder.

V2: Comment the haswell_crtc_off chunk, suggested by Damien Lespiau
and Daniel Vetter.

We currently need the haswell_crtc_off chunk because TRANSCODER_EDP
can be used by any CRTC, so when you stop using it you have to stop
saying you're using it, otherwise you may have at some point 2 CRTCs
claiming they're using TRANSCODER_EDP (a disabled CRTC and an enabled
one), then the HW state readout code will get completely confused.

In other words:

Imagine the following case:
  xrandr --output eDP1 --auto --crtc 0
  xrandr --output eDP1 --off
  xrandr --output eDP1 --auto --crtc 2

After the last command you could get a "pipe A assertion failure
(expected off, current on)" because CRTC 0 still claims it's using
TRANSCODER_EDP, so the HW state readout function will read it
(through PIPECONF) and expect it to be off, when it's actually on
because it's being used by CRTC 2.

So when we make "intel_crtc->cpu_transcoder = intel_crtc->pipe" we
make sure we're pointing to our own original CRTC which is certainly
not used by any other CRTC.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Get rid of saved int_lvds_connector and int_edp_connector in
drm_i915_private.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk>

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some BIOSes may forcibly suspend RC6 during their operation which
trigger a warning as we find the hardware in a perplexing state upon
first use. So far that appears to be the worst symptom as fortuituously
we use the same values as the BIOS for programming the FORCEWAKE register.
Reported-by: NOleksij Rempel <bug-track@fisher-privat.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On the worst scenario, users with new hardwares and old kernel from
enabling times can get black screens.  So, from now on, this
perliminary_hw_support module parameter shall be used by all upcoming
platforms that are still under enabling. The second option would be to
merge the pci ids after basic modeset works, but that makes testing
and development while bringing up hw a rather tedious afair.

Although it is uncomfortable for developers use this extra variable it
brings more stability for end users.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NDave Airlie <airlied@redhat.com>
[danvet: dropped the i915_ param prefix, i915.i915_ is just tedious.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is a special mechanism for communicating with the PCU already
being used for the ring frequency stuff. As we'll be needing this for
other commands, extract it now to make future code less error prone and
the current code more reusable.

I'm not entirely sure if this code matches 1:1 with the previous code
behaviorally. Functionally however, it should be the same.

CC: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Fixup compile fail reported by Wu Fengguang.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Note that just because we have n == MAX elements left, does not imply
that there are only MAX elements left in the scatterlist and so we may
not be on the last chain, and the nth element may in fact be a chain ptr.

This is exercised by the improved hangman tests and the gem_exec_big
test in i-g-t.

This regression has been introduced in

commit 9da3da66
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jun 1 15:20:22 2012 +0100

   drm/i915: Replace the array of pages with a scatterlist

v2: KISS, replace the direct lookup with a for_each_sg() [danvet]
v3: Try to be clever again.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The intention was to allow the caller to avoid a failure to queue a
request having already written commands to the ring. However, this is a
moot point as the i915_add_request() can fail for other reasons than a
mere allocation failure and those failure cases are more likely than
ENOMEM. So the overlay code already had to handle i915_add_request()
failures, and due to

commit 3bb73aba
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 20 12:40:59 2012 +0100

    drm/i915: Allow late allocation of request for i915_add_request()

the error handling code in intel_overlay.c was subject to causing
double-frees, as found by coverity.

Rather than further complicate i915_add_request() and callers, realise
the battle is lost and adapt intel_overlay.c to take advantage of the
late allocation of requests.

v2: Handle callers passing in a NULL seqno.
v3: Ditto. This time for sure.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Problems with the previous code:
  - HDMI just uses WRPLL1 for everything, so dual head cases might not
    work sometimes.
  - At encoder->mode_set we just write the PLL register without doing
    any kind of check (e.g., check if the PLL is already being used).
  - There is no way to fail and return error codes at
    encoder->mode_set.
  - We write to PORT_CLK_SEL at mode_set and we never disable it.
  - Machines hang due to wrong clock enable/disable sequence.

So here we rewrite the code, making it a little more like the
pre-Haswell PLL mode set code:
  - Check PLL availability at ironlake_crtc_mode_set.
  - Try to use both WRPLLs.
  - Check if PLLs are used before actually trying to use them, and
    properly fail with error messages.
  - Enable/disable PORT_CLK_SEL at the right place.
  - Add some WARNs to check for bugs.

The next improvement will be to try to reuse PLLs if the timings
match, but this is content for another patch and it's already
documented with a TODO comment.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

round_jiffies() aligns the wakeup time to the nearest second in order to
batch wakeups and reduce system load, which is useful for unimportant
coarse timers like our hangcheck.

v2: round_jiffies_relative() returns the relative jiffie value, whereas
we need the absolute value for the timer.
Suggested-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

By providing a callback for when we need to bind the pages, and then
release them again later, we can shorten the amount of time we hold the
foreign pages mapped and pinned, and importantly the dmabuf objects then
behave as any other normal object with respect to the shrinker and
memory management.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Magic numbers are bad mmmkay. In this case in particular the value is
especially weird because the docs say multiple things. We'll need this
value for sysfs, so extracting it is useful for that as well.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rather than have multiple data structures for describing our page layout
in conjunction with the array of pages, we can migrate all users over to
a scatterlist.

One major advantage, other than unifying the page tracking structures,
this offers is that we replace the vmalloc'ed array (which can be up to
a megabyte in size) with a chain of individual pages which helps reduce
memory pressure.

The disadvantage is that we then do not have a simple array to iterate,
or to access randomly. The common case for this is in the relocation
processing, which will typically fit within a single scatterlist page
and so be almost the same cost as the simple array. For iterating over
the array, the extra function call could be optimised away, but in
reality is an insignificant cost of either binding the pages, or
performing the pwrite/pread.

v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the
trivial compile error from rebasing.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>