For a PCIe device which wants to use MSI feature, it must somehow be
able to get the appropriate MSI address and write data to that address
to trigger the interrupt. If my understanding is correct, the device
driver should look up for that MSI address from MSI Capability
Registers and then tell the device it. I guess that address is
allocated by the BUS driver or some similar stuff by the host computer
when it’s scanning the bus devices. Is my understanding correct?
And, there is a MSI Data Register within the MSI Capability Registers,
what’s the purpose of that register? Do I, the device driver, need to
care about the content of that register? Shouldn’t the data written to
the MSI address be determined completely by the device driver?
It’s the device job to write the data to the address when it wants to
interrupt. Your driver probably has nothing to do with this at all. It
might be the case that the hardware designer blew it and your driver needs
to copy these values from config space to somewhere else, but probably not.
If your device implements multiple messages, it may be allowed to vary some
of the low bits of the data, to distinguish the messages from each other.
Jake Oshins
Windows Kernel Team
This post implies no warrantees and confers no rights.
“solotim” wrote in message news:xxxxx@ntdev…
Hi,
For a PCIe device which wants to use MSI feature, it must somehow be
able to get the appropriate MSI address and write data to that address
to trigger the interrupt. If my understanding is correct, the device
driver should look up for that MSI address from MSI Capability
Registers and then tell the device it. I guess that address is
allocated by the BUS driver or some similar stuff by the host computer
when it’s scanning the bus devices. Is my understanding correct?
And, there is a MSI Data Register within the MSI Capability Registers,
what’s the purpose of that register? Do I, the device driver, need to
care about the content of that register? Shouldn’t the data written to
the MSI address be determined completely by the device driver?
For a PCIe device which wants to use MSI feature, it must somehow be
able to get the appropriate MSI address and write data to that address
to trigger the interrupt. If my understanding is correct, the device
driver should look up for that MSI address from MSI Capability
Registers and then tell the device it.
No. The BIOS (or the bus driver) will write the assigned MSI address to
the “message address” field in the PCIe configuration space. That’s how
the device learns it – exactly the same way it is done with BARs.
And, there is a MSI Data Register within the MSI Capability Registers,
what’s the purpose of that register? Do I, the device driver, need to
care about the content of that register?
No. The hardware has to write the information from the MSI Data
Register to the assigned MSI Address. That’s how the interrupt is
fired. Both of those fields are assigned by the BIOS/bus driver. You
don’t get to write whatever you want to that address. Your MSI Address
might be shared among several different devices, and the operating
system uses the MSI Data Register to tell who fired the interrupt.
Shouldn’t the data written to
the MSI address be determined completely by the device driver?
No, that’s not how it works. To the driver, MSI is irrelevant. It’s
just another mechanism for firing an interrupt. All you know is that
your interrupt occurred. You still have to go make sure it was your
interrupt, by reading registers specific to your device.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
My case is exactly as what Jake pointed out, I need to COPY the MSI
addr/data from PCI configuration space to other registers on chips,
since HW engineers didn’t implement that. (They should do that in most
cases, right?)
Our device is assigned with one MSI addr/data, but the device may
trigger several types of interrupts. So, I guess the “messageID”
argument I get from ISR is useless in my case, and I need to traverse
the device interrupt registers to figure out which type of interrupt
occurred.
-solotim
2012/2/2 Tim Roberts : > solotim wrote: >> For a PCIe device which wants to use MSI feature, it must somehow be >> able to get the appropriate MSI address and write data to that address >> to trigger the interrupt. If my understanding is correct, the device >> driver should look up for that MSI address from MSI Capability >> Registers and then tell the device it. > > No. ?The BIOS (or the bus driver) will write the assigned MSI address to > the “message address” field in the PCIe configuration space. ?That’s how > the device learns it – exactly the same way it is done with BARs. > >> And, there is a MSI Data Register within the MSI Capability Registers, >> what’s the purpose of that register? Do I, the device driver, need to >> care about the content of that register? > > No. ?The hardware has to write the information from the MSI Data > Register to the assigned MSI Address. ?That’s how the interrupt is > fired. ?Both of those fields are assigned by the BIOS/bus driver. ?You > don’t get to write whatever you want to that address. ?Your MSI Address > might be shared among several different devices, and the operating > system uses the MSI Data Register to tell who fired the interrupt. > >> Shouldn’t the data written to >> the MSI address be determined completely by the device driver? > > No, that’s not how it works. ?To the driver, MSI is irrelevant. ?It’s > just another mechanism for firing an interrupt. ?All you know is that > your interrupt occurred. ?You still have to go make sure it was your > interrupt, by reading registers specific to your device. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
My case is exactly as what Jake pointed out, I need to COPY the MSI
addr/data from PCI configuration space to other registers on chips,
since HW engineers didn’t implement that. (They should do that in most
cases, right?)
If you have a PCIExpress core that doesn’t do this, then it is broken,
and I’d appreciate it if you could tell us where you bought the IP so I
could avoid it in the future.
Our device is assigned with one MSI addr/data, but the device may
trigger several types of interrupts. So, I guess the “messageID”
argument I get from ISR is useless in my case, and I need to traverse
the device interrupt registers to figure out which type of interrupt
occurred.
Right. The word “message” in MSI really refers to the mechanism used to
fire the interrupt, not the ability to carry information along with the
interrupt. With either MSI or an INTx pin, an interrupt is just an
event you can catch.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
“solotim” wrote in message news:xxxxx@ntdev… … > Our device is assigned with one MSI addr/data, but the device may > trigger several types of interrupts. So, I guess the “messageID” > argument I get from ISR is useless in my case, and I need to traverse > the device interrupt registers to figure out which type of interrupt > occurred.
Not quite so. As Tim has explained, the MSI intrerrupt “message” itself does not carry any useful payload. But this does not mean that you have to go out to the device registers. The deal with MSIs is that they are just usual master DMA writes. So you can define your own location in the host memory, pass the address to the device, and make it write all the relevant interrupt information there, before it issues the MSI write.
> So you can define your own location in the host memory, pass the address to
the
device, and make it write all the relevant interrupt information there,
before it issues the MSI write.
Thanks for this tip.
But I guess this is a HW feature. If the DMA IP doesn’t support it, I
still have to traverse the local registers, right?
@Tim, I’m sorry that I can’t say too much about the IP since it’s not
a released product. I’ll let you know when I get more accurate
information. I may need to discuss with HW engineers. Thanks.
“solotim” wrote in message news:xxxxx@ntdev… >> So you can define your own location in the host memory, pass the address >> to >> the >> device, and make it write all the relevant interrupt information there, >> before it issues the MSI write. > > Thanks for this tip. > But I guess this is a HW feature. If the DMA IP doesn’t support it, I > still have to traverse the local registers, right?
If your hardware does not support DMA, it neither supports MSI. Because MSI is just a DMA write. – pa
Now I encounter another question. When the device got plugged into the
host machine, there is no MSI address/data being assigned by the
system. I used RW-everything to look through the PCI configuration
space of my device. I don’t know if there is anything to do with my
driver. So later I just installed my driver with MSI-enable-declared
inf (http://msdn.microsoft.com/en-us/library/windows/hardware/ff544246(v=vs.85).aspx),
but the MSI Capability registers are still empty.
How to make the system recognize my device as a MSI supported device
and write MSI addr/data to the PCI configuration space?
Thanks,
-solotim
2012/2/4 Pavel A. : > “solotim” wrote in message news:xxxxx@ntdev… >>> >>> So you can define your own location in the host memory, pass the address >>> to >>> the >>> device, and make it write all the relevant interrupt information there, >>> before it issues the MSI write. >> >> >> Thanks for this tip. >> But I guess this is a HW feature. If the DMA IP doesn’t support it, I >> still have to traverse the local registers, right? > > > If your hardware does not support DMA, it neither supports MSI. > Because MSI is just a DMA write. > > – pa > > > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at > http://www.osronline.com/page.cfm?name=ListServer
Now I encounter another question. When the device got plugged into the
host machine, there is no MSI address/data being assigned by the
system. I used RW-everything to look through the PCI configuration
space of my device. I don’t know if there is anything to do with my
driver. So later I just installed my driver with MSI-enable-declared
inf (http://msdn.microsoft.com/en-us/library/windows/hardware/ff544246(v=vs.85).aspx),
but the MSI Capability registers are still empty.
How to make the system recognize my device as a MSI supported device
and write MSI addr/data to the PCI configuration space?
Which operating system? XP does not support MSI at all. Your board
must support the “legacy” INTx interrupts in order to work on XP.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
It’s Windows 7 64 bit.
I can see that the USB controller on the PC system is assigned with a
MSI addr/data, so I’m sure that MSI is able to work on this machine.
2012/2/9 Tim Roberts : > solotim wrote: >> Now I encounter another question. When the device got plugged into the >> host machine, there is no MSI address/data being assigned by the >> system. I used RW-everything to look through the PCI configuration >> space of my device. I don’t know if there is anything to do with my >> driver. So later I just installed my driver with MSI-enable-declared >> inf (http://msdn.microsoft.com/en-us/library/windows/hardware/ff544246(v=vs.85).aspx), >> but the MSI Capability registers are still empty. >> >> How to make the system recognize my device as a MSI supported device >> and write MSI addr/data to the PCI configuration space? > > Which operating system? ?XP does not support MSI at all. ?Your board > must support the “legacy” INTx interrupts in order to work on XP. > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Ok, I’ve found the root cause. Actually there is a problem in my inf
file and chkinf.bat gave a warning which I didn’t pay attention to.
Now everything is fine. Thanks, guys.
Cheers,
-solotim
2012/2/9 solotim : > It’s Windows 7 64 bit. > I can see that the USB controller on the PC system is assigned with a > MSI addr/data, so I’m sure that MSI is able to work on this machine. > > 2012/2/9 Tim Roberts : >> solotim wrote: >>> Now I encounter another question. When the device got plugged into the >>> host machine, there is no MSI address/data being assigned by the >>> system. I used RW-everything to look through the PCI configuration >>> space of my device. I don’t know if there is anything to do with my >>> driver. So later I just installed my driver with MSI-enable-declared >>> inf (http://msdn.microsoft.com/en-us/library/windows/hardware/ff544246(v=vs.85).aspx), >>> but the MSI Capability registers are still empty. >>> >>> How to make the system recognize my device as a MSI supported device >>> and write MSI addr/data to the PCI configuration space? >> >> Which operating system? ?XP does not support MSI at all. ?Your board >> must support the “legacy” INTx interrupts in order to work on XP. >> >> – >> Tim Roberts, xxxxx@probo.com >> Providenza & Boekelheide, Inc. >> >> >> — >> NTDEV is sponsored by OSR >> >> For our schedule of WDF, WDM, debugging and other seminars visit: >> http://www.osr.com/seminars >> >> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
It’s Windows 7 64 bit.
I can see that the USB controller on the PC system is assigned with a
MSI addr/data, so I’m sure that MSI is able to work on this machine.
Have you checked the registry to make sure your INF settings actually
took effect?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Yes, it’s an inf problem. I’ve fixed it. Thank you, Tim.
-solotim
2012/2/10 Tim Roberts : > solotim wrote: >> It’s Windows 7 64 bit. >> I can see that the USB controller on the PC system is assigned with a >> MSI addr/data, so I’m sure that MSI is able to work on this machine. > > Have you checked the registry to make sure your INF settings actually > took effect? > > – > Tim Roberts, xxxxx@probo.com > Providenza & Boekelheide, Inc. > > > — > NTDEV is sponsored by OSR > > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
