From owner-freebsd-mobile Thu Apr 8 13: 5:52 1999 Delivered-To: freebsd-mobile@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id BC50614E51 for ; Thu, 8 Apr 1999 13:05:50 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id NAA01215; Thu, 8 Apr 1999 13:00:53 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199904082000.NAA01215@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Ted Faber Cc: Nate Williams , "Daniel C. Sobral" , NAKAGAWA Yoshihisa , Nick Sayer , freebsd-mobile@FreeBSD.ORG Subject: Re: Any success with CirrusLogic 6729/6730??? In-reply-to: Your message of "Thu, 08 Apr 1999 11:38:47 PDT." <199904081838.LAA20241@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Apr 1999 13:00:53 -0700 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> I think the issue of is it or isn't it is most germane to whether we > >> can supply the ISA irq and port on a config line, as we can for the > >> devices that are definitely ISA drivers. Presumably using that > >> configuration mechanism means tying it to the kernel data structures > >> for ISA devices, and herein lies the problem. > > > >What he said. > > Ummm, not that I dislike being agreed with, but can you tell us a > little more about those problems? Even one example would help. The problem is that with the static configuration technologies (config, newconfig) under discussion, there is an array of per-bus data structures constructed at compile-time containing the parametric information. By making the pcic driver an ISA driver, you tie it to the data structure that config generates. This is a fundamental problem with our current bus code. Because there must be one instance of this structure per instance of the device, you can't dynamically create new instances when you discover more pcics. Because the supporting code for these structures doesn't understand things arriving and leaving at arbitrary times, you can't support dynamism. The "new bus" philosophy on this is to write code which knows how to find the pcics, and attach the driver to whichever point the bridge is logically connected. The major point of contention at the moment seems to rest around how you pass per-instance parameters to the driver, to tell it where to put the pcic (I/O, interrupt resources). I don't think that this should actually be an issue - we should be able to determine these numbers automatically. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message