1. 17 7月, 2008 1 次提交
  2. 12 6月, 2008 1 次提交
  3. 21 4月, 2008 1 次提交
    • I
      PCI: clean up resource alignment management · 88452565
      Ivan Kokshaysky 提交于
      Done per Linus' request and suggestions. Linus has explained that
      better than I'll be able to explain:
      
      On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
      > Actually, before we go any further, there might be a less intrusive
      > alternative: add just a couple of flags to the resource flags field (we
      > still have something like 8 unused bits on 32-bit), and use those to
      > implement a generic "resource_alignment()" routine.
      >
      > Two flags would do it:
      >
      >  - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
      >    resources)
      >
      >  - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
      >    during probing)
      >
      > and then the case of both flags zero (or both bits set) would actually be
      > "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
      > actually allocate the resource (so that we don't use the "start" field as
      > alignment incorrectly when it no longer indicates alignment).
      >
      > That wouldn't be totally generic, but it would have the nice property of
      > automatically at least add sanity checking for that whole "res->start has
      > the odd meaning of 'alignment' during probing" and remove the need for a
      > new field, and it would allow us to have a generic "resource_alignment()"
      > routine that just gets a resource pointer.
      
      Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
      Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Gary Hade <garyhade@us.ibm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      88452565
  4. 30 1月, 2008 1 次提交
  5. 17 10月, 2007 1 次提交
  6. 29 4月, 2007 1 次提交
    • J
      libata/IDE: remove combined mode quirk · 8cdfb29c
      Jeff Garzik 提交于
      Both old-IDE and libata should be able handle all controllers and
      devices found using normal resource reservation methods.
      
      This eliminates the awful, low-performing split-driver configuration
      where old-IDE drove the PATA portion of a PCI device, in PIO-only mode,
      and libata drove the SATA portion of the /same/ PCI device, in DMA mode.
      Typically vendors would ship SATA hard drive / PATA optical
      configuration, which would lend itself to slow (PIO-only) CD-ROM
      performance.
      
      For Intel users running in combined mode, it is now wholly dependent on
      your driver choice (potentially link order, if you compile both drivers
      in) whether old-IDE or libata will drive your hardware.
      
      In either case, you will get full performance from both SATA and PATA
      ports now, without having to pass a kernel command line parameter.
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      8cdfb29c
  7. 10 2月, 2007 1 次提交
    • T
      devres: device resource management · 9ac7849e
      Tejun Heo 提交于
      Implement device resource management, in short, devres.  A device
      driver can allocate arbirary size of devres data which is associated
      with a release function.  On driver detach, release function is
      invoked on the devres data, then, devres data is freed.
      
      devreses are typed by associated release functions.  Some devreses are
      better represented by single instance of the type while others need
      multiple instances sharing the same release function.  Both usages are
      supported.
      
      devreses can be grouped using devres group such that a device driver
      can easily release acquired resources halfway through initialization
      or selectively release resources (e.g. resources for port 1 out of 4
      ports).
      
      This patch adds devres core including documentation and the following
      managed interfaces.
      
      * alloc/free	: devm_kzalloc(), devm_kzfree()
      * IO region	: devm_request_region(), devm_release_region()
      * IRQ		: devm_request_irq(), devm_free_irq()
      * DMA		: dmam_alloc_coherent(), dmam_free_coherent(),
      		  dmam_declare_coherent_memory(), dmam_pool_create(),
      		  dmam_pool_destroy()
      * PCI		: pcim_enable_device(), pcim_pin_device(), pci_is_managed()
      * iomap		: devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
      		  devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
      		  pcim_iomap(), pcim_iounmap()
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      9ac7849e
  8. 21 12月, 2006 1 次提交
    • R
      PCI legacy resource fix · fb0f2b40
      Ralf Baechle 提交于
      Since commit 368c73d4 the kernel will try
      to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if
      pci_assign_unassigned_resources() is used to do full resource assignment of
      the bus.  This fails because in the PIIX4 these BAR registers have
      implicitly assumed values and read back as zero; it used to work because
      the kernel used to just write zero to that register the read back value did
      match what was written.
      
      The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a resource
      as non-movable.  This will also be useful to keep other import system
      resources from being moved around - for example system consoles on PCI
      busses.
      
      [akpm@osdl.org: cleanup]
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fb0f2b40
  9. 02 12月, 2006 1 次提交
  10. 13 7月, 2006 1 次提交
  11. 04 7月, 2006 1 次提交
  12. 28 6月, 2006 3 次提交
  13. 07 11月, 2005 1 次提交
  14. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4