[Intel-gfx] [PATCH] drm/i915: Delete the strict EDID check for SDVO DVI-D monitor

[ykzhao]

On Thu, 2009-10-22 at 18:32 +0800, Dave Airlie wrote:
> On Thu, Oct 22, 2009 at 7:41 PM, ykzhao <yakui.zhao at intel.com> wrote:
> > On Thu, 2009-10-22 at 15:15 +0800, Keith Packard wrote:
> >> Excerpts from yakui.zhao's message of Thu Oct 22 14:25:33 +0900 2009:
> >> > From: Zhao Yakui <yakui.zhao at intel.com>
> >> >
> >> > In theory we can use EDID obtained from the DVI-D monitor to detect whether
> >> > the device is connected or not.
> >>
> >> The DVI spec *requires* EDID on DVI-D monitors. Do we have any
> >> information on why this is failing? Perhaps our EDID code is broken
> >> for some monitors?
> > This issue happens on one SDVO card with multiple inputs and multiple
> > outputs.
> >
> > At first IMO maybe this is related with the incorrect DDC bus behind
> > SDVO card. I write a debug patch which tries to read 128byte by using
> > different DDC bus.(PROM, DDC1, DDC2, DDC3).
> > Unfortunately it can read nothing even when the different DDC bus is
> > used. It always reports that there doesn't exist the 0xA0 slave address.
> >
> > But one bug reporter can read the EDID by using the
> > read-edid-tool(1.4.2), which is realized by using BIOS call.
> >
> > It is very interesting. Maybe our I2C bus code is different with that
> > used in Video-BIOS.
> >
> 
> You should be able to at least figure out which DDC lines the BIOS
> is using to narrow down whether its incorrect timing, incorrect DDC
> or some SDVO bus interaction issue. None of these are something
> the initial patch fixes.
Unfortunately I can't know which DDC bus is used to read EDID by BIOS.
The following is the output info when using the thiry-party
tool(read-edid-1.4.2)
   >VBE/DDC service about to be called
	Report DDC capabilities

	Performing real mode VBE call
	Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
	Function supported
	Call successful

	Monitor and video card combination does not support DDC1 transfers
	Monitor and video card combination supports DDC2 transfers
	0 seconds per 128 byte EDID block transfer
	Screen is not blanked during DDC transfer
  
>From the above info it seems that the BIOS reads the EDID by using DDC2 bus behind SDVO device.
But when they apply the debug patch which tries all the DDC bus to read the EDID, it can't read anything.

Our code uses the GPIO to simimulate the I2C bus, which is used in KMS and UMS mode. Even when
the system is booted with KMS disabled, it still can't read the EDID.

But it seems that the GMBUS protocol is used in video bios. Maybe there exists the difference
between the GPIO I2C and GMBUS I2C.

As we can't read the EDID on the boxes of bug 24282/24458/23842, it causes that the system can't
be booted correctly. This is a regression. 

So this patch is only to workaround this issue so that their boxes can be booted as what we
have done.

Of course I will investigate why we can't read the EDID on the box of 24282/24458/23842. But it 
will take long time. 

Thanks.
> 
> Dave.