If read() on the inotify handle gave us several events at once, and handling
one of them resulted in whatever error, there is little reason not to try
handling the rest of the events.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If multiple inotify events are presented, process *all* of them.
This can happen when several device adds are pushed simultaneously.
handle_inotify() was refactored.
Signed-off-by: Peter Hurley <phurley@charter.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If an error is encountered while adding a new device in inotify
handling, make sure the fd is marked invalid (-1).
Signed-off-by: Peter Hurley <phurley@charter.net>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Applications or higher-level libraries have retry strategies of their own
in place, but they don't work too well sometimes. For example, old
Panasonic camcorders require pauses in the order of several milliseconds
between response of a former transaction and request of the next one,
but libavc1394 and libiec61883 retry already after 20 microseconds.
This change cures all FCP transaction failures ("send oops") in kino and
dvgrab that I was getting with Panasonic NV-DX110. According to reports,
Panasonic AG-EZ30 and Grundig Scenos DLC 2000 were affected too.
The additional latency in raw1394_read/write/lock/lock64 appears to be
the better alternative compared to terminal I/O failures. Besides, a
caller of this blocking request API should at least in theory be
prepared to cope with transaction durations in the order of a few seconds.
IEEE 1394 specifies split transaction timeouts of up to 8 seconds. An
application which needs more control should use the non-blocking request
API, i.e. raw1394_start_read/write/lock/lock64.
We specifically only retry after ack-busy, not after any of the other
types of transaction failures that may or may not succeed if retried.
This change is only done in the firewire-core backend (a.k.a. juju).
The same could be added to the raw1394 backend (a.k.a. linux1394) but is
not as important there, perhaps because transaction completion latency
in the ieee1394 core very much increases the success rate of existing
retry code in libavc1394 and friends.
Note, this does not fix every and all FCP transaction problems. There
are e.g. certain JVC camcorders which do not properly complete FCP
transactions if an application frequently polls for status or requests
status right before a control request, even with an order of magnitude
greater delays than used in this patch.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Reviewed-by: Dan Dennedy <dan@dennedy.org>
The kernel already read each node's Configuration ROM and cached it.
So let all libraw1394 clients read from that cache instead of having
to perform all those transactions all over again.
This reduces bus traffic at application start-up and at each bus reset.
It also makes all Configuration ROM accesses fool-proof and robust.
This together with the kernel patch "firewire: core: handle ack_busy
when fetching the Config ROM" lets me use an old Panasonic camcorder
which requires us to keep pauses between response and request ---
longer than librom1394's retry pause --- with dvgrab (though still
with frequent failures of write requests to FCP_COMMAND, i.e. with lots
of "send oops" noise in the console and occasionally having to repeat
key-presses in interactive mode).
For simplicity of implementation, only the blocking raw1394_read() is
modified, not the nonblocking raw1394_start_read().
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
Libraw1394 uses raw1394's convention of cycle numbers always being less
than one second, i.e., in the range 0..7999.
Firewire-core uses raw cycle numbers as used by the hardware, i.e., with
several additional bits for the seconds. This was correctly handled
when presenting timestamps returned by the kernel to the application,
but the application's start_on_cycle value was passed directly to the
kernel.
To fix this, do the same calculations that ohci1394 did internally,
i.e., interpret the start_on_cycle value as relative to the current
seconds value of the cycle timer.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Libraw1394's attempt to optimize away the packet queueing ioctl syscall
overhead was a little bit too successful: when used with FFADO's
streaming system, it ended up delaying packets after their intended
transmission time.
For now, to ensure correctness, don't try to optimize anything.
This makes FFADO playback on Juju with my DICE work.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
When faced with bogus config ROM read responses from an audio device
that did not support block requests as advertized, libffado's csr1212
code was able to recover when running on top of raw1394 but corrupted
its config ROM cache when running on top of firewire-core.
http://subversion.ffado.org/ticket/299
While the actual cause was a combination of firmware bug of the device
and flaw in csr1212.c of libffado, the much less graceful behavior when
running on firewire-core was obviously due to libraw1394's
firewire-core backend. Hence,
- do not write into the client's buffer if rcode != RCODE_COMPLETE,
- do not copy more data than the actual response contained.
The latter safeguard is not overly effective though. The libraw1394 API
has no means to inform a client about the error case that a responder
node sent less bytes than were requested. (The case that the responder
sent more bytes than requested is covered up by the kernel already.)
Should we synthesize an I/O failure? Does not sound ideal either.
However, such a size mismatch should never happen; the important part of
this change is the RCODE_COMPLETE check.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If multiple cards are installed, firewire-core will emit requests from
nodes on any of the cards to clients. This is not expected by
libraw1394 clients since a raw1394handle_t is bound to a single card
alias port.
On kernel 2.6.36 and newer we can filter out requests from other cards.
Note that we still need to call the response ioctl in order to release
kernel resources associated with an inbound transaction.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The firewire-core (juju) backend of libraw1394 installs address range
mappings on the default ioctl fd, i.e. a file that represents a random
device on the chosen port. It receives incoming requests from any
sender node via this address range mapping. Due to a kernel ABI
limitation, the sender node ID is not known though. So far libraw1394
simply assumed the node ID of the device that provided the default
ioctl fd. This only works if there is only one accessible fd on the
entire bus.
This limitation caused for example libffado to fail to work with
another AV/C or IIDC device attached to the bus, because node IDs of
FCP requests and FCP responses did not match since the latter were
wrong. FCP clients which did not check sender node IDs were seemingly
not affected by this bug. The bug is fixed by a kernel ABI extension
in Linux 2.6.36. This libraw1394 change implements libraw1394's
counterpart to this ABI extension.
Hence this libraw1394 fix requires
- kernel-headers 2.6.36 or later at build time of libraw1394
- kernel 2.6.36 or later at runtime.
Otherwise, libraw1394 simply degrades to the faulty previous behaviour.
Side note: The change of IMPLEMENTED_CDEV_ABI_VERSION to 4 requires
that we fill in struct fw_cdev_allocate.region_end which was added in
the ABI v4.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Since linux/firewire-cdev.h header file and libraw1394 sources are
distributed separately, it is wrong to fill in a constant from that
header into the FW_CDEV_IOC_GET_INFO ioctl as the ABI version which
libraw1394 supports. This may not be forward compatible if an old
libraw1394 is compiled with a new kernel header and ran on top of a
kernel that implements new features that require a compatible
userland.
OK, the damage is already done in released versions of libraw1394.
Hence the FW_CDEV_VERSION of the kernel header file is not going to
be updated anymore in future kernel versions. (Only the version
internally to firewire-core will be incremented further.)
But let's remove the buggy usage of FW_CDEV_VERSION nevertheless.
Developers of other firewire-cdev client programs might look at
libraw1394 sources. The libraw1394 sources should not teach them
how to do it wrong.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
because ieee1394_destroy_handle does it too. Otherwise, clients which
rely on the ieee1394 backend behaviour leak memory when running on the
juju backend.
Also add the ability to call fw_iso_shutdown multiple times or before
a successful context initialization. Faulty clients might rely on it
based on ieee1394 backend behaviour.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Libraw1394 must not rely on the kernel always handing out the value 0
as handle of the (first) allocated isochronous I/O context. For now
this assumption is true but it may not stay that way forever.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Also add errno = ENOMEM because it is said that that some malloc
implementations might miss to do so.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
When EPOLLHUP event is received in fw_loop_iterate(), it is or'd
with EPOLLERR. The EPOLLHUP event was then overlooked in
handle_device_event() with unpredictable-but-generally bad results.
This problem has been rediscovered several times.
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13330http://thread.gmane.org/gmane.linux.kernel.firewire.devel/13779
Reported-by: B.J. Buchalter <bj@mhlabs.com>
Reported-by: Michael Thireos <mthireos@vanteon.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
If running on top of the raw1394 kernel driver (any kernel version) or
on top of firewire-core (kernel version <= 2.6.29), raw1394_start_*
functions will return a value > 0 on success, not == 0. Only with
firewire-core of kernel 2.6.30 or later, == 0 is returned on success.
The exact value depends on which driver is used, on CPU architecture,
and on request payload size in case of some types of requests. In any
case, only that the value is > or == 0 on success (but == -1 on
failure) is significant to libraw1394 client applications.
This mismatch between documentation and implementation was already
present in older libraw1394 versions, including v1.x. For the time
being, do not change the implementation, only adjust the documentation.
Reported-by: Dr. David Alan Gilbert
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Questions and patches should be posted to the list rather than just sent
as personal mail to Dan. That way, more people can answer or review it
without Dan having to forward libraw1394 mails to the list all the time.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Reported by Guus Sliepen: "make doc" failed due to missing doctype,
unknown elements, and duplicate element IDs in libraw1394.sgml.
The fix is to declare a recent DTD (matching the one which is used
in current Linux kernel documentation docbooks) and to make the
conflicting element IDs unique.
The latter part of the fix is just temporary. In order to avoid the
conflict when the documentation is updated the next time, also fix the
kerneldoc comments of the respective API elements: These are typedefs,
hence kernel-doc needs their comments prepended by "typedef ".
Tested with Gentoo's docbook-xml-dtd 4.5, docbook-xsl-stylesheets
1.75.2, docbook-sgml-utils 0.6.14, and openjade 1.3.2-r1.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
The number of packets is a 4th of the number of header bytes (in case of
ABI version 1). Also, wrap after an increment over 8000.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This change is essentially cosmetic: Set fields of structs passed to
the kernel via ioctl so that valgrind will not complain about them.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, comments)
More accurately report the cycle on which isochronous packets were
received. Only affects libraw1394 when used with kernel 2.6.29 or
older.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, whitespace)
While firewire-core's iso reception ABI was fixed in its version 2 to
report the cycle of each received packet to userspace like rawiso does,
this same enhancement was forgotten to add to the iso transmission ABI,
causing FFADO to fail to set up and maintain streaming.
Since kernel commit 31769cef2e973544164aa7d0db2e2024660d5e21, we also
get iso xmit cycles in fw_cdev_event_iso_interrupt.header. Pass these
to the iso receive handler. In case of older kernels, calculate cycles
based on the cycle of the iso interrupt event. These are inaccurate but
better than nothing.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (changelog, whitespace)
libraw1394 takes a negative IRQ interval to mean "every 256 packets"
with the juju backend, which doesn't work well if you don't queue that
many. Use buf_packets / 4 like the ieee1394 version.
Signed-off-by: Jay Fenlason <fenlason@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (order, comment)
Date: Sun, 14 Jun 2009 11:51:33 +0100
From: Mike Auty <mike.auty@gmail.com>
Subject: [patch libraw1394-2] src/makefile.am expects FW_DIR to be set,
but configure only sets it if given --with-fw-dir
Here's a very small patch for the configure system of
libraw1394-2.0.{0,1,2}. At the moment, if configure is called without
--with-fw-dir, then FW_DIR doesn't get specified. The Makefile includes
the line INCLUDES=-I$(FW_DIR) and so in the compilation we get a -I not
followed by anything sensible. That can cause compilation issues in
certain circumstances (see Gentoo bug 272540), so this patch ensures
that INCLUDES is only set if --with-fw-dir was specified.
Please let me know if there's any problems with the patch or if I've
submitted it to the wrong place or in the wrong way. Thanks...
Mike 5:)
[1] http://bugs.gentoo.org/272540
Signed-off-by: Dan Dennedy <dan@dennedy.org>
Previously, /dev/fw* and hence files like /dev/fwmonitor were probed
which may have bad effects if the client runs with access privileges.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This implements asynchronous streams on juju, i.e. enables
raw1394_async_stream() and raw1394_start_async_stream() to work
with the new firewire kernel stack.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
In the firewire-cdev ABI v1, the kernel exported only the timestamp
of interrupt packets. libraw1394 estimated the cycle of all packets
between interrupt packets by continuously incrementing the cycle.
In v2 of the ABI, we can obtain an accurate timestamp of each packet
as provided by the OHCI controller. AFAIU, this is also what you got
from raw1394/ ohci1394.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This allows raw1394_bandwidth_modify() and raw1394_channel_modify()
to work on juju without write access to the IRM's character device file.
If either the build-time requirement of firewire-cdev header ABI >= v.2
or the runtime requirement of firewire-core ABI >= v.2 is not satisfied,
the code falls back to transactions to the IRM as before.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Stefan Richter
Peter Hurley
Clemens Ladisch
Sebastian Schüppel
Dan Dennedy
Jay Fenlason