To Do

From IEEE 1394 FireWire Wiki
Revision as of 10:46, 8 August 2010 by Stefanr (Talk | contribs)

Jump to: navigation, search

Linux1394 Project TODO List

This page is targeted towards users (to see which things don't work yet) as well as to developers (to pick a project which caught their interest). People new to FireWire low-level development may find our lists of specifications and books useful. Almost all FireWire related specifications are open, some of them even gratis.

See also our list of bugs at bugzilla.kernel.org for a whole lot of TODO items. There are also bugs filed in distributors' bug trackers but they are not as easy to query.


Contents


FireWire subsystem (a.k.a. Juju driver stack)

Documentation

  • Userspace programming documentation (for "plumbing layer" and application layer programming):
    • Add linux/Documentation/ABI/stable/sysfs-bus-firewire with reference documentation of firewire-core's sysfs interface.
    • Add linux/Documentation/ABI/stable/dev-fw (or however it should be called) with a summary description of firewire-core's character device file interface and a pointer to <linux/firewire-cdev.h>'s inline documentation.
    • Write some overview documentation of firewire-core's character device file interface: How to use ioctl, read, (e)poll, mmap; how ioctls and read events are paired; relationship between various ioctls and events to single nodes or a single bus or all buses; how to perform a few common tasks...
  • Kernel programming documentation:
    • Finish kerneldoc comments of all exported functions and struct types that are part of the firewire-core APIs?
    • Add a template to linux/Documentation/DocBook to pull firewire-core's kerneldoc comments in? Ideally, arrange the documentation in chapters for the userspace API, high-level API, and low-level API.
  • Usage documentation:
    • Add documentation for individual drivers on this wiki? See Special:Wantedpages.
    • Derive documentation suitable for distribution with the mainline kernel sources, i.e. linux/Documentation/...?

support in userspace

  • libraw1394: Fix handling of device removal.
  • Add <linux/firewire-cdev.h> support in FFmpeg's libavformat?
  • Add <linux/firewire-cdev.h> support in libdc1394 v1?

firewire-core

  • Implement proper FCP register support: Allow multiple clients to register for listening to FCP_COMMAND and FCP_RESPONSE. Multiplex incoming FCP frames to all listeners. This is required to use more than one AV/C device on a bus at a time. — Merged in Linux 2.6.33-rc3.
  • Design and implement an FCP transactions serializing infrastructure? See this posting for requirements.
  • Fedora bug 449252: A Panasonic AG-DV 2500 tape deck is not recognized, perhaps due to an issue with unexpected config ROM contents. — Fixed in Linux 2.6.34-rc1.
  • Finish the transaction layer:
    • The transaction timeout should be counted from the time when the request hit the bus, not from the time when the request was handed over from upper layers to fw-core.
    • The transaction timeout should be taken from the SPLIT_TIMEOUT CSRs.Queued for Linux 2.6.36-rc1.
    • These CSRs need to be writable from the bus. This is needed to extend the transaction timeout for some audio devices whose chipset becomes laggy when mixing lots of channels.Queued for Linux 2.6.36-rc1.
  • CSR registers required by the specification:
    • STATE_CLEAR/STATE_SET
      • state, dreq dropped in IEEE1212:2001
      • cmstrQueued for Linux 2.6.36-rc1.
      • abdicateQueued for Linux 2.6.36-rc1.
    • NODE_IDS: This allows to change the bus ID. The OHCI driver must check for both "local bus" and the actual bus IDs to detect local packets, and has to send the actual bus ID in AT packets' source field, when appropriate.Queued for Linux 2.6.36-rc1.
    • RESET_START (irrelevant to the function of Linux nodes)
    • SPLIT_TIMEOUT, see transaction layer related to-do item.Queued for Linux 2.6.36-rc1.
    • BUS_TIMEQueued for Linux 2.6.36-rc1.
    • BUSY_TIMEOUTQueued for Linux 2.6.36-rc1.
    • PRIORITY_BUDGETQueued for Linux 2.6.36-rc1.
  • Isochronous resource manager responsibilities:
    • Automatically reserve channel 31 for broadcasts. — Was already implemented in software. Hardware assistance by OHCI 1.1 controllers queued for Linux 2.6.36-rc1.
    • Set BROADCAST_CHANNEL on all nodes. — Implemented. (We do not write BROADCAST_CHANNEL on nodes that do not need or support it. Some 1394-1995 firmwares crash when BROADCAST_CHANNEL is written.)
    • Force a better node to become root if the current IRM does not support 1394a. Also required due to a firmware bug of certain camcorders.Merged in Linux 2.6.35-rc3. Also in 2.6.34.1, 2.6.33.6, 2.6.32.16.
  • Bus manager responsibilities:
    • Force a cycle-master-capable node to be root (already implemented) and set its cmstr bit.Queued for Linux 2.6.36-rc1.
    • Set SPLIT_TIMEOUT to the same value on all nodes.
    • Initialize BUS_TIME to the same value on all nodes.
    • Set PRIORITY_BUDGET on all nodes.
    • Implement gap count optimization based on round-trip delay measurement alternatively to the present hop count table based gap count optimization. The latter cannot be used if 1394b repeater nodes are present. (The algorithm for this is patented and not included in the 1394 Patent Portfolio License.)
    • Power management: Clear the linkoff bit and/or send link_on to disabled nodes if there is enough power. (It is impossible to determine whether there is enough power since too many devices and PCs provide wrong power class information.)

firewire-ohci

  • Move all (or as much as possible) of the isochronous receive and transmit context tasklets into the IRQ handler. This is most desirable for low latency as required for audio I/O. Note, such a change may also affect other drivers. It may for example be necessary to add a tasklet to firewire-net for ARP/ broadcast/ multicast reception.
  • Bug 10935: ALi controllers don't work yet.
  • Fedora bug 228073: Apple UniNorth v1 built-in controllers do not seem to fully work.
  • Bug 8828, Fedora bug 244576: Come up with a quirk fix for NForce2. The person to do so will most certainly require direct access to this hardware. Note, the NForce2 workaround in ohci1394 is unacceptable by today's standards as it involves busy-waiting in the interrupt handler. Either we find something better for firewire-ohci, or NForce2 remains unsupported in firewire-ohci.
  • Fedora bug 492718 comments 5 and 6: Implement a workaround for Texas Instruments' erratum SLLZ012, "Errata for the 1394 Physical Layer Devices"?
  • Fedora bug 608544: Handle IntEvent.regAccessFail at least in ohci_enable().

firewire-sbp2

  • Concurrency-managed workqueues have been merged into the mainline. Make use of them so that login, inquiry, and reconnects of different targets (or even different logical units?) are parallelized. The present single-threaded workqueue of firewire-sbp2 is only a compromise to avoid the creation of lots of kernel threads that are idle most of the time. If parallelism of management requests to different logical units on the same target work with multi-LUN devices that are available for testing, then firewire-sbp2 should simply queue everything into system_nrt_wq.
  • Implement dynamically appended ORB lists for performance improvement. Note, the old sbp2 driver's implementation of ORB lists is very buggy (default: off) but nevertheless results in better throughput with some hardware combinations.
  • Implement SBP-3 FASTSTART protocol which is rumored to be supported by newer OxSemi bridges and INIC-2430. — None of my (Stefan R.'s) OxSemi 912/ 924/ 934/ 936 or Initio 2430 based devices' firmwares offer FASTSTART support. It seems too rare to justify to add it to the driver.
  • Implement operation without physical DMA.
  • Implement hand-over from OpenFirmware login. When an Apple PC boots from a FireWire disk, the OpenFirmware is already logged in but does apparently not log out after it loaded the kernel image. When then the kernel's firewire-sbp2 (or sbp2, for that matter) logs in, the target may deny access. This has been observed with Momobay CX-1. The old ieee1394 driver stack somehow overcomes this because of timing subtleties, but firewire-sbp2 ends up with failed login due to denied access.
  • Bug 3225: Integrate with scsi_wait_scan module?

firewire-net

  • Stabilize.
  • Implement IPv6 support as per RFC 3146.

firedtv

  • Implement tuning of HD channels on DVB-S2 devices. (user forum thread, developer list thread)
  • Make it work with firewire alternatively to ieee1394. Merged in Linux 2.6.33-rc1.
  • Use firewire-core's channel and bandwidth allocation function in firedtv for proper cooperation with non-FireDTV AV/C devices on the same bus.

New drivers

  • Implement an audio i/o driver to enable FFADO to run smoother with less effort. There was a Google Summer of Code project registered for it which produced some initial results. — There is also a driver in the works by Clemens Ladisch.
  • Implement a V4L2 driver which exposes DV and HDV devices (IEC 61883-2...-4 camcorders, tapes, analogue tuners, TV sets) as /dev/video* devices? This has been suggested in order to offer an interface that is supported by a broad variety of multimedia application programs.
  • Implement an SBP-2 target using the in-kernel SCSI target framework as an alternative to Endpoint (Oracle's SBP-2 target implementation in userspace).
  • ohci1394_earlyinit: Add support for more architectures besides x86-64. Add interrupt handling to re-enable physical DMA after bus reset. Add hand-over of interrupt handling from ohci1394_earlyinit to firewire-ohci.


IEEE1394 Subsystem (a.k.a. Linux1394 driver stack)

The new FireWire subsystem in Linux 2.6.22+ (linux/drivers/firewire) is meant to replace the old IEEE 1394 subsystem (linux/drivers/ieee1394). New development, bug fixing, and even janitorial work should therefore concentrate on the new subsystem.

There is a meta-bug in kernel.org's bugzilla which tracks items on which nobody is working anymore because these bugs don't exist in the new firewire drivers or should be fixed in them. Anybody who nevertheless wants to fix any of those superseded issues is of course welcome to do so, if it can be done with low risk of regressions.

Personal tools