From owner-freebsd-arm@FreeBSD.ORG Tue Apr 3 22:24:48 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 B5BD616A401 for ; Tue, 3 Apr 2007 22:24:48 +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 4744C13C45D for ; Tue, 3 Apr 2007 22:24:48 +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 l33MOi3J010968; Wed, 4 Apr 2007 00:24:44 +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 l33MOTCw056387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Apr 2007 00:24:30 +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 l33MOT49003025; Wed, 4 Apr 2007 00:24:29 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l33MOSA1003024; Wed, 4 Apr 2007 00:24:28 +0200 (CEST) (envelope-from ticso) Date: Wed, 4 Apr 2007 00:24:28 +0200 From: Bernd Walter To: Marcel Moolenaar Message-ID: <20070403222428.GV80382@cicely12.cicely.de> References: <20070403154858.GR80382@cicely12.cicely.de> <20070403.100732.74697496.imp@bsdimp.com> <19589D66-9DF0-428B-80BD-2ECDC992A1EE@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19589D66-9DF0-428B-80BD-2ECDC992A1EE@mac.com> 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: ticso@cicely12.cicely.de, 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: Tue, 03 Apr 2007 22:24:48 -0000 On Tue, Apr 03, 2007 at 12:05:12PM -0700, Marcel Moolenaar wrote: > > On Apr 3, 2007, at 9:07 AM, Warner Losh wrote: > > >>I plan to add up to 48 16550 UART to an RM9200 system. > *snip* > >>- How can I attach our uart(4) driver to the chips? > >>It will likely addressed with: > >>UART0 0x30000000 - 0x30000007 IRQ0 > >>UART1 0x30000008 - 0x3000000f IRQ0 > >>UART2 0x30000010 - 0x30000017 IRQ0 > >>UART3 0x30000018 - 0x3000001f IRQ0 > >>UART4 0x30000020 - 0x30000027 IRQ0 > >>UART5 0x30000028 - 0x3000002f IRQ0 > >>[...] > >>UART47 0x30000170 - 0x30000177 IRQ0 > >>UART48 0x30000178 - 0x3000017f IRQ0 > >>- I would like to use a 14,7456MHz xtal > >>How can I tell uart(4) the frequency? > > > >I'd consider creating a puc device that attaches to the atmelarm bus. > > Seconded. It's really easy to map all 48 uart(4) with a > small configuration record in puc(4). This includes the > ability to specify the RCLK. The only thing you need to > do is have puc(4) attach to some bus so that it will > end up using the configuration record. This, as has been > suggested in another email, can be done with hints. Yes absolutely - puc is perfect for this. Just needs a bit of glue code added. > >This device would need to manage the resources for the sub devices in > >a minimal way (take a look at pccard_puc for a simple example). The > >advantage to doing this is that you also get the clock frequency as a > >parameter for free. You'll likely need to have a custom ISR routine, > >depending on the details of the interrupt structure. If there's no > >external way to know quickly which of the parts interrupted, you may > >be OK with the default one. > > In -CURRENT, puc(4) uses the serdev I/F to ask each uart(4) device > about pending interrupt status and then handle them in priority > order. This may be good enough when serial I/O is sufficiently > low-speed. > > Of course, if you have something like an ILR (interrupt latch > register), then you can use that with the serdev I/F as well. In > that case puc(4) will only ask those uart(4) devices that have a > bit set in the ILR. Given the number of ports, this may be > worthwhile and it's easy enough to teach puc(4) about your > particular implementation of an ILR anyway... I already saw the related code and was very pleased with it. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de