diff options
Diffstat (limited to 'drivers/ieee1394')
| -rw-r--r-- | drivers/ieee1394/Kconfig | 118 | ||||
| -rw-r--r-- | drivers/ieee1394/sbp2.c | 20 |
2 files changed, 74 insertions, 64 deletions
diff --git a/drivers/ieee1394/Kconfig b/drivers/ieee1394/Kconfig index 545663ef820..95f45f9b8e5 100644 --- a/drivers/ieee1394/Kconfig +++ b/drivers/ieee1394/Kconfig @@ -4,7 +4,7 @@ menu "IEEE 1394 (FireWire) support" source "drivers/firewire/Kconfig" config IEEE1394 - tristate "IEEE 1394 (FireWire) support" + tristate "Stable FireWire stack" depends on PCI || BROKEN help IEEE 1394 describes a high performance serial bus, which is also @@ -19,30 +19,45 @@ config IEEE1394 To compile this driver as a module, say M here: the module will be called ieee1394. -comment "Subsystem Options" - depends on IEEE1394 - -config IEEE1394_VERBOSEDEBUG - bool "Excessive debugging output" - depends on IEEE1394 +config IEEE1394_OHCI1394 + tristate "OHCI-1394 controllers" + depends on PCI && IEEE1394 help - If you say Y here, you will get very verbose debugging logs from - the subsystem which includes a dump of the header of every sent - and received packet. This can amount to a high amount of data - collected in a very short time which is usually also saved to - disk by the system logging daemons. + Enable this driver if you have an IEEE 1394 controller based on the + OHCI-1394 specification. The current driver is only tested with OHCI + chipsets made by Texas Instruments and NEC. Most third-party vendors + use one of these chipsets. It should work with any OHCI-1394 + compliant card, however. - Say Y if you really want or need the debugging output, everyone - else says N. + To compile this driver as a module, say M here: the + module will be called ohci1394. -comment "Controllers" - depends on IEEE1394 + NOTE: -comment "Texas Instruments PCILynx requires I2C" + You should only build either ohci1394 or the new firewire-ohci driver, + but not both. If you nevertheless want to install both, you should + configure them only as modules and blacklist the driver(s) which you + don't want to have auto-loaded. Add either + + blacklist firewire-ohci + or + blacklist ohci1394 + blacklist video1394 + blacklist dv1394 + + to /etc/modprobe.conf or /etc/modprobe.d/* and update modprobe.conf + depending on your distribution. The latter two modules should be + blacklisted together with ohci1394 because they depend on ohci1394. + + If you have an old modprobe which doesn't implement the blacklist + directive, use "install modulename /bin/true" for the modules to be + blacklisted. + +comment "PCILynx controller requires I2C" depends on IEEE1394 && I2C=n config IEEE1394_PCILYNX - tristate "Texas Instruments PCILynx support" + tristate "PCILynx controller" depends on PCI && IEEE1394 && I2C select I2C_ALGOBIT help @@ -57,35 +72,11 @@ config IEEE1394_PCILYNX PowerMacs G3 B&W contain the PCILynx controller. Therefore almost everybody can say N here. -config IEEE1394_OHCI1394 - tristate "OHCI-1394 support" - depends on PCI && IEEE1394 - help - Enable this driver if you have an IEEE 1394 controller based on the - OHCI-1394 specification. The current driver is only tested with OHCI - chipsets made by Texas Instruments and NEC. Most third-party vendors - use one of these chipsets. It should work with any OHCI-1394 - compliant card, however. - - To compile this driver as a module, say M here: the - module will be called ohci1394. - -comment "Protocols" - depends on IEEE1394 - -config IEEE1394_VIDEO1394 - tristate "OHCI-1394 Video support" - depends on IEEE1394 && IEEE1394_OHCI1394 - help - This option enables video device usage for OHCI-1394 cards. Enable - this option only if you have an IEEE 1394 video device connected to - an OHCI-1394 card. - comment "SBP-2 support (for storage devices) requires SCSI" depends on IEEE1394 && SCSI=n config IEEE1394_SBP2 - tristate "SBP-2 support (Harddisks etc.)" + tristate "Storage devices (SBP-2 protocol)" depends on IEEE1394 && SCSI help This option enables you to use SBP-2 devices connected to an IEEE @@ -127,24 +118,47 @@ config IEEE1394_ETH1394 The module is called eth1394 although it does not emulate Ethernet. +config IEEE1394_RAWIO + tristate "raw1394 userspace interface" + depends on IEEE1394 + help + This option adds support for the raw1394 device file which enables + direct communication of user programs with IEEE 1394 devices + (isochronous and asynchronous). Almost all application programs + which access FireWire require this option. + + To compile this driver as a module, say M here: the module will be + called raw1394. + +config IEEE1394_VIDEO1394 + tristate "video1394 userspace interface" + depends on IEEE1394 && IEEE1394_OHCI1394 + help + This option adds support for the video1394 device files which enable + isochronous communication of user programs with IEEE 1394 devices, + especially video capture or export. This interface is used by all + libdc1394 based programs and by several other programs, in addition to + the raw1394 interface. It is generally not required for DV capture. + + To compile this driver as a module, say M here: the module will be + called video1394. + config IEEE1394_DV1394 - tristate "OHCI-DV I/O support (deprecated)" + tristate "dv1394 userspace interface (deprecated)" depends on IEEE1394 && IEEE1394_OHCI1394 help The dv1394 driver is unsupported and may be removed from Linux in a future release. Its functionality is now provided by raw1394 together with libraries such as libiec61883. -config IEEE1394_RAWIO - tristate "Raw IEEE1394 I/O support" +config IEEE1394_VERBOSEDEBUG + bool "Excessive debugging output" depends on IEEE1394 help - This option adds support for the raw1394 device file which enables - direct communication of user programs with the IEEE 1394 bus and thus - with the attached peripherals. Almost all application programs which - access FireWire require this option. + If you say Y here, you will get very verbose debugging logs from the + ieee1394 drivers, including sent and received packet headers. This + will quickly result in large amounts of data sent to the system log. - To compile this driver as a module, say M here: the module will be - called raw1394. + Say Y if you really need the debugging output. Everyone else says N. endmenu diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c index 16b9d0ad154..a5ceff287a2 100644 --- a/drivers/ieee1394/sbp2.c +++ b/drivers/ieee1394/sbp2.c @@ -1539,15 +1539,13 @@ static void sbp2_prep_command_orb_sg(struct sbp2_command_orb *orb, static void sbp2_create_command_orb(struct sbp2_lu *lu, struct sbp2_command_info *cmd, - unchar *scsi_cmd, - unsigned int scsi_use_sg, - unsigned int scsi_request_bufflen, - struct scatterlist *sg, - enum dma_data_direction dma_dir) + struct scsi_cmnd *SCpnt) { struct sbp2_fwhost_info *hi = lu->hi; struct sbp2_command_orb *orb = &cmd->command_orb; u32 orb_direction; + unsigned int scsi_request_bufflen = scsi_bufflen(SCpnt); + enum dma_data_direction dma_dir = SCpnt->sc_data_direction; /* * Set-up our command ORB. @@ -1580,13 +1578,14 @@ static void sbp2_create_command_orb(struct sbp2_lu *lu, orb->data_descriptor_lo = 0x0; orb->misc |= ORB_SET_DIRECTION(1); } else - sbp2_prep_command_orb_sg(orb, hi, cmd, scsi_use_sg, sg, + sbp2_prep_command_orb_sg(orb, hi, cmd, scsi_sg_count(SCpnt), + scsi_sglist(SCpnt), orb_direction, dma_dir); sbp2util_cpu_to_be32_buffer(orb, sizeof(*orb)); - memset(orb->cdb, 0, 12); - memcpy(orb->cdb, scsi_cmd, COMMAND_SIZE(*scsi_cmd)); + memset(orb->cdb, 0, sizeof(orb->cdb)); + memcpy(orb->cdb, SCpnt->cmnd, SCpnt->cmd_len); } static void sbp2_link_orb_command(struct sbp2_lu *lu, @@ -1669,16 +1668,13 @@ static void sbp2_link_orb_command(struct sbp2_lu *lu, static int sbp2_send_command(struct sbp2_lu *lu, struct scsi_cmnd *SCpnt, void (*done)(struct scsi_cmnd *)) { - unchar *scsi_cmd = (unchar *)SCpnt->cmnd; struct sbp2_command_info *cmd; cmd = sbp2util_allocate_command_orb(lu, SCpnt, done); if (!cmd) return -EIO; - sbp2_create_command_orb(lu, cmd, scsi_cmd, scsi_sg_count(SCpnt), - scsi_bufflen(SCpnt), scsi_sglist(SCpnt), - SCpnt->sc_data_direction); + sbp2_create_command_orb(lu, cmd, SCpnt); sbp2_link_orb_command(lu, cmd); return 0; |