All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Paul Fulghum <paulkf@microgate.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] TTY flip buffer SMP changes
Date: Sat, 09 Oct 2004 11:42:35 +1000	[thread overview]
Message-ID: <1097286154.5592.9.camel@gaston> (raw)
In-Reply-To: <20041008150055.GA13870@thunk.org>

On Sat, 2004-10-09 at 01:00, Theodore Ts'o wrote:

> You can have the driver hang on to the sk_buff for several interrupts
> until it decides to push the data to the line displine.  So even if
> the FIFO is small, we only have to allocate/deallocate the skbuff only
> but rarely, unless someone really needs low_latency --- which should
> be but rarely. 

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%)

Ben.



  reply	other threads:[~2004-10-09  1:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-07 19:58 [RFC][PATCH] TTY flip buffer SMP changes 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 [this message]
2004-10-10  0:32             ` Alan Cox
2004-10-10  3:26               ` Benjamin Herrenschmidt
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=1097286154.5592.9.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.