From owner-freebsd-arm@FreeBSD.ORG Wed Apr 4 14:01:13 2007 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD59016A40A for ; Wed, 4 Apr 2007 14:01:13 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 5881813C46A for ; Wed, 4 Apr 2007 14:01:12 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l34E1939024417; Wed, 4 Apr 2007 16:01:09 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l34E0rVB062317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 16:00:53 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l34E0rc6005586; Wed, 4 Apr 2007 16:00:53 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l34E0qBT005585; Wed, 4 Apr 2007 16:00:52 +0200 (CEST) (envelope-from ticso) Date: Wed, 4 Apr 2007 16:00:52 +0200 From: Bernd Walter To: Krassimir Slavchev Message-ID: <20070404140052.GD80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> <46135EDC.30700@bulinfo.net> <20070404093651.GY80382@cicely12.cicely.de> <46139CE3.6090806@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46139CE3.6090806@bulinfo.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: Bernd Walter , freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: adding 16550 UART to RM9200 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2007 14:01:14 -0000 On Wed, Apr 04, 2007 at 03:41:07PM +0300, Krassimir Slavchev wrote: > Bernd Walter wrote: > >On Wed, Apr 04, 2007 at 11:16:28AM +0300, Krassimir Slavchev wrote: > >Additionally the 16C554 is available from multiple vendors and much > >easier to source in small volume than the IIC/SPI chips. > >If that wouldn't be a reason I would have selected the Exar XR16L788, > >which is a 8 channel 16550 compatible UART with 64 Byte buffers and > >an integraded ILR. > > > > > This chip seems to be good choice. I dont now what is your application > but 48 uarts are too much. > I have dial-up servers with 34 (32+2) uarts on P1 166 Mhz (FreeBSD 2.2.8 > and 3.5.1) which work perfect for years at 38400 bps but I still get > "silo overflow" messages. > It is not a bad idea to use multiplexers where you can. The main point is to get larger buffers to reduce interrupt load no matter how it is done. I get the ILR with external hardware as well and I can still get 64 byte FiFo with the same PCB layout by using ST16C654 chips if absolutely required. I know that 48 UART is much, but I still expect that it will work for todays use. Dial-up pools with UART are quite uncommon use for UART these days. People keep old equipment running, but unlikely install new one. It is more typical to have sensor networks, console concentrators and so on. The whole used bandwidth with 48 UART should be much lower than with your 34 UART dial-up scenario. Most UART will run at 9600bps, some may use all 48 with 115200, but to get peak performance not to have sustained 115200 traffic on all ports. The interrupt overhead on ARM should be much lower than on i386. Unlikely on i386 we can even reorder the priority compared to other interrupt sources. Possible that I loose that benefit with the interrupt sharing over multiple ILR though. The ithread overhead compared to 2.x and 3.x should be solved as well. Not shure about the sio(4) vs. uart(4) performance difference. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de