Hi Linus,
Just a fixes tree for -rc3 if possible, it did get rebased recently as I
had to get the nouveau pull cleaned, but I'd been running the non-nouveau
bits for a few days, there is also one late regression fix from Alex and
some fixups after Jean pushed an i2c change that broke the kms drivers.
Otherwise its mostly just modesetting fixups and radeon tiling fixes.
Dave.
The following changes since commit 0143832cc96d0bf78486297aad5c8fb2c2ead02a:
Merge branch 'urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6 (2010-11-13 10:00:15 -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 (12):
drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx
drm/radeon/kms: fix typo in r600 cs checker
drm/radeon/kms: turn the backlight off explicitly for dpms
drm/radeon/kms/atom: set sane defaults in atombios_get_encoder_mode()
drm/radeon/kms: properly power up/down the eDP panel as needed (v4)
drm/radeon/kms/atom: cleanup and unify DVO handling
drm/radeon/kms/atom: add proper external encoders support
drm/radeon/kms: register an i2c adapter name for the dp aux bus
drm/radeon/kms: fix alignment when allocating buffers
drm/radeon/kms: fix tiling info on evergreen
drm/radeon/kms: fix i2c pad masks on rs4xx
drm/radeon/kms: i2c s/sprintf/snprintf/g for safety
Andy Lutomirski (1):
nouveau: Acknowledge HPD irq in handler, not bottom half
Ben Skeggs (3):
drm/nva3: fix overflow in fixed point math used for pll calculation
drm/nv50: implement possible workaround for NV86 PGRAPH TLB flush hang
drm/nouveau: don't expose backlight control when available through ACPI
Dave Airlie (1):
Merge remote branch 'nouveau/for-airlied' of /ssd/git/drm-nouveau-next into drm-fixes
Francisco Jerez (17):
drm/nouveau: Fix sleep while atomic in the semaphore code.
drm/nouveau: Reject modes exceeding the integrated TMDS maximum bandwidth.
drm/nv04-nv40: Fall back to panel rescaling if we have no usable native mode.
drm/nv11: Fix bad PLL detection false positive.
drm/nouveau: Some random cleanups.
drm/nouveau: Avoid lock dependency between ramht and ramin spinlocks.
drm/nouveau: Reduce severity of the unknown getparam error.
drm/nouveau: Expose some BO usage flags to userspace.
drm/nv10: Balance RTs expected to be accessed simultaneously by the 3d engine.
drm/nv04: Fix scanout over the 16MB mark.
drm/nouveau: Use "force" to decide if analog load detection is ok or not.
drm/nouveau: Don't poll LVDS outputs.
drm/nv10-nv20: Fix instability after MPLL changes.
drm/nouveau: Don't use load detection for connector polling.
drm/nouveau: Return error from nouveau_gpuobj_new if we're out of RAMIN.
drm/nouveau: Make PCIE GART size depend on the available RAMIN space.
drm/nouveau: Fix a few confusions between "chipset" and "card_type".
Jiri Slaby (1):
drm/nouveau: ratelimit IRQ messages
Lucas Stach (1):
drm/nouveau: fix nv40 pcie gart size
Martin Peres (1):
drm/nouveau: Fix compilation issues in nouveau_pm when CONFIG_HWMON is not set
Roy Spliet (1):
drm/nouveau/pm: improve memtiming mappings
Thomas Hellstrom (2):
drm/vmwgfx: Fix up an error path during bo creation
drm/ttm: Fix up a theoretical deadlock
Vasiliy Kulikov (1):
drm: radeon: fix error value sign
drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 +
drivers/gpu/drm/nouveau/nouveau_bios.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 43 +++-
drivers/gpu/drm/nouveau/nouveau_connector.c | 77 ++---
drivers/gpu/drm/nouveau/nouveau_connector.h | 3 -
drivers/gpu/drm/nouveau/nouveau_drv.h | 55 +---
drivers/gpu/drm/nouveau/nouveau_fence.c | 7 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 36 ++-
drivers/gpu/drm/nouveau/nouveau_hw.c | 8 +-
drivers/gpu/drm/nouveau/nouveau_hw.h | 19 ++
drivers/gpu/drm/nouveau/nouveau_i2c.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_irq.c | 42 ++--
drivers/gpu/drm/nouveau/nouveau_mem.c | 49 ++--
drivers/gpu/drm/nouveau/nouveau_object.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_pm.c | 7 +-
drivers/gpu/drm/nouveau/nouveau_ramht.c | 71 +++--
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 14 +-
drivers/gpu/drm/nouveau/nouveau_state.c | 17 +-
drivers/gpu/drm/nouveau/nouveau_temp.c | 2 +-
drivers/gpu/drm/nouveau/nv04_crtc.c | 7 +-
drivers/gpu/drm/nouveau/nv04_dfp.c | 13 +-
drivers/gpu/drm/nouveau/nv04_pm.c | 9 +
drivers/gpu/drm/nouveau/nv50_calc.c | 16 +-
drivers/gpu/drm/nouveau/nv50_crtc.c | 4 +-
drivers/gpu/drm/nouveau/nv50_display.c | 35 ++-
drivers/gpu/drm/nouveau/nv50_fifo.c | 5 +
drivers/gpu/drm/nouveau/nv50_graph.c | 52 ++++
drivers/gpu/drm/nouveau/nv50_instmem.c | 1 -
drivers/gpu/drm/radeon/evergreen.c | 31 ++-
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 2 +-
drivers/gpu/drm/radeon/r600.c | 2 +-
drivers/gpu/drm/radeon/r600_blit_kms.c | 2 +-
drivers/gpu/drm/radeon/r600_cs.c | 311 ++++++++++++--------
drivers/gpu/drm/radeon/r600d.h | 6 +
drivers/gpu/drm/radeon/radeon.h | 4 +
drivers/gpu/drm/radeon/radeon_benchmark.c | 4 +-
drivers/gpu/drm/radeon/radeon_combios.c | 13 +
drivers/gpu/drm/radeon/radeon_connectors.c | 18 ++
drivers/gpu/drm/radeon/radeon_device.c | 2 +-
drivers/gpu/drm/radeon/radeon_encoders.c | 356 ++++++++++++++++++++---
drivers/gpu/drm/radeon/radeon_gart.c | 4 +-
drivers/gpu/drm/radeon/radeon_gem.c | 2 +-
drivers/gpu/drm/radeon/radeon_i2c.c | 8 +-
drivers/gpu/drm/radeon/radeon_irq.c | 4 +-
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 2 +-
drivers/gpu/drm/radeon/radeon_mode.h | 5 +-
drivers/gpu/drm/radeon/radeon_object.c | 7 +-
drivers/gpu/drm/radeon/radeon_object.h | 7 +-
drivers/gpu/drm/radeon/radeon_ring.c | 6 +-
drivers/gpu/drm/radeon/radeon_test.c | 4 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/radeon/rv770.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo.c | 11 +
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 14 +-
include/drm/nouveau_drm.h | 7 +
55 files changed, 1021 insertions(+), 424 deletions(-)
Hi Dave and Linus,
with travel I was a bit late in getting this pull request sent. It
contains a fix for Linus' machine, an i2c initialisation failure and a fix
from Keith to stop VGA flashing during polling on recent hardware. As well
as a patch that should hopefully prevent all of our indefinite GPU waits
on mode setting.
Note it also contains a couple of fluff fallout patches from the recent
drm-fixes rebase. (I thought it would be wise to include any core drm
changes in our testing before sending the request...)
-Chris
The following changes since commit 164bcb94bc821fcbac752e809b4ac7c6f15d13b5:
drm/radeon/kms: i2c s/sprintf/snprintf/g for safety (2010-11-19 09:27:48 +1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-fixes
Alex Deucher (1):
drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx
Alex Shi (1):
drm/i915: Disable FBC on Ironlake to save 1W
Chris Wilson (4):
drm/i915: Retire any pending operations on the old scanout when switching
Merge remote branch 'airlied/drm-fixes' into drm-intel-fixes
drm/i915: Do not hold mutex when faulting in user addresses
drm/i915/crt: Introduce struct intel_crt
Jean Delvare (1):
drm/i915: Fix I2C adapter registration
Keith Packard (1):
drm/i915: Take advantage of auto-polling CRT hotplug detection on PCH hardware
Vasiliy Kulikov (1):
drm: radeon: fix error value sign
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 77 +++++----
drivers/gpu/drm/i915/intel_crt.c | 159 ++++++++++-------
drivers/gpu/drm/i915/intel_display.c | 12 ++
drivers/gpu/drm/i915/intel_i2c.c | 11 +-
drivers/gpu/drm/radeon/r600_cs.c | 309 +++++++++++++++++++++-------------
drivers/gpu/drm/radeon/r600d.h | 6 +
drivers/gpu/drm/radeon/radeon_irq.c | 4 +-
9 files changed, 358 insertions(+), 225 deletions(-)
--
Chris Wilson, Intel Open Source Technology Centre
On Fri, Nov 19, 2010 at 2:02 AM, Chris Wilson <[email protected]> wrote:
>
> Note it also contains a couple of fluff fallout patches from the recent
> drm-fixes rebase. (I thought it would be wise to include any core drm
> changes in our testing before sending the request...)
F*%^ me, why does drm always have to be so messy?
You guys pull each others trees, and then rebase them. Yes, git is
smart enough that it will merge it all fine, but dammit, now that
multi-hundred-line Radeon commit exists twice in the tree. Do this:
git show --stat 16790569eddf fba4312e223f
git show --stat 21e2eae4daae a41c73e04673
and cry.
And yeah, it's ugly. And if that patch introduces a regression (which
is entirely possible, it's not like it's small and trivial and
obviously correct) it will just make bisection harder, and add
confusion. And it's totally pointless. It only adds pain. And it
makes the history harder to read.
Why did the Intel drm tree merge a patch that had _nothing_
what-so-ever to do with Intel DRM? WHY?
And why did the drm tree rebase a tree that had obviously been public
and pulled from? WHY? Why did you make it public before it was ready?
And/or why was it so ugly that it needed to rebase it? Why do these
things keep happening?
What's wrong with the whole drm crowd? Even if it isn't rebasing, why
is drivers/gpu/drm always so very visible in the later -rc trees?
I'm asking "why", but what I really want you guys to do is to ask
_yourself_ why. And ask "Why is that? What am I doing wrong that this
keeps happening?"
Really. Spend some time pondering. What the hell just happened, and
why did it happen, and how can you guys stop doing it?
Chris: stop pulling in random crap in your tree. Do _your_ development
in your tree. Nothing else.
And Dave, I have no idea why those two commits were rebased. They seem
identical in the tree that Chris had pulled. They have the same base
commit. What was the point?
Linus
On Sat, Nov 20, 2010 at 5:04 AM, Linus Torvalds
<[email protected]> wrote:
> On Fri, Nov 19, 2010 at 2:02 AM, Chris Wilson <[email protected]> wrote:
>>
>> Note it also contains a couple of fluff fallout patches from the recent
>> drm-fixes rebase. (I thought it would be wise to include any core drm
>> changes in our testing before sending the request...)
>
> F*%^ me, why does drm always have to be so messy?
please just reject Chris's pull, I've asked he don't send you pulls
directly, and he seems to have missed the memo in this case, if he'd
sent this to me I'd have pushed back.
the reason the tree got rebased is that i did a pull from Ben and I
screwed up, I didn't check his history and he'd based his tree on a
branch for -next not for you, and some commits
in there were also strangely renumbered, so I pushed back when I
noticed (which was after I pushed out drm-fixes). I should have
noticed before I pushed it out but I didn't mea-culpa.
I'll talk to Chris about where he bases his trees, generally I ask
they based their trees on your tree or the last thing I sent you,
unless we have some conflicting reasons which after -rc1 should never
be the case.
> And yeah, it's ugly. And if that patch introduces a regression (which
> is entirely possible, it's not like it's small and trivial and
> obviously correct) it will just make bisection harder, and add
> confusion. ?And it's totally pointless. It only adds pain. And it
> makes the history harder to read.
>
> Why did the Intel drm tree merge a patch that had _nothing_
> what-so-ever to do with Intel DRM? WHY?
>
> And why did the drm tree rebase a tree that had obviously been public
> and pulled from? WHY? Why did you make it public before it was ready?
> And/or why was it so ugly that it needed to rebase it? Why do these
> things keep happening?
I can't remember the last time we had a crazy rebase situation in the drm,
so its been a relatively while. I would have thought pushing a tree
with reverts would have made for uglier history than you just refusing
Chris's tree,
and letting me deal with it in time.
>
> What's wrong with the whole drm crowd? Even if it isn't rebasing, why
> is drivers/gpu/drm always so very visible in the later -rc trees?
>
> I'm asking "why", but what I really want you guys to do is to ask
> _yourself_ why. And ask "Why is that? What am I doing wrong that this
> keeps happening?"
>
> Really. Spend some time pondering. What the hell just happened, and
> why did it happen, and how can you guys stop doing it?
>
> Chris: stop pulling in random crap in your tree. Do _your_ development
> in your tree. Nothing else.
>
> And Dave, I have no idea why those two commits were rebased. They seem
> identical in the tree that Chris had pulled. They have the same base
> commit. What was the point?
Yeah I screwed up there, after I screwed up Ben's pull I nuked everything and
rebuilt, I should have just gone back before Ben's commit and left
those two commits intact.
As for why drm ends up with a lot of churn after rc1?
radeon 90,000 LOC (417 devices in pci table - not to mention variants
in set of encoder/connectors BIOS tables per card)
nouveau 45,148 LOC (can't tell how many devices).
intel 41,651 LOC (32 pciids, but also variants in connectors is massive)
these are just the drivers, I don't think a 1000 line modified set of
changes across 200,000 lines of code
is major, especially as its not in the core DRM, I'm guessing that
wireless is probably the only other driver
base in the same region of LOC per driver.
Like maybe we need more testing for code pre -rc1 but I think we just
end up with the same problem as when people tell you to merge less, it
just gets stacked up for the next window. People test stuff on the
hardware they have, its not really until it hits your tree or even
distros that we find it doesn't work on some other variant of the
hardware. We've had bugs in laptops with identical names and chipsets,
but slightly different panels, also people plug a wide range of
monitors into graphics cards, you'd think again these would be
standard but a small change in the EDID parser may break some monitor
or HDMI tv that has a 5c rom in it with 90% garbage. Generally merging
stuff in -rc1 means we have to fix it after that point, testing the
fixes don't regress anything is just as much pain as testing the code
in the first place.
Though I've been asking myself the same question lately why we have so
much change, it was one of the reasons I asked Chris to starting
sending things via me so I could get more visibility into what is
changing after rc1, for radeon I've been asking Alex about each fix as
it goes past and I'm generally happy they fix problems people are
actually seeing, and Chris seems to be showing a lot more constraint
than Eric used to. nouveau I'm not as pushed to constrain but I do
generally pushed back on Ben to rework stuff where it a big change
doesn't make sense.
I also wonder if its partly psychological on your part, if I sent a
number of smaller pull requests rather than queuing up things would
you notice the line count less? If Chris sends things direct to you
instead of me merging them and sending do you see a combined drm line
count or do you just notice on a pull by pull basis etc.
Like I know the goal here is to create the perfect kernel for hardware
Linus owns, but I'd like to be able to fix bugs urgently on hardware
users have that aren't so privileged, think of it as some sort of
outreach program.
Dave.