All of lore.kernel.org
 help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: christian pellegrin <chripell@fsfe.org>
Cc: "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>,
	"alan@lxorguk.ukuu.org.uk" <alan@lxorguk.ukuu.org.uk>,
	"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 10:14:45 +0800	[thread overview]
Message-ID: <20100330101445.5c64dedb@feng-i7> (raw)
In-Reply-To: <cabda6421003290555k70d13168y4beba2c3ae6e2ece@mail.gmail.com>

On Mon, 29 Mar 2010 20:55:51 +0800
christian pellegrin <chripell@fsfe.org> wrote:

> On Mon, Mar 29, 2010 at 9:06 AM, Feng Tang <feng.tang@intel.com>
> wrote:
> 
> > Our platform is Intel Moorestown platform, and use a spi controller
> > core from Designware (drivers/spi/dw_*.c). I know the problem may
> > probably be caused by my setting, but the dw_spi driver works fine
> > with our own 3110 driver.
> 
> I had a look at the dw_spi driver. The spi_transfer path queues some
> work to a worqueue that itself schedules a tasklet. I don't think this
> is good for latency, I won't bet that such an architecture could
> deliver good performance. Now I see why you needed to do only big fat
> SPI transfers. Anyway this doesn't justify the 2 seconds delay between
Hi

DW controller driver don't need max3110 driver to use big spi transfer,
the early version of our max3110 is also one word per spi transfer mode,
and the 2 drivers work fine, though the rx performance is not good (copy
& paste a bulk message to console).

Let me use some example to explain why I use big spi transfer for 3110:

When the HW works at 230400 bps, when we copy bulk data to the console,
max3110 will probably receive about 20K characters, so the time for
handling each char is 50us. If you use one char per spi transfer, it
will have to execute 20K spi_transfer in one second, and each need be
done in 50us, in this 50us you'll have to deal with controller IRQ 
handler + spi system overhead + tty receiving overhead. Is it a little
over-killing to use one char per spi transfer? while the HW does
have a 8 words RX FIFO 

> chars coming in and going out through the max31x0 you are seeing. I
> will try to analyze what's going on. BTW is only input slow or output
> is sluggish too? The initial messages from the console are coming out
> fast? If you disable the MAX3110 for console but you use just as a
> normal terminal (set console=/dev/null in the kernel command line and
> add getty 115200 /dev/ttyMAX0 in iniitab) is the interaction with the
> system fine? Thanks for helping sorting out this.

The output is not so slow as input, if we set the console=/dev/ttyMAX0,
the output is sluggish, looks like below, but when enter command line
console the output is smooth, while the input is very slow.

--------------------------------------------------------------
   kernel print log of max3100 over Moorestown platform
--------------------------------------------------------------

    0.000000] Moorestown CPU Lincroft identified
[[    ..000000  iiuu  eessoo  ....44rr11((eeggffnn--77  ggccvvrriinn444411((bbnnuu44441144bbnnuu))))
[[    ..000000  BBOO--8800  0000000000001100--0000000000008800  uuaall))

                                                                            00000000]]  IISSee22::00
00000000110000 - 000000000f2000000 (usabl))
                                           [     .0000000  BIOS-e822:: 000000000220000    0000000110
000000((eserved)
[    0.000000]  BIISSe820:: 00000000ee00000 --000000000fec01000 (reseree))

                                                                              00000000]]  IISSee200
[[    ..000000  BBOO--8800  00000000ff000000--0000000000000000  rrssrree))

                                                                              00000000]]NNttcc::NN
[[    ..000000  8800uuddtt  aagg::0000000000000000    0000000000000000((ssbbee  ==  rrssrree))

                                                                                                  00
000000]]ee22  eeooeerrnnee  0000000000aa0000--0000000000110000  uuaall))

                                                                            00000000]]llss__ff    xx
2200mmxxaacc__ff    xx000000

                                00000000]]MMRR  eeaall  yyee  nnaahhbbee

                                                                            00000000]]MMRR  iiee  aa
[[    ..000000    0000--FFFF  rrtt--aakk

[[    ..000000    0000--FFFF  rrtt--aakk    00000000]]  AA0000BBFFFFuuccccaall

                                            00000000]]MMRR  aaiibbeerrnnee  nnbbee::




> 1) the console code has to check if the serial port associated to the
> same physical max3100 is up (console driver start their life much
> before serial ones).
> 
> 2) if yes send data to the tty associated to the serial driver.
> Locking is needed here.
> 
> I will implement this ASAP.

cool!


  reply	other threads:[~2010-03-30  2:14 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 [this message]
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
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=20100330101445.5c64dedb@feng-i7 \
    --to=feng.tang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=chripell@fsfe.org \
    --cc=david-b@pacbell.net \
    --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.