PQOAL PCI BusID vs Bus Number Problem

The OALxxx PCI routines (e.g. OALPCICfgWrite) all take a BusID parameter, in
addition to the regular PCI location address. There is no documentation on
the parameters, but the bus ID appears to be intended for additional PCI
interfaces, while the bus portion of the PCI address defines secondary buses
behind a PCI bridge. In most cases, the BusID parameter would be zero,
unless there were multiple host bridges in the system.

However, the CEDDK functions (HalGetBusData etc) don't have a BusId
parameter, this is apparently something new that was defined with the PQOAL.
The CEDDK maps calls to the HalXXX functions to IOCTL_HAL_DDK_CALL, and
from there on to the OAL functions. However, the BusID parameter needs to
be set, so the PQOAL fills in this parameter with the PCI bus number.
Unfortunately, the OAL sees calls for secondary buses as calls for buses on
another interface. Obviously, the cpu dependent code can ignore the BusID
parameter and just use the PCI device location for any system that has only
one host interface.

Questions:
- What is the purpose of the BusID parameter in the PQOAL routines, and how
is it different from the bus portion of the address?
- If there are multiple interfaces (multiple host buses) how are they
supposed to be differentiated in calls to the CEDDK configuration routines?

Any other thoughts on this?

--
Dean Ramsier - eMVP

Dean
Fri Jan 07 14:59:51 CST 2005

Never mind... The upper bits of the CEDDK BusNumber parameter are used for
bus ID, and the lower 8 bits are the bus number.

The BusNumber parameter in the DEVICE_LOCATION structure corresponds to the
BusID parameter. The BusNumber parameter of the BUSDATA_PARMS structure is
overloaded to include both BusId and bus number. The first 8 bits are bus
number, the upper bits are bus ID.

The stock PCI bus driver doesn't handle multiple PCI interfaces, as best I
can tell. So, it will always end up setting BusID to zero.
--
Dean Ramsier - eMVP


"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:Od3%236NP9EHA.3124@TK2MSFTNGP11.phx.gbl...
> The OALxxx PCI routines (e.g. OALPCICfgWrite) all take a BusID parameter,
in
> addition to the regular PCI location address. There is no documentation
on
> the parameters, but the bus ID appears to be intended for additional PCI
> interfaces, while the bus portion of the PCI address defines secondary
buses
> behind a PCI bridge. In most cases, the BusID parameter would be zero,
> unless there were multiple host bridges in the system.
>
> However, the CEDDK functions (HalGetBusData etc) don't have a BusId
> parameter, this is apparently something new that was defined with the
PQOAL.
> The CEDDK maps calls to the HalXXX functions to IOCTL_HAL_DDK_CALL, and
> from there on to the OAL functions. However, the BusID parameter needs to
> be set, so the PQOAL fills in this parameter with the PCI bus number.
> Unfortunately, the OAL sees calls for secondary buses as calls for buses
on
> another interface. Obviously, the cpu dependent code can ignore the BusID
> parameter and just use the PCI device location for any system that has
only
> one host interface.
>
> Questions:
> - What is the purpose of the BusID parameter in the PQOAL routines, and
how
> is it different from the bus portion of the address?
> - If there are multiple interfaces (multiple host buses) how are they
> supposed to be differentiated in calls to the CEDDK configuration
routines?
>
> Any other thoughts on this?
>
> --
> Dean Ramsier - eMVP
>
>

Karel
Fri Jan 07 15:01:31 CST 2005

1) Original intention is add support for system with multiple PCI buses
(SG2_VR5500 BSP is example). Unfortunately name is easily to be confused
with bus number (which identify bus on particular PCI hardware).

2) There are to ways how to differentiate.

2a) For original CEDDK HalGetBusDataByOffset/HalSetBusDataByOffset we used
fact that BusNumber is ULONG variable. As long as PCI bus number is only
byte value we use upper 24 bits as BusId (see code in
common\src\common\io\ioctl.c). There is new registry value for PCI bus which
allows you to specify this BusId. At end IOCTL_HAL_DDK_CALL with
IOCTL_HAL_SETBUSDATA/IOCTL_HAL_GETBUSDATA codes are called.

2b) There are new codes in IOCTL_HAL_DDK_CALL
(IOCTL_OAL_READBUSDATA/IOCTL_OAL_WRITEBUSDATA) which can be used for less
cryptic CEDDK functions. They are used in OAL implementation (see
common\src\common\ceddk\ddk_bus). But as long as we implement same CEDDK
HalGetBusDataByOffset/HalSetBusDataByOffset there isn't difference for
device driver. But there is chance to extend CEDDK library in future or on
platform bases.

Let me know if you have another question.
--

Karel Danihelka
---
Windows CE CoreOS
This posting is provided "AS IS" with no warranties, and confers no rights.
---

"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:Od3%236NP9EHA.3124@TK2MSFTNGP11.phx.gbl...
> The OALxxx PCI routines (e.g. OALPCICfgWrite) all take a BusID parameter,
> in
> addition to the regular PCI location address. There is no documentation
> on
> the parameters, but the bus ID appears to be intended for additional PCI
> interfaces, while the bus portion of the PCI address defines secondary
> buses
> behind a PCI bridge. In most cases, the BusID parameter would be zero,
> unless there were multiple host bridges in the system.
>
> However, the CEDDK functions (HalGetBusData etc) don't have a BusId
> parameter, this is apparently something new that was defined with the
> PQOAL.
> The CEDDK maps calls to the HalXXX functions to IOCTL_HAL_DDK_CALL, and
> from there on to the OAL functions. However, the BusID parameter needs to
> be set, so the PQOAL fills in this parameter with the PCI bus number.
> Unfortunately, the OAL sees calls for secondary buses as calls for buses
> on
> another interface. Obviously, the cpu dependent code can ignore the BusID
> parameter and just use the PCI device location for any system that has
> only
> one host interface.
>
> Questions:
> - What is the purpose of the BusID parameter in the PQOAL routines, and
> how
> is it different from the bus portion of the address?
> - If there are multiple interfaces (multiple host buses) how are they
> supposed to be differentiated in calls to the CEDDK configuration
> routines?
>
> Any other thoughts on this?
>
> --
> Dean Ramsier - eMVP
>
>