Bug 202587 - AMD X370 has secondary SMBus at I/O address 0x0B20 that isn't being detected, also requesting increased SMBus performance
Summary: AMD X370 has secondary SMBus at I/O address 0x0B20 that isn't being detected,...
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: I2C (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jean Delvare
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-15 04:32 UTC by Adam Honse
Modified: 2024-10-16 21:08 UTC (History)
21 users (show)

See Also:
Kernel Version: 4.15.0-45
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Adam Honse 2019-02-15 04:32:41 UTC
I've been working on reverse engineering Asus and friends' Aura RGB lighting system that is found on many Asus motherboards along with DDR4 RAM modules from G.Skill, ADATA, and others.  This RGB lighting system uses the SMBus interface to communicate with lighting controllers on the motherboard and RAM modules.  I have reverse engineered much of the Aura controller's register map and have code to configure and set colors to the module from Linux.  I also utilized the Linux I2C code along with InpOut32 on Windows to drive the SMBus controllers from userspace and control the lighting without the official application.

In doing this research, I learned that the AMD X370 chipset actually has two PIIX4-compatible SMBus controllers, one at I/O 0x0B00 and one at I/O 0x0B20.  This seems to be the case with at least X470 and X399 as well, according to GitLab user reports.  I discovered that the RAM controllers are on the first bus at 0x0B00 (which also has the SPD EEPROMs) while the motherboard's Aura controller is on the second bus at 0x0B20.  With the current Linux driver on kernel 4.15.0-45, this second bus is not detected and as such I cannot control the motherboard's Aura lighting.

In addition, I believe the timeouts in the Linux i2c-piix4.c driver are unnecessarily high and would like to have them reduced or at least a userspace-accessible option to reduce them.  I have no problem with my Windows implementation writing to 4 RAM modules as well as the motherboard module with 5 RGB zones each (5*5*3 = 75 bytes, not including overhead) at 25ms or faster update rates.  I created a music visualizer application using the RGB lighting and thus a high update rate is important to get a smoothly animated visualization.  On Linux, I notice a major delay just setting single registers on the RAM modules in a loop, to the point that they don't appear to update all at once.

For more information, my reverse engineering and reimplementation project can be found on GitLab here:

https://gitlab.com/CalcProgrammer1/OpenAuraSDK
Comment 1 Darksurf 2019-07-07 04:38:56 UTC
Has there been any movement or review on this?
Comment 2 Jean Delvare 2019-08-06 10:29:18 UTC
Do the 2 SMBus controllers appear as separate PCI devices, or as 1 PCI device with multiple I/O resources? lspci -nnv should tell.
Comment 3 Adam Honse 2019-08-11 18:20:43 UTC
I believe it's just one PCI device.  On Windows, the I/O resources are not shown.  I'll try the lspci -nnv on my friend's B450 later today as I'm away from my X370 system for a few days.  In our testing it looks like all AM4 chipsets have this second bus.
Comment 4 gregersn 2019-11-16 20:44:46 UTC
ASUS ROG Strix B450-F GAMING, Socket-AM4

lspci -nnv

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61)
	Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:87c0]
	Flags: 66MHz, medium devsel
	Kernel driver in use: piix4_smbus
	Kernel modules: i2c_piix4, sp5100_tco
Comment 5 kernel 2020-01-17 16:53:48 UTC
Gigabyte X570 I Aorus Pro Wifi

lspci -nnv

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61)
	Subsystem: Gigabyte Technology Co., Ltd Device [1458:5001]
	Flags: 66MHz, medium devsel
	Kernel modules: i2c_piix4, sp5100_tco

Just one device for me
Comment 6 hac09 2020-01-19 17:06:36 UTC
Only a single SMBus-device on Asus PRIME X370-PR as well:

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 59)
	Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:8747]
	Flags: 66MHz, medium devsel
	Kernel driver in use: piix4_smbus
	Kernel modules: i2c_piix4, sp5100_tco
Comment 7 crt0mega 2020-01-19 21:14:02 UTC
Same here with my PRIME 370-PRO

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61)
	Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:87c0]
	Flags: 66MHz, medium devsel
	Kernel driver in use: piix4_smbus
	Kernel modules: sp5100_tco, i2c_piix4
Comment 8 Bert Haverkamp 2020-02-26 11:18:26 UTC
This patch works(and is needed) on my ASROCK B450M Pro 4 mainboard to make the port at at I/O 0x0B20 visible.
After this, I can use the OpenRGB tool to control the RGB lighting on the Mainboard. 
Can you please include it in the mainline
Comment 9 nutodafozo 2020-06-28 13:01:44 UTC
I suppose it was fixed: it was backported to stable 5.4.49.
Comment 10 Adam Honse 2020-06-28 18:30:50 UTC
My patch has been merged and backported.  Closing.
Comment 11 Priit O. 2020-07-19 16:15:01 UTC
ASRock AB350M Pro4

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 59)
	Subsystem: ASRock Incorporation Device [1849:790b]
	Flags: 66MHz, medium devsel, IOMMU group 11
	Kernel driver in use: piix4_smbus
	Kernel modules: i2c_piix4, sp5100_tco

Note You need to log in before you can comment on or make changes to this bug.