summaryrefslogtreecommitdiff
path: root/drivers/firewire/core-iso.c
AgeCommit message (Collapse)AuthorFilesLines
2010-08-02Merge firewire branches to be released post v2.6.35Stefan Richter1-8/+26
Conflicts: drivers/firewire/core-card.c drivers/firewire/core-cdev.c and forgotten #include <linux/time.h> in drivers/firewire/ohci.c Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-07-29firewire: add isochronous multichannel receptionStefan Richter1-7/+25
This adds the DMA context programming and userspace ABI for multichannel reception, i.e. for listening on multiple channel numbers by means of a single DMA context. The use case is reception of more streams than there are IR DMA units offered by the link layer. This is already implemented by the older ohci1394 + ieee1394 + raw1394 stack. And as discussed recently on linux1394-devel, this feature is occasionally used in practice. The big drawbacks of this mode are that buffer layout and interrupt generation necessarily differ from single-channel reception: Headers and trailers are not stripped from packets, packets are not aligned with buffer chunks, interrupts are per buffer chunk, not per packet. These drawbacks also cause a rather hefty code footprint to support this rarely used OHCI-1394 feature. (367 lines added, among them 94 lines of added userspace ABI documentation.) This implementation enforces that a multichannel reception context may only listen to channels to which no single-channel context on the same link layer is presently listening to. OHCI-1394 would allow to overlay single-channel contexts by the multi-channel context, but this would be a departure from the present first-come-first-served policy of IR context creation. The implementation is heavily based on an earlier one by Jay Fenlason. Thanks Jay. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-07-13firewire: core: fix fw_send_request kerneldoc commentStefan Richter1-1/+1
The present inline documentation of the fw_send_request() in-kernel API refers to userland code that is not applicable to kernel drivers at all. Reported-by: Ben Gamari <bgamari.foss@gmail.com> While we are at fixing the whole documentation of fw_send_request(), also improve the rest of firewire-core's kerneldoc comments: - Add a bit of text concerning fw_run_transaction()'s call parameters. - Append () to function names and tab-align parameter descriptions as suggested by the example in Documentation/kernel-doc-nano-HOWTO.txt. - Remove kerneldoc markers from comments on static functions. - Remove outdated parameter descriptions at build_tree(). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-04-22Merge branch 'for-linus' of ↵Linus Torvalds1-4/+10
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6: firewire: ohci: wait for local CSR lock access to finish firewire: ohci: prevent aliasing of locally handled register addresses firewire: core: fw_iso_resource_manage: return -EBUSY when out of resources firewire: core: fix retries calculation in iso manage_channel() firewire: cdev: fix cut+paste mistake in disclaimer
2010-04-19firewire: core: fw_iso_resource_manage: return -EBUSY when out of resourcesClemens Ladisch1-3/+7
Returning -EIO for all errors would not allow clients to determine if the resource allocation process itself failed, or if the resources are not available. (The latter information is needed by CMP to synchronize restoring of overlayed connections after a bus reset.) Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-04-19firewire: core: fix retries calculation in iso manage_channel()Clemens Ladisch1-1/+3
If there is a permanent error condition when communicating with the IRM, after the sixth error, the retry variable will be decremented to -1. If, in this case, the bits in channels_mask are not yet exhausted, the next channel is retried 2^32 times. To fix this, check that retry is never decremented beyond zero. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-03-30include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo1-0/+1
implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-15firewire: core: fw_iso_resource_manage: fix error handlingClemens Ladisch1-2/+3
If the bandwidth allocation fails, the error must be returned in *channel regardless of whether the channel allocation succeeded. Checking for c >= 0 is not correct if no channel allocation was requested, in which case this part of the code is reached with c == -EINVAL. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-09-05firewire: core: fix crash in iso resource managementStefan Richter1-2/+2
This fixes a regression due to post 2.6.30 commit "firewire: core: do not DMA-map stack addresses" 6fdc03709433ccc2005f0f593ae9d9dd04f7b485. As David Moore noted, a previously correct sizeof() expression became wrong since the commit changed its argument from an array to a pointer. This resulted in an oops in ohci_cancel_packet in the shared workqueue thread's context when an isochronous resource was to be freed. Reported-by: Jonathan Cameron <jic23@cam.ac.uk> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-06-25firewire: core: do not DMA-map stack addressesStefan Richter1-11/+13
The DMA mapping API cannot map on-stack addresses, as explained in Documentation/DMA-mapping.txt. Convert the two cases of on-stack packet payload buffers in firewire-core (payload of lock requests in the bus manager work and in iso resource management) to slab-allocated memory. There are a number on-stack buffers for quadlet write or quadlet read requests in firewire-core and firewire-sbp2. These are harmless; they are copied to/ from card driver internal DMA buffers since quadlet payloads are inlined with packet headers. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-06-16firewire: core: fix DMA unmapping in iso buffer removalStefan Richter1-2/+2
dmap_unmap_page() shall use the same direction as dma_map_page(). Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-06-14firewire: add IPv4 supportJay Fenlason1-0/+7
Implement IPv4 over IEEE 1394 as per RFC 2734 for the newer firewire stack. This feature has only been present in the older ieee1394 stack via the eth1394 driver. Still to do: - fix ipv4_priv and ipv4_node lifetime logic - fix determination of speeds and max payloads - fix bus reset handling - fix unaligned memory accesses - fix coding style - further testing/ improvement of fragment reassembly - perhaps multicast support Signed-off-by: Jay Fenlason <fenlason@redhat.com> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (rebased, copyright note, changelog)
2009-06-05firewire: rename source filesStefan Richter1-0/+329
The source files of firewire-core, firewire-ohci, firewire-sbp2, i.e. "drivers/firewire/fw-*.c" are renamed to "drivers/firewire/core-*.c", "drivers/firewire/ohci.c", "drivers/firewire/sbp2.c". The old fw- prefix was redundant to the directory name. The new core- prefix distinguishes the files according to which driver they belong to. This change comes a little late, but still before further firewire drivers are added as anticipated RSN. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>