[git pull] drm request 2

[git pull] drm request 2

[Dave Airlie]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 19588 bytes --]


Same tree as yesterday with a warning + PPC build fix + fix for build on 
x86 after PPC (I think I just validated Ingo).

The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad:
  Linus Torvalds (1):
        Linux 2.6.33

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 (34):
      drm/radeon/kms: add radeon i2c algo
      drm/radeon/kms: add support for hw i2c on r1xx-r5xx
      drm/radeon/kms: add workaround for rn50/rv100 servers
      drm/radeon/kms: add support for hardcoded edids in rom (v2)
      drm/radeon/kms: clean up some low-hanging magic numbers
      drm/radeon/kms: rework pll algo selection
      drm/radeon/kms: add pll quirk for toshiba laptop panel
      drm/radeon/kms/atom: clean up spread spectrum code
      drm/radeon/kms/atom: add a helper function to get the radeon connector priv
      drm/radeon/kms/r600: reduce gpu cache flushing
      drm/radeon/kms: consolidate crtc count in rdev
      drm/radeon/kms: add functions to get current pcie lanes
      drm/radeon/kms: pull power mode info from bios tables (v3)
      drm/radeon/kms: add a power state type based on power state flags
      drm/radeon/kms: add code to select power state
      drm/radeon/kms: use power states for dynamic reclocking
      drm/radeon/kms: dynclks fixes
      drm/radeon/kms: take the pm mutex when using hw i2c
      drm/radeon/kms: update atombios.h to latest upstream.
      drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx)
      drm/radeon/kms: fix prescale calculations
      drm/radeon/kms/atom: replace 0/1 in crtc code with ATOM_DISABLE/ATOM_ENABLE
      drm/radeon/kms/evergreen: fix multi-head
      drm/radeon/kms/evergreen: adapt to i2c changes
      drm/radeon/r600: fix warnings in CS checker
      drm/radeon/kms: add LVDS pll quirk for Dell Studio 15
      drm/radeon/kms: remove HDP flushes from fence emit (v2)
      drm/radeon/kms: remove unused r600_gart_clear_page
      drm/radeon/rv740: fix backend setup
      drm/radeon: fixes for r6xx/r7xx gfx init
      drm/radeon/kms/evergreen: fix typo in cursor code
      drm/radeon/kms: update new pll algo
      drm/radeon/kms/atom: fix shr/shl ops
      drm/radeon: fix typo in Makefile

Andy Shevchenko (1):
      drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of atoi()

Ben Skeggs (17):
      drm/nv50: switch to indirect push buffer controls
      drm/nouveau: remove PUSHBUF_CAL macro
      drm/nv50: make pushbuf dma object cover entire vm
      drm/nouveau: new gem pushbuf interface, bump to 0.0.16
      drm/nouveau: allow retrieval of vbios image from debugfs
      drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table
      drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table
      drm/nouveau: merge nvbios and nouveau_bios_info
      drm/nouveau: reorganise bios header, add dcb connector type enums
      drm/nouveau: parse dcb gpio/connector tables after encoders
      drm/nouveau: check for known dcb connector types
      drm/nouveau: construct a connector table for cards that lack a real one
      drm/nouveau: use dcb connector table for creating drm connectors
      drm/nv50: enable hpd on any connector we know the gpio line for
      drm/nouveau: use dcb connector types throughout the driver
      drm/nouveau: support version 0x20 displayport tables
      drm/nouveau: report unknown connector state if lid closed

Chris Wilson (2):
      drm/i915: Replace open-coded eviction in i915_gem_idle()
      drm/i915: Record batch buffer following GPU error

Daniel Vetter (11):
      drm/i915: overlay: nuke readback to flush wc caches
      drm/i915: overlay: drop superflous gpu flushes
      drm/i915: move a gtt flush to the correct place
      drm/i915: blow away userspace mappings before fence change
      drm/i915: reuse i915_gem_object_put_fence_reg for fence stealing code
      drm/i915: fixup active list locking in object_unbind
      drm/i915: extract fence stealing code
      drm/i915: ensure lru ordering of fence_list
      drm/i915: reuse i915_gpu_idle helper
      drm/i915: clean-up i915_gem_flush_gpu_write_domain
      drm/i915: check for multiple write domains in pin_and_relocate

Dave Airlie (21):
      drm/radeon/kms: switch all KMS driver ioctls to unlocked.
      drm/radeon/kms: use udelay for short delays
      drm: switch all GEM/KMS ioctls to unlocked ioctl status.
      drm/kms: fix fb_changed = true else statement
      drm/radeon/kms: check for valid PCI bios and not OF rom
      drm/radeon/kms: set gart pages to invalid on unbind and point to dummy page
      drm/radeon/kms: flush HDP cache on GART table updates.
      [rfc] drm/radeon/kms: pm debugging check for vbl.
      Merge remote branch 'korg/drm-core-next' into drm-next-stage
      Merge remote branch 'anholt/drm-intel-next' into drm-next-stage
      fb: for framebuffer handover don't exit the loop early.
      Merge remote branch 'korg/drm-radeon-testing' into drm-next-stage
      Merge remote branch 'korg/drm-core-next' into drm-next-stage
      Merge remote branch 'nouveau/for-airlied' into drm-next-stage
      Merge remote branch 'anholt/drm-intel-next' into drm-next-stage
      drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond
      Merge branch 'drm-radeon-testing' of /ssd/git/drm-radeon-next into drm-next-stage
      vga_switcheroo: initial implementation (v15)
      Merge branch 'gpu-switcher' of /ssd/git//linux-2.6 into drm-next-stage
      drm/radeon/kms: bump the KMS version number for square tiling support.
      vga_switcheroo: fix build on platforms with no ACPI

Eric Anholt (13):
      drm/i915: Don't reserve compatibility fence regs in KMS mode.
      agp/intel: Add support for Sandybridge.
      drm/i915: Add initial bits for VGA modesetting bringup on Sandybridge.
      drm/i915: Set up fence registers on sandybridge.
      drm/i915: Fix sandybridge status page setup.
      agp/intel: Use a non-reserved value for the cache field of the PTEs.
      drm/i915: Disable the surface tile swizzling on Sandybridge.
      drm/i915: Correct locking in the modesetting failure path, fixing a BUG_ON.
      agp/intel: Add a new Sandybridge HB/IG PCI ID combo.
      drm/i915: Add a new mobile Sandybridge PCI ID.
      drm/i915: Disable the hangcheck reset on Sandybridge until we add support.
      drm/i915: Correct the Sandybridge chipset info structs.
      drm/i915: More s/IS_IRONLAKE/HAS_PCH_SPLIT for Sandybridge.

Jerome Glisse (9):
      drm/radeon/kms: bogus cs recorder utilities
      drm/radeon/kms: r600/r700 command stream checker
      drm/radeon/kms: fix r600/r700 cs checker to avoid double kfree
      drm/radeon/kms: fix indirect buffer management V2
      drm/radeon/kms: fix bo's fence association
      drm/radeon/kms: simplify memory controller setup V2
      drm/radeon/kms: fix R3XX/R4XX memory controller initialization
      drm/radeon/kms: force pinning buffer into visible VRAM
      drm/radeon/kms: initialize set_surface_reg reg for rs600 asic

Jesse Barnes (6):
      drm/i915: add dynamic performance control support for Ironlake
      drm/i915: fix drps disable so unload & re-load works
      drm/i915: provide FBC status in debugfs
      drm/i915: provide self-refresh status in debugfs
      drm/i915: give up on 8xx lid status
      drm/i915: enable/disable LVDS port at DPMS time

Li Peng (2):
      drm/i915: enable memory self refresh on 9xx
      drm/i915: Fix OGLC performance regression on 945

Luca Barbieri (3):
      drm: introduce drm_gem_object_[handle_]unreference_unlocked
      Use drm_gem_object_[handle_]unreference_unlocked where possible
      drm/nouveau: fix missing spin_unlock in failure path

Maarten Maathuis (2):
      drm/ttm: handle OOM in ttm_tt_swapout
      drm/nouveau: protect channel create/destroy and irq handler with a spinlock

Marcin Kościelnicki (2):
      drm/nv50: Implement ctxprog/state generation.
      drm/nouveau: Fix noaccel/nofbaccel option descriptions.

Marcin Slusarz (3):
      drm/nouveau: fix pramdac_table range checking
      drm/nouveau: fix nouveau_i2c_find bounds checking
      drm/nouveau: fix i2ctable bounds checking

Marek Olšák (1):
      drm/radeon/kms: add support for square microtiles on r3xx-r5xx

Matt Turner (2):
      drm/nouveau: use ALIGN instead of open coding it
      drm/radeon: use ALIGN instead of open coding it

Matthew Garrett (1):
      drm/i915: Deobfuscate the render p-state obfuscation

Michel Dänzer (1):
      drm/radeon/kms: Test rdev->bios centrally in combios_get_table_offset().

Owain Ainsworth (1):
      drm/i915: reduce some of the duplication of tiling checking

Pauli Nieminen (5):
      drm/radeon/kms: Create asic structure for r300 pcie cards.
      drm/radeon: Add asic hook for dma copy to r200 cards.
      drm: Add generic multipart buffer.
      drm/radeon: Fix memory allocation failures in the preKMS command stream checking.
      drm/radeon: Fix printf type warning in 64bit system.

Pavel Roskin (1):
      drm/kms: fix spelling of "CLOCK"

Rafał Miłecki (13):
      drm/radeon/kms: add dynamic engine reclocking (V9)
      drm/radeon/kms: don't set pcie lanes for ignored power_state
      drm/radeon/kms: get_power_state early, not when processing IRQ
      drm/radeon/kms: use wait queue (events) for VBLANK sync
      drm/radeon/kms: isolate audio engine management, change fini order
      drm/radeon/kms: accept slightly overclocked power modes
      drm/radeon/kms: simplify picking power state
      drm/radeon/kms: simplify storing current and requested PM mode
      drm/radeon/kms: for downclocking non-mobility check PERFORMANCE state
      drm/radeon/kms: implement reading active PCIE lanes on R600+
      drm/radeon/kms: do not preset audio stuff and start timer when not using audio
      Revert "drm/radeon/kms: disable HDMI audio for now on rv710/rv730"
      drm/radeon/kms: do not disable audio engine twice

Randy Dunlap (1):
      drm/ttm: fix function prototype to match implementation

Zhao Yakui (1):
      drm/i915: Use a dmi quirk to skip a broken SDVO TV output.

Zhenyu Wang (4):
      drm/i915: Keep MCHBAR always enabled
      agp/intel: official names for Pineview and Ironlake
      drm/i915, agp/intel: Fix stolen memory size on Sandybridge
      drm/i915: Add dependency on the intel agp module

 drivers/char/agp/intel-agp.c                    |  123 +-
 drivers/gpu/drm/Makefile                        |    2 +-
 drivers/gpu/drm/drm_buffer.c                    |  184 +
 drivers/gpu/drm/drm_crtc_helper.c               |    6 +-
 drivers/gpu/drm/drm_drv.c                       |   44 +-
 drivers/gpu/drm/drm_edid.c                      |   30 +-
 drivers/gpu/drm/drm_fb_helper.c                 |   26 +-
 drivers/gpu/drm/drm_gem.c                       |   70 +-
 drivers/gpu/drm/i915/i915_debugfs.c             |  253 +-
 drivers/gpu/drm/i915/i915_dma.c                 |  326 +-
 drivers/gpu/drm/i915/i915_drv.c                 |   27 +-
 drivers/gpu/drm/i915/i915_drv.h                 |   69 +-
 drivers/gpu/drm/i915/i915_gem.c                 |  430 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c          |  169 +-
 drivers/gpu/drm/i915/i915_irq.c                 |  313 +-
 drivers/gpu/drm/i915/i915_reg.h                 |  170 +-
 drivers/gpu/drm/i915/i915_suspend.c             |   10 +
 drivers/gpu/drm/i915/intel_bios.c               |    3 +-
 drivers/gpu/drm/i915/intel_crt.c                |   14 +-
 drivers/gpu/drm/i915/intel_display.c            |  216 +-
 drivers/gpu/drm/i915/intel_dp.c                 |    6 +-
 drivers/gpu/drm/i915/intel_drv.h                |    2 +
 drivers/gpu/drm/i915/intel_fb.c                 |    2 +
 drivers/gpu/drm/i915/intel_hdmi.c               |    4 +-
 drivers/gpu/drm/i915/intel_i2c.c                |    2 +-
 drivers/gpu/drm/i915/intel_lvds.c               |   41 +-
 drivers/gpu/drm/i915/intel_overlay.c            |   29 +-
 drivers/gpu/drm/i915/intel_sdvo.c               |   23 +-
 drivers/gpu/drm/nouveau/Makefile                |    2 +-
 drivers/gpu/drm/nouveau/nouveau_acpi.c          |  160 +-
 drivers/gpu/drm/nouveau/nouveau_bios.c          |  339 +-
 drivers/gpu/drm/nouveau/nouveau_bios.h          |  126 +-
 drivers/gpu/drm/nouveau/nouveau_calc.c          |    4 +-
 drivers/gpu/drm/nouveau/nouveau_channel.c       |   39 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c     |  167 +-
 drivers/gpu/drm/nouveau/nouveau_connector.h     |    3 +-
 drivers/gpu/drm/nouveau/nouveau_debugfs.c       |   24 +
 drivers/gpu/drm/nouveau/nouveau_display.c       |    7 +-
 drivers/gpu/drm/nouveau/nouveau_dma.c           |  108 +-
 drivers/gpu/drm/nouveau/nouveau_dma.h           |   21 +-
 drivers/gpu/drm/nouveau/nouveau_drv.c           |   13 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h           |   53 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c         |    6 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c           |  508 +-
 drivers/gpu/drm/nouveau/nouveau_hw.c            |    6 +-
 drivers/gpu/drm/nouveau/nouveau_i2c.c           |   10 +-
 drivers/gpu/drm/nouveau/nouveau_irq.c           |    5 +
 drivers/gpu/drm/nouveau/nouveau_notifier.c      |    9 +-
 drivers/gpu/drm/nouveau/nouveau_state.c         |   40 +-
 drivers/gpu/drm/nouveau/nv04_crtc.c             |    4 +-
 drivers/gpu/drm/nouveau/nv04_dac.c              |    8 +-
 drivers/gpu/drm/nouveau/nv04_dfp.c              |    4 +-
 drivers/gpu/drm/nouveau/nv04_display.c          |   49 +-
 drivers/gpu/drm/nouveau/nv04_fbcon.c            |    2 +-
 drivers/gpu/drm/nouveau/nv04_fifo.c             |    5 +
 drivers/gpu/drm/nouveau/nv04_tv.c               |    2 +-
 drivers/gpu/drm/nouveau/nv17_tv.c               |    6 +-
 drivers/gpu/drm/nouveau/nv40_fifo.c             |    5 +
 drivers/gpu/drm/nouveau/nv50_crtc.c             |    4 +-
 drivers/gpu/drm/nouveau/nv50_dac.c              |    4 +-
 drivers/gpu/drm/nouveau/nv50_display.c          |   54 +-
 drivers/gpu/drm/nouveau/nv50_fbcon.c            |    2 +-
 drivers/gpu/drm/nouveau/nv50_fifo.c             |   13 +-
 drivers/gpu/drm/nouveau/nv50_graph.c            |   74 +-
 drivers/gpu/drm/nouveau/nv50_grctx.c            | 2367 ++++++++
 drivers/gpu/drm/nouveau/nv50_instmem.c          |    2 +-
 drivers/gpu/drm/radeon/Makefile                 |    9 +-
 drivers/gpu/drm/radeon/atom.c                   |    4 -
 drivers/gpu/drm/radeon/atombios.h               | 7300 +++++++++++++----------
 drivers/gpu/drm/radeon/atombios_crtc.c          |  456 ++-
 drivers/gpu/drm/radeon/atombios_dp.c            |   64 +-
 drivers/gpu/drm/radeon/avivod.h                 |    2 +
 drivers/gpu/drm/radeon/evergreen.c              |  767 +++
 drivers/gpu/drm/radeon/evergreen_reg.h          |  176 +
 drivers/gpu/drm/radeon/r100.c                   |  176 +-
 drivers/gpu/drm/radeon/r200.c                   |   46 +
 drivers/gpu/drm/radeon/r300.c                   |  157 +-
 drivers/gpu/drm/radeon/r300_cmdbuf.c            |  280 +-
 drivers/gpu/drm/radeon/r300_reg.h               |    2 +
 drivers/gpu/drm/radeon/r420.c                   |   49 +-
 drivers/gpu/drm/radeon/r500_reg.h               |  100 +-
 drivers/gpu/drm/radeon/r520.c                   |   21 +-
 drivers/gpu/drm/radeon/r600.c                   |  190 +-
 drivers/gpu/drm/radeon/r600_audio.c             |   21 +-
 drivers/gpu/drm/radeon/r600_blit.c              |    2 +-
 drivers/gpu/drm/radeon/r600_blit_kms.c          |   17 +-
 drivers/gpu/drm/radeon/r600_blit_shaders.c      |   10 -
 drivers/gpu/drm/radeon/r600_cp.c                |  262 +-
 drivers/gpu/drm/radeon/r600_cs.c                |  831 +++-
 drivers/gpu/drm/radeon/r600d.h                  |  467 ++-
 drivers/gpu/drm/radeon/radeon.h                 |  167 +-
 drivers/gpu/drm/radeon/radeon_agp.c             |    4 +
 drivers/gpu/drm/radeon/radeon_asic.h            |  172 +-
 drivers/gpu/drm/radeon/radeon_atombios.c        |  435 ++-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c    |  257 +
 drivers/gpu/drm/radeon/radeon_bios.c            |   50 +-
 drivers/gpu/drm/radeon/radeon_clocks.c          |   18 +-
 drivers/gpu/drm/radeon/radeon_combios.c         |  290 +-
 drivers/gpu/drm/radeon/radeon_connectors.c      |   20 +-
 drivers/gpu/drm/radeon/radeon_cp.c              |    1 +
 drivers/gpu/drm/radeon/radeon_cs.c              |    7 +-
 drivers/gpu/drm/radeon/radeon_cursor.c          |   50 +-
 drivers/gpu/drm/radeon/radeon_device.c          |  235 +-
 drivers/gpu/drm/radeon/radeon_display.c         |  332 +-
 drivers/gpu/drm/radeon/radeon_drv.c             |   14 +-
 drivers/gpu/drm/radeon/radeon_drv.h             |   46 +-
 drivers/gpu/drm/radeon/radeon_encoders.c        |  354 +-
 drivers/gpu/drm/radeon/radeon_family.h          |    5 +
 drivers/gpu/drm/radeon/radeon_fb.c              |   12 +-
 drivers/gpu/drm/radeon/radeon_gart.c            |   32 +-
 drivers/gpu/drm/radeon/radeon_gem.c             |   36 +-
 drivers/gpu/drm/radeon/radeon_i2c.c             |  768 +++-
 drivers/gpu/drm/radeon/radeon_kms.c             |   27 +-
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c     |   29 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c |   20 +
 drivers/gpu/drm/radeon/radeon_mode.h            |   55 +-
 drivers/gpu/drm/radeon/radeon_object.c          |    3 +-
 drivers/gpu/drm/radeon/radeon_pm.c              |  399 ++-
 drivers/gpu/drm/radeon/radeon_reg.h             |   50 +-
 drivers/gpu/drm/radeon/radeon_ring.c            |   67 +
 drivers/gpu/drm/radeon/radeon_state.c           |  203 +-
 drivers/gpu/drm/radeon/radeon_test.c            |    2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c             |   12 +-
 drivers/gpu/drm/radeon/reg_srcs/r600            |  837 +++
 drivers/gpu/drm/radeon/rs400.c                  |   39 +-
 drivers/gpu/drm/radeon/rs600.c                  |   56 +-
 drivers/gpu/drm/radeon/rs690.c                  |   41 +-
 drivers/gpu/drm/radeon/rv515.c                  |   21 +-
 drivers/gpu/drm/radeon/rv770.c                  |  259 +-
 drivers/gpu/drm/radeon/rv770d.h                 |    2 +
 drivers/gpu/drm/ttm/ttm_tt.c                    |   18 +-
 drivers/gpu/vga/Kconfig                         |   13 +
 drivers/gpu/vga/Makefile                        |    1 +
 drivers/gpu/vga/vga_switcheroo.c                |  450 ++
 drivers/video/console/fbcon.c                   |   18 +
 drivers/video/fbmem.c                           |    1 -
 include/drm/drmP.h                              |   28 +-
 include/drm/drm_buffer.h                        |  148 +
 include/drm/drm_crtc.h                          |    2 +
 include/drm/drm_edid.h                          |    3 +
 include/drm/drm_pciids.h                        |   36 +
 include/drm/nouveau_drm.h                       |   86 +-
 include/drm/radeon_drm.h                        |    1 +
 include/drm/ttm/ttm_bo_driver.h                 |    2 +-
 include/linux/fb.h                              |    2 +
 include/linux/vga_switcheroo.h                  |   57 +
 146 files changed, 18177 insertions(+), 6374 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_buffer.c
 create mode 100644 drivers/gpu/drm/nouveau/nv50_grctx.c
 create mode 100644 drivers/gpu/drm/radeon/evergreen.c
 create mode 100644 drivers/gpu/drm/radeon/evergreen_reg.h
 create mode 100644 drivers/gpu/drm/radeon/radeon_atpx_handler.c
 create mode 100644 drivers/gpu/drm/radeon/reg_srcs/r600
 create mode 100644 drivers/gpu/vga/vga_switcheroo.c
 create mode 100644 include/drm/drm_buffer.h
 create mode 100644 include/linux/vga_switcheroo.h

Re: [git pull] drm request 2

[Linus Torvalds]

On Mon, 1 Mar 2010, Dave Airlie wrote:
> 
> Same tree as yesterday with a warning + PPC build fix + fix for build on 
> x86 after PPC (I think I just validated Ingo).

Why is VGA_SWITCHEROO enabled by default?

We don't do things like that. New drivers and new features are _not_ 
enabled by default, unless there is some overriding reason why they should 
be. And I don't see that reason.

Please stop doing that. The whole "default y" is a f*cking disease. Yes, a 
developer always thinks that _his_ new code is so special and important 
that it should be enabled by default, BUT HE IS WRONG.

So remember: unless your new feature cures cancer, it should damn well not 
be enabled by default.

I disabled it in the merge, since I had to fix up that file anyway. But 
please don't make me do these so-called "evil merges" where I end up 
modifying the thing I merge.

			Linus

Re: [git pull] drm request 2

[Dave Airlie]

> > x86 after PPC (I think I just validated Ingo).
> 
> Why is VGA_SWITCHEROO enabled by default?

because it does nothing on anything except the laptops in question and on 
those it does nothing except add a control file in debugfs?

So how am I supposed to indicate to distro vendors that something should 
be turned on? If you think that distro kernel maintainers really 
understand every config option that goes past, I've got a bridge.

Dave.

Re: [git pull] drm request 2

[Linus Torvalds]

On Tue, 2 Mar 2010, Linus Torvalds wrote:
> 
> I disabled it in the merge, since I had to fix up that file anyway. But 
> please don't make me do these so-called "evil merges" where I end up 
> modifying the thing I merge.

Never mind. I've unpulled the whole effin' mess since it doesn't even 
compile:

	drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of ‘nouveau_register_dsm_handler’
	drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of ‘nouveau_register_dsm_handler’ was here
	drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of ‘nouveau_unregister_dsm_handler’
	drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of ‘nouveau_unregister_dsm_handler’ was here

because not only was that VGA_SWITCHEROO Kconfig default the wrong way 
around, the thing had clearly never ever been tested at all.

Why does sh*t like this even make it to me? Was this ever at all in -next? 
I assume not, since that would have picked up on basic compile failures.

Grr. Things like this is what makes me go "Ok, there's always the next 
merge window, maybe it will have gotten some testing by then".

		Linus

Re: [git pull] drm request 2

[Linus Torvalds]

On Tue, 2 Mar 2010, Dave Airlie wrote:
> 
> because it does nothing on anything except the laptops in question and on 
> those it does nothing except add a control file in debugfs?

It's still code. And if the user didn't ask for it, it should damn well 
not be there.

> So how am I supposed to indicate to distro vendors that something should 
> be turned on? If you think that distro kernel maintainers really 
> understand every config option that goes past, I've got a bridge.

User configurations is _not_ your job. Your job is to make sure that the 
kernel works, and people who don't ask for new feaures don't get them.

		Linus

Re: [git pull] drm request 2

[Linus Torvalds]

On Tue, 2 Mar 2010, Linus Torvalds wrote:
> 
> It's still code. And if the user didn't ask for it, it should damn well 
> not be there.

And I repeat: unless the feature cures cancer, it's not on by default.

Sometimes we split up _old_ features as config options, or do things that 
are meant to be turned off only for embedded people. THEN we use that 
whole 'default y' thing, because doing a "make oldconfig" should give you 
the same configuration you had before. 

But if it's not an old feature that used to not have a config option at 
all, and it doesn't cure cancer, you never EVER do "default y".  Because 
when I do "make oldconfig", and I see a "Y" default, it makes me go "I'm 
not pulling that piece of sh*t".

		Linus

Re: [git pull] drm request 2

[Dave Airlie]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1399 bytes --]

> 
> Never mind. I've unpulled the whole effin' mess since it doesn't even 
> compile:
> 
> 	drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of ‘nouveau_register_dsm_handler’
> 	drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of ‘nouveau_register_dsm_handler’ was here
> 	drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of ‘nouveau_unregister_dsm_handler’
> 	drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of ‘nouveau_unregister_dsm_handler’ was here
> 
> because not only was that VGA_SWITCHEROO Kconfig default the wrong way 
> around, the thing had clearly never ever been tested at all.
> 
> Why does sh*t like this even make it to me? Was this ever at all in -next? 
> I assume not, since that would have picked up on basic compile failures.
> 
> Grr. Things like this is what makes me go "Ok, there's always the next 
> merge window, maybe it will have gotten some testing by then".

Linux next didn't pick up this build failure, wierdly neither did the 
powerpc build I did with this turned off, because ACPI was also off on 
ppc, it was in linux-next for at least 2 days, and from what I can see 
that found the ppc problems, it never found the x86 option since it was on 
by default.

I'm going to just rip the nouveau bits out of the patch, btw nouveau is in 
staging, so you are being a bit OTT, calm down.

Dave.

Re: [git pull] drm request 2

[Dave Airlie]

0/3/3 Dave Airlie <airlied@linux.ie>:
>>
>> Never mind. I've unpulled the whole effin' mess since it doesn't even
>> compile:
>>
>>       drivers/gpu/drm/nouveau/nouveau_acpi.c:191: error: redefinition of ‘nouveau_register_dsm_handler’
>>       drivers/gpu/drm/nouveau/nouveau_drv.h:859: note: previous definition of ‘nouveau_register_dsm_handler’ was here
>>       drivers/gpu/drm/nouveau/nouveau_acpi.c:202: error: redefinition of ‘nouveau_unregister_dsm_handler’
>>       drivers/gpu/drm/nouveau/nouveau_drv.h:860: note: previous definition of ‘nouveau_unregister_dsm_handler’ was here
>>
>> because not only was that VGA_SWITCHEROO Kconfig default the wrong way
>> around, the thing had clearly never ever been tested at all.
>>
>> Why does sh*t like this even make it to me? Was this ever at all in -next?
>> I assume not, since that would have picked up on basic compile failures.
>>
>> Grr. Things like this is what makes me go "Ok, there's always the next
>> merge window, maybe it will have gotten some testing by then".
>
> Linux next didn't pick up this build failure, wierdly neither did the
> powerpc build I did with this turned off, because ACPI was also off on
> ppc, it was in linux-next for at least 2 days, and from what I can see
> that found the ppc problems, it never found the x86 option since it was on
> by default.
>
> I'm going to just rip the nouveau bits out of the patch, btw nouveau is in
> staging, so you are being a bit OTT, calm down.\

Anyways sfr just confirmed linux-next doesn't build CONFIG_STAGING
drivers so again that wouldn't have helped. So you made us pull nouveau
into staging, now you are giving out because staging drivers have issues?

In any case I've fixed the default y and the STAGING build in my tree.

Did I mention that driver is in STAGING?

Dave.

Re: [git pull] drm request 2

[Linus Torvalds]

On Wed, 3 Mar 2010, Dave Airlie wrote:
>
> Did I mention that driver is in STAGING?

Staging is for _improving_ the quality of the drivers, not for making it 
worse.

We still very much have quality standards. The staging tree is for things 
to get in that don't quite _reach_ the standards we expect, but it's not a 
blanket excuse for not testing things.

And yes, I expect that stuff can be a bit rough during the merge window, 
after all, the whole point is that we can fix things up. But quite 
frankly, if _I_ find problems on the few machines I personally build and 
test on, then what does that say about the bigger picture?

IOW, I refuse to pull code that doesn't even work for me. If I did, where 
would we end up? What do you think should be my minimal quality 
requirements, if "Oh, it doesn't even build for me" is too much to ask 
for?

So if I find code that doesn't work, I'm not going to just say "whatever". 
I'm going to reject it.

			Linus

Re: [git pull] drm request 2

[Dave Airlie]

On Wed, Mar 3, 2010 at 9:40 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 3 Mar 2010, Dave Airlie wrote:
>>
>> Did I mention that driver is in STAGING?
>
> Staging is for _improving_ the quality of the drivers, not for making it
> worse.
>
> We still very much have quality standards. The staging tree is for things
> to get in that don't quite _reach_ the standards we expect, but it's not a
> blanket excuse for not testing things.
>
> And yes, I expect that stuff can be a bit rough during the merge window,
> after all, the whole point is that we can fix things up. But quite
> frankly, if _I_ find problems on the few machines I personally build and
> test on, then what does that say about the bigger picture?
>
> IOW, I refuse to pull code that doesn't even work for me. If I did, where
> would we end up? What do you think should be my minimal quality
> requirements, if "Oh, it doesn't even build for me" is too much to ask
> for?
>
> So if I find code that doesn't work, I'm not going to just say "whatever".
> I'm going to reject it.

So can we get linux-next builds to build with *your* Kconfig? This should
cut down the amount of crap you see considerably.

I'm not saying we have too many configuration options and testing them all
is insane, granted I admit I should have found this one since I do generally
try and build with nouveau on here.

I've sent a new pull, take it or not it builds here at least under
staging/acpi/vga_switcheroo off

Dave.

Re: [git pull] drm request 2

[Linus Torvalds]

On Wed, 3 Mar 2010, Dave Airlie wrote:
> 
> So can we get linux-next builds to build with *your* Kconfig? This should
> cut down the amount of crap you see considerably.

No.

Dave, _think_ about what you're saying.

The absolute last thing we want to do is to make it easier for crap to 
flow through the system.

We don't want to make it easier to hide problems. 

I think we might want to instead extend on the tests that linux-next does. 
For example, STAGING should generally always compile.

There are exceptions - major "change the world" changes where staging 
drivers might not be updated in as timely a manner as other drivers, but 
they should be exceptions, not the rule.

If a driver really doesn't even compile, it should be marked BROKEN, not 
STAGING.

			Linus

Re: [git pull] drm request 2

[Thomas Backlund]

03.03.2010 01:02, Dave Airlie skrev:
>>> x86 after PPC (I think I just validated Ingo).
>>
>> Why is VGA_SWITCHEROO enabled by default?
>
> because it does nothing on anything except the laptops in question and on
> those it does nothing except add a control file in debugfs?
>
> So how am I supposed to indicate to distro vendors that something should
> be turned on? If you think that distro kernel maintainers really
> understand every config option that goes past, I've got a bridge.
>

Yep. If the help-text for a new config option is well written, a kernel 
maintainer will have no problem deciding what to do.
(the help text for the config in question is wery well written, thanks
  to whoever wrote that)

And this specific option/feature is already requested by endusers, so no
maintainer will be able to "miss it" :-)

--
Thomas