Hi
I try to access SMBus (read word) on chipset Intel US15W (Intel SCH) through I/O ports. I try to do it the way Linux driver (i2c-isch.c) does (just by taking pieces of code). The problem is that any slave address and any command return the same number (usually from 0x42 to 0x46, maybe it’s temperature or something else?). Using utility (“RW Everything”), I can see that this number appears in the result of periodic SMBus reading by some another program (slave address 0x98, command 0x01, format - byte). If I try to read SMBus not by my program but by “RW Everything”, result is the same (same number on any slave address and command). I try to read data from device with slave address 0x0A (SPD).
I do the following steps for reading SMBus data:
- Read host status register and check if BUSY bit is set.
- Write slave address (with 1 in bit 0, for reading) and command in corresponding registers.
- Write 0 to reserved bits in host control register, set format in host control register (set 1 to bits number 0 and 1 for reading word).
- Read byte from host status register, check if previous operation completed successfully and there are no “bus error” and “device error”. Write this byte back to the host status register. Read it and check bits 0 to 3, they must be 0.
- Set bit 4 (“start/stop”) in host control register to 1.
- Read host status register. Check “busy” up to 5000 times. If busy, timeout expired and there’s error.
- Check bus error and device error (bits 1 and 2 in host status register).
- Check if transaction completed successfully (bit 0 in host status register must be set). If set, write status (previously read from host status register) to host status register.
- Read status from the host status register. Check device error and bus error.
- Read word from “host data 0” and “host data 1” registers.
Error is in the step 8. Host status register is 0. If I ignore this error, I get number that was in data0 and data1 before my commands (0x42 to 0x46).
Please help me, tell if I do anything wrong and if I have any chances to get data through I/O ports, without editing ACPI BIOS. Maybe I should install something? Thanks in advance.
We’ve answered questions like this many times here.
The general principle in Windows is that the SMBUS belongs to the BIOS.
The SMBUS therefore CAN be used for a wide variety of things. Worse, the BIOS might communicate on the SMBUS using the master registers in the PCH. The BIOS, therefore, most likely does not expect a host-resident driver to ALSO be trying the use the SMBUS master registers in the PCH.
So, whether you can successfully use those registers from the host side to talk to some device you’ve put onto the SMBUS is entirely dependent on (a) the capabilities in the PCH, and (b) what the BIOS does.
Peter
OSR
Remember the discussion about hardware people should do hardware and
driver writers should do drivers? This is another example of the failure
of that pattern.
When you look at the schematics, especially for SoC-type devices, the
SMBus looks easy and straightforward compared to, say, using an onboard
PCI bus. Particularly if there is no PCI interface for onboard devices
already on the board. So they choose to connect to the SMBus, because
“it’s easy, and besides, on the machine on my desk, I was able to read and
write the SMBus without any problem”. I saw this a lot in past years, and
when I asked “Why the SMBus?” I was given some variant of the “that’s
easy” explanation. The fact that it cannot reliably be programmed for all
the reasons you cite is not considered important. By the time the
uninvolved-in-hardware driver writer gets it, it’s well into
manufacturing, with thousands of units in existence. And no hardware
designer wants to explain to his/her manager that an error was made due to
lack of understanding of the software universe, so it’s all the fault of
the driver writer, who can’t even implement a simple solution for a simple
device!
joe
We’ve answered questions like this many times here.
The general principle in Windows is that the SMBUS belongs to the BIOS.
The SMBUS therefore CAN be used for a wide variety of things. Worse, the
BIOS might communicate on the SMBUS using the master registers in the PCH.
The BIOS, therefore, most likely does not expect a host-resident driver
to ALSO be trying the use the SMBUS master registers in the PCH.
So, whether you can successfully use those registers from the host side to
talk to some device you’ve put onto the SMBUS is entirely dependent on (a)
the capabilities in the PCH, and (b) what the BIOS does.
Peter
OSR
NTDEV is sponsored by OSR
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
wrote in message news:xxxxx@ntdev…
> Remember the discussion about hardware people should do hardware and
> driver writers should do drivers? This is another example of the failure
> of that pattern.
Dr. Newcomer,
For sure, driver and hardware people must cooperate on the system or product
design - as shown on this old slide: http://bit.ly/Rxrbyy
(sorry, could not locate the original slideshow online on pcisig)
But IMO they should do their own part implementing the agreed design.
While most of h/w and electronic engineers learn software programming
and can write quite complex programs, this alone does not make them
software developers, leave alone driver developers.
Communication is the key. This exactly is why in almost every job ad
these days you see as requirment “excellent communication and presentation
skills”.
Quality communication, unfortunately, does not happen by itself, and can be
ruined easily
[then all kinds of nasty “patterns” may get loose: hardware folks write
drivers, software folks do customer support … you know].
Regards,
– pa
When I do “career day” at our local middle school (a block from home), and
students ask what skills they will need to be programmers, I say “Algebra
and English”.
I have often referred to programmers that I say “for whom English is a
second language”. The problem is that they were born and raised right
here in the US, but their “first” language is C, C++, C#, Java or VB.
Back when I was employed in the software industry (that is, a full-time W2
job with a paycheck every month, rather than the 24 years I spent as a
consultant), much of my time training new programmers was spent teaching
them to communicate.
joe
wrote in message news:xxxxx@ntdev…
>> Remember the discussion about hardware people should do hardware and
>> driver writers should do drivers? This is another example of the
>> failure
>> of that pattern.
>
> Dr. Newcomer,
> For sure, driver and hardware people must cooperate on the system or
> product
> design - as shown on this old slide: http://bit.ly/Rxrbyy
> (sorry, could not locate the original slideshow online on pcisig)
>
> But IMO they should do their own part implementing the agreed design.
>
> While most of h/w and electronic engineers learn software programming
> and can write quite complex programs, this alone does not make them
> software developers, leave alone driver developers.
>
> Communication is the key. This exactly is why in almost every job ad
> these days you see as requirment “excellent communication and presentation
> skills”.
> Quality communication, unfortunately, does not happen by itself, and can
> be
> ruined easily
> [then all kinds of nasty “patterns” may get loose: hardware folks write
> drivers, software folks do customer support … you know].
>
> Regards,
> – pa
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
Thanks for the explanation. So, it finally began to work, but very, very bad, because unknown another program reads I/O ports too. So, I’ve decided to do it by calling IOCTL_ACPI_EVAL_METHOD from my driver (another program reads ports by ACPI too, that’s exact). I can’t understand, what PDO should be passed to IoBuildDeviceIoControlRequest. PDO of the device, whose method (according to DSDT) I want to call, yes? So, for example, thermal zone can be found by GUID and I can call any its method that is defined in DSDT? It’s my suggestion, I didn’t check. But what PDO should I pass to IoBuildDeviceIoControlRequest if I want to call method, that doesn’t belong to any device in DSDT? Sorry if I express my thoughts incorrectly, I have just very little experience in driver development.