Whilst we had no older batches on the active list, everything was fine.
However, if the GPU is free running and the requests are only being
reaped by the periodic retirer, than the current seqno may not be at the
start of the list. In this case we need to select the first batch after
the last seqno written by the gpu and not inclusive of the seqno.
Signed-off-by: Chris 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: Lukács, Árpád <lukacs.arpad@gmail.com>
Bugzillla: https://bugs.freedesktop.org/show_bug.cgi?id=32748
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
... and not if the maximum is non-zero. This fixes the typo introduced
in 47356eb672 and preserves the backlight value from boot.
[ickle: My thanks also to Indan Zupancic for diagnosing the original
regression and suggesting the appropriate fix.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org # after 47356eb672
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: Chris Wilson <chris@chris-wilson.co.uk>
Rather than evicting an object at random, which is unlikely to alleviate
the memory pressure sufficient to allow us to continue, zap the entire
aperture. That should give the system long enough to recover and reap
some pages from the evicted objects, forestalling the allocation error
for the new object.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Before releasing the lock in order to copy the relocation list from user
pages, we need to drop all the object references as another thread may
usurp and execute another batchbuffer before we reacquire the lock.
However, the code was buggy and failed to clear the list...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
In order to retire active buffers whilst no client is active, we need to
insert our own flush requests onto the ring.
This is useful for servers that queue up some rendering and then go to
sleep as it allows us to the complete processing of those requests,
potentially making that memory available again much earlier.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Dave Airlie spotted that his ILK laptop with DMAR enabled was generating
the occasional DMAR warning.
"The ordering in the previous code was to rewrite the GTT table before
unmapping the pages and that makes sense to me."
This is his stable patch ported to d-i-n.
Reported-by: Dave Airlie <airlied@redhat.com>
Original-patch-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The docs recommend that if 8 display lines fit inside the FIFO buffer,
then the number of watermark entries should be increased to hide the
latency of filling the rest of the FIFO buffer.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
FDI and the transcoders can fail for various reasons, so detect those
conditions and report on them.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris 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: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: checkpatch cleanup]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Enabling RC6 implies setting a graphics context. Make sure we do that
only after the ring has been enabled, otherwise our ring commands will
hang.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Re-enable rc6 support on Ironlake for power savings. Adds a debugfs
file to check current RC state, adds a missing workaround for Ironlake
MI_SET_CONTEXT instructions, and renames MCHBAR_RENDER_STANDBY to
RSTDBYCTL to match the docs.
Keep RC6 and the power context disabled on pre-ILK. It only seems to
hang and doesn't save any power.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As the IMR for the USER interrupts are not modified elsewhere, we can
separate the spinlock used for these from that of hpd and pipestats.
Those two IMR are manipulated under an IRQ and so need heavier locking.
Reported-and-tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to ensure that writes through the GTT land before any
modification to the MMIO registers and so must impose a mandatory write
barrier when flushing the GTT domain. This was revealed by relaxing the
write ordering by experimentally mapping the registers and the GATT as
write-combining.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As has_gem is unconditionally set to true, the conditional immediately
following that assignment is superfluous.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
These functions need to be reworked for Ironlake and above, but until
then at least avoid reading non-existent registers.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: combine with a gratuitous tidy]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
When bringing up new hardware, or otherwise experimenting, GPU hangs are
a way of life. However, the automatic GPU reset can do more harm than
good under these circumstances, as we may wish to capture a full trace for
debugging.
Based on a patch by Zhenyu Wang.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On Ironlake, the LP0 latency is hardcoded and in ns unit, while on
Sandybridge, it comes from a register and with unit 0.1 us. So, fix
the wrong latency value while computing wm0 on Ironlake and Sandybridge.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This patch actually makes the watermark code even uglier (if that's
possible), but has the advantage of sharing code between SNB and ILK at
least. Longer term we should refactor the watermark stuff into its own
file and clean it up now that we know how it's supposed to work.
Supporting WM2 on my Vaio reduced power consumption by around 0.5W, so
this patch is definitely worthwhile (though it also needs lots of test
coverage).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: pass the watermark structs arounds]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
On i830 if the tail pointer is set to within 2 cachelines of the end of
the buffer, the chip may hang. So instead if the tail were to land in
that location, we pad the end of the buffer with NOPs, and start again
at the beginning.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In some configuration, the PCU may allow us to overclock the GPU.
Check for this case and adjust the max frequency as appropriate. Also
initialize the min/max frequencies to default values as indicated by
hardware.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
... and just any combination of bits & ~PFIT_ENABLE. This way we do not
attempt disable to the panel fitter controller uselessly upon
intel_lvds_disable().
Signed-off-by: Chris 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=22672
Tested-by: Alex Riesen <raa.lkml@gmail.com>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Alex Fiestas reported an issue with his HDMI connector being misdetected
as DVI unless he had something connected upon boot. By moving the
decision as to whether to use HDMI or DVI encoding for the HDMI capable
output until we probe the monitor means that we should avoid sending a
HDMI signal to a DVI monitor and also correctly detect hardware like
Alex's.
However, to really determine what connector is soldered onto the wire we
need to inspect the VBT sdvo child devices - but can we trust it?
Reported-by: Alex Fiestas <alex@eyeos.org>
Tested-by: Alex Fiestas <alex@eyeos.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32828
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Some voltage swing/pre-emphasis level use the same value on eDP
Sandybridge, like 400mv_0db and 600mv_0db are with the same value
of (0x0 << 22). So, fix them, and point out the value if it isn't
a supported voltage swing/pre-emphasis level.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Since Linux 2.6.36 the digital output on my system (855GME + DVI-I) is
not working any longer. The analog output is always activated
regardless of the type of monitor attached.
The culprit seems to be intel_crt_detect_ddc(), which returns true as
soon as an ACK from the EDID device is received. Obviously this
approach does not work with DVI-I where the analog and digital outputs
share a common DDC bus.
In a similar manner to the shared DDC wire, ala the "Mac Mini Hack", we
need an additional check to make sure that there really is an analog
device attached to the DDC.
Signed-off-by: David Müller <d.mueller@elsoft.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
When trying to do channel equalization, we need to make sure we still
have clock recovery on all lanes while training. We also need to try
clock recovery again if we lose the clock or if channel eq fails 5
times. We'll try clock recovery up to 5 more times before giving up
entirely.
Gets suspend/resume working on my Vaio again and brings us back into
compliance with the DP training sequence spec.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were using a stale pointer in the check which caused us to use CPU
attached DP params when we should have been using PCH attached params.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31988
Tested-by: Jan-Hendrik Zab <jan@jhz.name>
Tested-by: Christoph Lukas <christoph.lukas@gmx.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
If you change the color depth via fbset or some other framebuffer aware
userland application struct fb_fix_screeninfo is not updated to this new
information. This patch fixes this issue. Also the function is changed to
just pass in struct drm_framebuffer so in the future we could use more
fields. I'm hoping some day fix->smem* could be set here :-)
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We need to track the state of the switch in drivers, so that after s/r
we don't resume the card we've explicitly switched off before. Also
don't allow a userspace open to occur if we've switched the gpu off.
Signed-off-by: Dave Airlie <airlied@redhat.com>
As we have already detected something attached to the chip during
initialisation, always report the LVDS connector status as connected
during probing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The IPS driver is designed to be able to run detached from i915 and
just not enable GPU turbo in that case, in order to avoid module
dependencies between the two drivers. This means that we don't know
what the load order between the two is going to be, and we had
previously only supported IPS after (optionally) i915, but not i915
after IPS. If the wrong order was chosen, you'd get no GPU turbo, and
something like half the possible graphics performance.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
It's required by the specs, but we don't know why. Let's not find out
why.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
