[re-pull request]

Original pull req below + reverts the fallback placement change which had 
a side effect of causing more lockups on some AGP systems (this is a bug in 
the AGP drivers that needs to be tracked down), adds some further fixes 
from Alex for radeon. Also in case you are wondering why this has a 
v2.6.34-rc2 merge in the middle of it, one of the radeon changes needed an 
i2c change before I could test it.

original pull text:
Some nouveau updates + misc drm core fixes,

radeon kms: mostly fixes, however a cleanup to the ugly asic tables to
avoid drift between C prototypes moves some stuff around, and I've merged
Jerome's GPU recovery code, as I'd much rather users had some of hope of
recovering from their GPU locking up than a dead box. It seems to work
for quite a lot of people that have tested it, and it won't make a GPU
lockup problem worse. This also finally fixes HDMI audio on rv7xx cards.

The following changes since commit 220bf991b0366cc50a94feede3d7341fa5710ee4:
  Linus Torvalds (1):
        Linux 2.6.34-rc2

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus

Alex Deucher (32):
      drm/radeon: add new RS880 pci id
      drm/radeon/kms/atom: spread spectrum fix
      drm/radeon/kms: use lcd pll limits when available
      drm/radeon/kms: further spread spectrum fixes
      drm/radeon/kms: fix pal tv-out support on legacy IGP chips
      drm/radeon/kms: fix for hw i2c
      drm/radeon/kms: fix i2c prescale calc on older radeons
      drm/radeon/kms/r1xx: enable hw i2c
      drm/radeon/kms/rs4xx: make sure crtcs are enabled when setting timing
      drm/radeon/r600: add missing license and comments to r600_blit_shaders.c
      drm/radeon/kms: expose thermal/fan i2c buses
      drm/radeon/kms/pm: fix segfault in clock code
      drm/radeon/kms: gfx init fixes for r6xx/r7xx
      drm/radeon/kms/pm: fix typo in power table parsing
      drm/radeon/kms: init rdev->num_crtc at ...
[ message continues ]

While I was able to work around the lockups by making the AGP driver
never unbind a GTT entry, I think it's rather a radeon issue - how is
the AGP driver supposed to know when it's safe to unbind an entry?


Unfortunately, that's not true in all cases. The change itself mentions
that the new reset code is unreliable for R3xx generation GPUs, and
indeed with my RV350 it now turns my box into a brick immediately on a
GPU lockup most of the time whereas previously it was usually able to
recover at least in some cases, e.g. falling back to PCI mode after
trying to use a non-working AGP transfer mode.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
--

[ message continues ]

This issue has been a problem with AGP before, the Intel AGP docs claim
you should always use scratch pages on AGP, and never complete remove
bound entries. I've no idea why this is, as you'd expect AGP cards to
only generate
cycles to entries they've been asked to. There may be some memory controller
prefetching going on that could lead to prefetching into an unbound AGP page
and the resulting machine check that may cause I suppose.

We need to track this separately anyways and fix it for 2.6.35 hopefully, at

Okay so it makes it worse, hopefully Jerome can track it down, or
else we can lock down the gpu reset to only trying on the r600s where
it definitely makes life a lot better for everyone.

Dave.
--

[ message continues ]

Actually Linus, don't bother, consider this revoked, I'm going to kill
the GPU reset code
and re-send this tomorrow, its just a mess to get it back out of the
tree at this point,

but I realised I was falling back to the old ways, of putting things
with badness in, even
if they helped a few people.

Jerome, GPU reset will have to wait until 2.6.35 now.

--

[ message continues ]

Hey, thanks. 

		Linus
--

[ message continues ]

I will try to see if i can do a smaller version which only affect
r6xx/r7xx hw were it's know to be helpfull while leaving other hw
unaffected and working on a more reliable code for 2.6.35 for these
older hw.

Cheers.
Jerome
--

[ message continues ]

Ping? Are you waiting for Jerome or something? Please do not stop
pulling whole stuff because Jerome is preparing some patch for last
moment.

I believe I'll be much better to pull most stuff ASAP to let ppl test
it, and later eventually ask Linus to get some one-two additional
small patches.

-- 
Rafał
--

[ message continues ]

Rebasing out Jerome's patches and reverifying stuff works isn't
something that takes 5 minutes. Since the rebase pretty much
negates all the testing I'd done.

Dave.
--

[ message continues ]

Oh, OK. Thanks for your work on getting 2.6.34 into nice shape :)

-- 
Rafał
--

[ message continues ]