Sapphire RX580 Nitro+

[CalcProgrammer1]

I got this GPU and am trying to figure out how to use this driver to control and reverse engineer it. I figured it would be a simple matter of copying in the correct subvendor ID:

    {0x1002, 0x67df, 0x1da2, 0xe366, 0, 0, CHIP_POLARIS10},     // RX580 (Sapphire Nitro+)

This causes the driver to be detected, but i2cdetect on the bus returns all --

adam@adam-linux-desktop:~/aura-gpu$ sudo i2cdetect 10
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-10.
I will probe address range 0x03-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

I noticed there are a bunch of errors in dmesg:

[ 8646.596719] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:206] Pre Transaction: addr = 77, offset = 0, rw = w, count = 1, out = 0
[ 8646.596721] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f4 0
[ 8646.596721] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f4 val 8
[ 8646.596724] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 1862 6db6d800
[ 8646.596725] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 1862 val 6db6d800
[ 8646.596726] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 0 val 12260
[ 8646.596728] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 1 0
[ 8646.596728] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 1 val 0
[ 8646.596730] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 1 0
[ 8646.596731] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 1 val 0
[ 8646.596733] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16fb 0
[ 8646.596734] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16fb val 2829
[ 8646.596736] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f7 3e80002
[ 8646.596737] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f7 val 3e80002
[ 8646.596739] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f7 3e80002
[ 8646.596739] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f7 val 3e80002
[ 8646.596741] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f5 0
[ 8646.596742] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f5 val 2
[ 8646.596744] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f9 23100
[ 8646.596744] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f9 val 13100
[ 8646.596747] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f9 13100
[ 8646.596747] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f9 val 13100
[ 8646.596749] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f9 13100
[ 8646.596750] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f9 val 23100
[ 8646.596750] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16fa val 8000ee00
[ 8646.596751] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16fa val 80010000
[ 8646.596752] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16fa val 80020000
[ 8646.596753] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16fa val 80030000
[ 8646.596755] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f4 8
[ 8646.596755] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f4 val 9
[ 8646.596857] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f6 2
[ 8646.596959] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f6 610
[ 8646.596961] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f6 610
[ 8646.596963] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f5 0
[ 8646.596963] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f5 val 2
[ 8646.596966] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f4 8
[ 8646.596966] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f4 val 2
[ 8646.596970] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16f4 2
[ 8646.596970] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16f4 val 0
[ 8646.596972] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:140] Read reg 16fb 2829
[ 8646.596973] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:152] Writing reg 16fb val 0
[ 8646.596974] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:216] Post Transaction: status = 2, read = 0
[ 8646.596974] lights aura: [/home/adam/aura-gpu/aura-gpu-hw.c:224] hw_i2c error 2

I haven't experimented in Windows (AMD ADL) yet but I will soon.

[twifty]

This driver is only suitable for ASUS cards. If you have Aida64 or MSI AfterBurner, you can easily and quickly dump the cards I2C (They internally use ADL).

[CalcProgrammer1]

I was under the impression that this project was an i2c driver for AMD GPUs. What is Aura-specific about that?

I got the Sapphire card's RGB controller partially reverse engineered. It uses i2c address 0x55. I was able to detect it with OpenRGB's ADL implementation and dump the registers as I changed them with TriXX. I've written a new OpenRGB controller based on this information and on Windows it is working.

What do I need to capture from Aida64/AfterBurner to get this driver working in Linux?

[twifty]

The ASUS cards have an IT8915FN chip on the board, visible via i2c, within which the AURA RGB can be controlled. AFAIK not all AMD cards have this chip. This module creates a driver for the known missing i2c bus and looks for that specific chip. While, on sapphire cards, another similar chip may be on the hidden i2c bus, I have no way to verify. The error you are seeing above is the driver trying to read to a chip that is not present on the bus.

An important note, I cannot simply create a driver for that bus because the amdgpu module controls all memory access locks. This driver is accessing an already loaded memory region, but since amdgpu doesn't seem to use the exact address it "shouldn't" cause any problems (kernel crashes). TBH I wish amd would add support for these missing buses, including the vega/navi cards. It would make life so much easier.

This repo exists only as a debugging aid to get it working on vega cards. It is not intended to be a standalone driver. Using it as such would more than likely cause kernel scheduler errors and crashes.

ADL reports the missing bus as #6. If you can confirm the bus and chip address, and also reveal which registers do what, I can add the support to the main lights module. In that case we should move this conversation over to the https://github.com/twifty/lights repo.

[twifty]

You might also want to try the first commit of this module. The master branch was reconfigured to work the cards BIOS (which didn't work), while the first commit used direct memory access.

[CalcProgrammer1]

Does that mean that even though this driver exposes a full i2c interface, it will only ever communicate to one address? I'm not seeing how this driver (which appears to be a generic i2c controller driver for the "unused" i2c port on the AMD GPU) is Aura specific. The IT8915FN would be an I2C slave device just like the 0x55 device on the Sapphire GPU would it not?

Is it possible to patch the amdgpu module to access this bus? I assume the code in here is duplicated from the code that accesses the DDC i2c busses?

I know for sure my Sapphire GPU RGB controller is at 0x55 as I can control it with ADL. I've i2cdetect'ed all AMD i2c ports as well as using this driver and was not able to find an 0x55. I also tried blind writing to 0x55 (which I know would change the color if successful) but the color did not change.

Interestingly, using the first commit of this driver I see a device at 0x20. If I i2cdump it I get this:

adam@Adam-Desktop-2:~/aura-gpu$ sudo i2cdump 8 0x20
No size specified (using byte-data access)
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-8, address 0x20, mode byte
Continue? [Y/n] 
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: XX ff ff ff XX XX XX XX XX XX XX XX XX XX XX XX    X...XXXXXXXXXXXX
10: ff XX XX XX XX XX XX XX XX ff XX XX XX XX XX XX    .XXXXXXXX.XXXXXX
20: ff ff XX XX ff ff ff XX XX XX XX XX XX XX XX XX    ..XX...XXXXXXXXX
30: XX XX XX XX XX XX XX XX ff ff XX XX XX XX XX XX    XXXXXXXX..XXXXXX
40: XX XX XX XX XX XX XX XX XX XX ff XX XX XX XX ff    XXXXXXXXXX.XXXX.
50: XX ff ff ff XX ff XX XX XX XX XX XX XX XX XX XX    X...X.XXXXXXXXXX
60: XX XX XX XX XX XX XX XX ff XX XX XX XX XX XX XX    XXXXXXXX.XXXXXXX
70: XX XX XX XX XX XX XX XX ff ff ff ff ff ff XX XX    XXXXXXXX......XX
80: XX XX XX XX XX XX XX XX ff XX XX ff ff ff XX XX    XXXXXXXX.XX...XX
90: XX XX XX XX XX XX ff XX XX ff ff ff XX XX XX XX    XXXXXX.XX...XXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: ff ff ff ff ff ff ff XX XX XX ff XX XX XX XX XX    .......XXX.XXXXX
e0: XX ff ff ff ff ff ff ff XX XX XX XX XX XX XX XX    X.......XXXXXXXX
f0: XX XX XX ff XX XX XX ff ff ff XX ff XX ff ff XX    XXX.XXX...X.X..X

Would this diagram be correct?

[twifty]

Forgive me, you are correct, I'm confusing the repos. This repo does exclude the AURA specific code. However it has been contorted to probe the only the vega cards.

From what I remember, the Polaris cards have two hidden buses. 4 are exposed, one for each of the display outs, 2 are completely excluded. Patching amdgpu to expose them would be a massive undertaking. First, the code base is a convulted mess, it doesn't follow the kernel coding guidlines at all (I'm surprised Linus has even allowed it). Second, the module has hard coded structs for each of the chips. Adding an extra i2c would confuse its DC detection. My plan was to get it working on all chips then contact the amdgpu devs and get it included.

Reconfiguring this repo to work with direct memory access on the Polaris chips should expose one of the two hidden i2c buses. However, It will take me a few days to rework the code. (I'm currently eyes deep in extra "unpaid" work, thank you covid). But, as I mentioned earlier, this repo only exists as a test case. It is not intended to be used in other projects and will likely be deleted in the future.

[twifty]

I've just ran an i2cdetect on the latest kernel. Looks like a few changes have been made since I last played with this code. Still the four i2c buses visible on my navi card but now they've also exposed three aux (which run over i2c) buses. I've been waiting for amdgpu to mature on navi cards before I start coding again. Looks like that time has come.

[CalcProgrammer1]

IIRC I had i2c-0 to i2c-7 without your driver. 0 was the chipset (i801), two were non-AMD (something like "dmdc" or similar, really short name, can't remember exactly, so the remaining 5 were AMD. My card has 5 outputs (2 HDMI, 2 DP, 1 DVI) so that would make sense.

[twifty]

Also to note, BIOS functions should work with the Polaris chipset, but I have not managed to get i2c access to work on navi. This is probably because the i2c algorithm was changed on vega but the kernels legacy ATOM BIOS has not been updated to reflect that change on newer cards. I have what I believe to be the correct memory addresses for vega/navi but without the exact algorithm it's like trying to understand a foreign language given only the vowels.

When I get an opportunity, I'll swap out my GPU for the 580 and revert this repo to a working state. From there I'll use the code base to probe my navi card. Hopefully in doing so I can also solve for vega cards. From this you'll have at least one commit that should expose the hidden bus. But as noted, it is not intended for public release. It WILL cause problems with the existing amdgpu driver.

All this being said, it's also possible for the chips we're looking for to not even be on an i2c bus and that ADL on windows is doing some magic under the hood to make it look like one. Very unlikely though.

[CalcProgrammer1]

I got something interesting from TriXX (Sapphire's software).

https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/134#note_380909655

Someone posted a .net DLL pulled from TriXX and I decompiled it. It very clearly has a WriteI2C function and is writing the expected values. It also has this configuration block that indicates port is 7. Device 85 is hex 0x55, which is what I got from "i2cdetect" using the ADL I2C interface.

  public class NitroGlowV1 : UserControl, IComponentConnector
  {
    private ApiBase.I2CParameters i2cParameters = new ApiBase.I2CParameters()
    {
      device = 85,
      port = 7,
      speed = 0,
      extraDelay = 0,
      flags = ApiBase.I2CFlags.SKIP_ADL_I2C
    };

Does port = 7 mean anything to you? I figure that should help us figure out which hidden i2c interface it uses?

[CalcProgrammer1]

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/1180401-switch-off-sapphire-nitro-5700-xt-rgb-leds-linux?p=1194495#post1194495

There is some discussion on Phoronix with one of the AMD driver developers. He suggested it might be the SMU bus. I noticed that none of the amdgpu busses were even showing. Apparently the display controller busses and GPU busses are different? There are two files:

drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.c

and

drivers/gpu/drm/amd/amdgpu_dm/amdgpu_dm.c

which both provide i2c interfaces.

The ones in amdgpu_i2c.c:

"AMDGPU i2c hw bus %s"

"AMDGPU i2c bit bus %s"

The ones in amdgpu_dm.c:

"AMDGPU DM i2c hw bus %d"

"AMDGPU DM aux hw bus %d"

My i2cdetect -l:

i2c-3	i2c       	AMDGPU DM i2c hw bus 0          	I2C adapter
i2c-1	smbus     	SMBus PIIX4 adapter port 2 at 0b00	SMBus adapter
i2c-8	i2c       	AMDGPU DM aux hw bus 0          	I2C adapter
i2c-6	i2c       	AMDGPU DM i2c hw bus 3          	I2C adapter
i2c-4	i2c       	AMDGPU DM i2c hw bus 1          	I2C adapter
i2c-2	smbus     	SMBus PIIX4 adapter port 1 at 0b20	SMBus adapter
i2c-0	smbus     	SMBus PIIX4 adapter port 0 at 0b00	SMBus adapter
i2c-9	i2c       	AMDGPU DM aux hw bus 1          	I2C adapter
i2c-7	i2c       	AMDGPU DM i2c hw bus 4          	I2C adapter
i2c-5	i2c       	AMDGPU DM i2c hw bus 2          	I2C adapter

Only the DM busses are showing. I found a flag amdgpu_hw_i2c that defaults to 0. I just built a kernel with it default to 1. Hopefully the other busses will show now.

[CalcProgrammer1]

Success! Sort of... The i2c-10 bus is the right one. I can detect the 0x55 controller and change mode (but not color for some reason).

i2c-0	smbus     	SMBus PIIX4 adapter port 0 at 0b00	SMBus adapter
i2c-1	smbus     	SMBus PIIX4 adapter port 2 at 0b00	SMBus adapter
i2c-2	smbus     	SMBus PIIX4 adapter port 1 at 0b20	SMBus adapter
i2c-3	i2c       	AMDGPU i2c hw bus 0x90          	I2C adapter
i2c-4	i2c       	AMDGPU i2c hw bus 0x91          	I2C adapter
i2c-5	i2c       	AMDGPU i2c hw bus 0x92          	I2C adapter
i2c-6	i2c       	AMDGPU i2c hw bus 0x93          	I2C adapter
i2c-7	i2c       	AMDGPU i2c hw bus 0x94          	I2C adapter
i2c-8	i2c       	AMDGPU i2c hw bus 0x95          	I2C adapter
i2c-9	i2c       	AMDGPU i2c hw bus 0x96          	I2C adapter
i2c-10	i2c       	AMDGPU i2c hw bus 0x97          	I2C adapter
i2c-11	i2c       	AMDGPU DM i2c hw bus 0          	I2C adapter
i2c-12	i2c       	AMDGPU DM i2c hw bus 1          	I2C adapter
i2c-13	i2c       	AMDGPU DM i2c hw bus 2          	I2C adapter
i2c-14	i2c       	AMDGPU DM i2c hw bus 3          	I2C adapter
i2c-15	i2c       	AMDGPU DM i2c hw bus 4          	I2C adapter
i2c-16	i2c       	AMDGPU DM aux hw bus 0          	I2C adapter
i2c-17	i2c       	AMDGPU DM aux hw bus 1          	I2C adapter

adam@adam-linux-desktop:~/linux$ git diff
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index a027a8f7b281..ea1e9b4f1684 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3168,7 +3168,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
                        goto failed;
                }
                /* init i2c buses */
-               if (!amdgpu_device_has_dc_support(adev))
+               //if (!amdgpu_device_has_dc_support(adev))
                        amdgpu_atombios_i2c_init(adev);
        }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 126e74758a34..ddd9d57bfdbd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -101,7 +101,7 @@ int amdgpu_benchmarking = 0;
 int amdgpu_testing = 0;
 int amdgpu_audio = -1;
 int amdgpu_disp_priority = 0;
-int amdgpu_hw_i2c = 0;
+int amdgpu_hw_i2c = 1;
 int amdgpu_pcie_gen2 = -1;
 int amdgpu_msi = -1;
 char amdgpu_lockup_timeout[AMDGPU_MAX_TIMEOUT_PARAM_LENGTH];

[CalcProgrammer1]

I'm pretty sure these are actually the same busses...there seems to be 8 busses total. It looks like the driver initializes just the display controller busses if the device has a display controller.

The DM aux busses seem to be their own independent thing (don't see the same i2cdetect pattern on any of the 0x9x busses).

0x90
0x91 - AMDGPU DM i2c hw bus 2 (Second HDMI port) (I can dump my TV's EDID here)
0x92
0x93 - AMDGPU DM i2c hw bus 3 (First HDMI port)
0x94
0x95 - AMDGPU DM i2c hw bus 4 (DVI port)
0x96
0x97 - Hidden bus with GPU RGB controller

Interesting to note - If I try to dump EDID from the DM interface, it works. If I try to dump EDID from the matching hw interface, it returns all 00. Maybe there's an issue with the hw driver? Maybe if I instead change the display controller code to forcibly init all busses it would work?

[CalcProgrammer1]

Two different i2c xfer functions:

amdgpu_dm.c

static int amdgpu_dm_i2c_xfer(struct i2c_adapter *i2c_adap,
			      struct i2c_msg *msgs, int num)
{
	struct amdgpu_i2c_adapter *i2c = i2c_get_adapdata(i2c_adap);
	struct ddc_service *ddc_service = i2c->ddc_service;
	struct i2c_command cmd;
	int i;
	int result = -EIO;

	cmd.payloads = kcalloc(num, sizeof(struct i2c_payload), GFP_KERNEL);

	if (!cmd.payloads)
		return result;

	cmd.number_of_payloads = num;
	cmd.engine = I2C_COMMAND_ENGINE_DEFAULT;
	cmd.speed = 100;

	for (i = 0; i < num; i++) {
		cmd.payloads[i].write = !(msgs[i].flags & I2C_M_RD);
		cmd.payloads[i].address = msgs[i].addr;
		cmd.payloads[i].length = msgs[i].len;
		cmd.payloads[i].data = msgs[i].buf;
	}

	if (dc_submit_i2c(
			ddc_service->ctx->dc,
			ddc_service->ddc_pin->hw_info.ddc_channel,
			&cmd))
		result = num;

	kfree(cmd.payloads);
	return result;
}

atombios_i2c.c

int amdgpu_atombios_i2c_xfer(struct i2c_adapter *i2c_adap,
		      struct i2c_msg *msgs, int num)
{
	struct amdgpu_i2c_chan *i2c = i2c_get_adapdata(i2c_adap);
	struct i2c_msg *p;
	int i, remaining, current_count, buffer_offset, max_bytes, ret;
	u8 flags;

	/* check for bus probe */
	p = &msgs[0];
	if ((num == 1) && (p->len == 0)) {
		ret = amdgpu_atombios_i2c_process_i2c_ch(i2c,
						  p->addr, HW_I2C_WRITE,
						  NULL, 0);
		if (ret)
			return ret;
		else
			return num;
	}

	for (i = 0; i < num; i++) {
		p = &msgs[i];
		remaining = p->len;
		buffer_offset = 0;
		/* max_bytes are a limitation of ProcessI2cChannelTransaction not the hw */
		if (p->flags & I2C_M_RD) {
			max_bytes = ATOM_MAX_HW_I2C_READ;
			flags = HW_I2C_READ;
		} else {
			max_bytes = ATOM_MAX_HW_I2C_WRITE;
			flags = HW_I2C_WRITE;
		}
		while (remaining) {
			if (remaining > max_bytes)
				current_count = max_bytes;
			else
				current_count = remaining;
			ret = amdgpu_atombios_i2c_process_i2c_ch(i2c,
							  p->addr, flags,
							  &p->buf[buffer_offset], current_count);
			if (ret)
				return ret;
			remaining -= current_count;
			buffer_offset += current_count;
		}
	}

	return num;
}

[twifty]

This is looking great. It looks like the kernel has undergone some major changes since I last looked.

The aux bus operates on top of the i2c and is used mainly to communicate with the monitor. I once thought ADL was using aux due the memory constraints it imposes are the same as for aux, but that lead to dead end. Unless something has changed, the hw flag you used defaulted to on and it controlled whether the driver uses the BIOS vs direct memory access. In my earlier tests changing the flag didn't expose the i2c. It was configured to only look for the four known display ports. From the look of your results that may have changed.

Regarding your change color problem. The aura chip doesn't accept bulk writes. It must be written a single byte at a time. Trying to write multiple will set the first but all remaining are dropped without an error. Might be a similar problem on your chip.

After today, my workload is significantly reduced, so I finally have the time to start playing with the kernel again.