>
> “INUSE_STS  R/WC (special). This bit is used as semaphore among
> various independent software threads that may need to use the
> ICH8’s SMBus logic, and has no other effect on hardware.”.
>
> That’s pretty much exactly what I need for synchronization - but I
> can’t be sure if BIOS uses it, or simply assumes exclusive access.
I’ve also previously overlooked a flag in ICH8’s HST_STS register:
Does the Linux i2c driver use this flag? It defines
SMBHSTSTS_INUSE_STS bit
but I don’t see it used. If not… probably it is not worth anything.
I’ve done the very same exercise in the meantime Indeed, this flag
seems only #defined there for completeness, it’s never referenced.
BTW, It’s frustrating to find it so messy, but apparently there is too
little industry demand for OS <-> SMBus access to be standardized (as
there is little need for this kind of access itself).
Well, Windows does not use SMBUS; unless BIOS exposes SMBUS controller to the OS via ACPI tables (which, apparently, is not the case in your situation, right) there is a slim chance of ACPI methods invoked by the OS accessing it either; so that it looks like the only “competitor” in sight is SMI. Therefore, you have to make sure SMB_SMI_EN bit of SMBUS controller’s configuration register is configured to generate a PCI interrupt, rather than SMI. OTHOH, Linux does not seem to care - its code in i2c_i801.c seems to treat it matter-of-factly…
Read Linux sources more carefully - I believe it should all work just fine…
With all due respect: Tell your vendor that connecting random stuff via the SMBUS is, in general, not a good idea. Explain to them that Windows does not support connecting random devices this way. Describe for them Windows approach to the SMBUS.
Help them understand that it is very close to trivial (though slightly more expensive) to provide the connection they seek other ways such as, for example USB, that would be fully supported.
Every month or so, we see somebody post “I want to write an SMBUS driver” here on the list. Except for the rare exception, these people are very misguided. Some hardware guy at some IHV says “Hey! How about connecting our via I2C!! I could just solder this header onto the motherboard, and we could plug into the SMBUS! It’d be cheap and easy!! What a great idea, huh!?”
You want to connect random industrial devices via I2C? Either(a) Use a proper embedded PC and a different operating system, or (b) source your own mainboard, do the system integration, and provide your own set of custom drivers.
You want to connect random industrial devices to a WINDOWS system? Use a bus that’s designed for this. Heck, a SERIAL port connection is much more preferable to a connection via SMBUS for this purpose.
So, it seems you understand the problem. So, basically, you need a print set for the motherboard you’ll be using… and you need to determine which devices connect to the SMBUS. I’ve already told you one device that often uses the SMBUS after boot, the integrated NIC. You could always connect a bus analyzer to the SMBUS and log the activity, right? Sorta hard to get a definitive answer that way, to see all the various edge conditions and states, but you’ll get SOME idea.
Precisely.
Finally… if you’re REALLY intent on doing this (and remember that I recommend you convince your IHV client to take a different approach) the only way you’ll be able to sleep at night is if you can pick one SPECIFIC motherboard/chipset/BIOS/drivers/OS combination and stick with it. Get the print set. Dump and read the ACPI BIOS code. Do the necessary homework – basically the system integration engineering – to determine that what you’re designing is going to actually WORK.
Your IHV vendor client is going outside the bounds of what Windows wants to support. Windows leaves the SMBUS to the BIOS. If you want to do the engineering that crosses those boundaries, you certainly can. But you have to do the system integration engineering to ensure that what you’re doing is going to work.
Or, listen to Anton – who I doubt has ever written an SMBUS driver for Windows – and do some random engineering and just port the Linux code and do whatever you want. I mean, how hard can THAT be, right?
With all due respect: Tell your vendor that connecting random stuff via the SMBUS is, in general, not a good idea. Explain to them that Windows does not support connecting random devices this way. Describe for them Windows approach to the SMBUS.
I couldn’t agree more with you - unfortunately, I’m not in position to
push them like this (heck, if only there was no politics involved).
Help them understand that it is very close to trivial (though slightly more expensive) to provide the connection they seek other ways such as, for example USB, that would be fully supported.
Actually, I know that another hardware they’ve done uses CPLD chip
driven by LPC interface, which seems a better idea.
Every month or so, we see somebody post “I want to write an SMBUS driver” here on the list. Except for the rare exception, these people are very misguided. Some hardware guy at some IHV says “Hey! How about connecting our via I2C!! I could just solder this header onto the motherboard, and we could plug into the SMBUS! It’d be cheap and easy!! What a great idea, huh!?” And I’m perfectly sure that was exactly the case here, as I mentioned before - bill of materials was the only aspect analyzed.
Unfortunately, my task is to somehow recover from this decision as much as possible. I just hope I fall into what you call “rare exception”
> You want to connect random industrial devices to a WINDOWS system? Use a bus that’s designed for this. Heck, a SERIAL port connection is much more preferable to a connection via SMBUS for this purpose. Exactly, attaching a dirt-cheap Atmel or PIC MCU to the UART would be so much easier (and more powerful in this particular application). > So, it seems you understand the problem. So, basically, you need a print set for the motherboard you’ll be using… and you need to determine which devices connect to the SMBUS. I’ve already told you one device that often uses the SMBUS after boot, the integrated NIC. You could always connect a bus analyzer to the SMBUS and log the activity, right? Sorta hard to get a definitive answer that way, to see all the various edge conditions and states, but you’ll get SOME idea. Yes, that’s exactly what I’m going to do when the hardware eventually arrives - attach the scope and see whats’ going on there. Right after disassembling DSDT and scanning SMBus with i2cdetect under Linux, that is. > Your IHV vendor client is going outside the bounds of what Windows wants to support. Windows leaves the SMBUS to the BIOS. If you want to do the engineering that crosses those boundaries, you certainly can. But you have to do the system integration engineering to ensure that what you’re doing is going to work. You’re perfectly right. Fortunately we have only 2 exact MoBo to support, to ease the pain. > Or, listen to Anton – who I doubt has ever written an SMBUS driver for Windows – and do some random engineering and just port the Linux code and do whatever you want. I mean, how hard can THAT be, right? > Well, I believe we all agree that steering the ICH’s SMBus host is the easy part, but that’s not where the problem actually is.
> Or, listen to Anton – who I doubt has ever written an SMBUS driver for Windows – and do
some random engineering and just port the Linux code and do whatever you want.
Well, although, up to this point, I was lucky enough of not having encountered such a task, I would study Linux code thoroughly if I was assigned to it. Look - we are speaking about the code that has been field-tested already. In case if there is a problem with this code running on the OP’s target MB/chipset/BIOS combination (and there may be the one, and probably even more than one - who would ever argue about that ) the OP has a good chance of finding it out simply by searching Linux NGs, discover the reasons for these problems, consider possible proposed workarounds,etc,etc,etc…
I mean, how hard can THAT be, right?
Well, it is not going to be that easy, and system integration work that you have mentioned above is going to be a part of the job. However, it does not mean that you should not use Linux code as a reference, right…
Programming the SMBUS Host Controller via the ICH/PCH is sufficiently self evident that it would take you longer to understand how to run the device by reading a Linux implementation than it would be to read the register definitions in the documentation.
Also, Linux is not Windows – I know you know that. So whatever Linux does or does not do… or what it implements or does not implement… has very little relevance. So, looking at the Linux implementation isn’t going to tell you anything about how to “safely” use the device as part of a Windows system, really.
So, in fact, the Linux code is entirely irrelevant as a reference.
Nevertheless, I’m sure you would start by reading it. Me, personally? I start with the data sheet when I need to program a device. I usually try to avoid reading other drivers and creating derivative works myself.
> Programming the SMBUS Host Controller via the ICH/PCH is sufficiently self evident that it would
take you longer to understand how to run the device by reading a Linux implementation than it
would be to read the register definitions in the documentation.
…unless there are some scenarios that are not immediately obvious from reading datasheet for your target chipset, so that they require a special handling. More on it below…
Also, Linux is not Windows – I know you know that. So whatever Linux does or does not do…
or what it implements or does not implement… has very little relevance. So, looking
at the Linux implementation isn’t going to tell you anything about how to “safely” use the device
as part of a Windows system, really. Also, Linux is not Windows – I know you know that.
So whateverLinux does or does not do… or what it implements or does not implement…
has very little relevance. So, looking at the Linux implementation isn’t going to tell you anything
about how to “safely” use the device as part of a Windows system, really. or
Under the normal circumstances I would 100% agree with you. Indeed, there is very little (if any at all) correspondence between these two OSes, so that the only thing that can get ported is interaction with device-specific registers. However, this is a very special situation - Windows just does not recognize SMBUS at all. Therefore, if you want to introduce a subsystem that deals with it you are absolutely free to do it the way you wish - there are no API contracts to abide by, so that you can introduce LInux API, or xxxBSD one, or something of your own design. Don’t forget that the OP’s drivers have to work under both Windows and Linux. Therefore, if he takes Linux I2C subsystem’s API as a base he will, probably, save himself some effort…
Nevertheless, I’m sure you would start by reading it. Me, personally? I start with the data sheet
when I need to program a device.
I suggest you first look at Linux sources (particularly comments to some parts of its code) first…
The thing is, it has quite a few places that deal with certain hardware bugs and/or “peculiar things” that are not obvious from datasheets for the target hardware. I think it is just unwise to ignore such a “knowledge base”, in MSDN terms…
I usually try to avoid reading other drivers and creating derivative works myself.
Do you mean that your never read WDK samples either???
Indeed, this flag
