Atomic Port I/O
Phil
outb(0x07, 0x2E); // Select Super I/O Logical Device Number
register
outb(0x09, 0x2F); // Select Super I/O Logical Device 9 register
set
outb(0x30, 0x2E); // Select Super I/O Logical Device 9 Enable
register
outb(0x01, 0x2F); // Enable Super I/O Logical Device 9
If I do this in a Windows XP kernel driver, how to I prevent other
drivers (on a different thread or in a different CPU core) from
writing to ports 0x2E and 0x2F between the first and last statements
above? I'm pretty sure that other drivers output to port 0x2E, like
the standard Microsoft serial port driver when a Super I/O serial port
is opened.
Are their certain sections of a WDM driver (or any other type of
kernel driver) that are "single threaded". For instance, is the
DriverEntry() for each driver called on the same thread during system
startup? This will help the setup of the Super I/O Logical Devices at
startup time. However, I still need to perform the same pattern of
port I/O on an interrupt basis.
If I can identify the other drivers that access port 0x2E and 0x2F,
can I wrap these drivers somehow to serialize access to these ports?
- Phil
Don Burn
with it at all without likely crashing the system. There is nothing you can
trust to do this, and particularily not at interrupt time. Unless the super
I/O chip driver is a bus driver that destributes this functionality forget
it.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Phil" <GoogleGr...@ipavilion.com> wrote in message
news:bd89c9e3-630f-4c94...@l64g2000hse.googlegroups.com...
Tim Roberts
>
>I need to write to a Super I/O chip using port I/O, such as,
>
> outb(0x07, 0x2E); // Select Super I/O Logical Device Number
>register
> outb(0x09, 0x2F); // Select Super I/O Logical Device 9 register
>set
> outb(0x30, 0x2E); // Select Super I/O Logical Device 9 Enable
>register
> outb(0x01, 0x2F); // Enable Super I/O Logical Device 9
Note that you're using the Linux parameter order here. In Windows, the
arguments to outp/outpw/outpd are (port, data), although I'm sure you would
use the blessed WRITE_PORT_UCHAR macro instead.
You can reduce the exposure slightly by writing both ports at once:
outpw( 0x2e, 0x0907 );
outpw( 0x2e, 0x0130 );
but it's still not guaranteed.
>If I do this in a Windows XP kernel driver, how to I prevent other
>drivers (on a different thread or in a different CPU core) from
>writing to ports 0x2E and 0x2F between the first and last statements
>above? I'm pretty sure that other drivers output to port 0x2E, like
>the standard Microsoft serial port driver when a Super I/O serial port
>is opened.
I doubt it. I would guess that these registers are set up by the BIOS, and
not touched by Windows.
>...However, I still need to perform the same pattern of
>port I/O on an interrupt basis.
Really? May I ask what you are trying to accomplish? Most of the Super
I/O registers are designed to be manipulated at boot time only.
Remember that I/O access is hopelessly slow. Each outp takes roughly a
microsecond.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Phil
> Phil <GoogleGroupsP...@ipavilion.com> wrote:
>
> >I need to write to a Super I/O chip using port I/O, such as,
>
> > outb(0x07, 0x2E); // Select Super I/O Logical Device Number
> >register
> > outb(0x09, 0x2F); // Select Super I/O Logical Device 9 register
> >set
> > outb(0x30, 0x2E); // Select Super I/O Logical Device 9 Enable
> >register
> > outb(0x01, 0x2F); // Enable Super I/O Logical Device 9
>
> Note that you're using the Linux parameter order here. In Windows, the
> arguments to outp/outpw/outpd are (port, data), although I'm sure you would
> use the blessed WRITE_PORT_UCHAR macro instead.
Correct.
> You can reduce the exposure slightly by writing both ports at once:
> outpw( 0x2e, 0x0907 );
> outpw( 0x2e, 0x0130 );
> but it's still not guaranteed.
That is a step in the right direction.
>
> >If I do this in a Windows XP kernel driver, how to I prevent other
> >drivers (on a different thread or in a different CPU core) from
> >writing to ports 0x2E and 0x2F between the first and last statements
> >above? I'm pretty sure that other drivers output to port 0x2E, like
> >the standard Microsoft serial port driver when a Super I/O serial port
> >is opened.
>
> I doubt it. I would guess that these registers are set up by the BIOS, and
> not touched by Windows.
I have seen the Logical Device Number register change when a serial
port is opened under Windows XP. This might be to get or set the base
I/O port address or IRQ. Seeing this happen started to make me
concerned about stepping on the toes of Windows-supplied drivers.
>
> >...However, I still need to perform the same pattern of
> >port I/O on an interrupt basis.
>
> Really? May I ask what you are trying to accomplish? Most of the Super
> I/O registers are designed to be manipulated at boot time only.
One need is to access the GPIO states of the Super I/O chip on an
interrupt basis, which I don't think is supported by a standard
Windows driver. Another is to access the voltage level sensors, but
this would be polled.
>
> Remember that I/O access is hopelessly slow. Each outp takes roughly a
> microsecond.
Can I disable interrupts across the I/O to make it atomic? I wasn't
sure if that would have the desired effect, especially on a dual core
CPU.
> --
> Tim Roberts, t...@probo.com
> Providenza & Boekelheide, Inc.
- Phil
Phil
serial port is opened. I imagine that the same thing happens when the
parallel port is opened. So, I have wondered, how does Windows manage
this type of potential conflict? How can I determine if a bus driver
is used to access the Super I/O chip?
- Phil
On Apr 17, 6:24 pm, "Don Burn" <b...@stopspam.windrvr.com> wrote:
> You can't, you driver does not own the super I/O chip so you cannot muck
> with it at all without likely crashing the system. There is nothing you can
> trust to do this, and particularily not at interrupt time. Unless the super
> I/O chip driver is a bus driver that destributes this functionality forget
> it.
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website:http://www.windrvr.com
> Blog:http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> "Phil" <GoogleGroupsP...@ipavilion.com> wrote in message
>
> news:bd89c9e3-630f-4c94...@l64g2000hse.googlegroups.com...
>
>
>
> >I need to write to a Super I/O chip using port I/O, such as,
>
> > outb(0x07, 0x2E); // Select Super I/O Logical Device Number
> > register
> > outb(0x09, 0x2F); // Select Super I/O Logical Device 9 register
> > set
> > outb(0x30, 0x2E); // Select Super I/O Logical Device 9 Enable
> > register
> > outb(0x01, 0x2F); // Enable Super I/O Logical Device 9
>
> > If I do this in a Windows XP kernel driver, how to I prevent other
> > drivers (on a different thread or in a different CPU core) from
> > writing to ports 0x2E and 0x2F between the first and last statements
> > above? I'm pretty sure that other drivers output to port 0x2E, like
> > the standard Microsoft serial port driver when a Super I/O serial port
> > is opened.
>
> > Are their certain sections of a WDM driver (or any other type of
> > kernel driver) that are "single threaded". For instance, is the
> > DriverEntry() for each driver called on the same thread during system
> > startup? This will help the setup of the Super I/O Logical Devices at
> > startup time. However, I still need to perform the same pattern of
> > port I/O on an interrupt basis.
>
> > If I can identify the other drivers that access port 0x2E and 0x2F,
> > can I wrap these drivers somehow to serialize access to these ports?
>
> > - Phil- Hide quoted text -
>
> - Show quoted text -
Don Burn
never be done. You can do some games to corral all CPU's but that still
does not protect against the legitimate owner of the super I/O chip being in
the middle of a write to it and your driver stomping on the write. Also,
corralling the CPU's is going to destroy the systems performance.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Phil" <GoogleGr...@ipavilion.com> wrote in message
news:bf033ea4-0c29-45e5...@x41g2000hsb.googlegroups.com...
Ben Voigt [C++ MVP]
> Disabling interrupts is worthless in Windows, it breaks thing and
> should never be done. You can do some games to corral all CPU's but
> that still does not protect against the legitimate owner of the super
> I/O chip being in the middle of a write to it and your driver
> stomping on the write. Also, corralling the CPU's is going to
> destroy the systems performance.
Meaning that he needs to become the legitimate owner of the super I/O
chip -- i.e. replace the existing driver accessing these ports. Maybe
someone can give him some advice on how to identify which driver it is... my
guess is Device Manager -> View Resources By Type.
On my system (32-bit XP Pro SP2) port 0x2E and 0x2F (actually 0x20-0x3F) are
claimed by Programmable Interrupt Controller, and something funny is clearly
going on. Device Manager shows a Microsoft driver with version number
matching the OS, but driver details reveals National Instruments has
substituted nipbcfk.sys. This sounds suspiciously like someone else has
already faced the same problem and solved it -- after a fashion.
Don Burn
and having drivers that can handle all versions of the chip you want to run
on. The first requires a lot of clout with Microsoft, the second just a lot
of work.
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote in message
news:O68qnO7o...@TK2MSFTNGP02.phx.gbl...
Phil
embedded design. On a XP system with the W83627DHG (similar Super I/O
chip), the "Intel(R) 82801GB/GR (ICH7 Family) LPC Interface Controller
- 27B8" device has under its Bus Relations the Device Instance Id for
the "Communications Port (COM1)" device. Under the same Bus
Relations, there are many other Device Instance Ids, including the one
for the "ECP Printer Port (LPT1)" device.
Is this how Windows is arbitrating the use of the Super I/O registers
for all devices controlled by this chip? If so, how would my custom
GPIO driver (to be written yet) be registered under the LPC Interface
Controller Bus Relations? By simply adding my GPIO driver to the Bus
Relations, will the LPC Interface Controller know how to arbitrate the
use of the Super I/O registers, or would it need to be changed to
support a new device type?
On the same system, the 0x2E port is owned by "Motherboard
Resources" (with Device Instance Id ACPI\PNP0C02\10). There are 5
"Motherboard Resources" devices in total. I'm pretty sure that the
ICH7 has mapped the 0x2E/0x2F ports to the LPC bus, which is where the
W83627 chip is attached.
- Phil
On Apr 21, 6:35 am, "Don Burn" <b...@stopspam.windrvr.com> wrote:
> Yes, but unfortunately that means knowing the expected Microsoft interfaces
> and having drivers that can handle all versions of the chip you want to run
> on. The first requires a lot of clout with Microsoft, the second just a lot
> of work.
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website:http://www.windrvr.com
> Blog:http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> "Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote in messagenews:O68qnO7o...@TK2MSFTNGP02.phx.gbl...
>
>
>
> > Don Burn wrote:
> >> Disabling interrupts is worthless in Windows, it breaks thing and
> >> should never be done. You can do some games to corral all CPU's but
> >> that still does not protect against the legitimate owner of the super
> >> I/O chip being in the middle of a write to it and your driver
> >> stomping on the write. Also, corralling the CPU's is going to
> >> destroy the systems performance.
>
> > Meaning that he needs to become the legitimate owner of the super I/O
> > chip -- i.e. replace the existing driver accessing these ports. Maybe
> > someone can give him some advice on how to identify which driver it is...
> > my guess is Device Manager -> View Resources By Type.
>
> > On my system (32-bit XP Pro SP2) port 0x2E and 0x2F (actually 0x20-0x3F)
> > are claimed by Programmable Interrupt Controller, and something funny is
> > clearly going on. Device Manager shows a Microsoft driver with version
> > number matching the OS, but driver details reveals National Instruments
> > has substituted nipbcfk.sys. This sounds suspiciously like someone else
> > has already faced the same problem and solved it -- after a fashion.- Hide quoted text -
Pavel A.
to see whether any driver actually uses them.
If you're lucky and nobody uses these ports, just go ahead.
Otherwise... the GPIO interface on this machine has not been Designed for
Windows :(
--PA
"Phil" <GoogleGr...@ipavilion.com> wrote in message
news:cdfa80ca-00e1-4cbb...@y38g2000hsy.googlegroups.com...
Phil
that they change when I open a standard COM1/COM2 serial port at the
application level.
What I am trying to figure out is, how drivers get added to the
"Intel(R) 82801GB/GR (ICH7 Family) LPC Interface Controller -
27B8" (aka ISAPNP.sys) Bus Relations in the registry. Does the
ISAPNP.sys driver enumerate the LPC bus looking for LPC devices, such
as a Super I/O chip, and then probe the Super I/O chip to find out
what devices it supports? Or, is there information stored away by the
BIOS that indicates legacy devices, such as COM1, COM2, and LPT1 ports
all are controlled by the Super I/O chip on the LPC bus? I am
thinking it is the latter, because when I change the BIOS settings for
the Super I/O devices, they show up in Device Manager under
ISAPNP.sys.
What I want to do is figure out how these standard drivers get related
to the ISAPNP.sys upon installation, and how can I relate my driver in
the same so that access to the Super I/O chip is serialized by the LPC
Interface Controller.
- Phil
On Apr 26, 8:59 am, "Pavel A." <pave...@NOwritemeNO.com> wrote:
> Maybe you can set breakpoints on access to these ports ( ba i )
> to see whether any driver actually uses them.
>
> If you're lucky and nobody uses these ports, just go ahead.
> Otherwise... the GPIO interface on this machine has not been Designed for
> Windows :(
>
> --PA
>
> "Phil" <GoogleGroupsP...@ipavilion.com> wrote in message
Pavel A.
ISAPNP protocol does not know anything about LPC bus,
it was created long before LPC.
The com & lpt ports of ICH7 are related to isapnp because isapnp
detects them and is their enumerator.
Maybe you need to look in the ACPI direction: check
for ACPI methods to manipulate super io devices.
--PA
"Phil" <GoogleGr...@ipavilion.com> wrote in message
news:a5bebdfc-1427-4618...@56g2000hsm.googlegroups.com...
Phil
"isapnp", according to Device Manager. Not sure if that is useful
information. From what I understand, the ICH7 is setup by the BIOS to
decode the LPC I/O port addresses for the Super I/O COM1 and LPT1
devices.
I looked at the ACPI Specification, which doesn't go into a whole lot
of detail about Super I/O or "Generic Container Devices", but maybe I
have to stare at the spec for a few more weeks before I fully
understand it. The WDK documentation on ACPI is equally "intuitive".
I think I just have to learn all these new terms, and then I might be
able to make more sense out of ACPI.
- Phil
On May 7, 7:48 pm, "Pavel A." <pave...@NOwritemeNO.com> wrote:
> The LPC controller is not "aka isapnp.sys".
> ISAPNP protocol does not know anything about LPC bus,
> it was created long before LPC.
> The com & lpt ports of ICH7 are related to isapnp because isapnp
> detects them and is their enumerator.
>
> Maybe you need to look in the ACPI direction: check
> for ACPI methods to manipulate super io devices.
>
> --PA
>
> >> - Show quoted text -- Hide quoted text -