From owner-freebsd-hackers Mon Aug 21 01:44:04 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.FreeBSD.org (8.6.11/8.6.6) id BAA05295 for hackers-outgoing; Mon, 21 Aug 1995 01:44:04 -0700 Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.FreeBSD.org (8.6.11/8.6.6) with ESMTP id BAA05221 for ; Mon, 21 Aug 1995 01:41:17 -0700 Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA13733 for freebsd-hackers@freebsd.org; Mon, 21 Aug 1995 10:41:27 +0200 From: Luigi Rizzo Message-Id: <199508210841.KAA13733@labinfo.iet.unipi.it> Subject: Re: How to abort a DMA transfer ? To: freebsd-hackers@freebsd.org Date: Mon, 21 Aug 1995 10:41:27 +0200 (MET DST) In-Reply-To: <199508201813.UAA01188@uriah.heep.sax.de> from "J Wunsch" at Aug 20, 95 08:12:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2535 Sender: hackers-owner@freebsd.org Precedence: bulk > As Luigi Rizzo wrote: > > > > How (within a device driver) do I abort a DMA transfer which has > > been started but has not completed yet ? I am having this problem > > in the driver for a hand-scanner (the scanner does some read ahead; > > meanwhile, a user might close the device and we want to abort the > > transfer and free the buffer). I am surprised I haven't seen (or > > understood!) anything like this in existing drivers, not even in > > the floppy driver! > > You are surprised to have not seen this in the floppy driver? This > surprises me. :-) > > Actually, i'd immediately kill the floppy controller if i would abort > a transfer in progress. The only means then would raise the reset > line of the FDC. > > I'm not sure if setting some masking bit in one of the DMAC registers > will actually _abort_ a transfer. Van Gilluwe does only speak about > masking a request. The culprit is that DMA operation is usually > IO-controlled (via the TC signal) instead of being software- > controlled. > > Why don't you simply continue the started request, and throw away its > results once the DMAC has signalled the command completetion by an > interrupt (and the interrupt handler sees that the device is closed Consider the following scenario (working with a hand scanner): 1) on open, a buffer is allocated with sufficient room for reading N scanlines (the size of a scanline depends on the resolution, and the number of lines might be in the range 10..100) 2) the device is closed while the DMA is active (which is essentially all the times) *and* there will be no further data coming from the scanner (this is likely: the user knows he wants to close the device, thus he stops scanning and then gives the appropriate commands); 3) a new open is requested, possibly with different parameters, which causes the need for a larger buffer; now I need to abort the previous transfer, free the old memory, and malloc a newer block. > now)? I would personally do everything in avoiding even touching such > a hot iron like the DMAC. I'll see if I can get the data sheets for an 8237. Thanks Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ====================================================================