Skip to content

K
Kernel

openeuler / Kernel
11 个月 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 21 5月, 2013 2 次提交
  3. 20 5月, 2013 16 次提交
  5. 17 5月, 2013 5 次提交
  7. 13 5月, 2013 8 次提交
  9. 10 5月, 2013 7 次提交
  11. 08 5月, 2013 2 次提交
    • J
      drm/i915: clear the stolen fb before resuming · 1ffc5289
      由 Jani Nikula 提交于 
      Similar to
commit 88afe715
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Dec 16 12:15:41 2012 +0000

    drm/i915: Clear the stolen fb before enabling

but on the resume path.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=57191Reported-and-tested-by: NNikolay Amiantov <nikoamia@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org (3.9 only)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1ffc5289
    • B
      Revert "drm/i915: Calculate correct stolen size for GEN7+" · c4ae25ec
      由 Ben Widawsky 提交于 
      This reverts commit 03752f5b.

This revert requires a bit of explanation on how I understand things
work. Internally the architects/designers decide how the stolen encoding
works. We put it in a doc. BIOS writers take these docs and implement
it. Driver writers read the doc too, and read the value left by the BIOS
writers, and then we make magic.

The failing here is that in the docs we had[1] contained two different
definitions for this register for Gen7. (We have both a PCI register,
and an MMIO, and each of these were different). At the time [2] of
03752f5b, we asked the architects what the correct value should be; but
that doesn't match the reality (BIOS) unfortunately.

So on all machines I can get my hands on, this revert is the right thing
to do. I've also worked with the product group to confirm that they
agree this revert is what we should do. People using HW made my "people"
who both write their own BIOS, and have access to our docs (Apple?).
Investigations are still ongoing about whether we need to add a list
of machines needing special handling, but this patch should be the
right thing for pretty much everyone.

[1] The docs are still wrong on this one. Now instead of two registers with
two definitions, we have one register with BOTH definitions, progress?
[2] The open source PRMs have the "wrong" definitions in chapter Volume
1 part6, section 1.1.12.

This digging was inspired by Paulo.

Cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Augment the patch saying that it's still a bit unclear
whether there are any machines out there with "wrong" firmware and
whether we need to add a list to handle them specially.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c4ae25ec