drm/i915: add LCPLL control registers

Those are used to control the display core clock.

v2: change the enable bit setting, spotted by Rodrigo Vivi.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add SSC offsets for SBI access

Different registers are identified by their target id and offset. To
simplify their programming, they are called as <RegisterName><TargetId>.
For example, SSCCTL register accessed through SBI at target id 6 and
offset 0c is called SBI_SSCCTL6.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add port clock selection support for HSW

Multiple clocks can drive different outputs.

v2: use the port enums to access individual ports

v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add S PLL control

This PLL control can drive DDI ports at desired frequencies for
DisplayPort and FDI connections.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add PIXCLK_GATE register

Pixel clock gating control for Lynx point.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add SBI registers

Those are responsible for the Sideband Interface programming.

v2: rename SBI bits to better reflect their meaning

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add definition of DDI buffer translations regs

Those registers are used to train DDI buffer translations for each link
type.

v2: access each port registers through the DDI_BUF_TRANS macro

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add definitions for DDI_BUF_CTL registers

There is one instance of those registers for each DDI port.

v2: access registers via the DDI_BUF_CTL() macro

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add DP_TP_STATUS registers

There is one set of those registers for each port.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add DP_TP_CTL registers

This is one set of those registers for each pipe.

v2: use port enum to access individual registers

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add DDI registers

There is one set of such registers for each pipe (A/B/C/EDP).

v2: update to use DDI PORTS enum

v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add enumeration for DDI ports

There are 5 DDI ports on Haswell. Port A is always enabled, and is the one
connected to eDP, and Port E is the one that can be connected to the PCH
using FDI protocol.  Ports B, C, D and E can be used for digital outputs.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add support for power wells

This defines the registers used by different power wells.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add support for LynxPoint PCH

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add Haswell devices and their PCI IDs

This adds product definitions for desktop, mobile and server boards.

v2: split into a separate patch, add .has_pch_split feature.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: transform HAS_PCH_SPLIT in a feature check

The macro is becoming too complex and with VLV upon us it can lead to
confusion. So transforming this into a feature check instead.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: fixed conflict with is_valleyview addition.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: check for disabled interrupts on ValleyView

Haven't seen this yet, but it doesn't hurt.

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

drm/i915: ValleyView IRQ support

ValleyView has a new interrupt architecture; best to put it in a new set
of functions.  Also make sure the ring mask functions handle ValleyView.

FIXME: fix flipping; need to enable interrupts and call prepare/finish

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

drm/i915: interrupt bit definitions for VLV

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

drm/i915: add ValleyView specific force wake get/put functions

ValleyView handles force wake differently than previous chipsets, so add
a couple of new functions for it.  But leave it disabled by default
until we test it (need a chip with the Punit enabled first).

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

agp/intel: add ValleyView AGP driver

... and bind it right to the PCI id.

Note that there are still a few things to fix here:
- we need to move the tlb flush to a better place in drm/i915.
- we need to check snoop support on vlv and implement it.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: squash follow-on patch and add todo items to commit msg.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

agp/intel: map more registers for use by the GTT code

We need to flush the Gunit TLB when we update GTT PTEs on VLV, but the
register for doing so is above the range we normally map.  Map the whole
register space to make sure we can get it.

v2: only map the larger space on gen7+ (Daniel)

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

drm/i915: Enable HDMI on ValleyView

HDMI register offsets are different in Valleyview. Add support for the
same.

v2: drop superfluous comments in HDMI init (Daniel)

Signed-off-by: Beeresh G <beeresh.g@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: program drain latency regs on ValleyView

This patch adds support for programming drain latency registers of Pondicherry
memory arbiter of Valleyview.

v2: clarify function names (Daniel)
    fix summary typo (Daniel)
v3: add parens (Ben)
    make drain function return bool (Ben)

Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Reviewed-by: Jesse Barnes <jesse.barnes@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add ValleyView clock gating init

Set required clock gating and chicken bits on VLV.

v2: set PIXEL_SUBSPAN_COLLECT_OPT_DISABLE too (Ben)
    move function below ivb version to pretend to be consistent (Ben)

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

drm/i915: add DPIO support

ValleyView puts some display related registers like the PLL controls and
dividers behind the DPIO bus.  Add simple indirect register access
routines to get to those registers.

v2: move new wait_for macro to intel_drv.h (Ben)
    fix DPIO_PKT double write (Ben)
    add debugfs file

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

drm/i915: PLL defines for VLV

Add register definitions for the new VLV PLL bits.

v2: remove unused bits & regs (Ben)

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

drm/i915: ValleyView watermark support

Add support for ValleyView watermark handling.

v2: remove unused reg & bit definitions (Ben)

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

drm/i915: add ValleyView driver structs and IS_VALLEYVIEW macro

For use by the rest of the ValleyView code.

v2: fix desktop variant to not set is_mobile (Ben)

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

drm/i915: split PLL update code out of i9xx_crtc_mode_set

Makes it more readable and maintainable.  ValleyView will add its own
PLL update function in a later patch.

v2: split LVDS bits out of this patch (Daniel)
v3: fix dropped DP dithering hunk (Daniel)

Acked-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
danvet:
- fixup spurious whitespace change
- reorder patches to fix bisect breakage
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: split LVDS update code out of i9xx_crtc_mode_set

Just to make things clearer and reduce the size of this monstrosity.

v2: make sure 8xx PLL update function calls update_lvds too (Daniel)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
danvet: fixed patch ordering to avoid breaking bisect.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Initialise GTT MTRR to -1

Fixes a regression from 9e984bc1 (drm/i915: Don't do MTRR setup if PAT
is enabled) where we left the MTRR as 0 and so tried to free a MTRR we
did not own during unload.

Reported-and-tested-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private

This memory is always allocated, and it is always a fixed size, so just
allocate it along with the rest of the driver state.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/intel_i2c: gmbus disabled and reserved ports are invalid

There is no GMBUS "disabled" port 0, nor "reserved" port 7.
For the other 6 ports there is a fixed 1:1 mapping between pin pairs and
gmbus ports, which means every real gmbus port has a gpio pin.

Given these realizations, clean up gmbus initialization.

Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter

Instead of letting other modules directly access the ->gmbus array,
introduce intel_gmbus_get_adapter() for looking up an i2c_adapter
for a given gmbus port identifier.  This will enable later refactoring
of the gmbus port list.

Note: Before requesting an adapter for a given gmbus port number, the
driver must first check its validity using i2c_intel_gmbus_is_port_valid().
If this check fails, a call to intel_gmbus_get_adapter() will WARN_ON and
return NULL.  This is relevant for parts of the driver that read a port
from VBIOS, which might be improperly initialized and contain an invalid
port.  In these cases, the driver must fall back to using a safer default
port.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

Instead of rolling our own custom quirk_xfer function, use the bit_algo
pre_xfer and post_xfer functions to setup and teardown bit-banged
i2c transactions.

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

drm/i915/intel_i2c: assign HDMI port D to pin pair 6

According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
Pin pair 7 is a reserved pair.

[1] Documentation for [DevSNB+] and [DevIBX], as found on
http://intellinuxgraphics.org:

[DevSNB+]:
http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf
 Section 2.2.2 lists the 6 gmbus ports (gpio pin pairs):
    [ 5: HDMI/DPD, 4: HDMIB, 3: HDMI/DPC, 2: LVDS, 1: SSC, 0: VGA ]
 2.2.2.1 lists the GPIO registers to control these 6 ports.
 2.2.3.1 lists the mapping between 5 of these gmbus ports and the 3
 Pin_Pair_Select bits (of the GMBUS0 register).  This table is missing
 HDMIB (port 101).

[DevIBX]: http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf
 Section 2.2.2 lists the same 6 gmbus ports plus two 'reserved' gpio
 ports.
 2.2.2.1 lists 8 GPIO registers... however, it says the size of the
 block is 6x32, which implies that those 2 reserved GPIO registers
 (GPIO_6 & GPIO_7) don't actually exist (or are irrelevant).
 2.2.3.1 lists the mapping between the 6 named gmbus ports and the 3
 Pin_Pair_Select bits (of the GMBUS0 register).  This table has HDMIB.

Note: the "reserved" and "disabled" pairs do not actually map to a
physical pair of pins, nor GPIO regs and shouldn't be initialized or used.
Fixing this is left for a later patch.

This bug had not been noticed earlier for two reasons:
 1) Until recently, "gmbus" mode was disabled - all transfers actually
    used "bit-bang" mode on GPIO port 5 (the "HDMI/DPD CTLDATA/CLK"
    pair), at register 0x5024 (defined as GPIOF i915_reg.h).
    Since this is the correct pair of pins for HDMI1, transfers succeed.

 2) Even if gmbus mode is re-enabled, the first attempted transaction
    will fail because it tries to use the wrong ("Reserved") pin pair.
    However, the driver immediately falls back again to the bit-bang
    method, which correctly uses GPIOF, so again, transfers succeed.

However, if gmbus mode is re-enabled and the GPIO fall-back mode is
disabled, then reading an attached monitor's EDID fail.

Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915/intel_i2c: cleanup error messages and comments

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

drm/i915/intel_i2c: refactor gmbus_xfer

Split out gmbus_xfer_read/write() helper functions.

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

drm/i915: mark pwrite/pread slowpaths with unlikely

Beside helping the compiler untangle this maze they double-up as
documentation for which parts of the code aren't performance-critical
but just around to keep old (but already dead-slow) userspace from
breaking.

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

drm/i915: fixup in-line clflushing on bit17 swizzled bos

The issue is that with inline clflushing the clflushing isn't properly
swizzled. Fix this by
- always clflushing entire 128 byte chunks and
- unconditionally flush before writes when swizzling a given page.
  We could be clever and check whether we pwrite a partial 128 byte
  chunk instead of a partial cacheline, but I've figured that's not
  worth it.

Now the usual approach is to fold this into the original patch series, but
I've opted against this because
- this fixes a corner case only very old userspace relies on and
- I'd like to not invalidate all the testing the pwrite rewrite has gotten.

This fixes the regression notice by tests/gem_tiled_partial_prite_pread
from i-g-t. Unfortunately it doesn't fix the issues with partial pwrites to
tiled buffers on bit17 swizzling machines. But that is also broken without
the pwrite patches, so likely a different issue (or a problem with the
testcase).

v2: Simplify the patch by dropping the overly clever partial write
logic for swizzled pages.

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

mm: extend prefault helpers to fault in more than PAGE_SIZE

drm/i915 wants to read/write more than one page in its fastpath
and hence needs to prefault more than PAGE_SIZE bytes.

Add new functions in filemap.h to make that possible.

Also kill a copy&pasted spurious space in both functions while at it.

v2: As suggested by Andrew Morton, add a multipage parameter to both
functions to avoid the additional branch for the pagemap.c hotpath.
My gcc 4.6 here seems to dtrt and indeed reap these branches where not
needed.

v3: Becaus I couldn't find a way around adding a uaddr += PAGE_SIZE to
the filemap.c hotpaths (that the compiler couldn't remove again),
let's go with separate new functions for the multipage use-case.

v4: Adjust comment to CodingStlye and fix spelling.

Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: extract copy helpers from shmem_pread|pwrite

While moving around things, this two functions slowly grew out of any
sane bounds. So extract a few lines that do the copying and
clflushing. Also add a few comments to explain what's going on.

v2: Again do s/needs_clflush/needs_clflush_after/ in the write paths
as suggested by Chris Wilson.

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

drm/i915: use uncached writes in pwrite

It's around 20% faster.

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

drm/i915: fall back to shmem pwrite when the buffer is not accessible

It's too expensive to move it around just for that pwrite, especially
when we're trashing on the mappable gtt part like crazy.

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

drm/i915: implement inline clflush for pwrite

In micro-benchmarking of the usual pwrite use-pattern of alternating
pwrites with gtt domain reads from the gpu, this yields around 30%
improvement of pwrite throughput across all buffers size. The trick is
that we can avoid clflush cachelines that we will overwrite completely
anyway.

Furthermore for partial pwrites it gives a proportional speedup on top
of the 30% percent because we only clflush back the part of the buffer
we're actually writing.

v2: Simplify the clflush-before-write logic, as suggested by Chris
Wilson.

v3: Finishing touches suggested by Chris Wilson:
- add comment to needs_clflush_before and only set this if the bo is
  uncached.
- s/needs_clflush/needs_clflush_after/ in the write paths to clearly
  differentiate it from needs_clflush_before.

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

drm/i915: don't clobber userspace memory before commiting to the pread

The pagemap.h prefault helpers do the prefaulting by simply writing
some data into every page. Hence we should not prefault when we're not
yet commited to to actually writing data to userspace. The problem is
now that
- we can't prefault while holding dev->struct_mutex for we could
  deadlock with our own pagefault handler
- we need to grab dev->struct_mutex before copying to sync up with any
  outsanding gpu writes.

Therefore only prefault when we're dropping the lock the first time in
the pread slowpath - at that point we're committed to the write, don't
wait on the gpu anymore and hence won't return early (with e.g.
-EINTR).

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

drm/i915: drop gtt slowpath

With the proper prefault, it's extremely unlikely that we fall back
to the gtt slowpath.

So just kill it and use the shmem_pwrite path as fallback.

To further clean up the code, move the preparatory gem calls into the
respective pwrite functions. This way the gtt_fast->shmem fallback
is much more obvious.

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

drm/i915: don't call shmem_read_mapping unnecessarily

This speeds up pwrite and pread from ~120 µs ro ~100 µs for
reading/writing 1mb on my snb (if the backing storage pages
are already pinned, of course).

v2: Chris Wilson pointed out a glaring page reference bug - I've
unconditionally dropped the reference. With that fixed (and the
associated reduction of dirt in dmesg) it's now even a notch faster.

v3: Unconditionaly grab a page reference when dropping
dev->struct_mutex to simplify the code-flow.

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

drm/i915: don't use gtt_pwrite on LLC cached objects

~120 µs instead fo ~210 µs to write 1mb on my snb. I like this.

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

drm/i915: kill ranged cpu read domain support

No longer needed.

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

drm/i915: move clflushing into shmem_pread

This is obviously gonna slow down pread. But for a half-way realistic
micro-benchmark, it doesn't matter: Non-broken userspace reads back
data from the gpu once before the gpu again dirties it.

So all this ranged clflush tracking is just a waste of time.

No pread performance change (neglecting the dumb benchmark of
constantly reading the same data) measured.

As an added bonus, this avoids clflush on read on coherent objects.
Which means that partial preads on snb are now roughly 4x as fast.
This will be usefull for e.g. the libva encoder - when I finally get
around to fix that up.

v2: Properly sync with the gpu on LLC machines.

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

drm: add helper to clflush a virtual address range

Useful when the page is already mapped to copy date in/out.

For -stable because the next patch (fixing phys obj pwrite) needs this
little helper function.

Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: merge shmem_pread slow&fast-path

With the previous rewrite, they've become essential identical.

v2: Simplify the page_do_bit17_swizzling logic as suggested by Chris
Wilson.

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

drm/i915: merge shmem_pwrite slow&fast-path

With the previous rewrite, they've become essential identical.

v2: Simplify the page_do_bit17_swizzling logic as suggested by Chris
Wilson.

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

drm/i915: Avoid using mappable space for relocation processing through the CPU

We try to avoid writing the relocations through the uncached GTT, if the
buffer is currently in the CPU write domain and so will be flushed out to
main memory afterwards anyway. Also on SandyBridge we can safely write
to the pages in cacheable memory, so long as the buffer is LLC mapped.
In either of these cases, we therefore do not need to force the
reallocation of the buffer into the mappable region of the GTT, reducing
the aperture pressure.

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

drm/i915: clear the entire gtt when using gem

We've lost our guard page somewhere in the gtt rewrite, this patch
here will restore it.

Exercised by i-g-t/tests/gem_cs_prefetch.

v2: Substract the guard page from the range we're supposed to manage
with gem. Suggested by Chris Wilson to increase the odds of old ums +
gem userspace not blowing up. To compensate for the loss of a page,
don't substract the guard page in the modeset init code any longer.

Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44748
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: the intel gtt is _not_ an agp bridge!

So don't call it like that.

Also rip out a confusing comment and instead explain what's really
going on.

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

drm/i915: s/i915_gem_do_init/i915_gem_init_global_gtt

... because this is what it actually doesn now that we have the global
gtt vs. ppgtt split.

Also move it to the other global gtt functions in i915_gem_gtt.c

Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: reinstate GM45 TV detection fix

This reverts commmit d4b74bf07873da2e94219a7b67a334fc1c3ce649 which
reverted the origin fix fb8b5a39b6310379d7b54c0c7113703a8eaf4a57.

We have at least 3 different bug reports that this fixes things and no
indication what is exactly wrong with this. So try again.

To make matters slightly more fun, the commit itself was cc: stable
whereas the revert has not been.

According to Peter Clifton he discussed this with Zhao Yakui and this
seems to be in contradiction of the GM45 PRM, but rumours have it that
this is how the BIOS does it ... let's see.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Tested-by: Peter Clifton <Peter.Clifton@clifton-electronics.com>
Cc: Zhao Yakui <yakui.zhao@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16236
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=25913
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=14792
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Batch copy_from_user for relocation processing

Originally the code tried to allocate a large enough array to perform
the copy using vmalloc, performance wasn't great and throughput was
improved by processing each individual relocation entry separately.
This too is not as efficient as one would desire. A compromise would be
to allocate a single page, or to allocate a few entries on the stack,
and process the copy in batches. The latter gives simpler code and more
consistent performance due to a lack of heuristic.

x11perf -copywinwin10: n450/pnv i3-330m i5-2520m (cpu)
               before:    249000  785000  1280000 (80%)
                 page:   264000  896000  1280000 (65%)
             on-stack:   264000  902000  1280000 (67%)

v2: Use 512-bytes of stack for batching rather than allocate a page.
v3: Tidy the code slightly with more descriptive variable names

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

drm/i915: enable gmbus on gen2

With the recent set of gmbus fixes, this seems to work on my i855gm.

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

drm/i915: add an explict mmio base for gpio/gmbus io

Again, Valleyview modes these around, so make the mmio base more
explicit to consolidate the base address computations to one
HAS_PCH_SPLIT check.

v2: Fix up the PCH_SPLIT braino ... it actually works that way round.

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

drm/i915/sdov: switch IS_SDVOB to a flag

With valleyview we'll have these at yet another address, so keeping
track of this with an ever-growing list of registers will get ugly.

This way intel_sdvo.c is fully independent of the base address of the
output ports display register blocks.

While at it, do 2 closely related cleanups:
- use SDVO_NAME some more
- change the sdvo_reg variables to uint32_t like other registers.

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

drm/i915: re-order GT IIR bit definitions

They were all over the place, order them by position and add a few.

v2: add gen indications to the new bits (Ben)

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

drm/i915: move NEEDS_FORCE_WAKE to i915_drv.c

It's only used by the main read/write functions, so we can keep it with
them.

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

drm/i915: Release the mmap offset when purging a buffer

If we discard a buffer due to memory pressure, also release its alloted
mmap address space. As it may be sometime before userspace wakes up
and notices that it has buffers to purge from its cache, we may waste
valuable address space on unusable objects for a period of time.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47738
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add lvds_channel module option

Add a new module optoin lvds_channel to specify the LVDS channel mode
explicitly instead of probing the LVDS register value set by BIOS.
This will be helpful when VBT is broken or incompatible with the
current code.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42842
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Check VBIOS value for determining LVDS dual channel mode, too

Currently i915 driver checks [PCH_]LVDS register bits to decide
whether to set up the dual-link or the single-link mode.  This relies
implicitly on that BIOS initializes the register properly at boot.
However, BIOS doesn't initialize it always.  When the machine is
booted with the closed lid, BIOS skips the LVDS reg initialization.
This ends up in blank output on a machine with a dual-link LVDS when
you open the lid after the boot.

This patch adds a workaround for that problem by checking the initial
LVDS register value in VBT.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37742
Tested-By: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: [dinq] shut up six instances of -Warray-bounds

Introduced in commits c1cd90ed and d27b1e0e

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: s/fix/shut up in the commit msg and add a comment to the
BUG_ON.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: [dinq] shut up two instances -Wunitialized

Introduced in commit 8461d226 and 8c59967c

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: s/fix/shut up/ in the commit msg.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add HAS_ALIASING_PPGTT parameter for userspace

On Sanybridge a few MI read/write commands only work when ppgtt is
enabled.  Userspace therefore needs to be able to check whether ppgtt
is enabled. For added hilarity, you need to reset the "use global GTT"
bit on snb when ppgtt is enabled, otherwise it won't work.  Despite
what bspec says about automatically using ppgtt ...

Luckily PIPE_CONTROL (the only write cmd current userspace uses) is
not affected by all this, as tested by tests/gem_pipe_control_store_loop.

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

drm/i915: enable lazy global-gtt binding

Now that everything is in place, only bind to the global gtt
when actually required. Patch split-up suggested by Chris Wilson.

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

drm/i915: implement SNB workaround for lazy global gtt

PIPE_CONTROL on snb needs global gtt mappings in place to workaround a
hw gotcha. No other commands need such a workaround. Luckily we can
detect a PIPE_CONTROL commands easily because they have a write_domain
= I915_GEM_DOMAIN_INSTRUCTION (and nothing else has that).

v2: Binding the target of such a reloc into the global gtt actually
works instead of binding the source, which is rather pointless ...

v3: Kill a superflous has_global_gtt_mapping assignement noticed by
Chris Wilson.

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

drm/i915: bind objects to the global gtt only when needed

And track the existence of such a binding similar to the aliasing
ppgtt case. Speeds up binding/unbinding in the common case where we
only need a ppgtt binding (which is accessed in a cpu coherent fashion
by the gpu) and no gloabl gtt binding (which needs uc writes for the
ptes).

This patch just puts the required tracking in place.

v2: Check that global gtt mappings exist in the error_state capture
code (with Chris Wilson's llc reloc patches batchbuffers are no longer
relocated as mappable in all situations, so this matters). Suggested
by Chris Wilson.

v3: Adapted to Chris' latest llc-reloc patches.

v4: Fix a bug in the i915 error state capture code noticed by Chris
Wilson.

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

drm/i915: split out dma mapping from global gtt bind/unbind functions

Note that there's a functional change buried in this patch wrt the ilk
dmar workaround: We now only idle the gpu while tearing down the dmar
mappings, not while clearing the gtt. Keeping the current semantics
would have made for some really ugly code and afaik the issue is only
with the dmar unmapping that needs a fully idle gpu.

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

i915: Add and use pr_fmt and pr_<level>

Use a more current logging style.  Ensure that appropriate
logging messages are prefixed with "i915: ".

Convert printks to pr_<level>.  Align arguments.

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: panel: invert brightness acer aspire 5734z

Mark the Acer Aspire 5734Z that this machines requires the module to
invert the panel backlight brightness value after reading from and prior
to writing to the PCI configuration space.

Signed-off-by: Carsten Emde <C.Emde@osadl.org>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: panel: invert brightness via quirk

A machine may need to invert the panel backlight brightness value. This
patch adds the infrastructure for a quirk to do so.

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

drm/i915: panel: invert brightness via parameter

Following the documentation of the Legacy Backlight Brightness (LBB)
Register in the configuration space of some Intel PCI graphics adapters,
setting the LBB register with the value 0x0 causes the backlight to be
turned off, and 0xFF causes the backlight to be set to 100% intensity
(http://download.intel.com/embedded/processors/Whitepaper/324567.pdf).
The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets
it to maximum intensity at 0. In consequence, the screen of this systems
becomes dark at an early boot stage which makes it unusable. The same
inversion applies to the BLC_PWM_CTL I915 register. This problem was
introduced in kernel version 2.6.38 when the PCI device of this system
was first supported by the i915 KMS module.

This patch adds a parameter to the i915 module to enable inversion of
the brightness variable (i915.invert_brightness).

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

drm/i915: Add wait_for in init_ring_common

I have seen a number of "blt ring initialization failed" messages
where the ctl or start registers are not the correct value. Upon further
inspection, if the code just waited a little bit, it would read the
correct value. Adding the wait_for to these reads should eliminate the
issue.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Don't do MTRR setup if PAT is enabled

Some newer BIOSes are shipping with all MTRRs already populated.  These
BIOSes are all on machines with sufficiently new CPUs that the
referenced errata doesn't apply anyway, so just don't try to claim the
MTRR.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41648
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Pull MTRR setup to its own function

No functional change here, just clarifying code flow.

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Retry reading the PCH FDI receiver ISR

According to the PRM (Vol3P2), the PCH FDI receiver ISR read for bit lock
should be retried at least once. This patch retries the read 5 times
with a small delay in between reads. I've had reports of display corruption
on resume with "FDI train 1 fail!", so I'm hoping that adding this retry
will mitigate the issue.

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

drm/i915: remove ACPI related DRM_ERRORs

They're not really errors (well actually I don't know; I don't
understand _DSM and _MUX well enough to say, but I do know they spam
people's logs and seem to be harmless).

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: The _DSM error got remove in another patch already]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44250
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i915: Add option to bypass vbt table.

This change enables the use of displays where the vbt table just
contains inappropriate values, but either the vesa defaults or
the video=... modes do something sensible with the attached display.

The problem happens with an embedded board that contains vbt bios
tables that do not match the attached display.  Using this change and
the appropriate kernel boot command line they are able to use an
otherwise completely unusable secondary display on that embedded
board.

Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Mathias Froehlich <Mathias.Froehlich@web.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Only clear the GPU domains upon a successful finish

By clearing the GPU read domains before waiting upon the buffer, we run
the risk of the wait being interrupted and the domains prematurely
cleared. The next time we attempt to wait upon the buffer (after
userspace handles the signal), we believe that the buffer is idle and so
skip the wait.

There are a number of bugs across all generations which show signs of an
overly haste reuse of active buffers.

Such as:

  https://bugs.freedesktop.org/show_bug.cgi?id=29046
  https://bugs.freedesktop.org/show_bug.cgi?id=35863
  https://bugs.freedesktop.org/show_bug.cgi?id=38952
  https://bugs.freedesktop.org/show_bug.cgi?id=40282
  https://bugs.freedesktop.org/show_bug.cgi?id=41098
  https://bugs.freedesktop.org/show_bug.cgi?id=41102
  https://bugs.freedesktop.org/show_bug.cgi?id=41284
  https://bugs.freedesktop.org/show_bug.cgi?id=42141

A couple of those pre-date i915_gem_object_finish_gpu(), so may be
unrelated (such as a wild write from a userspace command buffer), but
this does look like a convincing cause for most of those bugs.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: reenable gmbus on gen3+ again

With the rework to merge the bit-banging fallback into the gmbus
i2c adapter we've gotten rid of the deadlock possibility that
originally lead to the disabling of this code.

This reverts the revert

commit 826c7e4147f902737b281e8a5a7d7aa33fd63316
Author: Jean Delvare <khali@linux-fr.org>
Date:   Sat Jun 4 19:34:56 2011 +0000

    Revert "drm/i915: Enable GMBUS for post-gen2 chipsets"

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=35572
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: i2c: unconditionally set up gpio fallback

This way we can simplify the setup and teardown a bit.

Because we don't actually allocate anything anymore for the force_bit
case, we can now convert that into a boolean.

Also and the functionality supported by the bit-banging together with
what gmbus can do, so that this doesn't randomly change any more.

v2: Chris Wilson noticed that I've mixed up && and & ...

v3: Clarify an if block as suggested by Eugeni Dodonov.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: merge gmbus and gpio i2c adpater into one

... and directly call the newly exported i2c bit-banging functions.

The code is still pretty convoluted because we only set up the gpio
i2c stuff when actually falling back, resulting in more complexity
than necessary. This will be fixed up in the next patch.

v2: Use exported i2c_bit_algo vtable instead of exported functions.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: merge struct intel_gpio into struct intel_gmbus

When we set up the gpio fallback, we always have a 1:1 relationship
with an intel_gmbus. Exploit that to store all gpio related data in
there, too. This is a preparation step to merge the tw i2c adapters
controlling the same bus into one.

Just mundane code-munging in this patch.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i2c: export bit-banging algo functions

i915 has a hw i2c controller (gmbus) but for a bunch of stupid reasons
we need to be able to fall back to the bit-banging algo on gpio pins.

The current code sets up a 2nd i2c controller for the same i2c bus using
the bit-banging algo. This has a bunch of issues, the major one being
that userspace can directly access this fallback i2c adaptor behind
the drivers back.

But we need to frob a few registers before and after using fallback
gpio bit-banging, so this horribly fails.

The new plan is to only set up one i2c adaptor and transparently fall
back to bit-banging by directly calling the xfer function of the bit-
banging algo in the i2c core.

To make that possible, export the 2 i2c algo functions.

v2: As suggested by Jean Delvare, simply export the i2c_bit_algo
vtable instead of the individual functions.

Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/nouveau: do a better job at hiding the NIH i2c bit-banging algo

I'd like to export the corresponding functions from the i2c core
so that I can use them in fallback bit-banging in i915.ko

v2: Adapt to new i2c export patch.

Cc: nouveau@lists.freedesktop.org
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add dev_priv to intel_gmbus

This way we can free up the bus->adaptor.algo_data pointer and make it
available for use with the bitbanging fallback algo.

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix single msg gmbus_xfers writes

gmbus_xfer with a single message (particularly a single message write) would
set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b,
No Index, Stop cycle. This would not start single message i2c transactions.

Also, gmbus_xfer done: will disable the interface without checking if
it is idle. In the case of writes, there will be no wait on status or delay
to ensure the write starts and completes before the interface is turned off.

Fixed the former issue by using the same cycle selection as used in the
I2C_M_RD for the write case.
GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0)
Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable.

Note from the grumpy d-i-n maintainer: The first hunk that changes the
gmbus read path is just cosmetics to align the code with the write
path.  I.e. the commit message above is slightly lying because the
first issue is _only_ with writes (and not simply "particularly").

Signed-off-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: error_buffer->ring should be signed

gcc seems to get uber-anal recently about these things.

Clarification from Dan Carpenter:

"Sorry, I should have said that it's not a gcc warning, it's a smatch
thing.  But also it's not uber-anal.  It's the exact level of anality
which is required to make the == -1 test work.  You can compare
unsigned int and longs to -1 and it works but for smaller types it
doesn't."

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Silence the error message from i915_wait_request()

This error message has since been superseded by the hangcheck, and does
not add any salient information beyond that already printed by hangcheck
discovering the GPU hang that lead to i915_wait_request() bombing out in
the first place.

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

drm/i915: use the new hdmi_force_audio enum more

While fixing up a merge conflict with drm-next I've noticed that we
use the same audio drm connector property also for dp and sdvo
outputs.

So put the new enum to some good use and convert these paths, too. The
HDMI_AUDIO_ prefix is a bit a misnomer. But at least for sdvo it makes
sense (and you can also connect a hdmi monitor with a dp->hdmi cable),
so I've decided to stick with it.

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

drm/i915: No need to search again after retiring requests

Retiring requests does not typically free up space in the aperture,
so the additional search is pointless.

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

drm/i915: Only bump refcnt on objects scheduled for eviction

Incrementing the reference count on all objects walked when searching
for space in the aperture is a non-neglible amount of overhead. In fact,
we only need to hold on to a reference for objects that we will evict,
so we can therefore delay the referencing until we find a suitable hole
and only add those objects that fall inside.

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