Commit graph

118 commits

Author SHA1 Message Date
Jay Fenlason
f8c2287c65 firewire: implement asynchronous stream transmission
Allow userspace and other firewire drivers (fw-ipv4 I'm looking at
you!) to send Asynchronous Transmit Streams as described in 7.8.3 of
release 1.1 of the 1394 Open Host Controller Interface Specification.

Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (tweaks)
2009-03-24 20:56:49 +01:00
Stefan Richter
e1eff7a393 firewire: normalize a variable name
Standardize on  if (err)
                        handle_error;
           and  if (ret < 0)
                        handle_error;

Don't call a variable err if we store values in it which mean success.
Also, offset some return statements by a blank line since this how we do
it in drivers/firewire.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-24 20:56:48 +01:00
Stefan Richter
4817ed2402 firewire: prevent creation of multiple IR DMA contexts for the same channel
OHCI-1394 1.1 clause 10.4.3 says:  "If more than one IR DMA context
specifies receives for packets from the same isochronous channel, the
context destination for that channel's packets is undefined."

Any userspace client and in the future also kernelspace clients can
allocate IR DMA contexts for any channel.  We don't want them to
interfere with each other, hence it is preferable to return -EBUSY if
allocation of a second context for a channel is attempted.

Notes:
  - This limitation is OHCI-1394 specific, therefore its proper place of
    implementation is down in the low-level driver.

  - Since the <linux/firewire-cdev.h> ABI simply maps one userspace iso
    client context to one hardware iso context, this OHCI-1394
    limitation alas requires userspace to implement its own multiplexing
    of iso reception from the same channel and card to multiple clients
    when needed.

  - The limitation is independent of channel allocation at the IRM; the
    latter is really only important for the initiation of iso 
    transmission but not of iso reception.

  - We don't need to do the same for IT DMA because OHCI-1394 does not
    have any ties between IT contexts and channels.  Only the voluntary
    channel allocation protocol via the IRM, globally to the FireWire
    bus, can ensure proper isochronous transmit behaviour anyway.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-24 20:56:41 +01:00
Stefan Richter
53dca51175 firewire: remove line breaks before function names
type
    function_name(parameters);

is nice to look at but was not used consistently.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-24 20:56:40 +01:00
Stefan Richter
2dbd7d7e23 firewire: standardize a variable name
"ret" is the new "retval".

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-24 20:56:39 +01:00
David Moore
1aa292bb1c firewire: Include iso timestamp in headers when header_size > 4
Previously, when an iso context had header_size > 4, the iso header
(len/tag/channel/tcode/sy) was passed to userspace followed by quadlets
stripped from the payload.  This patch changes the behavior:
header_size = 8 now passes the header quadlet followed by the timestamp
quadlet.  When header_size > 8, quadlets are stripped from the payload.
The header_size = 4 case remains identical.

Since this alters the semantics of the API, the firewire API version
needs to be bumped concurrently with this change.

This change also refactors the header copying code slightly to be much
easier to read.

Signed-off-by: David Moore <dcm@acm.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-03-24 20:56:35 +01:00
Stefan Richter
8b7b6afaa8 firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others
Camcorders have a tendency to fail read requests to their config ROM and
write request to their FCP command register with ack_busy_X.  This has
become a problem with newer kernels and especially Panasonic camcorders,
causing AV/C in dvgrab and kino to fail.  Dvgrab for example frequently
logs "send oops"; kino reports loss of AV/C control.  I suspect that
lower CPU scheduling latencies in newer kernels made this issue more
prominent now.

According to
https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103
this can be fixed by configuring the FireWire controller for more
hardware retries for request transmission; these retries are evidently
more successful than libavc1394's own retry loop (typically 3 tries on
top of hardware retries).

Presumably the same issue has been reported at
https://bugzilla.redhat.com/show_bug.cgi?id=449252 and
https://bugzilla.redhat.com/show_bug.cgi?id=477279 .

In a quick test with a JVC camcorder (which didn't malfunction like the
reported camcorders), this change decreased the number of ack_busy_X
from 16 in three runs of dvgrab to 4 in three runs of the same capture
duration.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-24 11:17:27 +01:00
Stefan Richter
b006854955 firewire: ohci: change "context_stop: still active" log message
The present message is mostly just noise.  We only need to be notified
if the "active" flag does not go off before the retry loop terminates.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-01-24 11:17:27 +01:00
Stefan Richter
1d1dc5e83f firewire: fw-ohci: fix IOMMU resource exhaustion
There is a DMA map/ unmap imbalance whenever a block write request
packet is sent and then dequeued with ohci_cancel_packet.  The latter
may happen frequently if the AR resp tasklet is executed before the AT
req tasklet for the same transaction.

Add the missing dma_unmap_single.  This fixes
https://bugzilla.redhat.com/show_bug.cgi?id=475156

Reported-by: Emmanuel Kowalski
Tested-by: Emmanuel Kowalski
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-12-10 12:45:34 +01:00
Kay Sievers
a1f64819fe firewire: struct device - replace bus_id with dev_name(), dev_set_name()
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-31 08:48:25 +01:00
Stefan Richter
7007a0765e firewire: fw-ohci: initialization failure path fixes
Fix leaks when pci_probe fails.  Simplify error log strings.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-26 10:27:00 +01:00
Jay Fenlason
a55709ba9d firewire: fw-ohci: don't leak dma memory on module removal
The transmit and receive context dma memory was not being freed on
module removal.  Neither was the config rom memory.  Fix that.

The ab->next assignment is pure paranoia.

Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-10-26 10:27:00 +01:00
Linus Torvalds
837b41b5de Merge branch 'for-linus' of 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: state userland requirements in Kconfig help
  firewire: avoid memleak after phy config transmit failure
  firewire: fw-ohci: TSB43AB22/A dualbuffer workaround
  firewire: queue the right number of data
  firewire: warn on unfinished transactions during card removal
  firewire: small fw_fill_request cleanup
  firewire: fully initialize fw_transaction before marking it pending
  firewire: fix race of bus reset with request transmission
2008-07-27 10:24:06 -07:00
FUJITA Tomonori
8d8bb39b9e dma-mapping: add the device argument to dma_mapping_error()
Add per-device dma_mapping_ops support for CONFIG_X86_64 as POWER
architecture does:

This enables us to cleanly fix the Calgary IOMMU issue that some devices
are not behind the IOMMU (http://lkml.org/lkml/2008/5/8/423).

I think that per-device dma_mapping_ops support would be also helpful for
KVM people to support PCI passthrough but Andi thinks that this makes it
difficult to support the PCI passthrough (see the above thread).  So I
CC'ed this to KVM camp.  Comments are appreciated.

A pointer to dma_mapping_ops to struct dev_archdata is added.  If the
pointer is non NULL, DMA operations in asm/dma-mapping.h use it.  If it's
NULL, the system-wide dma_ops pointer is used as before.

If it's useful for KVM people, I plan to implement a mechanism to register
a hook called when a new pci (or dma capable) device is created (it works
with hot plugging).  It enables IOMMUs to set up an appropriate
dma_mapping_ops per device.

The major obstacle is that dma_mapping_error doesn't take a pointer to the
device unlike other DMA operations.  So x86 can't have dma_mapping_ops per
device.  Note all the POWER IOMMUs use the same dma_mapping_error function
so this is not a problem for POWER but x86 IOMMUs use different
dma_mapping_error functions.

The first patch adds the device argument to dma_mapping_error.  The patch
is trivial but large since it touches lots of drivers and dma-mapping.h in
all the architecture.

This patch:

dma_mapping_error() doesn't take a pointer to the device unlike other DMA
operations.  So we can't have dma_mapping_ops per device.

Note that POWER already has dma_mapping_ops per device but all the POWER
IOMMUs use the same dma_mapping_error function.  x86 IOMMUs use device
argument.

[akpm@linux-foundation.org: fix sge]
[akpm@linux-foundation.org: fix svc_rdma]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix bnx2x]
[akpm@linux-foundation.org: fix s2io]
[akpm@linux-foundation.org: fix pasemi_mac]
[akpm@linux-foundation.org: fix sdhci]
[akpm@linux-foundation.org: build fix]
[akpm@linux-foundation.org: fix sparc]
[akpm@linux-foundation.org: fix ibmvscsi]
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Muli Ben-Yehuda <muli@il.ibm.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Avi Kivity <avi@qumranet.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-26 12:00:03 -07:00
Stefan Richter
95984f62c9 firewire: fw-ohci: TSB43AB22/A dualbuffer workaround
Isochronous reception in dualbuffer mode is reportedly broken with
TI TSB43AB22A on x86-64.  Descriptor addresses above 2G have been
determined as the trigger:
https://bugzilla.redhat.com/show_bug.cgi?id=435550

Two fixes are possible:
  - pci_set_consistent_dma_mask(pdev, DMA_31BIT_MASK);
    at least when IR descriptors are allocated, or
  - simply don't use dualbuffer.
This fix implements the latter workaround.

But we keep using dualbuffer on x86-32 which won't give us highmen (and
thus physical addresses outside the 31bit range) in coherent DMA memory
allocations.  Right now we could for example also whitelist PPC32, but
DMA mapping implementation details are expected to change there.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-07-25 15:41:23 +02:00
Stefan Richter
bbf094cf3d firewire: remove unused struct members
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-07-14 13:06:03 +02:00
Stefan Richter
161b96e782 firewire: fw-ohci: unify printk prefixes
The messages which can be enabled by fw-ohci's debug module parameter
are changed from KERN_DEBUG to KERN_NOTICE level and uniformly prefixed
with "firewire_ohci: ".  This further simplifies communication with
users when we ask them to capture debug messages.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-06-19 00:12:35 +02:00
Stefan Richter
affc9c24ad firewire: fw-ohci: write selfIDBufferPtr before LinkControl.rcvSelfID
OHCI 1.1 clause 5.10 requires that selfIDBufferPtr is valid when a 1 is
written into LinkControl.rcvSelfID.

This driver bug has so far not been known to cause harm because most
chips obviously accept a later selfIDBufferPtr write, at least before
HCControl.linkEnable is written.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
2008-06-19 00:12:35 +02:00
Stefan Richter
e896ec4302 firewire: fw-ohci: disable PHY packet reception into AR context
We want the rcvPhyPkt bit in LinkControl off before we start using the
chip.  However, the spec says that the reset value of it is undefined.
Hence switch it explicitly off.

https://bugzilla.redhat.com/show_bug.cgi?id=244576#c48 shows that for
example the nForce2 integrated FireWire controller seems to have it on
by default.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-06-19 00:12:34 +02:00
Stefan Richter
ccff962943 firewire: fw-ohci: use of uninitialized data in AR handler
header_length and payload_length are filled with random data if an
unknown tcode was read from the AR buffer (i.e. if the AR buffer
contained invalid data).

We still need a better strategy to recover from this, but at least
handle_ar_packet now doesn't return out of bound buffer addresses
anymore.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-06-19 00:12:34 +02:00
Stefan Richter
e09770db0f firewire: remove unused struct member
request_generation is internal to fw-ohci and unneeded in fw_card.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-04-18 17:55:36 +02:00
Stefan Richter
d34316a4bd firewire: fw-ohci: work around generation bug in TI controllers (fix AV/C and more)
Unlike the ohci1394 driver, fw-ohci uses the selfIDGeneration field of
bus reset packets to determine the generation of incoming requests as
per OHCI 1.1 clause 8.4.2.3.  This is more precise --- provided that the
controller inserts the correct generation.  Texas Instruments chips
often don't.

This prevented the transmission of response packets, which for example
broke AV/C transactions as used when communicating with miniDV cameras
and any other AV/C devices.

There is apparently no way to detect and adjust incorrect generations.
Therefore we ignore the generation of bus reset packets from TI chips
and use the generation of the self ID buffer instead.  Alas this is
received at a slightly wrong time.  In rare cases, this could cause us
to not respond to legitimate requests or to respond to expired requests.
(The latter is less likely because the bus reset packet AR event is
typically handled before the self ID complete event.)

Bug reported by Mladen Kuntner, who was extraordinarily patient while
dealing with the driver maintainers.  Fix confirmed to be required and
effective for TSB82AA2 and a TSB43AB22 or TSB43AB22A.
https://bugzilla.redhat.com/show_bug.cgi?id=243081

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-04-18 17:55:35 +02:00
Stefan Richter
08ddb2f4c2 firewire: fw-ohci: extend logging of bus generations and node ID
Extend the logging of "AR evt_bus_reset, link internal" to "AR
evt_bus_reset, generation ${selfIDGeneration}".  That way we can check
whether this generation matches the one seen in self ID complete event
logging.  See OHCI 1.1 clause 8.4.2.3.

Also extend logging of "firewire_ohci: * selfIDs, generation *" by
"local node ID ffc*" in self ID logging to make the local node in AT/AR
event logs more obvious.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-04-18 17:55:35 +02:00
Stefan Richter
a007bb857e firewire: fw-ohci: conditionally log busReset interrupts
Add a debug option to watch bus reset interrupt events.  Half of this
patch is taken from Jarod Wilson's first version of the JMicron fix.

BusReset interrupts are only generated if the respective module
parameter flag was set before the controller is being initialized.
Else we keep this event masked to reduce IRQ load in normal operation
and to avoid potential problems with buggy chips.

Note, this is unlike the other IRQ events whose logging can be enabled
any time after chip initialization.  This and the influence on what
interrupts the chip generates is why I added an extra flag for it.

Also, reorder the debug parameter flags according to their perceived
usefulness.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-04-18 17:55:35 +02:00
Jarod Wilson
76f73ca1b2 firewire: fw-ohci: don't append to AT context when it's not active
I finally tracked down the issues with this JMicron PCI-e card in my
possession to a failure to comply with section 7.2.3.2 of the OHCI 1.1
specification (thanks to Kristian for the pointer to illustrate that it
is indeed a flaw in this card, not the driver). The controller should
simply flush the packets we've appended to its AT queue if a bus reset
occurs before they've been transmitted and we'll try again, but
something goes wrong and the controller winds up hung.

However, we can avoid the problem by simply checking if the
IntEvent.busReset register had been set before we try appending to the
AT context. When busReset is set, the AT context is completely halted
until busReset is cleared, so there's no point in appending AT packets
until the register is cleared. So at_context_queue_packet() now checks
for busReset being set, and bails with an RCODE_GENERATION packet ack,
which results in us trying to append the packet again after recognizing
the fact there has been a bus reset, and clearing busReset.

Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-04-18 17:55:35 +02:00
Jarod Wilson
75f7832e3b firewire: fw-ohci: log regAccessFail events
While trying to debug this piece of crap JMicron PCI-e controller in my
possession, one thought was that perhaps I was encountering register access
failures. I'm not, but logging them would be good, so we can see if they
are a real problem we should be taking into account anywhere in the code.

Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (added list contact)
2008-04-18 17:55:34 +02:00
Jarod Wilson
022147242f firewire: fw-ohci: make sure HCControl register LPS bit is set
I've now witnessed multiple occasions where one of my controllers (a very
poorly working JMicron PCIe card) fails to get its registers properly set
up in ohci_enable(), apparently due to an occasionally very slow to
initiate SClk. The easy fix for this problem is to add a tiny while loop
to try again a time or three after initially enabling LPS before we
move on (or give up).

Of course, the card still isn't fully functional yet, but this gets it at
least one tiny step closer...

Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-04-18 17:55:34 +02:00
Stefan Richter
130d5496e2 firewire: fw-ohci: missing PPC PMac feature calls in failure path
Balance ohci_pmac_on and ohci_pmac_off if pci_driver.probe fails.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-04-18 17:55:34 +02:00
Stefan Richter
43286568ad firewire: fw-ohci: untangle a mixed unsigned/signed expression
and make another expression more readable.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-04-18 17:55:34 +02:00
Stefan Richter
ad3c0fe8b8 firewire: debug interrupt events
This adds debug printks for asynchronous transmission and reception and
for self ID reception.  They can be enabled at module load time, and at
runtime via /sys/module/firewire_ohci/parameters/debug.

Signed-off-by: Jarod Wilson <jwilson@redhat.com>

Also added:  Logging of interrupt event codes and of cancelled AT
packets.

The code now depends on a Kconfig variable.  This makes it easier to
build firewire-ohci without the feature or to make it an option in the
future.  The variable is currently hidden and always on.

This feature inflates firewire-ohci.ko by 7 kB = 27% on x86-64 and by
4 kB = 23% on i686.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-04-18 17:55:34 +02:00
Stefan Richter
016bf3dfcf firewire: fw-ohci: catch self_id_count == 0
fw_core_handle_bus_reset() incorrectly relied on the assumption that
self_id_count > 0.

We check early in fw-ohci and discard the self ID complete event if
self_id_count == 0 because a valid event always has at least one self ID
packet in it (the one of the local node).  Hence treat self_id_count ==
0 like any other kind of invalid self ID buffer.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-04-18 17:55:34 +02:00
Stefan Richter
c8a9a498e1 firewire: fw-ohci: add self ID error check
Discard self ID buffer contents if
  - the selfIDError flag is set,
  - any of the self ID packets has bit errors.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-04-18 17:55:33 +02:00
Stefan Richter
2ed0f181f0 firewire: fw-ohci: refactor probe, remove, suspend, resume
Clean up shared code and variable names.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-04-18 17:55:33 +02:00
Stefan Richter
eb5ca72eff firewire: fw-ohci: switch on bus power after resume on PPC PMac
The platform feature calls in the suspend method switched off cable
power, but the calls in the resume method did not switch it back on.

Add the necessary feature call to .resume.  Also add the corresponding
call to .suspend to make .suspend's behavior explicitly the same on all
PMacs.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-04-18 17:55:33 +02:00
Stefan Richter
080de8c2c5 firewire: fw-ohci: add option for remote debugging
This way firewire-ohci can be used for remote debugging like ohci1394.
Version with amendment from Fri, 11 Apr 2008 00:08:08 +0200.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Bernhard Kaindl <bk@suse.de>
2008-04-18 17:55:33 +02:00
Stefan Richter
bd7dee6311 firewire: remove superfluous reference counting
The card->kref became obsolete since patch "firewire: fix crash in
automatic module unloading" added another counter of card users.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-04-18 17:55:31 +02:00
Jarod Wilson
6b84236d37 firewire: fw-ohci: plug dma memory leak in AR handler
There's an ugly little memory leak in firewire-ohci's
ar_context_tasklet(), where we're not freeing up some of the memory we
use for each ar_buffer, due to a moving pointer. The problem has been
there for a while, but didn't get noticed until after converting the AR
routines over to use coherent DMA and I started running into I/O stall-
outs with the following message output repeatedly to the console:

PCI-DMA: Out of IOMMU space for 53248 bytes at device 0000:04:09.0

Plugging this leak is definitely necessary, but unfortunately, isn't the
entire answer to my problem, it only increases the amount of I/O that I
can do before hitting the problem. Still working on tracking down the
root cause..

Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-27 21:01:14 +01:00
Stefan Richter
f5101d58af firewire: fw-ohci: shut up false compiler warning on PPC32
Shut up "may be used uninitialised in this function" warnings due to
PPC32's implementation of dma_alloc_coherent().

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-14 00:57:00 +01:00
Jarod Wilson
bde1709aaa firewire: fw-ohci: use dma_alloc_coherent for ar_buffer
Currently, we do nothing to guarantee we have a consistent DMA buffer for
asynchronous receive packets. Rather than doing several sync's following a
dma_map_single() to get consistent buffers, just switch to using
dma_alloc_coherent().

Resolves constant buffer failures on my own x86_64 laptop w/4GB of RAM and
likely to fix a number of other failures witnessed on x86_64 systems with
4GB of RAM or more.

Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-14 00:57:00 +01:00
Stefan Richter
11bf20ad02 firewire: fw-ohci: Apple UniNorth 1st generation support
Mostly copied from ohci1394.c.  Necessary for some older Macs, e.g.
PowerBook G3 Pismo and early PowerBook G4 Titanium.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-14 00:56:59 +01:00
Stefan Richter
ea8d006b91 firewire: fw-ohci: PPC PMac platform code
Copied from ohci1394.c.  This code is necessary to prevent machine check
exceptions when reloading or resuming the driver.

Tested on a 1st generation PowerBook G4 Titanium, which also needs the
pci_probe() hunk.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

I was able to reproduce the system exception on resume with a 3rd-gen
Titanium PowerBook G4 667, and this patch does let the system resume
successfully now.

Not quite clear if there was possibly an updated version coming using
pci_enable_device() instead of the pair of pmac_call_feature() calls,
but either way, this is a definite must-have, at least for older ppc
macs -- my Aluminum PowerBook G4/1.67 suspends and resumes without this
patch just fine.

Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2008-03-14 00:56:58 +01:00
Stefan Richter
efbf390a2d firewire: endianess annotations
Kills warnings from 'make C=1 CHECKFLAGS="-D__CHECK_ENDIAN__" modules':

drivers/firewire/fw-transaction.c:771:10: warning: incorrect type in assignment (different base types)
drivers/firewire/fw-transaction.c:771:10:    expected unsigned int [unsigned] [usertype] <noident>
drivers/firewire/fw-transaction.c:771:10:    got restricted unsigned int [usertype] <noident>
drivers/firewire/fw-transaction.h:93:10: warning: incorrect type in assignment (different base types)
drivers/firewire/fw-transaction.h:93:10:    expected unsigned int [unsigned] [usertype] <noident>
drivers/firewire/fw-transaction.h:93:10:    got restricted unsigned int [usertype] <noident>
drivers/firewire/fw-ohci.c:1490:8: warning: restricted degrades to integer
drivers/firewire/fw-ohci.c:1490:35: warning: restricted degrades to integer
drivers/firewire/fw-ohci.c:1516:5: warning: cast to restricted type

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-03-14 00:56:58 +01:00
Stefan Richter
25df287dc7 firewire: endianess fix
The generation of incoming requests was filled in in wrong byte order on
machines with big endian CPU.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
2008-03-14 00:56:58 +01:00
David Moore
fe5ca63430 firewire: fw-ohci: Dynamically allocate buffers for DMA descriptors
Previously, the fw-ohci driver used fixed-length buffers for storing
descriptors for isochronous receive DMA programs.  If an application
(such as libdc1394) generated a DMA program that was too large, fw-ohci
would reach the limit of its fixed-sized buffer and return an error to
userspace.

This patch replaces the fixed-length ring-buffer with a linked-list of
page-sized buffers.  Additional buffers can be dynamically allocated and
appended to the list when necessary.  For a particular context, buffers
are kept around after use and reused as necessary, so there is no
allocation taking place after the DMA program is generated for the first
time.

In addition, the buffers it uses are coherent for DMA so there is no
syncing required before and after writes.  This syncing wasn't properly
done in the previous version of the code.

-

This is the fourth version of my patch that replaces a fixed-length
buffer for DMA descriptors with a dynamically allocated linked-list of
buffers.

As we discovered with the last attempt, new context programs are
sometimes queued from interrupt context, making it unacceptable to call
tasklet_disable() from context_get_descriptors().

This version of the patch uses ohci->lock for all locking needs instead
of tasklet_disable/enable.  There is a new requirement that
context_get_descriptors() be called while holding ohci->lock.  It was
already held for the AT context, so adding the requirement for the iso
context did not seem particularly onerous.  In addition, this has the
side benefit of allowing iso queue to be safely called from concurrent
user-space threads, which previously was not safe.

Signed-off-by: David Moore <dcm@acm.org>
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Jarod Wilson <jwilson@redhat.com>

-

Fixes the following issues:
  - Isochronous reception stopped prematurely if an application used a
    larger buffer.  (Reproduced with coriander.)
  - Isochronous reception stopped after one or a few frames on VT630x
    in OHCI 1.0 mode.  (Fixes reception in coriander, but dvgrab still
    doesn't work with these chips.)

Patch update: struct member alignment, whitespace nits

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-01-30 22:22:24 +01:00
Stefan Richter
bb9f2206b6 firewire: fw-ohci: CycleTooLong interrupt management
The firewire-ohci driver so far lacked the ability to resume cycle
master duty after that condition happened, as added to ohci1394 in Linux
2.6.18 by commit 57fdb58fa5.  This ports
this patch to fw-ohci.

The "cycle too long" condition has been seen in practice
  - with IIDC cameras if a mode with packets too large for a speed is
    chosen,
  - sporadically when capturing DV on a VIA VT6306 card with ohci1394/
    ieee1394/ raw1394/ dvgrab 2.
    https://bugzilla.redhat.com/show_bug.cgi?id=415841#c7
(This does not fix Fedora bug 415841.)

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-01-30 22:22:24 +01:00
David Moore
bcee893c6c firewire: fw-ohci: Bug fixes for packet-per-buffer support
This patch corrects a number of bugs in the current OHCI 1.0
packet-per-buffer support:

1. Correctly deal with payloads that cross a page boundary.  The
previous version would not split the descriptor at such a boundary,
potentially corrupting unrelated memory.

2. Allow user-space to specify multiple packets per struct
fw_cdev_iso_packet in the same way that dual-buffer allows.  This is
signaled by header_length being a multiple of header_size.  This
multiple determines the number of packets.  The payload size allocated
per packet is determined by dividing the total payload size by the
number of packets.

3. Make sync support work properly for packet-per-buffer.

I have tested this patch with libdc1394 by forcing my OHCI 1.1
controller to use the packet-per-buffer support instead of dual-buffer.

I would greatly appreciate testing by those who have a DV devices and
other types of iso streamers to make sure I didn't cause any
regressions.

Stefan, with this patch, I'm hoping that libdc1394 will work with all
your OHCI 1.0 controllers now.

The one bit of future work that remains for packet-per-buffer support is
the automatic compaction of short payloads that I discussed with
Kristian.

Signed-off-by: David Moore <dcm@acm.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-01-30 22:22:23 +01:00
David Moore
0642b6577f firewire: fw-ohci: Fix for dualbuffer three-or-more buffers
This patch fixes the problem where different OHCI 1.1 controllers behave
differently when a received iso packet straddles three or more buffers
when using the dual-buffer receive mode.  Two changes are made in order
to handle this situation:

1. The packet sync DMA descriptor is given a non-zero header length and
non-zero payload length.  This is because zero-payload descriptors are
not discussed in the OHCI 1.1 specs and their behavior is thus
undefined.  Instead we use a header size just large enough for a single
header and a payload length of 4 bytes for this first descriptor.

2. As we process received packets in the context's tasklet, read the
packet length out of the headers.  Keep track of the running total of
the packet length as "excess_bytes", so we can ignore any descriptors
where no packet starts or ends.  These descriptors may not have had
their first_res_count or second_res_count fields updated by the
controller so we cannot rely on those values.

The main drawback of this patch is that the excess_bytes value might get
"out of sync" with the packet descriptors if something strange happens
to the DMA program.  I'm not if such a thing could ever happen, but I
appreciate any suggestions in making it more robust.

Also, the packet-per-buffer support may need a similar fix to deal with
issue 1, but I haven't done any work on that yet.

Stefan, I'm hoping that with this patch, all your OHCI 1.1 controllers
will work properly with an unmodified version of libdc1394.

Signed-off-by: David Moore <dcm@acm.org>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-01-30 22:22:23 +01:00
Jarod Wilson
a186b4a6b2 firewire: OHCI 1.0 Isochronous Receive support
Third rendition of FireWire OHCI 1.0 Isochronous Receive support, using a
zer-copy method similar to OHCI 1.1 which puts the IR data payload directly
into the userspace buffer. The zero-copy implementation eliminates the
video artifacts, audio popping, and buffer underrun problems seen with
version 1 of this patch, as well as fixing a regression in OHCI 1.1 support
introduced by version 2 of this patch.

Successfully tested in OHCI 1.1 mode on the following chipsets:

- NEC uPD72847 (rev 01), OHCI 1.1 (PCI)
- Ti XIO2200(A) (rev 01), OHCI 1.1 (PCIe)
- Ti TSB41AB2 (rev 01), OHCI 1.1 (PCI on SB Audigy)
- Apple UniNorth 2 (rev 81), OHCI 1.1 (PowerBook G4 onboard)

Successfully tested in OHCI 1.0 mode on the following chipsets:

- Agere FW323 (rev 06), OHCI 1.0 (Mac Mini onboard)
- Agere FW323 (rev 06), OHCI 1.0 (PCI)
- Via VT6306 (rev 46), OHCI 1.0 (PCI)
- NEC OrangeLink (rev 01), OHCI 1.0 (PCI)
- NEC uPD72847 (rev 01), OHCI 1.1 (PCI)
- Ti XIO2200(A) (rev 01), OHCI 1.1 (PCIe)

The bulk of testing was done in an x86_64 system, but was also successfully
sanity-tested on other systems, including a PPC(32) PowerBook G4 and an i686
EPIA M10k. Crude benchmarking (watching top during capture) puts the cpu
utilization during capture on the EPIA's 1GHz Via C3 processor around 13%,
which is down from 30% with the v1 code.

Some implementation details:

To maintain the same userspace API as dual-buffer mode, we set up two
descriptors for every incoming packet. The first is an INPUT_MORE descriptor,
pointing to a buffer large enough to hold just the packet's iso headers,
immediately followed by an INPUT_LAST descriptor, pointing to a chunk of the
userspace buffer big enough for the packet's data payload. With this setup,
each incoming packet fills in these two descriptors in a manner that very
closely emulates dual-buffer receive, to the point where the bulk of the
handle_ir_* code is now identical between the two (and probably primed for
some restructuring to share code between them).

The only caveat I have at the moment is that neither of my OHCI 1.0 Via
VT6307-based FireWire controllers work particularly well with this code
for reasons I have yet to figure out.

Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-12-10 21:55:19 +01:00
Kristian Høgsberg
0bd243c4d9 firewire: Fix pci resume to not pass in a __be32 config rom.
The ohci_enable() function shared between pci_probe and pci_resume
takes a host endian config rom, but ohci->config_rom is __be32.  This
sets up the config rom in the wrong endian on little endian machine,
specifically, BusOptions will be initialized to a 0 max receive size.

This patch changes the way we reuse the config rom so that we avoid
this problem.

Signed-off-by: Kristian Hoegsberg <krh@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-10-31 19:02:19 +01:00
Stefan Richter
4b6d51ec62 firewire: fw-ohci: shut up a superfluous compiler warning
New warning since commit ab88ca488b,
"firewire: fw-ohci: missing dma_unmap_single":
drivers/firewire/fw-ohci.c: In function 'at_context_transmit':
drivers/firewire/fw-ohci.c:609: warning: 'payload_bus' may be used
 uninitialized in this function

Access to payload_bus is conditional on packet->payload_length > 0,
and that won't change while in at_context_queue_packet.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2007-10-22 19:48:56 +02:00