Merge git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
authorLinus Torvalds <torvalds@linux-foundation.org>
Wed, 1 Apr 2009 17:02:15 +0000 (10:02 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Wed, 1 Apr 2009 17:02:15 +0000 (10:02 -0700)
* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: (59 commits)
  ide-floppy: do not complete rq's prematurely
  ide: be able to build pmac driver without IDE built-in
  ide-pmac: IDE cable detection on Apple PowerBook
  ide: inline SELECT_DRIVE()
  ide: turn selectproc() method into dev_select() method (take 5)
  MAINTAINERS: move old ide-{floppy,tape} entries to CREDITS (take 2)
  ide: move data register access out of tf_{read|load}() methods (take 2)
  ide: call {in|out}put_data() methods from tf_{read|load}() methods (take 2)
  ide-io-std: shorten ide_{in|out}put_data()
  ide: rename IDE_TFLAG_IN_[HOB_]FEATURE
  ide: turn set_irq() method into write_devctl() method
  ide: use ATA_HOB
  ide-disk: use ATA_ERR
  ide: add support for CFA specified transfer modes (take 3)
  ide-iops: only clear DMA words on setting DMA mode
  ide: identify data word 53 bit 1 doesn't cover words 62 and 63 (take 3)
  au1xxx-ide: auide_{in|out}sw() should be static
  ide-floppy: use ide_pio_bytes()
  ide-{floppy,tape}: fix padding for PIO transfers
  ide: remove CONFIG_BLK_DEV_IDEDOUBLER config option
  ...

629 files changed:
Documentation/ABI/testing/sysfs-bus-pci
Documentation/DMA-API.txt
Documentation/DocBook/kernel-api.tmpl
Documentation/DocBook/procfs_example.c
Documentation/PCI/MSI-HOWTO.txt
Documentation/PCI/pci-iov-howto.txt [new file with mode: 0644]
Documentation/fb/00-INDEX
Documentation/fb/cyblafb/bugs [deleted file]
Documentation/fb/cyblafb/credits [deleted file]
Documentation/fb/cyblafb/documentation [deleted file]
Documentation/fb/cyblafb/fb.modes [deleted file]
Documentation/fb/cyblafb/performance [deleted file]
Documentation/fb/cyblafb/todo [deleted file]
Documentation/fb/cyblafb/usage [deleted file]
Documentation/fb/cyblafb/whatsnew [deleted file]
Documentation/fb/cyblafb/whycyblafb [deleted file]
Documentation/feature-removal-schedule.txt
Documentation/filesystems/Locking
Documentation/filesystems/sysfs-pci.txt
Documentation/hwmon/ds1621
Documentation/hwmon/lis3lv02d
Documentation/hwmon/ltc4215 [new file with mode: 0644]
Documentation/hwmon/pcf8591 [moved from Documentation/i2c/chips/pcf8591 with 100% similarity]
Documentation/hwmon/sysfs-interface
Documentation/hwmon/w83627ehf
Documentation/kernel-parameters.txt
Documentation/lguest/lguest.c
Documentation/lockdep-design.txt
Documentation/misc-devices/isl29003 [new file with mode: 0644]
Documentation/powerpc/dts-bindings/mmc-spi-slot.txt [new file with mode: 0644]
Documentation/sysrq.txt
MAINTAINERS
arch/Kconfig
arch/alpha/include/asm/machvec.h
arch/alpha/include/asm/pci.h
arch/alpha/include/asm/system.h
arch/alpha/include/asm/types.h
arch/alpha/include/asm/uaccess.h
arch/alpha/include/asm/xchg.h [new file with mode: 0644]
arch/alpha/kernel/Makefile
arch/alpha/kernel/err_ev6.c
arch/alpha/kernel/err_ev7.c
arch/alpha/kernel/err_marvel.c
arch/alpha/kernel/err_titan.c
arch/alpha/kernel/pci-sysfs.c [new file with mode: 0644]
arch/alpha/kernel/pci.c
arch/alpha/kernel/pci_iommu.c
arch/alpha/kernel/proto.h
arch/alpha/kernel/setup.c
arch/alpha/kernel/smc37c669.c
arch/alpha/kernel/srm_env.c
arch/alpha/kernel/sys_jensen.c
arch/alpha/kernel/sys_sable.c
arch/alpha/kernel/traps.c
arch/avr32/mm/fault.c
arch/blackfin/mm/sram-alloc.c
arch/cris/arch-v10/kernel/time.c
arch/cris/arch-v32/kernel/smp.c
arch/cris/arch-v32/kernel/time.c
arch/frv/kernel/irq-mb93091.c
arch/frv/kernel/irq-mb93093.c
arch/frv/kernel/irq-mb93493.c
arch/frv/kernel/time.c
arch/h8300/kernel/timer/itu.c
arch/h8300/kernel/timer/timer16.c
arch/h8300/kernel/timer/timer8.c
arch/h8300/kernel/timer/tpu.c
arch/ia64/dig/Makefile
arch/ia64/dig/dig_vtd_iommu.c [deleted file]
arch/ia64/hp/common/hwsw_iommu.c
arch/ia64/hp/common/sba_iommu.c
arch/ia64/hp/sim/simserial.c
arch/ia64/include/asm/dma-mapping.h
arch/ia64/include/asm/machvec.h
arch/ia64/include/asm/machvec_dig_vtd.h
arch/ia64/include/asm/machvec_hpzx1.h
arch/ia64/include/asm/machvec_hpzx1_swiotlb.h
arch/ia64/include/asm/machvec_sn2.h
arch/ia64/include/asm/topology.h
arch/ia64/kernel/Makefile
arch/ia64/kernel/dma-mapping.c [new file with mode: 0644]
arch/ia64/kernel/machvec.c
arch/ia64/kernel/palinfo.c
arch/ia64/kernel/pci-dma.c
arch/ia64/kernel/pci-swiotlb.c
arch/ia64/kernel/time.c
arch/ia64/sn/kernel/sn2/prominfo_proc.c
arch/ia64/sn/pci/pci_dma.c
arch/m32r/kernel/time.c
arch/mips/cobalt/irq.c
arch/mips/emma/markeins/irq.c
arch/mips/include/asm/mach-bcm47xx/gpio.h
arch/mips/include/asm/mach-ip27/topology.h
arch/mips/jazz/irq.c
arch/mips/kernel/cevt-bcm1480.c
arch/mips/kernel/cevt-sb1250.c
arch/mips/kernel/i8253.c
arch/mips/kernel/i8259.c
arch/mips/lasat/interrupt.c
arch/mips/lemote/lm2e/irq.c
arch/mips/mm/highmem.c
arch/mips/sgi-ip27/ip27-nmi.c
arch/mips/sgi-ip32/ip32-irq.c
arch/mips/sni/rm200.c
arch/mips/vr41xx/common/irq.c
arch/mn10300/kernel/time.c
arch/parisc/kernel/time.c
arch/powerpc/Kconfig
arch/powerpc/Kconfig.debug
arch/powerpc/boot/dts/mpc832x_rdb.dts
arch/powerpc/include/asm/highmem.h
arch/powerpc/include/asm/pci.h
arch/powerpc/include/asm/suspend.h
arch/powerpc/include/asm/topology.h
arch/powerpc/kernel/msi.c
arch/powerpc/kernel/rtas_flash.c
arch/powerpc/platforms/83xx/mpc832x_rdb.c
arch/powerpc/platforms/85xx/mpc85xx_cds.c
arch/powerpc/platforms/8xx/m8xx_setup.c
arch/powerpc/platforms/chrp/setup.c
arch/powerpc/platforms/powermac/pic.c
arch/powerpc/platforms/powermac/smp.c
arch/powerpc/sysdev/cpm1.c
arch/powerpc/sysdev/fsl_soc.c
arch/powerpc/sysdev/fsl_soc.h
arch/s390/Kconfig
arch/s390/Kconfig.debug
arch/s390/hypfs/hypfs_diag.c
arch/s390/include/asm/cio.h
arch/sh/include/asm/topology.h
arch/sh/kernel/time_64.c
arch/sh/kernel/timers/timer-cmt.c
arch/sh/kernel/timers/timer-mtu2.c
arch/sh/kernel/timers/timer-tmu.c
arch/sparc/Kconfig
arch/sparc/Kconfig.debug
arch/sparc/include/asm/mmu_context_64.h
arch/sparc/include/asm/smp_64.h
arch/sparc/include/asm/system_32.h
arch/sparc/include/asm/topology_64.h
arch/sparc/kernel/ds.c
arch/sparc/kernel/irq_32.c
arch/sparc/kernel/irq_64.c
arch/sparc/kernel/led.c
arch/sparc/kernel/mdesc.c
arch/sparc/kernel/nmi.c
arch/sparc/kernel/prom_64.c
arch/sparc/kernel/smp_32.c
arch/sparc/kernel/smp_64.c
arch/sparc/kernel/sun4d_irq.c
arch/sparc/kernel/sun4d_smp.c
arch/sparc/kernel/sun4m_smp.c
arch/sparc/mm/highmem.c
arch/sparc/mm/init_64.c
arch/sparc/mm/srmmu.c
arch/um/drivers/pcap_user.h
arch/um/drivers/port.h
arch/um/drivers/ssl.h
arch/um/drivers/stdio_console.h
arch/um/drivers/ubd_kern.c
arch/um/drivers/xterm.h
arch/um/include/asm/irq_vectors.h
arch/um/include/asm/mmu.h
arch/um/include/asm/pda.h
arch/um/include/asm/pgalloc.h
arch/um/include/asm/pgtable-3level.h
arch/um/include/shared/frame_kern.h
arch/um/include/shared/initrd.h
arch/um/include/shared/irq_kern.h
arch/um/include/shared/mem_kern.h
arch/um/include/shared/ubd_user.h
arch/um/kernel/Makefile
arch/um/kernel/config.c.in
arch/um/os-Linux/start_up.c
arch/um/sys-i386/asm/archparam.h
arch/um/sys-i386/shared/sysdep/checksum.h
arch/um/sys-ia64/sysdep/ptrace.h
arch/um/sys-ia64/sysdep/sigcontext.h
arch/um/sys-ia64/sysdep/syscalls.h
arch/um/sys-ppc/miscthings.c
arch/um/sys-ppc/ptrace.c
arch/um/sys-ppc/ptrace_user.c
arch/um/sys-ppc/shared/sysdep/ptrace.h
arch/um/sys-ppc/shared/sysdep/sigcontext.h
arch/um/sys-ppc/shared/sysdep/syscalls.h
arch/um/sys-ppc/sigcontext.c
arch/um/sys-x86_64/asm/archparam.h
arch/um/sys-x86_64/asm/module.h
arch/um/sys-x86_64/mem.c
arch/x86/Kconfig
arch/x86/Kconfig.debug
arch/x86/include/asm/device.h
arch/x86/include/asm/dma-mapping.h
arch/x86/include/asm/iommu.h
arch/x86/include/asm/lguest_hcall.h
arch/x86/include/asm/pci.h
arch/x86/include/asm/suspend_32.h
arch/x86/include/asm/topology.h
arch/x86/kernel/Makefile
arch/x86/kernel/amd_iommu.c
arch/x86/kernel/apic/io_apic.c
arch/x86/kernel/apm_32.c
arch/x86/kernel/asm-offsets_32.c
arch/x86/kernel/asm-offsets_64.c
arch/x86/kernel/cpu/mtrr/if.c
arch/x86/kernel/irqinit_32.c
arch/x86/kernel/irqinit_64.c
arch/x86/kernel/mfgpt_32.c
arch/x86/kernel/pci-calgary_64.c
arch/x86/kernel/pci-dma.c
arch/x86/kernel/pci-gart_64.c
arch/x86/kernel/pci-nommu.c
arch/x86/kernel/pci-swiotlb.c [moved from arch/x86/kernel/pci-swiotlb_64.c with 81% similarity]
arch/x86/kernel/setup.c
arch/x86/kernel/time_64.c
arch/x86/kernel/vmiclock_32.c
arch/x86/lguest/boot.c
arch/x86/lguest/i386_head.S
arch/x86/mm/highmem_32.c
arch/x86/mm/iomap_32.c
arch/x86/pci/early.c
arch/x86/pci/fixup.c
arch/x86/pci/legacy.c
arch/x86/pci/mmconfig-shared.c
arch/x86/pci/mmconfig_64.c
arch/x86/power/cpu_32.c
arch/x86/power/cpu_64.c
arch/x86/power/hibernate_64.c
arch/xtensa/platforms/iss/console.c
drivers/acpi/ac.c
drivers/acpi/battery.c
drivers/acpi/button.c
drivers/acpi/fan.c
drivers/acpi/pci_root.c
drivers/acpi/processor_core.c
drivers/acpi/sbs.c
drivers/acpi/thermal.c
drivers/acpi/video.c
drivers/auxdisplay/Kconfig
drivers/base/cpu.c
drivers/base/iommu.c
drivers/base/power/main.c
drivers/base/sys.c
drivers/block/loop.c
drivers/block/ps3vram.c
drivers/char/amiserial.c
drivers/char/cyclades.c
drivers/char/ip2/ip2main.c
drivers/char/ipmi/ipmi_msghandler.c
drivers/char/ipmi/ipmi_si_intf.c
drivers/char/istallion.c
drivers/char/pcmcia/synclink_cs.c
drivers/char/stallion.c
drivers/char/synclink.c
drivers/char/synclink_gt.c
drivers/char/synclinkmp.c
drivers/char/sysrq.c
drivers/char/tty_io.c
drivers/firmware/dmi_scan.c
drivers/gpu/drm/ati_pcigart.c
drivers/gpu/drm/drm_bufs.c
drivers/gpu/drm/drm_context.c
drivers/gpu/drm/drm_drv.c
drivers/gpu/drm/drm_edid.c
drivers/gpu/drm/drm_fops.c
drivers/gpu/drm/drm_gem.c
drivers/gpu/drm/drm_info.c
drivers/gpu/drm/drm_ioc32.c
drivers/gpu/drm/drm_memory.c
drivers/gpu/drm/drm_proc.c
drivers/gpu/drm/drm_stub.c
drivers/gpu/drm/drm_sysfs.c
drivers/gpu/drm/drm_vm.c
drivers/gpu/drm/i810/i810_drv.h
drivers/gpu/drm/i830/i830_drv.h
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/i915_drv.c
drivers/gpu/drm/i915/i915_gem.c
drivers/gpu/drm/mga/mga_dma.c
drivers/gpu/drm/mga/mga_drv.h
drivers/gpu/drm/r128/r128_cce.c
drivers/gpu/drm/radeon/Makefile
drivers/gpu/drm/radeon/r300_cmdbuf.c
drivers/gpu/drm/radeon/r300_reg.h
drivers/gpu/drm/radeon/r600_cp.c [new file with mode: 0644]
drivers/gpu/drm/radeon/r600_microcode.h [new file with mode: 0644]
drivers/gpu/drm/radeon/radeon_cp.c
drivers/gpu/drm/radeon/radeon_drv.c
drivers/gpu/drm/radeon/radeon_drv.h
drivers/gpu/drm/radeon/radeon_irq.c
drivers/gpu/drm/radeon/radeon_state.c
drivers/gpu/drm/savage/savage_bci.c
drivers/gpu/drm/via/via_drv.c
drivers/hwmon/Kconfig
drivers/hwmon/Makefile
drivers/hwmon/ds1621.c
drivers/hwmon/fschmd.c
drivers/hwmon/hdaps.c
drivers/hwmon/hp_accel.c
drivers/hwmon/lis3lv02d.c
drivers/hwmon/lis3lv02d.h
drivers/hwmon/lis3lv02d_spi.c [new file with mode: 0644]
drivers/hwmon/lm95241.c [new file with mode: 0644]
drivers/hwmon/ltc4215.c [new file with mode: 0644]
drivers/hwmon/pcf8591.c [moved from drivers/i2c/chips/pcf8591.c with 96% similarity]
drivers/hwmon/w83627ehf.c
drivers/i2c/busses/i2c-i801.c
drivers/i2c/chips/Kconfig
drivers/i2c/chips/Makefile
drivers/input/input.c
drivers/isdn/capi/capi.c
drivers/isdn/hardware/eicon/divasi.c
drivers/lguest/core.c
drivers/lguest/interrupts_and_traps.c
drivers/lguest/lg.h
drivers/lguest/lguest_device.c
drivers/lguest/page_tables.c
drivers/lguest/segments.c
drivers/lguest/x86/core.c
drivers/media/video/cpia.c
drivers/message/i2o/i2o_proc.c
drivers/misc/Kconfig
drivers/misc/Makefile
drivers/misc/hpilo.c
drivers/misc/hpilo.h
drivers/misc/isl29003.c [new file with mode: 0644]
drivers/mmc/card/sdio_uart.c
drivers/net/bonding/bond_main.c
drivers/net/gianfar.c
drivers/net/hamradio/dmascc.c
drivers/net/irda/vlsi_ir.c
drivers/net/netconsole.c
drivers/net/ni5010.c
drivers/net/niu.c
drivers/net/tg3.c
drivers/net/ucc_geth.c
drivers/net/wireless/airo.c
drivers/net/wireless/ipw2x00/ipw2200.c
drivers/net/wireless/prism54/islpci_dev.c
drivers/net/wireless/zd1201.c
drivers/of/base.c
drivers/oprofile/buffer_sync.c
drivers/pci/Kconfig
drivers/pci/Makefile
drivers/pci/bus.c
drivers/pci/hotplug/acpi_pcihp.c
drivers/pci/hotplug/fakephp.c
drivers/pci/hotplug/pciehp.h
drivers/pci/hotplug/pciehp_acpi.c
drivers/pci/hotplug/pciehp_core.c
drivers/pci/hotplug/pciehp_hpc.c
drivers/pci/hotplug/shpchp.h
drivers/pci/hotplug/shpchp_pci.c
drivers/pci/intel-iommu.c
drivers/pci/iov.c [new file with mode: 0644]
drivers/pci/msi.c
drivers/pci/msi.h
drivers/pci/pci-acpi.c
drivers/pci/pci-driver.c
drivers/pci/pci-sysfs.c
drivers/pci/pci.c
drivers/pci/pci.h
drivers/pci/pcie/aer/aerdrv.c
drivers/pci/pcie/aer/aerdrv_acpi.c
drivers/pci/pcie/aer/aerdrv_core.c
drivers/pci/pcie/portdrv.h
drivers/pci/pcie/portdrv_bus.c
drivers/pci/pcie/portdrv_core.c
drivers/pci/pcie/portdrv_pci.c
drivers/pci/probe.c
drivers/pci/quirks.c
drivers/pci/remove.c
drivers/pci/search.c
drivers/pci/setup-bus.c
drivers/pci/setup-res.c
drivers/pci/slot.c
drivers/platform/x86/asus_acpi.c
drivers/platform/x86/dell-laptop.c
drivers/platform/x86/thinkpad_acpi.c
drivers/platform/x86/toshiba_acpi.c
drivers/rtc/Kconfig
drivers/rtc/Makefile
drivers/rtc/rtc-ds1307.c
drivers/rtc/rtc-ds1374.c
drivers/rtc/rtc-efi.c [new file with mode: 0644]
drivers/rtc/rtc-lib.c
drivers/rtc/rtc-parisc.c
drivers/rtc/rtc-proc.c
drivers/rtc/rtc-v3020.c
drivers/rtc/rtc-wm8350.c
drivers/s390/block/dasd.c
drivers/s390/block/dasd_proc.c
drivers/s390/cio/device.c
drivers/s390/cio/device.h
drivers/s390/cio/device_fsm.c
drivers/s390/scsi/zfcp_ccw.c
drivers/scsi/scsi_devinfo.c
drivers/scsi/scsi_proc.c
drivers/serial/serial_core.c
drivers/spi/spi_mpc83xx.c
drivers/usb/serial/usb-serial.c
drivers/video/68328fb.c
drivers/video/Kconfig
drivers/video/Makefile
drivers/video/amba-clcd.c
drivers/video/amifb.c
drivers/video/arkfb.c
drivers/video/asiliantfb.c
drivers/video/aty/mach64_accel.c
drivers/video/aty/mach64_cursor.c
drivers/video/aty/radeon_pm.c
drivers/video/backlight/backlight.c
drivers/video/backlight/lcd.c
drivers/video/cirrusfb.c
drivers/video/console/fbcon.c
drivers/video/cyblafb.c [deleted file]
drivers/video/efifb.c
drivers/video/fb_defio.c
drivers/video/fbmem.c
drivers/video/nvidia/nv_type.h
drivers/video/nvidia/nvidia.c
drivers/video/omap/hwa742.c
drivers/video/omap/omapfb_main.c
drivers/video/s1d13xxxfb.c
drivers/video/s3c-fb.c [new file with mode: 0644]
drivers/video/sgivwfb.c
drivers/video/skeletonfb.c
drivers/video/sm501fb.c
drivers/video/sstfb.c
drivers/video/stifb.c
drivers/video/sunxvr500.c
drivers/video/tdfxfb.c
drivers/video/tgafb.c
drivers/video/tridentfb.c
drivers/video/uvesafb.c
drivers/video/valkyriefb.c
drivers/video/vesafb.c
drivers/video/vfb.c
drivers/video/via/accel.c
drivers/video/via/viafbdev.c
drivers/virtio/virtio_ring.c
drivers/watchdog/hpwdt.c
drivers/xen/manage.c
fs/afs/proc.c
fs/autofs4/autofs_i.h
fs/autofs4/dev-ioctl.c
fs/autofs4/expire.c
fs/autofs4/root.c
fs/btrfs/ctree.h
fs/btrfs/inode.c
fs/buffer.c
fs/cifs/cifs_debug.c
fs/ecryptfs/keystore.c
fs/ecryptfs/messaging.c
fs/eventfd.c
fs/eventpoll.c
fs/ext4/ext4.h
fs/ext4/inode.c
fs/fuse/file.c
fs/gfs2/ops_file.c
fs/hugetlbfs/inode.c
fs/jfs/jfs_debug.c
fs/nfs/client.c
fs/nfs/file.c
fs/ntfs/dir.c
fs/ntfs/inode.c
fs/ntfs/layout.h
fs/ntfs/logfile.h
fs/ntfs/mft.c
fs/ntfs/super.c
fs/ntfs/usnjrnl.h
fs/ocfs2/mmap.c
fs/proc/generic.c
fs/proc/inode-alloc.txt [deleted file]
fs/proc/inode.c
fs/proc/internal.h
fs/proc/proc_tty.c
fs/proc/task_mmu.c
fs/proc/uptime.c
fs/ramfs/file-nommu.c
fs/ramfs/inode.c
fs/reiserfs/procfs.c
fs/reiserfs/xattr.c
fs/seq_file.c
fs/sysfs/bin.c
fs/ubifs/file.c
fs/xfs/linux-2.6/xfs_file.c
include/asm-frv/highmem.h
include/asm-generic/dma-mapping.h [deleted file]
include/asm-generic/topology.h
include/asm-mn10300/highmem.h
include/drm/drmP.h
include/drm/drm_crtc.h
include/drm/drm_os_linux.h
include/drm/drm_pciids.h
include/drm/radeon_drm.h
include/linux/acpi.h
include/linux/auto_dev-ioctl.h
include/linux/auto_fs.h
include/linux/bootmem.h
include/linux/buffer_head.h
include/linux/cpuset.h
include/linux/dma-debug.h [new file with mode: 0644]
include/linux/dma-mapping.h
include/linux/dmi.h
include/linux/eventfd.h
include/linux/fb.h
include/linux/fs.h
include/linux/fsl_devices.h
include/linux/highmem.h
include/linux/intel-iommu.h
include/linux/interrupt.h
include/linux/ipmi_smi.h
include/linux/irq.h
include/linux/kernel.h
include/linux/lockdep.h
include/linux/loop.h
include/linux/mm.h
include/linux/mm_types.h
include/linux/mmzone.h
include/linux/msi.h
include/linux/mutex.h
include/linux/netpoll.h
include/linux/page-debug-flags.h [new file with mode: 0644]
include/linux/page-flags.h
include/linux/pagevec.h
include/linux/pci-acpi.h
include/linux/pci.h
include/linux/pci_ids.h
include/linux/pci_regs.h
include/linux/pcieport_if.h
include/linux/poison.h
include/linux/proc_fs.h
include/linux/reiserfs_acl.h
include/linux/rtc.h
include/linux/sched.h
include/linux/seq_file.h
include/linux/skbuff.h
include/linux/string.h
include/linux/suspend.h
include/linux/swap.h
include/linux/swiotlb.h
include/linux/timer.h
include/linux/tty_driver.h
include/linux/wait.h
include/linux/writeback.h
include/video/aty128.h
include/video/cirrus.h
include/video/newport.h
include/video/radeon.h
include/video/s1d13xxxfb.h
init/main.c
kernel/cpu.c
kernel/fork.c
kernel/irq/Makefile
kernel/irq/internals.h
kernel/irq/manage.c
kernel/irq/pm.c [new file with mode: 0644]
kernel/kexec.c
kernel/kmod.c
kernel/kthread.c
kernel/lockdep.c
kernel/lockdep_internals.h
kernel/lockdep_proc.c
kernel/lockdep_states.h [new file with mode: 0644]
kernel/mutex-debug.c
kernel/mutex-debug.h
kernel/mutex.c
kernel/mutex.h
kernel/power/disk.c
kernel/power/main.c
kernel/power/snapshot.c
kernel/power/swsusp.c
kernel/rcutorture.c
kernel/sched.c
kernel/sched_cpupri.h
kernel/sched_features.h
kernel/stop_machine.c
kernel/sysctl.c
kernel/timer.c
kernel/workqueue.c
lib/Kconfig.debug
lib/Makefile
lib/dma-debug.c [new file with mode: 0644]
lib/rbtree.c
lib/swiotlb.c
mm/Kconfig
mm/Kconfig.debug [new file with mode: 0644]
mm/Makefile
mm/allocpercpu.c
mm/debug-pagealloc.c [new file with mode: 0644]
mm/highmem.c
mm/hugetlb.c
mm/internal.h
mm/memory.c
mm/oom_kill.c
mm/page-writeback.c
mm/page_alloc.c
mm/pdflush.c
mm/shmem.c
mm/slab.c
mm/slob.c
mm/slub.c
mm/sparse.c
mm/swap.c
mm/util.c
mm/vmalloc.c
mm/vmscan.c
mm/vmstat.c
net/appletalk/atalk_proc.c
net/atm/mpoa_proc.c
net/atm/proc.c
net/bluetooth/rfcomm/tty.c
net/can/bcm.c
net/can/proc.c
net/core/netpoll.c
net/core/pktgen.c
net/core/skbuff.c
net/core/sock.c
net/irda/ircomm/ircomm_tty.c
net/irda/irproc.c
net/llc/llc_proc.c
net/netfilter/nf_conntrack_irc.c
net/netfilter/xt_cluster.c
net/sctp/protocol.c
net/sunrpc/cache.c
net/sunrpc/stats.c
net/sunrpc/svc.c
sound/core/info.c

index e638e15a8895abef445cedccb2df273f1e3ad0e1..97ad190e13af0586a528bbb7e6dfb10e748eddcd 100644 (file)
@@ -41,6 +41,49 @@ Description:
                for the device and attempt to bind to it.  For example:
                # echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
 
+What:          /sys/bus/pci/drivers/.../remove_id
+Date:          February 2009
+Contact:       Chris Wright <chrisw@sous-sol.org>
+Description:
+               Writing a device ID to this file will remove an ID
+               that was dynamically added via the new_id sysfs entry.
+               The format for the device ID is:
+               VVVV DDDD SVVV SDDD CCCC MMMM.  That is Vendor ID, Device
+               ID, Subsystem Vendor ID, Subsystem Device ID, Class,
+               and Class Mask.  The Vendor ID and Device ID fields are
+               required, the rest are optional.  After successfully
+               removing an ID, the driver will no longer support the
+               device.  This is useful to ensure auto probing won't
+               match the driver to the device.  For example:
+               # echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id
+
+What:          /sys/bus/pci/rescan
+Date:          January 2009
+Contact:       Linux PCI developers <linux-pci@vger.kernel.org>
+Description:
+               Writing a non-zero value to this attribute will
+               force a rescan of all PCI buses in the system, and
+               re-discover previously removed devices.
+               Depends on CONFIG_HOTPLUG.
+
+What:          /sys/bus/pci/devices/.../remove
+Date:          January 2009
+Contact:       Linux PCI developers <linux-pci@vger.kernel.org>
+Description:
+               Writing a non-zero value to this attribute will
+               hot-remove the PCI device and any of its children.
+               Depends on CONFIG_HOTPLUG.
+
+What:          /sys/bus/pci/devices/.../rescan
+Date:          January 2009
+Contact:       Linux PCI developers <linux-pci@vger.kernel.org>
+Description:
+               Writing a non-zero value to this attribute will
+               force a rescan of the device's parent bus and all
+               child buses, and re-discover devices removed earlier
+               from this part of the device tree.
+               Depends on CONFIG_HOTPLUG.
+
 What:          /sys/bus/pci/devices/.../vpd
 Date:          February 2008
 Contact:       Ben Hutchings <bhutchings@solarflare.com>
@@ -52,3 +95,30 @@ Description:
                that some devices may have malformatted data.  If the
                underlying VPD has a writable section then the
                corresponding section of this file will be writable.
+
+What:          /sys/bus/pci/devices/.../virtfnN
+Date:          March 2009
+Contact:       Yu Zhao <yu.zhao@intel.com>
+Description:
+               This symbolic link appears when hardware supports the SR-IOV
+               capability and the Physical Function driver has enabled it.
+               The symbolic link points to the PCI device sysfs entry of the
+               Virtual Function whose index is N (0...MaxVFs-1).
+
+What:          /sys/bus/pci/devices/.../dep_link
+Date:          March 2009
+Contact:       Yu Zhao <yu.zhao@intel.com>
+Description:
+               This symbolic link appears when hardware supports the SR-IOV
+               capability and the Physical Function driver has enabled it,
+               and this device has vendor specific dependencies with others.
+               The symbolic link points to the PCI device sysfs entry of
+               Physical Function this device depends on.
+
+What:          /sys/bus/pci/devices/.../physfn
+Date:          March 2009
+Contact:       Yu Zhao <yu.zhao@intel.com>
+Description:
+               This symbolic link appears when a device is a Virtual Function.
+               The symbolic link points to the PCI device sysfs entry of the
+               Physical Function this device associates with.
index 2a3fcc55e98157b83a514c98c0e13fcd71bab30a..d9aa43d78bcc9fc92e582a62cadb18cd9b27f4f0 100644 (file)
@@ -609,3 +609,109 @@ size is the size (and should be a page-sized multiple).
 The return value will be either a pointer to the processor virtual
 address of the memory, or an error (via PTR_ERR()) if any part of the
 region is occupied.
+
+Part III - Debug drivers use of the DMA-API
+-------------------------------------------
+
+The DMA-API as described above as some constraints. DMA addresses must be
+released with the corresponding function with the same size for example. With
+the advent of hardware IOMMUs it becomes more and more important that drivers
+do not violate those constraints. In the worst case such a violation can
+result in data corruption up to destroyed filesystems.
+
+To debug drivers and find bugs in the usage of the DMA-API checking code can
+be compiled into the kernel which will tell the developer about those
+violations. If your architecture supports it you can select the "Enable
+debugging of DMA-API usage" option in your kernel configuration. Enabling this
+option has a performance impact. Do not enable it in production kernels.
+
+If you boot the resulting kernel will contain code which does some bookkeeping
+about what DMA memory was allocated for which device. If this code detects an
+error it prints a warning message with some details into your kernel log. An
+example warning message may look like this:
+
+------------[ cut here ]------------
+WARNING: at /data2/repos/linux-2.6-iommu/lib/dma-debug.c:448
+       check_unmap+0x203/0x490()
+Hardware name:
+forcedeth 0000:00:08.0: DMA-API: device driver frees DMA memory with wrong
+       function [device address=0x00000000640444be] [size=66 bytes] [mapped as
+single] [unmapped as page]
+Modules linked in: nfsd exportfs bridge stp llc r8169
+Pid: 0, comm: swapper Tainted: G        W  2.6.28-dmatest-09289-g8bb99c0 #1
+Call Trace:
+ <IRQ>  [<ffffffff80240b22>] warn_slowpath+0xf2/0x130
+ [<ffffffff80647b70>] _spin_unlock+0x10/0x30
+ [<ffffffff80537e75>] usb_hcd_link_urb_to_ep+0x75/0xc0
+ [<ffffffff80647c22>] _spin_unlock_irqrestore+0x12/0x40
+ [<ffffffff8055347f>] ohci_urb_enqueue+0x19f/0x7c0
+ [<ffffffff80252f96>] queue_work+0x56/0x60
+ [<ffffffff80237e10>] enqueue_task_fair+0x20/0x50
+ [<ffffffff80539279>] usb_hcd_submit_urb+0x379/0xbc0
+ [<ffffffff803b78c3>] cpumask_next_and+0x23/0x40
+ [<ffffffff80235177>] find_busiest_group+0x207/0x8a0
+ [<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50
+ [<ffffffff803c7ea3>] check_unmap+0x203/0x490
+ [<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50
+ [<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0
+ [<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0
+ [<ffffffff8026df84>] handle_IRQ_event+0x34/0x70
+ [<ffffffff8026ffe9>] handle_edge_irq+0xc9/0x150
+ [<ffffffff8020e3ab>] do_IRQ+0xcb/0x1c0
+ [<ffffffff8020c093>] ret_from_intr+0x0/0xa
+ <EOI> <4>---[ end trace f6435a98e2a38c0e ]---
+
+The driver developer can find the driver and the device including a stacktrace
+of the DMA-API call which caused this warning.
+
+Per default only the first error will result in a warning message. All other
+errors will only silently counted. This limitation exist to prevent the code
+from flooding your kernel log. To support debugging a device driver this can
+be disabled via debugfs. See the debugfs interface documentation below for
+details.
+
+The debugfs directory for the DMA-API debugging code is called dma-api/. In
+this directory the following files can currently be found:
+
+       dma-api/all_errors      This file contains a numeric value. If this
+                               value is not equal to zero the debugging code
+                               will print a warning for every error it finds
+                               into the kernel log. Be carefull with this
+                               option. It can easily flood your logs.
+
+       dma-api/disabled        This read-only file contains the character 'Y'
+                               if the debugging code is disabled. This can
+                               happen when it runs out of memory or if it was
+                               disabled at boot time
+
+       dma-api/error_count     This file is read-only and shows the total
+                               numbers of errors found.
+
+       dma-api/num_errors      The number in this file shows how many
+                               warnings will be printed to the kernel log
+                               before it stops. This number is initialized to
+                               one at system boot and be set by writing into
+                               this file
+
+       dma-api/min_free_entries
+                               This read-only file can be read to get the
+                               minimum number of free dma_debug_entries the
+                               allocator has ever seen. If this value goes
+                               down to zero the code will disable itself
+                               because it is not longer reliable.
+
+       dma-api/num_free_entries
+                               The current number of free dma_debug_entries
+                               in the allocator.
+
+If you have this code compiled into your kernel it will be enabled by default.
+If you want to boot without the bookkeeping anyway you can provide
+'dma_debug=off' as a boot parameter. This will disable DMA-API debugging.
+Notice that you can not enable it again at runtime. You have to reboot to do
+so.
+
+When the code disables itself at runtime this is most likely because it ran
+out of dma_debug_entries. These entries are preallocated at boot. The number
+of preallocated entries is defined per architecture. If it is too low for you
+boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
+architectural default.
index bc962cda650485aea9cddcced9823ef39a3252b6..58c194572c763c8cfcba3e6c607f91220115e977 100644 (file)
@@ -199,6 +199,7 @@ X!Edrivers/pci/hotplug.c
 -->
 !Edrivers/pci/probe.c
 !Edrivers/pci/rom.c
+!Edrivers/pci/iov.c
      </sect1>
      <sect1><title>PCI Hotplug Support Library</title>
 !Edrivers/pci/hotplug/pci_hotplug_core.c
index 8c6396e4bf311901a19fd717500c422eeba4869a..a5b11793b1e0167bf32d1b1a19d13aca7a424aa5 100644 (file)
@@ -117,9 +117,6 @@ static int __init init_procfs_example(void)
                rv = -ENOMEM;
                goto out;
        }
-       
-       example_dir->owner = THIS_MODULE;
-       
        /* create jiffies using convenience function */
        jiffies_file = create_proc_read_entry("jiffies", 
                                              0444, example_dir, 
@@ -130,8 +127,6 @@ static int __init init_procfs_example(void)
                goto no_jiffies;
        }
 
-       jiffies_file->owner = THIS_MODULE;
-
        /* create foo and bar files using same callback
         * functions 
         */
@@ -146,7 +141,6 @@ static int __init init_procfs_example(void)
        foo_file->data = &foo_data;
        foo_file->read_proc = proc_read_foobar;
        foo_file->write_proc = proc_write_foobar;
-       foo_file->owner = THIS_MODULE;
                
        bar_file = create_proc_entry("bar", 0644, example_dir);
        if(bar_file == NULL) {
@@ -159,7 +153,6 @@ static int __init init_procfs_example(void)
        bar_file->data = &bar_data;
        bar_file->read_proc = proc_read_foobar;
        bar_file->write_proc = proc_write_foobar;
-       bar_file->owner = THIS_MODULE;
                
        /* create symlink */
        symlink = proc_symlink("jiffies_too", example_dir, 
@@ -169,8 +162,6 @@ static int __init init_procfs_example(void)
                goto no_symlink;
        }
 
-       symlink->owner = THIS_MODULE;
-
        /* everything OK */
        printk(KERN_INFO "%s %s initialised\n",
               MODULE_NAME, MODULE_VERS);
index 256defd7e1742be45497e1bcc8912d493241c5af..dcf7acc720e18bb68c572e38c6913863b5ead701 100644 (file)
        Revised Feb 12, 2004 by Martine Silbermann
                email: Martine.Silbermann@hp.com
        Revised Jun 25, 2004 by Tom L Nguyen
+       Revised Jul  9, 2008 by Matthew Wilcox <willy@linux.intel.com>
+               Copyright 2003, 2008 Intel Corporation
 
 1. About this guide
 
-This guide describes the basics of Message Signaled Interrupts (MSI),
-the advantages of using MSI over traditional interrupt mechanisms,
-and how to enable your driver to use MSI or MSI-X. Also included is
-a Frequently Asked Questions (FAQ) section.
-
-1.1 Terminology
-
-PCI devices can be single-function or multi-function.  In either case,
-when this text talks about enabling or disabling MSI on a "device
-function," it is referring to one specific PCI device and function and
-not to all functions on a PCI device (unless the PCI device has only
-one function).
-
-2. Copyright 2003 Intel Corporation
-
-3. What is MSI/MSI-X?
-
-Message Signaled Interrupt (MSI), as described in the PCI Local Bus
-Specification Revision 2.3 or later, is an optional feature, and a
-required feature for PCI Express devices. MSI enables a device function
-to request service by sending an Inbound Memory Write on its PCI bus to
-the FSB as a Message Signal Interrupt transaction. Because MSI is
-generated in the form of a Memory Write, all transaction conditions,
-such as a Retry, Master-Abort, Target-Abort or normal completion, are
-supported.
-
-A PCI device that supports MSI must also support pin IRQ assertion
-interrupt mechanism to provide backward compatibility for systems that
-do not support MSI. In systems which support MSI, the bus driver is
-responsible for initializing the message address and message data of
-the device function's MSI/MSI-X capability structure during device
-initial configuration.
-
-An MSI capable device function indicates MSI support by implementing
-the MSI/MSI-X capability structure in its PCI capability list. The
-device function may implement both the MSI capability structure and
-the MSI-X capability structure; however, the bus driver should not
-enable both.
-
-The MSI capability structure contains Message Control register,
-Message Address register and Message Data register. These registers
-provide the bus driver control over MSI. The Message Control register
-indicates the MSI capability supported by the device. The Message
-Address register specifies the target address and the Message Data
-register specifies the characteristics of the message. To request
-service, the device function writes the content of the Message Data
-register to the target address. The device and its software driver
-are prohibited from writing to these registers.
-
-The MSI-X capability structure is an optional extension to MSI. It
-uses an independent and separate capability structure. There are
-some key advantages to implementing the MSI-X capability structure
-over the MSI capability structure as described below.
-
-       - Support a larger maximum number of vectors per function.
-
-       - Provide the ability for system software to configure
-       each vector with an independent message address and message
-       data, specified by a table that resides in Memory Space.
-
-        - MSI and MSI-X both support per-vector masking. Per-vector
-       masking is an optional extension of MSI but a required
-       feature for MSI-X. Per-vector masking provides the kernel the
-       ability to mask/unmask a single MSI while running its
-       interrupt service routine. If per-vector masking is
-       not supported, then the device driver should provide the
-       hardware/software synchronization to ensure that the device
-       generates MSI when the driver wants it to do so.
-
-4. Why use MSI?
-
-As a benefit to the simplification of board design, MSI allows board
-designers to remove out-of-band interrupt routing. MSI is another
-step towards a legacy-free environment.
-
-Due to increasing pressure on chipset and processor packages to
-reduce pin count, the need for interrupt pins is expected to
-diminish over time. Devices, due to pin constraints, may implement
-messages to increase performance.
-
-PCI Express endpoints uses INTx emulation (in-band messages) instead
-of IRQ pin assertion. Using INTx emulation requires interrupt
-sharing among devices connected to the same node (PCI bridge) while
-MSI is unique (non-shared) and does not require BIOS configuration
-support. As a result, the PCI Express technology requires MSI
-support for better interrupt performance.
-
-Using MSI enables the device functions to support two or more
-vectors, which can be configured to target different CPUs to
-increase scalability.
-
-5. Configuring a driver to use MSI/MSI-X
-
-By default, the kernel will not enable MSI/MSI-X on all devices that
-support this capability. The CONFIG_PCI_MSI kernel option
-must be selected to enable MSI/MSI-X support.
-
-5.1 Including MSI/MSI-X support into the kernel
-
-To allow MSI/MSI-X capable device drivers to selectively enable
-MSI/MSI-X (using pci_enable_msi()/pci_enable_msix() as described
-below), the VECTOR based scheme needs to be enabled by setting
-CONFIG_PCI_MSI during kernel config.
-
-Since the target of the inbound message is the local APIC, providing
-CONFIG_X86_LOCAL_APIC must be enabled as well as CONFIG_PCI_MSI.
-
-5.2 Configuring for MSI support
-
-Due to the non-contiguous fashion in vector assignment of the
-existing Linux kernel, this version does not support multiple
-messages regardless of a device function is capable of supporting
-more than one vector. To enable MSI on a device function's MSI
-capability structure requires a device driver to call the function
-pci_enable_msi() explicitly.
-
-5.2.1 API pci_enable_msi
+This guide describes the basics of Message Signaled Interrupts (MSIs),
+the advantages of using MSI over traditional interrupt mechanisms, how
+to change your driver to use MSI or MSI-X and some basic diagnostics to
+try if a device doesn't support MSIs.
 
-int pci_enable_msi(struct pci_dev *dev)
 
-With this new API, a device driver that wants to have MSI
-enabled on its device function must call this API to enable MSI.
-A successful call will initialize the MSI capability structure
-with ONE vector, regardless of whether a device function is
-capable of supporting multiple messages. This vector replaces the
-pre-assigned dev->irq with a new MSI vector. To avoid a conflict
-of the new assigned vector with existing pre-assigned vector requires
-a device driver to call this API before calling request_irq().
+2. What are MSIs?
 
-5.2.2 API pci_disable_msi
+A Message Signaled Interrupt is a write from the device to a special
+address which causes an interrupt to be received by the CPU.
 
-void pci_disable_msi(struct pci_dev *dev)
+The MSI capability was first specified in PCI 2.2 and was later enhanced
+in PCI 3.0 to allow each interrupt to be masked individually.  The MSI-X
+capability was also introduced with PCI 3.0.  It supports more interrupts
+per device than MSI and allows interrupts to be independently configured.
 
-This API should always be used to undo the effect of pci_enable_msi()
-when a device driver is unloading. This API restores dev->irq with
-the pre-assigned IOAPIC vector and switches a device's interrupt
-mode to PCI pin-irq assertion/INTx emulation mode.
-
-Note that a device driver should always call free_irq() on the MSI vector
-that it has done request_irq() on before calling this API. Failure to do
-so results in a BUG_ON() and a device will be left with MSI enabled and
-leaks its vector.
-
-5.2.3 MSI mode vs. legacy mode diagram
-
-The below diagram shows the events which switch the interrupt
-mode on the MSI-capable device function between MSI mode and
-PIN-IRQ assertion mode.
-
-        ------------   pci_enable_msi   ------------------------
-       |            | <=============== |                        |
-       | MSI MODE   |                  | PIN-IRQ ASSERTION MODE |
-       |            | ===============> |                        |
-        ------------   pci_disable_msi  ------------------------
-
-
-Figure 1. MSI Mode vs. Legacy Mode
-
-In Figure 1, a device operates by default in legacy mode. Legacy
-in this context means PCI pin-irq assertion or PCI-Express INTx
-emulation. A successful MSI request (using pci_enable_msi()) switches
-a device's interrupt mode to MSI mode. A pre-assigned IOAPIC vector
-stored in dev->irq will be saved by the PCI subsystem and a new
-assigned MSI vector will replace dev->irq.
-
-To return back to its default mode, a device driver should always call
-pci_disable_msi() to undo the effect of pci_enable_msi(). Note that a
-device driver should always call free_irq() on the MSI vector it has
-done request_irq() on before calling pci_disable_msi(). Failure to do
-so results in a BUG_ON() and a device will be left with MSI enabled and
-leaks its vector. Otherwise, the PCI subsystem restores a device's
-dev->irq with a pre-assigned IOAPIC vector and marks the released
-MSI vector as unused.
-
-Once being marked as unused, there is no guarantee that the PCI
-subsystem will reserve this MSI vector for a device. Depending on
-the availability of current PCI vector resources and the number of
-MSI/MSI-X requests from other drivers, this MSI may be re-assigned.
-
-For the case where the PCI subsystem re-assigns this MSI vector to
-another driver, a request to switch back to MSI mode may result
-in being assigned a different MSI vector or a failure if no more
-vectors are available.
-
-5.3 Configuring for MSI-X support
-
-Due to the ability of the system software to configure each vector of
-the MSI-X capability structure with an independent message address
-and message data, the non-contiguous fashion in vector assignment of
-the existing Linux kernel has no impact on supporting multiple
-messages on an MSI-X capable device functions. To enable MSI-X on
-a device function's MSI-X capability structure requires its device
-driver to call the function pci_enable_msix() explicitly.
-
-The function pci_enable_msix(), once invoked, enables either
-all or nothing, depending on the current availability of PCI vector
-resources. If the PCI vector resources are available for the number
-of vectors requested by a device driver, this function will configure
-the MSI-X table of the MSI-X capability structure of a device with
-requested messages. To emphasize this reason, for example, a device
-may be capable for supporting the maximum of 32 vectors while its
-software driver usually may request 4 vectors. It is recommended
-that the device driver should call this function once during the
-initialization phase of the device driver.
-
-Unlike the function pci_enable_msi(), the function pci_enable_msix()
-does not replace the pre-assigned IOAPIC dev->irq with a new MSI
-vector because the PCI subsystem writes the 1:1 vector-to-entry mapping
-into the field vector of each element contained in a second argument.
-Note that the pre-assigned IOAPIC dev->irq is valid only if the device
-operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt at
-using dev->irq by the device driver to request for interrupt service
-may result in unpredictable behavior.
-
-For each MSI-X vector granted, a device driver is responsible for calling
-other functions like request_irq(), enable_irq(), etc. to enable
-this vector with its corresponding interrupt service handler. It is
-a device driver's choice to assign all vectors with the same
-interrupt service handler or each vector with a unique interrupt
-service handler.
-
-5.3.1 Handling MMIO address space of MSI-X Table
-
-The PCI 3.0 specification has implementation notes that MMIO address
-space for a device's MSI-X structure should be isolated so that the
-software system can set different pages for controlling accesses to the
-MSI-X structure. The implementation of MSI support requires the PCI
-subsystem, not a device driver, to maintain full control of the MSI-X
-table/MSI-X PBA (Pending Bit Array) and MMIO address space of the MSI-X
-table/MSI-X PBA.  A device driver should not access the MMIO address
-space of the MSI-X table/MSI-X PBA.
-
-5.3.2 API pci_enable_msix
+Devices may support both MSI and MSI-X, but only one can be enabled at
+a time.
 
-int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
 
-This API enables a device driver to request the PCI subsystem
-to enable MSI-X messages on its hardware device. Depending on
-the availability of PCI vectors resources, the PCI subsystem enables
-either all or none of the requested vectors.
+3. Why use MSIs?
+
+There are three reasons why using MSIs can give an advantage over
+traditional pin-based interrupts.
+
+Pin-based PCI interrupts are often shared amongst several devices.
+To support this, the kernel must call each interrupt handler associated
+with an interrupt, which leads to reduced performance for the system as
+a whole.  MSIs are never shared, so this problem cannot arise.
+
+When a device writes data to memory, then raises a pin-based interrupt,
+it is possible that the interrupt may arrive before all the data has
+arrived in memory (this becomes more likely with devices behind PCI-PCI
+bridges).  In order to ensure that all the data has arrived in memory,
+the interrupt handler must read a register on the device which raised
+the interrupt.  PCI transaction ordering rules require that all the data
+arrives in memory before the value can be returned from the register.
+Using MSIs avoids this problem as the interrupt-generating write cannot
+pass the data writes, so by the time the interrupt is raised, the driver
+knows that all the data has arrived in memory.
+
+PCI devices can only support a single pin-based interrupt per function.
+Often drivers have to query the device to find out what event has
+occurred, slowing down interrupt handling for the common case.  With
+MSIs, a device can support more interrupts, allowing each interrupt
+to be specialised to a different purpose.  One possible design gives
+infrequent conditions (such as errors) their own interrupt which allows
+the driver to handle the normal interrupt handling path more efficiently.
+Other possible designs include giving one interrupt to each packet queue
+in a network card or each port in a storage controller.
+
+
+4. How to use MSIs
+
+PCI devices are initialised to use pin-based interrupts.  The device
+driver has to set up the device to use MSI or MSI-X.  Not all machines
+support MSIs correctly, and for those machines, the APIs described below
+will simply fail and the device will continue to use pin-based interrupts.
+
+4.1 Include kernel support for MSIs
+
+To support MSI or MSI-X, the kernel must be built with the CONFIG_PCI_MSI
+option enabled.  This option is only available on some architectures,
+and it may depend on some other options also being set.  For example,
+on x86, you must also enable X86_UP_APIC or SMP in order to see the
+CONFIG_PCI_MSI option.
+
+4.2 Using MSI
+
+Most of the hard work is done for the driver in the PCI layer.  It simply
+has to request that the PCI layer set up the MSI capability for this
+device.
+
+4.2.1 pci_enable_msi
+
+int pci_enable_msi(struct pci_dev *dev)
+
+A successful call will allocate ONE interrupt to the device, regardless
+of how many MSIs the device supports.  The device will be switched from
+pin-based interrupt mode to MSI mode.  The dev->irq number is changed
+to a new number which represents the message signaled interrupt.
+This function should be called before the driver calls request_irq()
+since enabling MSIs disables the pin-based IRQ and the driver will not
+receive interrupts on the old interrupt.
+
+4.2.2 pci_enable_msi_block
+
+int pci_enable_msi_block(struct pci_dev *dev, int count)
+
+This variation on the above call allows a device driver to request multiple
+MSIs.  The MSI specification only allows interrupts to be allocated in
+powers of two, up to a maximum of 2^5 (32).
+
+If this function returns 0, it has succeeded in allocating at least as many
+interrupts as the driver requested (it may have allocated more in order
+to satisfy the power-of-two requirement).  In this case, the function
+enables MSI on this device and updates dev->irq to be the lowest of
+the new interrupts assigned to it.  The other interrupts assigned to
+the device are in the range dev->irq to dev->irq + count - 1.
+
+If this function returns a negative number, it indicates an error and
+the driver should not attempt to request any more MSI interrupts for
+this device.  If this function returns a positive number, it will be
+less than 'count' and indicate the number of interrupts that could have
+been allocated.  In neither case will the irq value have been
+updated, nor will the device have been switched into MSI mode.
+
+The device driver must decide what action to take if
+pci_enable_msi_block() returns a value less than the number asked for.
+Some devices can make use of fewer interrupts than the maximum they
+request; in this case the driver should call pci_enable_msi_block()
+again.  Note that it is not guaranteed to succeed, even when the
+'count' has been reduced to the value returned from a previous call to
+pci_enable_msi_block().  This is because there are multiple constraints
+on the number of vectors that can be allocated; pci_enable_msi_block()
+will return as soon as it finds any constraint that doesn't allow the
+call to succeed.
+
+4.2.3 pci_disable_msi
+
+void pci_disable_msi(struct pci_dev *dev)
 
-Argument 'dev' points to the device (pci_dev) structure.
+This function should be used to undo the effect of pci_enable_msi() or
+pci_enable_msi_block().  Calling it restores dev->irq to the pin-based
+interrupt number and frees the previously allocated message signaled
+interrupt(s).  The interrupt may subsequently be assigned to another
+device, so drivers should not cache the value of dev->irq.
 
-Argument 'entries' is a pointer to an array of msix_entry structs.
-The number of entries is indicated in argument 'nvec'.
-struct msix_entry is defined in /driver/pci/msi.h:
+A device driver must always call free_irq() on the interrupt(s)
+for which it has called request_irq() before calling this function.
+Failure to do so will result in a BUG_ON(), the device will be left with
+MSI enabled and will leak its vector.
+
+4.3 Using MSI-X
+
+The MSI-X capability is much more flexible than the MSI capability.
+It supports up to 2048 interrupts, each of which can be controlled
+independently.  To support this flexibility, drivers must use an array of
+`struct msix_entry':
 
 struct msix_entry {
        u16     vector; /* kernel uses to write alloc vector */
        u16     entry; /* driver uses to specify entry */
 };
 
-A device driver is responsible for initializing the field 'entry' of
-each element with a unique entry supported by MSI-X table. Otherwise,
--EINVAL will be returned as a result. A successful return of zero
-indicates the PCI subsystem completed initializing each of the requested
-entries of the MSI-X table with message address and message data.
-Last but not least, the PCI subsystem will write the 1:1
-vector-to-entry mapping into the field 'vector' of each element. A
-device driver is responsible for keeping track of allocated MSI-X
-vectors in its internal data structure.
-
-A return of zero indicates that the number of MSI-X vectors was
-successfully allocated. A return of greater than zero indicates
-MSI-X vector shortage. Or a return of less than zero indicates
-a failure. This failure may be a result of duplicate entries
-specified in second argument, or a result of no available vector,
-or a result of failing to initialize MSI-X table entries.
-
-5.3.3 API pci_disable_msix
+This allows for the device to use these interrupts in a sparse fashion;
+for example it could use interrupts 3 and 1027 and allocate only a
+two-element array.  The driver is expected to fill in the 'entry' value
+in each element of the array to indicate which entries it wants the kernel
+to assign interrupts for.  It is invalid to fill in two entries with the
+same number.
+
+4.3.1 pci_enable_msix
+
+int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
+
+Calling this function asks the PCI subsystem to allocate 'nvec' MSIs.
+The 'entries' argument is a pointer to an array of msix_entry structs
+which should be at least 'nvec' entries in size.  On success, the
+function will return 0 and the device will have been switched into
+MSI-X interrupt mode.  The 'vector' elements in each entry will have
+been filled in with the interrupt number.  The driver should then call
+request_irq() for each 'vector' that it decides to use.
+
+If this function returns a negative number, it indicates an error and
+the driver should not attempt to allocate any more MSI-X interrupts for
+this device.  If it returns a positive number, it indicates the maximum
+number of interrupt vectors that could have been allocated. See example
+below.
+
+This function, in contrast with pci_enable_msi(), does not adjust
+dev->irq.  The device will not generate interrupts for this interrupt
+number once MSI-X is enabled.  The device driver is responsible for
+keeping track of the interrupts assigned to the MSI-X vectors so it can
+free them again later.
+
+Device drivers should normally call this function once per device
+during the initialization phase.
+
+It is ideal if drivers can cope with a variable number of MSI-X interrupts,
+there are many reasons why the platform may not be able to provide the
+exact number a driver asks for.
+
+A request loop to achieve that might look like:
+
+static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
+{
+       while (nvec >= FOO_DRIVER_MINIMUM_NVEC) {
+               rc = pci_enable_msix(adapter->pdev,
+                                    adapter->msix_entries, nvec);
+               if (rc > 0)
+                       nvec = rc;
+               else
+                       return rc;
+       }
+
+       return -ENOSPC;
+}
+
+4.3.2 pci_disable_msix
 
 void pci_disable_msix(struct pci_dev *dev)
 
-This API should always be used to undo the effect of pci_enable_msix()
-when a device driver is unloading. Note that a device driver should
-always call free_irq() on all MSI-X vectors it has done request_irq()
-on before calling this API. Failure to do so results in a BUG_ON() and
-a device will be left with MSI-X enabled and leaks its vectors.
-
-5.3.4 MSI-X mode vs. legacy mode diagram
-
-The below diagram shows the events which switch the interrupt
-mode on the MSI-X capable device function between MSI-X mode and
-PIN-IRQ assertion mode (legacy).
-
-        ------------   pci_enable_msix(,,n) ------------------------
-       |            | <===============     |                        |
-       | MSI-X MODE |                      | PIN-IRQ ASSERTION MODE |
-       |            | ===============>     |                        |
-        ------------   pci_disable_msix     ------------------------
-
-Figure 2. MSI-X Mode vs. Legacy Mode
-
-In Figure 2, a device operates by default in legacy mode. A
-successful MSI-X request (using pci_enable_msix()) switches a
-device's interrupt mode to MSI-X mode. A pre-assigned IOAPIC vector
-stored in dev->irq will be saved by the PCI subsystem; however,
-unlike MSI mode, the PCI subsystem will not replace dev->irq with
-assigned MSI-X vector because the PCI subsystem already writes the 1:1
-vector-to-entry mapping into the field 'vector' of each element
-specified in second argument.
-
-To return back to its default mode, a device driver should always call
-pci_disable_msix() to undo the effect of pci_enable_msix(). Note that
-a device driver should always call free_irq() on all MSI-X vectors it
-has done request_irq() on before calling pci_disable_msix(). Failure
-to do so results in a BUG_ON() and a device will be left with MSI-X
-enabled and leaks its vectors. Otherwise, the PCI subsystem switches a
-device function's interrupt mode from MSI-X mode to legacy mode and
-marks all allocated MSI-X vectors as unused.
-
-Once being marked as unused, there is no guarantee that the PCI
-subsystem will reserve these MSI-X vectors for a device. Depending on
-the availability of current PCI vector resources and the number of
-MSI/MSI-X requests from other drivers, these MSI-X vectors may be
-re-assigned.
-
-For the case where the PCI subsystem re-assigned these MSI-X vectors
-to other drivers, a request to switch back to MSI-X mode may result
-being assigned with another set of MSI-X vectors or a failure if no
-more vectors are available.
-
-5.4 Handling function implementing both MSI and MSI-X capabilities
-
-For the case where a function implements both MSI and MSI-X
-capabilities, the PCI subsystem enables a device to run either in MSI
-mode or MSI-X mode but not both. A device driver determines whether it
-wants MSI or MSI-X enabled on its hardware device. Once a device
-driver requests for MSI, for example, it is prohibited from requesting
-MSI-X; in other words, a device driver is not permitted to ping-pong
-between MSI mod MSI-X mode during a run-time.
-
-5.5 Hardware requirements for MSI/MSI-X support
-
-MSI/MSI-X support requires support from both system hardware and
-individual hardware device functions.
-
-5.5.1 Required x86 hardware support
-
-Since the target of MSI address is the local APIC CPU, enabling
-MSI/MSI-X support in the Linux kernel is dependent on whether existing
-system hardware supports local APIC. Users should verify that their
-system supports local APIC operation by testing that it runs when
-CONFIG_X86_LOCAL_APIC=y.
-
-In SMP environment, CONFIG_X86_LOCAL_APIC is automatically set;
-however, in UP environment, users must manually set
-CONFIG_X86_LOCAL_APIC. Once CONFIG_X86_LOCAL_APIC=y, setting
-CONFIG_PCI_MSI enables the VECTOR based scheme and the option for
-MSI-capable device drivers to selectively enable MSI/MSI-X.
-
-Note that CONFIG_X86_IO_APIC setting is irrelevant because MSI/MSI-X
-vector is allocated new during runtime and MSI/MSI-X support does not
-depend on BIOS support. This key independency enables MSI/MSI-X
-support on future IOxAPIC free platforms.
-
-5.5.2 Device hardware support
-
-The hardware device function supports MSI by indicating the
-MSI/MSI-X capability structure on its PCI capability list. By
-default, this capability structure will not be initialized by
-the kernel to enable MSI during the system boot. In other words,
-the device function is running on its default pin assertion mode.
-Note that in many cases the hardware supporting MSI have bugs,
-which may result in system hangs. The software driver of specific
-MSI-capable hardware is responsible for deciding whether to call
-pci_enable_msi or not. A return of zero indicates the kernel
-successfully initialized the MSI/MSI-X capability structure of the
-device function. The device function is now running on MSI/MSI-X mode.
-
-5.6 How to tell whether MSI/MSI-X is enabled on device function
-
-At the driver level, a return of zero from the function call of
-pci_enable_msi()/pci_enable_msix() indicates to a device driver that
-its device function is initialized successfully and ready to run in
-MSI/MSI-X mode.
-
-At the user level, users can use the command 'cat /proc/interrupts'
-to display the vectors allocated for devices and their interrupt
-MSI/MSI-X modes ("PCI-MSI"/"PCI-MSI-X"). Below shows MSI mode is
-enabled on a SCSI Adaptec 39320D Ultra320 controller.
-
-           CPU0       CPU1
-  0:     324639          0    IO-APIC-edge  timer
-  1:       1186          0    IO-APIC-edge  i8042
-  2:          0          0          XT-PIC  cascade
- 12:       2797          0    IO-APIC-edge  i8042
- 14:       6543          0    IO-APIC-edge  ide0
- 15:          1          0    IO-APIC-edge  ide1
-169:          0          0   IO-APIC-level  uhci-hcd
-185:          0          0   IO-APIC-level  uhci-hcd
-193:        138         10         PCI-MSI  aic79xx
-201:         30          0         PCI-MSI  aic79xx
-225:         30          0   IO-APIC-level  aic7xxx
-233:         30          0   IO-APIC-level  aic7xxx
-NMI:          0          0
-LOC:     324553     325068
-ERR:          0
-MIS:          0
-
-6. MSI quirks
-
-Several PCI chipsets or devices are known to not support MSI.
-The PCI stack provides 3 possible levels of MSI disabling:
-* on a single device
-* on all devices behind a specific bridge
-* globally
-
-6.1. Disabling MSI on a single device
-
-Under some circumstances it might be required to disable MSI on a
-single device.  This may be achieved by either not calling pci_enable_msi()
-or all, or setting the pci_dev->no_msi flag before (most of the time
-in a quirk).
-
-6.2. Disabling MSI below a bridge
-
-The vast majority of MSI quirks are required by PCI bridges not
-being able to route MSI between busses. In this case, MSI have to be
-disabled on all devices behind this bridge. It is achieves by setting
-the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
-subordinate bus. There is no need to set the same flag on bridges that
-are below the broken bridge. When pci_enable_msi() is called to enable
-MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
-flag in all parent busses of the device.
-
-Some bridges actually support dynamic MSI support enabling/disabling
-by changing some bits in their PCI configuration space (especially
-the Hypertransport chipsets such as the nVidia nForce and Serverworks
-HT2000). It may then be required to update the NO_MSI flag on the
-corresponding devices in the sysfs hierarchy. To enable MSI support
-on device "0000:00:0e", do:
-
-       echo 1 > /sys/bus/pci/devices/0000:00:0e/msi_bus
-
-To disable MSI support, echo 0 instead of 1. Note that it should be
-used with caution since changing this value might break interrupts.
-
-6.3. Disabling MSI globally
-
-Some extreme cases may require to disable MSI globally on the system.
-For now, the only known case is a Serverworks PCI-X chipsets (MSI are
-not supported on several busses that are not all connected to the
-chipset in the Linux PCI hierarchy). In the vast majority of other
-cases, disabling only behind a specific bridge is enough.
-
-For debugging purpose, the user may also pass pci=nomsi on the kernel
-command-line to explicitly disable MSI globally. But, once the appro-
-priate quirks are added to the kernel, this option should not be
-required anymore.
-
-6.4. Finding why MSI cannot be enabled on a device
-
-Assuming that MSI are not enabled on a device, you should look at
-dmesg to find messages that quirks may output when disabling MSI
-on some devices, some bridges or even globally.
-Then, lspci -t gives the list of bridges above a device. Reading
-/sys/bus/pci/devices/0000:00:0e/msi_bus will tell you whether MSI
-are enabled (1) or disabled (0). In 0 is found in a single bridge
-msi_bus file above the device, MSI cannot be enabled.
-
-7. FAQ
-
-Q1. Are there any limitations on using the MSI?
-
-A1. If the PCI device supports MSI and conforms to the
-specification and the platform supports the APIC local bus,
-then using MSI should work.
-
-Q2. Will it work on all the Pentium processors (P3, P4, Xeon,
-AMD processors)? In P3 IPI's are transmitted on the APIC local
-bus and in P4 and Xeon they are transmitted on the system
-bus. Are there any implications with this?
-
-A2. MSI support enables a PCI device sending an inbound
-memory write (0xfeexxxxx as target address) on its PCI bus
-directly to the FSB. Since the message address has a
-redirection hint bit cleared, it should work.
-
-Q3. The target address 0xfeexxxxx will be translated by the
-Host Bridge into an interrupt message. Are there any
-limitations on the chipsets such as Intel 8xx, Intel e7xxx,
-or VIA?
-
-A3. If these chipsets support an inbound memory write with
-target address set as 0xfeexxxxx, as conformed to PCI
-specification 2.3 or latest, then it should work.
-
-Q4. From the driver point of view, if the MSI is lost because
-of errors occurring during inbound memory write, then it may
-wait forever. Is there a mechanism for it to recover?
-
-A4. Since the target of the transaction is an inbound memory
-write, all transaction termination conditions (Retry,
-Master-Abort, Target-Abort, or normal completion) are
-supported. A device sending an MSI must abide by all the PCI
-rules and conditions regarding that inbound memory write. So,
-if a retry is signaled it must retry, etc... We believe that
-the recommendation for Abort is also a retry (refer to PCI
-specification 2.3 or latest).
+This API should be used to undo the effect of pci_enable_msix().  It frees
+the previously allocated message signaled interrupts.  The interrupts may
+subsequently be assigned to another device, so drivers should not cache
+the value of the 'vector' elements over a call to pci_disable_msix().
+
+A device driver must always call free_irq() on the interrupt(s)
+for which it has called request_irq() before calling this function.
+Failure to do so will result in a BUG_ON(), the device will be left with
+MSI enabled and will leak its vector.
+
+4.3.3 The MSI-X Table
+
+The MSI-X capability specifies a BAR and offset within that BAR for the
+MSI-X Table.  This address is mapped by the PCI subsystem, and should not
+be accessed directly by the device driver.  If the driver wishes to
+mask or unmask an interrupt, it should call disable_irq() / enable_irq().
+
+4.4 Handling devices implementing both MSI and MSI-X capabilities
+
+If a device implements both MSI and MSI-X capabilities, it can
+run in either MSI mode or MSI-X mode but not both simultaneously.
+This is a requirement of the PCI spec, and it is enforced by the
+PCI layer.  Calling pci_enable_msi() when MSI-X is already enabled or
+pci_enable_msix() when MSI is already enabled will result in an error.
+If a device driver wishes to switch between MSI and MSI-X at runtime,
+it must first quiesce the device, then switch it back to pin-interrupt
+mode, before calling pci_enable_msi() or pci_enable_msix() and resuming
+operation.  This is not expected to be a common operation but may be
+useful for debugging or testing during development.
+
+4.5 Considerations when using MSIs
+
+4.5.1 Choosing between MSI-X and MSI
+
+If your device supports both MSI-X and MSI capabilities, you should use
+the MSI-X facilities in preference to the MSI facilities.  As mentioned
+above, MSI-X supports any number of interrupts between 1 and 2048.
+In constrast, MSI is restricted to a maximum of 32 interrupts (and
+must be a power of two).  In addition, the MSI interrupt vectors must
+be allocated consecutively, so the system may not be able to allocate
+as many vectors for MSI as it could for MSI-X.  On some platforms, MSI
+interrupts must all be targetted at the same set of CPUs whereas MSI-X
+interrupts can all be targetted at different CPUs.
+
+4.5.2 Spinlocks
+
+Most device drivers have a per-device spinlock which is taken in the
+interrupt handler.  With pin-based interrupts or a single MSI, it is not
+necessary to disable interrupts (Linux guarantees the same interrupt will
+not be re-entered).  If a device uses multiple interrupts, the driver
+must disable interrupts while the lock is held.  If the device sends
+a different interrupt, the driver will deadlock trying to recursively
+acquire the spinlock.
+
+There are two solutions.  The first is to take the lock with
+spin_lock_irqsave() or spin_lock_irq() (see
+Documentation/DocBook/kernel-locking).  The second is to specify
+IRQF_DISABLED to request_irq() so that the kernel runs the entire
+interrupt routine with interrupts disabled.
+
+If your MSI interrupt routine does not hold the lock for the whole time
+it is running, the first solution may be best.  The second solution is
+normally preferred as it avoids making two transitions from interrupt
+disabled to enabled and back again.
+
+4.6 How to tell whether MSI/MSI-X is enabled on a device
+
+Using 'lspci -v' (as root) may show some devices with "MSI", "Message
+Signalled Interrupts" or "MSI-X" capabilities.  Each of these capabilities
+has an 'Enable' flag which will be followed with either "+" (enabled)
+or "-" (disabled).
+
+
+5. MSI quirks
+
+Several PCI chipsets or devices are known not to support MSIs.
+The PCI stack provides three ways to disable MSIs:
+
+1. globally
+2. on all devices behind a specific bridge
+3. on a single device
+
+5.1. Disabling MSIs globally
+
+Some host chipsets simply don't support MSIs properly.  If we're
+lucky, the manufacturer knows this and has indicated it in the ACPI
+FADT table.  In this case, Linux will automatically disable MSIs.
+Some boards don't include this information in the table and so we have
+to detect them ourselves.  The complete list of these is found near the
+quirk_disable_all_msi() function in drivers/pci/quirks.c.
+
+If you have a board which has problems with MSIs, you can pass pci=nomsi
+on the kernel command line to disable MSIs on all devices.  It would be
+in your best interests to report the problem to linux-pci@vger.kernel.org
+including a full 'lspci -v' so we can add the quirks to the kernel.
+
+5.2. Disabling MSIs below a bridge
+
+Some PCI bridges are not able to route MSIs between busses properly.
+In this case, MSIs must be disabled on all devices behind the bridge.
+
+Some bridges allow you to enable MSIs by changing some bits in their
+PCI configuration space (especially the Hypertransport chipsets such
+as the nVidia nForce and Serverworks HT2000).  As with host chipsets,
+Linux mostly knows about them and automatically enables MSIs if it can.
+If you have a bridge which Linux doesn't yet know about, you can enable
+MSIs in configuration space using whatever method you know works, then
+enable MSIs on that bridge by doing:
+
+       echo 1 > /sys/bus/pci/devices/$bridge/msi_bus
+
+where $bridge is the PCI address of the bridge you've enabled (eg
+0000:00:0e.0).
+
+To disable MSIs, echo 0 instead of 1.  Changing this value should be
+done with caution as it can break interrupt handling for all devices
+below this bridge.
+
+Again, please notify linux-pci@vger.kernel.org of any bridges that need
+special handling.
+
+5.3. Disabling MSIs on a single device
+
+Some devices are known to have faulty MSI implementations.  Usually this
+is handled in the individual device driver but occasionally it's necessary
+to handle this with a quirk.  Some drivers have an option to disable use
+of MSI.  While this is a convenient workaround for the driver author,
+it is not good practise, and should not be emulated.
+
+5.4. Finding why MSIs are disabled on a device
+
+From the above three sections, you can see that there are many reasons
+why MSIs may not be enabled for a given device.  Your first step should
+be to examine your dmesg carefully to determine whether MSIs are enabled
+for your machine.  You should also check your .config to be sure you
+have enabled CONFIG_PCI_MSI.
+
+Then, 'lspci -t' gives the list of bridges above a device.  Reading
+/sys/bus/pci/devices/*/msi_bus will tell you whether MSI are enabled (1)
+or disabled (0).  If 0 is found in any of the msi_bus files belonging
+to bridges between the PCI root and the device, MSIs are disabled.
+
+It is also worth checking the device driver to see whether it supports MSIs.
+For example, it may contain calls to pci_enable_msi(), pci_enable_msix() or
+pci_enable_msi_block().
diff --git a/Documentation/PCI/pci-iov-howto.txt b/Documentation/PCI/pci-iov-howto.txt
new file mode 100644 (file)
index 0000000..fc73ef5
--- /dev/null
@@ -0,0 +1,99 @@
+               PCI Express I/O Virtualization Howto
+               Copyright (C) 2009 Intel Corporation
+                   Yu Zhao <yu.zhao@intel.com>
+
+
+1. Overview
+
+1.1 What is SR-IOV
+
+Single Root I/O Virtualization (SR-IOV) is a PCI Express Extended
+capability which makes one physical device appear as multiple virtual
+devices. The physical device is referred to as Physical Function (PF)
+while the virtual devices are referred to as Virtual Functions (VF).
+Allocation of the VF can be dynamically controlled by the PF via
+registers encapsulated in the capability. By default, this feature is
+not enabled and the PF behaves as traditional PCIe device. Once it's
+turned on, each VF's PCI configuration space can be accessed by its own
+Bus, Device and Function Number (Routing ID). And each VF also has PCI
+Memory Space, which is used to map its register set. VF device driver
+operates on the register set so it can be functional and appear as a
+real existing PCI device.
+
+2. User Guide
+
+2.1 How can I enable SR-IOV capability
+
+The device driver (PF driver) will control the enabling and disabling
+of the capability via API provided by SR-IOV core. If the hardware
+has SR-IOV capability, loading its PF driver would enable it and all
+VFs associated with the PF.
+
+2.2 How can I use the Virtual Functions
+
+The VF is treated as hot-plugged PCI devices in the kernel, so they
+should be able to work in the same way as real PCI devices. The VF
+requires device driver that is same as a normal PCI device's.
+
+3. Developer Guide
+
+3.1 SR-IOV API
+
+To enable SR-IOV capability:
+       int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
+       'nr_virtfn' is number of VFs to be enabled.
+
+To disable SR-IOV capability:
+       void pci_disable_sriov(struct pci_dev *dev);
+
+To notify SR-IOV core of Virtual Function Migration:
+       irqreturn_t pci_sriov_migration(struct pci_dev *dev);
+
+3.2 Usage example
+
+Following piece of code illustrates the usage of the SR-IOV API.
+
+static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
+{
+       pci_enable_sriov(dev, NR_VIRTFN);
+
+       ...
+
+       return 0;
+}
+
+static void __devexit dev_remove(struct pci_dev *dev)
+{
+       pci_disable_sriov(dev);
+
+       ...
+}
+
+static int dev_suspend(struct pci_dev *dev, pm_message_t state)
+{
+       ...
+
+       return 0;
+}
+
+static int dev_resume(struct pci_dev *dev)
+{
+       ...
+
+       return 0;
+}
+
+static void dev_shutdown(struct pci_dev *dev)
+{
+       ...
+}
+
+static struct pci_driver dev_driver = {
+       .name =         "SR-IOV Physical Function driver",
+       .id_table =     dev_id_table,
+       .probe =        dev_probe,
+       .remove =       __devexit_p(dev_remove),
+       .suspend =      dev_suspend,
+       .resume =       dev_resume,
+       .shutdown =     dev_shutdown,
+};
index caabbd395e6194c117444e538605af9582c7c392..a618fd99c9f0164298cd343ce404d04f3d38cd40 100644 (file)
@@ -11,8 +11,6 @@ aty128fb.txt
        - info on the ATI Rage128 frame buffer driver.
 cirrusfb.txt
        - info on the driver for Cirrus Logic chipsets.
-cyblafb/
-       - directory with documentation files related to the cyblafb driver.
 deferred_io.txt
        - an introduction to deferred IO.
 fbcon.txt
diff --git a/Documentation/fb/cyblafb/bugs b/Documentation/fb/cyblafb/bugs
deleted file mode 100644 (file)
index 9443a6d..0000000
+++ /dev/null
@@ -1,13 +0,0 @@
-Bugs
-====
-
-I currently don't know of any bug. Please do send reports to:
- - linux-fbdev-devel@lists.sourceforge.net
- - Knut_Petersen@t-online.de.
-
-
-Untested features
-=================
-
-All LCD stuff is untested. If it worked in tridentfb, it should work in
-cyblafb. Please test and report the results to Knut_Petersen@t-online.de.
diff --git a/Documentation/fb/cyblafb/credits b/Documentation/fb/cyblafb/credits
deleted file mode 100644 (file)
index 0eb3b44..0000000
+++ /dev/null
@@ -1,7 +0,0 @@
-Thanks to
-=========
-   *   Alan Hourihane, for writing the X trident driver
-   *   Jani Monoses, for writing the tridentfb driver
-   *   Antonino A. Daplas, for review of the first published
-       version of cyblafb and some code
-   *   Jochen Hein, for testing and a helpfull bug report
diff --git a/Documentation/fb/cyblafb/documentation b/Documentation/fb/cyblafb/documentation
deleted file mode 100644 (file)
index bb1aac0..0000000
+++ /dev/null
@@ -1,17 +0,0 @@
-Available Documentation
-=======================
-
-Apollo PLE 133 Chipset VT8601A North Bridge Datasheet, Rev. 1.82, October 22,
-2001, available from VIA:
-
-       http://www.viavpsd.com/product/6/15/DS8601A182.pdf
-
-The datasheet is incomplete, some registers that need to be programmed are not
-explained at all and important bits are listed as "reserved". But you really
-need the datasheet to understand the code.  "p. xxx" comments refer to page
-numbers of this document.
-
-XFree/XOrg drivers are available and of good quality, looking at the code
-there is a good idea if the datasheet does not provide enough information
-or if the datasheet seems to be wrong.
-
diff --git a/Documentation/fb/cyblafb/fb.modes b/Documentation/fb/cyblafb/fb.modes
deleted file mode 100644 (file)
index fe0e522..0000000
+++ /dev/null
@@ -1,154 +0,0 @@
-#
-#   Sample fb.modes file
-#
-#      Provides an incomplete list of working modes for
-#      the cyberblade/i1 graphics core.
-#
-#      The value 4294967256 is used instead of -40. Of course, -40 is not
-#      a really reasonable value, but chip design does not always follow
-#      logic. Believe me, it's ok, and it's the way the BIOS does it.
-#
-#      fbset requires 4294967256 in fb.modes and -40 as an argument to
-#      the -t parameter. That's also not too reasonable, and it might change
-#      in the future or might even be differt for your current version.
-#
-
-mode "640x480-50"
-    geometry 640 480 2048 4096 8
-    timings 47619 4294967256 24 17 0 216 3
-endmode
-
-mode "640x480-60"
-    geometry 640 480 2048 4096 8
-    timings 39682 4294967256 24 17 0 216 3
-endmode
-
-mode "640x480-70"
-    geometry 640 480 2048 4096 8
-    timings 34013 4294967256 24 17 0 216 3
-endmode
-
-mode "640x480-72"
-    geometry 640 480 2048 4096 8
-    timings 33068 4294967256 24 17 0 216 3
-endmode
-
-mode "640x480-75"
-    geometry 640 480 2048 4096 8
-    timings 31746 4294967256 24 17 0 216 3
-endmode
-
-mode "640x480-80"
-    geometry 640 480 2048 4096 8
-    timings 29761 4294967256 24 17 0 216 3
-endmode
-
-mode "640x480-85"
-    geometry 640 480 2048 4096 8
-    timings 28011 4294967256 24 17 0 216 3
-endmode
-
-mode "800x600-50"
-    geometry 800 600 2048 4096 8
-    timings 30303 96 24 14 0 136 11
-endmode
-
-mode "800x600-60"
-    geometry 800 600 2048 4096 8
-    timings 25252 96 24 14 0 136 11
-endmode
-
-mode "800x600-70"
-    geometry 800 600 2048 4096 8
-    timings 21645 96 24 14 0 136 11
-endmode
-
-mode "800x600-72"
-    geometry 800 600 2048 4096 8
-    timings 21043 96 24 14 0 136 11
-endmode
-
-mode "800x600-75"
-    geometry 800 600 2048 4096 8
-    timings 20202 96 24 14 0 136 11
-endmode
-
-mode "800x600-80"
-    geometry 800 600 2048 4096 8
-    timings 18939 96 24 14 0 136 11
-endmode
-
-mode "800x600-85"
-    geometry 800 600 2048 4096 8
-    timings 17825 96 24 14 0 136 11
-endmode
-
-mode "1024x768-50"
-    geometry 1024 768 2048 4096 8
-    timings 19054 144 24 29 0 120 3
-endmode
-
-mode "1024x768-60"
-    geometry 1024 768 2048 4096 8
-    timings 15880 144 24 29 0 120 3
-endmode
-
-mode "1024x768-70"
-    geometry 1024 768 2048 4096 8
-    timings 13610 144 24 29 0 120 3
-endmode
-
-mode "1024x768-72"
-    geometry 1024 768 2048 4096 8
-    timings 13232 144 24 29 0 120 3
-endmode
-
-mode "1024x768-75"
-    geometry 1024 768 2048 4096 8
-    timings 12703 144 24 29 0 120 3
-endmode
-
-mode "1024x768-80"
-    geometry 1024 768 2048 4096 8
-    timings 11910 144 24 29 0 120 3
-endmode
-
-mode "1024x768-85"
-    geometry 1024 768 2048 4096 8
-    timings 11209 144 24 29 0 120 3
-endmode
-
-mode "1280x1024-50"
-    geometry 1280 1024 2048 4096 8
-    timings 11114 232 16 39 0 160 3
-endmode
-
-mode "1280x1024-60"
-    geometry 1280 1024 2048 4096 8
-    timings 9262 232 16 39 0 160 3
-endmode
-
-mode "1280x1024-70"
-    geometry 1280 1024 2048 4096 8
-    timings 7939 232 16 39 0 160 3
-endmode
-
-mode "1280x1024-72"
-    geometry 1280 1024 2048 4096 8
-    timings 7719 232 16 39 0 160 3
-endmode
-
-mode "1280x1024-75"
-    geometry 1280 1024 2048 4096 8
-    timings 7410 232 16 39 0 160 3
-endmode
-
-mode "1280x1024-80"
-    geometry 1280 1024 2048 4096 8
-    timings 6946 232 16 39 0 160 3
-endmode
-
-mode "1280x1024-85"
-    geometry 1280 1024 2048 4096 8
-    timings 6538 232 16 39 0 160 3
-endmode
diff --git a/Documentation/fb/cyblafb/performance b/Documentation/fb/cyblafb/performance
deleted file mode 100644 (file)
index 8d15d5d..0000000
+++ /dev/null
@@ -1,79 +0,0 @@
-Speed
-=====
-
-CyBlaFB is much faster than tridentfb and vesafb. Compare the performance data
-for mode 1280x1024-[8,16,32]@61 Hz.
-
-Test 1: Cat a file with 2000 lines of 0 characters.
-Test 2: Cat a file with 2000 lines of 80 characters.
-Test 3: Cat a file with 2000 lines of 160 characters.
-
-All values show system time use in seconds, kernel 2.6.12 was used for
-the measurements. 2.6.13 is a bit slower, 2.6.14 hopefully will include a
-patch that speeds up kernel bitblitting a lot ( > 20%).
-
-+-----------+-----------------------------------------------------+
-|          |                   not accelerated                   |
-| TRIDENTFB +-----------------+-----------------+-----------------+
-| of 2.6.12 |     8 bpp      |     16 bpp      |     32 bpp      |
-|          | noypan |   ypan | noypan |   ypan | noypan |   ypan |
-+-----------+--------+--------+--------+--------+--------+--------+
-|    Test 1 |  4.31 |   4.33 |   6.05 |  12.81 |  ----  |  ----  |
-|    Test 2 |  67.94 |  5.44 | 123.16 |  14.79 |  ----  |  ----  |
-|    Test 3 | 131.36 |  6.55 | 240.12 |  16.76 |  ----  |  ----  |
-+-----------+--------+--------+--------+--------+--------+--------+
-|  Comments |                |                 | completely bro- |
-|          |                 |                 | ken, monitor    |
-|          |                 |                 | switches off    |
-+-----------+-----------------+-----------------+-----------------+
-
-
-+-----------+-----------------------------------------------------+
-|          |                     accelerated                     |
-| TRIDENTFB +-----------------+-----------------+-----------------+
-| of 2.6.12 |     8 bpp      |     16 bpp      |     32 bpp      |
-|          | noypan |   ypan | noypan |   ypan | noypan |   ypan |
-+-----------+--------+--------+--------+--------+--------+--------+
-|    Test 1 |  ----  | ----  |  20.62 |   1.22 |  ----  |  ----  |
-|    Test 2 |  ----  | ----  |  22.61 |   3.19 |  ----  |  ----  |
-|    Test 3 |  ----  | ----  |  24.59 |   5.16 |  ----  |  ----  |
-+-----------+--------+--------+--------+--------+--------+--------+
-|  Comments | broken, writing | broken, ok only | completely bro- |
-|          | to wrong places | if bgcolor is   | ken, monitor    |
-|          | on screen + bug | black, bug in   | switches off    |
-|          | in fillrect()   | fillrect()      |                 |
-+-----------+-----------------+-----------------+-----------------+
-
-
-+-----------+-----------------------------------------------------+
-|          |                   not accelerated                   |
-|   VESAFB  +-----------------+-----------------+-----------------+
-| of 2.6.12 |     8 bpp      |     16 bpp      |     32 bpp      |
-|          | noypan |   ypan | noypan |   ypan | noypan |   ypan |
-+-----------+--------+--------+--------+--------+--------+--------+
-|    Test 1 |  4.26 |   3.76 |   5.99 |   7.23 |  ----  |  ----  |
-|    Test 2 |  65.65 |  4.89 | 120.88 |   9.08 |  ----  |  ----  |
-|    Test 3 | 126.91 |  5.94 | 235.77 |  11.03 |  ----  |  ----  |
-+-----------+--------+--------+--------+--------+--------+--------+
-|  Comments | vga=0x307       | vga=0x31a      | vga=0x31b not   |
-|          | fh=80kHz        | fh=80kHz        | supported by    |
-|          | fv=75kHz        | fv=75kHz        | video BIOS and  |
-|          |                 |                 | hardware        |
-+-----------+-----------------+-----------------+-----------------+
-
-
-+-----------+-----------------------------------------------------+
-|          |                     accelerated                     |
-|  CYBLAFB  +-----------------+-----------------+-----------------+
-|          |      8 bpp      |     16 bpp      |     32 bpp      |
-|          | noypan |   ypan | noypan |   ypan | noypan |   ypan |
-+-----------+--------+--------+--------+--------+--------+--------+
-|    Test 1 |  8.02 |   0.23 |  19.04 |   0.61 |  57.12 |   2.74 |
-|    Test 2 |  8.38 |   0.55 |  19.39 |   0.92 |  57.54 |   3.13 |
-|    Test 3 |  8.73 |   0.86 |  19.74 |   1.24 |  57.95 |   3.51 |
-+-----------+--------+--------+--------+--------+--------+--------+
-|  Comments |                |                 |                 |
-|          |                 |                 |                 |
-|          |                 |                 |                 |
-|          |                 |                 |                 |
-+-----------+-----------------+-----------------+-----------------+
diff --git a/Documentation/fb/cyblafb/todo b/Documentation/fb/cyblafb/todo
deleted file mode 100644 (file)
index c5f6d0e..0000000
+++ /dev/null
@@ -1,31 +0,0 @@
-TODO / Missing features
-=======================
-
-Verify LCD stuff               "stretch" and "center" options are
-                               completely untested ... this code needs to be
-                               verified. As I don't have access to such
-                               hardware, please contact me if you are
-                               willing run some tests.
-
-Interlaced video modes         The reason that interleaved
-                               modes are disabled is that I do not know
-                               the meaning of the vertical interlace
-                               parameter. Also the datasheet mentions a
-                               bit d8 of a horizontal interlace parameter,
-                               but nowhere the lower 8 bits. Please help
-                               if you can.
-
-low-res double scan modes      Who needs it?
-
-accelerated color blitting     Who needs it? The console driver does use color
-                               blitting for nothing but drawing the penguine,
-                               everything else is done using color expanding
-                               blitting of 1bpp character bitmaps.
-
-ioctls                         Who needs it?
-
-TV-out                         Will be done later. Use "vga= " at boot time
-                               to set a suitable video mode.
-
-???                            Feel free to contact me if you have any
-                               feature requests
diff --git a/Documentation/fb/cyblafb/usage b/Documentation/fb/cyblafb/usage
deleted file mode 100644 (file)
index a39bb3d..0000000
+++ /dev/null
@@ -1,217 +0,0 @@
-CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated
-into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and
-tested using a VIA EPIA 5000 board.
-
-Cyblafb - compiled into the kernel or as a module?
-==================================================
-
-You might compile cyblafb either as a module or compile it permanently into the
-kernel.
-
-Unless you have a real reason to do so you should not compile both vesafb and
-cyblafb permanently into the kernel. It's possible and it helps during the
-developement cycle, but it's useless and will at least block some otherwise
-usefull memory for ordinary users.
-
-Selecting Modes
-===============
-
-       Startup Mode
-       ============
-
-       First of all, you might use the "vga=???" boot parameter as it is
-       documented in vesafb.txt and svga.txt. Cyblafb will detect the video
-       mode selected and will use the geometry and timings found by
-       inspecting the hardware registers.
-
-               video=cyblafb vga=0x317
-
-       Alternatively you might use a combination of the mode, ref and bpp
-       parameters. If you compiled the driver into the kernel, add something
-       like this to the kernel command line:
-
-               video=cyblafb:1280x1024,bpp=16,ref=50 ...
-
-       If you compiled the driver as a module, the same mode would be
-       selected by the following command:
-
-               modprobe cyblafb mode=1280x1024 bpp=16 ref=50 ...
-
-       None of the modes possible to select as startup modes are affected by
-       the problems described at the end of the next subsection.
-
-       For all startup modes cyblafb chooses a virtual x resolution of 2048,
-       the only exception is mode 1280x1024 in combination with 32 bpp. This
-       allows ywrap scrolling for all those modes if rotation is 0 or 2, and
-       also fast scrolling if rotation is 1 or 3. The default virtual y reso-
-       lution is 4096 for bpp == 8, 2048 for bpp==16 and 1024 for bpp == 32,
-       again with the only exception of 1280x1024 at 32 bpp.
-
-       Please do set your video memory size to 8 Mb in the Bios setup. Other
-       values will work, but performace is decreased for a lot of modes.
-
-       Mode changes using fbset
-       ========================
-
-       You might use fbset to change the video mode, see "man fbset". Cyblafb
-       generally does assume that you know what you are doing. But it does
-       some checks, especially those that are needed to prevent you from
-       damaging your hardware.
-
-               - only 8, 16, 24 and 32 bpp video modes are accepted
-               - interlaced video modes are not accepted
-               - double scan video modes are not accepted
-               - if a flat panel is found, cyblafb does not allow you
-                 to program a resolution higher than the physical
-                 resolution of the flat panel monitor
-               - cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp
-                 and (currently) 24 bit modes use a doubled vclk internally,
-                 the dotclock limit as seen by fbset is 115 MHz for those
-                 modes and 230 MHz for 8 and 16 bpp modes.
-               - cyblafb will allow you to select very high resolutions as
-                 long as the hardware can be programmed to these modes. The
-                 documented limit 1600x1200 is not enforced, but don't expect
-                 perfect signal quality.
-
-       Any request that violates the rules given above will be either changed
-       to something the hardware supports or an error value will be returned.
-
-       If you program a virtual y resolution higher than the hardware limit,
-       cyblafb will silently decrease that value to the highest possible
-       value. The same is true for a virtual x resolution that is not
-       supported by the hardware. Cyblafb tries to adapt vyres first because
-       vxres decides if ywrap scrolling is possible or not.
-
-       Attempts to disable acceleration are ignored, I believe that this is
-       safe.
-
-       Some video modes that should work do not work as expected. If you use
-       the standard fb.modes, fbset 640x480-60 will program that mode, but
-       you will see a vertical area, about two characters wide, with only
-       much darker characters than the other characters on the screen.
-       Cyblafb does allow that mode to be set, as it does not violate the
-       official specifications. It would need a lot of code to reliably sort
-       out all invalid modes, playing around with the margin values will
-       give a valid mode quickly. And if cyblafb would detect such an invalid
-       mode, should it silently alter the requested values or should it
-       report an error? Both options have some pros and cons. As stated
-       above, none of the startup modes are affected, and if you set
-       verbosity to 1 or higher, cyblafb will print the fbset command that
-       would be needed to program that mode using fbset.
-
-
-Other Parameters
-================
-
-
-crt            don't autodetect, assume monitor connected to
-               standard VGA connector
-
-fp             don't autodetect, assume flat panel display
-               connected to flat panel monitor interface
-
-nativex        inform driver about native x resolution of
-               flat panel monitor connected to special
-               interface (should be autodetected)
-
-stretch        stretch image to adapt low resolution modes to
-               higer resolutions of flat panel monitors
-               connected to special interface
-
-center         center image to adapt low resolution modes to
-               higer resolutions of flat panel monitors
-               connected to special interface
-
-memsize        use if autodetected memsize is wrong ...
-               should never be necessary
-
-nopcirr        disable PCI read retry
-nopciwr        disable PCI write retry
-nopcirb        disable PCI read bursts
-nopciwb        disable PCI write bursts
-
-bpp            bpp for specified modes
-               valid values: 8 || 16 || 24 || 32
-
-ref            refresh rate for specified mode
-               valid values: 50 <= ref <= 85
-
-mode           640x480 or 800x600 or 1024x768 or 1280x1024
-               if not specified, the startup mode will be detected
-               and used, so you might also use the vga=??? parameter
-               described in vesafb.txt. If you do not specify a mode,
-               bpp and ref parameters are ignored.
-
-verbosity      0 is the default, increase to at least 2 for every
-               bug report!
-
-Development hints
-=================
-
-It's much faster do compile a module and to load the new version after
-unloading the old module than to compile a new kernel and to reboot. So if you
-try to work on cyblafb, it might be a good idea to use cyblafb as a module.
-In real life, fast often means dangerous, and that's also the case here. If
-you introduce a serious bug when cyblafb is compiled into the kernel, the
-kernel will lock or oops with a high probability before the file system is
-mounted, and the danger for your data is low. If you load a broken own version
-of cyblafb on a running system, the danger for the integrity of the file
-system is much higher as you might need a hard reset afterwards. Decide
-yourself.
-
-Module unloading, the vfb method
-================================
-
-If you want to unload/reload cyblafb using the virtual framebuffer, you need
-to enable vfb support in the kernel first. After that, load the modules as
-shown below:
-
-       modprobe vfb vfb_enable=1
-       modprobe fbcon
-       modprobe cyblafb
-       fbset -fb /dev/fb1 1280x1024-60 -vyres 2662
-       con2fb /dev/fb1 /dev/tty1
-       ...
-
-If you now made some changes to cyblafb and want to reload it, you might do it
-as show below:
-
-       con2fb /dev/fb0 /dev/tty1
-       ...
-       rmmod cyblafb
-       modprobe cyblafb
-       con2fb /dev/fb1 /dev/tty1
-       ...
-
-Of course, you might choose another mode, and most certainly you also want to
-map some other /dev/tty* to the real framebuffer device. You might also choose
-to compile fbcon as a kernel module or place it permanently in the kernel.
-
-I do not know of any way to unload fbcon, and fbcon will prevent the
-framebuffer device loaded first from unloading. [If there is a way, then
-please add a description here!]
-
-Module unloading, the vesafb method
-===================================
-
-Configure the kernel:
-
-       <*> Support for frame buffer devices
-       [*]   VESA VGA graphics support
-       <M>   Cyberblade/i1 support
-
-Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan
-parameter is important, choose any vga parameter you like as long as it is
-a graphics mode.
-
-After booting, load cyblafb without any mode and bpp parameter and assign
-cyblafb to individual ttys using con2fb, e.g.:
-
-       modprobe cyblafb
-       con2fb /dev/fb1 /dev/tty1
-
-Unloading cyblafb works without problems after you assign vesafb to all
-ttys again, e.g.:
-
-       con2fb /dev/fb0 /dev/tty1
-       rmmod cyblafb
diff --git a/Documentation/fb/cyblafb/whatsnew b/Documentation/fb/cyblafb/whatsnew
deleted file mode 100644 (file)
index 76c07a2..0000000
+++ /dev/null
@@ -1,29 +0,0 @@
-0.62
-====
-
-      - the vesafb parameter has been removed as I decided to allow the
-       feature without any special parameter.
-
-      - Cyblafb does not use the vga style of panning any longer, now the
-       "right view" register in the graphics engine IO space is used. Without
-       that change it was impossible to use all available memory, and without
-       access to all available memory it is impossible to ywrap.
-
-      - The imageblit function now uses hardware acceleration for all font
-        widths. Hardware blitting across pixel column 2048 is broken in the
-       cyberblade/i1 graphics core, but we work around that hardware bug.
-
-      - modes with vxres != xres are supported now.
-
-      - ywrap scrolling is supported now and the default. This is a big
-        performance gain.
-
-      - default video modes use vyres > yres and vxres > xres to allow
-        almost optimal scrolling speed for normal and rotated screens
-
-      - some features mainly usefull for debugging the upper layers of the
-        framebuffer system have been added, have a look at the code
-
-      - fixed: Oops after unloading cyblafb when reading /proc/io*
-
-      - we work around some bugs of the higher framebuffer layers.
diff --git a/Documentation/fb/cyblafb/whycyblafb b/Documentation/fb/cyblafb/whycyblafb
deleted file mode 100644 (file)
index a123bc1..0000000
+++ /dev/null
@@ -1,85 +0,0 @@
-I tried the following framebuffer drivers:
-
-       - TRIDENTFB is full of bugs. Acceleration is broken for Blade3D
-         graphics cores like the cyberblade/i1. It claims to support a great
-         number of devices, but documentation for most of these devices is
-         unfortunately not available. There is _no_ reason to use tridentfb
-         for cyberblade/i1 + CRT users. VESAFB is faster, and the one
-         advantage, mode switching, is broken in tridentfb.
-
-       - VESAFB is used by many distributions as a standard. Vesafb does
-         not support mode switching. VESAFB is a bit faster than the working
-         configurations of TRIDENTFB, but it is still too slow, even if you
-         use ypan.
-
-       - EPIAFB (you'll find it on sourceforge) supports the Cyberblade/i1
-         graphics core, but it still has serious bugs and developement seems
-         to have stopped. This is the one driver with TV-out support. If you
-         do need this feature, try epiafb.
-
-None of these drivers was a real option for me.
-
-I believe that is unreasonable to change code that announces to support 20
-devices if I only have more or less sufficient documentation for exactly one
-of these. The risk of breaking device foo while fixing device bar is too high.
-
-So I decided to start CyBlaFB as a stripped down tridentfb.
-
-All code specific to other Trident chips has been removed. After that there
-were a lot of cosmetic changes to increase the readability of the code. All
-register names were changed to those mnemonics used in the datasheet. Function
-and macro names were changed if they hindered easy understanding of the code.
-
-After that I debugged the code and implemented some new features. I'll try to
-give a little summary of the main changes:
-
-       - calculation of vertical and horizontal timings was fixed
-
-       - video signal quality has been improved dramatically
-
-       - acceleration:
-
-               - fillrect and copyarea were fixed and reenabled
-
-               - color expanding imageblit was newly implemented, color
-                 imageblit (only used to draw the penguine) still uses the
-                 generic code.
-
-               - init of the acceleration engine was improved and moved to a
-                 place where it really works ...
-
-               - sync function has a timeout now and tries to reset and
-                 reinit the accel engine if necessary
-
-               - fewer slow copyarea calls when doing ypan scrolling by using
-                 undocumented bit d21 of screen start address stored in
-                 CR2B[5]. BIOS does use it also, so this should be safe.
-
-       - cyblafb rejects any attempt to set modes that would cause vclk
-         values above reasonable 230 MHz. 32bit modes use a clock
-         multiplicator of 2, so fbset does show the correct values for
-         pixclock but not for vclk in this case. The fbset limit is 115 MHz
-         for 32 bpp modes.
-
-       - cyblafb rejects modes known to be broken or unimplemented (all
-         interlaced modes, all doublescan modes for now)
-
-       - cyblafb now works independant of the video mode in effect at startup
-         time (tridentfb does not init all needed registers to reasonable
-         values)
-
-       - switching between video modes does work reliably now
-
-       - the first video mode now is the one selected on startup using the
-         vga=???? mechanism or any of
-               - 640x480, 800x600, 1024x768, 1280x1024
-               - 8, 16, 24 or 32 bpp
-               - refresh between 50 Hz and 85 Hz, 1 Hz steps (1280x1024-32
-                 is limited to 63Hz)
-
-       - pci retry and pci burst mode are settable (try to disable if you
-         experience latency problems)
-
-       - built as a module cyblafb might be unloaded and reloaded using
-         the vfb module and con2vt or might be used together with vesafb
-
index 5e02b83ac12b6e19842f18a4c5017b4a0ee8ab31..d0f354670646bc009b2ae837ad3e197574a5006f 100644 (file)
@@ -311,6 +311,18 @@ Who:       Vlad Yasevich <vladislav.yasevich@hp.com>
 
 ---------------------------
 
+What:  Ability for non root users to shm_get hugetlb pages based on mlock
+       resource limits
+When:  2.6.31
+Why:   Non root users need to be part of /proc/sys/vm/hugetlb_shm_group or
+       have CAP_IPC_LOCK to be able to allocate shm segments backed by
+       huge pages.  The mlock based rlimit check to allow shm hugetlb is
+       inconsistent with mmap based allocations.  Hence it is being
+       deprecated.
+Who:   Ravikiran Thirumalai <kiran@scalex86.org>
+
+---------------------------
+
 What:  CONFIG_THERMAL_HWMON
 When:  January 2009
 Why:   This option was introduced just to allow older lm-sensors userspace
@@ -380,3 +392,35 @@ Why:       The defines and typedefs (hw_interrupt_type, no_irq_type, irq_desc_t)
        have been kept around for migration reasons. After more than two years
        it's time to remove them finally
 Who:   Thomas Gleixner <tglx@linutronix.de>
+
+---------------------------
+
+What:  fakephp and associated sysfs files in /sys/bus/pci/slots/
+When:  2011
+Why:   In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
+       represent a machine's physical PCI slots. The change in semantics
+       had userspace implications, as the hotplug core no longer allowed
+       drivers to create multiple sysfs files per physical slot (required
+       for multi-function devices, e.g.). fakephp was seen as a developer's
+       tool only, and its interface changed. Too late, we learned that
+       there were some users of the fakephp interface.
+
+       In 2.6.30, the original fakephp interface was restored. At the same
+       time, the PCI core gained the ability that fakephp provided, namely
+       function-level hot-remove and hot-add.
+
+       Since the PCI core now provides the same functionality, exposed in:
+
+               /sys/bus/pci/rescan
+               /sys/bus/pci/devices/.../remove
+               /sys/bus/pci/devices/.../rescan
+
+       there is no functional reason to maintain fakephp as well.
+
+       We will keep the existing module so that 'modprobe fakephp' will
+       present the old /sys/bus/pci/slots/... interface for compatibility,
+       but users are urged to migrate their applications to the API above.
+
+       After a reasonable transition period, we will remove the legacy
+       fakephp interface.
+Who:   Alex Chiang <achiang@hp.com>
index 4e78ce6778435aacf321de21baffe4095739f2e9..76efe5b71d7d8f744739a129f4b5333b898acf5c 100644 (file)
@@ -505,7 +505,7 @@ prototypes:
        void (*open)(struct vm_area_struct*);
        void (*close)(struct vm_area_struct*);
        int (*fault)(struct vm_area_struct*, struct vm_fault *);
-       int (*page_mkwrite)(struct vm_area_struct *, struct page *);
+       int (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *);
        int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
 
 locking rules:
index 9f8740ca3f3bc514d9f5426168eb5b2273b96d42..26e4b8bc53ee097b0660650b83d276751855b1ea 100644 (file)
@@ -12,6 +12,7 @@ that support it.  For example, a given bus might look like this:
      |   |-- enable
      |   |-- irq
      |   |-- local_cpus
+     |   |-- remove
      |   |-- resource
      |   |-- resource0
      |   |-- resource1
@@ -36,6 +37,7 @@ files, each with their own function.
        enable             Whether the device is enabled (ascii, rw)
        irq                IRQ number (ascii, ro)
        local_cpus         nearby CPU mask (cpumask, ro)
+       remove             remove device from kernel's list (ascii, wo)
        resource                   PCI resource host addresses (ascii, ro)
        resource0..N       PCI resource N, if present (binary, mmap)
        resource0_wc..N_wc  PCI WC map resource N, if prefetchable (binary, mmap)
@@ -46,6 +48,7 @@ files, each with their own function.
 
   ro - read only file
   rw - file is readable and writable
+  wo - write only file
   mmap - file is mmapable
   ascii - file contains ascii text
   binary - file contains binary data
@@ -73,6 +76,13 @@ that the device must be enabled for a rom read to return data succesfully.
 In the event a driver is not bound to the device, it can be enabled using the
 'enable' file, documented above.
 
+The 'remove' file is used to remove the PCI device, by writing a non-zero
+integer to the file.  This does not involve any kind of hot-plug functionality,
+e.g. powering off the device.  The device is removed from the kernel's list of
+PCI devices, the sysfs directory for it is removed, and the device will be
+removed from any drivers attached to it. Removal of PCI root buses is
+disallowed.
+
 Accessing legacy resources through sysfs
 ----------------------------------------
 
index 1fee6f1e6bc5574102b04d13d5ed1fd1396f0641..5e97f333c4df547e79507631a5b848578409f3d6 100644 (file)
@@ -49,12 +49,9 @@ of up to +/- 0.5 degrees even when compared against precise temperature
 readings. Be sure to have a high vs. low temperature limit gap of al least
 1.0 degree Celsius to avoid Tout "bouncing", though!
 
-As for alarms, you can read the alarm status of the DS1621 via the 'alarms'
-/sys file interface. The result consists mainly of bit 6 and 5 of the
-configuration register of the chip; bit 6 (0x40 or 64) is the high alarm
-bit and bit 5 (0x20 or 32) the low one. These bits are set when the high or
-low limits are met or exceeded and are reset by the module as soon as the
-respective temperature ranges are left.
+The alarm bits are set when the high or low limits are met or exceeded and
+are reset by the module as soon as the respective temperature ranges are
+left.
 
 The alarm registers are in no way suitable to find out about the actual
 status of Tout. They will only tell you about its history, whether or not
@@ -64,45 +61,3 @@ with neither of the alarms set.
 
 Temperature conversion of the DS1621 takes up to 1000ms; internal access to
 non-volatile registers may last for 10ms or below.
-
-High Accuracy Temperature Reading
----------------------------------
-
-As said before, the temperature issued via the 9-bit i2c-bus data is
-somewhat arbitrary. Internally, the temperature conversion is of a
-different kind that is explained (not so...) well in the DS1621 data sheet.
-To cut the long story short: Inside the DS1621 there are two oscillators,
-both of them biassed by a temperature coefficient.
-
-Higher resolution of the temperature reading can be achieved using the
-internal projection, which means taking account of REG_COUNT and REG_SLOPE
-(the driver manages them):
-
-Taken from Dallas Semiconductors App Note 068: 'Increasing Temperature
-Resolution on the DS1620' and App Note 105: 'High Resolution Temperature
-Measurement with Dallas Direct-to-Digital Temperature Sensors'
-
-- Read the 9-bit temperature and strip the LSB (Truncate the .5 degs)
-- The resulting value is TEMP_READ.
-- Then, read REG_COUNT.
-- And then, REG_SLOPE.
-
-      TEMP = TEMP_READ - 0.25 + ((REG_SLOPE - REG_COUNT) / REG_SLOPE)
-
-Note that this is what the DONE bit in the DS1621 configuration register is
-good for: Internally, one temperature conversion takes up to 1000ms. Before
-that conversion is complete you will not be able to read valid things out
-of REG_COUNT and REG_SLOPE. The DONE bit, as you may have guessed by now,
-tells you whether the conversion is complete ("done", in plain English) and
-thus, whether the values you read are good or not.
-
-The DS1621 has two modes of operation: "Continuous" conversion, which can
-be understood as the default stand-alone mode where the chip gets the
-temperature and controls external devices via its Tout pin or tells other
-i2c's about it if they care. The other mode is called "1SHOT", that means
-that it only figures out about the temperature when it is explicitly told
-to do so; this can be seen as power saving mode.
-
-Now if you want to read REG_COUNT and REG_SLOPE, you have to either stop
-the continuous conversions until the contents of these registers are valid,
-or, in 1SHOT mode, you have to have one conversion made.
index 287f8c902656db40353954b967b06503d517dc70..effe949a7282cccd600365bffe78dd70541b9aa3 100644 (file)
@@ -1,11 +1,11 @@
 Kernel driver lis3lv02d
-==================
+=======================
 
 Supported chips:
 
   * STMicroelectronics LIS3LV02DL and LIS3LV02DQ
 
-Author:
+Authors:
         Yan Burman <burman.yan@gmail.com>
        Eric Piel <eric.piel@tremplin-utc.net>
 
@@ -15,7 +15,7 @@ Description
 
 This driver provides support for the accelerometer found in various HP
 laptops sporting the feature officially called "HP Mobile Data
-Protection System 3D" or "HP 3D DriveGuard". It detect automatically
+Protection System 3D" or "HP 3D DriveGuard". It detects automatically
 laptops with this sensor. Known models (for now the HP 2133, nc6420,
 nc2510, nc8510, nc84x0, nw9440 and nx9420) will have their axis
 automatically oriented on standard way (eg: you can directly play
@@ -27,7 +27,7 @@ position - 3D position that the accelerometer reports. Format: "(x,y,z)"
 calibrate - read: values (x, y, z) that are used as the base for input
                  class device operation.
             write: forces the base to be recalibrated with the current
-                 position.
+                  position.
 rate - reports the sampling rate of the accelerometer device in HZ
 
 This driver also provides an absolute input class device, allowing
@@ -48,7 +48,7 @@ For better compatibility between the various laptops. The values reported by
 the accelerometer are converted into a "standard" organisation of the axes
 (aka "can play neverball out of the box"):
  * When the laptop is horizontal the position reported is about 0 for X and Y
-and a positive value for Z
+       and a positive value for Z
  * If the left side is elevated, X increases (becomes positive)
  * If the front side (where the touchpad is) is elevated, Y decreases
        (becomes negative)
@@ -59,3 +59,13 @@ email to the authors to add it to the database.  When reporting a new
 laptop, please include the output of "dmidecode" plus the value of
 /sys/devices/platform/lis3lv02d/position in these four cases.
 
+Q&A
+---
+
+Q: How do I safely simulate freefall? I have an HP "portable
+workstation" which has about 3.5kg and a plastic case, so letting it
+fall to the ground is out of question...
+
+A: The sensor is pretty sensitive, so your hands can do it. Lift it
+into free space, follow the fall with your hands for like 10
+centimeters. That should be enough to trigger the detection.
diff --git a/Documentation/hwmon/ltc4215 b/Documentation/hwmon/ltc4215
new file mode 100644 (file)
index 0000000..2e6a21e
--- /dev/null
@@ -0,0 +1,50 @@
+Kernel driver ltc4215
+=====================
+
+Supported chips:
+  * Linear Technology LTC4215
+    Prefix: 'ltc4215'
+    Addresses scanned: 0x44
+    Datasheet:
+        http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1006,C1163,P17572,D12697
+
+Author: Ira W. Snyder <iws@ovro.caltech.edu>
+
+
+Description
+-----------
+
+The LTC4215 controller allows a board to be safely inserted and removed
+from a live backplane.
+
+
+Usage Notes
+-----------
+
+This driver does not probe for LTC4215 devices, due to the fact that some
+of the possible addresses are unfriendly to probing. You will need to use
+the "force" parameter to tell the driver where to find the device.
+
+Example: the following will load the driver for an LTC4215 at address 0x44
+on I2C bus #0:
+$ modprobe ltc4215 force=0,0x44
+
+
+Sysfs entries
+-------------
+
+The LTC4215 has built-in limits for overvoltage, undervoltage, and
+undercurrent warnings. This makes it very likely that the reference
+circuit will be used.
+
+in1_input              input voltage
+in2_input              output voltage
+
+in1_min_alarm          input undervoltage alarm
+in1_max_alarm          input overvoltage alarm
+
+curr1_input            current
+curr1_max_alarm                overcurrent alarm
+
+power1_input           power usage
+power1_alarm           power bad alarm
index 6dbfd5efd991de9f6a69eaa831d1a45634ba5979..2f10ce6a879f7276f635cd1ac51c03d8c004d8c1 100644 (file)
@@ -365,6 +365,7 @@ energy[1-*]_input           Cumulative energy use
                                Unit: microJoule
                                RO
 
+
 **********
 * Alarms *
 **********
@@ -453,6 +454,27 @@ beep_mask  Bitmask for beep.
                RW
 
 
+***********************
+* Intrusion detection *
+***********************
+
+intrusion[0-*]_alarm
+               Chassis intrusion detection
+               0: OK
+               1: intrusion detected
+               RW
+               Contrary to regular alarm flags which clear themselves
+               automatically when read, this one sticks until cleared by
+               the user. This is done by writing 0 to the file. Writing
+               other values is unsupported.
+
+intrusion[0-*]_beep
+               Chassis intrusion beep
+               0: disable
+               1: enable
+               RW
+
+
 sysfs attribute writes interpretation
 -------------------------------------
 
index d6e1ae30fa6e61f3da3e523befa708dcfbedb627..b6eb59384bb39c1b67d0c99a1ade601269a64d05 100644 (file)
@@ -2,30 +2,40 @@ Kernel driver w83627ehf
 =======================
 
 Supported chips:
-  * Winbond W83627EHF/EHG/DHG (ISA access ONLY)
+  * Winbond W83627EHF/EHG (ISA access ONLY)
     Prefix: 'w83627ehf'
     Addresses scanned: ISA address retrieved from Super I/O registers
     Datasheet:
-        http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf
-        DHG datasheet confidential.
+        http://www.nuvoton.com.tw/NR/rdonlyres/A6A258F0-F0C9-4F97-81C0-C4D29E7E943E/0/W83627EHF.pdf
+  * Winbond W83627DHG
+    Prefix: 'w83627dhg'
+    Addresses scanned: ISA address retrieved from Super I/O registers
+    Datasheet:
+        http://www.nuvoton.com.tw/NR/rdonlyres/7885623D-A487-4CF9-A47F-30C5F73D6FE6/0/W83627DHG.pdf
+  * Winbond W83667HG
+    Prefix: 'w83667hg'
+    Addresses scanned: ISA address retrieved from Super I/O registers
+    Datasheet: not available
 
 Authors:
         Jean Delvare <khali@linux-fr.org>
         Yuan Mu (Winbond)
         Rudolf Marek <r.marek@assembler.cz>
         David Hubbard <david.c.hubbard@gmail.com>
+        Gong Jun <JGong@nuvoton.com>
 
 Description
 -----------
 
-This driver implements support for the Winbond W83627EHF, W83627EHG, and
-W83627DHG super I/O chips. We will refer to them collectively as Winbond chips.
+This driver implements support for the Winbond W83627EHF, W83627EHG,
+W83627DHG and W83667HG super I/O chips. We will refer to them collectively
+as Winbond chips.
 
 The chips implement three temperature sensors, five fan rotation
 speed sensors, ten analog voltage sensors (only nine for the 627DHG), one
-VID (6 pins for the 627EHF/EHG, 8 pins for the 627DHG), alarms with beep
-warnings (control unimplemented), and some automatic fan regulation
-strategies (plus manual fan control mode).
+VID (6 pins for the 627EHF/EHG, 8 pins for the 627DHG and 667HG), alarms
+with beep warnings (control unimplemented), and some automatic fan
+regulation strategies (plus manual fan control mode).
 
 Temperatures are measured in degrees Celsius and measurement resolution is 1
 degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
@@ -54,7 +64,8 @@ follows:
 temp1 -> pwm1
 temp2 -> pwm2
 temp3 -> pwm3
-prog  -> pwm4 (the programmable setting is not supported by the driver)
+prog  -> pwm4 (not on 667HG; the programmable setting is not supported by
+              the driver)
 
 /sys files
 ----------
index be3bde51b56413c27ad92a3949b816d645f15768..240257dd4238fc55608989541b79c37e40101abc 100644 (file)
@@ -492,6 +492,16 @@ and is between 256 and 4096 characters. It is defined in the file
                        Range: 0 - 8192
                        Default: 64
 
+       dma_debug=off   If the kernel is compiled with DMA_API_DEBUG support
+                       this option disables the debugging code at boot.
+
+       dma_debug_entries=<number>
+                       This option allows to tune the number of preallocated
+                       entries for DMA-API debugging code. One entry is
+                       required per DMA-API allocation. Use this if the
+                       DMA-API debugging code disables itself because the
+                       architectural default is too low.
+
        hpet=           [X86-32,HPET] option to control HPET usage
                        Format: { enable (default) | disable | force |
                                verbose }
@@ -1685,6 +1695,8 @@ and is between 256 and 4096 characters. It is defined in the file
                        See also Documentation/blockdev/paride.txt.
 
        pci=option[,option...]  [PCI] various PCI subsystem options:
+               earlydump       [X86] dump PCI config space before the kernel
+                               changes anything
                off             [X86] don't probe for the PCI bus
                bios            [X86-32] force use of PCI BIOS, don't access
                                the hardware directly. Use this if your machine
@@ -1784,6 +1796,15 @@ and is between 256 and 4096 characters. It is defined in the file
                cbmemsize=nn[KMG]       The fixed amount of bus space which is
                                reserved for the CardBus bridge's memory
                                window. The default value is 64 megabytes.
+               resource_alignment=
+                               Format:
+                               [<order of align>@][<domain>:]<bus>:<slot>.<func>[; ...]
+                               Specifies alignment and device to reassign
+                               aligned memory resources.
+                               If <order of align> is not specified,
+                               PAGE_SIZE is used as alignment.
+                               PCI-PCI bridge can be specified, if resource
+                               windows need to be expanded.
 
        pcie_aspm=      [PCIE] Forcibly enable or disable PCIe Active State Power
                        Management.
index f2dbbf3bdeaba7a5c6d58e1ccb3f8a686ade88ed..d36fcc0f2715c705d0f70d1aa9c13e20b8aaa917 100644 (file)
@@ -1630,6 +1630,13 @@ static bool service_io(struct device *dev)
                }
        }
 
+       /* OK, so we noted that it was pretty poor to use an fdatasync as a
+        * barrier.  But Christoph Hellwig points out that we need a sync
+        * *afterwards* as well: "Barriers specify no reordering to the front
+        * or the back."  And Jens Axboe confirmed it, so here we are: */
+       if (out->type & VIRTIO_BLK_T_BARRIER)
+               fdatasync(vblk->fd);
+
        /* We can't trigger an IRQ, because we're not the Launcher.  It does
         * that when we tell it we're done. */
        add_used(dev->vq, head, wlen);
index 488773018152056ea159685e732e42452a7ae142..938ea22f2cc096f6838a678217e463bf9ec0cd4d 100644 (file)
@@ -27,33 +27,37 @@ lock-class.
 State
 -----
 
-The validator tracks lock-class usage history into 5 separate state bits:
+The validator tracks lock-class usage history into 4n + 1 separate state bits:
 
-- 'ever held in hardirq context'                    [ == hardirq-safe   ]
-- 'ever held in softirq context'                    [ == softirq-safe   ]
-- 'ever held with hardirqs enabled'                 [ == hardirq-unsafe ]
-- 'ever held with softirqs and hardirqs enabled'    [ == softirq-unsafe ]
+- 'ever held in STATE context'
+- 'ever head as readlock in STATE context'
+- 'ever head with STATE enabled'
+- 'ever head as readlock with STATE enabled'
+
+Where STATE can be either one of (kernel/lockdep_states.h)
+ - hardirq
+ - softirq
+ - reclaim_fs
 
 - 'ever used'                                       [ == !unused        ]
 
-When locking rules are violated, these state bits are presented in the
-locking error messages, inside curlies.  A contrived example:
+When locking rules are violated, these state bits are presented in the
+locking error messages, inside curlies. A contrived example:
 
    modprobe/2287 is trying to acquire lock:
-    (&sio_locks[i].lock){--..}, at: [<c02867fd>] mutex_lock+0x21/0x24
+    (&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24
 
    but task is already holding lock:
-    (&sio_locks[i].lock){--..}, at: [<c02867fd>] mutex_lock+0x21/0x24
+    (&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24
 
 
-The bit position indicates hardirq, softirq, hardirq-read,
-softirq-read respectively, and the character displayed in each
-indicates:
+The bit position indicates STATE, STATE-read, for each of the states listed
+above, and the character displayed in each indicates:
 
    '.'  acquired while irqs disabled
    '+'  acquired in irq context
    '-'  acquired with irqs enabled
-   '?' read acquired in irq context with irqs enabled.
+   '?'  acquired in irq context with irqs enabled.
 
 Unused mutexes cannot be part of the cause of an error.
 
diff --git a/Documentation/misc-devices/isl29003 b/Documentation/misc-devices/isl29003
new file mode 100644 (file)
index 0000000..c4ff5f3
--- /dev/null
@@ -0,0 +1,62 @@
+Kernel driver isl29003
+=====================
+
+Supported chips:
+* Intersil ISL29003
+Prefix: 'isl29003'
+Addresses scanned: none
+Datasheet:
+http://www.intersil.com/data/fn/fn7464.pdf
+
+Author: Daniel Mack <daniel@caiaq.de>
+
+
+Description
+-----------
+The ISL29003 is an integrated light sensor with a 16-bit integrating type
+ADC, I2C user programmable lux range select for optimized counts/lux, and
+I2C multi-function control and monitoring capabilities. The internal ADC
+provides 16-bit resolution while rejecting 50Hz and 60Hz flicker caused by
+artificial light sources.
+
+The driver allows to set the lux range, the bit resolution, the operational
+mode (see below) and the power state of device and can read the current lux
+value, of course.
+
+
+Detection
+---------
+
+The ISL29003 does not have an ID register which could be used to identify
+it, so the detection routine will just try to read from the configured I2C
+addess and consider the device to be present as soon as it ACKs the
+transfer.
+
+
+Sysfs entries
+-------------
+
+range:
+       0: 0 lux to 1000 lux (default)
+       1: 0 lux to 4000 lux
+       2: 0 lux to 16,000 lux
+       3: 0 lux to 64,000 lux
+
+resolution:
+       0: 2^16 cycles (default)
+       1: 2^12 cycles
+       2: 2^8 cycles
+       3: 2^4 cycles
+
+mode:
+       0: diode1's current (unsigned 16bit) (default)
+       1: diode1's current (unsigned 16bit)
+       2: difference between diodes (l1 - l2, signed 15bit)
+
+power_state:
+       0: device is disabled (default)
+       1: device is enabled
+
+lux (read only):
+       returns the value from the last sensor reading
+
diff --git a/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt b/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt
new file mode 100644 (file)
index 0000000..c39ac28
--- /dev/null
@@ -0,0 +1,23 @@
+MMC/SD/SDIO slot directly connected to a SPI bus
+
+Required properties:
+- compatible : should be "mmc-spi-slot".
+- reg : should specify SPI address (chip-select number).
+- spi-max-frequency : maximum frequency for this device (Hz).
+- voltage-ranges : two cells are required, first cell specifies minimum
+  slot voltage (mV), second cell specifies maximum slot voltage (mV).
+  Several ranges could be specified.
+- gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO,
+  Write-Protect GPIO.
+
+Example:
+
+       mmc-slot@0 {
+               compatible = "fsl,mpc8323rdb-mmc-slot",
+                            "mmc-spi-slot";
+               reg = <0>;
+               gpios = <&qe_pio_d 14 1
+                        &qe_pio_d 15 0>;
+               voltage-ranges = <3300 3300>;
+               spi-max-frequency = <50000000>;
+       };
index 9e592c718afb4bb41737399b29ff088adca386da..afa2946892da0e8c785d6b1d2fe879751b397499 100644 (file)
@@ -81,6 +81,8 @@ On all -  write a character to /proc/sysrq-trigger.  e.g.:
 
 'i'     - Send a SIGKILL to all processes, except for init.
 
+'j'     - Forcibly "Just thaw it" - filesystems frozen by the FIFREEZE ioctl.
+
 'k'     - Secure Access Key (SAK) Kills all programs on the current virtual
           console. NOTE: See important comments below in SAK section.
 
@@ -160,6 +162,9 @@ t'E'rm and k'I'll are useful if you have some sort of runaway process you
 are unable to kill any other way, especially if it's spawning other
 processes.
 
+"'J'ust thaw it" is useful if your system becomes unresponsive due to a frozen
+(probably root) filesystem via the FIFREEZE ioctl.
+
 *  Sometimes SysRq seems to get 'stuck' after using it, what can I do?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 That happens to me, also. I've found that tapping shift, alt, and control
index d20c786baf2eae4b5d68109c53a3dbe43aef0169..068f5fb900209102a96e99d79a0adcece8238d6c 100644 (file)
@@ -357,6 +357,7 @@ S:  Odd Fixes for 2.4; Maintained for 2.6.
 P:     Ivan Kokshaysky
 M:     ink@jurassic.park.msu.ru
 S:     Maintained for 2.4; PCI support for 2.6.
+L:     linux-alpha@vger.kernel.org
 
 AMD GEODE CS5536 USB DEVICE CONTROLLER DRIVER
 P:     Thomas Dahlmann
index 550dab22daa14b492d88258c9eb8ae7498d76ec1..830c16a2b801d38795139b941f277011e760ba37 100644 (file)
@@ -106,3 +106,5 @@ config HAVE_CLK
          The <linux/clk.h> calls support software clock gating and
          thus are a key power management tool on many systems.
 
+config HAVE_DMA_API_DEBUG
+       bool
index fea4ea75b79d20d08cac71369968a5d95c4a104b..13cd42743810e916b1be719497ac511034ddef67 100644 (file)
@@ -80,7 +80,7 @@ struct alpha_machine_vector
        void (*update_irq_hw)(unsigned long, unsigned long, int);
        void (*ack_irq)(unsigned long);
        void (*device_interrupt)(unsigned long vector);
-       void (*machine_check)(u64 vector, u64 la);
+       void (*machine_check)(unsigned long vector, unsigned long la);
 
        void (*smp_callin)(void);
        void (*init_arch)(void);
index 2a14302c17a337194cf3df0a7d20ae4dfa28273d..cb04eaa6ba33d13fb7be187c2bcd67ea626a2bfa 100644 (file)
@@ -273,4 +273,18 @@ struct pci_dev *alpha_gendev_to_pci(struct device *dev);
 
 extern struct pci_dev *isa_bridge;
 
+extern int pci_legacy_read(struct pci_bus *bus, loff_t port, u32 *val,
+                          size_t count);
+extern int pci_legacy_write(struct pci_bus *bus, loff_t port, u32 val,
+                           size_t count);
+extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
+                                     struct vm_area_struct *vma,
+                                     enum pci_mmap_state mmap_state);
+extern void pci_adjust_legacy_attr(struct pci_bus *bus,
+                                  enum pci_mmap_state mmap_type);
+#define HAVE_PCI_LEGACY        1
+
+extern int pci_create_resource_files(struct pci_dev *dev);
+extern void pci_remove_resource_files(struct pci_dev *dev);
+
 #endif /* __ALPHA_PCI_H */
index afe20fa58c990927fd10c5e94d41fe4d8d9eee8a..5aa40cca4f2356ea12a62e8576d50303a2b704b5 100644 (file)
@@ -309,518 +309,71 @@ extern int __min_ipl;
 #define tbia()         __tbi(-2, /* no second argument */)
 
 /*
- * Atomic exchange.
- * Since it can be used to implement critical sections
- * it must clobber "memory" (also for interrupts in UP).
+ * Atomic exchange routines.
  */
 
-static inline unsigned long
-__xchg_u8(volatile char *m, unsigned long val)
-{
-       unsigned long ret, tmp, addr64;
-
-       __asm__ __volatile__(
-       "       andnot  %4,7,%3\n"
-       "       insbl   %1,%4,%1\n"
-       "1:     ldq_l   %2,0(%3)\n"
-       "       extbl   %2,%4,%0\n"
-       "       mskbl   %2,%4,%2\n"
-       "       or      %1,%2,%2\n"
-       "       stq_c   %2,0(%3)\n"
-       "       beq     %2,2f\n"
-#ifdef CONFIG_SMP
-       "       mb\n"
-#endif
-       ".subsection 2\n"
-       "2:     br      1b\n"
-       ".previous"
-       : "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
-       : "r" ((long)m), "1" (val) : "memory");
-
-       return ret;
-}
-
-static inline unsigned long
-__xchg_u16(volatile short *m, unsigned long val)
-{
-       unsigned long ret, tmp, addr64;
-
-       __asm__ __volatile__(
-       "       andnot  %4,7,%3\n"
-       "       inswl   %1,%4,%1\n"
-       "1:     ldq_l   %2,0(%3)\n"
-       "       extwl   %2,%4,%0\n"
-       "       mskwl   %2,%4,%2\n"
-       "       or      %1,%2,%2\n"
-       "       stq_c   %2,0(%3)\n"
-       "       beq     %2,2f\n"
-#ifdef CONFIG_SMP
-       "       mb\n"
-#endif
-       ".subsection 2\n"
-       "2:     br      1b\n"
-       ".previous"
-       : "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
-       : "r" ((long)m), "1" (val) : "memory");
-
-       return ret;
-}
-
-static inline unsigned long
-__xchg_u32(volatile int *m, unsigned long val)
-{
-       unsigned long dummy;
-
-       __asm__ __volatile__(
-       "1:     ldl_l %0,%4\n"
-       "       bis $31,%3,%1\n"
-       "       stl_c %1,%2\n"
-       "       beq %1,2f\n"
-#ifdef CONFIG_SMP
-       "       mb\n"
-#endif
-       ".subsection 2\n"
-       "2:     br 1b\n"
-       ".previous"
-       : "=&r" (val), "=&r" (dummy), "=m" (*m)
-       : "rI" (val), "m" (*m) : "memory");
-
-       return val;
-}
-
-static inline unsigned long
-__xchg_u64(volatile long *m, unsigned long val)
-{
-       unsigned long dummy;
-
-       __asm__ __volatile__(
-       "1:     ldq_l %0,%4\n"
-       "       bis $31,%3,%1\n"
-       "       stq_c %1,%2\n"
-       "       beq %1,2f\n"
-#ifdef CONFIG_SMP
-       "       mb\n"
-#endif
-       ".subsection 2\n"
-       "2:     br 1b\n"
-       ".previous"
-       : "=&r" (val), "=&r" (dummy), "=m" (*m)
-       : "rI" (val), "m" (*m) : "memory");
+#define __ASM__MB
+#define ____xchg(type, args...)                __xchg ## type ## _local(args)
+#define ____cmpxchg(type, args...)     __cmpxchg ## type ## _local(args)
+#include <asm/xchg.h>
 
-       return val;
-}
-
-/* This function doesn't exist, so you'll get a linker error
-   if something tries to do an invalid xchg().  */
-extern void __xchg_called_with_bad_pointer(void);
-
-#define __xchg(ptr, x, size) \
-({ \
-       unsigned long __xchg__res; \
-       volatile void *__xchg__ptr = (ptr); \
-       switch (size) { \
-               case 1: __xchg__res = __xchg_u8(__xchg__ptr, x); break; \
-               case 2: __xchg__res = __xchg_u16(__xchg__ptr, x); break; \
-               case 4: __xchg__res = __xchg_u32(__xchg__ptr, x); break; \
-               case 8: __xchg__res = __xchg_u64(__xchg__ptr, x); break; \
-               default: __xchg_called_with_bad_pointer(); __xchg__res = x; \
-       } \
-       __xchg__res; \
-})
-
-#define xchg(ptr,x)                                                         \
-  ({                                                                        \
-     __typeof__(*(ptr)) _x_ = (x);                                          \
-     (__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_, sizeof(*(ptr))); \
+#define xchg_local(ptr,x)                                              \
+  ({                                                                   \
+     __typeof__(*(ptr)) _x_ = (x);                                     \
+     (__typeof__(*(ptr))) __xchg_local((ptr), (unsigned long)_x_,      \
+                                      sizeof(*(ptr)));                 \
   })
 
-static inline unsigned long
-__xchg_u8_local(volatile char *m, unsigned long val)
-{
-       unsigned long ret, tmp, addr64;
-
-       __asm__ __volatile__(
-       "       andnot  %4,7,%3\n"
-       "       insbl   %1,%4,%1\n"
-       "1:     ldq_l   %2,0(%3)\n"
-       "       extbl   %2,%4,%0\n"
-       "       mskbl   %2,%4,%2\n"
-       "       or      %1,%2,%2\n"
-       "       stq_c   %2,0(%3)\n"
-       "       beq     %2,2f\n"
-       ".subsection 2\n"
-       "2:     br      1b\n"
-       ".previous"
-       : "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
-       : "r" ((long)m), "1" (val) : "memory");
-
-       return ret;
-}
-
-static inline unsigned long
-__xchg_u16_local(volatile short *m, unsigned long val)
-{
-       unsigned long ret, tmp, addr64;
-
-       __asm__ __volatile__(
-       "       andnot  %4,7,%3\n"
-       "       inswl   %1,%4,%1\n"
-       "1:     ldq_l   %2,0(%3)\n"
-       "       extwl   %2,%4,%0\n"
-       "       mskwl   %2,%4,%2\n"
-       "       or      %1,%2,%2\n"
-       "       stq_c   %2,0(%3)\n"
-       "       beq     %2,2f\n"
-       ".subsection 2\n"
-       "2:     br      1b\n"
-       ".previous"
-       : "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
-       : "r" ((long)m), "1" (val) : "memory");
-
-       return ret;
-}
-
-static inline unsigned long
-__xchg_u32_local(volatile int *m, unsigned long val)
-{
-       unsigned long dummy;
-
-       __asm__ __volatile__(
-       "1:     ldl_l %0,%4\n"
-       "       bis $31,%3,%1\n"
-       "       stl_c %1,%2\n"
-       "       beq %1,2f\n"
-       ".subsection 2\n"
-       "2:     br 1b\n"
-       ".previous"
-       : "=&r" (val), "=&r" (dummy), "=m" (*m)
-       : "rI" (val), "m" (*m) : "memory");
-
-       return val;
-}
-
-static inline unsigned long
-__xchg_u64_local(volatile long *m, unsigned long val)
-{
-       unsigned long dummy;
-
-       __asm__ __volatile__(
-       "1:     ldq_l %0,%4\n"
-       "       bis $31,%3,%1\n"
-       "       stq_c %1,%2\n"
-       "       beq %1,2f\n"
-       ".subsection 2\n"
-       "2:     br 1b\n"
-       ".previous"
-       : "=&r" (val), "=&r" (dummy), "=m" (*m)
-       : "rI" (val), "m" (*m) : "memory");
-
-       return val;
-}
-
-#define __xchg_local(ptr, x, size) \
-({ \
-       unsigned long __xchg__res; \
-       volatile void *__xchg__ptr = (ptr); \
-       switch (size) { \
-               case 1: __xchg__res = __xchg_u8_local(__xchg__ptr, x); break; \
-               case 2: __xchg__res = __xchg_u16_local(__xchg__ptr, x); break; \
-               case 4: __xchg__res = __xchg_u32_local(__xchg__ptr, x); break; \
-               case 8: __xchg__res = __xchg_u64_local(__xchg__ptr, x); break; \
-               default: __xchg_called_with_bad_pointer(); __xchg__res = x; \
-       } \
-       __xchg__res; \
-})
-
-#define xchg_local(ptr,x)                                                   \
-  ({                                                                        \
-     __typeof__(*(ptr)) _x_ = (x);                                          \
-     (__typeof__(*(ptr))) __xchg_local((ptr), (unsigned long)_x_,           \
-               sizeof(*(ptr))); \
+#define cmpxchg_local(ptr, o, n)                                       \
+  ({                                                                   \
+     __typeof__(*(ptr)) _o_ = (o);                                     \
+     __typeof__(*(ptr)) _n_ = (n);                                     \
+     (__typeof__(*(ptr))) __cmpxchg_local((ptr), (unsigned long)_o_,   \
+                                         (unsigned long)_n_,           \
+                                         sizeof(*(ptr)));              \
   })
 
-/* 
- * Atomic compare and exchange.  Compare OLD with MEM, if identical,
- * store NEW in MEM.  Return the initial value in MEM.  Success is
- * indicated by comparing RETURN with OLD.
- *
- * The memory barrier should be placed in SMP only when we actually
- * make the change. If we don't change anything (so if the returned
- * prev is equal to old) then we aren't acquiring anything new and
- * we don't need any memory barrier as far I can tell.
- */
-
-#define __HAVE_ARCH_CMPXCHG 1
-
-static inline unsigned long
-__cmpxchg_u8(volatile char *m, long old, long new)
-{
-       unsigned long prev, tmp, cmp, addr64;
-
-       __asm__ __volatile__(
-       "       andnot  %5,7,%4\n"
-       "       insbl   %1,%5,%1\n"
-       "1:     ldq_l   %2,0(%4)\n"
-       "       extbl   %2,%5,%0\n"
-       "       cmpeq   %0,%6,%3\n"
-       "       beq     %3,2f\n"
-       "       mskbl   %2,%5,%2\n"
-       "       or      %1,%2,%2\n"
-       "       stq_c   %2,0(%4)\n"
-       "       beq     %2,3f\n"
-#ifdef CONFIG_SMP
-       "       mb\n"
-#endif
-       "2:\n"
-       ".subsection 2\n"
-       "3:     br      1b\n"
-       ".previous"
-       : "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
-       : "r" ((long)m), "Ir" (old), "1" (new) : "memory");
-
-       return prev;
-}
-
-static inline unsigned long
-__cmpxchg_u16(volatile short *m, long old, long new)
-{
-       unsigned long prev, tmp, cmp, addr64;
-
-       __asm__ __volatile__(
-       "       andnot  %5,7,%4\n"
-       "       inswl   %1,%5,%1\n"
-       "1:     ldq_l   %2,0(%4)\n"
-       "       extwl   %2,%5,%0\n"
-       "       cmpeq   %0,%6,%3\n"
-       "       beq     %3,2f\n"
-       "       mskwl   %2,%5,%2\n"
-       "       or      %1,%2,%2\n"
-       "       stq_c   %2,0(%4)\n"
-       "       beq     %2,3f\n"
-#ifdef CONFIG_SMP
-       "       mb\n"
-#endif
-       "2:\n"
-       ".subsection 2\n"
-       "3:     br      1b\n"
-       ".previous"
-       : "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
-       : "r" ((long)m), "Ir" (old), "1" (new) : "memory");
-
-       return prev;
-}
-
-static inline unsigned long
-__cmpxchg_u32(volatile int *m, int old, int new)
-{
-       unsigned long prev, cmp;
-
-       __asm__ __volatile__(
-       "1:     ldl_l %0,%5\n"
-       "       cmpeq %0,%3,%1\n"
-       "       beq %1,2f\n"
-       "       mov %4,%1\n"
-       "       stl_c %1,%2\n"
-       "       beq %1,3f\n"
-#ifdef CONFIG_SMP
-       "       mb\n"
-#endif
-       "2:\n"
-       ".subsection 2\n"
-       "3:     br 1b\n"
-       ".previous"
-       : "=&r"(prev), "=&r"(cmp), "=m"(*m)
-       : "r"((long) old), "r"(new), "m"(*m) : "memory");
-
-       return prev;
-}
+#define cmpxchg64_local(ptr, o, n)                                     \
+  ({                                                                   \
+       BUILD_BUG_ON(sizeof(*(ptr)) != 8);                              \
+       cmpxchg_local((ptr), (o), (n));                                 \
+  })
 
-static inline unsigned long
-__cmpxchg_u64(volatile long *m, unsigned long old, unsigned long new)
-{
-       unsigned long prev, cmp;
-
-       __asm__ __volatile__(
-       "1:     ldq_l %0,%5\n"
-       "       cmpeq %0,%3,%1\n"
-       "       beq %1,2f\n"
-       "       mov %4,%1\n"
-       "       stq_c %1,%2\n"
-       "       beq %1,3f\n"
 #ifdef CONFIG_SMP
-       "       mb\n"
+#undef __ASM__MB
+#define __ASM__MB      "\tmb\n"
 #endif
-       "2:\n"
-       ".subsection 2\n"
-       "3:     br 1b\n"
-       ".previous"
-       : "=&r"(prev), "=&r"(cmp), "=m"(*m)
-       : "r"((long) old), "r"(new), "m"(*m) : "memory");
-
-       return prev;
-}
-
-/* This function doesn't exist, so you'll get a linker error
-   if something tries to do an invalid cmpxchg().  */
-extern void __cmpxchg_called_with_bad_pointer(void);
-
-static __always_inline unsigned long
-__cmpxchg(volatile void *ptr, unsigned long old, unsigned long new, int size)
-{
-       switch (size) {
-               case 1:
-                       return __cmpxchg_u8(ptr, old, new);
-               case 2:
-                       return __cmpxchg_u16(ptr, old, new);
-               case 4:
-                       return __cmpxchg_u32(ptr, old, new);
-               case 8:
-                       return __cmpxchg_u64(ptr, old, new);
-       }
-       __cmpxchg_called_with_bad_pointer();
-       return old;
-}
-
-#define cmpxchg(ptr, o, n)                                              \
-  ({                                                                    \
-     __typeof__(*(ptr)) _o_ = (o);                                      \
-     __typeof__(*(ptr)) _n_ = (n);                                      \
-     (__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_,          \
-                                   (unsigned long)_n_, sizeof(*(ptr))); \
+#undef ____xchg
+#undef ____cmpxchg
+#define ____xchg(type, args...)                __xchg ##type(args)
+#define ____cmpxchg(type, args...)     __cmpxchg ##type(args)
+#include <asm/xchg.h>
+
+#define xchg(ptr,x)                                                    \
+  ({                                                                   \
+     __typeof__(*(ptr)) _x_ = (x);                                     \
+     (__typeof__(*(ptr))) __xchg((ptr), (unsigned long)_x_,            \
+                                sizeof(*(ptr)));                       \
   })
-#define cmpxchg64(ptr, o, n)                                            \
-  ({                                                                    \
-       BUILD_BUG_ON(sizeof(*(ptr)) != 8);                               \
-       cmpxchg((ptr), (o), (n));                                        \
-  })
-
-static inline unsigned long
-__cmpxchg_u8_local(volatile char *m, long old, long new)
-{
-       unsigned long prev, tmp, cmp, addr64;
-
-       __asm__ __volatile__(
-       "       andnot  %5,7,%4\n"
-       "       insbl   %1,%5,%1\n"
-       "1:     ldq_l   %2,0(%4)\n"
-       "       extbl   %2,%5,%0\n"
-       "       cmpeq   %0,%6,%3\n"
-       "       beq     %3,2f\n"
-       "       mskbl   %2,%5,%2\n"
-       "       or      %1,%2,%2\n"
-       "       stq_c   %2,0(%4)\n"
-       "       beq     %2,3f\n"
-       "2:\n"
-       ".subsection 2\n"
-       "3:     br      1b\n"
-       ".previous"
-       : "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
-       : "r" ((long)m), "Ir" (old), "1" (new) : "memory");
-
-       return prev;
-}
-
-static inline unsigned long
-__cmpxchg_u16_local(volatile short *m, long old, long new)
-{
-       unsigned long prev, tmp, cmp, addr64;
-
-       __asm__ __volatile__(
-       "       andnot  %5,7,%4\n"
-       "       inswl   %1,%5,%1\n"
-       "1:     ldq_l   %2,0(%4)\n"
-       "       extwl   %2,%5,%0\n"
-       "       cmpeq   %0,%6,%3\n"
-       "       beq     %3,2f\n"
-       "       mskwl   %2,%5,%2\n"
-       "       or      %1,%2,%2\n"
-       "       stq_c   %2,0(%4)\n"
-       "       beq     %2,3f\n"
-       "2:\n"
-       ".subsection 2\n"
-       "3:     br      1b\n"
-       ".previous"
-       : "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
-       : "r" ((long)m), "Ir" (old), "1" (new) : "memory");
-
-       return prev;
-}
-
-static inline unsigned long
-__cmpxchg_u32_local(volatile int *m, int old, int new)
-{
-       unsigned long prev, cmp;
-
-       __asm__ __volatile__(
-       "1:     ldl_l %0,%5\n"
-       "       cmpeq %0,%3,%1\n"
-       "       beq %1,2f\n"
-       "       mov %4,%1\n"
-       "       stl_c %1,%2\n"
-       "       beq %1,3f\n"
-       "2:\n"
-       ".subsection 2\n"
-       "3:     br 1b\n"
-       ".previous"
-       : "=&r"(prev), "=&r"(cmp), "=m"(*m)
-       : "r"((long) old), "r"(new), "m"(*m) : "memory");
-
-       return prev;
-}
-
-static inline unsigned long
-__cmpxchg_u64_local(volatile long *m, unsigned long old, unsigned long new)
-{
-       unsigned long prev, cmp;
-
-       __asm__ __volatile__(
-       "1:     ldq_l %0,%5\n"
-       "       cmpeq %0,%3,%1\n"
-       "       beq %1,2f\n"
-       "       mov %4,%1\n"
-       "       stq_c %1,%2\n"
-       "       beq %1,3f\n"
-       "2:\n"
-       ".subsection 2\n"
-       "3:     br 1b\n"
-       ".previous"
-       : "=&r"(prev), "=&r"(cmp), "=m"(*m)
-       : "r"((long) old), "r"(new), "m"(*m) : "memory");
-
-       return prev;
-}
-
-static __always_inline unsigned long
-__cmpxchg_local(volatile void *ptr, unsigned long old, unsigned long new,
-               int size)
-{
-       switch (size) {
-               case 1:
-                       return __cmpxchg_u8_local(ptr, old, new);
-               case 2:
-                       return __cmpxchg_u16_local(ptr, old, new);
-               case 4:
-                       return __cmpxchg_u32_local(ptr, old, new);
-               case 8:
-                       return __cmpxchg_u64_local(ptr, old, new);
-       }
-       __cmpxchg_called_with_bad_pointer();
-       return old;
-}
 
-#define cmpxchg_local(ptr, o, n)                                        \
-  ({                                                                    \
-     __typeof__(*(ptr)) _o_ = (o);                                      \
-     __typeof__(*(ptr)) _n_ = (n);                                      \
-     (__typeof__(*(ptr))) __cmpxchg_local((ptr), (unsigned long)_o_,    \
-                                   (unsigned long)_n_, sizeof(*(ptr))); \
+#define cmpxchg(ptr, o, n)                                             \
+  ({                                                                   \
+     __typeof__(*(ptr)) _o_ = (o);                                     \
+     __typeof__(*(ptr)) _n_ = (n);                                     \
+     (__typeof__(*(ptr))) __cmpxchg((ptr), (unsigned long)_o_,         \
+                                   (unsigned long)_n_, sizeof(*(ptr)));\
   })
-#define cmpxchg64_local(ptr, o, n)                                      \
-  ({                                                                    \
-       BUILD_BUG_ON(sizeof(*(ptr)) != 8);                               \
-       cmpxchg_local((ptr), (o), (n));                                  \
+
+#define cmpxchg64(ptr, o, n)                                           \
+  ({                                                                   \
+       BUILD_BUG_ON(sizeof(*(ptr)) != 8);                              \
+       cmpxchg((ptr), (o), (n));                                       \
   })
 
+#undef __ASM__MB
+#undef ____cmpxchg
+
+#define __HAVE_ARCH_CMPXCHG 1
 
 #endif /* __ASSEMBLY__ */
 
index c1541353ccefe04e67fe183ecb2013f7cb491642..f072f344497e7adba62719db66324bb11144c5ae 100644 (file)
@@ -8,7 +8,12 @@
  * not a major issue.  However, for interoperability, libraries still
  * need to be careful to avoid a name clashes.
  */
+
+#ifdef __KERNEL__
+#include <asm-generic/int-ll64.h>
+#else
 #include <asm-generic/int-l64.h>
+#endif
 
 #ifndef __ASSEMBLY__
 
index 22de3b434a22a59d7f16bce6520787efab1fc8f9..163f3053001c82e4976c082d1798ab656615088a 100644 (file)
@@ -498,13 +498,13 @@ struct exception_table_entry
 };
 
 /* Returns the new pc */
-#define fixup_exception(map_reg, fixup, pc)                    \
+#define fixup_exception(map_reg, _fixup, pc)                   \
 ({                                                             \
-       if ((fixup)->fixup.bits.valreg != 31)                   \
-               map_reg((fixup)->fixup.bits.valreg) = 0;        \
-       if ((fixup)->fixup.bits.errreg != 31)                   \
-               map_reg((fixup)->fixup.bits.errreg) = -EFAULT;  \
-       (pc) + (fixup)->fixup.bits.nextinsn;                    \
+       if ((_fixup)->fixup.bits.valreg != 31)                  \
+               map_reg((_fixup)->fixup.bits.valreg) = 0;       \
+       if ((_fixup)->fixup.bits.errreg != 31)                  \
+               map_reg((_fixup)->fixup.bits.errreg) = -EFAULT; \
+       (pc) + (_fixup)->fixup.bits.nextinsn;                   \
 })
 
 
diff --git a/arch/alpha/include/asm/xchg.h b/arch/alpha/include/asm/xchg.h
new file mode 100644 (file)
index 0000000..beba1b8
--- /dev/null
@@ -0,0 +1,258 @@
+#ifndef __ALPHA_SYSTEM_H
+#error Do not include xchg.h directly!
+#else
+/*
+ * xchg/xchg_local and cmpxchg/cmpxchg_local share the same code
+ * except that local version do not have the expensive memory barrier.
+ * So this file is included twice from asm/system.h.
+ */
+
+/*
+ * Atomic exchange.
+ * Since it can be used to implement critical sections
+ * it must clobber "memory" (also for interrupts in UP).
+ */
+
+static inline unsigned long
+____xchg(_u8, volatile char *m, unsigned long val)
+{
+       unsigned long ret, tmp, addr64;
+
+       __asm__ __volatile__(
+       "       andnot  %4,7,%3\n"
+       "       insbl   %1,%4,%1\n"
+       "1:     ldq_l   %2,0(%3)\n"
+       "       extbl   %2,%4,%0\n"
+       "       mskbl   %2,%4,%2\n"
+       "       or      %1,%2,%2\n"
+       "       stq_c   %2,0(%3)\n"
+       "       beq     %2,2f\n"
+               __ASM__MB
+       ".subsection 2\n"
+       "2:     br      1b\n"
+       ".previous"
+       : "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
+       : "r" ((long)m), "1" (val) : "memory");
+
+       return ret;
+}
+
+static inline unsigned long
+____xchg(_u16, volatile short *m, unsigned long val)
+{
+       unsigned long ret, tmp, addr64;
+
+       __asm__ __volatile__(
+       "       andnot  %4,7,%3\n"
+       "       inswl   %1,%4,%1\n"
+       "1:     ldq_l   %2,0(%3)\n"
+       "       extwl   %2,%4,%0\n"
+       "       mskwl   %2,%4,%2\n"
+       "       or      %1,%2,%2\n"
+       "       stq_c   %2,0(%3)\n"
+       "       beq     %2,2f\n"
+               __ASM__MB
+       ".subsection 2\n"
+       "2:     br      1b\n"
+       ".previous"
+       : "=&r" (ret), "=&r" (val), "=&r" (tmp), "=&r" (addr64)
+       : "r" ((long)m), "1" (val) : "memory");
+
+       return ret;
+}
+
+static inline unsigned long
+____xchg(_u32, volatile int *m, unsigned long val)
+{
+       unsigned long dummy;
+
+       __asm__ __volatile__(
+       "1:     ldl_l %0,%4\n"
+       "       bis $31,%3,%1\n"
+       "       stl_c %1,%2\n"
+       "       beq %1,2f\n"
+               __ASM__MB
+       ".subsection 2\n"
+       "2:     br 1b\n"
+       ".previous"
+       : "=&r" (val), "=&r" (dummy), "=m" (*m)
+       : "rI" (val), "m" (*m) : "memory");
+
+       return val;
+}
+
+static inline unsigned long
+____xchg(_u64, volatile long *m, unsigned long val)
+{
+       unsigned long dummy;
+
+       __asm__ __volatile__(
+       "1:     ldq_l %0,%4\n"
+       "       bis $31,%3,%1\n"
+       "       stq_c %1,%2\n"
+       "       beq %1,2f\n"
+               __ASM__MB
+       ".subsection 2\n"
+       "2:     br 1b\n"
+       ".previous"
+       : "=&r" (val), "=&r" (dummy), "=m" (*m)
+       : "rI" (val), "m" (*m) : "memory");
+
+       return val;
+}
+
+/* This function doesn't exist, so you'll get a linker error
+   if something tries to do an invalid xchg().  */
+extern void __xchg_called_with_bad_pointer(void);
+
+static __always_inline unsigned long
+____xchg(, volatile void *ptr, unsigned long x, int size)
+{
+       switch (size) {
+               case 1:
+                       return ____xchg(_u8, ptr, x);
+               case 2:
+                       return ____xchg(_u16, ptr, x);
+               case 4:
+                       return ____xchg(_u32, ptr, x);
+               case 8:
+                       return ____xchg(_u64, ptr, x);
+       }
+       __xchg_called_with_bad_pointer();
+       return x;
+}
+
+/*
+ * Atomic compare and exchange.  Compare OLD with MEM, if identical,
+ * store NEW in MEM.  Return the initial value in MEM.  Success is
+ * indicated by comparing RETURN with OLD.
+ *
+ * The memory barrier should be placed in SMP only when we actually
+ * make the change. If we don't change anything (so if the returned
+ * prev is equal to old) then we aren't acquiring anything new and
+ * we don't need any memory barrier as far I can tell.
+ */
+
+static inline unsigned long
+____cmpxchg(_u8, volatile char *m, unsigned char old, unsigned char new)
+{
+       unsigned long prev, tmp, cmp, addr64;
+
+       __asm__ __volatile__(
+       "       andnot  %5,7,%4\n"
+       "       insbl   %1,%5,%1\n"
+       "1:     ldq_l   %2,0(%4)\n"
+       "       extbl   %2,%5,%0\n"
+       "       cmpeq   %0,%6,%3\n"
+       "       beq     %3,2f\n"
+       "       mskbl   %2,%5,%2\n"
+       "       or      %1,%2,%2\n"
+       "       stq_c   %2,0(%4)\n"
+       "       beq     %2,3f\n"
+               __ASM__MB
+       "2:\n"
+       ".subsection 2\n"
+       "3:     br      1b\n"
+       ".previous"
+       : "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
+       : "r" ((long)m), "Ir" (old), "1" (new) : "memory");
+
+       return prev;
+}
+
+static inline unsigned long
+____cmpxchg(_u16, volatile short *m, unsigned short old, unsigned short new)
+{
+       unsigned long prev, tmp, cmp, addr64;
+
+       __asm__ __volatile__(
+       "       andnot  %5,7,%4\n"
+       "       inswl   %1,%5,%1\n"
+       "1:     ldq_l   %2,0(%4)\n"
+       "       extwl   %2,%5,%0\n"
+       "       cmpeq   %0,%6,%3\n"
+       "       beq     %3,2f\n"
+       "       mskwl   %2,%5,%2\n"
+       "       or      %1,%2,%2\n"
+       "       stq_c   %2,0(%4)\n"
+       "       beq     %2,3f\n"
+               __ASM__MB
+       "2:\n"
+       ".subsection 2\n"
+       "3:     br      1b\n"
+       ".previous"
+       : "=&r" (prev), "=&r" (new), "=&r" (tmp), "=&r" (cmp), "=&r" (addr64)
+       : "r" ((long)m), "Ir" (old), "1" (new) : "memory");
+
+       return prev;
+}
+
+static inline unsigned long
+____cmpxchg(_u32, volatile int *m, int old, int new)
+{
+       unsigned long prev, cmp;
+
+       __asm__ __volatile__(
+       "1:     ldl_l %0,%5\n"
+       "       cmpeq %0,%3,%1\n"
+       "       beq %1,2f\n"
+       "       mov %4,%1\n"
+       "       stl_c %1,%2\n"
+       "       beq %1,3f\n"
+               __ASM__MB
+       "2:\n"
+       ".subsection 2\n"
+       "3:     br 1b\n"
+       ".previous"
+       : "=&r"(prev), "=&r"(cmp), "=m"(*m)
+       : "r"((long) old), "r"(new), "m"(*m) : "memory");
+
+       return prev;
+}
+
+static inline unsigned long
+____cmpxchg(_u64, volatile long *m, unsigned long old, unsigned long new)
+{
+       unsigned long prev, cmp;
+
+       __asm__ __volatile__(
+       "1:     ldq_l %0,%5\n"
+       "       cmpeq %0,%3,%1\n"
+       "       beq %1,2f\n"
+       "       mov %4,%1\n"
+       "       stq_c %1,%2\n"
+       "       beq %1,3f\n"
+               __ASM__MB
+       "2:\n"
+       ".subsection 2\n"
+       "3:     br 1b\n"
+       ".previous"
+       : "=&r"(prev), "=&r"(cmp), "=m"(*m)
+       : "r"((long) old), "r"(new), "m"(*m) : "memory");
+
+       return prev;
+}
+
+/* This function doesn't exist, so you'll get a linker error
+   if something tries to do an invalid cmpxchg().  */
+extern void __cmpxchg_called_with_bad_pointer(void);
+
+static __always_inline unsigned long
+____cmpxchg(, volatile void *ptr, unsigned long old, unsigned long new,
+             int size)
+{
+       switch (size) {
+               case 1:
+                       return ____cmpxchg(_u8, ptr, old, new);
+               case 2:
+                       return ____cmpxchg(_u16, ptr, old, new);
+               case 4:
+                       return ____cmpxchg(_u32, ptr, old, new);
+               case 8:
+                       return ____cmpxchg(_u64, ptr, old, new);
+       }
+       __cmpxchg_called_with_bad_pointer();
+       return old;
+}
+
+#endif
index b4697759a1235ad60ce5458fcd6b896fb4f24e1d..a427538252f878aa664520e5c3f6f6d7ee844513 100644 (file)
@@ -12,7 +12,7 @@ obj-y    := entry.o traps.o process.o init_task.o osf_sys.o irq.o \
 
 obj-$(CONFIG_VGA_HOSE) += console.o
 obj-$(CONFIG_SMP)      += smp.o
-obj-$(CONFIG_PCI)      += pci.o pci_iommu.o
+obj-$(CONFIG_PCI)      += pci.o pci_iommu.o pci-sysfs.o
 obj-$(CONFIG_SRM_ENV)  += srm_env.o
 obj-$(CONFIG_MODULES)  += module.o
 
index 11aee012a8aed0986b7e744c7a43a0f7ac275814..985e5c1681ace50d0ef11c1bfdf29c485bcfbdda 100644 (file)
@@ -157,8 +157,8 @@ ev6_parse_cbox(u64 c_addr, u64 c1_syn, u64 c2_syn,
                       err_print_prefix,
                       streamname[stream], bitsname[bits], sourcename[source]);
 
-       printk("%s    Address: 0x%016lx\n"
-                "    Syndrome[upper.lower]: %02lx.%02lx\n", 
+       printk("%s    Address: 0x%016llx\n"
+                "    Syndrome[upper.lower]: %02llx.%02llx\n",
               err_print_prefix,
               c_addr,
               c2_syn, c1_syn);
index 68cd493f54c5fd93b5fddec8eb2323a65e124924..73770c6ca01321457d0430133525d4668dcc97e0 100644 (file)
@@ -246,13 +246,13 @@ ev7_process_pal_subpacket(struct el_subpacket *header)
 
        switch(header->type) {
        case EL_TYPE__PAL__LOGOUT_FRAME:
-               printk("%s*** MCHK occurred on LPID %ld (RBOX %lx)\n",
+               printk("%s*** MCHK occurred on LPID %ld (RBOX %llx)\n",
                       err_print_prefix,
                       packet->by_type.logout.whami, 
                       packet->by_type.logout.rbox_whami);
                el_print_timestamp(&packet->by_type.logout.timestamp);
-               printk("%s  EXC_ADDR: %016lx\n"
-                        "  HALT_CODE: %lx\n", 
+               printk("%s  EXC_ADDR: %016llx\n"
+                        "  HALT_CODE: %llx\n",
                       err_print_prefix,
                       packet->by_type.logout.exc_addr,
                       packet->by_type.logout.halt_code);
index 413bf37eb094057b0e38e03b965764056cb11c5a..6bfd243efba342200a36a51b4be1033921c0b3c0 100644 (file)
@@ -129,7 +129,7 @@ marvel_print_po7_crrct_sym(u64 crrct_sym)
 
 
        printk("%s      Correctable Error Symptoms:\n"
-              "%s        Syndrome: 0x%lx\n",
+              "%s        Syndrome: 0x%llx\n",
               err_print_prefix,
               err_print_prefix, EXTRACT(crrct_sym, IO7__PO7_CRRCT_SYM__SYN));
        marvel_print_err_cyc(EXTRACT(crrct_sym, IO7__PO7_CRRCT_SYM__ERR_CYC));
@@ -186,7 +186,7 @@ marvel_print_po7_uncrr_sym(u64 uncrr_sym, u64 valid_mask)
        uncrr_sym &= valid_mask;
 
        if (EXTRACT(valid_mask, IO7__PO7_UNCRR_SYM__SYN))
-               printk("%s        Syndrome: 0x%lx\n",
+               printk("%s        Syndrome: 0x%llx\n",
                       err_print_prefix, 
                       EXTRACT(uncrr_sym, IO7__PO7_UNCRR_SYM__SYN));
 
@@ -307,7 +307,7 @@ marvel_print_po7_ugbge_sym(u64 ugbge_sym)
                sprintf(opcode_str, "BlkIO");
                break;
        default:
-               sprintf(opcode_str, "0x%lx\n", 
+               sprintf(opcode_str, "0x%llx\n",
                        EXTRACT(ugbge_sym, IO7__PO7_UGBGE_SYM__UPH_OPCODE));
                break;
        }
@@ -321,7 +321,7 @@ marvel_print_po7_ugbge_sym(u64 ugbge_sym)
               opcode_str);
 
        if (0xC5 != EXTRACT(ugbge_sym, IO7__PO7_UGBGE_SYM__UPH_OPCODE))
-               printk("%s        Packet Offset 0x%08lx\n",
+               printk("%s        Packet Offset 0x%08llx\n",
                       err_print_prefix,
                       EXTRACT(ugbge_sym, IO7__PO7_UGBGE_SYM__UPH_PKT_OFF));
 }
@@ -480,8 +480,8 @@ marvel_print_po7_err_sum(struct ev7_pal_io_subpacket *io)
                printk("%s    Lost Error\n", err_print_prefix);
 
        printk("%s    Failing Packet:\n"
-              "%s      Cycle 1: %016lx\n"
-              "%s      Cycle 2: %016lx\n",
+              "%s      Cycle 1: %016llx\n"
+              "%s      Cycle 2: %016llx\n",
               err_print_prefix,
               err_print_prefix, io->po7_err_pkt0,
               err_print_prefix, io->po7_err_pkt1);
@@ -515,9 +515,9 @@ marvel_print_pox_tlb_err(u64 tlb_err)
        if (!(tlb_err & IO7__POX_TLBERR__ERR_VALID))
                return;
 
-       printk("%s      TLB Error on index 0x%lx:\n"
+       printk("%s      TLB Error on index 0x%llx:\n"
               "%s        - %s\n"
-              "%s        - Addr: 0x%016lx\n",
+              "%s        - Addr: 0x%016llx\n",
               err_print_prefix,
               EXTRACT(tlb_err, IO7__POX_TLBERR__ERR_TLB_PTR),
               err_print_prefix,
@@ -579,7 +579,7 @@ marvel_print_pox_spl_cmplt(u64 spl_cmplt)
                sprintf(message, "Uncorrectable Split Write Data Error");
                break;
        default:
-               sprintf(message, "%08lx\n", 
+               sprintf(message, "%08llx\n",
                        EXTRACT(spl_cmplt, IO7__POX_SPLCMPLT__MESSAGE));
                break;
        }
@@ -620,9 +620,9 @@ marvel_print_pox_trans_sum(u64 trans_sum)
                return;
 
        printk("%s      Transaction Summary:\n"
-              "%s        Command: 0x%lx - %s\n"
-              "%s        Address: 0x%016lx%s\n"
-              "%s        PCI-X Master Slot: 0x%lx\n",
+              "%s        Command: 0x%llx - %s\n"
+              "%s        Address: 0x%016llx%s\n"
+              "%s        PCI-X Master Slot: 0x%llx\n",
               err_print_prefix, 
               err_print_prefix, 
               EXTRACT(trans_sum, IO7__POX_TRANSUM__PCIX_CMD),
@@ -964,12 +964,12 @@ marvel_process_io_error(struct ev7_lf_subpackets *lf_subpackets, int print)
 
 #if 0
                printk("%s  PORT 7 ERROR:\n"
-                      "%s    PO7_ERROR_SUM: %016lx\n"
-                      "%s    PO7_UNCRR_SYM: %016lx\n"
-                      "%s    PO7_CRRCT_SYM: %016lx\n"
-                      "%s    PO7_UGBGE_SYM: %016lx\n"
-                      "%s    PO7_ERR_PKT0:  %016lx\n"
-                      "%s    PO7_ERR_PKT1:  %016lx\n",
+                      "%s    PO7_ERROR_SUM: %016llx\n"
+                      "%s    PO7_UNCRR_SYM: %016llx\n"
+                      "%s    PO7_CRRCT_SYM: %016llx\n"
+                      "%s    PO7_UGBGE_SYM: %016llx\n"
+                      "%s    PO7_ERR_PKT0:  %016llx\n"
+                      "%s    PO7_ERR_PKT1:  %016llx\n",
                       err_print_prefix,
                       err_print_prefix, io->po7_error_sum,
                       err_print_prefix, io->po7_uncrr_sym,
@@ -987,12 +987,12 @@ marvel_process_io_error(struct ev7_lf_subpackets *lf_subpackets, int print)
                if (!MARVEL_IO_ERR_VALID(io->ports[i].pox_err_sum))
                        continue;
 
-               printk("%s  PID %u PORT %d POx_ERR_SUM: %016lx\n", 
+               printk("%s  PID %u PORT %d POx_ERR_SUM: %016llx\n",
                       err_print_prefix, 
                       lf_subpackets->io_pid, i, io->ports[i].pox_err_sum);
                marvel_print_pox_err(io->ports[i].pox_err_sum, &io->ports[i]);
 
-               printk("%s  [ POx_FIRST_ERR: %016lx ]\n", 
+               printk("%s  [ POx_FIRST_ERR: %016llx ]\n",
                       err_print_prefix, io->ports[i].pox_first_err);
                marvel_print_pox_err(io->ports[i].pox_first_err, 
                                     &io->ports[i]);
index 257449ed15efca1ac97d46e999acb0e223e62408..c7e28a88d6e31b2869ab45488d7e5f9092127ffb 100644 (file)
@@ -107,12 +107,12 @@ titan_parse_p_serror(int which, u64 serror, int print)
        if (!print)
                return status;
 
-       printk("%s  PChip %d SERROR: %016lx\n", 
+       printk("%s  PChip %d SERROR: %016llx\n",
               err_print_prefix, which, serror);
        if (serror & TITAN__PCHIP_SERROR__ECCMASK) {
                printk("%s    %sorrectable ECC Error:\n"
                       "      Source: %-6s  Command: %-8s  Syndrome: 0x%08x\n"
-                      "      Address: 0x%lx\n", 
+                      "      Address: 0x%llx\n",
                       err_print_prefix,
                       (serror & TITAN__PCHIP_SERROR__UECC) ? "Unc" : "C",
                       serror_src[EXTRACT(serror, TITAN__PCHIP_SERROR__SRC)],
@@ -223,7 +223,7 @@ titan_parse_p_perror(int which, int port, u64 perror, int print)
        if (!print) 
                return status;
 
-       printk("%s  PChip %d %cPERROR: %016lx\n", 
+       printk("%s  PChip %d %cPERROR: %016llx\n",
               err_print_prefix, which, 
               port ? 'A' : 'G', perror);
        if (perror & TITAN__PCHIP_PERROR__IPTPW)
@@ -316,7 +316,7 @@ titan_parse_p_agperror(int which, u64 agperror, int print)
        addr = EXTRACT(agperror, TITAN__PCHIP_AGPERROR__ADDR) << 3;
        len = EXTRACT(agperror, TITAN__PCHIP_AGPERROR__LEN);
 
-       printk("%s  PChip %d AGPERROR: %016lx\n", err_print_prefix,
+       printk("%s  PChip %d AGPERROR: %016llx\n", err_print_prefix,
               which, agperror);
        if (agperror & TITAN__PCHIP_AGPERROR__NOWINDOW)
                printk("%s    No Window\n", err_print_prefix);
@@ -597,16 +597,16 @@ privateer_process_680_frame(struct el_common *mchk_header, int print)
                return status;
 
        /* TODO - decode instead of just dumping... */
-       printk("%s  Summary Flags:         %016lx\n"
-                "  CChip DIRx:            %016lx\n"
-                "  System Management IR:  %016lx\n"
-                "  CPU IR:                %016lx\n"
-                "  Power Supply IR:       %016lx\n"
-                "  LM78 Fault Status:     %016lx\n"
-                "  System Doors:          %016lx\n"
-                "  Temperature Warning:   %016lx\n"
-                "  Fan Control:           %016lx\n"
-                "  Fatal Power Down Code: %016lx\n",
+       printk("%s  Summary Flags:         %016llx\n"
+                "  CChip DIRx:            %016llx\n"
+                "  System Management IR:  %016llx\n"
+                "  CPU IR:                %016llx\n"
+                "  Power Supply IR:       %016llx\n"
+                "  LM78 Fault Status:     %016llx\n"
+                "  System Doors:          %016llx\n"
+                "  Temperature Warning:   %016llx\n"
+                "  Fan Control:           %016llx\n"
+                "  Fatal Power Down Code: %016llx\n",
               err_print_prefix,
               emchk->summary,
               emchk->c_dirx,
diff --git a/arch/alpha/kernel/pci-sysfs.c b/arch/alpha/kernel/pci-sysfs.c
new file mode 100644 (file)
index 0000000..6ea822e
--- /dev/null
@@ -0,0 +1,366 @@
+/*
+ * arch/alpha/kernel/pci-sysfs.c
+ *
+ * Copyright (C) 2009 Ivan Kokshaysky
+ *
+ * Alpha PCI resource files.
+ *
+ * Loosely based on generic HAVE_PCI_MMAP implementation in
+ * drivers/pci/pci-sysfs.c
+ */
+
+#include <linux/sched.h>
+#include <linux/pci.h>
+
+static int hose_mmap_page_range(struct pci_controller *hose,
+                               struct vm_area_struct *vma,
+                               enum pci_mmap_state mmap_type, int sparse)
+{
+       unsigned long base;
+
+       if (mmap_type == pci_mmap_mem)
+               base = sparse ? hose->sparse_mem_base : hose->dense_mem_base;
+       else
+               base = sparse ? hose->sparse_io_base : hose->dense_io_base;
+
+       vma->vm_pgoff += base >> PAGE_SHIFT;
+       vma->vm_flags |= (VM_IO | VM_RESERVED);
+
+       return io_remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
+                                 vma->vm_end - vma->vm_start,
+                                 vma->vm_page_prot);
+}
+
+static int __pci_mmap_fits(struct pci_dev *pdev, int num,
+                          struct vm_area_struct *vma, int sparse)
+{
+       unsigned long nr, start, size;
+       int shift = sparse ? 5 : 0;
+
+       nr = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+       start = vma->vm_pgoff;
+       size = ((pci_resource_len(pdev, num) - 1) >> (PAGE_SHIFT - shift)) + 1;
+
+       if (start < size && size - start >= nr)
+               return 1;
+       WARN(1, "process \"%s\" tried to map%s 0x%08lx-0x%08lx on %s BAR %d "
+               "(size 0x%08lx)\n",
+               current->comm, sparse ? " sparse" : "", start, start + nr,
+               pci_name(pdev), num, size);
+       return 0;
+}
+
+/**
+ * pci_mmap_resource - map a PCI resource into user memory space
+ * @kobj: kobject for mapping
+ * @attr: struct bin_attribute for the file being mapped
+ * @vma: struct vm_area_struct passed into the mmap
+ * @sparse: address space type
+ *
+ * Use the bus mapping routines to map a PCI resource into userspace.
+ */
+static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr,
+                            struct vm_area_struct *vma, int sparse)
+{
+       struct pci_dev *pdev = to_pci_dev(container_of(kobj,
+                                                      struct device, kobj));
+       struct resource *res = (struct resource *)attr->private;
+       enum pci_mmap_state mmap_type;
+       struct pci_bus_region bar;
+       int i;
+
+       for (i = 0; i < PCI_ROM_RESOURCE; i++)
+               if (res == &pdev->resource[i])
+                       break;
+       if (i >= PCI_ROM_RESOURCE)
+               return -ENODEV;
+
+       if (!__pci_mmap_fits(pdev, i, vma, sparse))
+               return -EINVAL;
+
+       if (iomem_is_exclusive(res->start))
+               return -EINVAL;
+
+       pcibios_resource_to_bus(pdev, &bar, res);
+       vma->vm_pgoff += bar.start >> (PAGE_SHIFT - (sparse ? 5 : 0));
+       mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
+
+       return hose_mmap_page_range(pdev->sysdata, vma, mmap_type, sparse);
+}
+
+static int pci_mmap_resource_sparse(struct kobject *kobj,
+                                   struct bin_attribute *attr,
+                                   struct vm_area_struct *vma)
+{
+       return pci_mmap_resource(kobj, attr, vma, 1);
+}
+
+static int pci_mmap_resource_dense(struct kobject *kobj,
+                                  struct bin_attribute *attr,
+                                  struct vm_area_struct *vma)
+{
+       return pci_mmap_resource(kobj, attr, vma, 0);
+}
+
+/**
+ * pci_remove_resource_files - cleanup resource files
+ * @dev: dev to cleanup
+ *
+ * If we created resource files for @dev, remove them from sysfs and
+ * free their resources.
+ */
+void pci_remove_resource_files(struct pci_dev *pdev)
+{
+       int i;
+
+       for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+               struct bin_attribute *res_attr;
+
+               res_attr = pdev->res_attr[i];
+               if (res_attr) {
+                       sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
+                       kfree(res_attr);
+               }
+
+               res_attr = pdev->res_attr_wc[i];
+               if (res_attr) {
+                       sysfs_remove_bin_file(&pdev->dev.kobj, res_attr);
+                       kfree(res_attr);
+               }
+       }
+}
+
+static int sparse_mem_mmap_fits(struct pci_dev *pdev, int num)
+{
+       struct pci_bus_region bar;
+       struct pci_controller *hose = pdev->sysdata;
+       long dense_offset;
+       unsigned long sparse_size;
+
+       pcibios_resource_to_bus(pdev, &bar, &pdev->resource[num]);
+
+       /* All core logic chips have 4G sparse address space, except
+          CIA which has 16G (see xxx_SPARSE_MEM and xxx_DENSE_MEM
+          definitions in asm/core_xxx.h files). This corresponds
+          to 128M or 512M of the bus space. */
+       dense_offset = (long)(hose->dense_mem_base - hose->sparse_mem_base);
+       sparse_size = dense_offset >= 0x400000000UL ? 0x20000000 : 0x8000000;
+
+       return bar.end < sparse_size;
+}
+
+static int pci_create_one_attr(struct pci_dev *pdev, int num, char *name,
+                              char *suffix, struct bin_attribute *res_attr,
+                              unsigned long sparse)
+{
+       size_t size = pci_resource_len(pdev, num);
+
+       sprintf(name, "resource%d%s", num, suffix);
+       res_attr->mmap = sparse ? pci_mmap_resource_sparse :
+                                 pci_mmap_resource_dense;
+       res_attr->attr.name = name;
+       res_attr->attr.mode = S_IRUSR | S_IWUSR;
+       res_attr->size = sparse ? size << 5 : size;
+       res_attr->private = &pdev->resource[num];
+       return sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
+}
+
+static int pci_create_attr(struct pci_dev *pdev, int num)
+{
+       /* allocate attribute structure, piggyback attribute name */
+       int retval, nlen1, nlen2 = 0, res_count = 1;
+       unsigned long sparse_base, dense_base;
+       struct bin_attribute *attr;
+       struct pci_controller *hose = pdev->sysdata;
+       char *suffix, *attr_name;
+
+       suffix = "";    /* Assume bwx machine, normal resourceN files. */
+       nlen1 = 10;
+
+       if (pdev->resource[num].flags & IORESOURCE_MEM) {
+               sparse_base = hose->sparse_mem_base;
+               dense_base = hose->dense_mem_base;
+               if (sparse_base && !sparse_mem_mmap_fits(pdev, num)) {
+                       sparse_base = 0;
+                       suffix = "_dense";
+                       nlen1 = 16;     /* resourceN_dense */
+               }
+       } else {
+               sparse_base = hose->sparse_io_base;
+               dense_base = hose->dense_io_base;
+       }
+
+       if (sparse_base) {
+               suffix = "_sparse";
+               nlen1 = 17;
+               if (dense_base) {
+                       nlen2 = 16;     /* resourceN_dense */
+                       res_count = 2;
+               }
+       }
+
+       attr = kzalloc(sizeof(*attr) * res_count + nlen1 + nlen2, GFP_ATOMIC);
+       if (!attr)
+               return -ENOMEM;
+
+       /* Create bwx, sparse or single dense file */
+       attr_name = (char *)(attr + res_count);
+       pdev->res_attr[num] = attr;
+       retval = pci_create_one_attr(pdev, num, attr_name, suffix, attr,
+                                    sparse_base);
+       if (retval || res_count == 1)
+               return retval;
+
+       /* Create dense file */
+       attr_name += nlen1;
+       attr++;
+       pdev->res_attr_wc[num] = attr;
+       return pci_create_one_attr(pdev, num, attr_name, "_dense", attr, 0);
+}
+
+/**
+ * pci_create_resource_files - create resource files in sysfs for @dev
+ * @dev: dev in question
+ *
+ * Walk the resources in @dev creating files for each resource available.
+ */
+int pci_create_resource_files(struct pci_dev *pdev)
+{
+       int i;
+       int retval;
+
+       /* Expose the PCI resources from this device as files */
+       for (i = 0; i < PCI_ROM_RESOURCE; i++) {
+
+               /* skip empty resources */
+               if (!pci_resource_len(pdev, i))
+                       continue;
+
+               retval = pci_create_attr(pdev, i);
+               if (retval) {
+                       pci_remove_resource_files(pdev);
+                       return retval;
+               }
+       }
+       return 0;
+}
+
+/* Legacy I/O bus mapping stuff. */
+
+static int __legacy_mmap_fits(struct pci_controller *hose,
+                             struct vm_area_struct *vma,
+                             unsigned long res_size, int sparse)
+{
+       unsigned long nr, start, size;
+
+       nr = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+       start = vma->vm_pgoff;
+       size = ((res_size - 1) >> PAGE_SHIFT) + 1;
+
+       if (start < size && size - start >= nr)
+               return 1;
+       WARN(1, "process \"%s\" tried to map%s 0x%08lx-0x%08lx on hose %d "
+               "(size 0x%08lx)\n",
+               current->comm, sparse ? " sparse" : "", start, start + nr,
+               hose->index, size);
+       return 0;
+}
+
+static inline int has_sparse(struct pci_controller *hose,
+                            enum pci_mmap_state mmap_type)
+{
+       unsigned long base;
+
+       base = (mmap_type == pci_mmap_mem) ? hose->sparse_mem_base :
+                                            hose->sparse_io_base;
+
+       return base != 0;
+}
+
+int pci_mmap_legacy_page_range(struct pci_bus *bus, struct vm_area_struct *vma,
+                              enum pci_mmap_state mmap_type)
+{
+       struct pci_controller *hose = bus->sysdata;
+       int sparse = has_sparse(hose, mmap_type);
+       unsigned long res_size;
+
+       res_size = (mmap_type == pci_mmap_mem) ? bus->legacy_mem->size :
+                                                bus->legacy_io->size;
+       if (!__legacy_mmap_fits(hose, vma, res_size, sparse))
+               return -EINVAL;
+
+       return hose_mmap_page_range(hose, vma, mmap_type, sparse);
+}
+
+/**
+ * pci_adjust_legacy_attr - adjustment of legacy file attributes
+ * @b: bus to create files under
+ * @mmap_type: I/O port or memory
+ *
+ * Adjust file name and size for sparse mappings.
+ */
+void pci_adjust_legacy_attr(struct pci_bus *bus, enum pci_mmap_state mmap_type)
+{
+       struct pci_controller *hose = bus->sysdata;
+
+       if (!has_sparse(hose, mmap_type))
+               return;
+
+       if (mmap_type == pci_mmap_mem) {
+               bus->legacy_mem->attr.name = "legacy_mem_sparse";
+               bus->legacy_mem->size <<= 5;
+       } else {
+               bus->legacy_io->attr.name = "legacy_io_sparse";
+               bus->legacy_io->size <<= 5;
+       }
+       return;
+}
+
+/* Legacy I/O bus read/write functions */
+int pci_legacy_read(struct pci_bus *bus, loff_t port, u32 *val, size_t size)
+{
+       struct pci_controller *hose = bus->sysdata;
+
+       port += hose->io_space->start;
+
+       switch(size) {
+       case 1:
+               *((u8 *)val) = inb(port);
+               return 1;
+       case 2:
+               if (port & 1)
+                       return -EINVAL;
+               *((u16 *)val) = inw(port);
+               return 2;
+       case 4:
+               if (port & 3)
+                       return -EINVAL;
+               *((u32 *)val) = inl(port);
+               return 4;
+       }
+       return -EINVAL;
+}
+
+int pci_legacy_write(struct pci_bus *bus, loff_t port, u32 val, size_t size)
+{
+       struct pci_controller *hose = bus->sysdata;
+
+       port += hose->io_space->start;
+
+       switch(size) {
+       case 1:
+               outb(port, val);
+               return 1;
+       case 2:
+               if (port & 1)
+                       return -EINVAL;
+               outw(port, val);
+               return 2;
+       case 4:
+               if (port & 3)
+                       return -EINVAL;
+               outl(port, val);
+               return 4;
+       }
+       return -EINVAL;
+}
index a3b938811400f70c82ec960082f6bdeaab935e0f..a91ba28999b57a03d34036f105fd1070fa8fe2d3 100644 (file)
@@ -168,7 +168,7 @@ pcibios_align_resource(void *data, struct resource *res,
                 */
 
                /* Align to multiple of size of minimum base.  */
-               alignto = max(0x1000UL, align);
+               alignto = max_t(resource_size_t, 0x1000, align);
                start = ALIGN(start, alignto);
                if (hose->sparse_mem_base && size <= 7 * 16*MB) {
                        if (((start / (16*MB)) & 0x7) == 0) {
index b9094da05d7a136a5dff6bf7a6a0751e25af5316..bfb880af959d4d39c4ed335cc4afb3326fcc989a 100644 (file)
@@ -247,7 +247,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
            && paddr + size <= __direct_map_size) {
                ret = paddr + __direct_map_base;
 
-               DBGA2("pci_map_single: [%p,%lx] -> direct %lx from %p\n",
+               DBGA2("pci_map_single: [%p,%zx] -> direct %llx from %p\n",
                      cpu_addr, size, ret, __builtin_return_address(0));
 
                return ret;
@@ -258,7 +258,7 @@ pci_map_single_1(struct pci_dev *pdev, void *cpu_addr, size_t size,
        if (dac_allowed) {
                ret = paddr + alpha_mv.pci_dac_offset;
 
-               DBGA2("pci_map_single: [%p,%lx] -> DAC %lx from %p\n",
+               DBGA2("pci_map_single: [%p,%zx] -> DAC %llx from %p\n",
                      cpu_addr, size, ret, __builtin_return_address(0));
 
                return ret;
@@ -299,7