pci configuration space

NTDEV
1

I have some driver code that I’ve inherited that is probing the PCI
configuration register. ie:

WRITE_PORT_ULONG( (PULONG)0xCF8, (ULONG)0x8000F858 );

What might be a better way of doing this through the HAL? More specifically
what does the 0xf858 part of the second argument mean?

thanks,

----- Original Message -----
From: “Roddy, Mark”
To: “Windows System Software Devs Interest List”
Sent: Monday, October 04, 2004 2:41 PM
Subject: RE: [ntdev] DISPATCH_LEVEL and SMP

> KeAcquireSpinLock is implemented with the help of locked instructions but
> not only by locked instructions. Step through spinlock acquire/release on
a
> SMP or HT system for the gory details. X86 locked instructions provide
> identical behavior on HT systems as they do on SMP systems, at least as
far
> as observed behavior is concerned. As an SMP system can also be an HT
> system, this is pretty much a requirement, right?
>
>
>
> =====================
> Mark Roddy
>
> -----Original Message-----
> From: Ta H. [mailto:xxxxx@hotmail.com]
> Sent: Monday, October 04, 2004 5:29 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
>
> Thanks.
>
> One more thing I am not sure if it is related. As far as I know,
> KeAcquireSpinLock() is implemented by “lock prefix” for x86. Does “lock
> prefix” for HT behave the same as it does for SMP?
>
> AH
>
>
> >From: “Mark Roddy”
> >Reply-To: “Windows System Software Devs Interest List”
> >
> >To: “Windows System Software Devs Interest List”
> >Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> >Date: Sat, 2 Oct 2004 08:06:44 -0400
> >
> >Yes. That is the point of executive spinlocks - they provide atomic
> >operations for both SMP and UP systems for all threads <= DISPATCH_LEVEL.
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of Ta H.
> > > Sent: Saturday, October 02, 2004 2:28 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] DISPATCH_LEVEL and SMP
> > >
> > > How would NT ensure the spin lock would be safe for the SMP
> > > (HT) case? I have a situation that 2 DISPATCH_LEVEL threads may
> > > try to touch the same HW register in my PCI card. Will a spin lock
> > > suffice?
> > >
> > > AH
> > >
> > >
> > > Express yourself instantly with MSN Messenger! Download today
> > > - it’s FREE!
> > > hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > > xxxxx@hollistech.com To unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> > >
> >
> >
> >
> >
> >
> >—
> >Questions? First check the Kernel Driver FAQ at
> >http://www.osronline.com/article.cfm?id=256
> >
> >You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> >unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> Express yourself instantly with MSN Messenger! Download today - it’s FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@stratus.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

2

I think I got it:

f8 - is the device id and function # (bits 7:3 device id, bits 2:0 function
#).
58 - is the offset

in this case I can use the HalGetBusData.

Is this a safe assumption?

thanks,

Greg

----- Original Message -----
From: “Greg Jacklin”
To: “Windows System Software Devs Interest List”
Sent: Monday, October 04, 2004 9:24 PM
Subject: [ntdev] pci configuration space

> I have some driver code that I’ve inherited that is probing the PCI
> configuration register. ie:
>
> WRITE_PORT_ULONG( (PULONG)0xCF8, (ULONG)0x8000F858 );
>
>
>
> What might be a better way of doing this through the HAL? More
specifically
> what does the 0xf858 part of the second argument mean?
>
>
>
> thanks,
>
>
>
>
>
>
>
> ----- Original Message -----
> From: “Roddy, Mark”
> To: “Windows System Software Devs Interest List”
> Sent: Monday, October 04, 2004 2:41 PM
> Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
>
>
> > KeAcquireSpinLock is implemented with the help of locked instructions
but
> > not only by locked instructions. Step through spinlock acquire/release
on
> a
> > SMP or HT system for the gory details. X86 locked instructions provide
> > identical behavior on HT systems as they do on SMP systems, at least as
> far
> > as observed behavior is concerned. As an SMP system can also be an HT
> > system, this is pretty much a requirement, right?
> >
> >
> >
> > =====================
> > Mark Roddy
> >
> > -----Original Message-----
> > From: Ta H. [mailto:xxxxx@hotmail.com]
> > Sent: Monday, October 04, 2004 5:29 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> >
> > Thanks.
> >
> > One more thing I am not sure if it is related. As far as I know,
> > KeAcquireSpinLock() is implemented by “lock prefix” for x86. Does “lock
> > prefix” for HT behave the same as it does for SMP?
> >
> > AH
> >
> >
> > >From: “Mark Roddy”
> > >Reply-To: “Windows System Software Devs Interest List”
> > >
> > >To: “Windows System Software Devs Interest List”
> > >Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > >Date: Sat, 2 Oct 2004 08:06:44 -0400
> > >
> > >Yes. That is the point of executive spinlocks - they provide atomic
> > >operations for both SMP and UP systems for all threads <=
DISPATCH_LEVEL.
> > >
> > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Ta H.
> > > > Sent: Saturday, October 02, 2004 2:28 AM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: [ntdev] DISPATCH_LEVEL and SMP
> > > >
> > > > How would NT ensure the spin lock would be safe for the SMP
> > > > (HT) case? I have a situation that 2 DISPATCH_LEVEL threads may
> > > > try to touch the same HW register in my PCI card. Will a spin lock
> > > > suffice?
> > > >
> > > > AH
> > > >
> > > >
> > > > Express yourself instantly with MSN Messenger! Download today
> > > > - it’s FREE!
> > > > hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as:
> > > > xxxxx@hollistech.com To unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > > >
> > >
> > >
> > >
> > >
> > >
> > >—
> > >Questions? First check the Kernel Driver FAQ at
> > >http://www.osronline.com/article.cfm?id=256
> > >
> > >You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > >unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > Express yourself instantly with MSN Messenger! Download today - it’s
FREE!
> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

3

> f8 - is the device id and function # (bits 7:3 device id, bits 2:0
function

#).
58 - is the offset

in this case I can use the HalGetBusData.

Is this a safe assumption?

Or HalGetBusDataByOffset, since you have an offset involved.

Both of which are depreciated interfaces that you really shouldn’t be using,
unless this is an NT 4.0 style driver, or you for some reason have to poke
at a card other than the one your driver controls.

If this is a PnP driver and you want the info from your card, ther is an
interface to get this information specifically for your card.

Loren

4

No actually,

8000F858

The high bit is the enabled bit, and should always be set for any present
PCI device.

bits 0-23 collectively make up the bus-dev-func-reg value

bus = bits 16-23
device = bits 11-15
function = bits 8-10
register = bits 2-7

bits 0-1 are always zero I believe.

I knew this old BIOS stuff would come in handy some day :slight_smile:

Do not ever use CF8/CFC(CFD, CFE, CFF) I/O ports to read PCI config space on
NT based platforms.

On NT4 platforms it was required that the driver walk the PCI config space
using HAL calls like HalGetBusDataByOffset. This was the only way the
driver could find its device and get the proper resources assigned. This
methodology is obsolete on 2000 and later platforms. Plug and play (PnP)
has eliminated the driver’s need to do any of this.

In general, you are no longer allowed to walk PCI config space under 2000
and later NT based Windows platforms. That is now the job of the PCI bus
driver. What you are allowed to do is access the PCI registers for your
device. These are handed to your driver via the IRP: IRP_MJ_PNP
IRP_MN_START_DEVICE.

I would highly suggest you get a good book on Windows device drivers such as
Walter Oney’s “Programming the Windows Driver Model 2nd Ed.” Walter has
some good PCI examples with source on the CD that comes with that book.

–
Bill McKenzie
Software Engineer - Prism 802.11 Wireless Solutions
Conexant Systems, Inc.

“Greg Jacklin” wrote in message news:xxxxx@ntdev…
> I think I got it:
>
> f8 - is the device id and function # (bits 7:3 device id, bits 2:0
function
> #).
> 58 - is the offset
>
> in this case I can use the HalGetBusData.
>
> Is this a safe assumption?
>
> thanks,
>
> Greg
>
> ----- Original Message -----
> From: “Greg Jacklin”
> To: “Windows System Software Devs Interest List”
> Sent: Monday, October 04, 2004 9:24 PM
> Subject: [ntdev] pci configuration space
>
>
> > I have some driver code that I’ve inherited that is probing the PCI
> > configuration register. ie:
> >
> > WRITE_PORT_ULONG( (PULONG)0xCF8, (ULONG)0x8000F858 );
> >
> >
> >
> > What might be a better way of doing this through the HAL? More
> specifically
> > what does the 0xf858 part of the second argument mean?
> >
> >
> >
> > thanks,
> >
> >
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > From: “Roddy, Mark”
> > To: “Windows System Software Devs Interest List”
> > Sent: Monday, October 04, 2004 2:41 PM
> > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> >
> >
> > > KeAcquireSpinLock is implemented with the help of locked instructions
> but
> > > not only by locked instructions. Step through spinlock acquire/release
> on
> > a
> > > SMP or HT system for the gory details. X86 locked instructions provide
> > > identical behavior on HT systems as they do on SMP systems, at least
as
> > far
> > > as observed behavior is concerned. As an SMP system can also be an HT
> > > system, this is pretty much a requirement, right?
> > >
> > >
> > >
> > > =====================
> > > Mark Roddy
> > >
> > > -----Original Message-----
> > > From: Ta H. [mailto:xxxxx@hotmail.com]
> > > Sent: Monday, October 04, 2004 5:29 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > >
> > > Thanks.
> > >
> > > One more thing I am not sure if it is related. As far as I know,
> > > KeAcquireSpinLock() is implemented by “lock prefix” for x86. Does
“lock
> > > prefix” for HT behave the same as it does for SMP?
> > >
> > > AH
> > >
> > >
> > > >From: “Mark Roddy”
> > > >Reply-To: “Windows System Software Devs Interest List”
> > > >
> > > >To: “Windows System Software Devs Interest List”

> > > >Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > > >Date: Sat, 2 Oct 2004 08:06:44 -0400
> > > >
> > > >Yes. That is the point of executive spinlocks - they provide atomic
> > > >operations for both SMP and UP systems for all threads <=
> DISPATCH_LEVEL.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: xxxxx@lists.osr.com
> > > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Ta H.
> > > > > Sent: Saturday, October 02, 2004 2:28 AM
> > > > > To: Windows System Software Devs Interest List
> > > > > Subject: [ntdev] DISPATCH_LEVEL and SMP
> > > > >
> > > > > How would NT ensure the spin lock would be safe for the SMP
> > > > > (HT) case? I have a situation that 2 DISPATCH_LEVEL threads may
> > > > > try to touch the same HW register in my PCI card. Will a spin
lock
> > > > > suffice?
> > > > >
> > > > > AH
> > > > >
> > > > >
> > > > > Express yourself instantly with MSN Messenger! Download today
> > > > > - it’s FREE!
> > > > > hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > > > >
> > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as:
> > > > > xxxxx@hollistech.com To unsubscribe send a blank email to
> > > > > xxxxx@lists.osr.com
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >—
> > > >Questions? First check the Kernel Driver FAQ at
> > > >http://www.osronline.com/article.cfm?id=256
> > > >
> > > >You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > > >unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > Express yourself instantly with MSN Messenger! Download today - it’s
> FREE!
> > > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>

5

What is the driver attempting to accomplish by probing this specific
device/function?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Jacklin
Sent: Tuesday, October 05, 2004 1:17 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] pci configuration space

I think I got it:

f8 - is the device id and function # (bits 7:3 device id,
bits 2:0 function #).
58 - is the offset

in this case I can use the HalGetBusData.

Is this a safe assumption?

thanks,

Greg

----- Original Message -----
From: “Greg Jacklin”
> To: “Windows System Software Devs Interest List”
> Sent: Monday, October 04, 2004 9:24 PM
> Subject: [ntdev] pci configuration space
>
>
> > I have some driver code that I’ve inherited that is probing the PCI
> > configuration register. ie:
> >
> > WRITE_PORT_ULONG( (PULONG)0xCF8, (ULONG)0x8000F858 );
> >
> >
> >
> > What might be a better way of doing this through the HAL? More
> specifically
> > what does the 0xf858 part of the second argument mean?
> >
> >
> >
> > thanks,
> >
> >
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > From: “Roddy, Mark”
> > To: “Windows System Software Devs Interest List”
>
> > Sent: Monday, October 04, 2004 2:41 PM
> > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> >
> >
> > > KeAcquireSpinLock is implemented with the help of locked
> instructions
> but
> > > not only by locked instructions. Step through spinlock
> acquire/release
> on
> > a
> > > SMP or HT system for the gory details. X86 locked
> instructions provide
> > > identical behavior on HT systems as they do on SMP
> systems, at least as
> > far
> > > as observed behavior is concerned. As an SMP system can
> also be an HT
> > > system, this is pretty much a requirement, right?
> > >
> > >
> > >
> > > =====================
> > > Mark Roddy
> > >
> > > -----Original Message-----
> > > From: Ta H. [mailto:xxxxx@hotmail.com]
> > > Sent: Monday, October 04, 2004 5:29 PM
> > > To: Windows System Software Devs Interest List
> > > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > >
> > > Thanks.
> > >
> > > One more thing I am not sure if it is related. As far as I know,
> > > KeAcquireSpinLock() is implemented by “lock prefix” for
> x86. Does “lock
> > > prefix” for HT behave the same as it does for SMP?
> > >
> > > AH
> > >
> > >
> > > >From: “Mark Roddy”
> > > >Reply-To: “Windows System Software Devs Interest List”
> > > >
> > > >To: “Windows System Software Devs Interest List”
>
> > > >Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > > >Date: Sat, 2 Oct 2004 08:06:44 -0400
> > > >
> > > >Yes. That is the point of executive spinlocks - they
> provide atomic
> > > >operations for both SMP and UP systems for all threads <=
> DISPATCH_LEVEL.
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: xxxxx@lists.osr.com
> > > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Ta H.
> > > > > Sent: Saturday, October 02, 2004 2:28 AM
> > > > > To: Windows System Software Devs Interest List
> > > > > Subject: [ntdev] DISPATCH_LEVEL and SMP
> > > > >
> > > > > How would NT ensure the spin lock would be safe for the SMP
> > > > > (HT) case? I have a situation that 2 DISPATCH_LEVEL
> threads may
> > > > > try to touch the same HW register in my PCI card.
> Will a spin lock
> > > > > suffice?
> > > > >
> > > > > AH
> > > > >
> > > > >
>
> > > > > Express yourself instantly with MSN Messenger! Download today
> > > > > - it’s FREE!
> > > > >
> hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > > > >
> > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as:
> > > > > xxxxx@hollistech.com To unsubscribe send a blank email to
> > > > > xxxxx@lists.osr.com
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >—
> > > >Questions? First check the Kernel Driver FAQ at
> > > >http://www.osronline.com/article.cfm?id=256
> > > >
> > > >You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > > >unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > Express yourself instantly with MSN Messenger! Download
> today - it’s
> FREE!
> > > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> xxxxx@stratus.com To
> > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

6

Bad code. Query the device interface from the PnP stack below, and use
these calls to work with the PCI config space.

On newer chipsets, the port 0xcf8 can begone.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Greg Jacklin”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 05, 2004 8:24 AM
Subject: [ntdev] pci configuration space

> I have some driver code that I’ve inherited that is probing the PCI
> configuration register. ie:
>
> WRITE_PORT_ULONG( (PULONG)0xCF8, (ULONG)0x8000F858 );
>
>
>
> What might be a better way of doing this through the HAL? More specifically
> what does the 0xf858 part of the second argument mean?
>
>
>
> thanks,
>
>
>
>
>
>
>
> ----- Original Message -----
> From: “Roddy, Mark”
> To: “Windows System Software Devs Interest List”
> Sent: Monday, October 04, 2004 2:41 PM
> Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
>
>
> > KeAcquireSpinLock is implemented with the help of locked instructions but
> > not only by locked instructions. Step through spinlock acquire/release on
> a
> > SMP or HT system for the gory details. X86 locked instructions provide
> > identical behavior on HT systems as they do on SMP systems, at least as
> far
> > as observed behavior is concerned. As an SMP system can also be an HT
> > system, this is pretty much a requirement, right?
> >
> >
> >
> > =====================
> > Mark Roddy
> >
> > -----Original Message-----
> > From: Ta H. [mailto:xxxxx@hotmail.com]
> > Sent: Monday, October 04, 2004 5:29 PM
> > To: Windows System Software Devs Interest List
> > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> >
> > Thanks.
> >
> > One more thing I am not sure if it is related. As far as I know,
> > KeAcquireSpinLock() is implemented by “lock prefix” for x86. Does “lock
> > prefix” for HT behave the same as it does for SMP?
> >
> > AH
> >
> >
> > >From: “Mark Roddy”
> > >Reply-To: “Windows System Software Devs Interest List”
> > >
> > >To: “Windows System Software Devs Interest List”
> > >Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > >Date: Sat, 2 Oct 2004 08:06:44 -0400
> > >
> > >Yes. That is the point of executive spinlocks - they provide atomic
> > >operations for both SMP and UP systems for all threads <= DISPATCH_LEVEL.
> > >
> > >
> > > > -----Original Message-----
> > > > From: xxxxx@lists.osr.com
> > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Ta H.
> > > > Sent: Saturday, October 02, 2004 2:28 AM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: [ntdev] DISPATCH_LEVEL and SMP
> > > >
> > > > How would NT ensure the spin lock would be safe for the SMP
> > > > (HT) case? I have a situation that 2 DISPATCH_LEVEL threads may
> > > > try to touch the same HW register in my PCI card. Will a spin lock
> > > > suffice?
> > > >
> > > > AH
> > > >
> > > >
> > > > Express yourself instantly with MSN Messenger! Download today
> > > > - it’s FREE!
> > > > hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as:
> > > > xxxxx@hollistech.com To unsubscribe send a blank email to
> > > > xxxxx@lists.osr.com
> > > >
> > >
> > >
> > >
> > >
> > >
> > >—
> > >Questions? First check the Kernel Driver FAQ at
> > >http://www.osronline.com/article.cfm?id=256
> > >
> > >You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > >unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > Express yourself instantly with MSN Messenger! Download today - it’s FREE!
> > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@stratus.com To
> > unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com

7

I have to get hold of the GPIO pins base address space. These pins are are
used to control some LED’s. As you can see this is a “fixed” hardware
solution and not entirely standard.

----- Original Message -----
From: “Mark Roddy”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 05, 2004 4:30 AM
Subject: RE: [ntdev] pci configuration space

> What is the driver attempting to accomplish by probing this specific
> device/function?
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Greg Jacklin
> > Sent: Tuesday, October 05, 2004 1:17 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] pci configuration space
> >
> > I think I got it:
> >
> > f8 - is the device id and function # (bits 7:3 device id,
> > bits 2:0 function #).
> > 58 - is the offset
> >
> > in this case I can use the HalGetBusData.
> >
> > Is this a safe assumption?
> >
> > thanks,
> >
> > Greg
> >
> > ----- Original Message -----
> > From: “Greg Jacklin”
> > To: “Windows System Software Devs Interest List”
> > Sent: Monday, October 04, 2004 9:24 PM
> > Subject: [ntdev] pci configuration space
> >
> >
> > > I have some driver code that I’ve inherited that is probing the PCI
> > > configuration register. ie:
> > >
> > > WRITE_PORT_ULONG( (PULONG)0xCF8, (ULONG)0x8000F858 );
> > >
> > >
> > >
> > > What might be a better way of doing this through the HAL? More
> > specifically
> > > what does the 0xf858 part of the second argument mean?
> > >
> > >
> > >
> > > thanks,
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: “Roddy, Mark”
> > > To: “Windows System Software Devs Interest List”
> >
> > > Sent: Monday, October 04, 2004 2:41 PM
> > > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > >
> > >
> > > > KeAcquireSpinLock is implemented with the help of locked
> > instructions
> > but
> > > > not only by locked instructions. Step through spinlock
> > acquire/release
> > on
> > > a
> > > > SMP or HT system for the gory details. X86 locked
> > instructions provide
> > > > identical behavior on HT systems as they do on SMP
> > systems, at least as
> > > far
> > > > as observed behavior is concerned. As an SMP system can
> > also be an HT
> > > > system, this is pretty much a requirement, right?
> > > >
> > > >
> > > >
> > > > =====================
> > > > Mark Roddy
> > > >
> > > > -----Original Message-----
> > > > From: Ta H. [mailto:xxxxx@hotmail.com]
> > > > Sent: Monday, October 04, 2004 5:29 PM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > > >
> > > > Thanks.
> > > >
> > > > One more thing I am not sure if it is related. As far as I know,
> > > > KeAcquireSpinLock() is implemented by “lock prefix” for
> > x86. Does “lock
> > > > prefix” for HT behave the same as it does for SMP?
> > > >
> > > > AH
> > > >
> > > >
> > > > >From: “Mark Roddy”
> > > > >Reply-To: “Windows System Software Devs Interest List”
> > > > >
> > > > >To: “Windows System Software Devs Interest List”
> >
> > > > >Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > > > >Date: Sat, 2 Oct 2004 08:06:44 -0400
> > > > >
> > > > >Yes. That is the point of executive spinlocks - they
> > provide atomic
> > > > >operations for both SMP and UP systems for all threads <=
> > DISPATCH_LEVEL.
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: xxxxx@lists.osr.com
> > > > > > [mailto:xxxxx@lists.osr.com] On Behalf Of Ta H.
> > > > > > Sent: Saturday, October 02, 2004 2:28 AM
> > > > > > To: Windows System Software Devs Interest List
> > > > > > Subject: [ntdev] DISPATCH_LEVEL and SMP
> > > > > >
> > > > > > How would NT ensure the spin lock would be safe for the SMP
> > > > > > (HT) case? I have a situation that 2 DISPATCH_LEVEL
> > threads may
> > > > > > try to touch the same HW register in my PCI card.
> > Will a spin lock
> > > > > > suffice?
> > > > > >
> > > > > > AH
> > > > > >
> > > > > >
> >
> > > > > > Express yourself instantly with MSN Messenger! Download today
> > > > > > - it’s FREE!
> > > > > >
> > hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > > > > >
> > > > > >
> > > > > >
> > > > > > —
> > > > > > Questions? First check the Kernel Driver FAQ at
> > > > > > http://www.osronline.com/article.cfm?id=256
> > > > > >
> > > > > > You are currently subscribed to ntdev as:
> > > > > > xxxxx@hollistech.com To unsubscribe send a blank email to
> > > > > > xxxxx@lists.osr.com
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >—
> > > > >Questions? First check the Kernel Driver FAQ at
> > > > >http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > >You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > > > >unsubscribe send a blank email to xxxxx@lists.osr.com
> > > >
> > > >
> > > > Express yourself instantly with MSN Messenger! Download
> > today - it’s
> > FREE!
> > > > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To
> > > > unsubscribe send a blank email to xxxxx@lists.osr.com
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > > > To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > > To unsubscribe send a blank email to xxxxx@lists.osr.com
> > >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@hollistech.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

8

So write a function or filter driver for the pci device that provides the
GPIO pins.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Greg Jacklin
Sent: Tuesday, October 05, 2004 5:58 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] pci configuration space

I have to get hold of the GPIO pins base address space.
These pins are are used to control some LED’s. As you can
see this is a “fixed” hardware solution and not entirely standard.

----- Original Message -----
From: “Mark Roddy”
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, October 05, 2004 4:30 AM
> Subject: RE: [ntdev] pci configuration space
>
>
> > What is the driver attempting to accomplish by probing this specific
> > device/function?
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > > [mailto:xxxxx@lists.osr.com] On Behalf Of
> Greg Jacklin
> > > Sent: Tuesday, October 05, 2004 1:17 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re: [ntdev] pci configuration space
> > >
> > > I think I got it:
> > >
> > > f8 - is the device id and function # (bits 7:3 device id,
> > > bits 2:0 function #).
> > > 58 - is the offset
> > >
> > > in this case I can use the HalGetBusData.
> > >
> > > Is this a safe assumption?
> > >
> > > thanks,
> > >
> > > Greg
> > >
> > > ----- Original Message -----
> > > From: “Greg Jacklin”
> > > To: “Windows System Software Devs Interest List”
>
> > > Sent: Monday, October 04, 2004 9:24 PM
> > > Subject: [ntdev] pci configuration space
> > >
> > >
> > > > I have some driver code that I’ve inherited that is
> probing the PCI
> > > > configuration register. ie:
> > > >
> > > > WRITE_PORT_ULONG( (PULONG)0xCF8, (ULONG)0x8000F858 );
> > > >
> > > >
> > > >
> > > > What might be a better way of doing this through the HAL? More
> > > specifically
> > > > what does the 0xf858 part of the second argument mean?
> > > >
> > > >
> > > >
> > > > thanks,
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: “Roddy, Mark”
> > > > To: “Windows System Software Devs Interest List”
> > >
> > > > Sent: Monday, October 04, 2004 2:41 PM
> > > > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > > >
> > > >
> > > > > KeAcquireSpinLock is implemented with the help of locked
> > > instructions
> > > but
> > > > > not only by locked instructions. Step through spinlock
> > > acquire/release
> > > on
> > > > a
> > > > > SMP or HT system for the gory details. X86 locked
> > > instructions provide
> > > > > identical behavior on HT systems as they do on SMP
> > > systems, at least as
> > > > far
> > > > > as observed behavior is concerned. As an SMP system can
> > > also be an HT
> > > > > system, this is pretty much a requirement, right?
> > > > >
> > > > >
> > > > >
> > > > > =====================
> > > > > Mark Roddy
> > > > >
> > > > > -----Original Message-----
> > > > > From: Ta H. [mailto:xxxxx@hotmail.com]
> > > > > Sent: Monday, October 04, 2004 5:29 PM
> > > > > To: Windows System Software Devs Interest List
> > > > > Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > > > >
> > > > > Thanks.
> > > > >
> > > > > One more thing I am not sure if it is related. As
> far as I know,
> > > > > KeAcquireSpinLock() is implemented by “lock prefix” for
> > > x86. Does “lock
> > > > > prefix” for HT behave the same as it does for SMP?
> > > > >
> > > > > AH
> > > > >
> > > > >
> > > > > >From: “Mark Roddy”
> > > > > >Reply-To: “Windows System Software Devs Interest List”
> > > > > >
> > > > > >To: “Windows System Software Devs Interest List”
> > >
> > > > > >Subject: RE: [ntdev] DISPATCH_LEVEL and SMP
> > > > > >Date: Sat, 2 Oct 2004 08:06:44 -0400
> > > > > >
> > > > > >Yes. That is the point of executive spinlocks - they
> > > provide atomic
> > > > > >operations for both SMP and UP systems for all threads <=
> > > DISPATCH_LEVEL.
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: xxxxx@lists.osr.com
> > > > > > > [mailto:xxxxx@lists.osr.com] On
> Behalf Of Ta H.
> > > > > > > Sent: Saturday, October 02, 2004 2:28 AM
> > > > > > > To: Windows System Software Devs Interest List
> > > > > > > Subject: [ntdev] DISPATCH_LEVEL and SMP
> > > > > > >
> > > > > > > How would NT ensure the spin lock would be safe
> for the SMP
> > > > > > > (HT) case? I have a situation that 2 DISPATCH_LEVEL
> > > threads may
> > > > > > > try to touch the same HW register in my PCI card.
> > > Will a spin lock
> > > > > > > suffice?
> > > > > > >
> > > > > > > AH
> > > > > > >
> > > > > > >
> > >
> > > > > > > Express yourself instantly with MSN Messenger!
> Download today
> > > > > > > - it’s FREE!
> > > > > > >
> > > hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > —
> > > > > > > Questions? First check the Kernel Driver FAQ at
> > > > > > > http://www.osronline.com/article.cfm?id=256
> > > > > > >
> > > > > > > You are currently subscribed to ntdev as:
> > > > > > > xxxxx@hollistech.com To unsubscribe send a blank email to
> > > > > > > xxxxx@lists.osr.com
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >—
> > > > > >Questions? First check the Kernel Driver FAQ at
> > > > > >http://www.osronline.com/article.cfm?id=256
> > > > > >
> > > > > >You are currently subscribed to ntdev as: xxxxx@hotmail.com To
> > > > > >unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > > >
> > > > >
>
> > > > > Express yourself instantly with MSN Messenger! Download
> > > today - it’s
> > > FREE!
> > > > >
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> > > > >
> > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as:
> > > xxxxx@stratus.com To
> > > > > unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > > >
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > > > > To unsubscribe send a blank email to
> > > xxxxx@lists.osr.com
> > > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as: xxxxx@hollistech.com
> > > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
> > >
> >
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@hotmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>