2010-02-26 11:43:19 +00:00
|
|
|
#pragma once
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2010-03-12 16:25:36 +00:00
|
|
|
#define PCI_ADDRESS_MEMORY_SPACE 0x00000000
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
//
|
|
|
|
// Helper Macros
|
|
|
|
//
|
|
|
|
#define PASTE2(x,y) x ## y
|
|
|
|
#define POINTER_TO_(x) PASTE2(P,x)
|
|
|
|
#define READ_FROM(x) PASTE2(READ_PORT_, x)
|
|
|
|
#define WRITE_TO(x) PASTE2(WRITE_PORT_, x)
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
//
|
|
|
|
// Declares a PCI Register Read/Write Routine
|
|
|
|
//
|
|
|
|
#define TYPE_DEFINE(x, y) \
|
|
|
|
ULONG \
|
|
|
|
NTAPI \
|
|
|
|
x( \
|
|
|
|
IN PPCIPBUSDATA BusData, \
|
|
|
|
IN y PciCfg, \
|
|
|
|
IN PUCHAR Buffer, \
|
|
|
|
IN ULONG Offset \
|
|
|
|
)
|
|
|
|
#define TYPE1_DEFINE(x) TYPE_DEFINE(x, PPCI_TYPE1_CFG_BITS);
|
|
|
|
#define TYPE2_DEFINE(x) TYPE_DEFINE(x, PPCI_TYPE2_ADDRESS_BITS);
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
//
|
|
|
|
// Defines a PCI Register Read/Write Type 1 Routine Prologue and Epilogue
|
|
|
|
//
|
|
|
|
#define TYPE1_START(x, y) \
|
|
|
|
TYPE_DEFINE(x, PPCI_TYPE1_CFG_BITS) \
|
|
|
|
{ \
|
|
|
|
ULONG i = Offset % sizeof(ULONG); \
|
|
|
|
PciCfg->u.bits.RegisterNumber = Offset / sizeof(ULONG); \
|
|
|
|
WRITE_PORT_ULONG(BusData->Config.Type1.Address, PciCfg->u.AsULONG);
|
|
|
|
#define TYPE1_END(y) \
|
|
|
|
return sizeof(y); }
|
|
|
|
#define TYPE2_END TYPE1_END
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
//
|
|
|
|
// PCI Register Read Type 1 Routine
|
|
|
|
//
|
|
|
|
#define TYPE1_READ(x, y) \
|
|
|
|
TYPE1_START(x, y) \
|
|
|
|
*((POINTER_TO_(y))Buffer) = \
|
2008-09-03 00:44:50 +00:00
|
|
|
READ_FROM(y)((POINTER_TO_(y))(ULONG_PTR)(BusData->Config.Type1.Data + i)); \
|
2006-11-27 19:26:31 +00:00
|
|
|
TYPE1_END(y)
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
//
|
|
|
|
// PCI Register Write Type 1 Routine
|
|
|
|
//
|
|
|
|
#define TYPE1_WRITE(x, y) \
|
|
|
|
TYPE1_START(x, y) \
|
2008-09-03 00:44:50 +00:00
|
|
|
WRITE_TO(y)((POINTER_TO_(y))(ULONG_PTR)(BusData->Config.Type1.Data + i), \
|
2006-11-27 19:26:31 +00:00
|
|
|
*((POINTER_TO_(y))Buffer)); \
|
|
|
|
TYPE1_END(y)
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
//
|
|
|
|
// Defines a PCI Register Read/Write Type 2 Routine Prologue and Epilogue
|
|
|
|
//
|
|
|
|
#define TYPE2_START(x, y) \
|
|
|
|
TYPE_DEFINE(x, PPCI_TYPE2_ADDRESS_BITS) \
|
|
|
|
{ \
|
|
|
|
PciCfg->u.bits.RegisterNumber = (USHORT)Offset;
|
|
|
|
|
|
|
|
//
|
|
|
|
// PCI Register Read Type 2 Routine
|
|
|
|
//
|
|
|
|
#define TYPE2_READ(x, y) \
|
|
|
|
TYPE2_START(x, y) \
|
|
|
|
*((POINTER_TO_(y))Buffer) = \
|
2008-09-03 00:44:50 +00:00
|
|
|
READ_FROM(y)((POINTER_TO_(y))(ULONG_PTR)PciCfg->u.AsUSHORT); \
|
2006-11-27 19:26:31 +00:00
|
|
|
TYPE2_END(y)
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
//
|
|
|
|
// PCI Register Write Type 2 Routine
|
|
|
|
//
|
|
|
|
#define TYPE2_WRITE(x, y) \
|
|
|
|
TYPE2_START(x, y) \
|
2008-09-03 00:44:50 +00:00
|
|
|
WRITE_TO(y)((POINTER_TO_(y))(ULONG_PTR)PciCfg->u.AsUSHORT, \
|
2006-11-27 19:26:31 +00:00
|
|
|
*((POINTER_TO_(y))Buffer)); \
|
|
|
|
TYPE2_END(y)
|
|
|
|
|
2009-11-06 23:55:08 +00:00
|
|
|
typedef NTSTATUS
|
|
|
|
(NTAPI *PciIrqRange)(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN PCI_SLOT_NUMBER PciSlot,
|
|
|
|
OUT PSUPPORTED_RANGE *Interrupt
|
|
|
|
);
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
typedef struct _PCIPBUSDATA
|
2001-08-21 20:18:27 +00:00
|
|
|
{
|
2006-11-27 19:26:31 +00:00
|
|
|
PCIBUSDATA CommonData;
|
|
|
|
union
|
|
|
|
{
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
PULONG Address;
|
|
|
|
ULONG Data;
|
|
|
|
} Type1;
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
PUCHAR CSE;
|
|
|
|
PUCHAR Forward;
|
|
|
|
ULONG Base;
|
|
|
|
} Type2;
|
|
|
|
} Config;
|
|
|
|
ULONG MaxDevice;
|
2009-11-06 23:55:08 +00:00
|
|
|
PciIrqRange GetIrqRange;
|
|
|
|
BOOLEAN BridgeConfigRead;
|
|
|
|
UCHAR ParentBus;
|
|
|
|
UCHAR Subtractive;
|
|
|
|
UCHAR reserved[1];
|
|
|
|
UCHAR SwizzleIn[4];
|
|
|
|
RTL_BITMAP DeviceConfigured;
|
|
|
|
ULONG ConfiguredBits[PCI_MAX_DEVICES * PCI_MAX_FUNCTION / 32];
|
2006-11-27 19:26:31 +00:00
|
|
|
} PCIPBUSDATA, *PPCIPBUSDATA;
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
typedef ULONG
|
|
|
|
(NTAPI *FncConfigIO)(
|
|
|
|
IN PPCIPBUSDATA BusData,
|
|
|
|
IN PVOID State,
|
|
|
|
IN PUCHAR Buffer,
|
|
|
|
IN ULONG Offset
|
|
|
|
);
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
typedef VOID
|
|
|
|
(NTAPI *FncSync)(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PCI_SLOT_NUMBER Slot,
|
|
|
|
IN PKIRQL Irql,
|
|
|
|
IN PVOID State
|
|
|
|
);
|
|
|
|
|
|
|
|
typedef VOID
|
|
|
|
(NTAPI *FncReleaseSync)(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN KIRQL Irql
|
|
|
|
);
|
|
|
|
|
|
|
|
typedef struct _PCI_CONFIG_HANDLER
|
|
|
|
{
|
|
|
|
FncSync Synchronize;
|
|
|
|
FncReleaseSync ReleaseSynchronzation;
|
|
|
|
FncConfigIO ConfigRead[3];
|
|
|
|
FncConfigIO ConfigWrite[3];
|
|
|
|
} PCI_CONFIG_HANDLER, *PPCI_CONFIG_HANDLER;
|
|
|
|
|
|
|
|
typedef struct _PCI_REGISTRY_INFO_INTERNAL
|
|
|
|
{
|
|
|
|
UCHAR MajorRevision;
|
|
|
|
UCHAR MinorRevision;
|
2009-11-02 21:46:41 +00:00
|
|
|
UCHAR NoBuses; // Number Of Buses
|
2006-11-27 19:26:31 +00:00
|
|
|
UCHAR HardwareMechanism;
|
|
|
|
ULONG ElementCount;
|
|
|
|
PCI_CARD_DESCRIPTOR CardList[ANYSIZE_ARRAY];
|
|
|
|
} PCI_REGISTRY_INFO_INTERNAL, *PPCI_REGISTRY_INFO_INTERNAL;
|
2001-08-21 20:18:27 +00:00
|
|
|
|
2010-06-27 23:54:47 +00:00
|
|
|
//
|
|
|
|
// PCI Type 1 Ports
|
|
|
|
//
|
|
|
|
#define PCI_TYPE1_ADDRESS_PORT (PULONG)0xCF8
|
|
|
|
#define PCI_TYPE1_DATA_PORT 0xCFC
|
|
|
|
|
|
|
|
//
|
|
|
|
// PCI Type 2 Ports
|
|
|
|
//
|
|
|
|
#define PCI_TYPE2_CSE_PORT (PUCHAR)0xCF8
|
|
|
|
#define PCI_TYPE2_FORWARD_PORT (PUCHAR)0xCFA
|
|
|
|
#define PCI_TYPE2_ADDRESS_BASE 0xC
|
|
|
|
|
|
|
|
//
|
|
|
|
// PCI Type 1 Configuration Register
|
|
|
|
//
|
|
|
|
typedef struct _PCI_TYPE1_CFG_BITS
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
ULONG Reserved1:2;
|
|
|
|
ULONG RegisterNumber:6;
|
|
|
|
ULONG FunctionNumber:3;
|
|
|
|
ULONG DeviceNumber:5;
|
|
|
|
ULONG BusNumber:8;
|
|
|
|
ULONG Reserved2:7;
|
|
|
|
ULONG Enable:1;
|
|
|
|
} bits;
|
|
|
|
|
|
|
|
ULONG AsULONG;
|
|
|
|
} u;
|
|
|
|
} PCI_TYPE1_CFG_BITS, *PPCI_TYPE1_CFG_BITS;
|
|
|
|
|
|
|
|
//
|
|
|
|
// PCI Type 2 CSE Register
|
|
|
|
//
|
|
|
|
typedef struct _PCI_TYPE2_CSE_BITS
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
UCHAR Enable:1;
|
|
|
|
UCHAR FunctionNumber:3;
|
|
|
|
UCHAR Key:4;
|
|
|
|
} bits;
|
|
|
|
|
|
|
|
UCHAR AsUCHAR;
|
|
|
|
} u;
|
|
|
|
} PCI_TYPE2_CSE_BITS, PPCI_TYPE2_CSE_BITS;
|
|
|
|
|
|
|
|
//
|
|
|
|
// PCI Type 2 Address Register
|
|
|
|
//
|
|
|
|
typedef struct _PCI_TYPE2_ADDRESS_BITS
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
USHORT RegisterNumber:8;
|
|
|
|
USHORT Agent:4;
|
|
|
|
USHORT AddressBase:4;
|
|
|
|
} bits;
|
|
|
|
|
|
|
|
USHORT AsUSHORT;
|
|
|
|
} u;
|
|
|
|
} PCI_TYPE2_ADDRESS_BITS, *PPCI_TYPE2_ADDRESS_BITS;
|
|
|
|
|
2010-04-01 19:42:07 +00:00
|
|
|
typedef struct _PCI_TYPE0_CFG_CYCLE_BITS
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
ULONG Reserved1:2;
|
|
|
|
ULONG RegisterNumber:6;
|
|
|
|
ULONG FunctionNumber:3;
|
|
|
|
ULONG Reserved2:21;
|
|
|
|
} bits;
|
|
|
|
ULONG AsULONG;
|
|
|
|
} u;
|
|
|
|
} PCI_TYPE0_CFG_CYCLE_BITS, *PPCI_TYPE0_CFG_CYCLE_BITS;
|
|
|
|
|
|
|
|
typedef struct _PCI_TYPE1_CFG_CYCLE_BITS
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
struct
|
|
|
|
{
|
|
|
|
ULONG Reserved1:2;
|
|
|
|
ULONG RegisterNumber:6;
|
|
|
|
ULONG FunctionNumber:3;
|
|
|
|
ULONG DeviceNumber:5;
|
|
|
|
ULONG BusNumber:8;
|
|
|
|
ULONG Reserved2:8;
|
|
|
|
} bits;
|
|
|
|
ULONG AsULONG;
|
|
|
|
} u;
|
|
|
|
} PCI_TYPE1_CFG_CYCLE_BITS, *PPCI_TYPE1_CFG_CYCLE_BITS;
|
|
|
|
|
2009-11-09 22:59:49 +00:00
|
|
|
typedef struct _ARRAY
|
|
|
|
{
|
|
|
|
ULONG ArraySize;
|
|
|
|
PVOID Element[ANYSIZE_ARRAY];
|
|
|
|
} ARRAY, *PARRAY;
|
|
|
|
|
|
|
|
typedef struct _HAL_BUS_HANDLER
|
|
|
|
{
|
|
|
|
LIST_ENTRY AllHandlers;
|
|
|
|
ULONG ReferenceCount;
|
|
|
|
BUS_HANDLER Handler;
|
|
|
|
} HAL_BUS_HANDLER, *PHAL_BUS_HANDLER;
|
|
|
|
|
2001-08-21 20:18:27 +00:00
|
|
|
/* FUNCTIONS *****************************************************************/
|
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
/* SHARED (Fake PCI-BUS HANDLER) */
|
|
|
|
|
2010-06-07 03:23:48 +00:00
|
|
|
extern PCI_CONFIG_HANDLER PCIConfigHandler;
|
|
|
|
extern PCI_CONFIG_HANDLER PCIConfigHandlerType1;
|
|
|
|
extern PCI_CONFIG_HANDLER PCIConfigHandlerType2;
|
|
|
|
|
2021-05-11 15:13:14 +00:00
|
|
|
CODE_SEG("INIT")
|
2010-06-07 03:23:48 +00:00
|
|
|
PPCI_REGISTRY_INFO_INTERNAL
|
|
|
|
NTAPI
|
|
|
|
HalpQueryPciRegistryInfo(
|
|
|
|
VOID
|
|
|
|
);
|
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpPCISynchronizeType1(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PCI_SLOT_NUMBER Slot,
|
|
|
|
IN PKIRQL Irql,
|
|
|
|
IN PPCI_TYPE1_CFG_BITS PciCfg
|
|
|
|
);
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpPCIReleaseSynchronzationType1(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN KIRQL Irql
|
|
|
|
);
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpPCISynchronizeType2(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PCI_SLOT_NUMBER Slot,
|
|
|
|
IN PKIRQL Irql,
|
|
|
|
IN PPCI_TYPE2_ADDRESS_BITS PciCfg
|
|
|
|
);
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
2007-12-13 15:34:02 +00:00
|
|
|
HalpPCIReleaseSynchronizationType2(
|
2006-11-27 19:26:31 +00:00
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN KIRQL Irql
|
|
|
|
);
|
|
|
|
|
|
|
|
TYPE1_DEFINE(HalpPCIReadUcharType1);
|
|
|
|
TYPE1_DEFINE(HalpPCIReadUshortType1);
|
|
|
|
TYPE1_DEFINE(HalpPCIReadUlongType1);
|
|
|
|
TYPE2_DEFINE(HalpPCIReadUcharType2);
|
|
|
|
TYPE2_DEFINE(HalpPCIReadUshortType2);
|
|
|
|
TYPE2_DEFINE(HalpPCIReadUlongType2);
|
|
|
|
TYPE1_DEFINE(HalpPCIWriteUcharType1);
|
|
|
|
TYPE1_DEFINE(HalpPCIWriteUshortType1);
|
|
|
|
TYPE1_DEFINE(HalpPCIWriteUlongType1);
|
|
|
|
TYPE2_DEFINE(HalpPCIWriteUcharType2);
|
|
|
|
TYPE2_DEFINE(HalpPCIWriteUshortType2);
|
|
|
|
TYPE2_DEFINE(HalpPCIWriteUlongType2);
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpValidPCISlot(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PCI_SLOT_NUMBER Slot
|
|
|
|
);
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpReadPCIConfig(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PCI_SLOT_NUMBER Slot,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Offset,
|
|
|
|
IN ULONG Length
|
|
|
|
);
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpWritePCIConfig(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PCI_SLOT_NUMBER Slot,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Offset,
|
|
|
|
IN ULONG Length
|
|
|
|
);
|
|
|
|
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpGetPCIData(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootBusHandler,
|
2014-09-21 16:00:27 +00:00
|
|
|
IN ULONG SlotNumber,
|
2009-10-30 22:15:50 +00:00
|
|
|
IN PVOID Buffer,
|
2006-11-27 19:26:31 +00:00
|
|
|
IN ULONG Offset,
|
|
|
|
IN ULONG Length
|
|
|
|
);
|
|
|
|
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpSetPCIData(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootBusHandler,
|
2014-09-21 16:00:27 +00:00
|
|
|
IN ULONG SlotNumber,
|
2009-10-30 22:15:50 +00:00
|
|
|
IN PVOID Buffer,
|
2006-11-27 19:26:31 +00:00
|
|
|
IN ULONG Offset,
|
|
|
|
IN ULONG Length
|
|
|
|
);
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
HalpAssignPCISlotResources(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN PUNICODE_STRING RegistryPath,
|
|
|
|
IN PUNICODE_STRING DriverClassName OPTIONAL,
|
|
|
|
IN PDRIVER_OBJECT DriverObject,
|
|
|
|
IN PDEVICE_OBJECT DeviceObject OPTIONAL,
|
|
|
|
IN ULONG Slot,
|
|
|
|
IN OUT PCM_RESOURCE_LIST *pAllocatedResources
|
|
|
|
);
|
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
/* NON-LEGACY */
|
|
|
|
|
|
|
|
ULONG
|
2006-11-27 19:26:31 +00:00
|
|
|
NTAPI
|
2021-06-05 13:41:49 +00:00
|
|
|
HalpGetRootInterruptVector(
|
|
|
|
_In_ ULONG BusInterruptLevel,
|
|
|
|
_In_ ULONG BusInterruptVector,
|
|
|
|
_Out_ PKIRQL Irql,
|
|
|
|
_Out_ PKAFFINITY Affinity);
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpGetCmosData(
|
2020-07-25 13:31:02 +00:00
|
|
|
_In_ ULONG BusNumber,
|
|
|
|
_In_ ULONG SlotNumber,
|
|
|
|
_Out_writes_bytes_(Length) PVOID Buffer,
|
|
|
|
_In_ ULONG Length
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
);
|
|
|
|
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpSetCmosData(
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Length
|
2006-11-27 19:26:31 +00:00
|
|
|
);
|
|
|
|
|
2021-05-11 15:13:14 +00:00
|
|
|
CODE_SEG("INIT")
|
2009-11-06 23:55:08 +00:00
|
|
|
VOID
|
|
|
|
NTAPI
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
HalpInitializePciBus(
|
2009-11-06 23:55:08 +00:00
|
|
|
VOID
|
|
|
|
);
|
|
|
|
|
2021-05-11 15:13:14 +00:00
|
|
|
CODE_SEG("INIT")
|
2009-11-09 22:59:49 +00:00
|
|
|
VOID
|
|
|
|
NTAPI
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
HalpInitializePciStubs(
|
2009-11-09 22:59:49 +00:00
|
|
|
VOID
|
|
|
|
);
|
|
|
|
|
2010-06-07 21:26:09 +00:00
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpTranslateBusAddress(
|
|
|
|
IN INTERFACE_TYPE InterfaceType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress
|
|
|
|
);
|
|
|
|
|
2009-11-09 22:59:49 +00:00
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
HalpAssignSlotResources(
|
|
|
|
IN PUNICODE_STRING RegistryPath,
|
|
|
|
IN PUNICODE_STRING DriverClassName,
|
|
|
|
IN PDRIVER_OBJECT DriverObject,
|
|
|
|
IN PDEVICE_OBJECT DeviceObject,
|
|
|
|
IN INTERFACE_TYPE BusType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN OUT PCM_RESOURCE_LIST *AllocatedResources
|
|
|
|
);
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpFindBusAddressTranslation(
|
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress,
|
|
|
|
IN OUT PULONG_PTR Context,
|
|
|
|
IN BOOLEAN NextBus
|
|
|
|
);
|
|
|
|
|
2021-05-11 15:13:14 +00:00
|
|
|
CODE_SEG("INIT")
|
2010-04-01 19:42:07 +00:00
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpRegisterPciDebuggingDeviceInfo(
|
|
|
|
VOID
|
|
|
|
);
|
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
/* LEGACY */
|
|
|
|
|
2010-06-07 21:36:31 +00:00
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HaliTranslateBusAddress(
|
|
|
|
IN INTERFACE_TYPE InterfaceType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress
|
|
|
|
);
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HaliFindBusAddressTranslation(
|
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress,
|
|
|
|
IN OUT PULONG_PTR Context,
|
|
|
|
IN BOOLEAN NextBus
|
|
|
|
);
|
|
|
|
|
2010-06-07 03:23:48 +00:00
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
HalpAdjustPCIResourceList(IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN OUT PIO_RESOURCE_REQUIREMENTS_LIST *pResourceList);
|
2014-09-21 16:00:27 +00:00
|
|
|
|
2010-06-07 03:23:48 +00:00
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpGetPCIIntOnISABus(IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN ULONG BusInterruptLevel,
|
|
|
|
IN ULONG BusInterruptVector,
|
|
|
|
OUT PKIRQL Irql,
|
|
|
|
OUT PKAFFINITY Affinity);
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpPCIPin2ISALine(IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN PCI_SLOT_NUMBER SlotNumber,
|
|
|
|
IN PPCI_COMMON_CONFIG PciData);
|
2014-09-21 16:00:27 +00:00
|
|
|
|
2010-06-07 03:23:48 +00:00
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpPCIISALine2Pin(IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN PCI_SLOT_NUMBER SlotNumber,
|
|
|
|
IN PPCI_COMMON_CONFIG PciNewData,
|
|
|
|
IN PPCI_COMMON_CONFIG PciOldData);
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
HalpGetISAFixedPCIIrq(IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN PCI_SLOT_NUMBER PciSlot,
|
|
|
|
OUT PSUPPORTED_RANGE *Range);
|
2014-09-21 16:00:27 +00:00
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
HalpInitBusHandler(
|
|
|
|
VOID
|
|
|
|
);
|
|
|
|
|
2010-06-07 21:36:31 +00:00
|
|
|
PBUS_HANDLER
|
|
|
|
NTAPI
|
|
|
|
HalpContextToBusHandler(
|
|
|
|
IN ULONG_PTR ContextValue
|
|
|
|
);
|
|
|
|
|
2010-06-07 20:10:53 +00:00
|
|
|
PBUS_HANDLER
|
|
|
|
FASTCALL
|
|
|
|
HaliReferenceHandlerForConfigSpace(
|
|
|
|
IN BUS_DATA_TYPE ConfigType,
|
|
|
|
IN ULONG BusNumber
|
|
|
|
);
|
|
|
|
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpNoBusData(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Offset,
|
|
|
|
IN ULONG Length
|
|
|
|
);
|
|
|
|
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpcGetCmosData(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Offset,
|
|
|
|
IN ULONG Length
|
|
|
|
);
|
|
|
|
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpcSetCmosData(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN ULONG SlotNumber,
|
|
|
|
IN PVOID Buffer,
|
|
|
|
IN ULONG Offset,
|
|
|
|
IN ULONG Length
|
|
|
|
);
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpTranslateSystemBusAddress(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
2014-09-21 16:00:27 +00:00
|
|
|
IN PBUS_HANDLER RootHandler,
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress
|
|
|
|
);
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
HalpTranslateIsaBusAddress(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
2014-09-21 16:00:27 +00:00
|
|
|
IN PBUS_HANDLER RootHandler,
|
[HAL]: Bus support in the HAL actually creates a further wedge between the different x86 HALs: There are actually two dinstinct implementations. On the ACPI HAL, the system is assumed not to have things like special ISA, MCA, EISA buses, and a PCI driver is used in combination with the ACPI Interface for PCI Bus support. On non-ACPI systems, the legacy "Bus Handler" library is used, and the HAL provides a core set of CMOS, EISA, ISA, MCA and PCI bus handlers, each with their own routines and specific code. Additionally, PCI IRQ Routing and other PCI bus internals are handled directly by the HAL -- on the ACPI HAL, the PCI Bus support is implemented through a "Fake"/static bus handler, just to keep the functions shared. On ReactOS, both the ACPI and non-ACPI HAL were currently using a mix of both HAL bus handling types, mostly implemented the "ACPI way" (with a fake PCI bus handler and such).
As a result, none of the Hal*Bus HALDISPATCH routines were implemented, which bus drivers expect to find when they're not on ACPI systems (ReactOS today). eVb's new PCI driver was crashing, for example.
Furthermore, legacy systems suffer, because the ACPI HAL Bus routines (that we currently have) expect perfect ACPI-style-compliant systems, not the legacy crap from the early 90ies. This works fine in VMs and new hardware, but old hardware is left behind.
This patch basically corrects the first part of the problem, by making the bus handling support separate between ACPI and non-ACPI HALs. For now, the code remains 100% the same in functionality between both.
However, I have started adding the first few elements:
[HAL]: Implement HalRegisterBusHandler HALDISPATCH routine.
[HAL]: On legacy HALs, register the CMOS, ISA, SYSTEM handlers.
[HAL]: Add cmosbus.c. Stub all bus-specific bus handler routines in the xxxbus.c files.
No real functionality change occurs with this patch, yet.
svn path=/trunk/; revision=47649
2010-06-07 01:09:41 +00:00
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress
|
|
|
|
);
|
|
|
|
|
|
|
|
ULONG
|
|
|
|
NTAPI
|
|
|
|
HalpGetSystemInterruptVector(
|
|
|
|
IN PBUS_HANDLER BusHandler,
|
|
|
|
IN PBUS_HANDLER RootHandler,
|
|
|
|
IN ULONG BusInterruptLevel,
|
|
|
|
IN ULONG BusInterruptVector,
|
|
|
|
OUT PKIRQL Irql,
|
|
|
|
OUT PKAFFINITY Affinity
|
|
|
|
);
|
2014-09-21 16:00:27 +00:00
|
|
|
|
2006-11-27 19:26:31 +00:00
|
|
|
extern ULONG HalpBusType;
|
|
|
|
extern BOOLEAN HalpPCIConfigInitialized;
|
|
|
|
extern BUS_HANDLER HalpFakePciBusHandler;
|
|
|
|
extern ULONG HalpMinPciBus, HalpMaxPciBus;
|
2010-06-07 21:36:31 +00:00
|
|
|
extern LIST_ENTRY HalpAllBusHandlers;
|
2002-10-02 19:32:57 +00:00
|
|
|
|
2002-05-05 14:57:45 +00:00
|
|
|
/* EOF */
|