PCI Device I/O

[4powellz]

Hi,

We are developing a PCI based device that will be added to our computers
that run QNX 4.24. This is our first attempt to develop PCI hardware and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device. Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device. Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

I don’t find much capability in QNX for PCI and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

As you can see I’m a bit confused about PCI and your help would
be appreciated.

Thanks in advance,
Charlie Powell

[R_B_Adler]

Charlie,
I’m not an expert in PCI programming, but I have done a little of it myself.
The QNX people might offer some more information that I do not know…

All of the PCI communication I have done is very simple and basic. One was
extracting the Mac address off of a NIC, another was checking whether the
NIC had an active link. Using show_pci I found the vendor and product IDs
of the NIC, put them into the _CA_PCI_Find_Device call, and performed a
Get_Config_Byte. From that, I get access to an address that I can use to
request information from the NIC. I needed the programming guide for that
particular NIC to find out what the register offsets were from the address I
got, and once I got it everything went smoothly. Sometimes it’s not so
easy, you might have to move values into and out of control registers, or
write more information into buffers. But once you have that address you can
basically do what you want to do on the PCI device. I could write my own
Net driver for the NIC if I wanted to because I have access to the card and
its registers.

So, what you’d need is the programming specs for the device, then you can
base what you want to do with it from there. If it provides a burst/no
burst switch, you could turn it on and off. If you want to send a word, you
could move the word into a buffer and tell a command register what to do
with it.

I hope this helps.

R B Adler


<4powellz@home.com> wrote in message news:39EC6C60.AAB0B8E6@home.com…

Hi,

We are developing a PCI based device that will be added to our computers
that run QNX 4.24. This is our first attempt to develop PCI hardware and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device. Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device. Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

I don’t find much capability in QNX for PCI and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

As you can see I’m a bit confused about PCI and your help would
be appreciated.

Thanks in advance,
Charlie Powell

[Armin_Steinhoff1]

In article <39EC6C60.AAB0B8E6@home.com>, “4powellz@home.com” says…

Hi,

We are developing a PCI based device that will be added to our computers
that run QNX 4.24. This is our first attempt to develop PCI hardware and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device.

… and that is completely sufficient.

Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device.

Yes … the device resources ( base address reg a.s.o) must be mapped into the
address space of your driver. Then you can talk to the device …

Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

NO … you dont’t have to talk to the PCI controller. That’s normaly the task of
the system BIOS.

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

If your device supports burst mode … then the initial setup of the PCI
controller should be done at system start ( mostly by a serial EEPROM )

I don’t find much capability in QNX for PCI

What I have found was sufficient enough to write a shared memory backplane
(network) driver for a cPCI system … let me know what you are missing.

and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

I don’t see any PCI specific tasks for QNX itself.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

You don’t need no specific QNX services to program your device … what you need
is just a good documentation about how you get access to the resources of your
controller ( via the config space)

As you can see I’m a bit confused about PCI and your help would
be appreciated.

post the output of show_pci -v …

Armin

[4powellz]

Hi R B,

Thanks for your reply and yes your comments helped. You confirmed
my suspicion of how I thought PCI under QNX would work. Your comments
in conjunction with QNX’s sample programs clearly show how to find a
PCI device and map a QNX segment over the device’s memory space.

Our hardware-software interface design is undefined at this time and
I’m not sure what PCI experience our team has. I don’t know if we have
knowledge of what a typical or accepted PCI design would look like.

Could you direct me to some publicly accessible copy of a sample
programming guide for a PCI device? A sample guide might give us
some idea of what a typical PCI design would look like. Our device’s
function is like a NIC in that it will be moving multi-byte messages
between computers so the programming interface of a NIC might be
a good model.

Thanks,
Charlie Powell

R B Adler wrote:

Charlie,
I’m not an expert in PCI programming, but I have done a little of it myself.
The QNX people might offer some more information that I do not know…

All of the PCI communication I have done is very simple and basic. One was
extracting the Mac address off of a NIC, another was checking whether the
NIC had an active link. Using show_pci I found the vendor and product IDs
of the NIC, put them into the _CA_PCI_Find_Device call, and performed a
Get_Config_Byte. From that, I get access to an address that I can use to
request information from the NIC. I needed the programming guide for that
particular NIC to find out what the register offsets were from the address I
got, and once I got it everything went smoothly. Sometimes it’s not so
easy, you might have to move values into and out of control registers, or
write more information into buffers. But once you have that address you can
basically do what you want to do on the PCI device. I could write my own
Net driver for the NIC if I wanted to because I have access to the card and
its registers.

So, what you’d need is the programming specs for the device, then you can
base what you want to do with it from there. If it provides a burst/no
burst switch, you could turn it on and off. If you want to send a word, you
could move the word into a buffer and tell a command register what to do
with it.

I hope this helps.

R B Adler

4powellz@home.com> > wrote in message news:> 39EC6C60.AAB0B8E6@home.com> …
Hi,

We are developing a PCI based device that will be added to our computers
that run QNX 4.24. This is our first attempt to develop PCI hardware and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device. Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device. Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

I don’t find much capability in QNX for PCI and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

As you can see I’m a bit confused about PCI and your help would
be appreciated.

Thanks in advance,
Charlie Powell

[4powellz]

Hi Armin and thanks for your comments.

I still have questions, inserted below, that I hope you can consider
and reply to.

Thanks in advance,
Charlie Powell

Armin Steinhoff wrote:

In article <> 39EC6C60.AAB0B8E6@home.com> >, "> 4powellz@home.com> " says…

Hi,

We are developing a PCI based device that will be added to our computers
that run QNX 4.24. This is our first attempt to develop PCI hardware and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device.

… and that is completely sufficient.

Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device.

Yes … the device resources ( base address reg a.s.o) must be mapped into the
address space of your driver. Then you can talk to the device …

Yes. I see QNX sample programs in the C Library book where the
program sets up shared memory and then maps it to the programs
address space. Just like you said. With this information I see
that I can read and write to the memory space of the PCI device.

Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

NO … you dont’t have to talk to the PCI controller. That’s normaly the task of
the system BIOS.

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

If your device supports burst mode … then the initial setup of the PCI
controller should be done at system start ( mostly by a serial EEPROM )

The hardware engineers tell me the device we’re building does support
burst mode. In fact they insist the software under QNX has to provide
burst capability too.

Right now this is the sticking point. I don’t see how to implement burst
mode transfer. All the code samples show single read/write operations
to the device’s address space and I haven’t found any way to start
a burst transfer from the software under QNX.

Do you have any suggestions?

I don’t find much capability in QNX for PCI

What I have found was sufficient enough to write a shared memory backplane
(network) driver for a cPCI system … let me know what you are missing.

Did your driver utilize burst transfers? If so, how was a burst mode
transaction initiated? Did the driver software cause the PCI burst
mode transfer to start or was it a device, other than the QNX host
computer, that caused the burst mode transfer to start?

and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

I don’t see any PCI specific tasks for QNX itself.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

You don’t need no specific QNX services to program your device … what you need
is just a good documentation about how you get access to the resources of your
controller ( via the config space)

As you can see I’m a bit confused about PCI and your help would
be appreciated.

post the output of show_pci -v …

Our PCI device is still under development and is not yet operating
with QNX. The engineers are using a Windows system for their work.
I can’t get a “show_pci” display that includes that device.

Armin

[Erick_Muis1]

Hi Charlie,

Check out:

http://qdn.qnx.com/support/bok/solution.qnx?9470

“Writing a PCI driver for QNX4”.

Hope this is of some help to you.

Take care!

Erick.



In qdn.public.qnx4 4powellz@home.com <4powellz@home.com> wrote:

Hi,

We are developing a PCI based device that will be added to our computers
that run QNX 4.24. This is our first attempt to develop PCI hardware and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device. Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device. Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

I don’t find much capability in QNX for PCI and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

As you can see I’m a bit confused about PCI and your help would
be appreciated.

Thanks in advance,
Charlie Powell

[Armin_Steinhoff1]

In article <39EE7CE0.8D6E87DB@home.com>, “4powellz@home.com” says…

Hi Armin and thanks for your comments.

I still have questions, inserted below, that I hope you can consider
and reply to.

Thanks in advance,
Charlie Powell

Armin Steinhoff wrote:

In article <> 39EC6C60.AAB0B8E6@home.com> >, "> 4powellz@home.com> " says…

Hi,

We are developing a PCI based device that will be added to our computers
that run QNX 4.24. This is our first attempt to develop PCI hardware and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device.

… and that is completely sufficient.

Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device.

Yes … the device resources ( base address reg a.s.o) must be mapped into the
address space of your driver. Then you can talk to the device …

Yes. I see QNX sample programs in the C Library book where the
program sets up shared memory and then maps it to the programs
address space. Just like you said. With this information I see
that I can read and write to the memory space of the PCI device.


Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

NO … you dont’t have to talk to the PCI controller. That’s normaly the task of
the system BIOS.

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

If your device supports burst mode … then the initial setup of the PCI
controller should be done at system start ( mostly by a serial EEPROM )

The hardware engineers tell me the device we’re building does support
burst mode. In fact they insist the software under QNX has to provide
burst capability too.

No … not the software provides the burst mode. IMHO … that is done at
the level of the PCI bus. Your PCI device must have a transmission cache and the
capability to realize the burst mode at hardware (bus) level.
The high water mark of the cache can be set dynamicalle by software … so if
the mark is set to 1 DWORD(32bit) → then you have single cycles. If the mark is
set to e.g. 128 DWORDs the hardware can process burst cycles.

Right now this is the sticking point. I don’t see how to implement burst
mode transfer.

The burst mode is a transmission mode at bus level … and it must be realized
here.

All the code samples show single read/write operations
to the device’s address space and I haven’t found any way to start
a burst transfer from the software under QNX.

Do you have any suggestions?

The only kind of ‘burst transfer’ you can initiate at QNX level is DMA … so
the PCI device should have an apropriate amount of dual ported memory if DMA
should make sense.

…Armin

[R_B_Adler]

Charlie,

The specification for the RTL8139A link is:
ftp://210.192.0.122/lancard/specification/8139a_v1.pdf

I used the register table to determine where information was stored, and
after I got the base address I just used the offsets to get what I needed.
The description of many of the other registers is provided. For this card,
I grabbed the MAC address off the card. After looking at the register data,
I noticed “ID Register 0 - 5” were at offsets 00h - 06h, and I used the base
address + the offsets to get the different pieces of the MAC address. Now
that was kind of an easy task to complete because the registers were laid
out right in the beginning and in a row. I’ve seen people have to move
values into command registers just to get the MAC address. It can get
complex.

R B Adler

<4powellz@home.com> wrote in message news:39ED35DA.F2874099@home.com…

Hi R B,

Thanks for your reply and yes your comments helped. You confirmed
my suspicion of how I thought PCI under QNX would work. Your comments
in conjunction with QNX’s sample programs clearly show how to find a
PCI device and map a QNX segment over the device’s memory space.

Our hardware-software interface design is undefined at this time and
I’m not sure what PCI experience our team has. I don’t know if we have
knowledge of what a typical or accepted PCI design would look like.

Could you direct me to some publicly accessible copy of a sample
programming guide for a PCI device? A sample guide might give us
some idea of what a typical PCI design would look like. Our device’s
function is like a NIC in that it will be moving multi-byte messages
between computers so the programming interface of a NIC might be
a good model.

Thanks,
Charlie Powell

R B Adler wrote:

Charlie,
I’m not an expert in PCI programming, but I have done a little of it
myself.
The QNX people might offer some more information that I do not know…

All of the PCI communication I have done is very simple and basic. One
was
extracting the Mac address off of a NIC, another was checking whether
the
NIC had an active link. Using show_pci I found the vendor and product
IDs
of the NIC, put them into the _CA_PCI_Find_Device call, and performed a
Get_Config_Byte. From that, I get access to an address that I can use
to
request information from the NIC. I needed the programming guide for
that
particular NIC to find out what the register offsets were from the
address I
got, and once I got it everything went smoothly. Sometimes it’s not so
easy, you might have to move values into and out of control registers,
or
write more information into buffers. But once you have that address you
can
basically do what you want to do on the PCI device. I could write my
own
Net driver for the NIC if I wanted to because I have access to the card
and
its registers.

So, what you’d need is the programming specs for the device, then you
can
base what you want to do with it from there. If it provides a burst/no
burst switch, you could turn it on and off. If you want to send a word,
you
could move the word into a buffer and tell a command register what to do
with it.

I hope this helps.

R B Adler

4powellz@home.com> > wrote in message news:> 39EC6C60.AAB0B8E6@home.com> …
Hi,

We are developing a PCI based device that will be added to our
computers
that run QNX 4.24. This is our first attempt to develop PCI hardware
and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device. Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device. Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

I don’t find much capability in QNX for PCI and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

As you can see I’m a bit confused about PCI and your help would
be appreciated.

Thanks in advance,
Charlie Powell

[Charlie_Powell1]

Thanks R B, your reference document supports my understanding
of what the model PCI device interface is. In summary, I think
the model, skipping some details, is as follows:

1. CPU records, in device’s Transmit Start Address register, the
   location of start of TX buffer located in RAM.

2. CPU records, in the device’s Receive Buffer Start Address
   register, the location of start of RX buffer located in RAM.

3. CPU writes desired interrupt mask value to device’s Interrupt
   Mask Register.

4. To initiate transmission of data, CPU writes length of data
   to be transmitted into bits 12-0 of Transmit Status Register.
   CPU can then monitor Transmit Status Register to see tranimission
   status or use device’s interrupt generation and inspection of
   Interrupt Status Register.

5. To receive data, the device receives the data and moves it
   to the RX buffer located in RAM. CPU can monitor the Receive
   Status Register to detect receipt of data or use the device’s
   interrupt and inspection of Interrupt Status Register.

The bottom line is that the CPU does little work with regards
to moving data between RAM and the device. The device uses the
supplied buffer address and buffer length information to move
data, via PCI, between RAM and the device.

If this is correct then QNX is indeed providing all the tools
one needs to support this model.

Thanks,
Charlie Powell



R B Adler wrote:

Charlie,

The specification for the RTL8139A link is:
ftp://210.192.0.122/lancard/specification/8139a_v1.pdf

I used the register table to determine where information was stored, and
after I got the base address I just used the offsets to get what I needed.
The description of many of the other registers is provided. For this card,
I grabbed the MAC address off the card. After looking at the register data,
I noticed “ID Register 0 - 5” were at offsets 00h - 06h, and I used the base
address + the offsets to get the different pieces of the MAC address. Now
that was kind of an easy task to complete because the registers were laid
out right in the beginning and in a row. I’ve seen people have to move
values into command registers just to get the MAC address. It can get
complex.

R B Adler

4powellz@home.com> > wrote in message news:> 39ED35DA.F2874099@home.com> …
Hi R B,

Thanks for your reply and yes your comments helped. You confirmed
my suspicion of how I thought PCI under QNX would work. Your comments
in conjunction with QNX’s sample programs clearly show how to find a
PCI device and map a QNX segment over the device’s memory space.

Our hardware-software interface design is undefined at this time and
I’m not sure what PCI experience our team has. I don’t know if we have
knowledge of what a typical or accepted PCI design would look like.

Could you direct me to some publicly accessible copy of a sample
programming guide for a PCI device? A sample guide might give us
some idea of what a typical PCI design would look like. Our device’s
function is like a NIC in that it will be moving multi-byte messages
between computers so the programming interface of a NIC might be
a good model.

Thanks,
Charlie Powell

R B Adler wrote:

Charlie,
I’m not an expert in PCI programming, but I have done a little of it
myself.
The QNX people might offer some more information that I do not know…

All of the PCI communication I have done is very simple and basic. One
was
extracting the Mac address off of a NIC, another was checking whether
the
NIC had an active link. Using show_pci I found the vendor and product
IDs
of the NIC, put them into the _CA_PCI_Find_Device call, and performed a
Get_Config_Byte. From that, I get access to an address that I can use
to
request information from the NIC. I needed the programming guide for
that
particular NIC to find out what the register offsets were from the
address I
got, and once I got it everything went smoothly. Sometimes it’s not so
easy, you might have to move values into and out of control registers,
or
write more information into buffers. But once you have that address you
can
basically do what you want to do on the PCI device. I could write my
own
Net driver for the NIC if I wanted to because I have access to the card
and
its registers.

So, what you’d need is the programming specs for the device, then you
can
base what you want to do with it from there. If it provides a burst/no
burst switch, you could turn it on and off. If you want to send a word,
you
could move the word into a buffer and tell a command register what to do
with it.

I hope this helps.

R B Adler

4powellz@home.com> > wrote in message news:> 39EC6C60.AAB0B8E6@home.com> …
Hi,

We are developing a PCI based device that will be added to our
computers
that run QNX 4.24. This is our first attempt to develop PCI hardware
and
associated QNX hosted software to communicate with the hardware.

My job is to develop the QNX software and I’m confused. I see QNX has
C library functions for PCI but those functions only provide access
to the “configuration space” of the PCI device. Ok. That looks good
to me. I assume I can use this to identify the interrupt, I/O space
and memory space the device is using and given that I can “talk”
with the device. Or do I have to issue commands to the PCI controller
of the host processor and it talks to the device?

For example, I want to utilize burst mode transfers to move data.
Do I have to program the PCI controller on the host processor to
accomplish this?

I don’t find much capability in QNX for PCI and I assume QNX wouldn’t
require me to program the PCI controller chip so I’m of the opinion
that the PCI device must do the work.

For example, the PCI device provides an address that I can write to
to accomplish single word transfers. Or it could provide an address
that I write a pointer to and the device uses that pointer to read
the data. Furthermore, the device controls the burst and non-burst
option.

As you can see I’m a bit confused about PCI and your help would
be appreciated.

Thanks in advance,
Charlie Powell

[system]

In comp.os.qnx 4powellz@home.com <4powellz@home.com> wrote:

Hi R B,

Thanks for your reply and yes your comments helped. You confirmed
my suspicion of how I thought PCI under QNX would work. Your comments
in conjunction with QNX’s sample programs clearly show how to find a
PCI device and map a QNX segment over the device’s memory space.

Our hardware-software interface design is undefined at this time and
I’m not sure what PCI experience our team has. I don’t know if we have
knowledge of what a typical or accepted PCI design would look like.

Could you direct me to some publicly accessible copy of a sample
programming guide for a PCI device? A sample guide might give us
some idea of what a typical PCI design would look like. Our device’s
function is like a NIC in that it will be moving multi-byte messages
between computers so the programming interface of a NIC might be
a good model.

www.pci.org

Don’t even think about doing this without a copy of the PCI 2.1
spec. It should answer the vast majority of your questions.

Essentially, PCI lets you choose a mix of several different addressing
apertures' of whatever size you need, decide which ones are I/O apertures’ and which are memory `apertures’, and then the PCI HW and
system software will conspire to allow the apertures you need mapped
somewhere into the address space of the system.

It is completely up to you what other registers your device implements.
Your driver comes up, `finds’ your cards apertures, and then uses offsets
from them to write to specific registers you implement.

The only really `standard’ part of it is the bus design itself, and the
rules for how your card asks for apertures, interrupts, DMA channels, etc.
and how the OS assigns them, enables/disables your card, etc.

Most video cards for example will have one aperture pointing at the
actual frame buffer memory, and another one that points to the registers
that control the graphics engine. Many have several other apertures
for special purposes like pumping unencoded MPEG data to an MPEG decoder.

But no two video cards do anything the same way.

[Charlie_Powell1]

I’d like to continue a bit more on this thread regarding PCI Device I/O.

I think I know how to move data between the single board computer and
another board plugged into the PCI bus. Thanks to all those that
contributed.

Now the question I have has to do with setting up QNX and my application
to so the PCI device can generate an interrupt to us. I see that the
POST
software will write the routing information into Interrupt Line register
of the device’s Configuration Space as POST initializes and configures
the system.

I’m suspecting my application need only read the value of the Interupt
Line register to identify which IRQ line/value is allocated and then
use qnx_hint_attach(intnum, handler) to associate the interrupt to my
handler code. This would be done during some initialization phase.

Is my suspicion correct? Is that all there is to using interrupts from
PCI hosted devices?

Also, my Watcom C Libray manuals lists a number of functions with names
of the form _CA_PCI… If I look at the contents of the file
/usr/include/sys/pci.h I see some additional function prototypes like
_CA_PCI_Set_Hardware_Interrupt and _CA_PCI_Get_Routing_Options.

Can anyone direct me to complete information about these functions?

Thanks in advance,
Charlie Powell

[system]

In qdn.public.qnx4 Charlie Powell <charlie.powell@nokia.com> wrote:

I’d like to continue a bit more on this thread regarding PCI Device I/O.

I think I know how to move data between the single board computer and
another board plugged into the PCI bus. Thanks to all those that
contributed.

Now the question I have has to do with setting up QNX and my application
to so the PCI device can generate an interrupt to us. I see that the
POST
software will write the routing information into Interrupt Line register
of the device’s Configuration Space as POST initializes and configures
the system.

I’m suspecting my application need only read the value of the Interupt
Line register to identify which IRQ line/value is allocated and then
use qnx_hint_attach(intnum, handler) to associate the interrupt to my
handler code. This would be done during some initialization phase.

Is my suspicion correct? Is that all there is to using interrupts from
PCI hosted devices?

Aside from any hardware specific details, yes.

Also, my Watcom C Libray manuals lists a number of functions with names
of the form _CA_PCI… If I look at the contents of the file
/usr/include/sys/pci.h I see some additional function prototypes like
_CA_PCI_Set_Hardware_Interrupt and _CA_PCI_Get_Routing_Options.

Can anyone direct me to complete information about these functions?

Our _CA_PCI functions mirror the standard PCI functions required by
the PCI 2.1 spec.

The two functions you mentioned are not doc’ed because they should not
really be used by individual device drivers. It is very likely that a device
driver that tries to mess around with the IRQ routing will bugger some other
device driver that may already be running and won’t notice that it’s IRQ has
been knocked out from underneath it.

The setup for your IRQ’s should be done by the system BIOS or by IPL code
before your driver is even loaded. Unless you are doing your own IPL, I
would stay away from these two. Even if you are doing an IPL, if you have
enough of a BIOS on board that can set up your PCI IRQ’s for you, you are
advised to play along with it and use the IRQ’s it assigns.

[David_Gibbs1]

In qdn.public.qnx4 pete@qnx.com wrote:

In qdn.public.qnx4 Charlie Powell <> charlie.powell@nokia.com> > wrote:
I’d like to continue a bit more on this thread regarding PCI Device I/O.

Also, my Watcom C Libray manuals lists a number of functions with names
of the form _CA_PCI… If I look at the contents of the file
/usr/include/sys/pci.h I see some additional function prototypes like
_CA_PCI_Set_Hardware_Interrupt and _CA_PCI_Get_Routing_Options.

Can anyone direct me to complete information about these functions?

Our _CA_PCI functions mirror the standard PCI functions required by
the PCI 2.1 spec.

The two functions you mentioned are not doc’ed because they should not
really be used by individual device drivers. It is very likely that a device
driver that tries to mess around with the IRQ routing will bugger some other
device driver that may already be running and won’t notice that it’s IRQ has
been knocked out from underneath it.

The setup for your IRQ’s should be done by the system BIOS or by IPL code
before your driver is even loaded. Unless you are doing your own IPL, I
would stay away from these two. Even if you are doing an IPL, if you have
enough of a BIOS on board that can set up your PCI IRQ’s for you, you are
advised to play along with it and use the IRQ’s it assigns.

To expand… use the CA_PCI_Read_Config* functions to get the information
that you need. Check the docs for your card as to which bytes/words should
be read to figure out what irq is assigned to your card – or grab a copy
of the source to show_pci from /usr/free and look at how it goes about
querying the cards to display that sort of information.

-David