Date: Fri, 09 Apr 1999 18:13:04 +0900 From: NAKAGAWA Yoshihisa <y-nakaga@nwsl.mesh.ad.jp> To: Mike Smith <mike@smith.net.au> Cc: Ted Faber <faber@ISI.EDU>, Nate Williams <nate@mt.sri.com>, "Daniel C. Sobral" <dcs@newsguy.com>, Nick Sayer <nsayer@quack.kfu.com>, freebsd-mobile@FreeBSD.ORG Subject: Re: Any success with CirrusLogic 6729/6730??? Message-ID: <199904090913.SAA03116@chandra.eatell.msr.prug.or.jp> In-Reply-To: Your message of "Thu, 08 Apr 1999 13:00:53 MST." <199904082000.NAA01215@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
# 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904090913.SAA03116>