Windows 7 PCI, I2C enumeration?

NTDEV
1

Hello,

I’m founding solution to make a HID over I2C touch panel work on Win7. IMHO I2Cs is just a subset of PCIs (correct me if i’m wrong plz). The first step I want to do is make a hello world driver based on pcidrv sample. But I don’t know what hardware id to use. I think it should be PCI\VEN_8086&DEV_9C62 because in Intel documentation I see that device id for I2C is 9C62. But in Win8’s device manager I see that the hardware id is ACPI\INT33C3 and it’s name is “Intel Serial IO I2C Host Controller - 9C62”. I know that is because the enumerator for this device in Win8 is ACPI.

On other direction Win7 won’t support I2C, Win8 support I2C but I wondering what is the level of “support” here? Of course Win7 don’t have SPB and HID over I2C but the “lower mechanism” should be still available. I mean when a device connected to system through I2C bus, it should be available for the OS?

From two directions above I think Win7 should be at least have the ability to enumerate my device through PCI enumerator and I can found PCI\VEN_8086&DEV_9C62 in device manager.

But I found nothing!

I’m totaly a newbie for driver programming, especially at this level.

2

I2C and PCI/PCIe are different technologies.
for PCI/PCIe vendorid/Device id remains same and it can be obtained by reading the config space.

3

I see that the parent of I2C devices is “PCI Express Root Complex”, in Win8 it can enumerate my device, but in Win7 it can’t. How to deal with it? The short question is how to enumerate i2c devices in Win7 so we can install a driver on it.

Another question, I hear about ACPI sometime. I even has been eval a ACPI method to obtain the HID Descriptor address but I’m not pretty sure what it is. Seem like it is the standard just above BIOS? In Win8 the hardware id for my device is ACPI\INT33C3. Is it just a naming convention or Win7 lack something in ACPI driver?

4

Below is brief details about ACPI - you can read the details yourself :
ACPI is layer between platform firware and os. ACPI contains different tables which are populated by platform firmare (bios/ uefi) during booting, these tables contains the details of attached peripherals one of the table is Differentiated System Description Table (DSDT) which contains the details of pci/pcie devices (bus, device and function- bdf). These tables are stored in memory and available to os after firmware handover control to os.
os reads the tables and understand the details of attached devices. now its os’s responsibility to configure and initialize the attached devices by identifying and loading the correct driver for devices. It also helps in hot plug pcie devices.

5

Thanks, helpful details.

So in this case the informations about my device already stored in the ACPI table. But Win7 have no ideal about what to do. Should I write something to read ACPI table my self and create the PDO? Do you have any sample or documentation about this problem?

6

ps of this helps:
http://social.msdn.microsoft.com/Search/en-US/windows/hardware?query=i2c&Refinement=182&emptyWatermark=true&ac=4

hope you know about the WDM/WDF. If no, then you need to understand that first before reading any of the material.

7

xxxxx@gmail.com wrote:

I’m founding solution to make a HID over I2C touch panel work on Win7. IMHO I2Cs is just a subset of PCIs (correct me if i’m wrong plz). The first step I want to do is make a hello world driver based on pcidrv sample. But I don’t know what hardware id to use. I think it should be PCI\VEN_8086&DEV_9C62 because in Intel documentation I see that device id for I2C is 9C62.

You have some dangerous misunderstandings here that need to be cleared
up before you can think about driver work.

I2C is nothing like PCI. I2C is an extremely simple 2-wire serial bus
to allow chips to talk to each other. (Indeed, the name stands for
“Inter-Integrated Circuit bus”).

I2C is not plug-and-play. I2C devices cannot identify themselves. Each
I2C device has a hardcoded 7-bit address, but you have to KNOW that
address to talk to the device. You have to KNOW that there is an EEPROM
at address A0, or a camera sensor at address 38, or an audio chip at
address 60. You can’t find that out. You can find out if something
responds at address XX, but even knowing that you can’t tell what it is.

I2C has traditionally not been relevant to PC motherboards, because
there’s no way to connect it to a processor. Embedded processors almost
always have direct I2C ports, but x86 chips do not. Your graphics card
gets the EDID information from your monitor via I2C, but that’s handled
entirely by the graphics chip, driven by the graphics driver, not by a
general purpose I2C driver.

Your 8086/9C62 device is really a fake device. The Intel “8 series
chipset”, which is what you have, does have a couple of I2C controllers,
but they aren’t addressed like normal PCI devices. You have to go
through the PCI chipset registers. That’s why your panel is attached to
an ACPI device. The ACPI driver, in this case, knows how to use the
SMBus within the chipset to do I2C reads and writes.

So, to do what you want to do, you’d have to recreate that ACPI driver.

On other direction Win7 won’t support I2C, Win8 support I2C but I wondering what is the level of “support” here? Of course Win7 don’t have SPB and HID over I2C but the “lower mechanism” should be still available. I mean when a device connected to system through I2C bus, it should be available for the OS?

No. There is no way to make an I2C device “available for OS”. You can
have a driver that happens to communicate via I2C, but you’ll have to
figure out how to get it loaded (for example, through ACPI), and you’ll
have to figure out how to reach the I2C controller. That requires
in-depth knowledge of the PCI chipset on your motherboard.

I’m totaly a newbie for driver programming, especially at this level.

This is not really a task for a newbie. You will be dealing at a very
low-level here, talking directly to hardware registers, not talking to a
nice memory-mapped abstraction provided by PCI.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

Thank you very much, it clear my brain.

I2C is not plug-and-play. I2C devices cannot identify themselves. Each
I2C device has a hardcoded 7-bit address, but you have to KNOW that
address to talk to the device. You have to KNOW that there is an EEPROM
at address A0, or a camera sensor at address 38, or an audio chip at
address 60. You can’t find that out. You can find out if something
responds at address XX, but even knowing that you can’t tell what it is.

It is clear, but I still wondering why the Win8 can KNOW these addresses. I guess the OS and device must have agreement here. Our case is limited to HID over I2C devices so I think we already know what it is by looking at the descriptors. Maybe the slave address for HID over I2C devices is stored in the ACPI table?

So, to do what you want to do, you’d have to recreate that ACPI driver.

Do you mean we must “replace the Acpi.sys”? Or it provide expansion capability?

Another short question, Can we create this driver with WDK or it must be WDM? I can’t found any example for this case in WDK 8.1 samples, seem like it is an unusual case.

9

Win8 knows about it because acpi was updated to reflect how to find these devices and assign resources to them. For 8 you need to update the bios to light up your device, pre win8 it is completely different work because there is no infrastructure at all in the os

d

Bent from my phone

From: xxxxx@gmail.commailto:xxxxx
Sent: ?6/?24/?2014 10:21 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE:[ntdev] Windows 7 PCI, I2C enumeration?

Thank you very much, it clear my brain.

> I2C is not plug-and-play. I2C devices cannot identify themselves. Each
I2C device has a hardcoded 7-bit address, but you have to KNOW that
address to talk to the device. You have to KNOW that there is an EEPROM
at address A0, or a camera sensor at address 38, or an audio chip at
address 60. You can’t find that out. You can find out if something
responds at address XX, but even knowing that you can’t tell what it is.

It is clear, but I still wondering why the Win8 can KNOW these addresses. I guess the OS and device must have agreement here. Our case is limited to HID over I2C devices so I think we already know what it is by looking at the descriptors. Maybe the slave address for HID over I2C devices is stored in the ACPI table?

> So, to do what you want to do, you’d have to recreate that ACPI driver.

Do you mean we must “replace the Acpi.sys”? Or it provide expansion capability?

Another short question, Can we create this driver with WDK or it must be WDM? I can’t found any example for this case in WDK 8.1 samples, seem like it is an unusual case.

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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</mailto:xxxxx></mailto:xxxxx>

10

xxxxx@gmail.com wrote:

> So, to do what you want to do, you’d have to recreate that ACPI driver.
Do you mean we must “replace the Acpi.sys”? Or it provide expansion capability?

What I mean is that the ACPI DSDT is causing the creation of a PDO named
ACPI\INT33C3. You would need to write a driver for that device, which
knows how to access the I2C hardware. You wouldn’t be handed any
resources, so you’d have to do everything by hand. Such a driver would
ONLY work on your hardware. That’s the price of using an ACPI device.

Now, here I am assuming that the same ACPI DSDT will create the same PDO
in Win 7 that it does in Win 8. Doron’s reply makes me wonder if that’s
not the case. If not, then you would be forced to create the PDO
yourself, using something like “devcon install”.

Another short question, Can we create this driver with WDK or it must be WDM? I can’t found any example for this case in WDK 8.1 samples, seem like it is an unusual case.

It could be done with KMDF. The distinction between KMDF and WDM is
really based on driver class, not hardware type.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

11

> Such a driver would
ONLY work on your hardware. That’s the price of using an ACPI device.

I hope I will be lucky since all my devices are hid over i2c. This driver should do minimal work, only read and write in transaction. Maybe it can be generic enough with considerable same chipset.

Now, here I am assuming that the same ACPI DSDT will create the same PDO
in Win 7 that it does in Win 8. Doron’s reply makes me wonder if that’s
not the case. If not, then you would be forced to create the PDO
yourself, using something like “devcon install”.

Win7 don’t create PDO for i2c devices.