Troubleshooting LVDS on GM45.

Troubleshooting LVDS on GM45.

[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 "1920x1080@148.5M", 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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Troubleshooting LVDS on GM45.

[Jani Nikula]

On Fri, 01 Apr 2016, Rob Kramer <rob@solution-space.com> wrote:
> 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.


>
> 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 "1920x1080@148.5M", 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
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Troubleshooting LVDS on GM45.

[Rob Kramer]

On 04/01/2016 04:01 PM, Jani Nikula wrote:
> On Fri, 01 Apr 2016, Rob Kramer <rob@solution-space.com> wrote:
>> 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
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

[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


On 04/01/2016 12:49 PM, Rob Kramer wrote:
> 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 "1920x1080@148.5M", 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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

[Jani Nikula]

On Fri, 01 Apr 2016, Rob Kramer <rob@solution-space.com> wrote:
> 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?

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.


>
> Cheers!
>
>       Rob
>
>
> On 04/01/2016 12:49 PM, Rob Kramer wrote:
>> 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 "1920x1080@148.5M", 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
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[ville.syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

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: stable@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Rob Kramer <rob@solution-space.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: Rob Kramer <rob@solution-space.com>
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ä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index e6b5ee51739b..b6f974dd43c9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -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;
-- 
2.7.4

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

[ville.syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

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: dri-devel@lists.freedesktop.org
Cc: Rob Kramer <rob@solution-space.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 21 +++------------------
 1 file changed, 3 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index b6f974dd43c9..9d3752accaa5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -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);
 
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[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

== 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
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Ville Syrjälä]

On Fri, Apr 01, 2016 at 04:44:01PM -0000, Patchwork wrote:
> == 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)

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 ]---

> 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()

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[ville.syrjala]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

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: dri-devel@lists.freedesktop.org
Cc: Rob Kramer <rob@solution-space.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 22 ++++------------------
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index b6f974dd43c9..f42073837204 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -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);
 
-- 
2.7.4

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

[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

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


On 04/01/2016 07:11 PM, Jani Nikula wrote:
>
> 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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

[Ville Syrjälä]

On Mon, Apr 04, 2016 at 11:14:45AM +0800, Rob Kramer wrote:
> 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.

> 
> 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?

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.

> 
> Cheers!
> 
>        Rob
> 
> 
> On 04/01/2016 07:11 PM, Jani Nikula wrote:
> >
> > 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.
> >

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)

[Rob Kramer]

On 04/04/2016 10:58 PM, Ville Syrjälä wrote:
>
>> 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?
> 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

> 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 1920x1080@148.5M mode was added by the vendor of the 
display set to match the panel that they use.

Cheers,

      Rob


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Ville Syrjälä]

On Fri, Apr 01, 2016 at 09:48:50PM +0300, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> 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.

> 
> v2: Store dotclock in adjusted_mode instead of the final mode
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Rob Kramer <rob@solution-space.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c | 22 ++++------------------
>  1 file changed, 4 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index b6f974dd43c9..f42073837204 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -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);
>  
> -- 
> 2.7.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting ville.syrjala@linux.intel.com (2016-04-01 16:37:25)
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> 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: stable@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: Rob Kramer <rob@solution-space.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reported-by: Rob Kramer <rob@solution-space.com>
> 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ä <ville.syrjala@linux.intel.com>

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 <chris@chris-wilson.co.uk>
-Chris

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

[Chris Wilson]

Quoting ville.syrjala@linux.intel.com (2016-04-01 19:48:50)
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> 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: dri-devel@lists.freedesktop.org
> Cc: Rob Kramer <rob@solution-space.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Fixes a pipe-state warn for me,
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Ville Syrjälä]

On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote:
> Quoting ville.syrjala@linux.intel.com (2016-04-01 19:48:50)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > 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: dri-devel@lists.freedesktop.org
> > Cc: Rob Kramer <rob@solution-space.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Thanks for the review. Patches pushed to dinq.

> 
> Fixes a pipe-state warn for me,
> Tested-by: Chris Wilson <chris@chris-wilson.co.uk>

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...

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Chris Wilson]

Quoting Ville Syrjälä (2017-10-09 17:18:17)
> On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote:
> > Quoting ville.syrjala@linux.intel.com (2016-04-01 19:48:50)
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > 
> > > 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: dri-devel@lists.freedesktop.org
> > > Cc: Rob Kramer <rob@solution-space.com>
> > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> Thanks for the review. Patches pushed to dinq.
> 
> > 
> > Fixes a pipe-state warn for me,
> > Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> 
> 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
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Ville Syrjälä]

On Mon, Oct 09, 2017 at 05:24:29PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2017-10-09 17:18:17)
> > On Mon, Sep 25, 2017 at 08:19:12PM +0100, Chris Wilson wrote:
> > > Quoting ville.syrjala@linux.intel.com (2016-04-01 19:48:50)
> > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > 
> > > > 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: dri-devel@lists.freedesktop.org
> > > > Cc: Rob Kramer <rob@solution-space.com>
> > > > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > Thanks for the review. Patches pushed to dinq.
> > 
> > > 
> > > Fixes a pipe-state warn for me,
> > > Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > 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!

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

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx