Re: Atomic Port I/O

Tech-Archive recommends: Fix windows errors by optimizing your registry

I'm only working with the Winbond W83627HF Super I/O chip in an
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...@xxxxxxxxxxxxxxxxxxxx> 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...@xxxxxxxxxxxxx> wrote in messagenews:O68qnO7oIHA.5096@xxxxxxxxxxxxxxxxxxxxxxx



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 -

- Show quoted text -

.

Quantcast