From owner-freebsd-multimedia  Sun Jul 20 22:08:13 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id WAA23182
          for multimedia-outgoing; Sun, 20 Jul 1997 22:08:13 -0700 (PDT)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA23176
          for <freebsd-multimedia@FreeBSD.ORG>; Sun, 20 Jul 1997 22:08:05 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA20534; Mon, 21 Jul 1997 06:05:51 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199707210405.GAA20534@labinfo.iet.unipi.it>
Subject: Re: dma handling in the sound driver
To: brianc@pobox.com (Brian Campbell)
Date: Mon, 21 Jul 1997 06:05:50 +0200 (MET DST)
Cc: freebsd-multimedia@FreeBSD.ORG
In-Reply-To: <19970720204439.26980@pobox.com> from "Brian Campbell" at Jul 20, 97 08:44:20 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Not to suggest you shouldn't go off in your own direction, but I
> don't think SETFRAGMENT is useless.

I agree that with the current code SETFRAGMENT is necessary for
the reasons you mention. But with my scheme it becomes less necessary
because there is no predefined buffer size, the driver adapts to the
size of io requests done by the driver, while at the same time it feeds
the dma engine with the largest possible buffer size. What I _can_ do
(and in fact will, following your and other comments) is to make the
SETFRAGMENT call be used to limit the max size passed to the DMA. This
would be useful to reduce latency when reading. The change is just one
line of code:
	
	dl = min (dl, maxfragmentsize);

so I am not too worried about implementing it :)

	Cheers
	Luigi