The code doesn't check first sscanf() return value.  If first sscanf()
failed then c contains some garbage.  It might lead to reading
uninitialised stack data in the second sscanf() call.
Signed-off-by: NVasiliy Kulikov <segoon@openwall.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Previous to the last GTT rework we always rewrote the GTT then unmapped the
object, somehow this got reversed in the rework in 2.6.37-rc5 timeframe.

This fix needs to go to stable in an alternate form since the code changed.

This fixes DMAR reports on my Ironlake HP2540p.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This code was setting up the status page before setting the DMAR-is-on-bit,
so we were getting DMAR errors on the status page. Reverse the two bits
of init code to the correct result.
Signed-off-by: NDave Airlie <airlied@redhat.com>

If the Link Start fails in cxgb4vf_open(), we need to back out any state
that we've built up ...
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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>

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: NChris Wilson <chris@chris-wilson.co.uk>

... and not leave the objects in a inconsistent state.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

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: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Useful for determining the layout.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

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

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: NChris Wilson <chris@chris-wilson.co.uk>

Currently the skb array is not fully allocated, and the allocation
is done as it's requested, which is not the expected way.

This patch just allocate the full skb array at driver initialization.
Also, this patch increases ehea version to 107.
Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

pcnet_cs:
     add another ID of "corega Ether CF-TD" 10Base-T PCMCIA card.
Signed-off-by: NKen Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NDave Airlie <airlied@redhat.com>
Original-patch-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NChris 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: 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>

FDI and the transcoders can fail for various reasons, so detect those
conditions and report on them.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
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>

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: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris 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: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris 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: NAlexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

... and move it under the spinlock to gain the appropriate memory
barriers.

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

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>

Signed-off-by: NChris 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: NChris 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: NChris 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: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: combine with a gratuitous tidy]
Signed-off-by: NChris 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: NChris 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: NYuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: NChris 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: NJesse Barnes <jbarnes@virtuousgeek.org>
[ickle: pass the watermark structs arounds]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Flush the chipset write buffers before and after adjusting the GTT base
register, just in case. We only modify this value upon initialisation
(boot and resume) so there should be no outstanding writes, however
there are always those persistent PGTBL_ER that keep getting reported
upon resume.
Signed-off-by: NChris 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: NChris Wilson <chris@chris-wilson.co.uk>

There should be no difference, but we can eliminate redundant code.
Signed-off-by: NChris 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: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris 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: 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

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: NAlex Fiestas <alex@eyeos.org>
Tested-by: NAlex Fiestas <alex@eyeos.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32828Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org