Update: with Linux 4.4-rc2, the "dp_aux_ch not started" warning is gone, and there is no longer a several second hang on boot or when changing the screen resolution.
However, the HDMI output continues to be broken, and the log messages about the EDID checksum being invalid still appear.

I updated the bug title to reflect the fact that the HDMI output not working (because of the invalid EDID checksum) is now the only problem for me. So there must have been two separate problems originally, one of which was solved by the 4.4 merges.
I tried hacking the i915 driver code in a few different ways but none of them solved the problem:
- always setting force_bit=1 on the 'struct intel_gmbus'
- changing the drm_i915_private hotplug_work to a delayed_work and scheduling it with delay 400 ms
- increasing the number of retries in drm_do_get_edid() from 4 to 32
- increasing the number of retries of the "live status" check in intel_hdmi_detect() from 3 to 30
Also, I verified that the same monitor and VGA->HDMI adapter works on a Raspberry Pi. So that leaves the Skylake hardware and/or the i915 driver as the source of the problem.

Update:
Using a different cable, which connects the DVI input of the monitor to the HDMI output of the Skylake GPU, everything works as expected.
The non-working setup used a different adapter that connected the VGA input of the monitor to the HDMI output of the Skylake GPU.
So, the issue manifests itself with particular adapters and not with the HDMI output itself. It's also possible that everything works as intended on the Skylake side and the particular (brand new) adapter I used was "bad". However, I don't currently have any other HDMI->VGA adapters to test.
I will leave this bug open for now as several people are watching it, and it's possible they have encountered similar problems.

I see the "dp aux hw did not signal timeout" error logged on IvyBridge (although the display works ok). Possibly it could have the same root cause, which looks like a race condition in the init code, see bug #96428

I meet the same problem and currently using kernel 4.9.17. All versions I tested until now have the problem.
I also bought and tested 3 different adapters. As they all exhibit the same problem and the HDMI output works with regular monitors I now assume there is something specific with HDMI to VGA adapters.
I suspect is it related to EID or monitor signaling.
Machine is actually ASUS K501UX.
I can do some tests within my technical abilities.
Thanks.

Hi Elizabeth
Thank for your reply.
I know this is not exactly what you expected, but I don't know how to compile a kernel with patches. Perhaps I could try if you refer me to a proper howto.
What I did it instead is to test the kernel from
http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2017-07-29/
I assumed it to be very close to the kernel you had in mind.
On my PC (ASUS k501X), 4.13 kernel break Bumblebee and NVIDIA proprietary driver (384) support as Bumblebee can't start and the DKMS module can not be compiled. Nevertheless the machine runs normally using the intel graphic support.
Unfortunately the HDMI adapater detection does not work any better with this kernel. Perhaps you'd like me to provide some log or other test output.

(In reply to Marc Neiger from comment #24)
>
Hello Marc,
Latest drm-tip is ok, actually last dmesg attached is from 4.9 so a new dmesg could be helpful to compare, and if any other information is needed it will be commented here. Thank you again.

I can see the same issue (HDMI-to-VGA not working) on a Laptop with 965GM (Dell Inspiron 11z).
The same adapter works when used behind a DP-to-HDMI adapter, the obvious difference is the AUX-to-I2C bridge in the DP/HDMI adapter.
I hooked up a logic analyzer to the HDMI connection (that is, the DDC lines). There is no obvious protocol violation when connected to the 965GM, but there are a few observations:
-- using i2c-dev/i2cdump 4 0x50, on 965GM --
- when reading each byte individually (i.e. write offset, read byte), the whole EEPROM is read correctly
- when reading in blocks (write offset, read 32 bytes), the first byte is always correct, the second byte occasionally
-- comparing 965GM as master and DP adapter as master --
965GM: releases SDA (ACK) at the exact same time as SCL is pulled down
DP: SDA is kept stable for 500ns after SCL is pulled down
My current assuption is the HDMI-to-VGA adapter samples the SDA line with the falling edge of SCL, i.e. at a time where the SDA line is already pulled up again.
LA traces can be made available.

KVM and display are VGA.
PC is HDMI and connected to KVM through the adapter.
The KVM is likely to react differently than the display and use different timings or shift the display timings, whether reception or transmission.

First of all. Sorry about spam.
This is mass update for our bugs.
Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!
If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.