linux/drivers/firewire/Kconfig

83 lines
2.8 KiB

firewire: IEEE 1394 (FireWire) support should depend on HAS_DMA Commit b3d681a4fc108f9653bbb44e4f4e72db2b8a5734 ("firewire: Use COMPILE_TEST for build testing") added COMPILE_TEST as an alternative dependency for the purpose of build testing the firewire core. However, this bypasses all other implicit dependencies assumed by PCI, like HAS_DMA. If NO_DMA=y: drivers/built-in.o: In function `fw_iso_buffer_destroy': (.text+0x36a096): undefined reference to `dma_unmap_page' drivers/built-in.o: In function `fw_iso_buffer_map_dma': (.text+0x36a164): undefined reference to `dma_map_page' drivers/built-in.o: In function `fw_iso_buffer_map_dma': (.text+0x36a172): undefined reference to `dma_mapping_error' drivers/built-in.o: In function `sbp2_send_management_orb': sbp2.c:(.text+0x36c6b4): undefined reference to `dma_map_single' sbp2.c:(.text+0x36c6c8): undefined reference to `dma_mapping_error' sbp2.c:(.text+0x36c772): undefined reference to `dma_map_single' sbp2.c:(.text+0x36c786): undefined reference to `dma_mapping_error' sbp2.c:(.text+0x36c854): undefined reference to `dma_unmap_single' sbp2.c:(.text+0x36c872): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `sbp2_map_scatterlist': sbp2.c:(.text+0x36ccbc): undefined reference to `scsi_dma_map' sbp2.c:(.text+0x36cd36): undefined reference to `dma_map_single' sbp2.c:(.text+0x36cd4e): undefined reference to `dma_mapping_error' sbp2.c:(.text+0x36cd84): undefined reference to `scsi_dma_unmap' drivers/built-in.o: In function `sbp2_unmap_scatterlist': sbp2.c:(.text+0x36cda6): undefined reference to `scsi_dma_unmap' sbp2.c:(.text+0x36cdc6): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `complete_command_orb': sbp2.c:(.text+0x36d6ac): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `sbp2_scsi_queuecommand': sbp2.c:(.text+0x36d8e0): undefined reference to `dma_map_single' sbp2.c:(.text+0x36d8f6): undefined reference to `dma_mapping_error' Add an explicit dependency on HAS_DMA to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2014-07-09 21:04:00 +02:00
firewire: ohci: Asynchronous Reception rewrite Move the AR DMA descriptors out of the buffer pages, and map the buffer pages linearly into the kernel's address space. This allows the driver to ignore any page boundaries in the DMA data and thus to avoid any copying around of packet payloads. This fixes the bug where S800 packets that are so big (> 4080 bytes) that they can be split over three pages were not handled correctly. Due to the changed algorithm, we can now use arbitrarily many buffer pages, which improves performance because the controller can more easily unload its DMA FIFO. Furthermore, using streaming DMA mappings should improve perfomance on architectures where coherent DMA mappings are not cacheable. Even on other architectures, the caching behaviour should be improved slightly because the CPU no longer writes to the buffer pages. v2: Detect the last filled buffer page by searching the descriptor's residual count value fields in order (like in the old code), instead of going backwards through the transfer status fields; it looks as if some controllers do not set the latter correctly. v3: Fix an old resume bug that would now make the handler run into a BUG_ON, and replace that check with more useful error handling. Increase the buffer size for better performance with non-TI chips. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Maxim Levitsky writes: Works almost perfectly. I can still see RCODE_BUSY errors sometimes, not very often though. 64K here eliminates these errors completely. This is most likely due to nouveau drivers and lowest perf level I use to lower card temperature. That increases latencies too much I think. Besides that the IO is just perfect. Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-11-26 08:57:31 +01:00
firewire: new driver: nosy - IEEE 1394 traffic sniffer This adds the traffic sniffer driver for Texas Instruments PCILynx/ PCILynx2 based cards. The use cases for nosy are analysis of nonstandard protocols and as an aid in development of drivers, applications, or firmwares. Author of the driver is Kristian Høgsberg. Known contributers are Jody McIntyre and Jonathan Woithe. Nosy programs PCILynx chips to operate in promiscuous mode, which is a feature that is not found in OHCI-1394 controllers. Hence, only special hardware as mentioned in the Kconfig help text is suitable for nosy. This is only the kernelspace part of nosy. There is a userspace interface to it, called nosy-dump, proposed to be added into the tools/ subdirectory of the kernel sources in a subsequent change. Kernelspace and userspave component of nosy communicate via a 'misc' character device file called /dev/nosy with a simple ioctl() and read() based protocol, as described by nosy-user.h. The files added here are taken from git://anongit.freedesktop.org/~krh/nosy commit ee29be97 (2009-11-10) with the following changes by Stefan Richter: - Kconfig and Makefile hunks are written from scratch. - Commented out version printk in nosy.c. - Included missing <linux/sched.h>, reported by Stephen Rothwell. "git shortlog nosy{-user.h,.c,.h}" from nosy's git repository: Jonathan Woithe (2): Nosy updates for recent kernels Fix uninitialised memory (needed for 2.6.31 kernel) Kristian Høgsberg (5): Pull over nosy from mercurial repo. Use a misc device instead. Add simple AV/C decoder. Don't break down on big payloads. Set parent device for misc device. As a low-level IEEE 1394 driver, its files are placed into drivers/firewire/ although nosy is not part of the firewire driver stack. I am aware of the following literature from Texas Instruments about PCILynx programming: SCPA020A - PCILynx 1394 to PCI Bus Interface TSB12LV21BPGF Functional Specification SLLA023 - Initialization and Asynchronous Programming of the TSB12LV21A 1394 Device Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Acked-by: Kristian Høgsberg <krh@bitplanet.net>
2010-07-27 10:26:33 +02:00
firewire: new driver: nosy - IEEE 1394 traffic sniffer This adds the traffic sniffer driver for Texas Instruments PCILynx/ PCILynx2 based cards. The use cases for nosy are analysis of nonstandard protocols and as an aid in development of drivers, applications, or firmwares. Author of the driver is Kristian Høgsberg. Known contributers are Jody McIntyre and Jonathan Woithe. Nosy programs PCILynx chips to operate in promiscuous mode, which is a feature that is not found in OHCI-1394 controllers. Hence, only special hardware as mentioned in the Kconfig help text is suitable for nosy. This is only the kernelspace part of nosy. There is a userspace interface to it, called nosy-dump, proposed to be added into the tools/ subdirectory of the kernel sources in a subsequent change. Kernelspace and userspave component of nosy communicate via a 'misc' character device file called /dev/nosy with a simple ioctl() and read() based protocol, as described by nosy-user.h. The files added here are taken from git://anongit.freedesktop.org/~krh/nosy commit ee29be97 (2009-11-10) with the following changes by Stefan Richter: - Kconfig and Makefile hunks are written from scratch. - Commented out version printk in nosy.c. - Included missing <linux/sched.h>, reported by Stephen Rothwell. "git shortlog nosy{-user.h,.c,.h}" from nosy's git repository: Jonathan Woithe (2): Nosy updates for recent kernels Fix uninitialised memory (needed for 2.6.31 kernel) Kristian Høgsberg (5): Pull over nosy from mercurial repo. Use a misc device instead. Add simple AV/C decoder. Don't break down on big payloads. Set parent device for misc device. As a low-level IEEE 1394 driver, its files are placed into drivers/firewire/ although nosy is not part of the firewire driver stack. I am aware of the following literature from Texas Instruments about PCILynx programming: SCPA020A - PCILynx 1394 to PCI Bus Interface TSB12LV21BPGF Functional Specification SLLA023 - Initialization and Asynchronous Programming of the TSB12LV21A 1394 Device Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Acked-by: Kristian Høgsberg <krh@bitplanet.net>
2010-07-27 10:26:33 +02:00
firewire: new driver: nosy - IEEE 1394 traffic sniffer This adds the traffic sniffer driver for Texas Instruments PCILynx/ PCILynx2 based cards. The use cases for nosy are analysis of nonstandard protocols and as an aid in development of drivers, applications, or firmwares. Author of the driver is Kristian Høgsberg. Known contributers are Jody McIntyre and Jonathan Woithe. Nosy programs PCILynx chips to operate in promiscuous mode, which is a feature that is not found in OHCI-1394 controllers. Hence, only special hardware as mentioned in the Kconfig help text is suitable for nosy. This is only the kernelspace part of nosy. There is a userspace interface to it, called nosy-dump, proposed to be added into the tools/ subdirectory of the kernel sources in a subsequent change. Kernelspace and userspave component of nosy communicate via a 'misc' character device file called /dev/nosy with a simple ioctl() and read() based protocol, as described by nosy-user.h. The files added here are taken from git://anongit.freedesktop.org/~krh/nosy commit ee29be97 (2009-11-10) with the following changes by Stefan Richter: - Kconfig and Makefile hunks are written from scratch. - Commented out version printk in nosy.c. - Included missing <linux/sched.h>, reported by Stephen Rothwell. "git shortlog nosy{-user.h,.c,.h}" from nosy's git repository: Jonathan Woithe (2): Nosy updates for recent kernels Fix uninitialised memory (needed for 2.6.31 kernel) Kristian Høgsberg (5): Pull over nosy from mercurial repo. Use a misc device instead. Add simple AV/C decoder. Don't break down on big payloads. Set parent device for misc device. As a low-level IEEE 1394 driver, its files are placed into drivers/firewire/ although nosy is not part of the firewire driver stack. I am aware of the following literature from Texas Instruments about PCILynx programming: SCPA020A - PCILynx 1394 to PCI Bus Interface TSB12LV21BPGF Functional Specification SLLA023 - Initialization and Asynchronous Programming of the TSB12LV21A 1394 Device Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Acked-by: Kristian Høgsberg <krh@bitplanet.net>
2010-07-27 10:26:33 +02:00