From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
Paul Fulghum <paulkf@microgate.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] TTY flip buffer SMP changes
Date: Sun, 10 Oct 2004 13:26:52 +1000 [thread overview]
Message-ID: <1097378811.14279.29.camel@gaston> (raw)
In-Reply-To: <1097368333.6128.2.camel@localhost.localdomain>
On Sun, 2004-10-10 at 10:32, Alan Cox wrote:
> On Sad, 2004-10-09 at 02:42, Benjamin Herrenschmidt wrote:
> > That reminds me... a while ago, I toyed with the idea of having DMA
> > support in pmac_zilog. The case where it would work well is typically
> > for things that have a known sized frame. If that information was
> > provided down to the driver, I could setup the DMA descriptor for
> > that frame size & have it interrupt me when the frame is complete,
> > along with a timeout set to the estimated time for receiving such
> > a frame + X% (I was thinking +20%)
>
> I thought the 85C30 only supported DMA for sync modes ? We have sync
> 8530 DMA code for ISA bus already, which I never got around to adding
> async too 8)
Nope, Apple's one is hooked to a DBDMA controller taht works well
in async mode too, though flow control can be a bit nasty.
We used to do DMA with the old macserial driver on the Rx side but it
had weird bugs and I didn't keep that implementation when rewriting
the driver.
Apple in Darwin does it in a funny way: they basically have a DBDMA
descriptor for _every_byte_ on the Rx side. After a given threshold
of time or data, they trigger an irq and 'harvest' it (that is walk
the DBDMA descriptors and for each completed, they "create" a status
byte to go along and recycle the descriptor. If the ring ends up
completely empty, an irq is triggered on the first Rx byte.
But that's a total waste of course. I'm pretty sure just using a
timer and a pair of DBDMA descriptors set to transfer the whole bunch,
I can just "pause" the dbdma engine while harvesting the buffer
(provided I do it quick enough since the HW Rx buffer is painfully
small on these, but HW irq latency is good and I can flip a new
buffer in right away before processing).
But for that scheme to be efficient with things like PPP, I need to
know the expected frame size (if there is such a notion with PPP, or
does it variable size frames holding one IP packet each ?) to set
my timer properly... Or I can just set my threshold to something
smaller instead, that is the DMA irq to something like 16 bytes and
the timeout timer to the estimated time of receiving 20 bytes or so...
That may not be worth the pain tho ... but we do lost data at 115200
on old G3 machines without DMA.
Ben.
next prev parent reply other threads:[~2004-10-10 3:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-07 19:58 Paul Fulghum
2004-10-07 19:37 ` Alan Cox
2004-10-08 6:26 ` Theodore Ts'o
2004-10-08 13:35 ` Paul Fulghum
2004-10-08 12:51 ` Alan Cox
2004-10-08 15:00 ` Theodore Ts'o
2004-10-09 1:42 ` Benjamin Herrenschmidt
2004-10-10 0:32 ` Alan Cox
2004-10-10 3:26 ` Benjamin Herrenschmidt [this message]
2004-10-10 12:49 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1097378811.14279.29.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=paulkf@microgate.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®