into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

If we build >1 DRM driver into the kernel, we get this lovely output..

[drm] Initialized tdfx 1.0.0 20010216 on minor 0
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized r128 2.3.0 20021029 on minor 1
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized radeon 1.8.0 20020828 on minor 2
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized mga 3.1.0 20021029 on minor 3
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized i810 1.2.1 20020211 on minor 4
[drm] AGP 0.100 aperture @ 0xe0000000 64MB
[drm] Initialized i830 1.3.2 20021108 on minor 5

agpgart already outputs the info about the aperture address & size
before drm initialises, so its just repetition for no purpose.

Spotted by Andi Kleen. AMD64 is the architecture, not the CPU.

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

into home.transmeta.com:/home/torvalds/v2.5/linux

  - compilation fixes
  - enhanced linux/pnp.h:
      pnp_device_is_isapnp(dev)
      pnp_device_is_pnpbios(dev)
      isapnp_card_number(dev)
      isapnp_csn_number(dev)

  - documentation
  - control API - added multi-elements to reduce memory usage
  - improved preallocation of DMA buffers
  - CS46xx driver - added support for secondary codec
  - HDSP driver - big update
    - firmware is loaded with hdsptool now
  - pmac driver updates (fixed oops and beep stuff)
  - VIA82xx driver updated
  - ymfpci driver updated 
  - drivers updated to new PnP layer
    - wavefront, ad1816a, cs423x, es18xx, interwave, opl3sa2, cmi8330
    

Add user pointer annotations.

into kernel.bkbits.net:/home/davem/net-2.5

into kernel.bkbits.net:/home/davem/sparc-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into nuts.ninka.net:/home/davem/src/BK/sparc-2.5

on the list-head being at the top of the DRI data structures and
using hard casts.

into home.transmeta.com:/home/torvalds/v2.5/linux

All the other GART drivers display what they've found, so make this
one follow suit.

Offering the K7 GARTs on 64bit kernels causes sillyness, like reports of
"unrecognised device, try unsupported".  We don't want people to even try
that, so don't offer it in the first place.

There's really no good reason for offering any of the IA32 era GARTs on a
x86-64 64bit kernel. If Intel (or whoever) ever do an x86-64 clone, a new
gart driver will be started anyways, as has been done for amd-k8-agp.

This optioned saved just a handful of bytes, and uglied up the code 
quite a lot. Saving less than a page of memory is not as important as
maintainable code.