1. 24 6月, 2005 1 次提交
  2. 22 6月, 2005 2 次提交
    • B
      [PATCH] ioc4: CONFIG split · e5d310b3
      Brent Casavant 提交于
      The SGI IOC4 I/O controller chip drivers are currently all configured by
      CONFIG_BLK_DEV_SGIIOC4.  This is undesirable as not all IOC4 hardware features
      are needed by all systems.
      
      This patch adds two configuration variables, CONFIG_SGI_IOC4 for core IOC4
      driver support (see patch 1/3 in this series for further explanation) and
      CONFIG_SERIAL_SGI_IOC4 to independently enable serial port support.
      Signed-off-by: NBrent Casavant <bcasavan@sgi.com>
      Acked-by: NPat Gefre <pfg@sgi.com>
      Acked-by: NJeremy Higdon <jeremy@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e5d310b3
    • B
      [PATCH] ioc4: Core driver rewrite · 22329b51
      Brent Casavant 提交于
      This series of patches reworks the configuration and internal structure
      of the SGI IOC4 I/O controller device drivers.
      
      These changes are motivated by several factors:
      
      - The IOC4 chip PCI resources are of mixed use between functions (i.e.
        multiple functions are handled in the same address range, sometimes
        within the same register), muddling resource ownership and initialization
        issues.  Centralizing this ownership in a core driver is desirable.
      
      - The IOC4 chip implements multiple functions (serial, IDE, others not
        yet implemented in the mainline kernel) but is not a multifunction
        PCI device.  In order to properly handle device addition and removal
        as well as module insertion and deletion, an intermediary IOC4-specific
        driver layer is needed to handle these operations cleanly.
      
      - All IOC4 drivers are currently enabled by a single CONFIG value.  As
        not all systems need all IOC4 functions, it is desireable to enable
        these drivers independently.
      
      - The current IOC4 core driver will trigger loading of all function-level
        drivers, as it makes direct calls to them.  This situation should be
        reversed (i.e. function-level drivers cause loading of core driver)
        in order to maintain a clear and least-surprise driver loading model.
      
      - IOC4 hardware design necessitates some driver-level dependency on
        the PCI bus clock speed.  Current code assumes a 66MHz bus, but the
        speed should be autodetected and appropriate compensation taken.
      
      This patch series effects the above changes by a newly and better designed
      IOC4 core driver with which the function-level drivers can register and
      deregister themselves upon module insertion/removal.  By tracking these
      modules, device addition/removal is also handled properly.  PCI resource
      management and ownership issues are centralized in this core driver, and
      IOC4-wide configuration actions such as bus speed detection are also
      handled in this core driver.
      
      This patch:
      
      The SGI IOC4 I/O controller chip implements multiple functions, though it is
      not a multi-function PCI device.  Additionally, various PCI resources of the
      IOC4 are shared by multiple hardware functions, and thus resource ownership by
      driver is not clearly delineated.  Due to the current driver design, all core
      and subordinate drivers must be loaded, or none, which is undesirable if not
      all IOC4 hardware features are being used.
      
      This patch reorganizes the IOC4 drivers so that the core driver provides a
      subdriver registration service.  Through appropriate callbacks the subdrivers
      can now handle device addition and removal, as well as module insertion and
      deletion (though the IOC4 IDE driver requires further work before module
      deletion will work).  The core driver now takes care of allocating PCI
      resources and data which must be shared between subdrivers, to clearly
      delineate module ownership of these items.
      Signed-off-by: NBrent Casavant <bcasavan@sgi.com>
      Acked-by: Pat Gefre <pfg@sgi.com
      Acked-by: NJeremy Higdon <jeremy@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      22329b51
  3. 01 6月, 2005 2 次提交
  4. 27 5月, 2005 1 次提交
  5. 26 5月, 2005 3 次提交
    • M
      [PATCH] timeout at boottime with NEC3500A (and possibly others) when inserted a CD in it · 284e4238
      Marcello Maggioni 提交于
      From: Marcello Maggioni <hayarms@gmail.com>
      
      Problem: Some drives (NEC 3500, TDK 1616N, Mad-dog MD-16XDVD9, RICOH
      MP5163DA, Memorex DVD9 drive and IO-DATA's too for sure), if a
      CD/DVD is inserted into the tray when the system is booted and if
      before the OS bootup the BIOS checked for the presence of a bootable
      CD/DVD into the drive, during the IDE probe phase the drive may
      result busy and remain so for the next 25/30 seconds . This cause the
      drive to be skipped during the booting phase and not begin usable
      until the next reboot (if the reboot goes well and the drive doesn't
      timeout again).
      
      Solution: Rising the timeout time from 10 seconds to 35 seconds
      (during these 35 seconds every drive should wake up for sure
      according to the tests I've done).
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
      284e4238
    • B
      [PATCH] convert IDE device drivers to driver-model · 8604affd
      Bartlomiej Zolnierkiewicz 提交于
      * add ide_bus_match() and export ide_bus_type
      * split ide_remove_driver_from_hwgroup() out of ide_unregister()
      * move device cleanup from ide_unregister() to drive_release_dev()
      * convert ide_driver_t->name to driver->name
      * convert ide_driver_t->{attach,cleanup} to driver->{probe,remove}
      * remove ide_driver_t->busy as ide_bus_type->subsys.rwsem
        protects against concurrent ->{probe,remove} calls
      * make ide_{un}register_driver() void as it cannot fail now
      * use driver_{un}register() directly, remove ide_{un}register_driver()
      * use device_register() instead of ata_attach(), remove ata_attach()
      * add proc_print_driver() and ide_drivers_show(), remove ide_drivers_op
      * fix ide_replace_subdriver() and move it to ide-proc.c
      * remove ide_driver_t->drives, ide_drives and drives_lock
      * remove ide_driver_t->drivers, drivers and drivers_lock
      * remove ide_drive_t->driver and DRIVER() macro
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@elka.pw.edu.pl>
      8604affd
    • J
      [PATCH] relax ide-cd dma restrictions · 384f1fcd
      Jens Axboe 提交于
      This has been sitting for a while, and is causing lots of grief for
      people burning CDs.  It relaxes the dma restriction for ide-cd,
      requiring only the length to be 32-byte aligned, address should be fine
      at normal double word alignment.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      384f1fcd
  6. 17 5月, 2005 1 次提交
    • Z
      [PATCH] ide proc destroy error · 643bdc6f
      Zhang, Yanmin 提交于
      Kernel 2.6 has an ide proc destroy error. Run #modprobe ide-core and
      #rmmod ide-core, then kernel will dump stack information like below.
      
      **********Log******************
      Badness in remove_proc_entry at fs/proc/generic.c:693
      
      Call Trace:
       [<a0000001000117e0>] show_stack+0x80/0xa0
                                      sp=3De0000003e05dfbe0 =
      bsp=3De0000003e05d0ea8
       [<a0000001000120b0>] dump_stack+0x30/0x60
                                      sp=3De0000003e05dfdb0 =
      bsp=3De0000003e05d0e90
       [<a000000100183090>] remove_proc_entry+0x530/0x540
                                      sp=3De0000003e05dfdb0 =
      bsp=3De0000003e05d0e20
       [<a000000221cbd280>] proc_ide_destroy+0x120/0x140 [ide_core]
                                      sp=3De0000003e05dfdc0 =
      bsp=3De0000003e05d0df0
       [<a000000221ca65f0>] cleanup_module+0x50/0xa0 [ide_core]
                                      sp=3De0000003e05dfdc0 =
      bsp=3De0000003e05d0dd0
       [<a0000001000a9e10>] sys_delete_module+0x390/0x580
                                      sp=3De0000003e05dfdc0 =
      bsp=3De0000003e05d0d50
       [<a00000010000af40>] ia64_ret_from_syscall+0x0/0x20
                                      sp=3De0000003e05dfe30 =
      bsp=3De0000003e05d0d50
       [<a000000000010640>] _stext+0xffffffff00010640/0x400
                                      sp=3De0000003e05e0000 =
      bsp=3De0000003e05d0d50
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Cc: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      643bdc6f
  7. 06 5月, 2005 1 次提交
  8. 01 5月, 2005 1 次提交
  9. 17 4月, 2005 4 次提交