From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Tore Anderson <tore@fud.no>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [BUG] HDMI 12bpc causing occasional flickering and blanking
Date: Wed, 24 Feb 2016 17:09:27 +0200 [thread overview]
Message-ID: <20160224150927.GA15993@intel.com> (raw)
In-Reply-To: <20160223204449.15b69196@envy.w5.y.home>
On Tue, Feb 23, 2016 at 08:44:49PM +0100, Tore Anderson wrote:
> Hi Ville,
>
> > "The monitor is connected with a DP+-to-HDMI cable"
> > This and some reading of the DP dual mode spec gave me another idea;
> > The DP->HDMI adaptor may simply be degrading the signal quality too
> > much. According to the DP dual mode spec we're supposed to limit the
> > TMDS clock based on the type of adapter used, but currently we have
> > no code to do that. I've cooked up a few patches that should do what
> > we want:
> > git://github.com/vsyrjala/linux.git dp_dual_mode
> >
> > I've quickly tested it locally, and it seemed to do the right thing
> > with a few different types of adaptors.
>
> I've run 32fa589 for a few hours now and it have not seen a single
> blank or flicker. So it seems you've nailed it - thanks a lot!
Excellent.
>
> Let me know if you want me to test more patches, post debug logs, or
> anything else.
Well, just to check the details of your particular cable/dongle,
maybe you can post the dmesg with drm.debug=0xe with my branch?
Or at least the parts that refer to DP dual mode adaptors.
>
> BTW, also discovered right before you sent that e-mail that downgrading
> to a 1920x1080i mode (rather than the monitor's native 1920x1080) would
> also stop the flickering. I'd assume that also fits well with your
> diagnosis (less bandwidth needed => better tolerance for degraded signal
> quality), but I thought I'd let you know in case not.
Yeah, interlaced requires half the bandwidth of progressive, so it
should then fit comfortably within the 165MHz limit of the adaptor.
>
> > > By the way: Is it possible to disable HDMI 12bpc in a way that
> > > doesn't require me to patch and rebuild the kernel drivers, such as
> > > a kernel module parameter or sysfs setting? (I prefer to simply use
> > > the upstream Fedora kernel RPMs, but this issue is currently making
> > > that impossible.)
> >
> > We don't have any knob to control this.
>
> I don't need it anymore, so no worries. ;-)
>
> Tore
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-02-24 15:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-15 19:17 [BUG] HDMI 12bpc causing occasional flickering and blanking Tore Anderson
2016-02-15 20:26 ` Ville Syrjälä
2016-02-15 22:37 ` Tore Anderson
2016-02-19 19:55 ` Tore Anderson
2016-02-23 14:41 ` Ville Syrjälä
2016-02-23 19:44 ` Tore Anderson
2016-02-24 15:09 ` Ville Syrjälä [this message]
2016-02-24 17:48 ` Tore Anderson
2016-02-24 18:53 ` Ville Syrjälä
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=20160224150927.GA15993@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tore@fud.no \
/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.