Instead of allocating memory for address range mappings (ARM) and handling all
reads and writes to said memory, the new ARM manager calls a function for each
received request with the data, transaction code, and allocation information.
The ARM tag manager now must handle validation of memory accesses and
retreive/write the data. This allows implementations to use network resources
or generated data as memory.
The ARM manager no longer automatically sends response packets. It is the
responsibility of the user to send response packets using
raw1394_send_rw_response().
The interface is not implemented for raw1394 and will probably never be
implemented for raw1394. It is for firewire-cdev (modern Linux) only.
The __uint32_t type is not a standard type, and not necessarily
provided by all C libraries. However, <stdint.h> provides a set of
standard types, which are guaranteed to be available with all C
libraries.
This patch therefore changes __uint32_t to uint32_t, which allows to
fix the compilation with the Musl C library.
This patch is already used by the Alpine Linux distribution and the
Buildroot build system.
Original patch from
http://git.alpinelinux.org/cgit/aports/plain/main/libraw1394/fix-types.patch.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Align fw_handle buffer for 64-bit access. This fixes SIGBUS on SPARC
when capturing DV stream with "dvgrab".
[Stefan R: If libraw1394 is compiled for 32 bit userland, struct
fw_handle.buffer was only 32 bit aligned. Various *__u64 accesses
happen to the buffer, and those accesses require 64 bit alignment on
some CPU architectures. The bug certainly affected all libraw1394
client applications on such architectures with 32 bit userland.]
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This lets initiators of isochronous streams or asynchronous streams from
or to the local node figure out what maximum speed can be configured.
Furthermore it can be used to display connection speeds for informative
purposes without having to perform topology analysis (in case of 1394a
buses) or extensive phy port status queries (in case of 1394b buses).
To be in line with other existing libraw1394 APIs which use nodeid_t
variables, this API identifies a node only via a card:nodeID tuple which
is unsafe against generation changes. A node can only be properly
identified by card:generation:nodeID tuples. However, since this new
API extension and libraw1394 as a whole is mainly aimed towards existing
libraw1394 client code bases rather than new developments, I decided
against making this call race free but somewhat more difficult to use in
typical existing client code.
A unit test for the new call is added to testlibraw as well.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This is an extension relative to raw1394_read_cycle_timer().
It lets the client choose a system clock other than CLOCK_REALTIME.
Use case: http://subversion.ffado.org/ticket/242
The underlying ioctl supports reading the system clock with nanoseconds
resolution. The new libraw1394 call sticks with microseconds resolution
though. This makes transition from (or parallel use with)
raw1394_read_cycle_timer() easier. Besides, the call itself takes longer
than a microsecond, primarily due to a costly MMIO read (on many
controllers even three or more MMIO reads).
Unit tests with CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW are added to
testlibraw as well.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
To conform with 'size' arguments of other libraw1394 calls, change the one in
raw1394_add_config_rom_descriptor() from quadlets to bytes. This breaks runtime
compatibility with potential clients that were written against B.J.'s original
patch, hence reorder arguments just to break compatibility also at compile time.
Change errno to ENOSYS (function not implemented) when called while running on
top of raw1394.
Allow &token to be NULL for convenience of clients which don't require
raw1394_remove_config_rom_descriptor().
Add exhaustive documentation. Much of it is copied from the documentation of
the underlying ioctl.
Add example code which doubles as unit test in testlibraw.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
This adds support of the firewire-core (juju) ABI to add and remove config ROM directories
or descriptors. The raw1394 ABI supports similar requests, but for now we leave the two
functions unimplemented when running on top of raw1394.
Signed-off-by: Benjamin Buchalter <bj@mhlabs.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> (whitespace changes)
This guarantees that all features of libraw1394 are actually built in.
Before, some features and fixes would be silently dropped if too old
system headers (typically provided by a package called linux-headers)
were present.
An alternative would be to keep using system headers but add warnings
during the ./configure stage if old headers were encountered. But this
helps only the person who builds libraw1394 (if there is a person
involved at all), not the users who have no reliable way to determine
how the library binary was built.
Another alternative would be to change the former soft dependency on
certain linux-headers versions into a hard dependency, i.e. fail the
build in absence of too old headers. This would add an inconvenience
in setting up the build environment though: The system headers would
have to be updated or a private copy of linux/firewire-*.h be specified
by way of the --with-fw-dir configure switch.
Anyhow. The libraw1394 sources now already bring a suitable copy of
the two header files. The --with-fw-dir configure switch is no longer
useful and is removed.
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>
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>
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>
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>
On 10 Jan, David Moore wrote:
> On Sat, 2009-01-10 at 19:28 +0100, Stefan Richter wrote:
>> @@ -161,14 +160,16 @@ scan_devices(fw_handle_t handle)
...
>> + for (j = 0; j < i; j++)
>> + if (ports[j].card == get_info.card)
>> + continue;
>> +
>
> That continue statement doesn't do what you intended I think.
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Subject: [PATCH] Work without permission to access local node's /dev/fw*
Fix for juju backend:
libraw1394 required write permission to the character device file of
the local node(s) in order to enumerate cards and for a number of
other operations. This forced users to either run applications like
dvgrab and kino with elevated privileges, or to configure write
permission for all /dev/fw* or at least for local nodes' /dev/fw*.
We now use the first accessible file which was found for each card
for as many tasks as possible, instead of the local node's file.
This allows distributors or admins to implement stricter access
rights (default off, e.g. only on for AV/C and IIDC devices)
without sacrificing functionality of said class of applications.
Access to the local node is now only required by low-level tools
like gscanbus.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
Make iso start/stop/start sequences on the same handle, such as those used
by apps such as MythTV behave as expected. I can finally watch video off my
cable box over FireWire using MythTV w/the juju stack now. :)
Initially, seemed a one-liner might be the ticket (setting handle->iso.fd = -1
at the end of fw_iso_shutdown()), but that led to memory corruption and a
locked up system. What ultimately worked was essentially mimicking what the
old stack did to track iso state, and call fw_iso_stop() from
fw_iso_shutdown() as needed.
Nb: Only lightly tested with iso receive via MythTV, but its all fairly
straight-forward, I think.
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
because they do the same.
We only may want a separate fw_bandwidth_modify() in the future when
firewire-core gains a special ioctl() for that.
(Not runtime-tested, but it looks good to me.)
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
(juju)
Reported by Adrian Knoth: fw_channel_modify() was unable to allocate
some channels which were actually free.
http://marc.info/?l=linux1394-devel&t=122818128900002
This can be easily fixed by replacing fw_channel_modify() by
ieee1394_channel_modify() because this is highlevel enough to work with
Juju as well. We only may want a separate fw_channel_modify() in the
future when firewire-core gains a special ioctl() for that.
Also fix a documentation typo: raw1394_channel_modify() did not show up
in extracted API documentation due to a cut'n'paste typo in raw1394.h.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Dan Dennedy <dan@dennedy.org>
The ieee1394 version of raw1394_read_cycle_timer() fell over the cliff
in "First cut at integrating juju". This brings it back and adds a juju
version of it.
Also correct a typo in the inline documentation: s/get/read/
Peter McGoron
Thomas Petazzoni
Aaro Koskinen
Stefan Richter
B.J. Buchalter
Dan Dennedy
Jarod Wilson
Dan Dennedy