https://bugs.freedesktop.org/show_bug.cgi?id=56461
--- Comment #41 from Chris Paulson-Ellis <ch...@edesix.com> --- Hi, I've been looking at the 'hsync' problem I first mentioned in comment 25. This problem seems to be caused by any interaction with i2c bus 2 and was uncovered by commit 486a45c2, because it fixed a previous bug... My VBIOS lists 3 i2c buses. Bus 0 is referenced by DCB entry 0 - OUTPUT_ANALOGUE. Bus 1 is referenced by DCB entries 1 & 2 - OUTPUT_LVDS & OUTPUT_TV. Prior to 486a45c2, bus 2 is never properly driven because nouveau_i2c_init() is called without there having been a call to read_dcb_i2c_entry() for index 2, so the bit-bang i2c adapter gets set up with 0 for the rd & wr variables (a later commit renames these to sense & drive). Surprisingly, the resulting incorrect CRTC register read/writes don't seem to trash the system and everything works okay. Commit 486a45c2 fixes the bug by parsing all 3 i2c entries up-front, so bus 2 gets a bit-bang i2c adapter with sensible rd & wr values. However, any access to this bus seems to cause the display to show the 'hsync' problem. The only reference to the bus is from nouveau_temp_probe_i2c(), so I've worked around the problem with the following hack: --- a/drivers/gpu/drm/nouveau/nouveau_temp.c +++ b/drivers/gpu/drm/nouveau/nouveau_temp.c @@ -287,11 +287,13 @@ static void nouveau_temp_probe_i2c(struct drm_device *dev) { struct i2c_board_info info[] = { +#if 0 { I2C_BOARD_INFO("w83l785ts", 0x2d) }, { I2C_BOARD_INFO("w83781d", 0x2d) }, { I2C_BOARD_INFO("adt7473", 0x2e) }, { I2C_BOARD_INFO("f75375", 0x2e) }, { I2C_BOARD_INFO("lm99", 0x4c) }, +#endif { } }; Re-adding any of the I2C_BOARD_INFO lines - I tried them 1 at a time - makes the problem come back. The simple 1 byte address test i2c transfer is enough to trigger the problem. The above work around is enough to make my display work again for commit 486a45c2, but the problem comes back in a later commit when the i2c lines are reset in the bit-bang adapter init code. I've had to add the following hack to work around the problem again: --- a/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/base.c @@ -327,9 +333,13 @@ nouveau_i2c_ctor(struct nouveau_object *parent, struct nouveau_object *engine, i2c_set_adapdata(&port->adapter, i2c); if (port->adapter.algo != &nouveau_i2c_aux_algo) { + if(i==2) { + nv_warn(i2c, "I2C%d: type %d index %x/%x - supressing scl/sda init\n", i, port->type, port->drive, port->sense); + } else { nouveau_i2c_drive_scl(port, 0); nouveau_i2c_drive_sda(port, 1); nouveau_i2c_drive_scl(port, 1); + } So it appears that even this simple attempt to reset the i2c lines on bus 2 is enough to destabilise the display. Obviously, these 2 hacks will need to be replaced with something better, but I've no idea what - perhaps a board specific i2c bus blacklist! None of this makes any difference to the fade-to-back problem introduced by commit cb75d97e, but I can now get its parent commit 70790f4f working. In summary, this is where I am: 70790f4f + 3bb076af + dpms-fix + i2c-2-hacks - works cb75d97e + 3bb076af + dpms-fix + i2c-2-hacks - fades to black Looking at the console output from these 2 tests, the only significant change seems to be a change of the AGP GART aperture from a sensible 64 MiB to 3712 MiB, which doesn't look right. The GART seem to be initialised later than before too. Regards, Chris. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau