From: Thomas Fjellstrom <thomas@fjellstrom.ca>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Jerome Glisse <j.glisse@gmail.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: long delay when using HMDI output on RS780
Date: Mon, 9 May 2011 21:22:32 -0600 [thread overview]
Message-ID: <201105092122.32284.thomas@fjellstrom.ca> (raw)
In-Reply-To: <201105091532.48331.thomas@fjellstrom.ca>
On May 9, 2011, Thomas Fjellstrom wrote:
> On May 9, 2011, Alex Deucher wrote:
> > On Mon, May 9, 2011 at 5:04 PM, Thomas Fjellstrom <thomas@fjellstrom.ca>
>
> wrote:
> > > On May 9, 2011, Thomas Fjellstrom wrote:
> > >> On May 9, 2011, Jerome Glisse wrote:
> > >> > On Mon, May 9, 2011 at 3:50 PM, Thomas Fjellstrom
> > >> > <thomas@fjellstrom.ca>
> > >>
> > >> wrote:
> > >> > > On May 7, 2011, Thomas Fjellstrom wrote:
> > >> > >> I just switched to using HDMI with my media center, and its
> > >> > >> causing a 30+ second delay in the screen turning on, as well as
> > >> > >> a 7 second delay in the X startup when it tries to fetch the
> > >> > >> EDID
> > >> > >> information. Basically I don't get any picture at all once KMS
> > >> > >> initializes until after X has been up a few seconds.
> > >> > >>
> > >> > >> The odd thing is the monitor seems to think something is going
> > >> > >> on, since it doesn't go to sleep or display its "No Signal" OSD,
> > >> > >> but just after X starts up, it pops up the "Input
> > >> > >> detected/switched" OSD, and the picture appears.
> > >> > >>
> > >> > >> The bios, grub2 (in both text mode and graphics mode), and the
> > >> > >> initial linux kernel messages all display fine and immediately.
> > >> > >> Its only once KMS and radeondrmfb initializes that there's a
> > >> > >> problem (at least till X starts up).
> > >> > >>
> > >> > >> I've just built with a vanila 2.6.38.4 kernel from the stable git
> > >> > >> repo, and have played with some EDID settings, trying to disable
> > >> > >> edid where I could thinking thats what caused the problem. That
> > >> > >> doesn't seem to be the case though. I also tried playing with the
> > >> > >> video= kernel option, trying to force disable VGA-1, and set a
> > >> > >> static mode for HDMI-A-1, but if I try, it seems to force disable
> > >> > >> HDMI-A-1 instead of force the mode.
> > >> > >>
> > >> > >> With a DVI-D cable instead, the problem goes away.
> > >> > >>
> > >> > >> Attached are the dmesg and xorg.log files for the latest boot
> > >> > >> with HDMI (no video= parameter, and EDID enabled, most settings
> > >> > >> at defaults).
> > >> > >>
> > >> > >> What exactly would cause this, and is there a way I can fix it?
> > >> > >
> > >> > > I've been playing around with it more, and got it to not blank the
> > >> > > screen after KMS init, /once/. So far no luck repeating that
> > >> > > success.
> > >> > >
> > >> > > I've tried late, and early kms init, and currently have the radeon
> > >> > > module and firmware compiled into the kernel. Boot times at least
> > >> > > are fairly decent, about 8-10s till X starts, but about 25-35s
> > >> > > till anything shows up.
> > >> > >
> > >> > > Some strangeness, I have the kernel set to force the hdmi output
> > >> > > to on, with a very specific mode, that X tends to like, the vga
> > >> > > port is forced disabled. X is set to ignore EDID, and also set to
> > >> > > that specific mode that it tends to auto set itself. Regardless X
> > >> > > still wants to pause for 7s 2-3 times while processing EDID info.
> > >> > >
> > >> > > I've attached the new dmesg and xorg logs from the latest
> > >> > > attempts.
> > >> > >
> > >> > > Note, this only happens with KMS, with HDMI. disabling KMS, or
> > >> > > using DVI makes the problem go away. Even grub's own graphical
> > >> > > mode works fine, its only once KMS inits that things go bad, and
> > >> > > its not till after X is up for a few seconds that something
> > >> > > displays on my screen.
> > >> > >
> > >> > > --
> > >> > > Thomas Fjellstrom
> > >> > > thomas@fjellstrom.ca
> > >> >
> > >> > Please boot with drm.debug=4 and attach dmesg it should be more
> > >> > verbose. You might also want to try booting with radeon.audio=0
> > >>
> > >> Hi, attached both one with just drm.debug=4, and one with that and
> > >> radeon.audio=0.
> > >>
> > >> Now, I'm guessing its a bug in my monitor claiming it can do HDMI
> > >> audio? As setting radeon.audio=0 seems to have fixed the blanking
> > >> problem. And the dmesg logs seem to claim that radeon thinks it can
> > >> do HDMI audio.
> >
> > Most likely the driver is sending the wrong packets for hdmi audio.
> > Until that gets fixed up, it's probably best to disable hdmi audio if
> > it's not working for you.
>
> Ok. I'll do that for now, since I have no need for HDMI audio atm. My
> receiver is only capable of Dolby Pro Logic input, so eh.
>
> Would be nice to fix the xorg pauses. And whatever is causing the massive
> amounts of drm log spam (yes, I could disable drm.debug, but that would
> just hide the issue, as whatever it is, will keep doing whatever it is
> doing regardless).
Any hints on where to look to fix the stalls when the xorg radeon driver starts
up?
> > Alex
> >
> > >> It also seems to be ignoring the mode I've requested via the video=
> > >> param. It at least sees that I want it forced enabled, but claims its
> > >> 0x0? Or at least it seems its picking the preferred mode.
> > >>
> > >> Still have X blocking for up to 14s though.
> > >>
> > >> Theres also a bunch of repeated log messages from drm now, every
> > >> second about it seems to spam the following lines: (the last one is
> > >> repeated a bunch of times, with FB:44 or FB:42)
> > >>
> > >> [ 31.330033] [drm:output_poll_execute], [CONNECTOR:13:VGA-1] status
> > >> updated from 2 to 2
> > >> [ 31.435455] [drm:radeon_atombios_connected_scratch_regs], DFP1
> > >> connected [ 31.435463] [drm:output_poll_execute],
> > >> [CONNECTOR:15:HDMI-A-1] status updated from 1 to 1
> > >> [ 31.437391] [drm:drm_mode_addfb], [FB:42]
> > >>
> > >> > Cheers,
> > >> > Jerome
> > >
> > > Ok, a bit more news. My monitor does indeed support audio, at least it
> > > has volume buttons, so I assume it has speakers, and should support
> > > HDMI audio (I have never used it though).
> > >
> > > --
> > > Thomas Fjellstrom
> > > thomas@fjellstrom.ca
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
--
Thomas Fjellstrom
thomas@fjellstrom.ca
next prev parent reply other threads:[~2011-05-10 3:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-08 0:15 long delay when using HMDI output on RS780 Thomas Fjellstrom
2011-05-09 19:50 ` Thomas Fjellstrom
2011-05-09 20:03 ` Jerome Glisse
2011-05-09 20:46 ` Thomas Fjellstrom
2011-05-09 21:04 ` Thomas Fjellstrom
2011-05-09 21:20 ` Alex Deucher
2011-05-09 21:32 ` Thomas Fjellstrom
2011-05-10 3:22 ` Thomas Fjellstrom [this message]
2011-05-10 18:19 ` Jerome Glisse
2011-05-10 18:19 ` Jerome Glisse
2011-05-10 18:37 ` Thomas Fjellstrom
2011-05-10 21:41 ` Alex Deucher
2011-05-10 21:41 ` Alex Deucher
2011-05-10 23:16 ` Thomas Fjellstrom
2011-05-09 20:21 ` Alex Deucher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201105092122.32284.thomas@fjellstrom.ca \
--to=thomas@fjellstrom.ca \
--cc=alexdeucher@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=j.glisse@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.