21 Jun, 2010

2 commits

  • The problem:

    A target-like userspace driver, e.g. AV/C target or SBP-2/3 target,
    needs to be able to act as responder and requester. In the latter role,
    it needs to send requests to nods from which it received requests. This
    is currently impossible because fw_cdev_event_request lacks information
    about sender node ID.
    Reported-by: Jay Fenlason

    Libffado + libraw1394 + firewire-core is currently unable to drive two
    or more audio devices on the same bus.
    Reported-by: Arnold Krille

    This is because libffado requires destination node ID of FCP requests
    and sender node ID of FCP responses to match. It even prohibits
    libffado from working with a bus on which libraw1394 opens a /dev/fw* as
    default ioctl device that does not correspond with the audio device.
    This is because libraw1394 does not receive the sender node ID from the
    kernel.

    Moreover, fw_cdev_event_request makes it impossible to tell unicast and
    broadcast write requests apart.

    The fix:

    Add a replacement of struct fw_cdev_event_request request, boringly
    called struct fw_cdev_event_request2. The new event will be sent to a
    userspace client instead of the old one if the client claims
    compatibility with ABI version 4 or later.

    libraw1394 needs to be extended to make use of the new event, in order
    to properly support libffado and other FCP or address range mapping
    users who require correct sender node IDs.

    Further notes:

    While we are at it, change back the range of possible values of
    fw_cdev_event_request.tcode to 0x0...0xb like in ABI version

    Stefan Richter
     
  • libraw1394 v2.0.0...v2.0.5 takes FW_CDEV_VERSION from an externally
    installed header file and uses it to declare its own implementation
    level in FW_CDEV_IOC_GET_INFO. This is wrong; it should set the real
    version for which it was actually written.

    If we add features to the kernel ABI that require the kernel to check
    a client's implementation level, we can not trust the client version if
    it was set from FW_CDEV_VERSION.

    Hence freeze FW_CDEV_VERSION at the current value (no damage has been
    done yet), clearly document FW_CDEV_VERSION as a dummy version and what
    clients are expected to do with fw_cdev_get_info.version, and use a new
    defined constant (which is not placed into the exported header file) as
    kernel implementation level.

    Note, in order to check in client program source code which features are
    present in an externally installed linux/firewire-cdev.h, use
    preprocessor directives like
    #ifdef FW_CDEV_IOC_ALLOCATE_ISO_RESOURCE
    or
    #ifdef FW_CDEV_EVENT_ISO_RESOURCE_ALLOCATED
    instead of a check of FW_CDEV_VERSION.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

10 Apr, 2010

2 commits


25 Feb, 2010

2 commits

  • so that clients can detect whether the FW_CDEV_IOC_GET_CYCLE_TIMER ioctl
    is reliable (on all tested controllers, especially the widely used VIA
    controllers, also NEC controllers, see commits b677532b and 1c1517ef).

    Also add a comment on the 2.6.32 iso xmit enhancement and on dual-buffer
    IR having been disabled in 2.6.33.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • The system time from CLOCK_REALTIME is not monotonic, hence problematic
    for the main user of the FW_CDEV_IOC_GET_CYCLE_TIMER ioctl. This issue
    exists in its successor ABI, i.e. raw1394, too.
    http://subversion.ffado.org/ticket/242

    We now offer an alternative ioctl which lets the caller choose between
    CLOCK_REALTIME, CLOCK_MONOTONIC, and CLOCK_MONOTONIC_RAW as source of
    the local time, very similar to the clock_gettime libc function. The
    format of the local time return value matches that of clock_gettime
    (seconds and nanoseconds, instead of a single microseconds value from
    the existing ioctl).

    Signed-off-by: Stefan Richter

    Stefan Richter
     

27 Jan, 2010

1 commit


30 Dec, 2009

1 commit

  • Control of more than one AV/C device at once --- e.g. camcorders, tape
    decks, audio devices, TV tuners --- failed or worked only unreliably,
    depending on driver implementation. This affected kernelspace and
    userspace drivers alike and was caused by firewire-core's inability to
    accept multiple registrations of FCP listeners.

    The fix allows multiple address handlers to be registered for the FCP
    command and response registers. When a request for these registers is
    received, all handlers are invoked, and the Firewire response is
    generated by the core and not by any handler.

    The cdev API does not change, i.e., userspace is still expected to send
    a response for FCP requests; this response is silently ignored.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Stefan Richter (changelog, rebased, whitespace)

    Clemens Ladisch
     

25 Mar, 2009

12 commits

  • This changes the as yet unreleased FW_CDEV_IOC_SEND_STREAM_PACKET ioctl
    to generate an fw_cdev_event_response event just like the other two
    ioctls for asynchronous request transmission do. This way, clients get
    feedback on successful or unsuccessful transmission.

    This also adds input validation for length, tag, channel, sy, speed.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • The access permissions and ownership or ACL of /dev/fw* character device
    files will typically be set based on the device type of the respective
    nodes, as obtained by firewire-core from descriptors in the device's
    configuration ROM. An example policy is to deny write permission by
    default but grant write permission to files of AV/C video and audio
    devices and IIDC video devices.

    The FW_CDEV_IOC_ADD_DESCRIPTOR ioctl could be used to partly subvert
    such a policy: Find a device file with relaxed permissions, use the
    ioctl to add a descriptor with AV/C marker to the local node's ROM, thus
    gain access to the local node's character device file. (This is only
    possible if there are udev scripts installed which actively relax
    permissions for known device types and if there is a device of such a
    type connected.)

    Accessibility of the local node's device file is relevant to host
    security if the host contains two or more IEEE 1394 link layer
    controllers which are plugged into a single bus.

    Therefore change the ABI to deny FW_CDEV_IOC_ADD_DESCRIPTOR if the file
    belongs to a remote node. (This change has no impact on known
    implementers of the ABI: None of them uses the ioctl yet.)

    Also clarify the documentation: The ioctl affects all local nodes, not
    just one local node.

    Cc: stable@kernel.org
    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • The as yet unreleased FW_CDEV_IOC_GET_SPEED ioctl puts only a single
    integer into the parameter buffer. We can use ioctl()'s return value
    instead.

    (Also: Some whitespace change in firewire-cdev.h.)

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • 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
    Signed-off-by: Stefan Richter (tweaks)

    Jay Fenlason
     
  • Some fixes:
    - Remove stale documentation.
    - Fix a != vs. == thinko that got in the way of channel management.
    - Try bandwidth deallocation even if channel deallocation failed.

    A simplification:
    - fw_cdev_allocate_iso_resource.channels is now ordered like
    libdc1394's dc1394_iso_allocate_channel() channels_allowed
    argument.

    By the way, I looked closer at cards from NEC, TI, and VIA, and noticed
    that they all don't implement IEEE 1394a behaviour which is meant to
    deviate from IEEE 1212's notion of lock compare-swap. This means that
    we have to do two lock transactions instead of one in many cases where
    one transaction would already succeed on a fully 1394a compliant IRM.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Necessary due to
    Date: Tue, 22 Jul 2008 23:23:40 -0700
    From: David Moore
    Subject: firewire: Include iso timestamp in headers when header_size > 4

    Side note: The lack of upwards compatibility sounds worse than it is.
    All existing client implementations, libraw1394 and libdc1394, set
    header_size = 4. And since the ABI v1 behaviour does not offer any
    advantages over the new behaviour, we deliberately do not provide the
    old behaviour anymore.

    Also add documentation about the format of fw_cdev_get_cycle_timer which
    may be used in conjunction with the timestamp of iso packets but has a
    different format.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Write transactions to the broadcast node ID are a convenient way to
    trigger functions of multiple nodes at once. IIDC is a protocol which
    can make use of this if multiple cameras with same command_regs_base are
    connected at the same bus.

    Based on
    Date: Wed, 10 Sep 2008 11:32:16 -0400
    From: Jay Fenlason
    Subject: [patch] SEND_BROADCAST_REQUEST
    Changes: ioctl_send_request() and ioctl_send_broadcast_request() now
    share code. Broadcast speed corrected to S100. Check for proper tcode.

    Signed-off-by: Stefan Richter

    Jay Fenlason, Stefan Richter
     
  • While the speed of asynchronous transactions is automatically chosen by
    the kernel, the speed of isochronous streams has to be chosen by the
    initiating client.

    In case of 1394a bus topologies, the maximum possible speed could be
    figured out with some effort by evaluation of the remote node's link
    speed field in the config ROM, the local node's link speed field, and
    the PHY speeds and topologic information in the local node's or IRM's
    topology map CSR. However, this does not work in case of 1394b buses.

    Hence add an ioctl to export the maximum speed which the kernel already
    determined.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • This adds ioctls for allocation and deallocation of a channel or/and
    bandwidth without auto-reallocation and without auto-deallocation.

    The benefit of these ioctls is that libraw1394-style isochronous
    resource management can be implemented without write access to the IRM's
    character device file.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Based on
    Date: Tue, 18 Nov 2008 11:41:27 -0500
    From: Jay Fenlason
    Subject: [Patch V4] Add ISO resource management support
    with several changes to the ABI and implementation. Only the part of
    the ABI which enables auto-reallocation and auto-deallocation is
    included here.

    This implements ioctls for kernel-assisted allocation of isochronous
    channels and isochronous bandwidth. The benefits are:
    - The client does not have to have write access to the /dev/fw* device
    corresponding to the IRM.
    - The client does not have to perform reallocation after bus resets.
    - Channel and bandwidth are deallocated by the kernel if the file is
    closed before the client deallocated the resources. Thus resources
    are released even if the client crashes.

    It is anticipated that future in-kernel code (firewire-core IRM code;
    the firewire port of firedtv), will use the fw-iso.c portions of this
    code too.

    Signed-off-by: Stefan Richter
    Tested-by: David Moore

    Jay Fenlason, Stefan Richter
     
  • The FW_CDEV_IOC_GET_INFO ioctl looks at client->device->config_rom, not
    at the local node's config ROM.

    We could fix the implementation or the documentation. I believe the way
    how it is currently implemented is more useful than the way how it is
    currently documented. In fact, libdc1394 uses the ABI already as
    implemented, not as documented. Hence let's change the documentation.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Reported-by: Jay Fenlason
    Signed-off-by: Stefan Richter

    Stefan Richter
     

16 Oct, 2008

1 commit


17 Oct, 2007

1 commit


10 Jul, 2007

1 commit


01 Jun, 2007

1 commit


11 May, 2007

2 commits


01 May, 2007

1 commit