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(-)
On 12/21/2010 06:43 PM, 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
>
> 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(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
Hello,
I am new to git and can't figure out how to get these changes.
I have done a git clone of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
What next?
Thanks
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
>
> I am new to git and can't figure out how to get these changes.
>
> I have done a git clone of
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> What next?
the easiest way:
You can git pull my tree into that
git pull git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-fixes
though you should really setup remotes
git remote add airlied
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
git fetch airlied
git branch drm-fixes
git pull . remotes/airlied/drm-fixes
Dave.
At Wed, 22 Dec 2010 16:59:06 +0000,
Chris Wilson wrote:
>
> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai <[email protected]> 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, 22 Dec 2010 17:24:36 +0100, Takashi Iwai <[email protected]> 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
--
Chris Wilson, Intel Open Source Technology Centre
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, Dec 22, 2010 at 8:59 AM, Chris Wilson <[email protected]> wrote:
> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai <[email protected]> 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.
Linus
Linus Torvalds wrote:
> You should always take for granted that the BIOS is wrong.
Better yet, that there is no BIOS. Maybe one happy day, in the future.
//Peter
On Thu, Dec 23, 2010 at 1:54 PM, Linus Torvalds
<[email protected]> wrote:
> On Wed, Dec 22, 2010 at 8:59 AM, Chris Wilson <[email protected]> wrote:
>> On Wed, 22 Dec 2010 17:24:36 +0100, Takashi Iwai <[email protected]> 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
> [email protected]
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
<[email protected]> 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 Wed, 22 Dec 2010 19:54:31 -0800
Linus Torvalds <[email protected]> wrote:
> > 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.
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).
--
Jesse Barnes, Intel Open Source Technology Center
On Thu, Dec 23, 2010 at 1:32 AM, Alex Riesen <[email protected]> wrote:
> On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
> <[email protected]> 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