Date: Fri, 9 Apr 1999 09:36:59 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> 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>, NAKAGAWA Yoshihisa <y-nakaga@nwsl.mesh.ad.jp>, Nick Sayer <nsayer@quack.kfu.com>, freebsd-mobile@freebsd.org Subject: Re: Any success with CirrusLogic 6729/6730??? Message-ID: <Pine.BSF.4.05.9904090935060.74823-100000@herring.nlsystems.com> In-Reply-To: <199904082000.NAA01215@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 Apr 1999, Mike Smith wrote: > > >> 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. The current code has an abstraction system for resources which allows the driver to just ask for its memory region (or whatever) and let the parent device (pcic, cardbus etc) handle the request in an appropriate fashion. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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?Pine.BSF.4.05.9904090935060.74823-100000>