diff options
author | Chris Wilson <chris@chris-wilson.co.uk> | 2011-03-23 18:16:55 +0000 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2011-03-23 19:45:06 -0700 |
commit | 968b503e69a6b90aa4a3b9162960f605b6abd821 (patch) | |
tree | b11144867500373dc33b1d85413dbf575e849c90 /fs/stack.c | |
parent | 4bbba111d94781d34081c37856bbc5eb33f6c72a (diff) |
Revert "drm/i915: Don't save/restore hardware status page address register"
This reverts commit a7a75c8f70d6f6a2f16c9f627f938bbee2d32718.
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: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Jan Niehusmann <jan@gondor.com>
Reported-by: Justin P. Mattock <justinmattock@gmail.com>
Reported-and-tested-by: Michael "brot" Groh <brot@minad.de>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/stack.c')
0 files changed, 0 insertions, 0 deletions