| Message ID | 20160215202633.GA23290@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* Ville Syrjälä > Could you test the following hack while using a 1920x1080 mode with > 148.5 MHz dotclock, and see if there's any improvement? I think it might be an improvement, that is, the blanking/flickers seems to occur less often than it did with 8ed1804, but it is not completely fixed. I've noticed 5-6 blankings events in the last hour or so (during most of those events I wasn't even using the computer actively, it was just sitting there showing a static image of gitk). Kernel output here: http://filebin.net/r3nlwu09y2/villepatched.txt Tore
* Tore Anderson > * Ville Syrjälä > > > Could you test the following hack while using a 1920x1080 mode with > > 148.5 MHz dotclock, and see if there's any improvement? > > I think it might be an improvement, that is, the blanking/flickers > seems to occur less often than it did with 8ed1804, but it is not > completely fixed. Hi again Ville, I spoke too soon. I've been doing some more testing with current Git master (e7d04bf). I'm now certain that your patch makes no difference whatsoever, the flickering/blanking is just as bad as before. The intensity/frequency of the problems vary significantly, so when I tested your patch previously I must have hit one of the better periods. As I write this, however, the computer is essentially rendered unusable. (I have no idea what causes this variance, unfortunately.) Do you (or anyone else for that matter) have any other ideas? 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.) Tore
On Fri, Feb 19, 2016 at 08:55:02PM +0100, Tore Anderson wrote: > * Tore Anderson > > > * Ville Syrjälä > > > > > Could you test the following hack while using a 1920x1080 mode with > > > 148.5 MHz dotclock, and see if there's any improvement? > > > > I think it might be an improvement, that is, the blanking/flickers > > seems to occur less often than it did with 8ed1804, but it is not > > completely fixed. > > Hi again Ville, > > I spoke too soon. I've been doing some more testing with current Git > master (e7d04bf). I'm now certain that your patch makes no difference > whatsoever, the flickering/blanking is just as bad as before. > > The intensity/frequency of the problems vary significantly, so when I > tested your patch previously I must have hit one of the better periods. > As I write this, however, the computer is essentially rendered > unusable. (I have no idea what causes this variance, unfortunately.) > > Do you (or anyone else for that matter) have any other ideas? "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. > > 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. There is at least one way to do it though, but it's quite involved. What you would need to do is dump the EDID, modify it to indicate that 12bpc isn't supported (and fix up the CRC), and then use the firmware EDID mechanism to override the EDID with the hacked up version.
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! Let me know if you want me to test more patches, post debug logs, or anything else. 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. > > 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
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
Hi Ville, > 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. Here: http://filebin.net/gd91wnltky/dmesg.4.5.0-rc4-g32fa589.txt I'm assuming the most important parts are: [drm:intel_hdmi_dp_dual_mode_detect] DP dual mode adaptor (type 1 HDMI) detected (max TMDS clock: 165000 kHz, TMDS OE# control: no) [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output For the record, I'd call my adapter a «cable» and not a «dongle». I had thought it was completely passive; if there's any active circuitry inside it it must be really tiny - it'd have to fit inside the rather standard-sized HDMI/DP connectors in the ends. Tore
On Wed, Feb 24, 2016 at 06:48:35PM +0100, Tore Anderson wrote: > Hi Ville, > > > 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. > > Here: http://filebin.net/gd91wnltky/dmesg.4.5.0-rc4-g32fa589.txt > > I'm assuming the most important parts are: > > [drm:intel_hdmi_dp_dual_mode_detect] DP dual mode adaptor (type 1 HDMI) detected (max TMDS clock: 165000 kHz, TMDS OE# control: no) > [drm:intel_hdmi_compute_config] picking bpc to 8 for HDMI output > > For the record, I'd call my adapter a «cable» and not a «dongle». I had > thought it was completely passive; if there's any active circuitry > inside it it must be really tiny - it'd have to fit inside the rather > standard-sized HDMI/DP connectors in the ends. Yeah, the chips used for this stuff are pretty small. I had one dongle fry itself a while back, so I pulled it apart and found a PS8121E chip inside it (with a number of other mostly passive components).
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 4e1321b96522..ea24de873e14 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12842,6 +12842,11 @@ intel_modeset_pipe_config(struct drm_crtc *crtc, clear_intel_crtc_state(pipe_config); + if (pipe_config->base.adjusted_mode.clock == 148500) { + DRM_ERROR("adjusting dotclock\n"); + pipe_config->base.adjusted_mode.clock = 148800; + } + pipe_config->cpu_transcoder = (enum transcoder) to_intel_crtc(crtc)->pipe;