All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: christian pellegrin <chripell@fsfe.org>
Cc: Feng Tang <feng.tang@intel.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"greg@kroah.com" <greg@kroah.com>,
	"david-b@pacbell.net" <david-b@pacbell.net>,
	"grant.likely@secretlab.ca" <grant.likely@secretlab.ca>,
	"spi-devel-general@lists.sourceforge.net"
	<spi-devel-general@lists.sourceforge.net>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>
Subject: Re: [PATCH v1 3/4] max3100: adds console support for MAX3100
Date: Tue, 30 Mar 2010 09:46:37 +0100	[thread overview]
Message-ID: <20100330094637.325d3fb9@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <cabda6421003292349m2dd6125cp2bcc1060f5aa8741@mail.gmail.com>

> 1) latency on rx chars becomes very high because we can process
> incoming transfers only after a full 8 byte (or whatever the spi
> transfer dimension is). For a 9600 this is too much.

There I would partly disagree. Fixing the spi driver clearly makes sense
but the serial driver should be batching better. Is there a reason the
driver couldn't adjust the size based upon the tty speed when getting a
termios request ?

> 2) even worse is that we can do flow control decision only on such boundary.

For serial flow control it doesn't matter, its implicitly asynchronous
and if you only turn the fifo on at high speed you response time will be
reasonably bounded.

> 3) this is not reliable: think of what happens if the actual SPI
> transfer speed we get will be slower that the one we requested. We
> won't be emptying the RX buffer fastly enough even if could.

Consoles are not usually balanced for I/O. I grant you probably don't
want to be using full fifo sized blocks but I'm not sure I understand why
there is a problem below that ?

Alan

  parent reply	other threads:[~2010-03-30  8:46 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-23 10:29 [PATCH v1 0/3] max3100: improvements christian pellegrin
2010-03-23 10:28 ` [PATCH v1 1/4] max3100: added raise_threaded_irq Christian Pellegrin
2010-03-23 10:28   ` Christian Pellegrin
2010-03-23 10:28   ` Christian Pellegrin
2010-03-23 10:29   ` [PATCH v1 2/4] max3100: moved to threaded interrupt Christian Pellegrin
2010-03-23 10:29     ` Christian Pellegrin
2010-03-23 10:29     ` Christian Pellegrin
2010-03-23 10:29   ` [PATCH v1 3/4] max3100: adds console support for MAX3100 Christian Pellegrin
2010-03-23 10:29     ` Christian Pellegrin
2010-03-23 10:29     ` Christian Pellegrin
2010-03-29  2:48     ` Feng Tang
2010-03-29  2:48       ` Feng Tang
2010-03-29  2:48       ` Feng Tang
2010-03-29  6:11       ` christian pellegrin
2010-03-29  6:11         ` christian pellegrin
2010-03-29  7:06         ` Feng Tang
2010-03-29  7:06           ` Feng Tang
2010-03-29 12:55           ` christian pellegrin
2010-03-29 12:55             ` christian pellegrin
2010-03-30  2:14             ` Feng Tang
2010-03-30  6:49               ` christian pellegrin
2010-03-30  7:19                 ` Feng Tang
2010-03-30  8:00                   ` christian pellegrin
2010-03-30  8:46                 ` Alan Cox [this message]
2010-03-30 12:03                   ` christian pellegrin
2010-03-31  6:04                     ` Grant Likely
2010-04-05 18:19                       ` christian pellegrin
2010-04-05 19:00                         ` Grant Likely
2010-04-08  9:31       ` christian pellegrin
2010-04-08  9:31         ` christian pellegrin
2010-04-08  9:43         ` christian pellegrin
2010-04-08  9:43           ` christian pellegrin
2010-03-23 10:29   ` [PATCH v1 4/4] max3100: introduced to_max3100_port, small style fixes Christian Pellegrin
2010-03-23 10:29     ` Christian Pellegrin
2010-03-23 10:29     ` Christian Pellegrin
2010-04-15 23:22   ` [PATCH v1 1/4] max3100: added raise_threaded_irq Thomas Gleixner
2010-04-16 16:18     ` christian pellegrin
2010-04-16 22:06       ` Thomas Gleixner
2010-04-17 16:25         ` christian pellegrin

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=20100330094637.325d3fb9@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=chripell@fsfe.org \
    --cc=david-b@pacbell.net \
    --cc=feng.tang@intel.com \
    --cc=grant.likely@secretlab.ca \
    --cc=greg@kroah.com \
    --cc=linux-serial@vger.kernel.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    /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.