d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
freebsd-skq/sys/dev/acpica/acpi_pcibvar.h

73 lines
2.5 KiB
C
Raw Normal View History

Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
/*-
* Copyright (c) 2000 Michael Smith
* Copyright (c) 2000 BSDi
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* $FreeBSD$
*/
#ifndef _ACPI_PCIBVAR_H_
#define _ACPI_PCIBVAR_H_
int acpi_pcib_attach(device_t bus, ACPI_BUFFER *prt, int busno);
Re-work ACPI PCI IRQ routing (_PRT, link devices). The old approach was incomplete in that the PRT routing was not aware of link programming. Fix this by doing all routing through the link devices. The new algorithm for setting up links is: 1. Read _CRS to get current setting. If invalid (not in _PRS), then set to 0. 2. Attempt to call _DIS on the link. If successful, mark the link as not routed. Otherwise, assume it still is. Then when a routing request occurs: 3. Update weights for all IRQs 4. Attempt to route the initial IRQ if valid 5. If that fails, walk through the sorted list, attempting to route IRQs. 6. Configure the trigger/polarity based on _PRS. Other changes: * Add acpi_pci_find_prt() to look up the PRT entry for a given device and acpi_pci_link_route() to select/route the best IRQ for it. * Remove duplicated code in acpi_pcib_route_interrupt() that picked the first IRQ from _PRS. * Remove unneeded arguments from acpi_pcib_resume() and friends. * Ignore _STA on link devices but report if it seems strange. * Add a prt_source handle to the PRT structure since the ACPI struct ACPI_PCI_ROUTING_TABLE uses a fixed-size entry for it. We'll need to dynamically size this object if we want to use it the same way ACPI-CA does. Null-terminate the source. Tested by: Luo Hong <luohong99_at_mails.tsinghua.edu.cn>, Jeffrey Katcher <jmkatcher_at_yahoo.com> Info from: jhb, Len Brown (Intel)
2004-08-11 14:52:50 +00:00
int acpi_pcib_route_interrupt(device_t pcib, device_t dev, int pin);
int acpi_pcib_resume(device_t dev);
#define MAX_POSSIBLE_INTERRUPTS 16
#define MAX_ISA_INTERRUPTS 16
#define MAX_ACPI_INTERRUPTS 255
struct acpi_pci_link_entry {
TAILQ_ENTRY(acpi_pci_link_entry) links;
ACPI_HANDLE handle;
UINT8 current_irq;
UINT8 initial_irq;
ACPI_RESOURCE possible_resources;
UINT8 number_of_interrupts;
UINT8 interrupts[MAX_POSSIBLE_INTERRUPTS];
UINT8 sorted_irq[MAX_POSSIBLE_INTERRUPTS];
int references;
int priority;
int flags;
#define ACPI_LINK_NONE 0
#define ACPI_LINK_ROUTED (1 << 0)
};
struct acpi_prt_entry {
TAILQ_ENTRY(acpi_prt_entry) links;
device_t pcidev;
int busno;
ACPI_PCI_ROUTING_TABLE prt;
ACPI_HANDLE prt_source;
struct acpi_pci_link_entry *pci_link;
};
Add code for ACPI PCI link object manipulation. This allocate the best IRQ to boot-disable devices (have IRQ 0). Allocated IRQ will be used for PCI interrupt routing when ACPI is enabled. Note that verbose messaging enabled for the time being so that people can easily notice the strange behavior if it happened.
2002-10-05 02:01:05 +00:00
int acpi_pci_link_config(device_t pcib, ACPI_BUFFER *prt, int busno);
Re-work ACPI PCI IRQ routing (_PRT, link devices). The old approach was incomplete in that the PRT routing was not aware of link programming. Fix this by doing all routing through the link devices. The new algorithm for setting up links is: 1. Read _CRS to get current setting. If invalid (not in _PRS), then set to 0. 2. Attempt to call _DIS on the link. If successful, mark the link as not routed. Otherwise, assume it still is. Then when a routing request occurs: 3. Update weights for all IRQs 4. Attempt to route the initial IRQ if valid 5. If that fails, walk through the sorted list, attempting to route IRQs. 6. Configure the trigger/polarity based on _PRS. Other changes: * Add acpi_pci_find_prt() to look up the PRT entry for a given device and acpi_pci_link_route() to select/route the best IRQ for it. * Remove duplicated code in acpi_pcib_route_interrupt() that picked the first IRQ from _PRS. * Remove unneeded arguments from acpi_pcib_resume() and friends. * Ignore _STA on link devices but report if it seems strange. * Add a prt_source handle to the PRT structure since the ACPI struct ACPI_PCI_ROUTING_TABLE uses a fixed-size entry for it. We'll need to dynamically size this object if we want to use it the same way ACPI-CA does. Null-terminate the source. Tested by: Luo Hong <luohong99_at_mails.tsinghua.edu.cn>, Jeffrey Katcher <jmkatcher_at_yahoo.com> Info from: jhb, Len Brown (Intel)
2004-08-11 14:52:50 +00:00
int acpi_pci_link_resume(device_t pcib);
struct acpi_prt_entry *acpi_pci_find_prt(device_t pcibdev, device_t dev,
int pin);
int acpi_pci_link_route(device_t dev, struct acpi_prt_entry *prt);
Overhaul the ACPI PCI bridge driver a bit: - Add an ACPI PCI-PCI bridge driver (the previous driver just handled Host-PCI bridges) that is a PCI driver that is a subclass of the generic PCI-PCI bridge driver. It overrides probe, attach, read_ivar, and pci_route_interrupt. - The probe routine only succeeds if our parent is an ACPI PCI bus which we test for by seeing if we can read our ACPI_HANDLE as an ivar. - The attach routine saves a copy of our handle and calls the new acpi_pcib_attach_common() function described below. - The read_ivar routine handles normal PCI-PCI bridge ivars and adds an ivar to return the ACPI_HANDLE of the bus this bridge represents. - The route_interrupt routine fetches the _PRT (PCI Interrupt Routing Table) from the bridge device's softc and passes it off to acpi_pcib_route_interrupt() to route the interrupt. - Split the old ACPI Host-PCI bridge driver into two pieces. Part of the attach routine and most of the route_interrupt routine remain in acpi_pcib.c and are shared by both ACPI PCI bridge drivers. - The attach routine verifies the PCI bridge is present, reads in the _PRT for the bridge, and attaches the child PCI bus. - The route_interrupt routine uses the passed in _PRT to route a PCI interrupt. The rest of the driver is the ACPI Host-PCI bridge specific bits that live in acpi_pcib_acpi.c. - We no longer duplicate pcib_maxslots but use it directly. - The driver now uses the pcib devclass instead of its own devclass. This means that PCI busses are now only children of pcib devices. - Allow the ACPI_HANDLE for the child PCI bus to be read as an ivar of the child bus. - Fetch the _PRT for routing PCI interrupts directly from our softc instead of walking the devclass to find ourself and then fetch our own softc. With this change and the new ACPI PCI bus driver, ACPI can now properly route interrupts for devices behind PCI-PCI bridges. That is, the Itanium2 with like 10 PCI busses can now boot ok and route all the PCI interrupts. Hopefully this will also fix problems people are having with CardBus bridges behind PCI-PCI bridges not properly routing interrupts when ACPI is used. Tested on: i386, ia64
2002-08-26 18:30:27 +00:00
#endif
Reference in New Issue Copy Permalink