Hi Linus,
Please pull the 'drm-patches' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches
I'm sorry this ended up so big at this point in the cycle, and I did read
the LWN quote of the week last week, the re-org of the tree set me back a
bit with lining up the patches. We are hopefully trying a more upstream
oriented DRM development process quite soon, which may make things like
this happen less often as the drm developers educate themselves on patch
cycles.
So this has fixes for the SiS build with fbdev, a fix for a warning
reported by Jiri Slaby in the irq locking code, a fix for debugging the X
server startup sequence, r300/r500 radeon lockup fixes, Intel hw
instability fixes in the irq and hw status pages, and the biggest
bit is a fix for the backlight keys on a bunch of Intel laptops which is
enabled using opregion support from Matthew Garrett.
Dave.
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_irq.c | 40 +-
drivers/gpu/drm/drm_lock.c | 33 +-
drivers/gpu/drm/i915/Makefile | 2 +-
drivers/gpu/drm/i915/i915_dma.c | 171 +++--
drivers/gpu/drm/i915/i915_drv.c | 58 +-
drivers/gpu/drm/i915/i915_drv.h | 860 ++--------------------
drivers/gpu/drm/i915/i915_irq.c | 189 ++++--
drivers/gpu/drm/i915/i915_opregion.c | 371 +++++++++
drivers/gpu/drm/i915/i915_reg.h | 1406 ++++++++++++++++++++++++++++++++++
drivers/gpu/drm/radeon/r300_cmdbuf.c | 196 ++++-
drivers/gpu/drm/radeon/r300_reg.h | 5 +-
drivers/gpu/drm/radeon/radeon_cp.c | 38 +-
drivers/gpu/drm/radeon/radeon_drv.h | 19 +-
drivers/gpu/drm/sis/sis_mm.c | 10 +-
include/drm/drm.h | 17 -
16 files changed, 2333 insertions(+), 1083 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_opregion.c
create mode 100644 drivers/gpu/drm/i915/i915_reg.h
commit 066d38b34b451605a35ed498cef89756f59dfdcc
Author: Adrian Bunk <[email protected]>
Date: Sun Aug 24 17:11:22 2008 +1000
FB_SIS=m, DRM_SIS=y is not a legal configuration.
Reported-by: Randy Dunlap <[email protected]>
Signed-off-by: Adrian Bunk <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit 8ba0be53102f8d8509ee2958d15142bdd2fd433f
Author: Dave Airlie <[email protected]>
Date: Sun Aug 24 17:02:26 2008 +1000
drm: don't set the signal blocker on the master process.
There is a problem with debugging the X server and gdb crashes in
the xkb startup code.
This avoids the problem by allowing the master process to get signals.
It should be safe as the signal blocker is mainly so that you can
Ctrl-Z a 3D application without locking up the whole box. Ctrl-Z the
X server isn't something many people do.
Signed-off-by: Dave Airlie <[email protected]>
commit 8f812b6bea43866cd41a236596d64e41e93009fd
Author: Thomas Hellstrom <thomas-at-tungstengraphics-dot-com>
Date: Sun Aug 24 17:00:00 2008 +1000
drm: don't call the vblank tasklet with irqs disabled.
If a specific tasklet shares data with irq context,
it needs to take a private irq-blocking spinlock within
the tasklet itself.
Signed-off-by: Dave Airlie <[email protected]>
commit 47465ec5599740b8b8fceb76305abaf1bf3e92b7
Author: Nicolai Haehnle <[email protected]>
Date: Wed Aug 13 09:50:12 2008 +1000
r300: Fix cliprect emit
This makes our handling of cliprects sane. drm_clip_rect always has exclusiv
bottom-right corners, but the hardware expects inclusive bottom-right corner
so we adjust this here.
This complements Michel Daenzer's commit 57aea290e1e0a26d1e74df6cff777eb9f03
to Mesa. See also http://bugs.freedesktop.org/show_bug.cgi?id=16123
Signed-off-by: Dave Airlie <[email protected]>
commit 185b013ed895b925b97db4cc71b53128379d838a
Author: Nicolai Haehnle <[email protected]>
Date: Wed Aug 13 09:49:15 2008 +1000
drm/radeon: r300_cmdbuf: Always emit INDX_BUFFER immediately after DRAW_INDEX
DRAW_INDEX writes a vertex count to VAP_VF_CNTL. Docs say that behaviour
is undefined (i.e. lockups happen) when this write is not followed by the
right number of vertex indices.
Thus we used to do the wrong thing when drawing across many cliprects was
necessary, because we emitted a sequence
DRAW_INDEX, DRAW_INDEX, INDX_BUFFER, INDX_BUFFER
instead of
DRAW_INDEX, INDX_BUFFER, DRAW_INDEX, INDX_BUFFER
The latter is what we're doing now and which ought to be correct.
Signed-off-by: Dave Airlie <[email protected]>
commit a2f902c1d70ec106d2dc339e9f1df77c9d4ad81a
Author: Jerome Glisse <[email protected]>
Date: Wed Aug 13 09:46:31 2008 +1000
radeon: fix some hard lockups on r3/4/500s
This patch should fix hard lockup and convert them in
softlockup (ie you can ssh the box but the gpu is busted
and we are waiting in loop for it to come back to reason).
Signed-off-by: Dave Airlie <[email protected]>
commit 997f17afbd6e081a82ea14a6ed4e3cf663a507c4
Author: Matthew Garrett <[email protected]>
Date: Tue Aug 5 19:37:25 2008 +0100
Add Intel ACPI IGD OpRegion support
This adds the support necessary for allowing ACPI backlight control to
work on some newer Intel-based graphics systems. Tested on Thinkpad T61
and HP 2510p hardware.
Signed-off-by: Matthew Garrett <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit cadb300542a0673c0526b0e1e008553fd9e6a1e6
Author: Keith Packard <[email protected]>
Date: Wed Jul 30 13:03:43 2008 -0700
i915: Initialize hardware status page at device load when possible.
Some chips were unstable with repeated setup/teardown of the hardware status
page.
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit 24f17e00e605629599424309743caf56bb0eecd7
Author: Keith Packard <[email protected]>
Date: Wed Jul 30 12:21:20 2008 -0700
i915: Track progress inside of batchbuffers for determining wedgedness.
This avoids early termination for long-running commands.
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit effcf8a598eb917fb45b640bfaffe133c6a071f5
Author: Eric Anholt <[email protected]>
Date: Tue Jul 29 12:10:39 2008 -0700
i915: Add support for MSI and interrupt mitigation.
Previous attempts at interrupt mitigation had been foiled by i915_wait_irq's
failure to update the sarea seqno value when the status page indicated that
the seqno had already been passed. MSI support has been seen to cut CPU
costs by up to 40% in some workloads by avoiding other expensive interrupt
handlers for frequent graphics interrupts.
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit c140b9e73669178e8560852642bba634ac0ae6e0
Author: Jesse Barnes <[email protected]>
Date: Tue Jul 29 11:54:06 2008 -0700
i915: Use more consistent names for regs, and store them in a separate file.
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit 6efc5380867417507e1b82c8e625b9da4a710073
Author: Keith Packard <[email protected]>
Date: Wed Jul 30 12:36:08 2008 -0700
i915: Ignore X server provided mmio address
It is already correctly detected by the kernel for use in suspend/resume.
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit d88c85320dd0658683383f7c62cf25c196d5fa90
Author: Keith Packard <[email protected]>
Date: Wed Jul 30 12:28:47 2008 -0700
i915: remove settable use_mi_batchbuffer_start
The driver can know what hardware requires MI_BATCH_BUFFER vs
MI_BATCH_BUFFER_START; there's no reason to let user mode configure this.
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit 95e00aa789ab3afc6e3a987296d784bc2d49c6cd
Author: David Howells <[email protected]>
Date: Wed Jul 30 12:29:38 2008 -0700
SiS DRM: fix a pointer cast warning
Fix a pointer cast warning in the SIS DRM code.
This was introduced in patch ce65a44de07f73ceda1749812b75086b7add408d.
Signed-off-by: David Howells <[email protected]>
Cc: Dave Airlie <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit d324fcdb8de22d19d911793999bd7fb6819e50b0
Author: David Howells <[email protected]>
Date: Wed Jul 30 12:29:37 2008 -0700
SiS DRM: fix the memory allocator if the SIS FB is built as a module
Fix the SIS DRM memory allocator if the SIS FB built as a module. The SIS DRM
code initialises the mm allocation hooks, but _only_ if the SIS FB is not
built as a module because it depends on CONFIG_FB_SIS, and that's unset if the
SIS FB is not built in. It must check CONFIG_FB_SIS_MODULE as well.
Signed-off-by: David Howells <[email protected]>
Cc: Dave Airlie <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
commit 74d2f507880a3e63d60fbcb898fb1678d936b46d
Author: Carlos R. Mafra <[email protected]>
Date: Wed Jul 30 12:29:37 2008 -0700
drm: remove #define's for non-linux systems
There is no point in considering FreeBSD et al. in the linux kernel
source code.
Signed-off-by: Carlos R. Mafra <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
On Sun, 2008-08-24 at 21:57 +0100, Dave Airlie wrote:
> > Quite frankly, I'm not going to take this.
> >
> > None of what you describe sounds like regressions, and this is just TOO
> > F*CKING LATE to take big changes like this, to a fragile subsystem that
> > has historically easily introduced new regressions.
> >
> > Can you please make a branch with ONLY REGRESSIONS, or fixes for major
> > problems that don't introduce several thousand lines of new code?
> >
> > Because you seem to be constantly unable to understand what "merge window"
> > means. And I'm not going to take this kind of crap.
>
> I thought you might say that, I'll re-send with just the ones that fix the
> major issues, instead of ones that fix issues people wanted fixed. Most of
> the real bits were in Rawhide kernels for a few weeks, which tbh kicks the
> ass outta a linux-next/linux-mm test cycle.
>
> Your reply now serves as place to point people at when they ask why Red
> Hat/Fedora ships features that they can't get for 1-6 months, and I'm fine
> with that.
6 months sounds too long, there's at least one merge window in such a
time-frame.
On Mon, 2008-08-25 at 08:49 +0200, Peter Zijlstra wrote:
> On Sun, 2008-08-24 at 21:57 +0100, Dave Airlie wrote:
> > > Quite frankly, I'm not going to take this.
> > >
> > > None of what you describe sounds like regressions, and this is just TOO
> > > F*CKING LATE to take big changes like this, to a fragile subsystem that
> > > has historically easily introduced new regressions.
> > >
> > > Can you please make a branch with ONLY REGRESSIONS, or fixes for major
> > > problems that don't introduce several thousand lines of new code?
> > >
> > > Because you seem to be constantly unable to understand what "merge window"
> > > means. And I'm not going to take this kind of crap.
> >
> > I thought you might say that, I'll re-send with just the ones that fix the
> > major issues, instead of ones that fix issues people wanted fixed. Most of
> > the real bits were in Rawhide kernels for a few weeks, which tbh kicks the
> > ass outta a linux-next/linux-mm test cycle.
> >
> > Your reply now serves as place to point people at when they ask why Red
> > Hat/Fedora ships features that they can't get for 1-6 months, and I'm fine
> > with that.
>
> 6 months sounds too long, there's at least one merge window in such a
> time-frame.
Right - just realized its 2*cycle for max latency here. The next cycle
also needs to finish before Joe User gets it.
/me now goes fetch a nice hot cup of tea and wake up..
> >
> > Your reply now serves as place to point people at when they ask why Red
> > Hat/Fedora ships features that they can't get for 1-6 months, and I'm fine
> > with that.
>
> 6 months sounds too long, there's at least one merge window in such a
> time-frame.
Not every distro rebases their kernel every release..
Dave.
> Quite frankly, I'm not going to take this.
>
> None of what you describe sounds like regressions, and this is just TOO
> F*CKING LATE to take big changes like this, to a fragile subsystem that
> has historically easily introduced new regressions.
>
> Can you please make a branch with ONLY REGRESSIONS, or fixes for major
> problems that don't introduce several thousand lines of new code?
>
> Because you seem to be constantly unable to understand what "merge window"
> means. And I'm not going to take this kind of crap.
I thought you might say that, I'll re-send with just the ones that fix the
major issues, instead of ones that fix issues people wanted fixed. Most of
the real bits were in Rawhide kernels for a few weeks, which tbh kicks the
ass outta a linux-next/linux-mm test cycle.
Your reply now serves as place to point people at when they ask why Red
Hat/Fedora ships features that they can't get for 1-6 months, and I'm fine
with that.
Dave.
On Sun, 24 Aug 2008, Dave Airlie wrote:
>
> So this has fixes for the SiS build with fbdev, a fix for a warning
> reported by Jiri Slaby in the irq locking code, a fix for debugging the X
> server startup sequence, r300/r500 radeon lockup fixes, Intel hw
> instability fixes in the irq and hw status pages, and the biggest
> bit is a fix for the backlight keys on a bunch of Intel laptops which is
> enabled using opregion support from Matthew Garrett.
Quite frankly, I'm not going to take this.
None of what you describe sounds like regressions, and this is just TOO
F*CKING LATE to take big changes like this, to a fragile subsystem that
has historically easily introduced new regressions.
Can you please make a branch with ONLY REGRESSIONS, or fixes for major
problems that don't introduce several thousand lines of new code?
Because you seem to be constantly unable to understand what "merge window"
means. And I'm not going to take this kind of crap.
Linus