This reverts commit a7a75c8f.

There are two different variations on how Intel hardware addresses the
"Hardware Status Page". One as a location in physical memory and the
other as an offset into the virtual memory of the GPU, used in more
recent chipsets. (The HWS itself is a cacheable region of memory which
the GPU can write to without requiring CPU synchronisation, used for
updating various details of hardware state, such as the position of
the GPU head in the ringbuffer, the last breadcrumb seqno, etc).

These two types of addresses were updated in different locations of code
- one inline with the ringbuffer initialisation, and the other during
device initialisation. (The HWS page is logically associated with
the rings, and there is one HWS page per ring.) During resume, only the
ringbuffers were being re-initialised along with the virtual HWS page,
leaving the older physical address HWS untouched. This then caused a
hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried
to synchronise the GPU as the breadcrumbs were never being updated.
Reported-and-tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reported-by: NJan Niehusmann <jan@gondor.com>
Reported-and-tested-by: NJustin P. Mattock <justinmattock@gmail.com>
Reported-and-tested-by: NMichael "brot" Groh <brot@minad.de>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Early gen3 and gen2 chipset do not have the relaxed per-surface tiling
constraints of the later chipsets, so we need to check that the GTT
alignment is correct for the new tiling. If it is not, we need to
rebind.
Reported-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Andi Kleen narrowed his GPU hangs on his Sugar Bay (SNB desktop) rev 09
down to the use of GPU semaphores, and we already know that they appear
broken up to Huron River (mobile) rev 08. (I'm optimistic that disabling
GPU semaphores is simply hiding another bug by the latency and
side-effects of the additional device interaction it introduces...)

However, use of semaphores is a massive performance improvement... Only
as long as the system remains stable. Enable at your peril.
Reported-by: NAndi Kleen <andi-fd@firstfloor.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33921Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Whilst the GT is powered down (rc6), writes to MMADDR are placed in a
FIFO by the System Agent. This is a limited resource, only 64 entries, of
which 20 are reserved for Display and PCH writes, and so we must take
care not to queue up too many writes. To avoid this, there is counter
which we can poll to ensure there are sufficient free entries in the
fifo.

"Issuing a write to a full FIFO is not supported; at worst it could
result in corruption or a system hang."
Reported-and-Tested-by: NMatt Turner <mattst88@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34056Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It's cleaned before saving and re-initialized after restoring.
So don't need to save/restore it. And also new chip has new address
for hardware status page register, don't write to old address.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It is trivially computable from the real physical address so no need to
store both.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Using PM latency request turns out to be very fragile and only works for
some systems, depending upon the ACPI implementation. However, I've
stumbled across a promising bit in INSTPM: "Interrupt-Based AGPBUSY#".

This reverts commit b0b544cd.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In order to prevent "crushed blacks" on TVs, the range of the RGB output
may be limited to 16-235. This used to be available through Xorg under
the "Broadcast RGB" option, so reintroduce support for KMS.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34543Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The code paths for modesetting are growing in complexity as we may need
to move the buffers around in order to fit the scanout in the aperture.
Therefore we face a choice as to whether to thread the interruptible status
through the entire pinning and unbinding code paths or to add a flag to
the device when we may not be interrupted by a signal. This does the
latter and so fixes a few instances of modesetting failures under stress.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Seems like we are forever to be cursed with buggy firmware, so allow the
user to explicitly set the panel connection status.

Of secondary utility for cases where I run laptops with the lid closed,
but still want to configure the LVDS.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This reverts commit 633f2ea2 and the
attempted fix dcbe6f2b.

There is a single clock source used for both SSC (some LVDS and DP) and
non-SSC (VGA, DVI) outputs. So we need to be careful to only enable SSC
as necessary. However, fiddling with DREFCLK was causing DP links to be
dropped and we do not have a fix ready, so revert.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

The automatic powersaving feature is once again causing havoc, with 100%
reliable hangs on boot and resume on affected machines.
Reported-by: NFrancesco Allertsen <fallertsen@gmail.com>
Reported-by: NGui Rui <chaos.proton@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=28582Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We had some conversions over to the _PIPE macros, but didn't get
everything.  So hide the per-pipe regs with an _ (still used in a few
places for legacy) and add a few _PIPE based macros, then make sure
everyone uses them.

[update: remove usage of non-existent no-op macro]
[update 2: keep modesetting suspend/resume code, update to new reg names]
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: stylistic cleanups for checkpatch and taste]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

A lot of minor tweaks to fix the tracepoints, improve the outputting for
ftrace, and to generally make the tracepoints useful again. It is a start
and enough to begin identifying performance issues and gaps in our
coverage.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This is just an idea that might or might not be a good idea,
it basically adds two ioctls to create a dumb and map a dumb buffer
suitable for scanout. The handle can be passed to the KMS ioctls to create
a framebuffer.

It looks to me like it would be useful in the following cases:
a) in development drivers - we can always provide a shadowfb fallback.
b) libkms users - we can clean up libkms a lot and avoid linking
to libdrm_*.
c) plymouth via libkms is a lot easier.

Userspace bits would be just calls + mmaps. We could probably
mark these handles somehow as not being suitable for acceleartion
so as top stop people who are dumber than dumb.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Judging by comments in the BIOS, if the SDVO LVDS option h40 is enabled,
then we are supposed to query the real panel type via Int15. We don't do
this and so for the Sony Vaio VGC-JS210J which has otherwise default
values, we choose the wrong mode.

This patch adds a driver option, i915.vbt_sdvo_panel_type, which can be
used to override the value in the VBT.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33691Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

Instead of reporting EIO upfront in the entrance of an ioctl that may or
may not attempt to use the GPU, defer the actual detection of an invalid
ioctl to when we issue a GPU instruction. This allows us to continue to
use bo in video memory (via pread/pwrite and mmap) after the GPU has hung.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Rather than power cycling the panel when there are no bits to display,
use the VDD AUX bit to power the panel up just enough for DP AUX
transactions to work.  This prevents a bit of unnecessary ugliness as
mode sets occur on the panel.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Move the plane->mode config to the point of use rather than repeatedly
querying the same information.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

We can only utilize the stolen portion of the GTT if we are in sole
charge of the hardware. This is only true if using GEM and KMS,
otherwise VESA continues to access stolen memory.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Reported-by: NFrederic Weisbecker <fweisbec@gmail.com>
Tested-by: NJiri Olsa <jolsa@redhat.com>
Tested-by: NFrederic Weisbecker <fweisbec@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

For CRT and SDVO/HDMI, we need to use a normal, non-SSC, clock and so we
must clear any enabling bits left-over from earlier outputs. And also
seems to correct the LVDS panel on the Lenovo U160.

However, at one point, it did cause an "ERROR failed to disable
trancoder". So prolonged testing on top of Jesse's refactored and
error-checking CRTC logic is desired.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Move code around and invoke iomem annotation in a few more places in
order to silence sparse. Still a few more iomem annotations to go...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

945 class hardware has an interesting quirk in which the vblank
interrupt is not raised if the CPU is in a low power state. (We also
suspect that the memory bus is clocked to the CPU/c-state and not the
GPU so there are secondary starvation issues.) In order to prevent the
most obvious issue of the low of the vblank interrupt (stuttering
compositing that only updates when the mouse is moving) is to install a
PM QoS request to prevent low c-states whilst the GPU is active.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Admittedly, trusting ACPI or the BIOS at all to be correct is littered
with numerous examples where it is wrong. Maybe, just maybe, we will
have better luck using the ACPI OpRegion lid status...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

In order to workaround the issue with LVDS not working on the Lenovo
U160 apparently due to using the wrong SSC frequency, add an option to
disable SSC.
Suggested-by: NLukács, Árpád <lukacs.arpad@gmail.com>
Bugzillla: https://bugs.freedesktop.org/show_bug.cgi?id=32748Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

As the mappable portion of the aperture is always a small subset at the
start of the GTT, it is allocated preferentially by drm_mm. This is
useful in case we ever need to map an object later. However, if you have
a large object that can consume the entire mappable region of the
GTT this prevents the batchbuffer from fitting and so causing an error.
Instead allocate all those that require a mapping up front in order to
improve the likelihood of finding sufficient space to bind them.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

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

... in order to avoid a BUG() and potential unbounded waits.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Cleanup several aspects of the rc6 code:
  - misnamed intel_disable_clock_gating function (was only about rc6)
  - remove commented call to intel_disable_clock_gating
  - rc6 enabling code belongs in its own function (allows us to move the
    actual clock gating enable call back into restore_state)
  - allocate power & render contexts up front, only free on unload
    (avoids ugly lazy init at rc6 enable time)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: checkpatch cleanup]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Otherwise we may consume 20% of the CPU just handling IRQs whilst
rendering. Ouch.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

By tracking the current status of the backlight we can prevent recording
the value of the current backlight when we have disabled it. And so
prevent restoring it to 'off' after an unbalanced sequence of
intel_lvds_disable/enable.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=22672Tested-by: NAlex Riesen <raa.lkml@gmail.com>
Tested-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

The relative-to-general state default is useless as it means having to
rewrite the streaming kernels for each batch. Relative-to-surface is
more useful, as that stream usually needs to be rewritten for each
batch. And absolute addressing mode, vital if you start streaming
state, is also only available by adjusting the register...
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Add an interrupt handler for switching graphics frequencies and handling
PM interrupts.  This should allow for increased performance when busy
and lower power consumption when idle.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

v2: Change IS_IRONLAKE to IS_GEN5 to adapt to 2.6.37

This patch adds new functions for use by the drm core:

.get_vblank_timestamp() provides a precise timestamp
for the end of the most recent (or current) vblank
interval of a given crtc, as needed for the DRI2
implementation of the OML_sync_control extension.
It is a thin wrapper around the drm function
drm_calc_vbltimestamp_from_scanoutpos() which does
almost all the work.

.get_scanout_position() provides the current horizontal
and vertical video scanout position and "in vblank"
status of a given crtc, as needed by the drm for use by
drm_calc_vbltimestamp_from_scanoutpos().

The patch modifies the pageflip completion routine
to use these precise vblank timestamps as the timestamps
for pageflip completion events.

This code has been only tested on a HP-Mini Netbook with
Atom processor and Intel 945GME gpu. The codepath for
(IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) gpu's
has not been tested so far due to lack of hardware.
Signed-off-by: NMario Kleiner <mario.kleiner@tuebingen.mpg.de>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Once we have read the value out of the GT power well, we need to remove
the FORCE WAKE bit to allow the system to auto-power down.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

As we provide a list of all objects that will be accessed from the
batchbuffer, we can build a lut of the handles associated with those
objects for this invocation and use that to avoid the overhead of
looking up those objects again for every relocation.

The cost of building and searching a small hash table is much less than
that of acquiring a spinlock, searching a radix tree and manipulating an
atomic refcnt per relocation.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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