| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The drivers
- ohci1394 (controller driver)
- ieee1394 (core)
- dv1394, raw1394, video1394 (userspace ABI)
- eth1394, sbp2 (protocol drivers)
are replaced by
- firewire-ohci (controller driver)
- firewire-core (core and userspace ABI)
- firewire-net, firewire-sbp2 (protocol drivers)
which are more featureful, better performing, and more secure than the older
drivers; all with a smaller and more modern code base.
The driver firedtv in drivers/media/dvb/firewire/ contains backends to both
ieee1394 and firewire-core. Its ieee1394 backend code can be removed in an
independent commit; firedtv as-is builds and works fine without ieee1394.
The driver pcilynx (an incomplete controller driver) is deleted without
replacement since PCILynx cards are extremely rare. Owners of these cards
use them with the stand-alone bus sniffer driver nosy instead.
The drivers nosy and init_ohci1394_dma which do not interact with either of
the two IEEE 1394 stacks are not affected by the ieee1394 subsystem removal.
There are still some issues with the newer firewire subsystem compared to
the older one:
- The rare and quirky controllers ALi M52xx, Apple UniNorth v1, NVIDIA
NForce2 are even less well supported by firewire-ohci than by ohci1394.
I am looking into the M52xx issue.
- The experimental firewire-net is reportedly less stable than its
experimental cousin eth1394.
- Audio playback of a certain group of audio devices (ones based on DICE
chipset with EAP; supported by prerelease FFADO code) does not work yet.
This issue is still under investigation.
- There were some ieee1394 based out-of-the-mainline drivers. Of them,
only lisight, an audio driver for iSight webcams, seems still useful.
Work is underway to reimplement it on top of firewire-core.
All these remainig issues are minor; they should not stand in the way of
overall better user experience of IEEE 1394 on Linux, together with a
reduction in support efforts and maintenance burden. The coexistence of two
IEEE 1394 kernel driver stacks in the mainline since 2.6.22 shall end now,
as announced earlier this year.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the simultaneous read of the isochronous cycle timer and
the system clock (in usecs). This allows to express the exact receive
time of an ISO packet as a system time with microsecond accuracy.
http://bugzilla.kernel.org/show_bug.cgi?id=7773
The counterpart patch for libraw1394 can be found at
http://thread.gmane.org/gmane.linux.kernel.firewire.devel/8934
Patch update (Stefan R.): Disable preemption and local interrupts.
Prevent integer overflow. Add paranoid error checks and kerneldoc to
hpsb_read_cycle_timer. Move it to other ieee1394_core high-level API
functions. Change comments. Adjust whitespace. Rename struct
_raw1394_cycle_timer.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Acked-by: Pieter Palmers <pieterp@joow.be>
Acked-by: Dan Dennedy <dan@dennedy.org>
|
| |
|
|
|
|
|
|
|
| |
Adjust tabulators, line wraps, empty lines, and comment style.
Update comments in ieee1394_transactions.h and highlevel.h.
Fix typo in comment in csr.h.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Ben Collins <bcollins@ubuntu.com>
|
| |
|
|
|
|
|
|
|
|
| |
Remove the Audio and Music Data Transmission Protocol driver and the
Connection Management Procedures driver. These are incomplete, have never
worked, and are better implemented in userland via raw1394 (see
http://freebob.sourceforge.net/ for example.)
Signed-off-by: Jody McIntyre <scjody@steamballoon.com>
Cc: Adrian Bunk <bunk@stusta.de>
|
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
