summaryrefslogtreecommitdiff
path: root/drivers/ieee1394
diff options
context:
space:
mode:
authorIngo Molnar <mingo@elte.hu>2008-06-23 11:53:03 +0200
committerIngo Molnar <mingo@elte.hu>2008-06-23 11:53:03 +0200
commit009b9fc98ddd83f9139fdabb12c0d7a8535d5421 (patch)
treef7d3e182407d2ebe50a9b8db6361ac910027a1cf /drivers/ieee1394
parent3711ccb07b7f0a13f4f1aa16a8fdca9c930f21ca (diff)
parent481c5346d0981940ee63037eb53e4e37b0735c10 (diff)
Merge branch 'linus' into x86/threadinfotip-x86-threadinfo-2008-06-23_09.53_Mon
Diffstat (limited to 'drivers/ieee1394')
-rw-r--r--drivers/ieee1394/Kconfig118
-rw-r--r--drivers/ieee1394/sbp2.c20
2 files changed, 74 insertions, 64 deletions
diff --git a/drivers/ieee1394/Kconfig b/drivers/ieee1394/Kconfig
index 545663ef820b..95f45f9b8e5e 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 16b9d0ad154e..a5ceff287a28 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;