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

[Dave Airlie]

On Fri, Oct 23, 2009 at 11:23 AM, ykzhao <yakui.zhao at intel.com> wrote:
> 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.
>

At least once on radeon we had a problem where the BIOS used a hw i2c
engine, and left
it enabled on those lines, so when the sw tried to do normal bit
banged i2c the hw engine
was getting in the way. Perhaps something similiar is happening here,
maybe the gmbus i2c
controller is getting left connected to the sdvo bus and interfering.

Dave.

> Thanks.
>>
>> Dave.
>
>