tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: RFC: device flavours



On Mon, Jul 26, 2010 at 06:27:55PM -0500, David Young wrote:
> On Sun, Jul 25, 2010 at 09:22:53PM +0000, Quentin Garnier wrote:
> > Hi all,
> > 
> > I'm looking for comments about what I call "device flavours".  The best
> > example of the kind of situation it tries to be an answer for is the
> > multiplicity of drivers one can find around the source tree for PCI-ISA
> > bridges (mostly on x86).  An even older idea of mine is to finally see
> > legacy devices listed in the ACPI tables attached to the PCI-ISA bridge
> > where they logically belong, and device flavours can be used for that,
> > too.
> > 
> > Here's an exerpt of the dmesg output I get on my EeeBox, with two
> > flavours defined, ichlpc (to replace ichlpcib(4)) and acpiib (to let
> > legacy devices attach there;  I've only let npx(4) attach though for the
> > sake of the test):
> > 
> > pcib0 at pci0 dev 31 function 0: vendor 0x8086 product 0x27b9 (rev. 0x02)
> > timecounter: Timecounter "pcib0/ichlpc" frequency 3579545 Hz quality 1000
> > pcib0/ichlpc: 24-bit timer
> > pcib0/ichlpc: TCO (watchdog) timer configured.
> > gpio5 at pcib0: 64 pins
> > pcib0/acpiib: ACPI node SBRG
> > npx1 at pcib0 (COPR, PNP0C04): io 0xf0-0xff irq 13
> > npx1: reported by CPUID; using exception 16
> > SIOR (PNP0C02) at pcib0 not configured
> > RMSC (PNP0C02) at pcib0 not configured
> > OMSC (PNP0C02) at pcib0 not configured
> 
> ISTM you can accomplish about the same thing and get the pmf(9) support
> "for free" with a slightly different approach:
> 
> 0) Extract ISA "direct configuration" information from ACPI tables (and
>    ISA Plug 'N' Play?) and stuff it somewhere that device_register(9)
>    can get it.
> 
> 1) Make device_register() attach ISA direct configuration information to
>    each isa(4) instance as device properties.
> 
> 2) Make isa(4) use direct configuration if the information is available in
>    device properties.
> 
> 3) Refactor ichlpcib0 and pcib0 so that you have
>       ichlpc0 at pci0 dev 31 function 0: ...
>       timecounter: Timecounter "ichlpc0" frequency 3579545 Hz quality 1000
>       ichlpc0: 24-bit timer
>       ichlpc0: TCO (watchdog) timer configured.
>       pcib0 at ichlpc0: ...
>       isa0 at pcib0: ...
>       gpio5 at ichlpc0: 64 pins
>       npx0 at isa0: ...
> 
> ISTM that following such an approach, you get pmf(9) support and
> detachment virtually for free.

"For free" is a subjective thing.  I don't think using device_register()
--which is a MD callback--to pass information between two MI drivers is
free.  Nor the fact that you end up with three full devices in your tree
when there is only one in the ACPI tree.

You know, I've been there before:

http://mail-index.netbsd.org/tech-kern/2005/11/11/0011.html

And then Jared had his own approach a couple years later (which I'm not
a big fan of, but still looks a lot nicer than using device_register()):

http://mail-index.netbsd.org/tech-kern/2007/11/21/0010.html

-- 
Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.

Attachment: pgpWnEJWtERmN.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index