Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 08 Apr 1999 13:00:53 -0700
From:      Mike Smith <mike@smith.net.au>
To:        Ted Faber <faber@ISI.EDU>
Cc:        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:  <199904082000.NAA01215@dingo.cdrom.com>
In-Reply-To: Your message of "Thu, 08 Apr 1999 11:38:47 PDT." <199904081838.LAA20241@boreas.isi.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904082000.NAA01215>