Hi Linus,
This is a bunch of drm fixes, it includes couple of regression fixers on
radeon that could cause oops/memory corruptions, along with few Intel
fixers. It also fixes the Kconfig for the poulsbo stub.
I've started taking Chris's pull requests now, so all the intel drm
changes should start coming via my tree always now, unless they are pretty
exceptional or I'm away.
Dave.
The following changes since commit a7bcf21e60c73cb7f7c13fad928967d7e47c3cac:
Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2010-11-08 11:54:53 -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 (5):
drm/radeon/kms/evergreen: add missing pm.vblank_sync update in vbl handler
drm/radeon/kms: make the connector code less verbose
drm/radeon/kms: don't disable shared encoders on pre-DCE3 display blocks
drm/radeon/kms: add support for clock/data path routers
drm/radeon/kms: fix thermal sensor reporting on rv6xx
Chris Wilson (7):
drm/i915: Flush read-only buffers from the active list upon idle as well
drm/i915: Apply big hammer to serialise buffer access between rings
drm/i915: Allow powersave modparam to be adjusted at runtime.
drm/i915: SNB BLT workaround
drm/i915: Avoid might_fault during pwrite whilst holding our mutex
drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism
drm/i915: Fix LVDS fixed-mode regression from 219adae1
Christoph Fritz (1):
drm/i915: opregion_setup: iounmap correct address
Dan Carpenter (1):
i915: signedness bug in check_overlay_src()
Dave Airlie (1):
Merge branch 'drm-intel-fixes' of git://git.kernel.org/.../ickle/drm-intel
Ingo Molnar (1):
drm/stub/Kconfig: fix Kconfig for stub driver.
Jesse Barnes (1):
drm/i915: Fix the graphics frequency clamping at init and when IPS is active.
Joe Perches (3):
drivers/gpu/drm/vmwgfx: Fix k.alloc switched arguments
drivers/gpu/drm: Update WARN uses
drivers/gpu: Use vzalloc
Kulikov Vasiliy (1):
drm: vmwgfx: fix information leak to userland
Kyle McMartin (1):
i915: reprogram power monitoring registers on resume
Michel D?nzer (1):
drm/radeon/kms: Fix retrying ttm_bo_init() after it failed once.
Sam Tygier (1):
DRM: ignore invalid EDID extensions
Takashi Iwai (1):
drm/i915: Fix typo from "Enable DisplayPort Audio"
Thomas Hellstrom (10):
drm/ttm: Documentation update
drm/ttm: Use private locks for the default bo range manager
drm/ttm: Remove pointless list_empty check
drm/ttm: Remove mm init error printouts and checks
drm/ttm: Add a barrier when unreserving
drm/ttm: remove failed ttm binding error printout
drm/ttm: Make sure a sync object doesn't disappear while we use it
drm/ttm: Remove the CAP_SYS_ADMIN requirement for bo pinning
drm/vmwgfx: Fix oops on failing bo pin
drm/ttm: Be consistent on ttm_bo_init() failures
Tyson Whitehead (1):
drm/radeon/kms: fix bugs in ddc and cd path router code
Zhenyu Wang (4):
drm/i915: Fix KMS regression on Sandybridge/CPT
drm/i915; Don't apply Ironlake FDI clock workaround to Sandybridge
agp/intel: restore cache behavior on sandybridge
agp/intel: fix cache control for sandybridge
drivers/char/agp/intel-gtt.c | 6 +-
drivers/gpu/drm/drm_crtc_helper.c | 2 +-
drivers/gpu/drm/drm_edid.c | 26 +++++--
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 118 +++++++++++++++----------
drivers/gpu/drm/i915/i915_gem_evict.c | 8 +--
drivers/gpu/drm/i915/i915_suspend.c | 4 +-
drivers/gpu/drm/i915/intel_display.c | 70 +++++++++------
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_lvds.c | 16 +++-
drivers/gpu/drm/i915/intel_opregion.c | 2 +-
drivers/gpu/drm/i915/intel_overlay.c | 4 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 129 +++++++++++++++++++++++++++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +
drivers/gpu/drm/radeon/evergreen.c | 8 ++-
drivers/gpu/drm/radeon/r100.c | 4 +-
drivers/gpu/drm/radeon/r300.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 12 +--
drivers/gpu/drm/radeon/radeon_atombios.c | 27 ++++--
drivers/gpu/drm/radeon/radeon_connectors.c | 16 ++--
drivers/gpu/drm/radeon/radeon_display.c | 18 +++--
drivers/gpu/drm/radeon/radeon_encoders.c | 26 ++++++
drivers/gpu/drm/radeon/radeon_fence.c | 3 +-
drivers/gpu/drm/radeon/radeon_i2c.c | 41 +++++++--
drivers/gpu/drm/radeon/radeon_mode.h | 17 +++-
drivers/gpu/drm/radeon/radeon_object.c | 4 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 3 +-
drivers/gpu/drm/radeon/rs400.c | 2 +-
drivers/gpu/drm/radeon/rs600.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo.c | 86 +++++--------------
drivers/gpu/drm/ttm/ttm_bo_manager.c | 81 ++++++++++--------
drivers/gpu/drm/ttm/ttm_tt.c | 4 +-
drivers/gpu/drm/via/via_dmablit.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 5 +
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 2 +-
drivers/gpu/stub/Kconfig | 3 +
include/drm/ttm/ttm_bo_api.h | 4 +
include/drm/ttm/ttm_bo_driver.h | 79 ++++++++++++++++-
42 files changed, 577 insertions(+), 275 deletions(-)
On Wed, Nov 10, 2010 at 4:24 PM, Dave Airlie <[email protected]> wrote:
>
> I've started taking Chris's pull requests now, so all the intel drm
> changes should start coming via my tree always now, unless they are pretty
> exceptional or I'm away.
Btw, Chris - don't do this:
commit 08deebf98783d3de553eed2c9b6b8dcc7e168567
Author: Chris Wilson <[email protected]>
Date: Fri Nov 5 08:56:38 2010 +0000
drm/i915/ringbuffer: Use the HEAD auto-reporting mechanism
My Sandybridge only reports 0 for the ring buffer registers, causing it
to hang as soon as we exhaust the available ring. As a workaround, take
advantage of our huge ring buffers and use the auto-reporting mechanism
to update the status page with the HEAD location every 64 KiB.
Cherry-picked from 6aa56062eaba67adfb247cded244fd877329588d.
...
Think about what that "Cherry-picked from 6aa56062eaba.." means for a while.
It's a totally random number that is entirely pointless. That commit
doesn't exist in any trees anybody else is aware of, so it's pure and
utter noise. It has no meaning.
The only SHA1 numbers that are meaningful are numbers that are in some
history that is relevant. So a SHA1 should normally only ever point to
a commit that exists in the history of the commit that it points to
(think reverts, or "this fixes an issue introduced in xyz"). So if you
see that commit description, you're pretty much guaranteed that the
SHA1 makes sense.
The one exception is when you point to some "known external tree" - ie
the stable tree has references to the commits in the upstream kernel,
even though they are obviously not in the history of the stable commit
itself. The numbers may not make sense within the confines of just the
stable tree at the time, but at the same time, the stable tree rules
are very much that commits only get in once they are in mainline, so
there are actual rules in place basically saying that the hash makes
sense even _if_ it refers to an outside tree.
But when you cherry-pick it from some random internal tree that nobody
will necessarily ever see, and that you don't even describe what it
is, it's only pure confusion. I do
[torvalds@i5 linux]$ git show 6aa56062eaba67adfb247cded244fd877329588d
fatal: bad object 6aa56062eaba67adfb247cded244fd877329588d
and so will everybody else. So from a documentation standpoint, you're
actually adding negative information. Please don't.
Linus
On Fri, 12 Nov 2010 08:24:48 -0800, Linus Torvalds <[email protected]> wrote:
> But when you cherry-pick it from some random internal tree that nobody
> will necessarily ever see, and that you don't even describe what it
> is, it's only pure confusion. I do
>
> [torvalds@i5 linux]$ git show 6aa56062eaba67adfb247cded244fd877329588d
> fatal: bad object 6aa56062eaba67adfb247cded244fd877329588d
>
> and so will everybody else. So from a documentation standpoint, you're
> actually adding negative information. Please don't.
My bad, I cherry-picked it from our public drm-intel-next tree and thought
it wise to include the cross-reference to explain the duplication and
merge conflicts and to provide some additional test history into the commit.
Obviously not enough information.
Is there a right approach here? I'm trying to be strict in that what is
sent upstream in -fixes are purely known regression fixes, and to preserve
test history on both -fixes and -next. That leads to situations like the
above where we have a commit that does not appear to relevant to stable at
first, but then is later shown to be required. How best to resolve the
eventual conflict that will show up in your tree? Just cherry-pick and be
dammed?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Nov 12, 2010 at 9:21 AM, Chris Wilson <[email protected]> wrote:
>
> My bad, I cherry-picked it from our public drm-intel-next tree and thought
> it wise to include the cross-reference to explain the duplication and
> merge conflicts and to provide some additional test history into the commit.
> Obviously not enough information.
>
> Is there a right approach here? I'm trying to be strict in that what is
> sent upstream in -fixes are purely known regression fixes, and to preserve
> test history on both -fixes and -next. That leads to situations like the
> above where we have a commit that does not appear to relevant to stable at
> first, but then is later shown to be required. How best to resolve the
> eventual conflict that will show up in your tree? Just cherry-pick and be
> dammed?
Generally "just cherry-pick and be damned". Duplicate patches happen
all the time, and it has nothing to do with cherry-picking: the same
patch gets done by two different people (or just forwarded to two
different maintainers). So duplication isn't problematic per se.
And if it happens so much that it then causes real problems elsewhere
(for example lots of merge conflicts due to other related changes
around it), that's indicative of something _else_ going on.
Maybe it's just a lack of good topic branches, so that you mix
everything up in one place, and get conflicts due to that. With well
chosen topic branches, you do fixes in one particular branch that can
be merged into both -next and -stable. But then you really have to do
topic branches based on _topic_, not just "this is a random collection
of -stable crap". Name the branch by the actual problem it fixes, and
do NOT merge it into either -next _nor_ -stable until that particular
problem has really been fixed and you're sure (otherwise you'll just
end up with lots of daily merges of random fixes, and that will be
_worse_. You may avoid the merge conflicts, but your history will look
like sh*t, and your topic branches will be meaningless).
Or you have two people who work in the same area, and your code is
just not modular enough, so when they work on the same file, they
invariably step on each others fingers. Functions too big, actions not
clearly enough abstracted out, people just adding things to the same
area even when they work on two different chips (the intel DRM code
tends to be _full_ of "common" functions that then test individual
chip ID's and do different things. Dammit, if they do that, they
aren't common functions, and you write them the wrong way around:
instead of having "common function testing if ID==sandybridge", you
should have "sandybridge function doing its thing and calling _truly_
common helper functions that do things that other chip functions will
need too")
Merge conflicts (of anything but the totally trivial kind) are almost
always a sign of something being wrong in the development. Trivial
merge conflicts (and merges that had the same patch and got resolved
totally automatically - they were so trivial that a human never even
saw it) are normal. But if it's at the point that it causes pain,
there is some more fundamental problem, and marking commits as "this
is the same as in that other branch" is not the solution.
Linus