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 airlied@linux.ie 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 chris@chris-wilson.co.uk 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 torvalds@linux-foundation.org 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
On Fri, Nov 12, 2010 at 9:21 AM, Chris Wilson chris@chris-wilson.co.uk 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
dri-devel@lists.freedesktop.org
-
Chris Wilson -
Dave Airlie -
Linus Torvalds