Hi,
meant to get this out earlier, but I've been off sick as well as having a sick kid, also meant a few things piled up when I wasn't looking
contains a revert for reported regression in intel and also one in radeon, a few radeon fixes, one for a 15s resume time on certain laptops, and one to fix gpu reset on some gpus,
Dave.
The following changes since commit a4851d8f7d6351a395d36ae8fdcf41745a832d76:
Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2010-12-15 12:41:17 -0800)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes
Alex Deucher (7): drm/radeon/kms: disable ss fixed ref divide drm/radeon/kms: disable the r600 cb offset checker for linear surfaces drm/radeon/kms/evergreen: flush hdp cache when flushing gart tlb drm/radeon/kms: fix evergreen asic reset drm/radeon/kms/evergreen: reset the grbm blocks at resume and init drm/radeon/kms: reorder display resume to avoid problems drm/radeon/kms: fix bug in r600_gpu_is_lockup
Benjamin Herrenschmidt (1): drm/radeon: Add early unregister of firmware fb's
Chris Wilson (5): drm/i915/ringbuffer: Handle wrapping of the autoreported HEAD drm/i915/sdvo: Only use the SDVO pin if it is in the valid range agp/intel: Fix missed cached memory flags setting in i965_write_entry() drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks drm: Include the connector name in the output_poll_execute() debug message
Dave Airlie (3): Merge remote branch 'intel/drm-intel-fixes' of /ssd/git/drm-next into drm-fixes drm/radeon: use aperture size not vram size for overlap tests Revert "drm: Don't try and disable an encoder that was never enabled"
David Flynn (1): drm/i915/dp: Fix I2C/EDID handling with active DisplayPort to DVI converter
drivers/char/agp/intel-gtt.c | 11 +++++++- drivers/gpu/drm/drm_crtc_helper.c | 7 ++++- drivers/gpu/drm/i915/intel_bios.c | 2 +- drivers/gpu/drm/i915/intel_dp.c | 37 +++++++++++++++++++++++++------ drivers/gpu/drm/i915/intel_ringbuffer.c | 19 ++++++--------- drivers/gpu/drm/i915/intel_ringbuffer.h | 5 ++- drivers/gpu/drm/i915/intel_sdvo.c | 9 +++++-- drivers/gpu/drm/radeon/atombios_crtc.c | 7 +++-- drivers/gpu/drm/radeon/evergreen.c | 27 ++++++++++------------ drivers/gpu/drm/radeon/evergreend.h | 1 + drivers/gpu/drm/radeon/r600.c | 10 ++++++- drivers/gpu/drm/radeon/r600_cs.c | 9 +++---- drivers/gpu/drm/radeon/radeon_device.c | 9 +++---- drivers/gpu/drm/radeon/radeon_drv.c | 19 ++++++++++++++++ drivers/gpu/drm/radeon/radeon_fb.c | 2 +- 15 files changed, 115 insertions(+), 59 deletions(-)
At Tue, 21 Dec 2010 23:43:18 +0000 (GMT), Dave Airlie wrote:
Hi,
meant to get this out earlier, but I've been off sick as well as having a sick kid, also meant a few things piled up when I wasn't looking
contains a revert for reported regression in intel and also one in radeon, a few radeon fixes, one for a 15s resume time on certain laptops, and one to fix gpu reset on some gpus,
Dave.
The following changes since commit a4851d8f7d6351a395d36ae8fdcf41745a832d76:
Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2010-12-15 12:41:17 -0800)
are available in the git repository at:
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes
Alex Deucher (7): drm/radeon/kms: disable ss fixed ref divide drm/radeon/kms: disable the r600 cb offset checker for linear surfaces drm/radeon/kms/evergreen: flush hdp cache when flushing gart tlb drm/radeon/kms: fix evergreen asic reset drm/radeon/kms/evergreen: reset the grbm blocks at resume and init drm/radeon/kms: reorder display resume to avoid problems drm/radeon/kms: fix bug in r600_gpu_is_lockup
Benjamin Herrenschmidt (1): drm/radeon: Add early unregister of firmware fb's
Chris Wilson (5): drm/i915/ringbuffer: Handle wrapping of the autoreported HEAD drm/i915/sdvo: Only use the SDVO pin if it is in the valid range agp/intel: Fix missed cached memory flags setting in i965_write_entry() drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks drm: Include the connector name in the output_poll_execute() debug message
The commit 448f53a1ede54eb854d036abf54573281412d650 drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
causes a regression on a SandyBridge machine here. The laptop display (LVDS) becomes blank. Reverting the commit fixes the problem.
thanks,
Takashi
On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai tiwai@suse.de wrote:
The commit 448f53a1ede54eb854d036abf54573281412d650 drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
causes a regression on a SandyBridge machine here. The laptop display (LVDS) becomes blank. Reverting the commit fixes the problem.
The question is whose BIOS is wrong? The Lenovo U160's or the Sandybridge SDV? And why does it work for that other OS? <Insert rhetorical question of the day here.>
It's back to the square one for one or the other platform... -Chris
At Wed, 22 Dec 2010 16:59:06 +0000, Chris Wilson wrote:
On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai tiwai@suse.de wrote:
The commit 448f53a1ede54eb854d036abf54573281412d650 drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
causes a regression on a SandyBridge machine here. The laptop display (LVDS) becomes blank. Reverting the commit fixes the problem.
The question is whose BIOS is wrong? The Lenovo U160's or the Sandybridge SDV? And why does it work for that other OS? <Insert rhetorical question of the day here.>
It's back to the square one for one or the other platform...
Yeah, we can blame BIOS :) And, this is likely the BIOS on my machine here that is broken.
But this seems like an issue that you can't rely solely on VBT. We can never guarantee that BIOS is correct (who can?), and there is no way to avoid this change as long as it's hard-coded. We've hit another regression by VBT check (e-DP wrongly detected; kernel bug 24822), so I think judging the behavior only from BIOS is rather dangerous.
thanks,
Takashi
On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson chris@chris-wilson.co.uk wrote:
On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai tiwai@suse.de wrote:
The commit 448f53a1ede54eb854d036abf54573281412d650 drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
causes a regression on a SandyBridge machine here. The laptop display (LVDS) becomes blank. Reverting the commit fixes the problem.
The question is whose BIOS is wrong?
I don't think so.
The Lenovo U160's or theSandybridge SDV? And why does it work for that other OS? <Insert rhetorical question of the day here.>
Quite frankly, I don't think the question should *ever* be "whose BIOS is wrong?"
You should always take for granted that the BIOS is wrong. It's not a question of "blame the BIOS", it's a question of facts of life.
It's 100% pointless to point fingers and say "the HP BIOS is wrong" or "the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that relies on the BIOS to such a degree that it either works or not based on it is by definition broken.
Why does that code need to figure out some LVDS clock from the BIOS? Why can't the code look at the actual hardware state or similar, since presumably the screen is on after boot. THAT we can rely on, since a BIOS that doesn't initialize LVDS is not going to ever ship even as pre-release.
Linus
On Thu, Dec 23, 2010 at 1:54 PM, Linus Torvalds torvalds@linux-foundation.org wrote:
On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson chris@chris-wilson.co.uk wrote:
On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai tiwai@suse.de wrote:
The commit 448f53a1ede54eb854d036abf54573281412d650 drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks
causes a regression on a SandyBridge machine here. The laptop display (LVDS) becomes blank. Reverting the commit fixes the problem.
The question is whose BIOS is wrong?
I don't think so.
The Lenovo U160's or the Sandybridge SDV? And why does it work for that other OS? <Insert rhetorical question of the day here.>
Quite frankly, I don't think the question should *ever* be "whose BIOS is wrong?"
You should always take for granted that the BIOS is wrong. It's not a question of "blame the BIOS", it's a question of facts of life.
It's 100% pointless to point fingers and say "the HP BIOS is wrong" or "the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that relies on the BIOS to such a degree that it either works or not based on it is by definition broken.
Why does that code need to figure out some LVDS clock from the BIOS? Why can't the code look at the actual hardware state or similar, since presumably the screen is on after boot. THAT we can rely on, since a BIOS that doesn't initialize LVDS is not going to ever ship even as pre-release.
I've no idea but since this is spread-spectrum related the bios may not enable spread-spectrum on the panel, though really the question is as always, what does Windows do.
Dave.
Linus _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Dec 23, 2010 at 04:54, Linus Torvalds torvalds@linux-foundation.org wrote:
Why does that code need to figure out some LVDS clock from the BIOS? Why can't the code look at the actual hardware state or similar, since presumably the screen is on after boot. THAT we can rely on, since a BIOS that doesn't initialize LVDS is not going to ever ship even as pre-release.
What if the system booted with it's display turned off? Like a closed laptop lid or disconnected monitor?
On Thu, Dec 23, 2010 at 1:32 AM, Alex Riesen raa.lkml@gmail.com wrote:
On Thu, Dec 23, 2010 at 04:54, Linus Torvalds torvalds@linux-foundation.org wrote:
Why does that code need to figure out some LVDS clock from the BIOS? Why can't the code look at the actual hardware state or similar, since presumably the screen is on after boot. THAT we can rely on, since a BIOS that doesn't initialize LVDS is not going to ever ship even as pre-release.
What if the system booted with it's display turned off? Like a closed laptop lid or disconnected monitor?
So then we might have to guess and even use the BIOS state for guessing.
But what's so hard to understand about that word "guess"? That really is what happens every single time you use some BIOS table. It's not "look up". It's not "get the right data". It very much is all about "guessing". The BIOS tables are invariably buggy, and have likely only ever been tested with one particular version of Windows.
And that's _especially_ true of something like VBIOS tables. They haven't been tested even with windows, they have only been tested with the particular graphics driver that the vendor shipped with that machine. It's quite possible - even likely - that the graphics driver hard-codes something.
So think about it - if we boot with the laptop open, you have two choices: "ask the hardware for real working state" or "guess by probing random state from the BIOS that may or may not actually ever be used that way by anything".
Which choice would you pick?
And if that means that some laptops have to be booted with the lid open, that really isn't a problem.
And yes, I do realize that VGA traditionally has had lots of hardware state that is write-only and cannot be read back. It's possible that this case is one of those. I dunno. I hope not.
(Side note: resume is different from boot. You should test that resume works with the lid closed, because resume state is not at all guaranteed to be sane at all, lid or no lid. But the way to fix that is NOT to ask the BIOS, it's to remember the state from the original boot from before the suspend).
Linus
On Wed, 22 Dec 2010 19:54:31 -0800 Linus Torvalds torvalds@linux-foundation.org wrote:
The Lenovo U160's or theSandybridge SDV? And why does it work for that other OS? <Insert rhetorical question of the day here.>
Quite frankly, I don't think the question should *ever* be "whose BIOS is wrong?"
You should always take for granted that the BIOS is wrong. It's not a question of "blame the BIOS", it's a question of facts of life.
It's 100% pointless to point fingers and say "the HP BIOS is wrong" or "the Lenovo BIOS is wrong". Buggy BIOSes happen. ALWAYS. Any code that relies on the BIOS to such a degree that it either works or not based on it is by definition broken.
Why does that code need to figure out some LVDS clock from the BIOS? Why can't the code look at the actual hardware state or similar, since presumably the screen is on after boot. THAT we can rely on, since a BIOS that doesn't initialize LVDS is not going to ever ship even as pre-release.
Oh I wish we could just do that. Strictly speaking though this isn't so much of a BIOS issue as it is a ROM issue. Platform vendors provide no way of getting at platform configuration details related to graphics aside from the tables they flash into ROM along with the VBIOS. The tables are just like an EDID ROM on a display: they communicate data we have no other way of getting.
In the particular case of SSC, there's a board down spread spectrum clock reference source at a fixed frequency. We can't automatically determine it at runtime (asking the user "can you see this" at boot time isn't really an option), so we need to rely on the VBT to tell us. The Windows driver uses this data as well, but obviously either it's incorrect on our SDV (possible) or we're failing to parse the data correctly (likely). It's also possible we're failing to look at a bit that says "use/don't use SSC on this platform" making the frequency field meaningless.
We'll figure it out or disable SSC enabling altogether failing that (risking interference with other components like wireless and sound).
dri-devel@lists.freedesktop.org
-
Alex Riesen -
Chris Wilson -
Dave Airlie -
Dave Airlie -
Jesse Barnes -
Linus Torvalds -
Peter Stuge -
Takashi Iwai