From owner-acpi-jp@jp.FreeBSD.org Wed Sep 11 03:52:33 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g8AIqXZ31545;
	Wed, 11 Sep 2002 03:52:33 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from tasogare.imasy.or.jp (root@tasogare.imasy.or.jp [202.227.24.5])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g8AIqV331537
	for <acpi-jp@jp.FreeBSD.org>; Wed, 11 Sep 2002 03:52:31 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (iwa@tasogare.imasy.or.jp [202.227.24.5])
	by tasogare.imasy.or.jp (8.11.6+3.4W/8.11.6/tasogare) with ESMTP/inet id g8AIqPY70525;
	Wed, 11 Sep 2002 03:52:25 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Message-Id: <20020911.035217.41626778.iwasaki@jp.FreeBSD.org>
To: acpi-jp@jp.FreeBSD.org, imp@bsdimp.com
Cc: jhb@freebsd.org
From: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org>
In-Reply-To: <20020910.095906.35799601.imp@bsdimp.com>
References: <XFMail.20020910092247.jhb@FreeBSD.org>
	<20020910.233702.112628289.iwasaki@jp.FreeBSD.org>
	<20020910.095906.35799601.imp@bsdimp.com>
X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Wed, 11 Sep 2002 03:52:17 +0900
X-Sequence: acpi-jp 1807
Subject: [acpi-jp 1807] Re: acpi issue on my Fiva 205
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: iwasaki@jp.FreeBSD.org
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+020902

> : I don't feel it's right at all too :-)
> : Because I couldn't find any functions to write cfg->inline back to PCI.
> : # maybe pci_write_ivar() or new pci_write_device()?
> 
> There's a way...  If nothing else pci_write_config after setting the
> value in the cfg structure...

I've recalled pci_cfgregwrite() for this purpose and modified
acpi_pci_link_set_irq() a bit.  After AcpiSetCurrentResources(),
write irq to PCI config space.

        if (ACPI_FAILURE(error = AcpiSetCurrentResources(link->handle, &crsbuf))) {
                ACPI_DEBUG_PRINT((ACPI_DB_WARN,
                    "couldn't set PCI interrupt link device _SRS data - %s\n",
                    AcpiFormatException(error)));
                return_ACPI_STATUS (error);
        }

        acpi_pci_link_get_current_irq(link, &link->current_irq);
        if (link->current_irq == irq) {
                pci_cfgregwrite(link->busno,
                    (int)((link->prt.Address & 0xffff0000) >> 16),
                    (int)link->prt.Pin, PCIR_INTLINE, irq, 1);
                error = AE_OK;
        } else {
                error = AE_ERROR;
        }
 
        return_ACPI_STATUS (error);

And removed dirty hint hack from pccbb.c.
Looks better?

> : > > Here is dmesg w/ acpi_pci_link:
> : > > ----
> : > > Using $PIR table, 10 entries at 0xc00fdf20
> : > > PCI-Only Interrupts: none
> : > > Location  Bus Device Pin  Link  IRQs
> : > > slot 5      0   13    A   0x01  6 10 11 14
> : > > embedded    0    9    A   0x01  3 4 5 6 7 9 10 11 12 14 15
> : > > embedded    0   10    A   0x02  11
> : > > slot 5      0   13    B   0x02  6 10 11 14
> : > > embedded    0   10    B   0x03  11
> : > > slot 5      0   13    C   0x03  6 10 11 14
> : > > slot 5      0   13    D   0x04  6 10 11 14
> : > > embedded    0   11    A   0x04  10
> : > > embedded    0   12    A   0x05  6 10 11 14
> : > > embedded    0    3    A   0x07  6 10 11 14
> : > > embedded    0    4    A   0x08  6 10 11 14
> : > > embedded    0   20    A   0x59  6 10 11 14
> 
> I've resorted the table.  This table is bogus because all the Links
> should have the same possible mask (by definition of the link pin),
> yet they do not in the case of links 1, 2, 3 and 4.  I think that the
> links for the slots should have some other number and this is a
> mistake by the BIOS writers.
> 
> # Are there any BIOS updates for the FIVAs?

Hmmm...
But I think there are many other laptops which have the bogus table,
and we need more general solution for them...

> : Yes, all LNKs have the same Possible IRQs(3, 4, 5, 7, 10, 11),
> : that looks strange for me.  And actually I tried all other possible
> : IRQs for LNK2 and 3, all failed.  Only 11 is working configuration
> : as $PIR table claimed.
> 
> Yes, that's the other problem that I found with the FIVA.  Its link
> table is completely bogus in acpi.

I tested various configurations with revised code, and found IRQ 10
also can be used for FIVA's LNK2 and LNK3.
# and I wonder why Windows can use other IRQs other than 10 and 11...
Now that my dmesg output is like this;
---- arbitrated configuration ----------------------
\_SB_.PCI0.ISA_.LNKU irq  11: [  3  4  5  7 10 11] low,level,sharable 0:20:0
\_SB_.PCI0.ISA_.LNK7 irq   3: [  3  4  5  7 10 11] low,level,sharable 0:3:0
\_SB_.PCI0.ISA_.LNK8 irq  10: [  3  4  5  7 10 11] low,level,sharable 0:4:0
\_SB_.PCI0.ISA_.LNK2 irq  10: [  3  4  5  7 10 11] low,level,sharable 0:10:0
\_SB_.PCI0.ISA_.LNK3 irq  11: [  3  4  5  7 10 11] low,level,sharable 0:10:1
\_SB_.PCI0.ISA_.LNK1 irq   3: [  3  4  5  7 10 11] low,level,sharable 0:9:0
\_SB_.PCI0.ISA_.LNK4 irq  10: [  3  4  5  7 10 11] low,level,sharable 0:11:0
\_SB_.PCI0.ISA_.LNK5 irq  11: [  3  4  5  7 10 11] low,level,sharable 0:12:0
[snip]
cbb0: <TI1420 PCI-CardBus Bridge> mem 0x88000000-0x88000fff irq 10 at device 10.0 on pci0
cardbus0: <CardBus bus> on cbb0
pccard0: <16-bit PCCard bus> on cbb0
cbb1: <TI1420 PCI-CardBus Bridge> mem 0x88001000-0x88001fff irq 11 at device 10.1 on pci0
cardbus1: <CardBus bus> on cbb1
pccard1: <16-bit PCCard bus> on cbb1
[snip]
wi0: <Corega Wireless LAN PCC-11> at port 0x100-0x13f irq 10 function 0 config 1 on pccard0
[snip]
ata2 at port 0x140-0x14f irq 11 function 0 config 1 on pccard1

> We have a couple of options here.  Maybe we can optionally second
> guess the ACPI table if there is a $PIR table and make best guess
> corrections.  The other is to have some way to load an alternate, and
> correct, link table.

I guess that we need more time to implement the perfect ACPI PRT fixup,
especially for FIVA's.
Until that time, I still think giving hints w/ loader tunable would be
helpful.

These two lines in my loader.conf:
hw.acpi.pcilink.0.10.0.irq="10"
hw.acpi.pcilink.0.10.1.irq="11"

Any better naming for them?
# e.g. hw.acpi.pci.link.0.10.0.irq or hw.acpi.pci0.link.10.0.irq ?

Thanks
