Skip to contentSkip to conversation

Troubleshooting LVDS on GM45.

PATCH In review Rob Kramer 5 participants 19 messages Apr 1, 2016 – Oct 9, 2017

Subsystems (3)
Stable branch DRM drivers Intel i915
lore
Share & tools
lore

Rob Kramer

author
#0 lore raw

Hi,

My setup is an embedded GM45 based board with a screen connected via 24 bit LVDS. When trying a to use a newer kernel (3.14.57) with KMS, the screen stays blank. I'm only testing KMS so far, no X. Older, pre-KMS versions of the kernel worked fine.

I'm hoping that a resident Intel DRM guru has an idea of what might be wrong here, or can tell me where to continue troubleshooting :)

I've uploaded a kernel log (drm.debug=0xe) here: http://pastebin.com/nYNRGW5B

The video kernel parameter for this log is: video=LVDS-1:1920x1080. I've tried others, M and/or R suffixes, loading edid/1920x1080.bin etc, but nothing works. I'm not sure if all this EDID timing stuff is even used for LVDS..

One line in the log mentions a mode that is promising:

  [    5.534021] [drm:intel_dump_crtc_timings], crtc timings: 148571

1920 2040 2080 2200 1080 1097 1108 1125, type: 0x0 flags: 0xa

In the BIOS, the panel type is configured as "[email protected]", so that looks good. I have no idea where that modeline came from though.

From what I can see, LVDS-1 and CRTC 3 are connected, but when it's time to set the mode, it seems to have been modified into a bogus adjusted mode:

  [    5.570523] [drm:intel_dump_pipe_config], requested mode:
  [    5.570525] [drm:drm_mode_debug_printmodeline], Modeline 
0:"1920x1080" 0 172780 1920 2040 2248 2576 1080 1081 1084 1118 0x0 0x6
  [    5.570526] [drm:intel_dump_pipe_config], adjusted mode:
  [    5.570529] [drm:drm_mode_debug_printmodeline], Modeline 
0:"640x480" 0 148571 640 656 752 800 480 490 492 525 0x8 0x0
  [    5.570531] [drm:intel_dump_crtc_timings], crtc timings: 148571

640 656 752 800 480 490 492 525, type: 0x8 flags: 0x0

Also, the dot-clock mentioned in the HD mode is now 172780, for some reason..

All sorts of kernel warnings follow, after this (what is LVDS-6?):

  [    5.570569] [drm:intel_crtc_mode_set], [ENCODER:6:LVDS-6] set

[MODE:0:1920x1080]

Please let me know if you'd like more logging or details.

Cheers,

Rob

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

maintainer
#1 lore raw
Quoted 7 lines · Rob Kramer

My setup is an embedded GM45 based board with a screen connected via 24 bit LVDS. When trying a to use a newer kernel (3.14.57) with KMS, the screen stays blank. I'm only testing KMS so far, no X. Older, pre-KMS versions of the kernel worked fine.

I'm hoping that a resident Intel DRM guru has an idea of what might be wrong here, or can tell me where to continue troubleshooting :)

I'll put it bluntly, I don't think anyone's interested in troubleshooting v3.14 anymore. Please try v4.5.

BR,
Jani.

Quoted 48 lines

I've uploaded a kernel log (drm.debug=0xe) here:
http://pastebin.com/nYNRGW5B

The video kernel parameter for this log is: video=LVDS-1:1920x1080. I've tried others, M and/or R suffixes, loading edid/1920x1080.bin etc, but nothing works. I'm not sure if all this EDID timing stuff is even used for LVDS..

One line in the log mentions a mode that is promising:

   [    5.534021] [drm:intel_dump_crtc_timings], crtc timings: 148571

1920 2040 2080 2200 1080 1097 1108 1125, type: 0x0 flags: 0xa

In the BIOS, the panel type is configured as "[email protected]", so that looks good. I have no idea where that modeline came from though.

From what I can see, LVDS-1 and CRTC 3 are connected, but when it's
time to set the mode, it seems to have been modified into a bogus adjusted mode:

   [    5.570523] [drm:intel_dump_pipe_config], requested mode:
   [    5.570525] [drm:drm_mode_debug_printmodeline], Modeline 
0:"1920x1080" 0 172780 1920 2040 2248 2576 1080 1081 1084 1118 0x0 0x6
   [    5.570526] [drm:intel_dump_pipe_config], adjusted mode:
   [    5.570529] [drm:drm_mode_debug_printmodeline], Modeline 
0:"640x480" 0 148571 640 656 752 800 480 490 492 525 0x8 0x0
   [    5.570531] [drm:intel_dump_crtc_timings], crtc timings: 148571

640 656 752 800 480 490 492 525, type: 0x8 flags: 0x0

Also, the dot-clock mentioned in the HD mode is now 172780, for some reason..

All sorts of kernel warnings follow, after this (what is LVDS-6?):

   [    5.570569] [drm:intel_crtc_mode_set], [ENCODER:6:LVDS-6] set

[MODE:0:1920x1080]

Please let me know if you'd like more logging or details.

Cheers,

Rob

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Signature · 5 lines
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
author
#2 lore raw
Quoted 10 lines · Jani Nikula
Quoted 7 lines · Rob Kramer

My setup is an embedded GM45 based board with a screen connected via 24 bit LVDS. When trying a to use a newer kernel (3.14.57) with KMS, the screen stays blank. I'm only testing KMS so far, no X. Older, pre-KMS versions of the kernel worked fine.

I'm hoping that a resident Intel DRM guru has an idea of what might be wrong here, or can tell me where to continue troubleshooting :)

I'll put it bluntly, I don't think anyone's interested in troubleshooting v3.14 anymore. Please try v4.5.

I don't mind blunt.

I've tried 4.4 on a Fedora live disk, which had the same issue, superficially. But I guess you're right, I ought to try a newer kernel first.

I'll post a new log when I've got 4.5 installed.

Cheers!

Rob
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

author
#3 lore raw

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

In reply to Rob Kramer

Here's the same issue on a more reasonable kernel. The log looks quite different, but the end result is still a blank screen. Uploaded here: http://pastebin.com/WLpT5mPc

This section looks promising:

[    4.763951] [drm:intel_dump_pipe_config] requested mode:
[    4.763953] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148571 1920 2040 2080 2200 1080 1097 1108 1125 0x40 0xa
[    4.763955] [drm:intel_dump_pipe_config] adjusted mode:
[    4.763958] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 60 148571 1920 2040 2080 2200 1080 1097 1108 1125 0x40 0xa
[    4.763961] [drm:intel_dump_crtc_timings] crtc timings: 148571 1920 2040 2080 2200 1080 1097 1108 1125, type: 0x40 flags: 0xa

.. but I don't know how relevant it is. I also have no idea where those timings came from.

Could anyone tell me what I could try next?

Cheers!

Rob

Quoted 32 lines · Rob Kramer

Hi,

My setup is an embedded GM45 based board with a screen connected via 24 bit LVDS. When trying a to use a newer kernel (3.14.57) with KMS, the screen stays blank. I'm only testing KMS so far, no X. Older, pre-KMS versions of the kernel worked fine.

I'm hoping that a resident Intel DRM guru has an idea of what might be wrong here, or can tell me where to continue troubleshooting :)

I've uploaded a kernel log (drm.debug=0xe) here: http://pastebin.com/nYNRGW5B

The video kernel parameter for this log is: video=LVDS-1:1920x1080. I've tried others, M and/or R suffixes, loading edid/1920x1080.bin etc, but nothing works. I'm not sure if all this EDID timing stuff is even used for LVDS..

One line in the log mentions a mode that is promising:

  [    5.534021] [drm:intel_dump_crtc_timings], crtc timings: 148571

1920 2040 2080 2200 1080 1097 1108 1125, type: 0x0 flags: 0xa

In the BIOS, the panel type is configured as "[email protected]", so that looks good. I have no idea where that modeline came from though.

From what I can see, LVDS-1 and CRTC 3 are connected, but when it's time to set the mode, it seems to have been modified into a bogus adjusted mode:

  [    5.570523] [drm:intel_dump_pipe_config], requested mode:
  [    5.570525] [drm:drm_mode_debug_printmodeline], Modeline 
0:"1920x1080" 0 172780 1920 2040 2248 2576 1080 1081 1084 1118 0x0 0x6
  [    5.570526] [drm:intel_dump_pipe_config], adjusted mode:
  [    5.570529] [drm:drm_mode_debug_printmodeline], Modeline 
0:"640x480" 0 148571 640 656 752 800 480 490 492 525 0x8 0x0
  [    5.570531] [drm:intel_dump_crtc_timings], crtc timings: 148571

640 656 752 800 480 490 492 525, type: 0x8 flags: 0x0

Also, the dot-clock mentioned in the HD mode is now 172780, for some reason..

All sorts of kernel warnings follow, after this (what is LVDS-6?):

Quoted 9 lines
  [    5.570569] [drm:intel_crtc_mode_set], [ENCODER:6:LVDS-6] set

[MODE:0:1920x1080]

Please let me know if you'd like more logging or details.

Cheers,

Rob

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

maintainer
#4 lore raw

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

Quoted 13 lines · Rob Kramer

Here's the same issue on a more reasonable kernel. The log looks quite different, but the end result is still a blank screen. Uploaded here:
http://pastebin.com/WLpT5mPc

This section looks promising:

[    4.763951] [drm:intel_dump_pipe_config] requested mode:
[    4.763953] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 
60 148571 1920 2040 2080 2200 1080 1097 1108 1125 0x40 0xa
[    4.763955] [drm:intel_dump_pipe_config] adjusted mode:
[    4.763958] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 
60 148571 1920 2040 2080 2200 1080 1097 1108 1125 0x40 0xa
[    4.763961] [drm:intel_dump_crtc_timings] crtc timings: 148571 1920
Quoted 6 lines

2040 2080 2200 1080 1097 1108 1125, type: 0x40 flags: 0xa

.. but I don't know how relevant it is. I also have no idea where those timings came from.

Could anyone tell me what I could try next?

Apr  1 11:32:21 vides user.err kernel: [    4.896341] [drm:i9xx_crtc_compute_clock [i915]] *ERROR* Couldn't find PLL settings for mode!

Please try without the kernel command line mode.

BR,
Jani.

Quoted 65 lines

Cheers!

Rob

Quoted 44 lines · Rob Kramer

Hi,

My setup is an embedded GM45 based board with a screen connected via 24 bit LVDS. When trying a to use a newer kernel (3.14.57) with KMS, the screen stays blank. I'm only testing KMS so far, no X. Older, pre-KMS versions of the kernel worked fine.

I'm hoping that a resident Intel DRM guru has an idea of what might be wrong here, or can tell me where to continue troubleshooting :)

I've uploaded a kernel log (drm.debug=0xe) here:
http://pastebin.com/nYNRGW5B

The video kernel parameter for this log is: video=LVDS-1:1920x1080. I've tried others, M and/or R suffixes, loading edid/1920x1080.bin etc, but nothing works. I'm not sure if all this EDID timing stuff is even used for LVDS..

One line in the log mentions a mode that is promising:

  [    5.534021] [drm:intel_dump_crtc_timings], crtc timings: 148571

1920 2040 2080 2200 1080 1097 1108 1125, type: 0x0 flags: 0xa

In the BIOS, the panel type is configured as "[email protected]", so that looks good. I have no idea where that modeline came from though.

From what I can see, LVDS-1 and CRTC 3 are connected, but when it's time to set the mode, it seems to have been modified into a bogus adjusted mode:

  [    5.570523] [drm:intel_dump_pipe_config], requested mode:
  [    5.570525] [drm:drm_mode_debug_printmodeline], Modeline 
0:"1920x1080" 0 172780 1920 2040 2248 2576 1080 1081 1084 1118 0x0 0x6
  [    5.570526] [drm:intel_dump_pipe_config], adjusted mode:
  [    5.570529] [drm:drm_mode_debug_printmodeline], Modeline 
0:"640x480" 0 148571 640 656 752 800 480 490 492 525 0x8 0x0
  [    5.570531] [drm:intel_dump_crtc_timings], crtc timings: 148571

640 656 752 800 480 490 492 525, type: 0x8 flags: 0x0

Also, the dot-clock mentioned in the HD mode is now 172780, for some reason..

All sorts of kernel warnings follow, after this (what is LVDS-6?):

Quoted 9 lines
  [    5.570569] [drm:intel_crtc_mode_set], [ENCODER:6:LVDS-6] set

[MODE:0:1920x1080]

Please let me know if you'd like more logging or details.

Cheers,

Rob

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Signature · 5 lines
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
author
#5 lore raw

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

I've tried again without video parameter -- same outcome. I've also applied Ville's patch "drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()" (with teeny backport fix). It seems this code is never called in my case though, since intel_lvds_init() chooses to use the VBT mode instead. Log is uploaded here: http://pastebin.com/bGa2UvLu

Since this VBT mode is probably junk anyway, I commented out the if-statement that selects it (in intel_lvds.c), so that the code will pick the mode as set by BIOS. The result is much better, I actually get proper looking output! X also runs well on top of that.

There are still several errors in the log file though (probably caused by my little hack), see here: http://pastebin.com/UbCjizSV.

Is using the mode as set up by BIOS the way to go for LVDS? If so, is there a module parameter that can force this, or force the bogus VBT to be disregarded?

Cheers!

Rob

Quoted 8 lines · Jani Nikula
Apr  1 11:32:21 vides user.err kernel: [    4.896341] [drm:i9xx_crtc_compute_clock [i915]] *ERROR* Couldn't find PLL settings for mode!

Please try without the kernel command line mode.

BR,
Jani.

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#6 lore raw

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

Quoted 6 lines · Rob Kramer

I've tried again without video parameter -- same outcome. I've also applied Ville's patch "drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()" (with teeny backport fix). It seems this code is never called in my case though, since intel_lvds_init() chooses to use the VBT mode instead. Log is uploaded here:
http://pastebin.com/bGa2UvLu

That's a bit odd. The 3.14 kernel definitely chose to use the current pipe timings instead of the VBT mode:

[    5.504033] [drm:intel_lvds_init], using current (BIOS) mode:
[    5.504037] [drm:drm_mode_debug_printmodeline], Modeline 0:"640x480" 0 148571 640 656 752 800 480 490 492 525 0x0 0x0

Although it looks like it did find a mode in the VBT as well:

[    5.502056] [drm:parse_lfp_panel_data], Found panel mode in BIOS VBT tables:
[    5.502060] [drm:drm_mode_debug_printmodeline], Modeline 0:"1024x768" 0 65000 1024 1048 1184 1344 768 771 777 806 0x8 0xa

so now I'm rather confused as to how it managed to not use it.

Quoted 6 lines

Since this VBT mode is probably junk anyway, I commented out the if-statement that selects it (in intel_lvds.c), so that the code will pick the mode as set by BIOS. The result is much better, I actually get proper looking output! X also runs well on top of that.

Quoted 6 lines

There are still several errors in the log file though (probably caused by my little hack), see here: http://pastebin.com/UbCjizSV.

Is using the mode as set up by BIOS the way to go for LVDS? If so, is there a module parameter that can force this, or force the bogus VBT to be disregarded?

Can you provide a dump of /sys/kernel/debug/dri/0/i915_opregion ?

Maybe file a bug in bugs.freedesktop.org and attach it (and the dmesg logs you already have) there so we don't lose these.

You also said you can choose the panel type in the BIOS? Does it have some predefined set of panels or something? I would have assumed changing that might patch the VBT to point at the correct timings.

Quoted 15 lines

Cheers!

Rob

Quoted 8 lines · Jani Nikula
Apr  1 11:32:21 vides user.err kernel: [    4.896341] [drm:i9xx_crtc_compute_clock [i915]] *ERROR* Couldn't find PLL settings for mode!

Please try without the kernel command line mode.

BR,
Jani.

Signature · 6 lines
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
author
#7 lore raw

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

Quoted 9 lines · Ville Syrjälä
Quoted 9 lines

Since this VBT mode is probably junk anyway, I commented out the if-statement that selects it (in intel_lvds.c), so that the code will pick the mode as set by BIOS. The result is much better, I actually get proper looking output! X also runs well on top of that.

There are still several errors in the log file though (probably caused by my little hack), see here: http://pastebin.com/UbCjizSV.

Quoted 7 lines
Quoted 3 lines

Is using the mode as set up by BIOS the way to go for LVDS? If so, is there a module parameter that can force this, or force the bogus VBT to be disregarded?

Can you provide a dump of /sys/kernel/debug/dri/0/i915_opregion ?

Maybe file a bug in bugs.freedesktop.org and attach it (and the dmesg logs you already have) there so we don't lose these.

Sure! I added the opregion blob to the newly opened bug here: https://bugs.freedesktop.org/show_bug.cgi?id=94825

Quoted 3 lines

You also said you can choose the panel type in the BIOS? Does it have some predefined set of panels or something? I would have assumed changing that might patch the VBT to point at the correct timings.

Yes, there's a list of modes, and the correct one is selected. I've added an image to the bug entry. I don't know if the 1024x768 mode mentioned in the boot log is the same as the 1024x768 mode in that bios list, or why only that mode is found..

I assume that the [email protected] mode was added by the vendor of the display set to match the panel that they use.

Cheers,

Rob

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#8 lore raw

PATCH 1/2 drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()

In reply to Rob Kramer

From: Ville Syrjälä <[email protected]>

intel_crtc->config->cpu_transcoder isn't yet filled out when intel_crtc_mode_get() gets called during output probing, so we should not use it there. Instead intel_crtc_mode_get() figures out the correct transcoder on its own, and that's what we should use.

If the BIOS boots LVDS on pipe B, intel_crtc_mode_get() would actually end up reading the timings from pipe A instead (since PIPE_A==0), which clearly isn't what we want.

It looks to me like this may have been broken by
commit eccb140bca67 ("drm/i915: hw state readout&check support for cpu_transcoder") as that one removed the early initialization of cpu_transcoder from intel_crtc_init().

Cc [email protected]
Cc [email protected]
Cc Rob Kramer <[email protected]>
Cc Daniel Vetter <[email protected]>
Reported-by Rob Kramer <[email protected]>
Fixes eccb140bca67 ("drm/i915: hw state readout&check support for cpu_transcoder")

References: https://lists.freedesktop.org/archives/dri-devel/2016-April/104142.html

Signed-off-by Ville Syrjälä <[email protected]>
---
 drivers/gpu/drm/i915/intel_display.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)
drivers/gpu/drm/i915/intel_display.c +9 -5
index e6b5ee51739b..b6f974dd43c9 100644
@@ -10719,13 +10719,10 @@ struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-	enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
+	enum transcoder cpu_transcoder;
 	struct drm_display_mode *mode;
 	struct intel_crtc_state *pipe_config;
-	int htot = I915_READ(HTOTAL(cpu_transcoder));
-	int hsync = I915_READ(HSYNC(cpu_transcoder));
-	int vtot = I915_READ(VTOTAL(cpu_transcoder));
-	int vsync = I915_READ(VSYNC(cpu_transcoder));
+	u32 htot, hsync, vtot, vsync;
 	enum pipe pipe = intel_crtc->pipe;
 
 	mode = kzalloc(sizeof(*mode), GFP_KERNEL);

@@ -10753,6 +10750,13 @@ struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
 	i9xx_crtc_clock_get(intel_crtc, pipe_config);
 
 	mode->clock = pipe_config->port_clock / pipe_config->pixel_multiplier;
+
+	cpu_transcoder = pipe_config->cpu_transcoder;
+	htot = I915_READ(HTOTAL(cpu_transcoder));
+	hsync = I915_READ(HSYNC(cpu_transcoder));
+	vtot = I915_READ(VTOTAL(cpu_transcoder));
+	vsync = I915_READ(VSYNC(cpu_transcoder));
+
 	mode->hdisplay = (htot & 0xffff) + 1;
 	mode->htotal = ((htot & 0xffff0000) >> 16) + 1;
 	mode->hsync_start = (hsync & 0xffff) + 1;
Signature · 1 line
2.7.4
#9 lore raw

PATCH 2/2 drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

From: Ville Syrjälä <[email protected]>

Eliminate the duplicate code for pipe timing readout in intel_crtc_mode_get() by using the functions we use for the normal state readout.

Cc [email protected]
Cc Rob Kramer <[email protected]>
Cc Daniel Vetter <[email protected]>
Signed-off-by Ville Syrjälä <[email protected]>
---
 drivers/gpu/drm/i915/intel_display.c | 21 +++------------------
 1 file changed, 3 insertions(+), 18 deletions(-)
drivers/gpu/drm/i915/intel_display.c +3 -18
index b6f974dd43c9..9d3752accaa5 100644
@@ -10719,10 +10719,8 @@ struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-	enum transcoder cpu_transcoder;
 	struct drm_display_mode *mode;
 	struct intel_crtc_state *pipe_config;
-	u32 htot, hsync, vtot, vsync;
 	enum pipe pipe = intel_crtc->pipe;
 
 	mode = kzalloc(sizeof(*mode), GFP_KERNEL);

@@ -10749,24 +10747,11 @@ struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
 	pipe_config->dpll_hw_state.fp1 = I915_READ(FP1(pipe));
 	i9xx_crtc_clock_get(intel_crtc, pipe_config);
 
-	mode->clock = pipe_config->port_clock / pipe_config->pixel_multiplier;
-
-	cpu_transcoder = pipe_config->cpu_transcoder;
-	htot = I915_READ(HTOTAL(cpu_transcoder));
-	hsync = I915_READ(HSYNC(cpu_transcoder));
-	vtot = I915_READ(VTOTAL(cpu_transcoder));
-	vsync = I915_READ(VSYNC(cpu_transcoder));
+	mode->crtc_clock = pipe_config->port_clock / pipe_config->pixel_multiplier;
 
-	mode->hdisplay = (htot & 0xffff) + 1;
-	mode->htotal = ((htot & 0xffff0000) >> 16) + 1;
-	mode->hsync_start = (hsync & 0xffff) + 1;
-	mode->hsync_end = ((hsync & 0xffff0000) >> 16) + 1;
-	mode->vdisplay = (vtot & 0xffff) + 1;
-	mode->vtotal = ((vtot & 0xffff0000) >> 16) + 1;
-	mode->vsync_start = (vsync & 0xffff) + 1;
-	mode->vsync_end = ((vsync & 0xffff0000) >> 16) + 1;
+	intel_get_pipe_timings(intel_crtc, pipe_config);
 
-	drm_mode_set_name(mode);
+	intel_mode_from_pipe_config(mode, pipe_config);
 
 	kfree(pipe_config);
Signature · 6 lines
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
#10 lore raw

PATCH v2 2/2 drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

From: Ville Syrjälä <[email protected]>

Eliminate the duplicate code for pipe timing readout in intel_crtc_mode_get() by using the functions we use for the normal state readout.

v2: Store dotclock in adjusted_mode instead of the final mode

Cc [email protected]
Cc Rob Kramer <[email protected]>
Cc Daniel Vetter <[email protected]>
Signed-off-by Ville Syrjälä <[email protected]>
---
 drivers/gpu/drm/i915/intel_display.c | 22 ++++------------------
 1 file changed, 4 insertions(+), 18 deletions(-)
drivers/gpu/drm/i915/intel_display.c +4 -18
index b6f974dd43c9..f42073837204 100644
@@ -10719,10 +10719,8 @@ struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-	enum transcoder cpu_transcoder;
 	struct drm_display_mode *mode;
 	struct intel_crtc_state *pipe_config;
-	u32 htot, hsync, vtot, vsync;
 	enum pipe pipe = intel_crtc->pipe;
 
 	mode = kzalloc(sizeof(*mode), GFP_KERNEL);

@@ -10749,24 +10747,12 @@ struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
 	pipe_config->dpll_hw_state.fp1 = I915_READ(FP1(pipe));
 	i9xx_crtc_clock_get(intel_crtc, pipe_config);
 
-	mode->clock = pipe_config->port_clock / pipe_config->pixel_multiplier;
-
-	cpu_transcoder = pipe_config->cpu_transcoder;
-	htot = I915_READ(HTOTAL(cpu_transcoder));
-	hsync = I915_READ(HSYNC(cpu_transcoder));
-	vtot = I915_READ(VTOTAL(cpu_transcoder));
-	vsync = I915_READ(VSYNC(cpu_transcoder));
+	pipe_config->base.adjusted_mode.crtc_clock =
+		pipe_config->port_clock / pipe_config->pixel_multiplier;
 
-	mode->hdisplay = (htot & 0xffff) + 1;
-	mode->htotal = ((htot & 0xffff0000) >> 16) + 1;
-	mode->hsync_start = (hsync & 0xffff) + 1;
-	mode->hsync_end = ((hsync & 0xffff0000) >> 16) + 1;
-	mode->vdisplay = (vtot & 0xffff) + 1;
-	mode->vtotal = ((vtot & 0xffff0000) >> 16) + 1;
-	mode->vsync_start = (vsync & 0xffff) + 1;
-	mode->vsync_end = ((vsync & 0xffff0000) >> 16) + 1;
+	intel_get_pipe_timings(intel_crtc, pipe_config);
 
-	drm_mode_set_name(mode);
+	intel_mode_from_pipe_config(mode, pipe_config);
 
 	kfree(pipe_config);
Signature · 6 lines
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
#11 lore raw

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

Quoted 5 lines · On Fri, Apr 01, 2016 at 09:48:50PM +0300, [email protected] wrote:

From: Ville Syrjälä <[email protected]>

Eliminate the duplicate code for pipe timing readout in intel_crtc_mode_get() by using the functions we use for the normal state readout.

I also forgot to point out here that this should fix mode.flags readout for intel_crtc_mode_get(). Previously it just left tha t as 0.

Quoted 62 lines

v2: Store dotclock in adjusted_mode instead of the final mode

Cc [email protected]
Cc Rob Kramer <[email protected]>
Cc Daniel Vetter <[email protected]>
Signed-off-by Ville Syrjälä <[email protected]>
---
 drivers/gpu/drm/i915/intel_display.c | 22 ++++------------------
 1 file changed, 4 insertions(+), 18 deletions(-)
drivers/gpu/drm/i915/intel_display.c +4 -18
index b6f974dd43c9..f42073837204 100644
@@ -10719,10 +10719,8 @@ struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-	enum transcoder cpu_transcoder;
 	struct drm_display_mode *mode;
 	struct intel_crtc_state *pipe_config;
-	u32 htot, hsync, vtot, vsync;
 	enum pipe pipe = intel_crtc->pipe;
 
 	mode = kzalloc(sizeof(*mode), GFP_KERNEL);

@@ -10749,24 +10747,12 @@ struct drm_display_mode *intel_crtc_mode_get(struct drm_device *dev,
 	pipe_config->dpll_hw_state.fp1 = I915_READ(FP1(pipe));
 	i9xx_crtc_clock_get(intel_crtc, pipe_config);
 
-	mode->clock = pipe_config->port_clock / pipe_config->pixel_multiplier;
-
-	cpu_transcoder = pipe_config->cpu_transcoder;
-	htot = I915_READ(HTOTAL(cpu_transcoder));
-	hsync = I915_READ(HSYNC(cpu_transcoder));
-	vtot = I915_READ(VTOTAL(cpu_transcoder));
-	vsync = I915_READ(VSYNC(cpu_transcoder));
+	pipe_config->base.adjusted_mode.crtc_clock =
+		pipe_config->port_clock / pipe_config->pixel_multiplier;
 
-	mode->hdisplay = (htot & 0xffff) + 1;
-	mode->htotal = ((htot & 0xffff0000) >> 16) + 1;
-	mode->hsync_start = (hsync & 0xffff) + 1;
-	mode->hsync_end = ((hsync & 0xffff0000) >> 16) + 1;
-	mode->vdisplay = (vtot & 0xffff) + 1;
-	mode->vtotal = ((vtot & 0xffff0000) >> 16) + 1;
-	mode->vsync_start = (vsync & 0xffff) + 1;
-	mode->vsync_end = ((vsync & 0xffff0000) >> 16) + 1;
+	intel_get_pipe_timings(intel_crtc, pipe_config);
 
-	drm_mode_set_name(mode);
+	intel_mode_from_pipe_config(mode, pipe_config);
 
 	kfree(pipe_config);
Signature · 6 lines
2.7.4

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Signature · 6 lines
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by Tested-by on v2 2/2
#12 lore raw

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

In reply to [email protected]

Quoting [email protected] (2016-04-01 19:48:50)

Quoted 6 lines

From: Ville Syrjälä <[email protected]>

Eliminate the duplicate code for pipe timing readout in intel_crtc_mode_get() by using the functions we use for the normal state readout.

Quoted 6 lines

v2: Store dotclock in adjusted_mode instead of the final mode

Cc [email protected]
Cc Rob Kramer <[email protected]>
Cc Daniel Vetter <[email protected]>
Signed-off-by Ville Syrjälä <[email protected]>
Reviewed-by Chris Wilson <[email protected]>

Fixes a pipe-state warn for me,

Tested-by Chris Wilson <[email protected]>

-Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#13 lore raw

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

Quoted 7 lines · Chris Wilson

Quoting [email protected] (2016-04-01 19:48:50)

Quoted 6 lines

From: Ville Syrjälä <[email protected]>

Eliminate the duplicate code for pipe timing readout in intel_crtc_mode_get() by using the functions we use for the normal state readout.

Quoted 7 lines
Quoted 6 lines

v2: Store dotclock in adjusted_mode instead of the final mode

Cc [email protected]
Cc Rob Kramer <[email protected]>
Cc Daniel Vetter <[email protected]>
Signed-off-by Ville Syrjälä <[email protected]>
Reviewed-by Chris Wilson <[email protected]>

Thanks for the review. Patches pushed to dinq.

Quoted 3 lines

Fixes a pipe-state warn for me,

Tested-by Chris Wilson <[email protected]>

However, now that I look at the code again I'm not 100% sure why this fixed anything. The readout still seems to fail at fully populating the mode flags. I'll post a more thorough solution that simply calls the normal state readout hooks for the crtc and encoder...

Signature · 6 lines
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
#14 lore raw

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

Quoting Ville Syrjälä (2017-10-09 17:18:17)

Quoted 19 lines · Chris Wilson
Quoted 7 lines

Quoting [email protected] (2016-04-01 19:48:50)

Quoted 6 lines

From: Ville Syrjälä <[email protected]>

Eliminate the duplicate code for pipe timing readout in intel_crtc_mode_get() by using the functions we use for the normal state readout.

Quoted 7 lines
Quoted 6 lines

v2: Store dotclock in adjusted_mode instead of the final mode

Cc [email protected]
Cc Rob Kramer <[email protected]>
Cc Daniel Vetter <[email protected]>
Signed-off-by Ville Syrjälä <[email protected]>
Reviewed-by Chris Wilson <[email protected]>

Thanks for the review. Patches pushed to dinq.

Quoted 1 line
Quoted 7 lines
Quoted 2 lines

Fixes a pipe-state warn for me,

Tested-by Chris Wilson <[email protected]>

However, now that I look at the code again I'm not 100% sure why this fixed anything. The readout still seems to fail at fully populating the mode flags. I'll post a more thorough solution that simply calls the normal state readout hooks for the crtc and encoder...

The first patch fixed up the implied A,B transcoder mixup. I just tested both patches together. Do you want me to double check if it was just the first patch that silenced the warnings? I'm just happy to have a clean boot!
-Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#15 lore raw

Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()

Quoted 28 lines · Chris Wilson

Quoting Ville Syrjälä (2017-10-09 17:18:17)

Quoted 19 lines · Chris Wilson
Quoted 7 lines

Quoting [email protected] (2016-04-01 19:48:50)

Quoted 6 lines

From: Ville Syrjälä <[email protected]>

Eliminate the duplicate code for pipe timing readout in intel_crtc_mode_get() by using the functions we use for the normal state readout.

Quoted 7 lines
Quoted 6 lines

v2: Store dotclock in adjusted_mode instead of the final mode

Cc [email protected]
Cc Rob Kramer <[email protected]>
Cc Daniel Vetter <[email protected]>
Signed-off-by Ville Syrjälä <[email protected]>
Reviewed-by Chris Wilson <[email protected]>

Thanks for the review. Patches pushed to dinq.

Quoted 1 line
Quoted 7 lines
Quoted 2 lines

Fixes a pipe-state warn for me,

Tested-by Chris Wilson <[email protected]>

However, now that I look at the code again I'm not 100% sure why this fixed anything. The readout still seems to fail at fully populating the mode flags. I'll post a more thorough solution that simply calls the normal state readout hooks for the crtc and encoder...

Quoted 4 lines

The first patch fixed up the implied A,B transcoder mixup. I just tested both patches together. Do you want me to double check if it was just the first patch that silenced the warnings? I'm just happy to have a clean boot!

I think the first patch should have been a nop for you since 845g only has the one pipe.

Signature · 6 lines
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by on v1 1/2
#16 lore raw

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()

In reply to [email protected]

Quoting [email protected] (2016-04-01 16:37:25)

Quoted 16 lines

From: Ville Syrjälä <[email protected]>

intel_crtc->config->cpu_transcoder isn't yet filled out when intel_crtc_mode_get() gets called during output probing, so we should not use it there. Instead intel_crtc_mode_get() figures out the correct transcoder on its own, and that's what we should use.

If the BIOS boots LVDS on pipe B, intel_crtc_mode_get() would actually end up reading the timings from pipe A instead (since PIPE_A==0), which clearly isn't what we want.

It looks to me like this may have been broken by
commit eccb140bca67 ("drm/i915: hw state readout&check support for cpu_transcoder") as that one removed the early initialization of cpu_transcoder from intel_crtc_init().

Quoted 8 lines
Cc [email protected]
Cc [email protected]
Cc Rob Kramer <[email protected]>
Cc Daniel Vetter <[email protected]>
Reported-by Rob Kramer <[email protected]>
Fixes eccb140bca67 ("drm/i915: hw state readout&check support for cpu_transcoder")

References: https://lists.freedesktop.org/archives/dri-devel/2016-April/104142.html

Signed-off-by Ville Syrjälä <[email protected]>

Matches the writing on the tin.
The effect is to s/intel_crtc->config->cpu_transcoder/intel_crtc->pipe/ and aiui, the dvo path will call this before intel_crtc->config->cpu_transcoder is ever set.

Reviewed-by Chris Wilson <[email protected]>

-Chris

CI
#17 lore raw

✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()

In reply to Rob Kramer
== Series Details ==

== Series Details ==

Series: series starting with [1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()
URL : https://patchwork.freedesktop.org/series/5183/
State : warning

== Summary ==

Series 5183v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5183/revisions/1/mbox/

Test gem_sync:

        Subgroup basic-all:
                pass       -> DMESG-WARN (snb-dellxps)
Test kms_force_connector_basic:
        Subgroup force-edid:
                skip       -> PASS       (ivb-t430s)
bdw-nuci7        total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultra        total:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2        total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc          total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox      total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2          total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p      total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430s        total:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2        total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5        total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps      total:196  pass:161  dwarn:1   dfail:0   fail:0   skip:34 
snb-x220t        total:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33

Results at /archive/results/CI_IGT_test/Patchwork_1777/

38b47023a604068e2a222ac166f5f8ef7d56e352 drm-intel-nightly: 2016y-04m-01d-12h-04m-08s UTC integration manifest 3f8006df79544c32af65fdde19355cba7c7d6517 drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get() d6b04b87cdc9249f426a25206915dfabee27f671 drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()

_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

#18 lore raw

Re: ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()

Quoted 6 lines · Patchwork

== Series Details ==

Series: series starting with [1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()
URL : https://patchwork.freedesktop.org/series/5183/
State : warning

Quoted 8 lines

== Summary ==

Series 5183v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5183/revisions/1/mbox/

Test gem_sync:

        Subgroup basic-all:
                pass       -> DMESG-WARN (snb-dellxps)

Network issue of some sort.

[  189.725107] ------------[ cut here ]------------
[  189.725120] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x23a/0x240
[  189.725136] Modules linked in: snd_hda_intel i915 smsc75xx usbnet mii snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core mei_me snd_pcm mei lpc_ich [last unloaded: i915]
[  189.725161] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G     U          4.6.0-rc1-gfxbench+ #1
[  189.725164] Hardware name: Dell Inc. XPS 8300  /0Y2MRG, BIOS A06 10/17/2011
[  189.725168]  0000000000000000 ffff88012fa03d80 ffffffff81404dc5 ffff88012fa03dd0
[  189.725175]  0000000000000000 ffff88012fa03dc0 ffffffff81079b7c 0000012f2fa03e00
[  189.725179]  0000000000000000 0000000000000000 ffff8800365938d8 ffff8800bb344560
[  189.725183] Call Trace:
[  189.725184]  <IRQ>  [<ffffffff81404dc5>] dump_stack+0x67/0x92
[  189.725192]  [<ffffffff81079b7c>] __warn+0xcc/0xf0
[  189.725195]  [<ffffffff81079bea>] warn_slowpath_fmt+0x4a/0x50
[  189.725198]  [<ffffffff816f514a>] dev_watchdog+0x23a/0x240
[  189.725202]  [<ffffffff816f4f10>] ? dev_graft_qdisc+0x70/0x70
[  189.725207]  [<ffffffff810ee67f>] call_timer_fn+0x8f/0x350
[  189.725210]  [<ffffffff810ee5f0>] ? process_timeout+0x10/0x10
[  189.725216]  [<ffffffff816f4f10>] ? dev_graft_qdisc+0x70/0x70
[  189.725220]  [<ffffffff810eeba2>] run_timer_softirq+0x262/0x3a0
[  189.725227]  [<ffffffff8108002e>] __do_softirq+0x11e/0x4a0
[  189.725233]  [<ffffffff81080514>] irq_exit+0x84/0xa0
[  189.725237]  [<ffffffff8103bfbd>] smp_apic_timer_interrupt+0x3d/0x50
[  189.725244]  [<ffffffff817d1ee9>] apic_timer_interrupt+0x89/0x90
[  189.725247]  <EOI>  [<ffffffff81669fc3>] ? cpuidle_enter_state+0xe3/0x310
[  189.725254]  [<ffffffff81669fbe>] ? cpuidle_enter_state+0xde/0x310
[  189.725258]  [<ffffffff8166a212>] cpuidle_enter+0x12/0x20
[  189.725262]  [<ffffffff810c3335>] call_cpuidle+0x25/0x40
[  189.725265]  [<ffffffff810c36f9>] cpu_startup_entry+0x2a9/0x3d0
[  189.725269]  [<ffffffff817c8837>] rest_init+0x127/0x130
[  189.725273]  [<ffffffff81d6ae88>] start_kernel+0x3fb/0x408
[  189.725276]  [<ffffffff81d6a491>] x86_64_start_reservations+0x2a/0x2c
[  189.725280]  [<ffffffff81d6a578>] x86_64_start_kernel+0xe5/0xe8
[  189.725295] ---[ end trace 693fcfdf42f88556 ]---
Quoted 22 lines

Test kms_force_connector_basic:

        Subgroup force-edid:
                skip       -> PASS       (ivb-t430s)
bdw-nuci7        total:196  pass:184  dwarn:0   dfail:0   fail:0   skip:12 
bdw-ultra        total:196  pass:175  dwarn:0   dfail:0   fail:0   skip:21 
bsw-nuc-2        total:196  pass:159  dwarn:0   dfail:0   fail:0   skip:37 
byt-nuc          total:196  pass:161  dwarn:0   dfail:0   fail:0   skip:35 
hsw-brixbox      total:196  pass:174  dwarn:0   dfail:0   fail:0   skip:22 
hsw-gt2          total:196  pass:179  dwarn:0   dfail:0   fail:0   skip:17 
ilk-hp8440p      total:196  pass:132  dwarn:0   dfail:0   fail:0   skip:64 
ivb-t430s        total:196  pass:171  dwarn:0   dfail:0   fail:0   skip:25 
skl-i7k-2        total:196  pass:173  dwarn:0   dfail:0   fail:0   skip:23 
skl-nuci5        total:196  pass:185  dwarn:0   dfail:0   fail:0   skip:11 
snb-dellxps      total:196  pass:161  dwarn:1   dfail:0   fail:0   skip:34 
snb-x220t        total:196  pass:162  dwarn:0   dfail:0   fail:1   skip:33

Results at /archive/results/CI_IGT_test/Patchwork_1777/

38b47023a604068e2a222ac166f5f8ef7d56e352 drm-intel-nightly: 2016y-04m-01d-12h-04m-08s UTC integration manifest 3f8006df79544c32af65fdde19355cba7c7d6517 drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get() d6b04b87cdc9249f426a25206915dfabee27f671 drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()

Signature · 6 lines
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx