Linux-2.6.12-rc2v2.6.12-rc2

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!

48 files changed, 39925 insertions, 0 deletions

diff --git a/drivers/ieee1394/Kconfig b/drivers/ieee1394/Kconfig
new file mode 100644
index 00000000000..78b201fb5e8
--- /dev/null
+++ b/drivers/ieee1394/Kconfig
@@ -0,0 +1,188 @@
+# -*- shell-script -*-
+
+menu "IEEE 1394 (FireWire) support"
+
+config IEEE1394
+	tristate "IEEE 1394 (FireWire) support"
+	depends on PCI || BROKEN
+	select NET
+	help
+	  IEEE 1394 describes a high performance serial bus, which is also
+	  known as FireWire(tm) or i.Link(tm) and is used for connecting all
+	  sorts of devices (most notably digital video cameras) to your
+	  computer.
+
+	  If you have FireWire hardware and want to use it, say Y here.  This
+	  is the core support only, you will also need to select a driver for
+	  your IEEE 1394 adapter.
+
+	  To compile this driver as a module, say M here: the
+	  module will be called ieee1394.
+
+comment "Subsystem Options"
+	depends on IEEE1394
+
+config IEEE1394_VERBOSEDEBUG
+	bool "Excessive debugging output"
+	depends on IEEE1394
+	help
+	  If you say Y here, you will get very verbose debugging logs from
+	  the subsystem which includes a dump of the header of every sent
+	  and received packet.  This can amount to a high amount of data
+	  collected in a very short time which is usually also saved to
+	  disk by the system logging daemons.
+
+	  Say Y if you really want or need the debugging output, everyone
+	  else says N.
+
+config IEEE1394_OUI_DB
+	bool "OUI Database built-in"
+	depends on IEEE1394
+	help
+	  If you say Y here, then an OUI list (vendor unique ID's) will be
+	  compiled into the ieee1394 module. This doesn't really do much
+	  except being able to display the vendor of a hardware node. The
+	  downside is that it adds about 300k to the size of the module,
+	  or kernel (depending on whether you compile ieee1394 as a
+	  module, or static in the kernel).
+
+	  This option is not needed for userspace programs like gscanbus
+	  to show this information.
+
+config IEEE1394_EXTRA_CONFIG_ROMS
+	bool "Build in extra config rom entries for certain functionality"
+	depends on IEEE1394
+	help
+	  Some IEEE1394 functionality depends on extra config rom entries
+	  being available in the host adapters CSR. These options will
+	  allow you to choose which ones.
+
+config IEEE1394_CONFIG_ROM_IP1394
+	bool "IP-1394 Entry"
+	depends on IEEE1394_EXTRA_CONFIG_ROMS && IEEE1394
+	help
+	  Adds an entry for using IP-over-1394. If you want to use your
+	  IEEE1394 bus as a network for IP systems (including interacting
+	  with MacOSX and WinXP IP-over-1394), enable this option and the
+	  eth1394 option below.
+
+comment "Device Drivers"
+	depends on IEEE1394
+
+comment "Texas Instruments PCILynx requires I2C"
+	depends on IEEE1394 && I2C=n
+
+config IEEE1394_PCILYNX
+	tristate "Texas Instruments PCILynx support"
+	depends on PCI && IEEE1394 && I2C
+	select I2C_ALGOBIT
+	help
+	  Say Y here if you have an IEEE-1394 controller with the Texas
+	  Instruments PCILynx chip.  Note: this driver is written for revision
+	  2 of this chip and may not work with revision 0.
+
+	  To compile this driver as a module, say M here: the
+	  module will be called pcilynx.
+
+# Non-maintained pcilynx options
+# if [ "$CONFIG_IEEE1394_PCILYNX" != "n" ]; then
+#     bool '    Use PCILynx local RAM' CONFIG_IEEE1394_PCILYNX_LOCALRAM
+#     bool '    Support for non-IEEE1394 local ports' CONFIG_IEEE1394_PCILYNX_PORTS
+# fi
+config IEEE1394_OHCI1394
+	tristate "OHCI-1394 support"
+	depends on PCI && IEEE1394
+	help
+	  Enable this driver if you have an IEEE 1394 controller based on the
+	  OHCI-1394 specification. The current driver is only tested with OHCI
+	  chipsets made by Texas Instruments and NEC. Most third-party vendors
+	  use one of these chipsets.  It should work with any OHCI-1394
+	  compliant card, however.
+
+	  To compile this driver as a module, say M here: the
+	  module will be called ohci1394.
+
+comment "Protocol Drivers"
+	depends on IEEE1394
+
+config IEEE1394_VIDEO1394
+	tristate "OHCI-1394 Video support"
+	depends on IEEE1394 && IEEE1394_OHCI1394
+	help
+	  This option enables video device usage for OHCI-1394 cards.  Enable
+	  this option only if you have an IEEE 1394 video device connected to
+	  an OHCI-1394 card.
+
+config IEEE1394_SBP2
+	tristate "SBP-2 support (Harddisks etc.)"
+	depends on IEEE1394 && SCSI && (PCI || BROKEN)
+	help
+	  This option enables you to use SBP-2 devices connected to your IEEE
+	  1394 bus.  SBP-2 devices include harddrives and DVD devices.
+
+config IEEE1394_SBP2_PHYS_DMA
+	bool "Enable Phys DMA support for SBP2 (Debug)"
+	depends on IEEE1394 && IEEE1394_SBP2
+
+config IEEE1394_ETH1394
+	tristate "Ethernet over 1394"
+	depends on IEEE1394 && EXPERIMENTAL && INET
+	select IEEE1394_CONFIG_ROM_IP1394
+	select IEEE1394_EXTRA_CONFIG_ROMS
+	help
+	  This driver implements a functional majority of RFC 2734: IPv4 over
+	  1394.  It will provide IP connectivity with implementations of RFC
+	  2734 found on other operating systems.  It will not communicate with
+	  older versions of this driver found in stock kernels prior to 2.6.3.
+	  This driver is still considered experimental.  It does not yet support
+	  MCAP, therefore multicast support is significantly limited.
+
+config IEEE1394_DV1394
+	tristate "OHCI-DV I/O support"
+	depends on IEEE1394 && IEEE1394_OHCI1394
+	help
+	  This driver allows you to transmit and receive DV (digital video)
+	  streams on an OHCI-1394 card using a simple frame-oriented
+	  interface.
+
+	  The user-space API for dv1394 is documented in dv1394.h.
+
+	  To compile this driver as a module, say M here: the
+	  module will be called dv1394.
+
+config IEEE1394_RAWIO
+	tristate "Raw IEEE1394 I/O support"
+	depends on IEEE1394
+	help
+	  Say Y here if you want support for the raw device. This is generally
+	  a good idea, so you should say Y here. The raw device enables
+	  direct communication of user programs with the IEEE 1394 bus and
+	  thus with the attached peripherals.
+
+	  To compile this driver as a module, say M here: the
+	  module will be called raw1394.
+
+config IEEE1394_CMP
+	tristate "IEC61883-1 Plug support"
+	depends on IEEE1394
+	help
+	  This option enables the Connection Management Procedures
+	  (IEC61883-1) driver, which implements input and output plugs.
+
+	  To compile this driver as a module, say M here: the
+	  module will be called cmp.
+
+config IEEE1394_AMDTP
+	tristate "IEC61883-6 (Audio transmission) support"
+	depends on IEEE1394 && IEEE1394_OHCI1394 && IEEE1394_CMP
+	help
+	  This option enables the Audio & Music Data Transmission Protocol
+	  (IEC61883-6) driver, which implements audio transmission over
+	  IEEE1394.
+
+	  The userspace interface is documented in amdtp.h.
+
+	  To compile this driver as a module, say M here: the
+	  module will be called amdtp.
+
+endmenu
diff --git a/drivers/ieee1394/Makefile b/drivers/ieee1394/Makefile
new file mode 100644
index 00000000000..e8b4d48d376
--- /dev/null
+++ b/drivers/ieee1394/Makefile
@@ -0,0 +1,26 @@
+#
+# Makefile for the Linux IEEE 1394 implementation
+#
+
+ieee1394-objs := ieee1394_core.o ieee1394_transactions.o hosts.o \
+		 highlevel.o csr.o nodemgr.o oui.o dma.o iso.o \
+		 csr1212.o config_roms.o
+
+obj-$(CONFIG_IEEE1394) += ieee1394.o
+obj-$(CONFIG_IEEE1394_PCILYNX) += pcilynx.o
+obj-$(CONFIG_IEEE1394_OHCI1394) += ohci1394.o
+obj-$(CONFIG_IEEE1394_VIDEO1394) += video1394.o
+obj-$(CONFIG_IEEE1394_RAWIO) += raw1394.o
+obj-$(CONFIG_IEEE1394_SBP2) += sbp2.o
+obj-$(CONFIG_IEEE1394_DV1394) += dv1394.o
+obj-$(CONFIG_IEEE1394_ETH1394) += eth1394.o
+obj-$(CONFIG_IEEE1394_AMDTP) += amdtp.o
+obj-$(CONFIG_IEEE1394_CMP) += cmp.o
+
+quiet_cmd_oui2c = OUI2C   $@
+      cmd_oui2c = $(CONFIG_SHELL) $(srctree)/$(src)/oui2c.sh < $< > $@
+
+targets := oui.c
+$(obj)/oui.o: $(obj)/oui.c
+$(obj)/oui.c: $(src)/oui.db $(src)/oui2c.sh FORCE
+	$(call if_changed,oui2c)
diff --git a/drivers/ieee1394/amdtp.c b/drivers/ieee1394/amdtp.c
new file mode 100644
index 00000000000..84ae027b021
--- /dev/null
+++ b/drivers/ieee1394/amdtp.c
@@ -0,0 +1,1300 @@
+/* -*- c-basic-offset: 8 -*-
+ *
+ * amdtp.c - Audio and Music Data Transmission Protocol Driver
+ * Copyright (C) 2001 Kristian Høgsberg
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+
+/* OVERVIEW
+ * --------
+ *
+ * The AMDTP driver is designed to expose the IEEE1394 bus as a
+ * regular OSS soundcard, i.e. you can link /dev/dsp to /dev/amdtp and
+ * then your favourite MP3 player, game or whatever sound program will
+ * output to an IEEE1394 isochronous channel.  The signal destination
+ * could be a set of IEEE1394 loudspeakers (if and when such things
+ * become available) or an amplifier with IEEE1394 input (like the
+ * Sony STR-LSA1).  The driver only handles the actual streaming, some
+ * connection management is also required for this to actually work.
+ * That is outside the scope of this driver, and furthermore it is not
+ * really standardized yet.
+ *
+ * The Audio and Music Data Tranmission Protocol is available at
+ *
+ *     http://www.1394ta.org/Download/Technology/Specifications/2001/AM20Final-jf2.pdf
+ *
+ *
+ * TODO
+ * ----
+ *
+ * - We should be able to change input sample format between LE/BE, as
+ *   we already shift the bytes around when we construct the iso
+ *   packets.
+ *
+ * - Fix DMA stop after bus reset!
+ *
+ * - Clean up iso context handling in ohci1394.
+ *
+ *
+ * MAYBE TODO
+ * ----------
+ *
+ * - Receive data for local playback or recording.  Playback requires
+ *   soft syncing with the sound card.
+ *
+ * - Signal processing, i.e. receive packets, do some processing, and
+ *   transmit them again using the same packet structure and timestamps
+ *   offset by processing time.
+ *
+ * - Maybe make an ALSA interface, that is, create a file_ops
+ *   implementation that recognizes ALSA ioctls and uses defaults for
+ *   things that can't be controlled through ALSA (iso channel).
+ *
+ *   Changes:
+ *
+ * - Audit copy_from_user in amdtp_write.
+ *                           Daniele Bellucci <bellucda@tiscali.it>
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/list.h>
+#include <linux/sched.h>
+#include <linux/types.h>
+#include <linux/fs.h>
+#include <linux/ioctl.h>
+#include <linux/wait.h>
+#include <linux/pci.h>
+#include <linux/interrupt.h>
+#include <linux/poll.h>
+#include <linux/ioctl32.h>
+#include <linux/compat.h>
+#include <linux/cdev.h>
+#include <asm/uaccess.h>
+#include <asm/atomic.h>
+
+#include "hosts.h"
+#include "highlevel.h"
+#include "ieee1394.h"
+#include "ieee1394_core.h"
+#include "ohci1394.h"
+
+#include "amdtp.h"
+#include "cmp.h"
+
+#define FMT_AMDTP 0x10
+#define FDF_AM824 0x00
+#define FDF_SFC_32KHZ   0x00
+#define FDF_SFC_44K1HZ  0x01
+#define FDF_SFC_48KHZ   0x02
+#define FDF_SFC_88K2HZ  0x03
+#define FDF_SFC_96KHZ   0x04
+#define FDF_SFC_176K4HZ 0x05
+#define FDF_SFC_192KHZ  0x06
+
+struct descriptor_block {
+	struct output_more_immediate {
+		u32 control;
+		u32 pad0;
+		u32 skip;
+		u32 pad1;
+		u32 header[4];
+	} header_desc;
+
+	struct output_last {
+		u32 control;
+		u32 data_address;
+		u32 branch;
+		u32 status;
+	} payload_desc;
+};
+
+struct packet {
+	struct descriptor_block *db;
+	dma_addr_t db_bus;
+	struct iso_packet *payload;
+	dma_addr_t payload_bus;
+};
+
+#include <asm/byteorder.h>
+
+#if defined __BIG_ENDIAN_BITFIELD
+
+struct iso_packet {
+	/* First quadlet */
+	unsigned int dbs      : 8;
+	unsigned int eoh0     : 2;
+	unsigned int sid      : 6;
+
+	unsigned int dbc      : 8;
+	unsigned int fn       : 2;
+	unsigned int qpc      : 3;
+	unsigned int sph      : 1;
+	unsigned int reserved : 2;
+
+	/* Second quadlet */
+	unsigned int fdf      : 8;
+	unsigned int eoh1     : 2;
+	unsigned int fmt      : 6;
+
+	unsigned int syt      : 16;
+
+        quadlet_t data[0];
+};
+
+#elif defined __LITTLE_ENDIAN_BITFIELD
+
+struct iso_packet {
+	/* First quadlet */
+	unsigned int sid      : 6;
+	unsigned int eoh0     : 2;
+	unsigned int dbs      : 8;
+
+	unsigned int reserved : 2;
+	unsigned int sph      : 1;
+	unsigned int qpc      : 3;
+	unsigned int fn       : 2;
+	unsigned int dbc      : 8;
+
+	/* Second quadlet */
+	unsigned int fmt      : 6;
+	unsigned int eoh1     : 2;
+	unsigned int fdf      : 8;
+
+	unsigned int syt      : 16;
+
+	quadlet_t data[0];
+};
+
+#else
+
+#error Unknown bitfield type
+
+#endif
+
+struct fraction {
+	int integer;
+	int numerator;
+	int denominator;
+};
+
+#define PACKET_LIST_SIZE 256
+#define MAX_PACKET_LISTS 4
+
+struct packet_list {
+	struct list_head link;
+	int last_cycle_count;
+	struct packet packets[PACKET_LIST_SIZE];
+};
+
+#define BUFFER_SIZE 128
+
+/* This implements a circular buffer for incoming samples. */
+
+struct buffer {
+	size_t head, tail, length, size;
+	unsigned char data[0];
+};
+
+struct stream {
+	int iso_channel;
+	int format;
+	int rate;
+	int dimension;
+	int fdf;
+	int mode;
+	int sample_format;
+	struct cmp_pcr *opcr;
+
+	/* Input samples are copied here. */
+	struct buffer *input;
+
+	/* ISO Packer state */
+	unsigned char dbc;
+	struct packet_list *current_packet_list;
+	int current_packet;
+	struct fraction ready_samples, samples_per_cycle;
+
+	/* We use these to generate control bits when we are packing
+	 * iec958 data.
+	 */
+	int iec958_frame_count;
+	int iec958_rate_code;
+
+	/* The cycle_count and cycle_offset fields are used for the
+	 * synchronization timestamps (syt) in the cip header.  They
+	 * are incremented by at least a cycle every time we put a
+	 * time stamp in a packet.  As we don't time stamp all
+	 * packages, cycle_count isn't updated in every cycle, and
+	 * sometimes it's incremented by 2.  Thus, we have
+	 * cycle_count2, which is simply incremented by one with each
+	 * packet, so we can compare it to the transmission time
+	 * written back in the dma programs.
+	 */
+	atomic_t cycle_count, cycle_count2;
+	struct fraction cycle_offset, ticks_per_syt_offset;
+	int syt_interval;
+	int stale_count;
+
+	/* Theses fields control the sample output to the DMA engine.
+	 * The dma_packet_lists list holds packet lists currently
+	 * queued for dma; the head of the list is currently being
+	 * processed.  The last program in a packet list generates an
+	 * interrupt, which removes the head from dma_packet_lists and
+	 * puts it back on the free list.
+	 */
+	struct list_head dma_packet_lists;
+	struct list_head free_packet_lists;
+        wait_queue_head_t packet_list_wait;
+	spinlock_t packet_list_lock;
+	struct ohci1394_iso_tasklet iso_tasklet;
+	struct pci_pool *descriptor_pool, *packet_pool;
+
+	/* Streams at a host controller are chained through this field. */
+	struct list_head link;
+	struct amdtp_host *host;
+};
+
+struct amdtp_host {
+	struct hpsb_host *host;
+	struct ti_ohci *ohci;
+	struct list_head stream_list;
+	spinlock_t stream_list_lock;
+};
+
+static struct hpsb_highlevel amdtp_highlevel;
+
+
+/* FIXME: This doesn't belong here... */
+
+#define OHCI1394_CONTEXT_CYCLE_MATCH 0x80000000
+#define OHCI1394_CONTEXT_RUN         0x00008000
+#define OHCI1394_CONTEXT_WAKE        0x00001000
+#define OHCI1394_CONTEXT_DEAD        0x00000800
+#define OHCI1394_CONTEXT_ACTIVE      0x00000400
+
+static void ohci1394_start_it_ctx(struct ti_ohci *ohci, int ctx,
+			   dma_addr_t first_cmd, int z, int cycle_match)
+{
+	reg_write(ohci, OHCI1394_IsoXmitIntMaskSet, 1 << ctx);
+	reg_write(ohci, OHCI1394_IsoXmitCommandPtr + ctx * 16, first_cmd | z);
+	reg_write(ohci, OHCI1394_IsoXmitContextControlClear + ctx * 16, ~0);
+	wmb();
+	reg_write(ohci, OHCI1394_IsoXmitContextControlSet + ctx * 16,
+		  OHCI1394_CONTEXT_CYCLE_MATCH | (cycle_match << 16) |
+		  OHCI1394_CONTEXT_RUN);
+}
+
+static void ohci1394_wake_it_ctx(struct ti_ohci *ohci, int ctx)
+{
+	reg_write(ohci, OHCI1394_IsoXmitContextControlSet + ctx * 16,
+		  OHCI1394_CONTEXT_WAKE);
+}
+
+static void ohci1394_stop_it_ctx(struct ti_ohci *ohci, int ctx, int synchronous)
+{
+	u32 control;
+	int wait;
+
+	reg_write(ohci, OHCI1394_IsoXmitIntMaskClear, 1 << ctx);
+	reg_write(ohci, OHCI1394_IsoXmitContextControlClear + ctx * 16,
+		  OHCI1394_CONTEXT_RUN);
+	wmb();
+
+	if (synchronous) {
+		for (wait = 0; wait < 5; wait++) {
+			control = reg_read(ohci, OHCI1394_IsoXmitContextControlSet + ctx * 16);
+			if ((control & OHCI1394_CONTEXT_ACTIVE) == 0)
+				break;
+
+			set_current_state(TASK_INTERRUPTIBLE);
+			schedule_timeout(1);
+		}
+	}
+}
+
+/* Note: we can test if free_packet_lists is empty without aquiring
+ * the packet_list_lock.  The interrupt handler only adds to the free
+ * list, there is no race condition between testing the list non-empty
+ * and acquiring the lock.
+ */
+
+static struct packet_list *stream_get_free_packet_list(struct stream *s)
+{
+	struct packet_list *pl;
+	unsigned long flags;
+
+	if (list_empty(&s->free_packet_lists))
+		return NULL;
+
+	spin_lock_irqsave(&s->packet_list_lock, flags);
+	pl = list_entry(s->free_packet_lists.next, struct packet_list, link);
+	list_del(&pl->link);
+	spin_unlock_irqrestore(&s->packet_list_lock, flags);
+
+	return pl;
+}
+
+static void stream_start_dma(struct stream *s, struct packet_list *pl)
+{
+	u32 syt_cycle, cycle_count, start_cycle;
+
+	cycle_count = reg_read(s->host->ohci,
+			       OHCI1394_IsochronousCycleTimer) >> 12;
+	syt_cycle = (pl->last_cycle_count - PACKET_LIST_SIZE + 1) & 0x0f;
+
+	/* We program the DMA controller to start transmission at
+	 * least 17 cycles from now - this happens when the lower four
+	 * bits of cycle_count is 0x0f and syt_cycle is 0, in this
+	 * case the start cycle is cycle_count - 15 + 32. */
+	start_cycle = (cycle_count & ~0x0f) + 32 + syt_cycle;
+	if ((start_cycle & 0x1fff) >= 8000)
+		start_cycle = start_cycle - 8000 + 0x2000;
+
+	ohci1394_start_it_ctx(s->host->ohci, s->iso_tasklet.context,
+			      pl->packets[0].db_bus, 3,
+			      start_cycle & 0x7fff);
+}
+
+static void stream_put_dma_packet_list(struct stream *s,
+				       struct packet_list *pl)
+{
+	unsigned long flags;
+	struct packet_list *prev;
+
+	/* Remember the cycle_count used for timestamping the last packet. */
+	pl->last_cycle_count = atomic_read(&s->cycle_count2) - 1;
+	pl->packets[PACKET_LIST_SIZE - 1].db->payload_desc.branch = 0;
+
+	spin_lock_irqsave(&s->packet_list_lock, flags);
+	list_add_tail(&pl->link, &s->dma_packet_lists);
+	spin_unlock_irqrestore(&s->packet_list_lock, flags);
+
+	prev = list_entry(pl->link.prev, struct packet_list, link);
+	if (pl->link.prev != &s->dma_packet_lists) {
+		struct packet *last = &prev->packets[PACKET_LIST_SIZE - 1];
+		last->db->payload_desc.branch = pl->packets[0].db_bus | 3;
+		last->db->header_desc.skip = pl->packets[0].db_bus | 3;
+		ohci1394_wake_it_ctx(s->host->ohci, s->iso_tasklet.context);
+	}
+	else
+		stream_start_dma(s, pl);
+}
+
+static void stream_shift_packet_lists(unsigned long l)
+{
+	struct stream *s = (struct stream *) l;
+	struct packet_list *pl;
+	struct packet *last;
+	int diff;
+
+	if (list_empty(&s->dma_packet_lists)) {
+		HPSB_ERR("empty dma_packet_lists in %s", __FUNCTION__);
+		return;
+	}
+
+	/* Now that we know the list is non-empty, we can get the head
+	 * of the list without locking, because the process context
+	 * only adds to the tail.
+	 */
+	pl = list_entry(s->dma_packet_lists.next, struct packet_list, link);
+	last = &pl->packets[PACKET_LIST_SIZE - 1];
+
+	/* This is weird... if we stop dma processing in the middle of
+	 * a packet list, the dma context immediately generates an
+	 * interrupt if we enable it again later.  This only happens
+	 * when amdtp_release is interrupted while waiting for dma to
+	 * complete, though.  Anyway, we detect this by seeing that
+	 * the status of the dma descriptor that we expected an
+	 * interrupt from is still 0.
+	 */
+	if (last->db->payload_desc.status == 0) {
+		HPSB_INFO("weird interrupt...");
+		return;
+	}
+
+	/* If the last descriptor block does not specify a branch
+	 * address, we have a sample underflow.
+	 */
+	if (last->db->payload_desc.branch == 0)
+		HPSB_INFO("FIXME: sample underflow...");
+
+	/* Here we check when (which cycle) the last packet was sent
+	 * and compare it to what the iso packer was using at the
+	 * time.  If there is a mismatch, we adjust the cycle count in
+	 * the iso packer.  However, there are still up to
+	 * MAX_PACKET_LISTS packet lists queued with bad time stamps,
+	 * so we disable time stamp monitoring for the next
+	 * MAX_PACKET_LISTS packet lists.
+	 */
+	diff = (last->db->payload_desc.status - pl->last_cycle_count) & 0xf;
+	if (diff > 0 && s->stale_count == 0) {
+		atomic_add(diff, &s->cycle_count);
+		atomic_add(diff, &s->cycle_count2);
+		s->stale_count = MAX_PACKET_LISTS;
+	}
+
+	if (s->stale_count > 0)
+		s->stale_count--;
+
+	/* Finally, we move the packet list that was just processed
+	 * back to the free list, and notify any waiters.
+	 */
+	spin_lock(&s->packet_list_lock);
+	list_del(&pl->link);
+	list_add_tail(&pl->link, &s->free_packet_lists);
+	spin_unlock(&s->packet_list_lock);
+
+	wake_up_interruptible(&s->packet_list_wait);
+}
+
+static struct packet *stream_current_packet(struct stream *s)
+{
+	if (s->current_packet_list == NULL &&
+	    (s->current_packet_list = stream_get_free_packet_list(s)) == NULL)
+		return NULL;
+
+	return &s->current_packet_list->packets[s->current_packet];
+}
+
+static void stream_queue_packet(struct stream *s)
+{
+	s->current_packet++;
+	if (s->current_packet == PACKET_LIST_SIZE) {
+		stream_put_dma_packet_list(s, s->current_packet_list);
+		s->current_packet_list = NULL;
+		s->current_packet = 0;
+	}
+}
+
+/* Integer fractional math.  When we transmit a 44k1Hz signal we must
+ * send 5 41/80 samples per isochronous cy