ACPI and PCI vs interrupt routing on Sony VAIO's

[Jun Su]

Good Explain.
The same problem is in my PCG-R505DC.

Jun Su
--- Iain Templeton <iain.templeton at cisra.canon.com.au>
wrote:
> Hi,
> 
> I have a Sony VAIO (PCG-R505TFP) which has an
> interrupts related problem (this
> problem was previous posted elsewhere as "Weird as*
> sound problem"). This problem
> has been confirmed on at least one other Sony VAIO
> model (I forget which).
> 
> They're both Intel i830M chipset based.
> 
> Basically, the LNKB interrupt configuration register
> is not being initialised,
> so the interrupt never gets routed, and so the
> interrupt never gets to the CPU.
> Result: Sound doesn't work.
> 
> A really hacky solution to this is to run the
> command:
> 	pciconf -w -b pci0:31:0 0x61 9
> 
> which sets the i830's PCI routing register for LNKB
> to IRQ 9.
> 
> I did a bit of digging and found the following bits
> of information:
> 
> 1.  When the ACPI PCI bus starts up, it calls all
> the LNKx.CRS methods to
>     get the current resources. LNKB (amongst others)
> returns 0.
> 
> 2.  The PCI configuration space register for IRQ
> contains the value 9.
> 
> 3.  If somebody calls the LNKB.SRS method, it would
> all work because that
>     writes the PCI interrupt routing register thingy
> like pciconf does above.
> 
> But the acpi_pcib_route_interrupt() function is not
> being called because
> in pci_alloc_resource() there is a test that checks
> if the PCI config space
> register that contains the interrupt contains a
> valid number (which it does - 9).
> 
> So, basically I think there is something wrong here,
> which I think is that
> ACPI and the generic PCI code (in
> pci_alloc_resource()) don't agree when it comes
> to interrupt management.
> 
> 
> Other than saying "the BIOS is broken" (which it is,
> providing mislead information
> and all), is it a fair statement to say that the
> ACPI CRS method should be trusted
> more than the PCI configuration space registers?
> 
> If so, then if the PCI conf space register disagrees
> with the ACPI result, should
> the PCI conf space register be updated to show what
> the ACPI stuff shows?
> 
> 
> I'm happy to muddle up a patch that might do this,
> but I was hoping for a bit
> of a guide as to how to do it. I thought initially
> that I could update the PCI
> config space register at the time the LNKs CRS
> method was called, but quickly
> gave up on that because I don't know which device to
> update...
> 
> Could I instead perhaps implement the
> pci_alloc_resource() method in
> acpi_pcib_pci.c which inspects the existing PCI
> configuration and the ACPI LNK
> information and if they differ, put the ACPI value
> into the PCI configuration
> register, then call the pci_alloc_resource()
> function to finish off.
> 
> Then pci_alloc_resource() will see a bad value for
> the PCI config space IRQ,
> and call the PCIB_ROUTE_INTERRUPT method to do the
> routing.
> 
> 
> Or is there a better place (or way) to do this. (Can
> I even legally call
> pci_alloc_resource() from
> acpi_pcib_pci_alloc_resource()?).
> 
> For extra information, here is a rather verbose
> dmesg and AML dump:
> 
> 	http://starbug.ugh.net.au/~iaint/vaio/dmesg.txt
> 	http://starbug.ugh.net.au/~iaint/vaio/ruri.aml
> 
> Oh yeah, not using ACPI is not an option (panics in
> either PCI or PnP BIOS),
> also I think the same problem would exist then since
> it would still not
> try to route interrupts, but I could be wrong.
> 
> Iain
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
>
http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"freebsd-current-unsubscribe at freebsd.org"


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com