kernel/git/stable/linux.git/drivers/ieee1394/sbp2.h, branch master

ieee1394: remove the old IEEE 1394 driver stack

2010-10-11T12:48:03+00:00

The drivers - ohci1394 (controller driver) - ieee1394 (core) - dv1394, raw1394, video1394 (userspace ABI) - eth1394, sbp2 (protocol drivers) are replaced by - firewire-ohci (controller driver) - firewire-core (core and userspace ABI) - firewire-net, firewire-sbp2 (protocol drivers) which are more featureful, better performing, and more secure than the older drivers; all with a smaller and more modern code base. The driver firedtv in drivers/media/dvb/firewire/ contains backends to both ieee1394 and firewire-core. Its ieee1394 backend code can be removed in an independent commit; firedtv as-is builds and works fine without ieee1394. The driver pcilynx (an incomplete controller driver) is deleted without replacement since PCILynx cards are extremely rare. Owners of these cards use them with the stand-alone bus sniffer driver nosy instead. The drivers nosy and init_ohci1394_dma which do not interact with either of the two IEEE 1394 stacks are not affected by the ieee1394 subsystem removal. There are still some issues with the newer firewire subsystem compared to the older one: - The rare and quirky controllers ALi M52xx, Apple UniNorth v1, NVIDIA NForce2 are even less well supported by firewire-ohci than by ohci1394. I am looking into the M52xx issue. - The experimental firewire-net is reportedly less stable than its experimental cousin eth1394. - Audio playback of a certain group of audio devices (ones based on DICE chipset with EAP; supported by prerelease FFADO code) does not work yet. This issue is still under investigation. - There were some ieee1394 based out-of-the-mainline drivers. Of them, only lisight, an audio driver for iSight webcams, seems still useful. Work is underway to reimplement it on top of firewire-core. All these remainig issues are minor; they should not stand in the way of overall better user experience of IEEE 1394 on Linux, together with a reduction in support efforts and maintenance burden. The coexistence of two IEEE 1394 kernel driver stacks in the mainline since 2.6.22 shall end now, as announced earlier this year. Signed-off-by: Stefan Richter

ieee1394: sbp2: add support for disks >2 TB (and 16 bytes long CDBs)

2009-07-02T19:27:01+00:00

Increase the command ORB data structure to transport up to 16 bytes long CDBs (instead of 12 bytes), and tell the SCSI mid layer about it. This is notably necessary for READ CAPACITY(16) and friends, i.e. support of large disks. Signed-off-by: Stefan Richter

ieee1394: sbp2: enforce s/g segment size limit

2008-10-15T20:21:07+00:00

1. We don't need to round the SBP-2 segment size limit down to a multiple of 4 kB (0xffff -> 0xf000). It is only necessary to ensure quadlet alignment (0xffff -> 0xfffc). 2. Use dma_set_max_seg_size() to tell the DMA mapping infrastructure and the block IO layer about the restriction. This way we can remove the size checks and segment splitting in the queuecommand path. This assumes that no other code in the ieee1394 stack uses dma_map_sg() with conflicting requirements. It furthermore assumes that the controller device's platform actually allows us to set the segment size to our liking. Assert the latter with a BUG_ON(). 3. Also use blk_queue_max_segment_size() to tell the block IO layer about it. It cannot know it because our scsi_add_host() does not point to the FireWire controller's device. We can also uniformly use dma_map_sg() for the single segment case just like for the multi segment case, to further simplify the code. Also clean up how the page table is converted to big endian. Thanks to Grant Grundler and FUJITA Tomonori for advice. Signed-off-by: Stefan Richter

ieee1394: sbp2: fix spindown for PL-3507 and TSB42AA9 firmwares

2008-07-14T11:00:18+00:00

Reported by Tino Keitel: PL-3507 with firmware from Prolific does not spin down the disk on START STOP UNIT with power condition = 0 and start = 0. It does however work with power condition = 2 or 3. Also found while investigating this: DViCO Momobay CX-1 and FX-3A (TI TSB42AA9/A based) become unresponsive after START STOP UNIT with power condition = 0 and start = 0. They stay responsive if power condition is set when stopping the motor. Signed-off-by: Stefan Richter

ieee1394: sbp2: add INQUIRY delay workaround

2008-02-16T14:40:34+00:00

Add the same workaround as found in fw-sbp2 for feature parity and compatibility of the workarounds module parameter. Signed-off-by: Stefan Richter Signed-off-by: Jarod Wilson

ieee1394: sbp2: raise default transfer size limit

2008-01-30T21:22:21+00:00

This patch speeds up sbp2 a little bit --- but more importantly, it brings the behavior of sbp2 and fw-sbp2 closer to each other. Like fw-sbp2, sbp2 now does not limit the size of single transfers to 255 sectors anymore, unless told so by a blacklist flag or by module load parameters. Only very old bridge chips have been known to need the 255 sectors limit, and we have got one such chip in our hardwired blacklist. There certainly is a danger that more bridges need that limit; but I prefer to have this issue present in both fw-sbp2 and sbp2 rather than just one of them. An OXUF922 with 400GB 7200RPM disk on an S400 controller is sped up by this patch from 22.9 to 23.5 MB/s according to hdparm. The same effect could be achieved before by setting a higher max_sectors module parameter. On buses which use 1394b beta mode, sbp2 and fw-sbp2 will now achieve virtually the same bandwidth. Fw-sbp2 only remains faster on 1394a buses due to fw-core's gap count optimization. Signed-off-by: Stefan Richter

ieee1394: sbp2: change some module parameters from int to bool

2007-07-09T22:07:41+00:00

This is upwards compatible, except that integer values other than 0 or 1 are no longer accepted. But values like "Y", "N", "no", "nnoooh!" work now. Also, improve a comment on the serialize_io parameter and make the ORB_SET_EXCLUSIVE macro ultra-safe. Signed-off-by: Stefan Richter

ieee1394: sbp2: remove unnecessary alignments of struct members

2007-04-29T22:00:27+00:00

The members "dma_addr_t command_orb_dma" and "dma_addr_t sge_dma" of sbp2.h::sbp2_command_info do not have to be aligned themselves --- only the memory which they point to has to be. The member "struct sbp2_command_orb command_orb" has to be aligned on 4 bytes boundary which is guaranteed because it contains u32 members. The member "struct sbp2_unrestricted_page_table scatter_gather_element", i.e. the SBP-2 s/g table, has to be aligned on 8 bytes boundary according to the SBP-2 spec. This is not a requirement for FireWire controllers but could be expected by SBP-2 targets. I see no need to align the members command_orb and scatter_gather_element on CPU cacheline boundaries. It could have performance benefits, but on the other hand sbp2 has a somewhat wasteful allocation scheme which should be optimized first before further tweaks like cacheline alignments. (E.g. don't always allocate SG_ALL s/g table elements.) Note, before as well as after the patch, the code relies on the assumption that memory alignment in the virtual address space is preserved in the physical address space after DMA mapping. Signed-off-by: Stefan Richter

ieee1394: sbp2: convert from PCI DMA to generic DMA

2006-12-07T22:11:43+00:00

API conversion without change in functionality Signed-off-by: Stefan Richter

sbp2: make 1bit bitfield unsigned

2006-12-07T22:05:47+00:00

A signed single-bit bitfield doesn't make much sense. Make it unsigned. Signed-off-by: Luca Tettamanti Signed-off-by: Stefan Richter