From owner-freebsd-sparc64@FreeBSD.ORG Sun Aug 31 10:40:05 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD7C016A4BF for ; Sun, 31 Aug 2003 10:40:05 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3976643FEA for ; Sun, 31 Aug 2003 10:40:04 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 18861 invoked by uid 65534); 31 Aug 2003 17:40:02 -0000 Received: from p508E5667.dip.t-dialin.net (EHLO timesink.dyndns.org) (80.142.86.103) by mail.gmx.net (mp012) with SMTP; 31 Aug 2003 19:40:02 +0200 Received: by galatea (Postfix, from userid 1001) id E5E4CBD; Sun, 31 Aug 2003 19:40:15 +0200 (CEST) Date: Sun, 31 Aug 2003 19:40:15 +0200 From: Thomas Moestl To: Marcel Moolenaar Message-ID: <20030831174015.GB679@timesink.dyndns.org> Mail-Followup-To: Marcel Moolenaar , sparc64@freebsd.org References: <20030829211641.GA628@athlon.pn.xcllnt.net> <20030831124536.GA679@timesink.dyndns.org> <20030831164510.GA570@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030831164510.GA570@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.4.1i cc: sparc64@freebsd.org Subject: Re: Q: resource range for SBus oddity X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2003 17:40:06 -0000 On Sun, 2003/08/31 at 09:45:10 -0700, Marcel Moolenaar wrote: > On Sun, Aug 31, 2003 at 02:45:36PM +0200, Thomas Moestl wrote: > > > puc1: mem 0x1000000-0x1000003 irq 2024 on sbus0 > > > > > > As you can see, the memory I/O resource is 4 bytes wide. However, > > > the channel A registers on the z8530 chip are at offsets 4 > > > (control) and 6 (data). This lies outside the reserved range. > > > > > > I would think that with 2 channels and 2 addressable registers > > > per channel we would be using offsets 0-3. > > > > > > Question: Is there an implied multiplication or division factor? > > > > No, the ranges should in general be correct; I've checked this with > > other devices. The register space of a single zs channel is indeed 4 > > bytes, but IIRC each channel has a separate device node, and there was > > some oddity which required both channels to use the register addresses > > specified in the first one, which is why the zs driver attaches two > > zsttys to the first device, and does not attach to the second zs > > instance. Jake can probably give more details on that. > > I'm not sure you understand what I mean. The firmware has given a > single zs device 4 bytes of (s)bus space. We print the I/O range > in accordance with the firmware. The zs device has 4 bus-accessable > registers (2 channels, 2 registers per channel). This matches the > I/O range given to it, provided the offsets within the range are: > channel B control 0 > channel B data 1 > channel A control 2 > channel A data 3 > > But this is not the case. The registers of a single zs device are > at the following offsets: > channel B control 0 > channel B data 2 > channel A control 4 > channel A data 6 > > Thus: given the actual offsets of a single zs device, the firmware > should have assigned 8 bytes of (s)bus space to it, not 4. Unless > the I/O range is interleaved with another independent device, such > as a second zs device of course. But this is not the case. > > The zstty devices you talk about are created for each channel of > a zs device. The second zs device is not attached because we only > attach the device with number 0 (see sys/dev/zs/zs_sbus.c), I think > because the second is for the keyboard and mouse? Yes, I assumed that each device node was for a channel; I had misremembered why only the first zs device was used, and jumped to conclusions. Sorry for the confusion. I assume this is just a firmware bug then; it is unlikely that there is a factor by which we ought to multiply the sizes given in the property, since for other devices they match exactly what is to be expected by the documentation, and larger sizes would lead to overlapping regions there. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C