Created attachment 30015 [details]
Log of successful detection

I tried this patch from bug 22002 <https://bugs.freedesktop.org/show_bug.cgi?id=22002>

https://bugs.freedesktop.org/attachment.cgi?id=29654

No joy.

is this a regression?

(In reply to comment #3)
> is this a regression?
> 

Not sure what you mean by regression.

I'm running current git (as of yesterday).  I was trying to solve the problem and saw the TV_Connector option in git and thought it would solve my problem.  Alas it appears to be effective only for i8?? chips, not i9?? chips which use the svdo code.  There's no way to bypass the load-detect in the svdo code, and I don't know enough to try to hack that in.

This behavior only happens when there is a monitor connected to the VGA port as well as the S-Video port.  If there is no monitor connected to the VGA port, then the detection succeeds every time.

Also, I tested with 1.6.0 (the xorg version packaged with ubuntu jaunty) and the behavior appears to be the same.

Created attachment 30337 [details] [review]
add the 30ms delay when detecting SDVO-TV

Will you please try the debug patch on the latest Eric's drm-intel-next tree and see whether the issue still exists?
Please add the boot option of "drm.debug=0x04" and attach the output of dmesg after doing the test.
Thanks.

Sorry, I'm not a regular xorg dev... Where do I get latest Eric's drm-intel-next tree?

(In reply to comment #7)
> Sorry, I'm not a regular xorg dev... Where do I get latest Eric's
> drm-intel-next tree?
You can use the following command to get the Eric's drm-intel-next tree:
a. git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git
b. git branch -r
c. git checkout -b origin/drm-intel-next

Of course the 2.6.32-rc4 kernel is also ok.
thanks.
> 

*** Bug 20785 has been marked as a duplicate of this bug. ***

Building 2.6.32.rc5 with the patch fails with:

ERROR: "__bad_udelay" [drivers/gpu/drm/i915/i915.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

(In reply to comment #10)
> Building 2.6.32.rc5 with the patch fails with:
> 
> ERROR: "__bad_udelay" [drivers/gpu/drm/i915/i915.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> 

I changed usleep to msleep in the above patch and rc5 compiled.

This appears to have solved the problem.

Created attachment 30683 [details] [review]
add the 15ms udelay to detect whether the SDVO-TV is connected

Thanks for your test.
From the test it seems that the SDVO-TV can be detected correctly if we add some delay.
But when you change from udelay to msleep, it will sleep too much time.

Will you please try the debug patch and see whether the SDVO-TV can be detected correctly?

Thanks.

I tried the 15ms patch.  Using either udelay(15000) or mdelay(15) results in hard lock on the machine.  It appears that X tries to start twice, then the machine hard locks the third time.  As the screen goes blank with complete signal loss, I have no way to guess what might have transpired.

I've reverted to the 30ms patch, which works fine.  I'm using mdelay(30) as udelay(30*1000) resulted in build failure.

(In reply to comment #13)
> I tried the 15ms patch.  Using either udelay(15000) or mdelay(15) results in
> hard lock on the machine.  It appears that X tries to start twice, then the
> machine hard locks the third time.  As the screen goes blank with complete
> signal loss, I have no way to guess what might have transpired.
It is very interesting that udelay/mdelay results in the hard lock. Maybe the udelay/mdelay for 15ms is inappropriate.
> 
> I've reverted to the 30ms patch, which works fine.  I'm using mdelay(30) as
> udelay(30*1000) resulted in build failure.
Do you mean that it can work fine if we using msleep for 30ms delay?
Thanks.
> 

(In reply to comment #14)
> (In reply to comment #13)
> > I tried the 15ms patch.  Using either udelay(15000) or mdelay(15) results in
> > hard lock on the machine.  It appears that X tries to start twice, then the
> > machine hard locks the third time.  As the screen goes blank with complete
> > signal loss, I have no way to guess what might have transpired.
> It is very interesting that udelay/mdelay results in the hard lock. Maybe the
> udelay/mdelay for 15ms is inappropriate.

Hardware dependent, I'd guess.  Maybe on a faster machine it may work.  I'm testing on an Atom 330 on a mini-itx board; not a speed champion.

To expand on the hardlock, gdm would try to start X twice, and hard lock on the third attempt.  That appeared to be reproducible the half-dozen or so times I tried.  The system is embedded and it's a bit of a pain to get to, so I'm not able to do a whole lot of testing that results in hard locks.

> > I've reverted to the 30ms patch, which works fine.  I'm using mdelay(30) as
> > udelay(30*1000) resulted in build failure.
> Do you mean that it can work fine if we using msleep for 30ms delay?
> Thanks.

Yes.  The system boots just fine with no perceptible delay.  mdelay(30) works fine.  I figured mdelay is sleep in msec and udelay is sleep in usec, so mdelay(30) should be the same as udelay(30000).

> Yes.  The system boots just fine with no perceptible delay.  mdelay(30) works
> fine.  I figured mdelay is sleep in msec and udelay is sleep in usec, so
> mdelay(30) should be the same as udelay(30000).
Is it msleep or mdelay?
It seems that the msleep is used in your test.
Thanks.
> 

        intel_sdvo_write_cmd(intel_output,
                             SDVO_CMD_GET_ATTACHED_DISPLAYS, NULL, 0);
        if (sdvo_priv->is_tv) {
                /* When it is SDVO-TV, add the 30ms delay */
                mdelay(30);
        }

(In reply to comment #17)
>         intel_sdvo_write_cmd(intel_output,
>                              SDVO_CMD_GET_ATTACHED_DISPLAYS, NULL, 0);
>         if (sdvo_priv->is_tv) {
>                 /* When it is SDVO-TV, add the 30ms delay */
>                 mdelay(30);
>         }
Thanks for the confirm.
It seems that the system can work well if we add 30ms delay by using mdelay. But it can't work if the 15ms delay is added. Right?
thanks.
> 

That is correct.