On Mon, Jul 26, 2010 at 08:25:10AM +0300, Jukka Ruohonen wrote: > On Sun, Jul 25, 2010 at 09:22:53PM +0000, Quentin Garnier wrote: > > 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. > > I am not sure if I understand all of this, so bear with me. > > While this is the direction we should go, it seems to me that the long- That's a bold statement that I wouldn't have dared say :-) > standing issues in ACPI-PCI-ISA are not so much where the legacy drivers > actually logically attach, but that these, like majority of drivers on > modern x86, should utilize the information from ACPI. Sure. The ISA_DIRECT_CONFIG() macro is a kludge to allow direct configuration on the ISA bus. I could have fetched Jared McNeill's old patch that implemented direct configuration of the legacy devices using that (and he and I would certainly have had a good laugh about it), but here it was simpler to simply have an acpinodebus and attach the driver under dev/acpi. But here you get into autoconf(9) issues that are outside the scope of this thread. My long standing opinion is that drivers should have the possibility to have both a probe function (for indirect configuration) and a match function (for direct configuration). And even when you have that, at what point should the ACPI resources be decoded? The driver itself could still do it, in which case it wouldn't really be different from the current situation. > Is this possible with flavours? Will the siblings still require a stub on > the ACPI side of things? I think it is an orthogonal issue. The point of the flavours here for ACPI was to allow mixing the features without invading the *pcib drivers. > > 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 > > In the above example it is known that the LPC bridge currently conflicts > with the ACPI PM registers. So to put this to the logical end, the > derivation using ACPI should start from there, and the pci_mapreg_map(9) > call therein should use the information supplied by ACPI. That's entirely possible, and it is the kind of reasons why I have the pre-attach call to the flavours. The fact that the main driver doesn't have to know about the flavours doesn't mean they can't communicate, and for instance the flavour can set a device property. > > There are other situations in which I think device flavours could bring > > clarity and also better modularisation. For instance, support for CPU > > features on x86 like EST or PowerNow, or even ACPI P-states could be > > done that way, and it is more module-friendly because it wouldn't > > require the main CPU driver to explicitely call those feature-drivers. > > Here I can see use. I was actually seeking this kind of granularity with the > ACPI CPU. Well, I'm sure you know how I feel about having a cpu(4) object somewhere in the device tree and an acpicpu(4) object somewhere else. -- 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:
pgp4Z3iZyUZBa.pgp
Description: PGP signature