Simone
c9b8799f69
Two things came out of preparing the suspend test, and one of them is a correction. ee1004 does not bind to this adapter. Both functionality combinations it accepts include I2C_FUNC_SMBUS_BYTE (drivers/misc/eeprom/ee1004.c:301), which this driver does not implement, so the probe fails with -EPFNOSUPPORT. The cover letter claimed BYTE_DATA and WORD_DATA "cover ee1004 and jc42" and the .rst told the reader to instantiate it; both were wrong and are corrected. jc42 is fine, it only needs BYTE_DATA and WORD_DATA, but no TSOD is populated here to bind to. The practical cost is that decode-dimms does not work through this adapter. SPD bytes stay readable byte by byte with i2cget. Receive Byte is what PawnIO implements with its pointer-select bit and what this project chose not to advertise for want of validation; that choice was not free, and adding it validated is the most useful thing left. Suspend and resume tested with continuous traffic on both adapters, s2idle and S3. Transfers recover, nothing complains. Across S3 the engine comes back reprogrammed on both channels: DATA 0x2000b600 -> 0x20005000 STATUS 0x0000500c -> 0x00005004 The command word addresses SPD 0x50 for a read and the status drops to READ_DONE alone. Linux issued none of it: the adapter was marked suspended and userspace frozen. This is consistent with firmware reading SPD during memory training on resume, and it is the first direct observation of a second master on this engine. It is also the concrete justification for restoring command state per transfer and comparing it afterwards. Add tools/test-suspend.sh, which drives that test and reports the register delta across the sleep. Traffic goes through i2c-dev rather than a bound client: with ee1004 unable to attach and no TSOD present, there is no in-kernel client to use, and the PM path exercised is the same either way -- i2c_smbus_xfer() consults __i2c_check_suspended() before reaching the adapter.
138 lines
5.1 KiB
ReStructuredText
138 lines
5.1 KiB
ReStructuredText
.. SPDX-License-Identifier: GPL-2.0
|
|
|
|
=============================
|
|
Kernel driver i2c-imc-skylake
|
|
=============================
|
|
|
|
Supported adapters:
|
|
* Intel Skylake-X / Cascade Lake-X integrated memory controller (iMC)
|
|
SMBus engine, PCU function 8086:2085 (socket LGA 2066, platform X299)
|
|
|
|
Author: Simone Chifari <[email protected]>
|
|
|
|
|
|
Description
|
|
-----------
|
|
|
|
The integrated memory controller of Intel Skylake-X and Cascade Lake-X
|
|
processors contains an SMBus engine wired to the DDR4 DIMMs. It reaches the
|
|
SPD EEPROMs (0x50-0x57) and the thermal sensors (TSOD, 0x18-0x1f) of the
|
|
installed modules, plus whatever else a particular module carries on those
|
|
lines.
|
|
|
|
The engine has two independent channels. DIMM slots 1 and 2 are on channel 0,
|
|
slots 3 and 4 on channel 1, so the driver registers two i2c adapters::
|
|
|
|
$ i2cdetect -l | grep iMC
|
|
i2c-6 smbus iMC SMBus Skylake-X channel 0 SMBus adapter
|
|
i2c-7 smbus iMC SMBus Skylake-X channel 1 SMBus adapter
|
|
|
|
Both channels share one hardware engine, so the driver serializes every
|
|
transaction across both adapters.
|
|
|
|
|
|
This driver is not enabled by default
|
|
-------------------------------------
|
|
|
|
The SMBus engine has no arbitration mechanism. System Management Mode, a BMC,
|
|
and the memory controller's own closed-loop thermal throttling (CLTT) can all
|
|
drive the same registers, and nothing in the PCI ID tells the driver whether
|
|
any of them is doing so on a given system. Two masters using the engine at the
|
|
same time can send a transaction to the wrong address or return the wrong data.
|
|
|
|
The driver therefore refuses to bind unless the operator opts in::
|
|
|
|
modprobe i2c-imc-skylake allow_unsafe_access=1
|
|
|
|
Do this only on a system where concurrent firmware access has been excluded.
|
|
Desktop and HEDT boards have no BMC, but CLTT may still be enabled by the
|
|
firmware.
|
|
|
|
The driver reduces, but cannot remove, the risk.
|
|
|
|
At probe it reads SMBCNTL on every iMC channel function (device 10 and 12,
|
|
function 0; offsets 0xe88 and 0xe98, documented in the Intel Xeon Processor
|
|
Scalable Family datasheet volume 2, reference 614073, section 3.1.9).
|
|
``SMB_TSOD_POLL_EN`` in that register says whether the memory controller is
|
|
polling the DIMM thermal sensors on its own, which Intel documents as mutually
|
|
exclusive with SPD command access. If the bit is set on any channel the driver
|
|
refuses to bind: the engine is not ours to drive. This covers the memory
|
|
controller, not SMM or a BMC, which remain the reason for the opt-in.
|
|
|
|
Per transfer:
|
|
|
|
* every transaction waits for both channels to report idle before it
|
|
touches any register;
|
|
* the previous command state of both channels is saved, the TSOD-active
|
|
state is cleared for the duration of the transfer, and both are restored
|
|
afterwards;
|
|
* after each transfer the command registers are compared against what the
|
|
driver left in them. A difference means another master used the engine,
|
|
and the transfer is failed with ``-EAGAIN`` rather than reported as
|
|
successful.
|
|
|
|
The last check is what makes an unarbitrated system detectable: if the log
|
|
shows
|
|
|
|
``chN command changed under us (...): another master is using the engine``
|
|
|
|
then firmware is using the engine and the driver should not be loaded on that
|
|
system.
|
|
|
|
|
|
Config space access
|
|
-------------------
|
|
|
|
The engine's registers live at config space offsets 0x9C-0xB8 of the PCU
|
|
function and are reached with the ordinary ``pci_read_config_dword()`` and
|
|
``pci_write_config_dword()``. Nothing special is required.
|
|
|
|
Supported transactions
|
|
----------------------
|
|
|
|
The driver implements SMBus Read/Write Byte Data and Read/Write Word Data.
|
|
|
|
That is enough for ``jc42`` (TSOD), which asks for exactly those two. It is
|
|
**not** enough for ``ee1004``: both of its accepted combinations include
|
|
``I2C_FUNC_SMBUS_BYTE``, which this adapter does not implement, so the driver
|
|
probe fails with ``-EPFNOSUPPORT``. SPD bytes are still readable directly with
|
|
``i2cget``. Implementing SMBus Receive Byte would make ``ee1004`` and
|
|
``decode-dimms`` work; it is the most useful thing still missing.
|
|
|
|
SMBus Quick and Receive Byte are not implemented, so ``i2cdetect`` cannot scan
|
|
these buses. Address a device directly instead, for example SPD byte 2 of the
|
|
EEPROM at 0x50::
|
|
|
|
$ i2cget -y 6 0x50 0x02
|
|
0x0c
|
|
|
|
Block transfers are not implemented. The engine has block primitives, but no
|
|
device on this bus needs them.
|
|
|
|
Word transfers use the standard SMBus byte order, so ``jc42`` reading through
|
|
``i2c_smbus_read_word_swapped()`` gets the value it expects.
|
|
|
|
|
|
Instantiating clients
|
|
---------------------
|
|
|
|
The adapter does not create clients by itself. There is no firmware
|
|
description of these buses and the driver does not scan.
|
|
|
|
``jc42`` can be instantiated where a thermal sensor is populated::
|
|
|
|
# echo jc42 0x18 > /sys/bus/i2c/devices/i2c-6/new_device
|
|
|
|
Whether one is populated is visible in ``SMBCNTL.TSOD_PRESENT``; on the
|
|
development system that mask is empty and no ``jc42`` binds.
|
|
|
|
``ee1004`` will not bind for the reason given above. Read SPD bytes directly
|
|
instead.
|
|
|
|
Module parameters
|
|
-----------------
|
|
|
|
allow_unsafe_access
|
|
Bool, read-only after load, defaults to false. The driver does not bind
|
|
unless this is set. See the section above.
|