Re: RFC: device flavours

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

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-
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.

Is this possible with flavours? Will the siblings still require a stub on
the ACPI side of things?

> 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.

> 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.

- Jukka.