From owner-freebsd-mobile Fri Apr 9 2:18: 3 1999 Delivered-To: freebsd-mobile@freebsd.org Received: from chandra.eatell.msr.prug.or.jp (dhcp418.6bone.nec.co.jp [202.247.4.18]) by hub.freebsd.org (Postfix) with ESMTP id 4C85815000 for ; Fri, 9 Apr 1999 02:18:00 -0700 (PDT) (envelope-from y-nakaga@nwsl.mesh.ad.jp) Received: from nwsl.mesh.ad.jp (localhost.eatell.msr.prug.or.jp [127.0.0.1]) by chandra.eatell.msr.prug.or.jp (8.8.8/8.8.5) with ESMTP id SAA03116; Fri, 9 Apr 1999 18:13:05 +0900 (JST) Message-Id: <199904090913.SAA03116@chandra.eatell.msr.prug.or.jp> To: Mike Smith Cc: Ted Faber , Nate Williams , "Daniel C. Sobral" , Nick Sayer , freebsd-mobile@FreeBSD.ORG Subject: Re: Any success with CirrusLogic 6729/6730??? In-reply-to: Your message of "Thu, 08 Apr 1999 13:00:53 MST." <199904082000.NAA01215@dingo.cdrom.com> Date: Fri, 09 Apr 1999 18:13:04 +0900 From: NAKAGAWA Yoshihisa Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org # Thanks advice and translate nomads ML people! > 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. It is incorrect. We already explain, some times. Newconfig *is* both dynamic and static configuration technology. > 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. Of cource, newconfig framework adopted in 4.4BSD, BSD/OS, NetBSD and OpenBSD supports dynamic device instance creation. Also detaching is supported. What is the problem of newconfig aproach ? > 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. The "newconfig" supports these, and already coded and working! Of cource in the "newconfig" project, we will do, - Separate PCIC code into three parts: ISA frontend, PCI frontend and bus independent backend. # using NetBSD pcmcia support code, and *native* CardBus # support code. - ISA frontend supports ISA PCICs on ISA buses and PCI PCICs' ISA PCIC compatible mode. # "PCI PCICs' ISA PCIC compatible mode" means BIOS setuped # Legacy compatible mode. Some CardBus bridge, it can't # probe PCI bus in this mode. - PCI frontend supports PCICs on PCI buses for *native* CardBus support. - Supports dynamic configuration for both ISA frontend and PCI frontend. Naturally it is clear that can do fully automatic configuration in PCI frontend only. - There *is* already working code and you can get it! (The UserConfig facility is not supported yet.) - Are there any problem handling PCIC as ISA device ? -- NAKAGAWA, Yoshihisa y-nakaga@nwsl.mesh.ad.jp nakagawa@jp.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message