Previously when converting the GMBUS pin to the GPIO reg, we would
offset the pin by one and then use the look-up table. Now that we first
try to use the GMBUS pin, we no longer need the offset and can use the
value from the VBIOS directly.
Reported-by: NCarlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Otherwise we will hit a list handling assertion when moving the object
to the inactive list.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

During i915_gem_create_mmap_offset() if the subsystem reports an error
code, use it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we do not wait for the panel to turn off when we need to adjust the
panel-fitting registers we also need to unlock the PLLs as with the
non-pfit update path.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In order to handle disable_functions() where the framebuffer is
decoupled from the crtc we need to unpin the fb in order to prevent a
leak.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29857Reported-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Suspending (especially hibernating) may take a finite amount of time,
during which a hotplug event may trigger and we will attempt to handle
it with inconsistent state. Disable hotplug polling around suspend and
resume.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30070Reported-by: NRui Tiago Matos <tiagomatos@gmail.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The old code didn't clean up the i830 chipset flush page. And it
looks nicer.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Storing this explicitly makes for clearer code and hopefully
less further confusion.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Consolidate everything in intel-gtt.c and also kill the export
of intel_max_stolen.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

DMA remapping was only used by the intel-gtt driver. With that
code now folded into the driver, kill the agp generic support for
it.

Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

They're now all the same.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This is the last differentiator between the different fake agp drivers.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

That indirection mess can now go. Add a dummy i81x gtt_driver to
avoid a NULL pointer check.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Like before, but now with the added bonus of being able to kill
quite a bit of no-longer userful code (the old dmar support stuff).
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Like for the i915.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Beef up the generic version to support dmar. Otherwise like for the i830.

v2: Don't try to DMA remap on resume for already remapped pages.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Well, not all too generic because it does not yet support dmar.
Add a new function check_flags to ensure that non-gem code does
not try to screw us over.

v2: Beautify i830_check_flags with an idea from Chris Wilson.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Only used to remap the scratch page. Now that intel-gtt does this
itself, kill the support code.

Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

intel-gtt.c now handles the scratch page itself, so drop all that
was just there to support it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Like for i830. intel_i9xx_configure is now unused, so kill it.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Like for the i830.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

And put it to use in the gtt configuration code that writes
the scratch page addr in all gtt ptes. This makes intel_i830_configure
generic, hence rename it to intel_fake_agp_configure.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The intel gtt fake agp driver is the only agp driver to use dma
address remapping. So it makes sense to fold this code back into the
only user (and thus reduce the reliance on the agp code).

This patch does the first step by initializing (and remapping) the
scratch page in a new function intel_gtt_setup_scratch_page.
Unfortunately intel_gtt_cleanup had to move to avoid a forward
declaration. The new scratch page is not yet used, though.

v2: Refactor out scratch page teardown.  Suggested by Chris Wilson on
irc. This makes it clear what's going on and results in a nice
symmetry between setup and teardown.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Keep a list of pinned objects and display it via debugfs. Now all
objects that exist in the GTT are always tracked on one of the
active, flushing, inactive or pinned lists.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

If we have queued a page flip on the current fb and then request a mode
change, wait until the page flip completes before performing the new
request.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Track if the gpu requires the fence for the execution of a batch buffer
and so only wait upon the retirement of the object's last rendering
seqno if the fence is in use by the GPU.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Always PAGE_SIZE and only complicates the code.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The compiler happily does that for us.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

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

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

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

Documentation explicitly mentions that the ring registers are
designed to have the same offsets relative to a base registers.

Use this to fight the code beaurocratic in intel_ringbuffer.c.

No code changes in this patch, just the new definitions.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This looks like a copy-paste remnant from the i810. All the regs
that are actually used are already defined somewhere else in i915_reg.h!
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Use the ring abstraction to hide the details of having choose the
appropriate flushing method.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This ring buffer is used for video decoding/encoding on Sandybridge.
Signed-off-by: NXiang, Haihao <haihao.xiang@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>