* Re: Troubleshooting LVDS on GM45.
2016-04-01 4:49 Troubleshooting LVDS on GM45 Rob Kramer
@ 2016-04-01 8:01 ` Jani Nikula
2016-04-01 8:11 ` Rob Kramer
2016-04-01 10:07 ` Troubleshooting LVDS on GM45 (kernel 4.5.0) Rob Kramer
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Jani Nikula @ 2016-04-01 8:01 UTC (permalink / raw)
To: Rob Kramer, dri-devel; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: Troubleshooting LVDS on GM45.
2016-04-01 8:01 ` Jani Nikula
@ 2016-04-01 8:11 ` Rob Kramer
0 siblings, 0 replies; 19+ messages in thread
From: Rob Kramer @ 2016-04-01 8:11 UTC (permalink / raw)
To: Jani Nikula, dri-devel; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)
2016-04-01 4:49 Troubleshooting LVDS on GM45 Rob Kramer
2016-04-01 8:01 ` Jani Nikula
@ 2016-04-01 10:07 ` Rob Kramer
2016-04-01 11:11 ` Jani Nikula
2016-04-01 15:37 ` [PATCH 1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get() ville.syrjala
2016-04-01 16:44 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] " Patchwork
3 siblings, 1 reply; 19+ messages in thread
From: Rob Kramer @ 2016-04-01 10:07 UTC (permalink / raw)
To: dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)
2016-04-01 10:07 ` Troubleshooting LVDS on GM45 (kernel 4.5.0) Rob Kramer
@ 2016-04-01 11:11 ` Jani Nikula
2016-04-04 3:14 ` Rob Kramer
0 siblings, 1 reply; 19+ messages in thread
From: Jani Nikula @ 2016-04-01 11:11 UTC (permalink / raw)
To: Rob Kramer, dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)
2016-04-01 11:11 ` Jani Nikula
@ 2016-04-04 3:14 ` Rob Kramer
2016-04-04 14:58 ` Ville Syrjälä
0 siblings, 1 reply; 19+ messages in thread
From: Rob Kramer @ 2016-04-04 3:14 UTC (permalink / raw)
To: dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)
2016-04-04 3:14 ` Rob Kramer
@ 2016-04-04 14:58 ` Ville Syrjälä
2016-04-05 4:07 ` Rob Kramer
0 siblings, 1 reply; 19+ messages in thread
From: Ville Syrjälä @ 2016-04-04 14:58 UTC (permalink / raw)
To: Rob Kramer; +Cc: dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Troubleshooting LVDS on GM45 (kernel 4.5.0)
2016-04-04 14:58 ` Ville Syrjälä
@ 2016-04-05 4:07 ` Rob Kramer
0 siblings, 0 replies; 19+ messages in thread
From: Rob Kramer @ 2016-04-05 4:07 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH 1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()
2016-04-01 4:49 Troubleshooting LVDS on GM45 Rob Kramer
2016-04-01 8:01 ` Jani Nikula
2016-04-01 10:07 ` Troubleshooting LVDS on GM45 (kernel 4.5.0) Rob Kramer
@ 2016-04-01 15:37 ` ville.syrjala
2016-04-01 15:37 ` [PATCH 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() " ville.syrjala
2017-09-25 14:18 ` [Intel-gfx] [PATCH 1/2] drm/i915: Read timings from the correct transcoder " Chris Wilson
2016-04-01 16:44 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] " Patchwork
3 siblings, 2 replies; 19+ messages in thread
From: ville.syrjala @ 2016-04-01 15:37 UTC (permalink / raw)
To: intel-gfx; +Cc: stable, dri-devel, Rob Kramer, Daniel Vetter
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
^ permalink raw reply related [flat|nested] 19+ messages in thread* [PATCH 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
2016-04-01 15:37 ` [PATCH 1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get() ville.syrjala
@ 2016-04-01 15:37 ` ville.syrjala
2016-04-01 18:48 ` [PATCH v2 " ville.syrjala
2017-09-25 14:18 ` [Intel-gfx] [PATCH 1/2] drm/i915: Read timings from the correct transcoder " Chris Wilson
1 sibling, 1 reply; 19+ messages in thread
From: ville.syrjala @ 2016-04-01 15:37 UTC (permalink / raw)
To: intel-gfx; +Cc: Rob Kramer, Daniel Vetter, dri-devel
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
^ permalink raw reply related [flat|nested] 19+ messages in thread* [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
2016-04-01 15:37 ` [PATCH 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() " ville.syrjala
@ 2016-04-01 18:48 ` ville.syrjala
2016-04-13 12:08 ` Ville Syrjälä
2017-09-25 19:19 ` Chris Wilson
0 siblings, 2 replies; 19+ messages in thread
From: ville.syrjala @ 2016-04-01 18:48 UTC (permalink / raw)
To: intel-gfx; +Cc: Rob Kramer, Daniel Vetter, dri-devel
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
^ permalink raw reply related [flat|nested] 19+ messages in thread* Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
2016-04-01 18:48 ` [PATCH v2 " ville.syrjala
@ 2016-04-13 12:08 ` Ville Syrjälä
2017-09-25 19:19 ` Chris Wilson
1 sibling, 0 replies; 19+ messages in thread
From: Ville Syrjälä @ 2016-04-13 12:08 UTC (permalink / raw)
To: intel-gfx; +Cc: Rob Kramer, Daniel Vetter, dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
2016-04-01 18:48 ` [PATCH v2 " ville.syrjala
2016-04-13 12:08 ` Ville Syrjälä
@ 2017-09-25 19:19 ` Chris Wilson
2017-10-09 16:18 ` Ville Syrjälä
1 sibling, 1 reply; 19+ messages in thread
From: Chris Wilson @ 2017-09-25 19:19 UTC (permalink / raw)
To: ville.syrjala, intel-gfx; +Cc: Rob Kramer, Daniel Vetter, dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
2017-09-25 19:19 ` Chris Wilson
@ 2017-10-09 16:18 ` Ville Syrjälä
2017-10-09 16:24 ` Chris Wilson
0 siblings, 1 reply; 19+ messages in thread
From: Ville Syrjälä @ 2017-10-09 16:18 UTC (permalink / raw)
To: Chris Wilson; +Cc: Rob Kramer, Daniel Vetter, intel-gfx, dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
2017-10-09 16:18 ` Ville Syrjälä
@ 2017-10-09 16:24 ` Chris Wilson
2017-10-09 16:48 ` Ville Syrjälä
0 siblings, 1 reply; 19+ messages in thread
From: Chris Wilson @ 2017-10-09 16:24 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: Rob Kramer, Daniel Vetter, intel-gfx, dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v2 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() in intel_crtc_mode_get()
2017-10-09 16:24 ` Chris Wilson
@ 2017-10-09 16:48 ` Ville Syrjälä
0 siblings, 0 replies; 19+ messages in thread
From: Ville Syrjälä @ 2017-10-09 16:48 UTC (permalink / raw)
To: Chris Wilson; +Cc: Rob Kramer, Daniel Vetter, intel-gfx, dri-devel
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [Intel-gfx] [PATCH 1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()
2016-04-01 15:37 ` [PATCH 1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get() ville.syrjala
2016-04-01 15:37 ` [PATCH 2/2] drm/i915: Use intel_get_pipe_timings() and intel_mode_from_pipe_config() " ville.syrjala
@ 2017-09-25 14:18 ` Chris Wilson
1 sibling, 0 replies; 19+ messages in thread
From: Chris Wilson @ 2017-09-25 14:18 UTC (permalink / raw)
To: ville.syrjala, intel-gfx; +Cc: Rob Kramer, Daniel Vetter, dri-devel, stable
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()
2016-04-01 4:49 Troubleshooting LVDS on GM45 Rob Kramer
` (2 preceding siblings ...)
2016-04-01 15:37 ` [PATCH 1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get() ville.syrjala
@ 2016-04-01 16:44 ` Patchwork
2016-04-01 17:14 ` Ville Syrjälä
3 siblings, 1 reply; 19+ messages in thread
From: Patchwork @ 2016-04-01 16:44 UTC (permalink / raw)
To: ville.syrjala; +Cc: intel-gfx
== 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
^ permalink raw reply [flat|nested] 19+ messages in thread* Re: ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()
2016-04-01 16:44 ` ✗ Fi.CI.BAT: warning for series starting with [1/2] " Patchwork
@ 2016-04-01 17:14 ` Ville Syrjälä
0 siblings, 0 replies; 19+ messages in thread
From: Ville Syrjälä @ 2016-04-01 17:14 UTC (permalink / raw)
To: intel-gfx
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
^ permalink raw reply [flat|nested] 19+ messages in thread