Re: pchb@acpi again

[Chuck Silvers <chuq%chuq.com@localhost>]

On Tue, Apr 09, 2013 at 07:44:25AM +0900, KIYOHARA Takashi wrote:
> Hi!
> 
> 
> From: Chuck Silvers <chuq%chuq.com@localhost>
> Date: Mon, 8 Apr 2013 09:34:06 -0700
> 
> > in acpi_pci.c, why do you need to skip the check for ACPI_VALID_ADR?
> > does the ACPI info on ia64 not have that flag set when it should?
> 
> In my memory, YES.  :-<
> But I can't access to my ia64 now.  I will try and check at next weekend.
> 
> Also my pchb on my ia64 has invalid vendor and product IDs(0xffffffff).

would it make sense to keep the check for that flag in the MI code,
and have the ia64 code set the flag on the appropriate ACPI nodes
in acpi_md_callback()?


> > should the x86 ports be able to use this driver?
> 
> Yes I shall maybe.  My amd64 boots at last 3-4 years ago.

great.  I'll try to help out with that.


> > I tried adding "pchb* at acpi?" on amd64, but it isn't found.
> 
> Please see acpi_ignored_ids[] in sys/dev/acpi/acpi.c.

ah, yes, removing it from that list lets it be found.  and initializing
the new aa_dmat and aa_dmat64 fields lets pchb_acpi attach successfully.
all the PCI devices work fine, it turns out that we already have logic
to prevent a PCI bus from being attached twice.  but the ISA devices are
are found twice:

pchb0 at acpi0 (PCI0, PNP0A03-7): ACPI Host-PCI Bridge
pci0 at pchb0 bus 0: configuration mode 1
NVIDIA nForce4 Memory Controller (miscellaneous memory, revision 0xa3) at pci0 
dev 0 function 0 not configured
pcib0 at pci0 dev 1 function 0: NVIDIA nForce4 PCI-ISA Bridge (rev. 0xa3)
...
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com0: console
pckbc0 at isa0 port 0x60-0x64
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
attimer0 at isa0 port 0x40-0x43
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
smsc0 at isa0 port 0x2e-0x2f: SMSC LPC47B397 Super I/O (rev 1)
smsc0: Hardware Monitor registers at 0x0480
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
attimer0: attached to pcppi0
attimer1 at acpi0 (TIME, PNP0100): io 0x40-0x43 irq 0
attimer1: can't map i/o space
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
pcppi1: can't map i/o space
pckbc1 at acpi0 (PS2M, PNP0F13) (aux port): irq 12
pckbc2 at acpi0 (KBD, PNP0303) (kbd port): io 0x60,0x64 irq 1
pckbc2: unable to map registers
com1 at acpi0 (COM1, PNP0501-1): io 0x3f8-0x3ff irq 4
com1: can't map i/o space
fdc1 at acpi0 (FDC0, PNP0700): io 0x3f0-0x3f5,0x3f7 irq 6 drq 2
fdc1: can't map i/o space


I see that we already use config_defer() to postpone looking for ISA devices,
but it's only postponed until pcib0's parent (pci0) is finished configuring.
we'd like to postpone much longer, until after acpi0 is finished, so that
the ACPI drivers get first shot at claiming all the ISA devices.

we could define a new config_defer_until() flavor of deferring the configuration
of a device, which would allow a device to specify which what other device
it wants to be processed after.  but there's no great way to get the right
device_t down to pcibattach().

I guess the real problem is that we're jumping back and forth between
walking the ACPI device tree and enumerating devices ourselves.
having ISA devices attach either "at acpi0" or "at isa0" depending
on which way we found them doesn't help either.  it seems like it would
be better if the device tree built by the autoconf process followed
the structure of the ACPI device tree.  that seems like a big change though.



anyway, there are more problems with the new pchb,
it's unhappy with the other two PCI root bridges in this system:

pchb7 at acpi0 (PCI1, PNP0A03-8): ACPI Host-PCI Bridge
pchb7: Can't get _PRT
pchb8 at acpi0 (PCI2, PNP0A03-9): ACPI Host-PCI Bridge
pchb8: Can't get _PRT


these really don't have a _PRT method, but the rest of the code doesn't mind.
they still attach fine with the mainbus attachment:

        PCI1  [06] [] (PCI) @ 0x01:0x40:0x00:0x00 [R] [B] -> 0x01:0x40
            GLMA  [06] [] (PCI) @ 0x01:0x40:0x01:0x00 [B] -> 0x01:0x41
                SLO6  [06] [] (PCI) @ 0x01:0x41:0x04:0x00
            GLMB  [06] [] (PCI) @ 0x01:0x40:0x02:0x00 [B] -> 0x01:0x61
                SLO4  [06] [] (PCI) @ 0x01:0x61:0x04:0x00
                SLO5  [06] [] (PCI) @ 0x01:0x61:0x09:0x00
        PCI2  [06] [] (PCI) @ 0x02:0x80:0x00:0x00 [R] [B] -> 0x02:0x80
            LPC   [06] [] (PCI) @ 0x02:0x80:0x01:0x00
            EXPA  [06] [] (PCI) @ 0x02:0x80:0x0E:0x00
                SLO3  [06] []

pci3 at mainbus0 bus 64
mainbus0: added to list as bus 64
ppb2 at pci3 dev 1 function 0: AMD AMD8131 PCI-X Tunnel (rev. 0x12)
pci4 at ppb2 bus 65
ppb2: added to list as bus 65
aapic0 at pci3 dev 1 function 1: AMD AMD8131 IO Apic (rev. 0x01)
ppb3 at pci3 dev 2 function 0: AMD AMD8131 PCI-X Tunnel (rev. 0x12)
pci5 at ppb3 bus 97
ppb3: added to list as bus 97
mpt0 at pci5 dev 6 function 0: Symbios Logic 53c1020/53c1030 (rev. 0x07)
mpt0: applying 1030 quirk
mpt0: interrupting at ioapic2 pin 2
scsibus0 at mpt0: 16 targets, 8 luns per target
mpt1 at pci5 dev 6 function 1: Symbios Logic 53c1020/53c1030 (rev. 0x07)
mpt1: applying 1030 quirk
mpt1: interrupting at ioapic2 pin 3
scsibus1 at mpt1: 16 targets, 8 luns per target


I guess that's because even though these root bridges themselves don't have
_PRT methods, the PCI bridges directly under them do have them.
so we'll need to accomodate that somehow.

-Chuck