Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/lspcon: Work around resume failure

[Saarinen, Jani]

> > == Summary ==
> >
> > Series 14280v1 drm/i915/lspcon: Work around resume failure
> > https://patchwork.freedesktop.org/api/1.0/series/14280/revisions/1/mb
> > ox/
> >
> > Test drv_module_reload_basic:
> > pass   -> DMESG-WARN (fi-skl-6700hq)
> 
> This one is a result of the previous CI run where LSPCON failed after S3. 
> After a
> warm-reboot LSPCON is still in a broken state, and even the initial LSPCON 
> probe
> will fail.
> 
> A power cycle between CI runs would prevent the above.
OK, thanks.

> 
> > Test gem_exec_suspend:
> > Subgroup basic-s3:
> > dmesg-warn -> PASS   (fi-skl-6700hq) Test
> > kms_pipe_crc_basic:
> > Subgroup suspend-read-crc-pipe-a:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > Subgroup suspend-read-crc-pipe-b:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> > Subgroup suspend-read-crc-pipe-c:
> > dmesg-warn -> PASS   (fi-skl-6700hq)
> >


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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

Re: [Intel-gfx] i915 4.8.3: cdclk < crtc_clock

[Daniel J Blueman]

On 24 October 2016 at 14:49, Tvrtko Ursulin
 wrote:
>
> Hi Daniel,
>
> On 24/10/2016 12:54, Daniel J Blueman wrote:
>>
>> Hi Tvrtko,
>>
>> I'm seeing this warning [1] on a Skylake Dell XPS 15 9550 with the
>> internal 3840x2160 panel with 4.8.4.
>>
>> Let me know if you're interested in any debug.
>
> I suggest best to add your logs to
> https://bugs.freedesktop.org/show_bug.cgi?id=98214 and go from there.
> Unfortunately I am not too knowledgable on the display side of things, just
> happened to add this warning since I was hitting it myself under some
> circumstances.

Good tip! I updated the bug report.

Thanks,
  Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/lspcon: Work around resume failure

[Saarinen, Jani]

> == Series Details ==
> 
> Series: drm/i915/lspcon: Work around resume failure
> URL   : https://patchwork.freedesktop.org/series/14280/
> State : warning
> 
> == Summary ==
> 
> Series 14280v1 drm/i915/lspcon: Work around resume failure
> https://patchwork.freedesktop.org/api/1.0/series/14280/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (fi-skl-6700hq)
[   27.826226] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[   27.826261] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B
[   27.846057] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS

> Test gem_exec_suspend:
> Subgroup basic-s3:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Subgroup suspend-read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Subgroup suspend-read-crc-pipe-c:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31
> fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35
> fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23
> fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /Patchwork_2801/
> 
> 102441087e47f4892b88c4f6e308e3edf89eeda1 drm-intel-nightly: 2016y-10m-
> 24d-14h-28m-17s UTC integration manifest eaa672c drm/i915/lspcon: Add
> workaround for resuming in PCON mode
> eb04604 drm/i915/lspcon: Get DDC adapter via container_of() instead of cached
> ptr 0ca993d drm/i915/dp: Read DP descriptor for eDP and LSPCON too
> 0144d102 drm/i915/lspcon: Fail LSPCON probe if the start of DPCD can't be read
> 7568e07 drm/i915/dp: Print full branch/sink descriptor
> 3b4f6e9 drm/i915/dp: Print only sink or branch specific OUI based on dev type
> b1439bc drm/i915/dp: Remove debug dependency of DPCD SW/HW revision
> read 2beca1a drm/dp: Factor out helper to distinguish between branch and sink
> devices


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation

[Saarinen, Jani]

> == Series Details ==
> 
> Series: drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation
> URL   : https://patchwork.freedesktop.org/series/14279/
> State : warning
> 
> == Summary ==
> 
> Series 14279v1 drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate
> computation
> https://patchwork.freedesktop.org/api/1.0/series/14279/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> SKIP   (fi-skl-6260u)
Out 
Reloading i915.ko with
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
module successfully unloaded
module successfully loaded again
Reloading i915.ko with inject_load_failure=1
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
Reloading i915.ko with inject_load_failure=2
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
Reloading i915.ko with inject_load_failure=3
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
Reloading i915.ko with inject_load_failure=4
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device
Reloading i915.ko with
unbinding /sys/class/vtconsole/vtcon1/: (M) frame buffer device

Err 
rmmod: ERROR: Module snd_hda_intel is in use
Module  Size  Used by
snd_hda_intel  30473  1

Audio team looking at this.

> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-a:
> pass   -> DMESG-WARN (fi-ilk-650)
https://bugs.freedesktop.org/show_bug.cgi?id=98251

> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31
> fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35
> fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:184  dwarn:1   dfail:0   fail:1   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-skl-6260u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23
> fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /Patchwork_2800/
> 
> 102441087e47f4892b88c4f6e308e3edf89eeda1 drm-intel-nightly: 2016y-10m-
> 24d-14h-28m-17s UTC integration manifest
> b8b2df0 drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate
> computation


Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

[Intel-gfx] ✗ Fi.CI.BAT: warning for DP audio fixes

[Patchwork]

== Series Details ==

Series: DP audio fixes
URL   : https://patchwork.freedesktop.org/series/14314/
State : warning

== Summary ==

Series 14314v1 DP audio fixes
https://patchwork.freedesktop.org/api/1.0/series/14314/revisions/1/mbox/

Test drv_module_reload_basic:
skip   -> PASS   (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> SKIP   (fi-ivb-3770)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-hsw-4770r)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-ilk-650)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
fail   -> PASS   (fi-ilk-650)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:0   skip:61 
fi-ivb-3520m total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-ivb-3770  total:246  pass:220  dwarn:0   dfail:0   fail:0   skip:26 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-snb-2600  total:246  pass:208  dwarn:0   dfail:0   fail:0   skip:38 

Results at /Patchwork_2803/

194359e4a31ff988c7a290093820c5ef28d3752b drm-intel-nightly: 
2016y-10m-24d-19h-42m-14s UTC integration manifest
538d5b1 drm/i915/dp: BDW cdclk fix for DP audio
04d3ec8 drm/i915/dp: Enable DP audio stall fix for gen9 platforms

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

[Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Enable DP audio stall fix for gen9 platforms

[Dhinakaran Pandiyan]

Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
let's set this bit right before enabling the audio codec. Playing audio
without setting this bit results in pipe FIFO underruns.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/i915_reg.h  |  5 +
 drivers/gpu/drm/i915/intel_ddi.c | 38 ++
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 3 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00efaa1..76dac48 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6236,6 +6236,11 @@ enum {
 #define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
 #define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
 
+#define _CHICKEN_TRANS_A   0x420C0
+#define _CHICKEN_TRANS_B   0x420C4
+#define CHICKEN_TRANS(tran) _MMIO_TRANS(tran, _CHICKEN_TRANS_A, 
_CHICKEN_TRANS_B)
+#define SPARE_13   (1<<13)
+
 /* WaCatErrorRejectionIssue */
 #define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG _MMIO(0x9030)
 #define  GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB  (1<<11)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fb18d69..84c91c1 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1858,6 +1858,38 @@ void intel_ddi_fdi_post_disable(struct intel_encoder 
*intel_encoder,
I915_WRITE(FDI_RX_CTL(PIPE_A), val);
 }
 
+void gen9_enable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config)
+{
+   struct drm_i915_private *dev_priv =
+   to_i915(pipe_config->base.crtc->dev);
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
+   uint32_t temp;
+
+   if (intel_crtc_has_dp_encoder(pipe_config) &&
+   pipe_config->port_clock >= 54000) {
+
+   temp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
+   temp |= SPARE_13;
+   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), temp);
+   }
+}
+
+void gen9_disable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config)
+{
+   struct drm_i915_private *dev_priv =
+   to_i915(pipe_config->base.crtc->dev);
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
+   uint32_t temp;
+
+   if (intel_crtc_has_dp_encoder(pipe_config) &&
+   pipe_config->port_clock >= 54000) {
+
+   temp = I915_READ(CHICKEN_TRANS(cpu_transcoder));
+   temp &= ~SPARE_13;
+   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), temp);
+   }
+}
+
 static void intel_enable_ddi(struct intel_encoder *intel_encoder,
 struct intel_crtc_state *pipe_config,
 struct drm_connector_state *conn_state)
@@ -1893,6 +1925,9 @@ static void intel_enable_ddi(struct intel_encoder 
*intel_encoder,
}
 
if (intel_crtc->config->has_audio) {
+   if (IS_GEN9(dev_priv))
+   gen9_enable_dp_audio_stall_fix(pipe_config);
+
intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO);
intel_audio_codec_enable(intel_encoder);
}
@@ -1912,6 +1947,9 @@ static void intel_disable_ddi(struct intel_encoder 
*intel_encoder,
if (intel_crtc->config->has_audio) {
intel_audio_codec_disable(intel_encoder);
intel_display_power_put(dev_priv, POWER_DOMAIN_AUDIO);
+
+   if (IS_GEN9(dev_priv))
+   gen9_disable_dp_audio_stall_fix(old_crtc_state);
}
 
if (type == INTEL_OUTPUT_EDP) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4e90b07..ef02c62 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1189,6 +1189,8 @@ unsigned int intel_fb_align_height(struct drm_device *dev,
   uint64_t fb_format_modifier);
 u32 intel_fb_stride_alignment(const struct drm_i915_private *dev_priv,
  uint64_t fb_modifier, uint32_t pixel_format);
+void gen9_enable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config);
+void gen9_disable_dp_audio_stall_fix(struct intel_crtc_state *pipe_config);
 
 /* intel_audio.c */
 void intel_init_audio_hooks(struct drm_i915_private *dev_priv);
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 2/2] drm/i915/dp: BDW cdclk fix for DP audio

[Dhinakaran Pandiyan]

According to BSpec, cdclk has to be not less than 432 MHz with DP audio
enabled, port width x4, and link rate HBR2 (5.4 GHz)

Having a lower cdclk triggers pipe underruns, which then lead to displays
continuously cycling off and on. This is essential for DP MST audio as the
link is trained at HBR2 and 4 lanes by default.

v2: Restrict fix to BDW
Retain the set cdclk across modesets (Ville)

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_display.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a94f7d1..8c59651 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10260,6 +10260,18 @@ static void bxt_modeset_commit_cdclk(struct 
drm_atomic_state *old_state)
bxt_set_cdclk(to_i915(dev), req_cdclk);
 }
 
+static unsigned int bdw_dp_audio_cdclk(struct intel_crtc_state *crtc_state)
+{
+
+   if (intel_crtc_has_dp_encoder(crtc_state) &&
+   crtc_state->has_audio &&
+   crtc_state->port_clock >= 54 &&
+   crtc_state->lane_count == 4)
+   return 432000;
+
+   return 0;
+}
+
 /* compute the max rate for new configuration */
 static int ilk_max_pixel_rate(struct drm_atomic_state *state)
 {
@@ -10275,7 +10287,7 @@ static int ilk_max_pixel_rate(struct drm_atomic_state 
*state)
   sizeof(intel_state->min_pixclk));
 
for_each_crtc_in_state(state, crtc, cstate, i) {
-   int pixel_rate;
+   unsigned int pixel_rate;
 
crtc_state = to_intel_crtc_state(cstate);
if (!crtc_state->base.enable) {
@@ -10285,9 +10297,19 @@ static int ilk_max_pixel_rate(struct drm_atomic_state 
*state)
 
pixel_rate = ilk_pipe_pixel_rate(crtc_state);
 
+   if (IS_BROADWELL(dev_priv)) {
/* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
-   if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
-   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
+   if (crtc_state->ips_enabled)
+   pixel_rate = DIV_ROUND_UP(pixel_rate * 100, 95);
+
+   /* BSpec says "Do not use DisplayPort with CDCLK less than
+* 432 MHz, audio enabled, port width x4, and link rate
+* HBR2 (5.4 GHz), or else there may be audio corruption or
+* screen corruption."
+*/
+   pixel_rate = max(pixel_rate,
+bdw_dp_audio_cdclk(crtc_state));
+   }
 
intel_state->min_pixclk[i] = pixel_rate;
}
-- 
2.7.4

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

[Intel-gfx] [PATCH v2 0/2] DP audio fixes

[Dhinakaran Pandiyan]

Playing audio over DP MST or just enabling it during boot caused underruns
on BDW and SKL. The underruns are followed by displays cycling on-off.
Debugging the underruns led to the understanding this was not a MST
specific issue but specific to the HBR2 configuration. There are two
solutions depending on the platform:

a) BDW - Increase the cdclk to at least 432 MHz in DP HBR2, x4 configs.
b) SKL, BXT and KBL - Enable DP stall fix (increasing the cdclk works
too).

I have tested this only on SKL and it would be great if somebody else can
share the results for other platforms.

Dhinakaran Pandiyan (2):
  drm/i915/dp: Enable DP audio stall fix for gen9 platforms
  drm/i915/dp: BDW cdclk fix for DP audio

 drivers/gpu/drm/i915/i915_reg.h  |  5 +
 drivers/gpu/drm/i915/intel_ddi.c | 38 
 drivers/gpu/drm/i915/intel_display.c | 28 +++---
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 4 files changed, 70 insertions(+), 3 deletions(-)

-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 0/2] drm/i915/gvt: fix compilation errors in gtt.c

[Zhenyu Wang]

On 2016.10.24 15:33:34 -0400, Jérémy Lefaure wrote:
> On Mon, 24 Oct 2016 10:36:58 +0800
> Zhenyu Wang  wrote:
> 
> > On 2016.10.20 18:05:56 -0400, Jérémy Lefaure wrote:
> > > This series fixes 2 compilations errors in gvt/gtt.c on 32-bits platform:
> > >  [PATCH 1/2] drm/i915/gvt: fix bad 32 bit shift in gtt
> > >  [PATCH 2/2] drm/i915/gvt: fix an error string format
> > > 
> > > The file gtt.c still does not compile because of shifting errors. Should 
> > > the 32
> > > bits architecture be supported ?  
> > 
> > Hi, we don't have 32bit platform support now, so will depend on 64bit 
> > kernel only.
> > 
> Ok, that was I thought. Do my patches are valid anyway ? At least the
> 1st ?
> 

yes, I'll pick up these although not enough for fixing 32bit compiling.

thanks

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/DMC/KBL: Load DMC on KBL using the no_stepping_info array

[Anusha Srivatsa]

Currently, for display there is only one DMC image for KBL.
Remove the stepping_info table for KBL and use the no_stepping_info
array for loading the firmware.

v2: Removed the block of code as pointed out by Rodrigo to make the
loads as generic as possible.

Cc: Rodrigo Vivi 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_csr.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 1ea0e1f..d7a04bc 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -168,12 +168,6 @@ struct stepping_info {
char substepping;
 };
 
-static const struct stepping_info kbl_stepping_info[] = {
-   {'A', '0'}, {'B', '0'}, {'C', '0'},
-   {'D', '0'}, {'E', '0'}, {'F', '0'},
-   {'G', '0'}, {'H', '0'}, {'I', '0'},
-};
-
 static const struct stepping_info skl_stepping_info[] = {
{'A', '0'}, {'B', '0'}, {'C', '0'},
{'D', '0'}, {'E', '0'}, {'F', '0'},
@@ -194,10 +188,7 @@ intel_get_stepping_info(struct drm_i915_private *dev_priv)
const struct stepping_info *si;
unsigned int size;
 
-   if (IS_KABYLAKE(dev_priv)) {
-   size = ARRAY_SIZE(kbl_stepping_info);
-   si = kbl_stepping_info;
-   } else if (IS_SKYLAKE(dev_priv)) {
+   if (IS_SKYLAKE(dev_priv)) {
size = ARRAY_SIZE(skl_stepping_info);
si = skl_stepping_info;
} else if (IS_BROXTON(dev_priv)) {
-- 
2.7.4

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

[Intel-gfx] linux-next: manual merge of the mali-dp tree with the drm-misc tree

[Stephen Rothwell]

Hi Liviu,

Today's linux-next merge of the mali-dp tree got a conflict in:

  drivers/gpu/drm/arm/malidp_planes.c

between commit:

  ea0e1ce20f73 ("drm/arm: Use per-plane rotation property")

from the drm-misc tree and commit:

  9ebb89762c30 ("drm: mali-dp: Refactor plane initialisation")

from the mali-dp tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/arm/malidp_planes.c
index abaca03b9d36,9020c0d8399c..
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@@ -254,23 -284,33 +284,30 @@@ int malidp_de_planes_init(struct drm_de
if (ret < 0)
goto cleanup;
  
+   drm_plane_helper_add(>base,
+_de_plane_helper_funcs);
+   plane->hwdev = malidp->dev;
+   plane->layer = >layers[i];
+ 
+   /* Skip the features which the SMART layer doesn't have */
+   if (id == DE_SMART)
+   continue;
+ 
 -  if (!drm->mode_config.rotation_property) {
 +  /* SMART layer can't be rotated */
 +  if (id != DE_SMART) {
unsigned long flags = DRM_ROTATE_0 |
  DRM_ROTATE_90 |
  DRM_ROTATE_180 |
  DRM_ROTATE_270 |
  DRM_REFLECT_X |
  DRM_REFLECT_Y;
 -  drm->mode_config.rotation_property =
 -  drm_mode_create_rotation_property(drm, flags);
 +  drm_plane_create_rotation_property(>base,
 + DRM_ROTATE_0,
 + flags);
}
  
-   drm_plane_helper_add(>base,
-_de_plane_helper_funcs);
-   plane->hwdev = malidp->dev;
-   plane->layer = >layers[i];
 -  if (drm->mode_config.rotation_property)
 -  drm_object_attach_property(>base.base,
 - 
drm->mode_config.rotation_property,
 - DRM_ROTATE_0);
 -
+   malidp_hw_write(malidp->dev, MALIDP_ALPHA_LUT,
+   plane->layer->base + MALIDP_LAYER_COMPOSE);
}
  
kfree(formats);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v7 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c

[Robert Bragg]

In particular this tries to capture for posterity some of the early
challenges we had with using the core perf infrastructure in case we
ever want to revisit adapting perf for device metrics.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_perf.c | 163 +++
 1 file changed, 163 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index e46cd36..501d20a 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -24,6 +24,169 @@
  *   Robert Bragg 
  */
 
+
+/**
+ * DOC: i915 Perf, streaming API for GPU metrics
+ *
+ * Gen graphics supports a large number of performance counters that can help
+ * driver and application developers understand and optimize their use of the
+ * GPU.
+ *
+ * This i915 perf interface enables userspace to configure and open a file
+ * descriptor representing a stream of GPU metrics which can then be read() as
+ * a stream of sample records.
+ *
+ * The interface is particularly suited to exposing buffered metrics that are
+ * captured by DMA from the GPU, unsynchronized with and unrelated to the CPU.
+ *
+ * Streams representing a single context are accessible to applications with a
+ * corresponding drm file descriptor, such that OpenGL can use the interface
+ * without special privileges. Access to system-wide metrics requires root
+ * privileges by default, unless changed via the dev.i915.perf_event_paranoid
+ * sysctl option.
+ *
+ *
+ * The interface was initially inspired by the core Perf infrastructure but
+ * some notable differences are:
+ *
+ * i915 perf file descriptors represent a "stream" instead of an "event"; where
+ * a perf event primarily corresponds to a single 64bit value, while a stream
+ * might sample sets of tightly-coupled counters, depending on the
+ * configuration.  For example the Gen OA unit isn't designed to support
+ * orthogonal configurations of individual counters; it's configured for a set
+ * of related counters. Samples for an i915 perf stream capturing OA metrics
+ * will include a set of counter values packed in a compact HW specific format.
+ * The OA unit supports a number of different packing formats which can be
+ * selected by the user opening the stream. Perf has support for grouping
+ * events, but each event in the group is configured, validated and
+ * authenticated individually with separate system calls.
+ *
+ * i915 perf stream configurations are provided as an array of u64 (key,value)
+ * pairs, instead of a fixed struct with multiple miscellaneous config members,
+ * interleaved with event-type specific members.
+ *
+ * i915 perf doesn't support exposing metrics via an mmap'd circular buffer.
+ * The supported metrics are being written to memory by the GPU unsynchronized
+ * with the CPU, using HW specific packing formats for counter sets. Sometimes
+ * the constraints on HW configuration require reports to be filtered before it
+ * would be acceptable to expose them to unprivileged applications - to hide
+ * the metrics of other processes/contexts. For these use cases a read() based
+ * interface is a good fit, and provides an opportunity to filter data as it
+ * gets copied from the GPU mapped buffers to userspace buffers.
+ *
+ *
+ * Some notes regarding Linux Perf:
+ * 
+ *
+ * The first prototype of this driver was based on the core perf
+ * infrastructure, and while we did make that mostly work, with some changes to
+ * perf, we found we were breaking or working around too many assumptions baked
+ * into perf's currently cpu centric design.
+ *
+ * In the end we didn't see a clear benefit to making perf's implementation and
+ * interface more complex by changing design assumptions while we knew we still
+ * wouldn't be able to use any existing perf based userspace tools.
+ *
+ * Also considering the Gen specific nature of the Observability hardware and
+ * how userspace will sometimes need to combine i915 perf OA metrics with
+ * side-band OA data captured via MI_REPORT_PERF_COUNT commands; we're
+ * expecting the interface to be used by a platform specific userspace such as
+ * OpenGL or tools. This is to say; we aren't inherently missing out on having
+ * a standard vendor/architecture agnostic interface by not using perf.
+ *
+ *
+ * For posterity, in case we might re-visit trying to adapt core perf to be
+ * better suited to exposing i915 metrics these were the main pain points we
+ * hit:
+ *
+ * - The perf based OA PMU driver broke some significant design assumptions:
+ *
+ *   Existing perf pmus are used for profiling work on a cpu and we were
+ *   introducing the idea of _IS_DEVICE pmus with different security
+ *   implications, the need to fake cpu-related data (such as user/kernel
+ *   registers) to fit with perf's current 

[Intel-gfx] [PATCH v7 10/11] drm/i915: Add more Haswell OA metric sets

[Robert Bragg]

This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.

The code is auto generated from an XML description of metric sets,
currently maintained in gputop, ref:

 https://github.com/rib/gputop
 > gputop-data/oa-*.xml
 > scripts/i915-perf-kernelgen.py

 $ make -C gputop-data -f Makefile.xml

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_oa_hsw.c | 559 -
 1 file changed, 558 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 19f272b..cd2a23a 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -31,9 +31,14 @@
 
 enum metric_set_id {
METRIC_SET_ID_RENDER_BASIC = 1,
+   METRIC_SET_ID_COMPUTE_BASIC,
+   METRIC_SET_ID_COMPUTE_EXTENDED,
+   METRIC_SET_ID_MEMORY_READS,
+   METRIC_SET_ID_MEMORY_WRITES,
+   METRIC_SET_ID_SAMPLER_BALANCE,
 };
 
-int i915_oa_n_builtin_metric_sets_hsw = 1;
+int i915_oa_n_builtin_metric_sets_hsw = 6;
 
 static const struct i915_oa_reg b_counter_config_render_basic[] = {
{ _MMIO(0x2724), 0x0080 },
@@ -112,6 +117,298 @@ get_render_basic_mux_config(struct drm_i915_private 
*dev_priv,
return mux_config_render_basic;
 }
 
+static const struct i915_oa_reg b_counter_config_compute_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 0x0080 },
+   { _MMIO(0x2718), 0x },
+   { _MMIO(0x271c), 0x },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2724), 0x0080 },
+   { _MMIO(0x2728), 0x },
+   { _MMIO(0x272c), 0x },
+   { _MMIO(0x2740), 0x },
+   { _MMIO(0x2744), 0x },
+   { _MMIO(0x2748), 0x },
+   { _MMIO(0x274c), 0x },
+   { _MMIO(0x2750), 0x },
+   { _MMIO(0x2754), 0x },
+   { _MMIO(0x2758), 0x },
+   { _MMIO(0x275c), 0x },
+   { _MMIO(0x236c), 0x },
+};
+
+static const struct i915_oa_reg mux_config_compute_basic[] = {
+   { _MMIO(0x253a4), 0x },
+   { _MMIO(0x2681c), 0x01f00800 },
+   { _MMIO(0x26820), 0x1000 },
+   { _MMIO(0x2781c), 0x01f00800 },
+   { _MMIO(0x26520), 0x0007 },
+   { _MMIO(0x265a0), 0x0007 },
+   { _MMIO(0x25380), 0x0010 },
+   { _MMIO(0x2538c), 0x0030 },
+   { _MMIO(0x25384), 0xaa8a },
+   { _MMIO(0x25404), 0x },
+   { _MMIO(0x26800), 0x4202 },
+   { _MMIO(0x26808), 0x00605817 },
+   { _MMIO(0x2680c), 0x10001005 },
+   { _MMIO(0x26804), 0x },
+   { _MMIO(0x27800), 0x0102 },
+   { _MMIO(0x27808), 0x0c0701e0 },
+   { _MMIO(0x2780c), 0x000200a0 },
+   { _MMIO(0x27804), 0x },
+   { _MMIO(0x26484), 0x4400 },
+   { _MMIO(0x26704), 0x4400 },
+   { _MMIO(0x26500), 0x0006 },
+   { _MMIO(0x26510), 0x0001 },
+   { _MMIO(0x26504), 0x8800 },
+   { _MMIO(0x26580), 0x0006 },
+   { _MMIO(0x26590), 0x0020 },
+   { _MMIO(0x26584), 0x },
+   { _MMIO(0x26104), 0x5582 },
+   { _MMIO(0x26184), 0xaa86 },
+   { _MMIO(0x25420), 0x08320c83 },
+   { _MMIO(0x25424), 0x06820c83 },
+   { _MMIO(0x2541c), 0x },
+   { _MMIO(0x25428), 0x0c03 },
+};
+
+static const struct i915_oa_reg *
+get_compute_basic_mux_config(struct drm_i915_private *dev_priv,
+int *len)
+{
+   *len = ARRAY_SIZE(mux_config_compute_basic);
+   return mux_config_compute_basic;
+}
+
+static const struct i915_oa_reg b_counter_config_compute_extended[] = {
+   { _MMIO(0x2724), 0xf080 },
+   { _MMIO(0x2720), 0x },
+   { _MMIO(0x2714), 0xf080 },
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2770), 0x0007fe2a },
+   { _MMIO(0x2774), 0xff00 },
+   { _MMIO(0x2778), 0x0007fe6a },
+   { _MMIO(0x277c), 0xff00 },
+   { _MMIO(0x2780), 0x0007fe92 },
+   { _MMIO(0x2784), 0xff00 },
+   { _MMIO(0x2788), 0x0007fea2 },
+   { _MMIO(0x278c), 0xff00 },
+   { _MMIO(0x2790), 0x0007fe32 },
+   { _MMIO(0x2794), 0xff00 },
+   { _MMIO(0x2798), 0x0007fe9a },
+   { _MMIO(0x279c), 0xff00 },
+   { _MMIO(0x27a0), 0x0007ff23 },
+   { _MMIO(0x27a4), 0xff00 },
+   { _MMIO(0x27a8), 0x0007fff3 },
+   { _MMIO(0x27ac), 0xfffe },
+};
+
+static const struct i915_oa_reg mux_config_compute_extended[] = {
+   { _MMIO(0x2681c), 0x3eb00800 },
+   { _MMIO(0x26820), 0x0090 },
+   { _MMIO(0x25384), 0x02aa },
+   { _MMIO(0x25404), 0x03ff },
+   { _MMIO(0x26800), 0x00142284 },
+   { _MMIO(0x26808), 0x0e629062 },
+   { _MMIO(0x2680c), 0x3f6f55cb },
+   { _MMIO(0x26810), 0x0014 },
+   { 

[Intel-gfx] [PATCH v7 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.

v2:
   Make sure to initialize ->specific_ctx_id when opening, without
   relying on _pin_notify hook, in case ctx already pinned.
v3:
   Revert back to pinning ctx upfront when opening stream, removing
   need to hook in to pinning and to update OACONTROL on the fly.

Cc: Chris Wilson 
Signed-off-by: Robert Bragg 
Signed-off-by: Zhenyu Wang 

fix enable hsw
---
 drivers/gpu/drm/i915/i915_drv.h  |   65 ++-
 drivers/gpu/drm/i915/i915_perf.c | 1000 +-
 drivers/gpu/drm/i915/i915_reg.h  |  338 +
 include/uapi/drm/i915_drm.h  |   70 ++-
 4 files changed, 1444 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3448d05..ea24814 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1764,6 +1764,11 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_oa_format {
+   u32 format;
+   int size;
+};
+
 struct i915_oa_reg {
i915_reg_t addr;
u32 value;
@@ -1784,11 +1789,6 @@ struct i915_perf_stream_ops {
 */
void (*disable)(struct i915_perf_stream *stream);
 
-   /* Return: true if any i915 perf records are ready to read()
-* for this stream.
-*/
-   bool (*can_read)(struct i915_perf_stream *stream);
-
/* Call poll_wait, passing a wait queue that will be woken
 * once there is something ready to read() for the stream
 */
@@ -1798,9 +1798,7 @@ struct i915_perf_stream_ops {
 
/* For handling a blocking read, wait until there is something
 * to ready to read() for the stream. E.g. wait on the same
-* wait queue that would be passed to poll_wait() until
-* ->can_read() returns true (if its safe to call ->can_read()
-* without the i915 perf lock held).
+* wait queue that would be passed to poll_wait().
 */
int (*wait_unlocked)(struct i915_perf_stream *stream);
 
@@ -1840,11 +1838,28 @@ struct i915_perf_stream {
struct list_head link;
 
u32 sample_flags;
+   int sample_size;
 
struct i915_gem_context *ctx;
bool enabled;
 
-   struct i915_perf_stream_ops *ops;
+   const struct i915_perf_stream_ops *ops;
+};
+
+struct i915_oa_ops {
+   void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
+   int (*enable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*disable_metric_set)(struct drm_i915_private *dev_priv);
+   void (*oa_enable)(struct drm_i915_private *dev_priv);
+   void (*oa_disable)(struct drm_i915_private *dev_priv);
+   void (*update_oacontrol)(struct drm_i915_private *dev_priv);
+   void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv,
+   u32 ctx_id);
+   int (*read)(struct i915_perf_stream *stream,
+   char __user *buf,
+   size_t count,
+   size_t *offset);
+   bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv);
 };
 
 struct drm_i915_private {
@@ -2149,16 +2164,46 @@ struct drm_i915_private {
 
struct {
bool initialized;
+
struct mutex lock;
struct list_head streams;
 
+   spinlock_t hook_lock;
+
struct {
-   u32 metrics_set;
+   struct i915_perf_stream *exclusive_stream;
+
+   u32 specific_ctx_id;
+
+   struct hrtimer poll_check_timer;
+   wait_queue_head_t poll_wq;
+   atomic_t pollin;
+
+   bool periodic;
+   int period_exponent;
+   int timestamp_frequency;
+
+   int tail_margin;
+
+   int metrics_set;
 
const struct i915_oa_reg *mux_regs;
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+
+   struct {
+   struct i915_vma *vma;
+   u8 *vaddr;
+   int format;
+   int format_size;
+   } oa_buffer;
+
+   u32 gen7_latched_oastatus1;
+
+   struct i915_oa_ops ops;
+   const struct i915_oa_format *oa_formats;
+   int n_builtin_sets;
} oa;
} perf;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c 

[Intel-gfx] [PATCH v7 09/11] drm/i915: add oa_event_min_timer_exponent sysctl

[Robert Bragg]

The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.

Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_perf.c | 41 
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index ab4c171..e46cd36 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -82,6 +82,22 @@ static u32 i915_perf_stream_paranoid = true;
 #define INVALID_CTX_ID 0x
 
 
+/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */
+static int oa_exponent_max = OA_EXPONENT_MAX;
+
+/* Theoretically we can program the OA unit to sample every 160ns but don't
+ * allow that by default unless root...
+ *
+ * The period is derived from the exponent as:
+ *
+ *   period = 80ns * 2^(exponent + 1)
+ *
+ * Referring to perf's kernel.perf_event_max_sample_rate for a precedent
+ * (10 by default); with an OA exponent of 6 we get a period of 10.240
+ * microseconds - just under 10Hz
+ */
+static u32 i915_oa_min_timer_exponent = 6;
+
 /* XXX: beware if future OA HW adds new report formats that the current
  * code assumes all reports have a power-of-two size and ~(size - 1) can
  * be used as a mask to align the OA tail pointer.
@@ -1317,21 +1333,13 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
return -EINVAL;
}
 
-   /* NB: The exponent represents a period as follows:
-*
-*   80ns * 2^(period_exponent + 1)
-*
-* Theoretically we can program the OA unit to sample
+   /* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* Referring to perf's
-* kernel.perf_event_max_sample_rate for a precedent
-* (10 by default); with an OA exponent of 6 we get
-* a period of 10.240 microseconds -just under 10Hz
 */
-   if (value < 6 && !capable(CAP_SYS_ADMIN)) {
-   DRM_ERROR("Sampling period too high without 
root privileges\n");
+   if (value < i915_oa_min_timer_exponent &&
+   !capable(CAP_SYS_ADMIN)) {
+   DRM_ERROR("OA timer exponent too low without 
root privileges\n");
return -EACCES;
}
 
@@ -1439,6 +1447,15 @@ static struct ctl_table oa_table[] = {
 .extra1 = ,
 .extra2 = ,
 },
+   {
+.procname = "oa_min_timer_exponent",
+.data = _oa_min_timer_exponent,
+.maxlen = sizeof(i915_oa_min_timer_exponent),
+.mode = 0644,
+.proc_handler = proc_dointvec_minmax,
+.extra1 = ,
+.extra2 = _exponent_max,
+},
{}
 };
 
-- 
2.10.1

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

[Intel-gfx] [PATCH v7 08/11] drm/i915: Add dev.i915.perf_stream_paranoid sysctl option

[Robert Bragg]

Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c | 50 +++-
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a968212..7010c6e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2166,6 +2166,7 @@ struct drm_i915_private {
bool initialized;
 
struct kobject *metrics_kobj;
+   struct ctl_table_header *sysctl_header;
 
struct mutex lock;
struct list_head streams;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index aedefbc..ab4c171 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -64,6 +64,11 @@
 #define POLL_FREQUENCY 200
 #define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY)
 
+/* for sysctl proc_dointvec_minmax of dev.i915.perf_stream_paranoid */
+static int zero;
+static int one = 1;
+static u32 i915_perf_stream_paranoid = true;
+
 /* The maximum exponent the hardware accepts is 63 (essentially it selects one
  * of the 64bit timestamp bits to trigger reports from) but there's currently
  * no known use case for sampling as infrequently as once per 47 thousand 
years.
@@ -1174,7 +1179,13 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
}
}
 
-   if (!specific_ctx && !capable(CAP_SYS_ADMIN)) {
+   /* Similar to perf's kernel.perf_paranoid_cpu sysctl option
+* we check a dev.i915.perf_stream_paranoid sysctl option
+* to determine if it's ok to access system wide OA counters
+* without CAP_SYS_ADMIN privileges.
+*/
+   if (!specific_ctx &&
+   i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) {
DRM_ERROR("Insufficient privileges to open system-wide i915 
perf stream\n");
ret = -EACCES;
goto err_ctx;
@@ -1418,6 +1429,39 @@ void i915_perf_unregister(struct drm_i915_private 
*dev_priv)
dev_priv->perf.metrics_kobj = NULL;
 }
 
+static struct ctl_table oa_table[] = {
+   {
+.procname = "perf_stream_paranoid",
+.data = _perf_stream_paranoid,
+.maxlen = sizeof(i915_perf_stream_paranoid),
+.mode = 0644,
+.proc_handler = proc_dointvec_minmax,
+.extra1 = ,
+.extra2 = ,
+},
+   {}
+};
+
+static struct ctl_table i915_root[] = {
+   {
+.procname = "i915",
+.maxlen = 0,
+.mode = 0555,
+.child = oa_table,
+},
+   {}
+};
+
+static struct ctl_table dev_root[] = {
+   {
+.procname = "dev",
+.maxlen = 0,
+.mode = 0555,
+.child = i915_root,
+},
+   {}
+};
+
 void i915_perf_init(struct drm_i915_private *dev_priv)
 {
if (!IS_HASWELL(dev_priv))
@@ -1448,6 +1492,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_hsw;
 
+   dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
+
dev_priv->perf.initialized = true;
 }
 
@@ -1456,6 +1502,8 @@ void i915_perf_fini(struct drm_i915_private *dev_priv)
if (!dev_priv->perf.initialized)
return;
 
+   unregister_sysctl_table(dev_priv->perf.sysctl_header);
+
memset(_priv->perf.oa.ops, 0, sizeof(dev_priv->perf.oa.ops));
dev_priv->perf.initialized = false;
 }
-- 
2.10.1

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

[Intel-gfx] [PATCH v7 02/11] drm/i915: rename OACONTROL GEN7_OACONTROL

[Robert Bragg]

OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/gvt/handlers.c| 2 +-
 drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
 drivers/gpu/drm/i915/i915_reg.h| 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index 3e74fb3..68e07a1 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -2159,7 +2159,7 @@ static int init_generic_mmio_info(struct intel_gvt *gvt)
MMIO_DFH(0x1217c, D_ALL, F_CMD_ACCESS, NULL, NULL);
 
MMIO_F(0x2290, 8, 0, 0, 0, D_HSW_PLUS, NULL, NULL);
-   MMIO_D(OACONTROL, D_HSW);
+   MMIO_D(GEN7_OACONTROL, D_HSW);
MMIO_D(0x2b00, D_BDW_PLUS);
MMIO_D(0x2360, D_BDW_PLUS);
MMIO_F(0x5200, 32, 0, 0, 0, D_ALL, NULL, NULL);
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index f191d7b..fe34470 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -450,7 +450,7 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(OACONTROL), /* Only allowed for LRI and SRM. See below. */
+   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1108,7 +1108,7 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
 * to the register. Hence, limit OACONTROL writes to
 * only MI_LOAD_REGISTER_IMM commands.
 */
-   if (reg_addr == i915_mmio_reg_offset(OACONTROL)) {
+   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
return false;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a9be3f0..070d3297 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -615,7 +615,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define HSW_CS_GPR(n)   _MMIO(0x2600 + (n) * 8)
 #define HSW_CS_GPR_UDW(n)   _MMIO(0x2600 + (n) * 8 + 4)
 
-#define OACONTROL _MMIO(0x2360)
+#define GEN7_OACONTROL _MMIO(0x2360)
 
 #define _GEN7_PIPEA_DE_LOAD_SL 0x70068
 #define _GEN7_PIPEB_DE_LOAD_SL 0x71068
-- 
2.10.1

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

[Intel-gfx] [PATCH v7 01/11] drm/i915: Add i915 perf infrastructure

[Robert Bragg]

Adds base i915 perf infrastructure for Gen performance metrics.

This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl() to enable or disable capture and poll() to wait for
data.

A stream is opened something like:

  uint64_t properties[] = {
  /* Single context sampling */
  DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,

  /* Include OA reports in samples */
  DRM_I915_PERF_PROP_SAMPLE_OA, true,

  /* OA unit configuration */
  DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
  DRM_I915_PERF_PROP_OA_FORMAT, report_format,
  DRM_I915_PERF_PROP_OA_EXPONENT,   period_exponent,
   };
   struct drm_i915_perf_open_param parm = {
  .flags = I915_PERF_FLAG_FD_CLOEXEC |
   I915_PERF_FLAG_FD_NONBLOCK |
   I915_PERF_FLAG_DISABLED,
  .properties_ptr = (uint64_t)properties,
  .num_properties = sizeof(properties) / 16,
   };
   int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, );

Records read all start with a common { type, size } header with
DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
contain an extensible number of fields and it's the
DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
determine what's included in every sample.

No specific streams are supported yet so any attempt to open a stream
will return an error.

v4:
s/DRM_IORW/DRM_IOW/ - Emil Velikov
v3:
update read() interface to avoid passing state struct - Chris Wilson
fix some rebase fallout, with i915-perf init/deinit
v2:
use i915_gem_context_get() - Chris Wilson

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/Makefile|   3 +
 drivers/gpu/drm/i915/i915_drv.c  |   4 +
 drivers/gpu/drm/i915/i915_drv.h  |  91 
 drivers/gpu/drm/i915/i915_perf.c | 443 +++
 include/uapi/drm/i915_drm.h  |  67 ++
 5 files changed, 608 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/i915_perf.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 6123400..8d4e25f 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -113,6 +113,9 @@ i915-$(CONFIG_DRM_I915_CAPTURE_ERROR) += i915_gpu_error.o
 # virtual gpu code
 i915-y += i915_vgpu.o
 
+# perf code
+i915-y += i915_perf.o
+
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
 include $(src)/gvt/Makefile
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 99e4e04..e99d14e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -836,6 +836,8 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
intel_detect_preproduction_hw(dev_priv);
 
+   i915_perf_init(dev_priv);
+
return 0;
 
 err_workqueues:
@@ -849,6 +851,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
  */
 static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
 {
+   i915_perf_fini(dev_priv);
i915_gem_load_cleanup(_priv->drm);
i915_workqueues_cleanup(dev_priv);
 }
@@ -2554,6 +2557,7 @@ static const struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, 
DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, 
i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, 
i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, 
DRM_RENDER_ALLOW),
 };
 
 static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dd3acab..fcc5958 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1764,6 +1764,84 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct i915_perf_stream;
+
+struct i915_perf_stream_ops {
+   /* Enables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_ENABLE or implicitly called when stream is
+* opened without I915_PERF_FLAG_DISABLED.
+*/
+   void (*enable)(struct i915_perf_stream *stream);
+
+   /* Disables the collection of HW samples, either in response to
+* I915_PERF_IOCTL_DISABLE or implicitly called before
+* destroying the stream.
+*/
+   void (*disable)(struct i915_perf_stream *stream);
+
+   /* Return: true if any i915 perf records are ready to read()
+* for this stream.
+*/
+   bool (*can_read)(struct i915_perf_stream *stream);
+
+   /* Call poll_wait, passing a wait queue that will be woken
+* once there is something ready to read() for the stream
+*/
+   void (*poll_wait)(struct i915_perf_stream 

[Intel-gfx] [PATCH v7 07/11] drm/i915: advertise available metrics via sysfs

[Robert Bragg]

Each metric set is given a sysfs entry like:

/sys/class/drm/card0/metrics//id

This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN. The  is a globally unique ID for a
specific OA unit register configuration that can be reliably used by
userspace as a key to lookup corresponding counter meta data and
normalization equations.

The guid registry is currently maintained as part of gputop along with
the XML metric set descriptions and code generation scripts, ref:

 https://github.com/rib/gputop
 > gputop-data/guids.xml
 > scripts/update-guids.py
 > gputop-data/oa-*.xml
 > scripts/i915-perf-kernelgen.py

 $ make -C gputop-data -f Makefile.xml SYSFS=1 WHITELIST=RenderBasic

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c|  5 
 drivers/gpu/drm/i915/i915_drv.h|  4 +++
 drivers/gpu/drm/i915/i915_oa_hsw.c | 51 +
 drivers/gpu/drm/i915/i915_oa_hsw.h |  4 +++
 drivers/gpu/drm/i915/i915_perf.c   | 52 ++
 5 files changed, 116 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e99d14e..b887051 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1115,6 +1115,9 @@ static void i915_driver_register(struct drm_i915_private 
*dev_priv)
if (drm_dev_register(dev, 0) == 0) {
i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
+
+   /* Depends on sysfs having been initialized */
+   i915_perf_register(dev_priv);
} else
DRM_ERROR("Failed to register driver for userspace access!\n");
 
@@ -1151,6 +1154,8 @@ static void i915_driver_unregister(struct 
drm_i915_private *dev_priv)
acpi_video_unregister();
intel_opregion_unregister(dev_priv);
 
+   i915_perf_unregister(dev_priv);
+
i915_teardown_sysfs(dev_priv);
i915_debugfs_unregister(dev_priv);
drm_dev_unregister(_priv->drm);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea24814..a968212 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2165,6 +2165,8 @@ struct drm_i915_private {
struct {
bool initialized;
 
+   struct kobject *metrics_kobj;
+
struct mutex lock;
struct list_head streams;
 
@@ -3748,6 +3750,8 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
 /* i915_perf.c */
 extern void i915_perf_init(struct drm_i915_private *dev_priv);
 extern void i915_perf_fini(struct drm_i915_private *dev_priv);
+extern void i915_perf_register(struct drm_i915_private *dev_priv);
+extern void i915_perf_unregister(struct drm_i915_private *dev_priv);
 
 /* i915_suspend.c */
 extern int i915_save_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 8906380..19f272b 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -24,6 +24,8 @@
  *
  */
 
+#include 
+
 #include "i915_drv.h"
 #include "i915_oa_hsw.h"
 
@@ -142,3 +144,52 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
return -ENODEV;
}
 }
+
+static ssize_t
+show_render_basic_id(struct device *kdev, struct device_attribute *attr, char 
*buf)
+{
+   return sprintf(buf, "%d\n", METRIC_SET_ID_RENDER_BASIC);
+}
+
+static struct device_attribute dev_attr_render_basic_id = {
+   .attr = { .name = "id", .mode = S_IRUGO },
+   .show = show_render_basic_id,
+   .store = NULL,
+};
+
+static struct attribute *attrs_render_basic[] = {
+   _attr_render_basic_id.attr,
+   NULL,
+};
+
+static struct attribute_group group_render_basic = {
+   .name = "403d8832-1a27-4aa6-a64e-f5389ce7b212",
+   .attrs =  attrs_render_basic,
+};
+
+int
+i915_perf_register_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int mux_len;
+   int ret = 0;
+
+   if (get_render_basic_mux_config(dev_priv, _len)) {
+   ret = sysfs_create_group(dev_priv->perf.metrics_kobj, 
_render_basic);
+   if (ret)
+   goto error_render_basic;
+   }
+
+   return 0;
+
+error_render_basic:
+   return ret;
+}
+
+void
+i915_perf_unregister_sysfs_hsw(struct drm_i915_private *dev_priv)
+{
+   int mux_len;
+
+   if (get_render_basic_mux_config(dev_priv, _len))
+   sysfs_remove_group(dev_priv->perf.metrics_kobj, 
_render_basic);
+}
diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.h 
b/drivers/gpu/drm/i915/i915_oa_hsw.h
index b618a1f..429a229 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.h
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.h

[Intel-gfx] [PATCH v7 04/11] drm/i915: don't whitelist oacontrol in cmd parser

[Robert Bragg]

Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL via a batch buffer isn't able to report useable
data without a more complete OA unit configuration. Mesa handles the
possibility that writes to OACONTROL may not be allowed and so only
advertises the extension after explicitly testing that a write to
OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist
should be ok for userspace.

Removing this simplifies adding a new kernel api for configuring the OA
unit without needing to consider the possibility that userspace might
trample on OACONTROL state which we'd like to start managing within
the kernel instead. In particular running any Mesa based GL application
currently results in clearing OACONTROL when initializing which would
disable the capturing of metrics.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 38 ++
 1 file changed, 2 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index c45dd83..5152d6f 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -450,7 +450,6 @@ static const struct drm_i915_reg_descriptor 
gen7_render_regs[] = {
REG64(PS_INVOCATION_COUNT),
REG64(PS_DEPTH_COUNT),
REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE),
-   REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */
REG64(MI_PREDICATE_SRC0),
REG64(MI_PREDICATE_SRC1),
REG32(GEN7_3DPRIM_END_OFFSET),
@@ -1060,8 +1059,7 @@ bool intel_engine_needs_cmd_parser(struct intel_engine_cs 
*engine)
 static bool check_cmd(const struct intel_engine_cs *engine,
  const struct drm_i915_cmd_descriptor *desc,
  const u32 *cmd, u32 length,
- const bool is_master,
- bool *oacontrol_set)
+ const bool is_master)
 {
if (desc->flags & CMD_DESC_SKIP)
return true;
@@ -1099,31 +1097,6 @@ static bool check_cmd(const struct intel_engine_cs 
*engine,
}
 
/*
-* OACONTROL requires some special handling for
-* writes. We want to make sure that any batch which
-* enables OA also disables it before the end of the
-* batch. The goal is to prevent one process from
-* snooping on the perf data from another process. To do
-* that, we need to check the value that will be written
-* to the register. Hence, limit OACONTROL writes to
-* only MI_LOAD_REGISTER_IMM commands.
-*/
-   if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) {
-   if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRM to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_REG) {
-   DRM_DEBUG_DRIVER("CMD: Rejected LRR to 
OACONTROL\n");
-   return false;
-   }
-
-   if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1))
-   *oacontrol_set = (cmd[offset + 1] != 0);
-   }
-
-   /*
 * Check the value written to the register against the
 * allowed mask/value pair given in the whitelist entry.
 */
@@ -1214,7 +1187,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
u32 *cmd, *batch_end;
struct drm_i915_cmd_descriptor default_desc = noop_desc;
const struct drm_i915_cmd_descriptor *desc = _desc;
-   bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */
bool needs_clflush_after = false;
int ret = 0;
 
@@ -1270,8 +1242,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
break;
}
 
-   if (!check_cmd(engine, desc, cmd, length, is_master,
-  _set)) {
+   if (!check_cmd(engine, desc, cmd, length, is_master)) {
ret = -EACCES;
break;
}
@@ -1279,11 +1250,6 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
cmd += length;
}
 
- 

[Intel-gfx] [PATCH v7 03/11] drm/i915: return EACCES for check_cmd() failures

[Robert Bragg]

check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.

The distinction makes the difference between allowing the buffer to be
executed as an unprivileged batch buffer or returning an EINVAL error to
userspace without executing anything.

In a case where userspace may want to test whether it can successfully
write to a register that needs privileges the distinction may be
important and an EINVAL error may be considered fatal.

In particular this is currently true for Mesa, which includes a test for
whether OACONTROL can be written too, but Mesa treats any error when
flushing a batch buffer as fatal, calling exit(1).

As it is currently Mesa can gracefully handle a failure to write to
OACONTROL if the command parser is disabled, but if we were to remove
OACONTROL from the parser's whitelist then the returned EINVAL would
break Mesa applications as they attempt an OACONTROL write.

This bumps the command parser version from 7 to 8, as the change is
visible to userspace.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_cmd_parser.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c 
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index fe34470..c45dd83 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1272,7 +1272,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs 
*engine,
 
if (!check_cmd(engine, desc, cmd, length, is_master,
   _set)) {
-   ret = -EINVAL;
+   ret = -EACCES;
break;
}
 
@@ -1333,6 +1333,9 @@ int i915_cmd_parser_get_version(struct drm_i915_private 
*dev_priv)
 * 5. GPGPU dispatch compute indirect registers.
 * 6. TIMESTAMP register and Haswell CS GPR registers
 * 7. Allow MI_LOAD_REGISTER_REG between whitelisted registers.
+* 8. Don't report cmd_check() failures as EINVAL errors to userspace;
+*rely on the HW to NOOP disallowed commands as it would without
+*the parser enabled.
 */
-   return 7;
+   return 8;
 }
-- 
2.10.1

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

Re: [Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

[Carlos Santa]

On Mon, 2016-10-03 at 11:42 -0700, Anusha Srivatsa wrote:
> From: Peter Antoine 
> 
> HuC firmware css header has almost exactly same definition as GuC
> firmware except for the sw_version. Also, add a new member fw_type
> into intel_uc_fw to indicate what kind of fw it is. So, the loader
> will pull right sw_version from header.
> 
> v2: rebased on-top of drm-intel-nightly
> v3: rebased on-top of drm-intel-nightly (again).
> v4: rebased + spaces.
> v7: rebased.
> v8: rebased.
> 
> Tested-by: Xiang Haihao 
> Signed-off-by: Anusha Srivatsa 
> Signed-off-by: Alex Dai 
> Signed-off-by: Peter Antoine 
> Reviewed-by: Dave Gordon 
> ---
>  drivers/gpu/drm/i915/intel_guc.h|  4 
>  drivers/gpu/drm/i915/intel_guc_fwif.h   | 16 ++---
>  drivers/gpu/drm/i915/intel_guc_loader.c | 41 ++-
> --
>  3 files changed, 45 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc.h
> b/drivers/gpu/drm/i915/intel_guc.h
> index b134a41..812e4ca 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -98,6 +98,9 @@ enum intel_uc_fw_status {
>   UC_FIRMWARE_SUCCESS
>  };
>  
> +#define UC_FW_TYPE_GUC   0
> +#define UC_FW_TYPE_HUC   1
> +

This can be changed to an enum as suggested earlier by Rodrigo.

>  /*
>   * This structure encapsulates all the data needed during the
> process
>   * of fetching, caching, and loading the firmware image into the
> GuC.
> @@ -115,6 +118,7 @@ struct intel_uc_fw {
>   uint16_t major_ver_found;
>   uint16_t minor_ver_found;
> 
> + uint32_t fw_type;

Maybe a comment can be added to this variable to explicitly describe
what it is ("GuC/HuC FW")?

Carlos

>   uint32_t header_size;
>   uint32_t header_offset;
>   uint32_t rsa_size;
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
> b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index e40db2d..b38b6b4 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -154,7 +154,7 @@
>   * The GuC firmware layout looks like this:
>   *
>   * +---+
> - * |guc_css_header |
> + * | uc_css_header |
>   * |   |
>   * | contains major/minor version  |
>   * +---+
> @@ -181,9 +181,16 @@
>   * 3. Length info of each component can be found in header, in
> dwords.
>   * 4. Modulus and exponent key are not required by driver. They may
> not appear
>   *in fw. So driver will load a truncated firmware in this case.
> + *
> + * HuC firmware layout is same as GuC firmware.
> + *
> + * HuC firmware css header is different. However, the only
> difference is where
> + * the version information is saved. The uc_css_header is unified to
> support
> + * both. Driver should get HuC version from
> uc_css_header.huc_sw_version, while
> + * uc_css_header.guc_sw_version for GuC.
>   */
>  
> -struct guc_css_header {
> +struct uc_css_header {
>   uint32_t module_type;
>   /* header_size includes all non-uCode bits, including
> css_header, rsa
>    * key, modulus key and exponent data. */
> @@ -214,7 +221,10 @@ struct guc_css_header {
>  
>   char username[8];
>   char buildnumber[12];
> - uint32_t device_id;
> + union {
> + uint32_t device_id;
> + uint32_t huc_sw_version;
> + };
>   uint32_t guc_sw_version;
>   uint32_t prod_preprod_fw;
>   uint32_t reserved[12];
> diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
> b/drivers/gpu/drm/i915/intel_guc_loader.c
> index 493295d..0b863a1 100644
> --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> @@ -586,7 +586,7 @@ void intel_uc_fw_fetch(struct drm_device *dev,
> struct intel_uc_fw *uc_fw)
>   struct pci_dev *pdev = dev->pdev;
>   struct drm_i915_gem_object *obj;
>   const struct firmware *fw;
> - struct guc_css_header *css;
> + struct uc_css_header *css;
>   size_t size;
>   int err;
>  
> @@ -603,19 +603,19 @@ void intel_uc_fw_fetch(struct drm_device *dev,
> struct intel_uc_fw *uc_fw)
>   uc_fw->uc_fw_path, fw);
>  
>   /* Check the size of the blob before examining buffer
> contents */
> - if (fw->size < sizeof(struct guc_css_header)) {
> + if (fw->size < sizeof(struct uc_css_header)) {
>   DRM_NOTE("Firmware header is missing\n");
>   goto fail;
>   }
>  
> - css = (struct guc_css_header *)fw->data;
> + css = (struct uc_css_header *)fw->data;
>  
>   /* Firmware bits always start from header */
>   uc_fw->header_offset = 0;
>   uc_fw->header_size = (css->header_size_dw - css-
> >modulus_size_dw -
>   css->key_size_dw - 

Re: [Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

[Carlos Santa]

On Thu, 2016-10-13 at 13:54 -0700, Jeff McGee wrote:
> On Thu, Oct 13, 2016 at 10:42:42AM -0700, Jeff McGee wrote:
> > 
> > On Mon, Oct 03, 2016 at 11:42:57AM -0700, Anusha Srivatsa wrote:
> > > 
> > > From: Peter Antoine 
> > > 
> > > The HuC loading process is similar to GuC. The
> > > intel_uc_fw_fetch()
> > > is used for both cases.
> > > 
> > > HuC loading needs to be before GuC loading. The WOPCM setting
> > > must
> > > be done early before loading any of them.
> > > 
> > > v2: rebased on-top of drm-intel-nightly.
> > > removed if(HAS_GUC()) before the guc call. (D.Gordon)
> > > update huc_version number of format.
> > > v3: rebased to drm-intel-nightly, changed the file name format to
> > > match the one in the huc package.
> > > Changed dev->dev_private to to_i915()
> > > v4: moved function back to where it was.
> > > change wait_for_atomic to wait_for.
> > > v5: rebased + comment changes.
> > > v7: rebased.
> > > v8: rebased.
> > > 
> > > Tested-by: Xiang Haihao 
> > > Signed-off-by: Anusha Srivatsa 
> > > Signed-off-by: Alex Dai 
> > > Signed-off-by: Peter Antoine 
> > > Reviewed-by: Dave Gordon 
> > > ---
> > >  drivers/gpu/drm/i915/Makefile   |   1 +
> > >  drivers/gpu/drm/i915/i915_drv.c |   3 +
> > >  drivers/gpu/drm/i915/i915_drv.h |   3 +
> > >  drivers/gpu/drm/i915/i915_guc_reg.h |   3 +
> > >  drivers/gpu/drm/i915/intel_guc.h|   1 +
> > >  drivers/gpu/drm/i915/intel_guc_loader.c |   6 +-
> > >  drivers/gpu/drm/i915/intel_huc.h|  44 ++
> > >  drivers/gpu/drm/i915/intel_huc_loader.c | 268
> > > 
> > >  8 files changed, 327 insertions(+), 2 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/i915/intel_huc.h
> > >  create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c
> > > 
> > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > b/drivers/gpu/drm/i915/Makefile
> > > index e6fe004..6e99c51 100644
> > > --- a/drivers/gpu/drm/i915/Makefile
> > > +++ b/drivers/gpu/drm/i915/Makefile
> > > @@ -53,6 +53,7 @@ i915-y += i915_cmd_parser.o \
> > >  
> > >  # general-purpose microcontroller (GuC) support
> > >  i915-y += intel_guc_loader.o \
> > > +   intel_huc_loader.o \
> > >     i915_guc_submission.o
> > >  
> > >  # autogenerated null render state
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > > b/drivers/gpu/drm/i915/i915_drv.c
> > > index 31b2b63..7af7bd6 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > @@ -613,6 +613,7 @@ static int i915_load_modeset_init(struct
> > > drm_device *dev)
> > >    * working irqs for e.g. gmbus and dp aux transfers. */
> > >   intel_modeset_init(dev);
> > >  
> > > + intel_huc_init(dev);
> > >   intel_guc_init(dev);
> > >  
> > >   ret = i915_gem_init(dev);
> > > @@ -638,6 +639,7 @@ static int i915_load_modeset_init(struct
> > > drm_device *dev)
> > >  cleanup_gem:
> > >   i915_gem_fini(dev);
> > >  cleanup_irq:
> > > + intel_huc_fini(dev);
> > >   intel_guc_fini(dev);
> > >   drm_irq_uninstall(dev);
> > >   intel_teardown_gmbus(dev);
> > > @@ -1315,6 +1317,7 @@ void i915_driver_unload(struct drm_device
> > > *dev)
> > >   /* Flush any outstanding unpin_work. */
> > >   drain_workqueue(dev_priv->wq);
> > >  
> > > + intel_huc_fini(dev);
> > >   intel_guc_fini(dev);
> > >   i915_gem_fini(dev);
> > >   intel_fbc_cleanup_cfb(dev_priv);
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index e0cb71c..625aa92 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -55,6 +55,7 @@
> > >  #include "intel_bios.h"
> > >  #include "intel_dpll_mgr.h"
> > >  #include "intel_guc.h"
> > > +#include "intel_huc.h"
> > >  #include "intel_lrc.h"
> > >  #include "intel_ringbuffer.h"
> > >  
> > > @@ -1766,6 +1767,7 @@ struct drm_i915_private {
> > >  
> > >   struct intel_gvt gvt;
> > >  
> > > + struct intel_huc huc;
> > >   struct intel_guc guc;
> > >  
> > >   struct intel_csr csr;
> > > @@ -2822,6 +2824,7 @@ struct drm_i915_cmd_table {
> > >  #define HAS_GUC(dev) (INTEL_INFO(dev)->has_guc)
> > >  #define HAS_GUC_UCODE(dev)   (HAS_GUC(dev))
> > >  #define HAS_GUC_SCHED(dev)   (HAS_GUC(dev))
> > > +#define HAS_HUC_UCODE(dev)   (HAS_GUC(dev))
> > >  
> > >  #define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)-
> > > >has_resource_streamer)
> > >  
> > > diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h
> > > b/drivers/gpu/drm/i915/i915_guc_reg.h
> > > index a47e1e4..64e942a 100644
> > > --- a/drivers/gpu/drm/i915/i915_guc_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_guc_reg.h
> > > @@ -61,9 +61,12 @@
> > >  #define   DMA_ADDRESS_SPACE_GTT    (8 << 16)
> > >  #define DMA_COPY_SIZE_MMIO(0xc310)
> > >  #define DMA_CTRL 

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

[Paul Bolle]

[Detailed post, but please give it a quick scan.]

On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> > start.
> 
> That would be between v4.7 and v4.8. (I guess my report was
> ambiguous.)
> 
> That might take some time. Because bisecting always takes a long time
> and especially since hitting this WARNING sometimes takes over an hour.
> Anyhow, please prod me if I stay silent for too long.

0) So I've lost my courage to do a bisect when my first attempt landed
me in v4.6-rc3. This is about for issue popping up between v4.7 and
v4.8-rc1.

1) So I used the most reliable debugging tool that I actually
understand: printk():

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index fbcfed63a76e..791de414cf1e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct 
intel_crtc_state *crtc_state
return DRM_PLANE_HELPER_NO_SCALING;
 
crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
-   cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+   if (WARN_ON_ONCE(!crtc_clock))
+   return DRM_PLANE_HELPER_NO_SCALING;
 
-   if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
+   cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+   if (WARN_ON_ONCE(cdclk < crtc_clock)) {
+   printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n", cdclk, 
crtc_clock);
return DRM_PLANE_HELPER_NO_SCALING;
+   }
+
+   printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >= %d\n", 
cdclk, crtc_clock);
 
/*
 * skl max scale is lower of:

2) This taught me that crtc_clock always is 373250 on my machine. cdclk
mostly is 45, but every now and then it briefly is 337500.

3) Now the interesting pattern is that cdclk drops to 337500 only after
two quick calls of skl_max_scale() with cdclk set to 45, and a
roughly 300ms pause before the third call of that function. Example:

<7>[23758.501933] i915: cdclk >= crtc_clock: 45 >= 373250
<7>[23758.515211] i915: cdclk >= crtc_clock: 45 >= 373250
<7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250

This pattern of cdclk being 337500 after roughly 300ms is surprisingly
stable.

4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
that sets cdclk to 337500 and triggers this issue. Ideas?

To be continued,


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

Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/drv_module_reload_basic: Convert sh script to C version.

[Chris Wilson]

On Mon, Oct 24, 2016 at 09:05:28PM +0300, Marius Vlad wrote:
> On Thu, Oct 20, 2016 at 08:52:23PM +0100, Chris Wilson wrote:
> > On Thu, Oct 20, 2016 at 10:36:48PM +0300, Marius Vlad wrote:
> > > +static const char *tests[] = {
> > > + "gem_alive", "gem_exec_store"
> > > +};
> > 
> > gem_alive is just a single ioctl query, simpler and move obvious to do
> > it inline. Then remove tests/gem_alive.c, but it may live on as
> > tools/gem_alive.c (or better yet tools/gem_info.c).
> > 
> > gem_exec_store is a couple of ioctls...
> Initially I tried embeddeding them directly. Problem is the at exit drm
> fd handler:
> 
> if (is_i915_device(fd)) {
>   if (__sync_fetch_and_add(_count, 1) == 0) {
>   gem_quiescent_gpu(fd);
> 
>   at_exit_drm_fd = __drm_open_driver(chipset); <-- leaked until 
> igt_exit, at_exit(), exit.
>   igt_install_exit_handler(quiescent_gpu_at_exit);
>   }
> }
> 
> A drm_open_driver() w/o that opened fd allows reloading the driver after
> running those basic tests/subtests.

Ah, yes, for module reload in C, you have to use __drm_open_driver() to
avoid that stray open device filehandle.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/dp: Print full branch/sink descriptor

[Imre Deak]

On Mon, 2016-10-24 at 22:10 +0300, Jani Nikula wrote:
> On Mon, 24 Oct 2016, Imre Deak  wrote:
> > On Mon, 2016-10-24 at 21:14 +0300, Jani Nikula wrote:
> > > On Mon, 24 Oct 2016, Imre Deak  wrote:
> > > > Extend the branch/sink descriptor info with the missing device
> > > > ID
> > > > field. While at it also read out all the descriptor registers
> > > > in one
> > > > transfer and make the debug print more compact.
> > > > 
> > > > v2: (Jani)
> > > > - Cache the descriptor in intel_dp.
> > > > - Split out this change into a separate patch.
> > > > 
> > > > Cc: Jani Nikula 
> > > > Signed-off-by: Imre Deak 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp.c  | 61 +---
> > > > 
> > > >  drivers/gpu/drm/i915/intel_drv.h | 10 +++
> > > >  2 files changed, 30 insertions(+), 41 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 1991250..726fdf2 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -1451,34 +1451,33 @@ static void intel_dp_print_rates(struct
> > > > intel_dp *intel_dp)
> > > >     DRM_DEBUG_KMS("common rates: %s\n", str);
> > > >  }
> > > >  
> > > > -static void intel_dp_print_hw_revision(struct intel_dp
> > > > *intel_dp)
> > > > +static bool
> > > > +__intel_dp_read_desc(struct intel_dp *intel_dp, struct
> > > > intel_dp_desc *desc)
> > > >  {
> > > > -   uint8_t rev;
> > > > -   int len;
> > > > +   u32 base = drm_dp_is_branch(intel_dp->dpcd) ?
> > > > DP_BRANCH_OUI :
> > > > +     DP_SINK_
> > > > OUI;
> > > >  
> > > > -   if (!drm_dp_is_branch(intel_dp->dpcd))
> > > > -   return;
> > > > -
> > > > -   len = drm_dp_dpcd_read(_dp->aux,
> > > > DP_BRANCH_HW_REV, , 1);
> > > > -   if (len < 0)
> > > > -   return;
> > > > -
> > > > -   DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev &
> > > > 0xf0) >> 4, rev & 0xf);
> > > > +   return drm_dp_dpcd_read(_dp->aux, base, desc,
> > > > sizeof(*desc)) ==
> > > > +      sizeof(*desc);
> > > >  }
> > > >  
> > > > -static void intel_dp_print_sw_revision(struct intel_dp
> > > > *intel_dp)
> > > > +static bool intel_dp_read_desc(struct intel_dp *intel_dp)
> > > >  {
> > > > -   uint8_t rev[2];
> > > > -   int len;
> > > > +   struct intel_dp_desc *desc = _dp->desc;
> > > > +   bool oui_sup = intel_dp-
> > > > >dpcd[DP_DOWN_STREAM_PORT_COUNT] &
> > > > +      DP_OUI_SUPPORT;
> > > >  
> > > > -   if (!drm_dp_is_branch(intel_dp->dpcd))
> > > > -   return;
> > > > +   if (__intel_dp_read_desc(intel_dp, desc) < 0)
> > > 
> > > The bool returned from __intel_dp_read_desc will never be less
> > > than 0...
> > 
> > Yep, that's a typo, will fix it.
> > 
> > > There's no point in reading the desc if oui_sup is false, is
> > > there? All of desc should read all zeros in that case, not just
> > > OUI.
> > 
> > The spec is not too clear about this yes, but as I read it oui_sup
> > applies only to the OUI reg, device ID and the revisions can be
> > still valid.
> 
> For address 7h:
> 
> """
> Bit 7 = OUI Support
> 0 = OUI not supported
> 1 = OUI supported (OUI and Device Identification mandatory for DP
> 1.2)
> 00400h to 00402h for a Sink device, plus 00403h-0040Bh for Device
> Identification
> 00500h to 00502h for a Branch device, plus 00503h-0050Bh for Device
> Identification
> """
> 
> Based on that I'd say the bit covers device id and revisions too. Why
> would the device id and revision offset be mentioned here otherwise?

As a reference to what 'Device Identification' above means? In any case
if 'OUI Support' applies to the whole descriptor referring separately
to OUI and Device Identification right afterwards is confusing to me.

Could we just read it out regardless of the flag and depend on the read
failing or the values being zeroed if it's not "supported"?

> 
> > The LSPCON FW has oui_sup cleared, but returns valid device ID and
> > revision values.
> 
> I think I'll cry a little.
> 
> > > I guess the desc should be reset to zeros at detect or somewhere.
> > > I'm
> > > sure we have other stuff we fail to reset too.
> > 
> > Yes, like the dpcd array. desc will be used only for debug printing
> > atm
> > where we always re-read it first, and for LSPCON where it's
> > constant,
> > so if that's fine for you I'd leave this for later.
> > 
> > > 
> > > > +   return false;
> > > >  
> > > > -   len = drm_dp_dpcd_read(_dp->aux,
> > > > DP_BRANCH_SW_REV, , 2);
> > > > -   if (len < 0)
> > > > -   return;
> > > > +   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %.*s HW-rev
> > > > %d.%d SW-rev %d.%d\n",
> > > 
> > > Maybe some form of %*pE would be more defensive for device id?
> > > See
> > > 

Re: [Intel-gfx] [PATCH 0/2] drm/i915/gvt: fix compilation errors in gtt.c

[Jérémy Lefaure]

On Mon, 24 Oct 2016 10:36:58 +0800
Zhenyu Wang  wrote:

> On 2016.10.20 18:05:56 -0400, Jérémy Lefaure wrote:
> > This series fixes 2 compilations errors in gvt/gtt.c on 32-bits platform:
> >  [PATCH 1/2] drm/i915/gvt: fix bad 32 bit shift in gtt
> >  [PATCH 2/2] drm/i915/gvt: fix an error string format
> > 
> > The file gtt.c still does not compile because of shifting errors. Should 
> > the 32
> > bits architecture be supported ?  
> 
> Hi, we don't have 32bit platform support now, so will depend on 64bit kernel 
> only.
> 
Ok, that was I thought. Do my patches are valid anyway ? At least the
1st ?

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

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/dp: Print full branch/sink descriptor

[Jani Nikula]

On Mon, 24 Oct 2016, Imre Deak  wrote:
> On Mon, 2016-10-24 at 21:14 +0300, Jani Nikula wrote:
>> On Mon, 24 Oct 2016, Imre Deak  wrote:
>> > Extend the branch/sink descriptor info with the missing device ID
>> > field. While at it also read out all the descriptor registers in one
>> > transfer and make the debug print more compact.
>> > 
>> > v2: (Jani)
>> > - Cache the descriptor in intel_dp.
>> > - Split out this change into a separate patch.
>> > 
>> > Cc: Jani Nikula 
>> > Signed-off-by: Imre Deak 
>> > ---
>> >  drivers/gpu/drm/i915/intel_dp.c  | 61 
>> > +---
>> >  drivers/gpu/drm/i915/intel_drv.h | 10 +++
>> >  2 files changed, 30 insertions(+), 41 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> > b/drivers/gpu/drm/i915/intel_dp.c
>> > index 1991250..726fdf2 100644
>> > --- a/drivers/gpu/drm/i915/intel_dp.c
>> > +++ b/drivers/gpu/drm/i915/intel_dp.c
>> > @@ -1451,34 +1451,33 @@ static void intel_dp_print_rates(struct intel_dp 
>> > *intel_dp)
>> >    DRM_DEBUG_KMS("common rates: %s\n", str);
>> >  }
>> >  
>> > -static void intel_dp_print_hw_revision(struct intel_dp *intel_dp)
>> > +static bool
>> > +__intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc 
>> > *desc)
>> >  {
>> > -  uint8_t rev;
>> > -  int len;
>> > +  u32 base = drm_dp_is_branch(intel_dp->dpcd) ? DP_BRANCH_OUI :
>> > +    DP_SINK_OUI;
>> >  
>> > -  if (!drm_dp_is_branch(intel_dp->dpcd))
>> > -  return;
>> > -
>> > -  len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
>> > -  if (len < 0)
>> > -  return;
>> > -
>> > -  DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev & 0xf0) >> 4, rev & 
>> > 0xf);
>> > +  return drm_dp_dpcd_read(_dp->aux, base, desc, sizeof(*desc)) ==
>> > +     sizeof(*desc);
>> >  }
>> >  
>> > -static void intel_dp_print_sw_revision(struct intel_dp *intel_dp)
>> > +static bool intel_dp_read_desc(struct intel_dp *intel_dp)
>> >  {
>> > -  uint8_t rev[2];
>> > -  int len;
>> > +  struct intel_dp_desc *desc = _dp->desc;
>> > +  bool oui_sup = intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] &
>> > +     DP_OUI_SUPPORT;
>> >  
>> > -  if (!drm_dp_is_branch(intel_dp->dpcd))
>> > -  return;
>> > +  if (__intel_dp_read_desc(intel_dp, desc) < 0)
>> 
>> The bool returned from __intel_dp_read_desc will never be less than 0...
>
> Yep, that's a typo, will fix it.
>
>> There's no point in reading the desc if oui_sup is false, is there? All of 
>> desc should read all zeros in that case, not just OUI.
>
> The spec is not too clear about this yes, but as I read it oui_sup
> applies only to the OUI reg, device ID and the revisions can be
> still valid.

For address 7h:

"""
Bit 7 = OUI Support
0 = OUI not supported
1 = OUI supported (OUI and Device Identification mandatory for DP 1.2)
00400h to 00402h for a Sink device, plus 00403h-0040Bh for Device
Identification
00500h to 00502h for a Branch device, plus 00503h-0050Bh for Device
Identification
"""

Based on that I'd say the bit covers device id and revisions too. Why
would the device id and revision offset be mentioned here otherwise?

> The LSPCON FW has oui_sup cleared, but returns valid device ID and
> revision values.

I think I'll cry a little.

>> I guess the desc should be reset to zeros at detect or somewhere. I'm
>> sure we have other stuff we fail to reset too.
>
> Yes, like the dpcd array. desc will be used only for debug printing atm
> where we always re-read it first, and for LSPCON where it's constant,
> so if that's fine for you I'd leave this for later.
>
>> 
>> > +  return false;
>> >  
>> > -  len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
>> > -  if (len < 0)
>> > -  return;
>> > +  DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %.*s HW-rev %d.%d SW-rev 
>> > %d.%d\n",
>> 
>> Maybe some form of %*pE would be more defensive for device id? See
>> Documentation/printk-formats.txt.
>
> Yes, can change that to '%*pE'.
>
>> > +    drm_dp_is_branch(intel_dp->dpcd) ? "branch" : "sink",
>> > +    (int)sizeof(desc->oui), desc->oui, oui_sup ? "" : "(NS)",
>> > +    (int)sizeof(desc->device_id), desc->device_id,
>> > +    desc->hw_rev >> 4, desc->hw_rev & 0xf,
>> > +    desc->sw_major_rev, desc->sw_minor_rev);
>> >  
>> > -  DRM_DEBUG_KMS("sink sw revision: %d.%d\n", rev[0], rev[1]);
>> > +  return true;
>> >  }
>> >  
>> >  static int rate_to_index(int find, const int *rates)
>> > @@ -3621,23 +3620,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>> >    return true;
>> >  }
>> >  
>> > -static void
>> > -intel_dp_probe_oui(struct intel_dp *intel_dp)
>> > -{
>> > -  bool is_branch = drm_dp_is_branch(intel_dp->dpcd);
>> > -  u8 buf[3];
>> > -
>> > -  if (!(intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
>> > -  

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/lspcon: Work around resume failure

[Imre Deak]

On Mon, 2016-10-24 at 21:58 +0300, Jani Nikula wrote:
> On Mon, 24 Oct 2016, Imre Deak  wrote:
> > On ma, 2016-10-24 at 17:16 +, Patchwork wrote:
> > > == Series Details ==
> > > 
> > > Series: drm/i915/lspcon: Work around resume failure
> > > URL   : https://patchwork.freedesktop.org/series/14280/
> > > State : warning
> > > 
> > > == Summary ==
> > > 
> > > Series 14280v1 drm/i915/lspcon: Work around resume failure
> > > https://patchwork.freedesktop.org/api/1.0/series/14280/revisions/1/mb
> > > ox/
> > > 
> > > Test drv_module_reload_basic:
> > > pass   -> DMESG-WARN (fi-skl-6700hq)
> > 
> > This one is a result of the previous CI run where LSPCON failed after
> > S3. After a warm-reboot LSPCON is still in a broken state, and even the
> > initial LSPCON probe will fail.
> > 
> > A power cycle between CI runs would prevent the above.
> 
> Err, what. So patch 8/8 doesn't fix that problem? What fixes that
> then?!?

It does fix the problem, which happens after S3. The above fail is due to the
previous CI run which left LSPCON in a broken state after an S3 test. A 
subsequent
warm-reset on that machine won't recover LSPCON and the load time LSPCON probe 
will
fail. I couldn't reproduce this problem with the workaround applied.

--Imre

> 
> BR,
> Jani
> 
> > 
> > > Test gem_exec_suspend:
> > > Subgroup basic-s3:
> > > dmesg-warn -> PASS   (fi-skl-6700hq)
> > > Test kms_pipe_crc_basic:
> > > Subgroup suspend-read-crc-pipe-a:
> > > dmesg-warn -> PASS   (fi-skl-6700hq)
> > > Subgroup suspend-read-crc-pipe-b:
> > > dmesg-warn -> PASS   (fi-skl-6700hq)
> > > Subgroup suspend-read-crc-pipe-c:
> > > dmesg-warn -> PASS   (fi-skl-6700hq)
> > > 
> > > fi-bdw-
> > > 5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
> > > fi-bsw-
> > > n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
> > > fi-bxt-
> > > t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
> > > fi-byt-
> > > j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
> > > fi-byt-
> > > n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
> > > fi-hsw-
> > > 4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
> > > fi-hsw-
> > > 4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
> > > fi-ilk-
> > > 650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
> > > fi-ivb-
> > > 3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
> > > fi-ivb-
> > > 3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
> > > fi-skl-
> > > 6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
> > > fi-skl-
> > > 6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
> > > fi-skl-
> > > 6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
> > > fi-skl-
> > > 6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
> > > fi-snb-
> > > 2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
> > > fi-snb-
> > > 2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
> > > 
> > > Results at /Patchwork_2801/
> > > 
> > > 102441087e47f4892b88c4f6e308e3edf89eeda1 drm-intel-nightly: 2016y-
> > > 10m-24d-14h-28m-17s UTC integration manifest
> > > eaa672c drm/i915/lspcon: Add workaround for resuming in PCON mode
> > > eb04604 drm/i915/lspcon: Get DDC adapter via container_of() instead
> > > of cached ptr
> > > 0ca993d drm/i915/dp: Read DP descriptor for eDP and LSPCON too
> > > 0144d102 drm/i915/lspcon: Fail LSPCON probe if the start of DPCD
> > > can't be read
> > > 7568e07 drm/i915/dp: Print full branch/sink descriptor
> > > 3b4f6e9 drm/i915/dp: Print only sink or branch specific OUI based on
> > > dev type
> > > b1439bc drm/i915/dp: Remove debug dependency of DPCD SW/HW revision
> > > read
> > > 2beca1a drm/dp: Factor out helper to distinguish between branch and
> > > sink devices
> > > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> 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: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/lspcon: Work around resume failure

[Jani Nikula]

On Mon, 24 Oct 2016, Imre Deak  wrote:
> On ma, 2016-10-24 at 17:16 +, Patchwork wrote:
>> == Series Details ==
>> 
>> Series: drm/i915/lspcon: Work around resume failure
>> URL   : https://patchwork.freedesktop.org/series/14280/
>> State : warning
>> 
>> == Summary ==
>> 
>> Series 14280v1 drm/i915/lspcon: Work around resume failure
>> https://patchwork.freedesktop.org/api/1.0/series/14280/revisions/1/mb
>> ox/
>> 
>> Test drv_module_reload_basic:
>> pass   -> DMESG-WARN (fi-skl-6700hq)
>
> This one is a result of the previous CI run where LSPCON failed after
> S3. After a warm-reboot LSPCON is still in a broken state, and even the
> initial LSPCON probe will fail.
>
> A power cycle between CI runs would prevent the above.

Err, what. So patch 8/8 doesn't fix that problem? What fixes that
then?!?

BR,
Jani

>
>> Test gem_exec_suspend:
>> Subgroup basic-s3:
>> dmesg-warn -> PASS   (fi-skl-6700hq)
>> Test kms_pipe_crc_basic:
>> Subgroup suspend-read-crc-pipe-a:
>> dmesg-warn -> PASS   (fi-skl-6700hq)
>> Subgroup suspend-read-crc-pipe-b:
>> dmesg-warn -> PASS   (fi-skl-6700hq)
>> Subgroup suspend-read-crc-pipe-c:
>> dmesg-warn -> PASS   (fi-skl-6700hq)
>> 
>> fi-bdw-
>> 5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
>> fi-bsw-
>> n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
>> fi-bxt-
>> t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
>> fi-byt-
>> j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
>> fi-byt-
>> n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
>> fi-hsw-
>> 4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
>> fi-hsw-
>> 4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
>> fi-ilk-
>> 650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
>> fi-ivb-
>> 3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
>> fi-ivb-
>> 3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
>> fi-skl-
>> 6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
>> fi-skl-
>> 6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
>> fi-skl-
>> 6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
>> fi-skl-
>> 6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
>> fi-snb-
>> 2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
>> fi-snb-
>> 2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
>> 
>> Results at /Patchwork_2801/
>> 
>> 102441087e47f4892b88c4f6e308e3edf89eeda1 drm-intel-nightly: 2016y-
>> 10m-24d-14h-28m-17s UTC integration manifest
>> eaa672c drm/i915/lspcon: Add workaround for resuming in PCON mode
>> eb04604 drm/i915/lspcon: Get DDC adapter via container_of() instead
>> of cached ptr
>> 0ca993d drm/i915/dp: Read DP descriptor for eDP and LSPCON too
>> 0144d102 drm/i915/lspcon: Fail LSPCON probe if the start of DPCD
>> can't be read
>> 7568e07 drm/i915/dp: Print full branch/sink descriptor
>> 3b4f6e9 drm/i915/dp: Print only sink or branch specific OUI based on
>> dev type
>> b1439bc drm/i915/dp: Remove debug dependency of DPCD SW/HW revision
>> read
>> 2beca1a drm/dp: Factor out helper to distinguish between branch and
>> sink devices
>> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: [Intel-gfx] [PATCH v2 4/8] drm/i915/dp: Print full branch/sink descriptor

[Imre Deak]

On Mon, 2016-10-24 at 21:14 +0300, Jani Nikula wrote:
> On Mon, 24 Oct 2016, Imre Deak  wrote:
> > Extend the branch/sink descriptor info with the missing device ID
> > field. While at it also read out all the descriptor registers in one
> > transfer and make the debug print more compact.
> > 
> > v2: (Jani)
> > - Cache the descriptor in intel_dp.
> > - Split out this change into a separate patch.
> > 
> > Cc: Jani Nikula 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 61 
> > +---
> >  drivers/gpu/drm/i915/intel_drv.h | 10 +++
> >  2 files changed, 30 insertions(+), 41 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 1991250..726fdf2 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1451,34 +1451,33 @@ static void intel_dp_print_rates(struct intel_dp 
> > *intel_dp)
> >     DRM_DEBUG_KMS("common rates: %s\n", str);
> >  }
> >  
> > -static void intel_dp_print_hw_revision(struct intel_dp *intel_dp)
> > +static bool
> > +__intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc)
> >  {
> > -   uint8_t rev;
> > -   int len;
> > +   u32 base = drm_dp_is_branch(intel_dp->dpcd) ? DP_BRANCH_OUI :
> > +     DP_SINK_OUI;
> >  
> > -   if (!drm_dp_is_branch(intel_dp->dpcd))
> > -   return;
> > -
> > -   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
> > -   if (len < 0)
> > -   return;
> > -
> > -   DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev & 0xf0) >> 4, rev & 
> > 0xf);
> > +   return drm_dp_dpcd_read(_dp->aux, base, desc, sizeof(*desc)) ==
> > +      sizeof(*desc);
> >  }
> >  
> > -static void intel_dp_print_sw_revision(struct intel_dp *intel_dp)
> > +static bool intel_dp_read_desc(struct intel_dp *intel_dp)
> >  {
> > -   uint8_t rev[2];
> > -   int len;
> > +   struct intel_dp_desc *desc = _dp->desc;
> > +   bool oui_sup = intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] &
> > +      DP_OUI_SUPPORT;
> >  
> > -   if (!drm_dp_is_branch(intel_dp->dpcd))
> > -   return;
> > +   if (__intel_dp_read_desc(intel_dp, desc) < 0)
> 
> The bool returned from __intel_dp_read_desc will never be less than 0...

Yep, that's a typo, will fix it.

> There's no point in reading the desc if oui_sup is false, is there? All of 
> desc should read all zeros in that case, not just OUI.

The spec is not too clear about this yes, but as I read it oui_sup
applies only to the OUI reg, device ID and the revisions can be
still valid. The LSPCON FW has oui_sup cleared, but returns valid
device ID and revision values.

> I guess the desc should be reset to zeros at detect or somewhere. I'm
> sure we have other stuff we fail to reset too.

Yes, like the dpcd array. desc will be used only for debug printing atm
where we always re-read it first, and for LSPCON where it's constant,
so if that's fine for you I'd leave this for later.

> 
> > +   return false;
> >  
> > -   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
> > -   if (len < 0)
> > -   return;
> > +   DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %.*s HW-rev %d.%d SW-rev 
> > %d.%d\n",
> 
> Maybe some form of %*pE would be more defensive for device id? See
> Documentation/printk-formats.txt.

Yes, can change that to '%*pE'.

> > +     drm_dp_is_branch(intel_dp->dpcd) ? "branch" : "sink",
> > +     (int)sizeof(desc->oui), desc->oui, oui_sup ? "" : "(NS)",
> > +     (int)sizeof(desc->device_id), desc->device_id,
> > +     desc->hw_rev >> 4, desc->hw_rev & 0xf,
> > +     desc->sw_major_rev, desc->sw_minor_rev);
> >  
> > -   DRM_DEBUG_KMS("sink sw revision: %d.%d\n", rev[0], rev[1]);
> > +   return true;
> >  }
> >  
> >  static int rate_to_index(int find, const int *rates)
> > @@ -3621,23 +3620,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
> >     return true;
> >  }
> >  
> > -static void
> > -intel_dp_probe_oui(struct intel_dp *intel_dp)
> > -{
> > -   bool is_branch = drm_dp_is_branch(intel_dp->dpcd);
> > -   u8 buf[3];
> > -
> > -   if (!(intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
> > -   return;
> > -
> > -   if (drm_dp_dpcd_read(_dp->aux,
> > -    is_branch ? DP_BRANCH_OUI : DP_SINK_OUI,
> > -    buf, 3) == 3)
> > -   DRM_DEBUG_KMS("%s OUI: %02hx%02hx%02hx\n",
> > -     is_branch ? "Branch" : "Sink",
> > -     buf[0], buf[1], buf[2]);
> > -}
> > -
> >  static bool
> >  intel_dp_can_mst(struct intel_dp *intel_dp)
> >  {
> > @@ -4416,10 +4398,7 @@ intel_dp_long_pulse(struct intel_connector 
> > *intel_connector)
> >  
> >     intel_dp_print_rates(intel_dp);
> >  
> > -   intel_dp_probe_oui(intel_dp);
> > -
> > -   

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/lspcon: Get DDC adapter via container_of() instead of cached ptr

[Jani Nikula]

On Mon, 24 Oct 2016, Imre Deak  wrote:
> We can use the container_of() magic to get to the DDC adapter, so no
> need for caching a pointer to it. We'll also need to get at the intel_dp
> ptr in the following patch, so add a helper that can be used for both
> purposes.
>
> Cc: Shashank Sharma 
> Signed-off-by: Imre Deak 

SPOT FTW.

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_drv.h|  1 -
>  drivers/gpu/drm/i915/intel_lspcon.c | 15 +++
>  2 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index a79cbad..45f55b5 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -974,7 +974,6 @@ struct intel_dp {
>  struct intel_lspcon {
>   bool active;
>   enum drm_lspcon_mode mode;
> - struct drm_dp_aux *aux;
>  };
>  
>  struct intel_digital_port {
> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
> b/drivers/gpu/drm/i915/intel_lspcon.c
> index c5f278b..3dc5a0b 100644
> --- a/drivers/gpu/drm/i915/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> @@ -27,10 +27,18 @@
>  #include 
>  #include "intel_drv.h"
>  
> +static struct intel_dp *lspcon_to_intel_dp(struct intel_lspcon *lspcon)
> +{
> + struct intel_digital_port *dig_port =
> + container_of(lspcon, struct intel_digital_port, lspcon);
> +
> + return _port->dp;
> +}
> +
>  static enum drm_lspcon_mode lspcon_get_current_mode(struct intel_lspcon 
> *lspcon)
>  {
>   enum drm_lspcon_mode current_mode = DRM_LSPCON_MODE_INVALID;
> - struct i2c_adapter *adapter = >aux->ddc;
> + struct i2c_adapter *adapter = _to_intel_dp(lspcon)->aux.ddc;
>  
>   if (drm_lspcon_get_mode(adapter, _mode))
>   DRM_ERROR("Error reading LSPCON mode\n");
> @@ -45,7 +53,7 @@ static int lspcon_change_mode(struct intel_lspcon *lspcon,
>  {
>   int err;
>   enum drm_lspcon_mode current_mode;
> - struct i2c_adapter *adapter = >aux->ddc;
> + struct i2c_adapter *adapter = _to_intel_dp(lspcon)->aux.ddc;
>  
>   err = drm_lspcon_get_mode(adapter, _mode);
>   if (err) {
> @@ -72,7 +80,7 @@ static int lspcon_change_mode(struct intel_lspcon *lspcon,
>  static bool lspcon_probe(struct intel_lspcon *lspcon)
>  {
>   enum drm_dp_dual_mode_type adaptor_type;
> - struct i2c_adapter *adapter = >aux->ddc;
> + struct i2c_adapter *adapter = _to_intel_dp(lspcon)->aux.ddc;
>  
>   /* Lets probe the adaptor and check its type */
>   adaptor_type = drm_dp_dual_mode_detect(adapter);
> @@ -111,7 +119,6 @@ bool lspcon_init(struct intel_digital_port 
> *intel_dig_port)
>  
>   lspcon->active = false;
>   lspcon->mode = DRM_LSPCON_MODE_INVALID;
> - lspcon->aux = >aux;
>  
>   if (!lspcon_probe(lspcon)) {
>   DRM_ERROR("Failed to probe lspcon\n");

-- 
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: [Intel-gfx] [PATCH v2 5/8] drm/i915/lspcon: Fail LSPCON probe if the start of DPCD can't be read

[Jani Nikula]

On Mon, 24 Oct 2016, Imre Deak  wrote:
> All types of DP devices (eDP, DP sink, DP branch) will fail their probe
> if the start of DPCD can't be read. The LSPCON PCON functionality also
> depends on accessing this area, so fail the probe if the read fails.
>
> Cc: Shashank Sharma 
> Signed-off-by: Imre Deak 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_dp.c | 2 +-
>  drivers/gpu/drm/i915/intel_drv.h| 2 ++
>  drivers/gpu/drm/i915/intel_lspcon.c | 5 +
>  3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 726fdf2..62c5512 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3495,7 +3495,7 @@ intel_dp_link_down(struct intel_dp *intel_dp)
>   intel_dp->DP = DP;
>  }
>  
> -static bool
> +bool
>  intel_dp_read_dpcd(struct intel_dp *intel_dp)
>  {
>   if (drm_dp_dpcd_read(_dp->aux, 0x000, intel_dp->dpcd,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 4c9f953..ff9d2dc 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1461,6 +1461,8 @@ static inline unsigned int 
> intel_dp_unused_lane_mask(int lane_count)
>   return ~((1 << lane_count) - 1) & 0xf;
>  }
>  
> +bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> +
>  /* intel_dp_aux_backlight.c */
>  int intel_dp_aux_init_backlight_funcs(struct intel_connector 
> *intel_connector);
>  
> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
> b/drivers/gpu/drm/i915/intel_lspcon.c
> index 632149c..23b817a 100644
> --- a/drivers/gpu/drm/i915/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> @@ -131,6 +131,11 @@ bool lspcon_init(struct intel_digital_port 
> *intel_dig_port)
>   }
>   }
>  
> + if (!intel_dp_read_dpcd(dp)) {
> + DRM_ERROR("LSPCON DPCD read failed\n");
> + return false;
> + }
> +
>   DRM_DEBUG_KMS("Success: LSPCON init\n");
>   return true;
>  }

-- 
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: [Intel-gfx] [PATCH v2 6/8] drm/i915/dp: Read DP descriptor for eDP and LSPCON too

[Jani Nikula]

On Mon, 24 Oct 2016, Imre Deak  wrote:
> As for external DP sink and branch devices read and print the DP
> descriptor for eDP and LSPCON devices as well to aid debugging.
>
> v2:
> - Split out this change to a separate patch. (Jani)
>
> Cc: Jani Nikula 
> Signed-off-by: Imre Deak 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_dp.c | 4 +++-
>  drivers/gpu/drm/i915/intel_drv.h| 1 +
>  drivers/gpu/drm/i915/intel_lspcon.c | 2 ++
>  3 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62c5512..043993f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1461,7 +1461,7 @@ __intel_dp_read_desc(struct intel_dp *intel_dp, struct 
> intel_dp_desc *desc)
>  sizeof(*desc);
>  }
>  
> -static bool intel_dp_read_desc(struct intel_dp *intel_dp)
> +bool intel_dp_read_desc(struct intel_dp *intel_dp)
>  {
>   struct intel_dp_desc *desc = _dp->desc;
>   bool oui_sup = intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] &
> @@ -3519,6 +3519,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   if (!intel_dp_read_dpcd(intel_dp))
>   return false;
>  
> + intel_dp_read_desc(intel_dp);
> +
>   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
>   dev_priv->no_aux_handshake = intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
>   DP_NO_AUX_HANDSHAKE_LINK_TRAINING;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index ff9d2dc..a79cbad 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1462,6 +1462,7 @@ static inline unsigned int 
> intel_dp_unused_lane_mask(int lane_count)
>  }
>  
>  bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> +bool intel_dp_read_desc(struct intel_dp *intel_dp);
>  
>  /* intel_dp_aux_backlight.c */
>  int intel_dp_aux_init_backlight_funcs(struct intel_connector 
> *intel_connector);
> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
> b/drivers/gpu/drm/i915/intel_lspcon.c
> index 23b817a..c5f278b 100644
> --- a/drivers/gpu/drm/i915/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> @@ -136,6 +136,8 @@ bool lspcon_init(struct intel_digital_port 
> *intel_dig_port)
>   return false;
>   }
>  
> + intel_dp_read_desc(dp);
> +
>   DRM_DEBUG_KMS("Success: LSPCON init\n");
>   return true;
>  }

-- 
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: [Intel-gfx] [PATCH v3] drm/edid: Only print the bad edid when aborting

[Sean Paul]

On Mon, Oct 24, 2016 at 7:38 AM, Chris Wilson  wrote:
> Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
> intermediate edid reads. This causes transient failures in CI which
> flags up the sporadic EDID read failures, which are recovered by
> rereading the EDID automatically. This patch combines the reporting done
> by drm_do_get_edid() itself with the bad block printing from
> get_edid_block(), into a single warning associated with the connector
> once all attempts to retrieve the EDID fail.
>
> v2: Print the whole EDID, marking up the bad/zero blocks. This requires
> recording the whole of the raw edid, then a second pass to reduce it to
> the valid extensions.
> v3: Fix invalid/valid extension fumble.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
> Signed-off-by: Chris Wilson 
> Cc: Ville Syrjälä 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_edid.c | 79 
> --
>  1 file changed, 56 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 95de47ba1e77..9506933b41cd 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1260,6 +1260,34 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned 
> int block, size_t len)
> return ret == xfers ? 0 : -1;
>  }
>
> +static void connector_bad_edid(struct drm_connector *connector,
> +  u8 *edid, int num_blocks)
> +{
> +   int i;
> +
> +   if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
> +   return;
> +
> +   dev_warn(connector->dev->dev,
> +"%s: EDID is invalid:\n",
> +connector->name);
> +   for (i = 0; i < num_blocks; i++) {
> +   u8 *block = edid + i * EDID_LENGTH;
> +   char prefix[20];
> +
> +   if (drm_edid_is_zero(block, EDID_LENGTH))
> +   sprintf(prefix, "\t[%02x] ZERO ", i);
> +   else if (!drm_edid_block_valid(block, i, false, NULL))
> +   sprintf(prefix, "\t[%02x] BAD  ", i);
> +   else
> +   sprintf(prefix, "\t[%02x] GOOD ", i);
> +
> +   print_hex_dump(KERN_WARNING,
> +  prefix, DUMP_PREFIX_NONE, 16, 1,
> +  block, EDID_LENGTH, false);
> +   }
> +}
> +
>  /**
>   * drm_do_get_edid - get EDID data using a custom EDID block read function
>   * @connector: connector we're probing
> @@ -1283,7 +1311,6 @@ struct edid *drm_do_get_edid(struct drm_connector 
> *connector,
>  {
> int i, j = 0, valid_extensions = 0;
> u8 *edid, *new;
> -   bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
> DRM_UT_KMS);
>
> if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> return NULL;
> @@ -1292,7 +1319,7 @@ struct edid *drm_do_get_edid(struct drm_connector 
> *connector,
> for (i = 0; i < 4; i++) {
> if (get_edid_block(data, edid, 0, EDID_LENGTH))
> goto out;
> -   if (drm_edid_block_valid(edid, 0, print_bad_edid,
> +   if (drm_edid_block_valid(edid, 0, false,
>  >edid_corrupt))
> break;
> if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
> @@ -1304,54 +1331,60 @@ struct edid *drm_do_get_edid(struct drm_connector 
> *connector,
> goto carp;
>
> /* if there's no extensions, we're done */
> -   if (edid[0x7e] == 0)
> +   valid_extensions = edid[0x7e];
> +   if (valid_extensions == 0)
> return (struct edid *)edid;
>
> -   new = krealloc(edid, (edid[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
> +   new = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH, 
> GFP_KERNEL);
> if (!new)
> goto out;
> edid = new;
>
> for (j = 1; j <= edid[0x7e]; j++) {
> -   u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
> +   u8 *block = edid + j * EDID_LENGTH;
>
> for (i = 0; i < 4; i++) {
> if (get_edid_block(data, block, j, EDID_LENGTH))
> goto out;
> -   if (drm_edid_block_valid(block, j,
> -print_bad_edid, NULL)) {
> -   valid_extensions++;
> +   if (drm_edid_block_valid(block, j, false, NULL))
> break;
> -   }
> }
>
> -   if (i == 4 && print_bad_edid) {
> -   dev_warn(connector->dev->dev,
> -"%s: Ignoring invalid EDID block %d.\n",
> -

Re: [Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

[Sean Paul]

On Mon, Oct 24, 2016 at 3:12 AM, Daniel Vetter  wrote:
> On Mon, Oct 24, 2016 at 9:00 AM, Manasi Navare
>  wrote:
>>> I guess we just need to do some additional work on top to make sure the
>>> vblank ioctl can't see invalid state. Which would then again make upfront
>>> link trainig possible ...
>>
>> Could you share some more details on what work would need to be done
>> for vblank? Then I can investigate it a little bit more tomor during the day.
>
> So the trouble is that drm_irq.c is still from the old pre-kms days.
> Which means it deals in int pipe instead of struct drm_crtc *, among
> other things. But we can't simply switch over because some old drivers
> (pre-kms ones) still depend upon that old code. Hence we need:
>
> 1. Duplicate most of the code in drm_irq.c into a new
> drm_crtc_vblank.c, which is only used for kms drivers.

Why duplicate all of this code? That seems a bit wasteful.

Can't we just add the inverse of drm_crtc_pipe() (coincidentally, I
also suggested we introduce this function in "drm: zte: add initial
vou drm driver"), and use those to map between pipe and crtc where
appropriate? The crtc locks could be acquired/dropped based on
DRIVER_MODESET in drm_irq.c

Unrelated to the vblank discussion: This functionality is pretty
similar to what happens on suspend/resume. Any chance we can share?

Sean

> And in the
> ioctl code have a DRIVER_MODESET check and either call the new kms
> version (in drm_crtc_vblank.c) or the old one (still in drm_irq.c).
>
> 2. Convert the int pipe into a drm_crtc pointer in the new kms code.
> For prettiness we could (try) to do that as much as possible.
>
> 3. Grab the drm_crtc->mutex in the ioctl code to block these races.
>
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915/dp: Print full branch/sink descriptor

[Jani Nikula]

On Mon, 24 Oct 2016, Imre Deak  wrote:
> Extend the branch/sink descriptor info with the missing device ID
> field. While at it also read out all the descriptor registers in one
> transfer and make the debug print more compact.
>
> v2: (Jani)
> - Cache the descriptor in intel_dp.
> - Split out this change into a separate patch.
>
> Cc: Jani Nikula 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 61 
> +---
>  drivers/gpu/drm/i915/intel_drv.h | 10 +++
>  2 files changed, 30 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 1991250..726fdf2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1451,34 +1451,33 @@ static void intel_dp_print_rates(struct intel_dp 
> *intel_dp)
>   DRM_DEBUG_KMS("common rates: %s\n", str);
>  }
>  
> -static void intel_dp_print_hw_revision(struct intel_dp *intel_dp)
> +static bool
> +__intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc)
>  {
> - uint8_t rev;
> - int len;
> + u32 base = drm_dp_is_branch(intel_dp->dpcd) ? DP_BRANCH_OUI :
> +   DP_SINK_OUI;
>  
> - if (!drm_dp_is_branch(intel_dp->dpcd))
> - return;
> -
> - len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
> - if (len < 0)
> - return;
> -
> - DRM_DEBUG_KMS("sink hw revision: %d.%d\n", (rev & 0xf0) >> 4, rev & 
> 0xf);
> + return drm_dp_dpcd_read(_dp->aux, base, desc, sizeof(*desc)) ==
> +sizeof(*desc);
>  }
>  
> -static void intel_dp_print_sw_revision(struct intel_dp *intel_dp)
> +static bool intel_dp_read_desc(struct intel_dp *intel_dp)
>  {
> - uint8_t rev[2];
> - int len;
> + struct intel_dp_desc *desc = _dp->desc;
> + bool oui_sup = intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] &
> +DP_OUI_SUPPORT;
>  
> - if (!drm_dp_is_branch(intel_dp->dpcd))
> - return;
> + if (__intel_dp_read_desc(intel_dp, desc) < 0)

The bool returned from __intel_dp_read_desc will never be less than 0...

There's no point in reading the desc if oui_sup is false, is there? All
of desc should read all zeros in that case, not just OUI.

I guess the desc should be reset to zeros at detect or somewhere. I'm
sure we have other stuff we fail to reset too.

> + return false;
>  
> - len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
> - if (len < 0)
> - return;
> + DRM_DEBUG_KMS("DP %s: OUI %*phD%s dev-ID %.*s HW-rev %d.%d SW-rev 
> %d.%d\n",

Maybe some form of %*pE would be more defensive for device id? See
Documentation/printk-formats.txt.

> +   drm_dp_is_branch(intel_dp->dpcd) ? "branch" : "sink",
> +   (int)sizeof(desc->oui), desc->oui, oui_sup ? "" : "(NS)",
> +   (int)sizeof(desc->device_id), desc->device_id,
> +   desc->hw_rev >> 4, desc->hw_rev & 0xf,
> +   desc->sw_major_rev, desc->sw_minor_rev);
>  
> - DRM_DEBUG_KMS("sink sw revision: %d.%d\n", rev[0], rev[1]);
> + return true;
>  }
>  
>  static int rate_to_index(int find, const int *rates)
> @@ -3621,23 +3620,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   return true;
>  }
>  
> -static void
> -intel_dp_probe_oui(struct intel_dp *intel_dp)
> -{
> - bool is_branch = drm_dp_is_branch(intel_dp->dpcd);
> - u8 buf[3];
> -
> - if (!(intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] & DP_OUI_SUPPORT))
> - return;
> -
> - if (drm_dp_dpcd_read(_dp->aux,
> -  is_branch ? DP_BRANCH_OUI : DP_SINK_OUI,
> -  buf, 3) == 3)
> - DRM_DEBUG_KMS("%s OUI: %02hx%02hx%02hx\n",
> -   is_branch ? "Branch" : "Sink",
> -   buf[0], buf[1], buf[2]);
> -}
> -
>  static bool
>  intel_dp_can_mst(struct intel_dp *intel_dp)
>  {
> @@ -4416,10 +4398,7 @@ intel_dp_long_pulse(struct intel_connector 
> *intel_connector)
>  
>   intel_dp_print_rates(intel_dp);
>  
> - intel_dp_probe_oui(intel_dp);
> -
> - intel_dp_print_hw_revision(intel_dp);
> - intel_dp_print_sw_revision(intel_dp);
> + intel_dp_read_desc(intel_dp);
>  
>   intel_dp_configure_mst(intel_dp);
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 16b33f5..4c9f953 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -883,6 +883,14 @@ enum link_m_n_set {
>   M2_N2
>  };
>  
> +struct intel_dp_desc {
> + u8 oui[3];
> + u8 device_id[6];
> + u8 hw_rev;
> + u8 sw_major_rev;
> + u8 sw_minor_rev;
> +} __packed;
> +
>  struct intel_dp {
>   i915_reg_t output_reg;
>   i915_reg_t aux_ch_ctl_reg;
> @@ -905,6 +913,8 @@ struct 

Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/drv_module_reload_basic: Convert sh script to C version.

[Marius Vlad]

On Fri, Oct 21, 2016 at 12:39:22PM +0300, Petri Latvala wrote:
> 
> 
> On 10/20/2016 10:36 PM, Marius Vlad wrote:
> > Signed-off-by: Marius Vlad 
> > ---
> >   tests/Makefile.sources  |   2 +-
> >   tests/drv_module_reload_basic   |  97 ---
> >   tests/drv_module_reload_basic.c | 166 
> > 
> >   3 files changed, 167 insertions(+), 98 deletions(-)
> >   delete mode 100755 tests/drv_module_reload_basic
> >   create mode 100644 tests/drv_module_reload_basic.c
> > 
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > index 6d081c3..c35ea11 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -211,6 +211,7 @@ TESTS_progs = \
> > kms_pwrite_crc \
> > kms_sink_crc_basic \
> > prime_udl \
> > +   drv_module_reload_basic \
> > $(NULL)
> >   # IMPORTANT: The ZZ_ tests need to be run last!
> > @@ -221,7 +222,6 @@ TESTS_scripts_M = \
> >   TESTS_scripts = \
> > debugfs_emon_crash \
> > drv_debugfs_reader \
> > -   drv_module_reload_basic \
> > kms_sysfs_edid_timing \
> > sysfs_l3_parity \
> > test_rte_check \
> > diff --git a/tests/drv_module_reload_basic b/tests/drv_module_reload_basic
> > deleted file mode 100755
> > index a8d628d..000
> > --- a/tests/drv_module_reload_basic
> > +++ /dev/null
> > @@ -1,97 +0,0 @@
> > -#!/bin/bash
> > -#
> > -# Testcase: Reload the drm module
> > -#
> > -# ... we've broken this way too often :(
> > -#
> > -
> > -SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
> > -. $SOURCE_DIR/drm_lib.sh
> > -
> > -# no other drm service should be running, so we can just unbind
> > -
> > -# return 0 if module by name $1 is loaded according to lsmod
> > -function mod_loaded()
> > -{
> > -   lsmod | grep -w "^$1" &> /dev/null
> > -}
> > -
> > -function reload() {
> > -   local snd_hda_intel_unloaded
> > -
> > -   echo Reloading i915.ko with $*
> > -
> > -   # we must kick away fbcon (but only fbcon)
> > -   for vtcon in /sys/class/vtconsole/vtcon*/ ; do
> > -   if grep "frame buffer device" $vtcon/name > /dev/null ; then
> > -   echo unbinding $vtcon: `cat $vtcon/name`
> > -   echo 0 > $vtcon/bind
> > -   fi
> > -   done
> > -
> > -   # The sound driver uses our power well
> > -   pkill alsactl
> > -   snd_hda_intel_unloaded=0
> > -   if mod_loaded snd_hda_intel; then
> > -   rmmod snd_hda_intel && snd_hda_intel_unloaded=1
> > -   fi
> > -
> > -   # gen5 only
> > -   if mod_loaded intel_ips; then
> > -   rmmod intel_ips
> > -   fi
> > -   rmmod i915 || return $IGT_EXIT_SKIP
> > -   #ignore errors in intel-gtt, often built-in
> > -   rmmod intel-gtt &> /dev/null
> > -   # drm may be used by other devices (nouveau, radeon, udl, etc)
> > -   rmmod drm_kms_helper &> /dev/null
> > -   rmmod drm &> /dev/null
> > -
> > -   if mod_loaded i915; then
> > -   echo WARNING: i915.ko still loaded!
> > -   return $IGT_EXIT_FAILURE
> > -   else
> > -   echo module successfully unloaded
> > -   fi
> > -
> > -   modprobe i915 $*
> > -
> > -   if [ -f /sys/class/vtconsole/vtcon1/bind ]; then
> > -   echo 1 > /sys/class/vtconsole/vtcon1/bind
> > -   fi
> > -
> > -   modprobe -q snd_hda_intel || return $snd_hda_intel_unloaded
> > -}
> > -
> > -function finish_load() {
> > -   # does the device exist?
> > -   if $SOURCE_DIR/gem_alive > /dev/null ; then
> > -   echo "module successfully loaded again"
> > -   else
> > -   echo "failed to reload module successfully"
> > -   return $IGT_EXIT_FAILURE
> > -   fi
> > -
> > -   # then try to run something
> > -   if ! $SOURCE_DIR/gem_exec_store > /dev/null ; then
> > -   echo "failed to execute a simple batch after reload"
> > -   return $IGT_EXIT_FAILURE
> > -   fi
> > -
> > -   return $IGT_EXIT_SUCCESS
> > -}
> > -
> > -hda_dynamic_debug_enable
> 
> I don't see the equivalent of hda_dynamic_debug_enable in the C version.
Indeed, this got updated prior to me looking at it.
> 
> 
> > -
> > -reload || exit $?
> > -finish_load || exit $?
> > -
> > -# Repeat the module reload trying to to generate faults
> > -for i in $(seq 1 4); do
> > -   reload inject_load_failure=$i
> > -done
> > -
> > -reload || exit $?
> > -finish_load
> > -
> > -exit $?
> > diff --git a/tests/drv_module_reload_basic.c 
> > b/tests/drv_module_reload_basic.c
> > new file mode 100644
> > index 000..d36afde
> > --- /dev/null
> > +++ b/tests/drv_module_reload_basic.c
> > @@ -0,0 +1,166 @@
> > +/*
> > + * Copyright © 2016 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of this software and associated documentation files (the 
> > "Software"),
> > + * to deal in the Software without restriction, including without 
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> > + * and/or sell copies of 

Re: [Intel-gfx] [PATCH i-g-t 2/3] tests/drv_module_reload_basic: Convert sh script to C version.

[Marius Vlad]

On Thu, Oct 20, 2016 at 08:52:23PM +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 10:36:48PM +0300, Marius Vlad wrote:
> > +static const char *tests[] = {
> > +   "gem_alive", "gem_exec_store"
> > +};
> 
> gem_alive is just a single ioctl query, simpler and move obvious to do
> it inline. Then remove tests/gem_alive.c, but it may live on as
> tools/gem_alive.c (or better yet tools/gem_info.c).
> 
> gem_exec_store is a couple of ioctls...
Initially I tried embeddeding them directly. Problem is the at exit drm
fd handler:

if (is_i915_device(fd)) {
if (__sync_fetch_and_add(_count, 1) == 0) {
gem_quiescent_gpu(fd);

at_exit_drm_fd = __drm_open_driver(chipset); <-- leaked until 
igt_exit, at_exit(), exit.
igt_install_exit_handler(quiescent_gpu_at_exit);
}
}

A drm_open_driver() w/o that opened fd allows reloading the driver after
running those basic tests/subtests.

> 
> A rewritten C test should not be i915 specific if we can help it. The
> core of it can be driver agnostic (same steps required to unbind from
> console and reload after all).
> 
> > +
> > +static int
> > +reload(const char *opts_i915)
> > +{
> > +   kick_fbcon(0);
> > +
> > +   if (opts_i915)
> > +   igt_info("Reloading i915 with %s\n\n", opts_i915);
> > +
> > +   if (igt_lsmod_has_module("snd_hda_intel")) {
> > +   if (igt_pkill(SIGTERM, "alsactl") == -1) {
> > +   return IGT_EXIT_FAILURE;
> > +   }
> > +   if (igt_rmmod("snd_hda_intel", false) == -1)
> > +   return IGT_EXIT_FAILURE;
> > +   }
> > +
> > +   /* gen5 */
> > +   if (igt_lsmod_has_module("intel_ips")) {
> > +   igt_rmmod("intel_ips", false);
> > +   }
> > +
> > +   if (igt_rmmod("i915", false) == -1) {
> > +   return IGT_EXIT_SKIP;
> > +   }
> 
> Ugh. These names leave much to be desired.
> 
> igt_kmod_load()
> igt_kmod_unload()
> igt_kmod_is_loaded() (can return refcnt >= 0 and -1 for unloaded)
> 
> > +
> > +   igt_info("i915.ko has been unloaded!\n");
> > +
> > +   if (igt_lsmod_has_module("intel-gtt")) {
> > +   igt_rmmod("intel-gtt", false);
> > +   }
> > +
> > +   igt_rmmod("drm_kms_helper", false);
> > +   igt_rmmod("drm", false);
> > +
> > +   if (igt_lsmod_has_module("i915")) {
> > +   igt_info("WARNING: i915.ko still loaded!\n");
> > +   return IGT_EXIT_FAILURE;
> > +   } else {
> > +   igt_info("module successfully unloaded\n");
> > +   }
> > +
> > +   /* we do not have automatic loading of dependencies */
> > +   igt_insmod("drm", NULL);
> > +   igt_insmod("drm_kms_helper", NULL);
> > +
> > +   if (igt_insmod("i915", opts_i915) == -1) {
> > +   igt_info("Could not load i915\n");
> > +   return IGT_EXIT_FAILURE;
> > +   }
> > +
> > +   kick_fbcon(1);
> > +
> > +   if (igt_insmod("snd_hda_intel", NULL) == -1)
> > +   return IGT_EXIT_FAILURE;
> > +
> > +   return IGT_EXIT_SUCCESS;
> > +}
> > +
> > +static void
> > +igt_execv(char **argv)
> > +{
> > +   igt_fork(child, 1) {
> > +   if (execv(argv[0], argv) < 0) {
> > +   igt_info("Failed to exec %s\n",
> > +   argv[0]);
> > +   exit(IGT_EXIT_FAILURE);
> > +   }
> > +   }
> > +   igt_waitchildren();
> > +}
> > +
> > +static void
> > +finish_load(char *dirname)
> > +{
> > +   char buf[PATH_MAX];
> > +   char *__argv[2] = { buf, NULL };
> > +
> > +   memset(buf, 0, PATH_MAX);
> > +   snprintf(buf, sizeof(buf), "%s/%s", dirname, tests[0]);
> > +
> > +   igt_execv(__argv);
> > +
> > +   memset(buf, 0, sizeof(buf));
> > +   snprintf(buf, sizeof(buf), "%s/%s", dirname, tests[1]);
> > +
> > +   igt_execv(__argv);
> > +}
> > +
> > +int main(int argc, char *argv[])
> 
> igt_main
> {
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 1/3] lib/{igt_sysfs, igt_aux}: Make available to other users kick_fbcon() (unbind_fbcon()), and added helpers to igt_aux.

[Marius Vlad]

On Thu, Oct 20, 2016 at 09:09:17PM +0100, Chris Wilson wrote:
> On Thu, Oct 20, 2016 at 10:36:47PM +0300, Marius Vlad wrote:
> > +int
> > +igt_pkill(int sig, const char *comm)
> > +{
> > +   int err = 0, try = 5;
> > +   PROCTAB *proc;
> > +   proc_t *proc_info;
> > +
> > +   proc = openproc(PROC_FILLCOM | PROC_FILLSTAT | PROC_FILLARG);
> > +   igt_assert(proc != NULL);
> > +
> > +   while ((proc_info = readproc(proc, NULL))) {
> > +   if (proc_info &&
> 
> proc_info cannot be NULL, you've already tested for that.
True. Removed.
> 
> > +   !strncasecmp(proc_info->cmd, comm, sizeof(proc_info->cmd))) 
> > {
> > +   switch (sig) {
> > +   case SIGTERM:
> > +   case SIGKILL:
> > +   do {
> > +   kill(proc_info->tid, sig);
> > +   } while (kill(proc_info->tid, 0) < 0 && try--);
> > +
> > +   if (kill(proc_info->tid, 0) < 0)
> > +   err = -1;
> 
> Not convinced this is good behaviour for an API, to repeatedly call
> kill(SIGTERM) until bored. If the function didn't take a int sig and was
> called igt_terminate_process(const char *name), then repeating a few
> SIGTERM; before sending SIGKILL makes sense. But as it it, named like
> kill() I expect this to send exactly one signal.

I got mixed feelings about this as well. I'll keep it simple.

> 
> > +/**
> > + * igt_kill:
> > + * @sig: Signal to send.
> > + * @pid: Process pid to send.
> > + * @returns: 0 in case of success or -1 otherwise.
> > + *
> > + * This function is identical to igt_pkill() only that it searches the 
> > process
> > + * table using @pid instead of comm name.
> 
> There's a function called kill() that does exactly that, you even use it
> here ;)
True.
> 
> > +int
> > +igt_rmmod(const char *mod_name, bool force)
> > +{
> > +   struct kmod_ctx *ctx;
> > +   struct kmod_module *kmod;
> > +   int err, flags = 0;
> > +
> > +   ctx = kmod_new(NULL, NULL);
> > +   igt_assert(ctx != NULL);
> > +
> > +   err = kmod_module_new_from_name(ctx, mod_name, );
> > +   if (err < 0) {
> > +   igt_info("Could not use module %s (%s)\n", mod_name,
> > +   strerror(-err));
> > +   err = -1;
> > +   goto out;
> > +   }
> > +
> > +   if (igt_module_in_use(kmod)) {
> > +   igt_info("Module %s is in use\n", mod_name);
> > +   err = -1;
> > +   goto out;
> > +   }
> 
> Pointless (this is redundant).
Indeed.
> 
> > +
> > +   if (force) {
> > +   flags |= KMOD_REMOVE_FORCE;
> 
> Will it not be wiser (future proof) just to pass flags from the caller?
I'll pass it directly.
> 
> > +   }
> > +
> > +   err = kmod_module_remove_module(kmod, flags);
> > +   if (err < 0) {
> > +   igt_info("Could not remove module %s (%s)\n", mod_name,
> > +   strerror(-err));
> > +   err = -1;
> > +   }
> > +
> > +out:
> > +   kmod_module_unref(kmod);
> > +   kmod_unref(ctx);
> > +
> > +   return err;
> > +}
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/lspcon: Work around resume failure

[Patchwork]

== Series Details ==

Series: drm/i915/lspcon: Work around resume failure
URL   : https://patchwork.freedesktop.org/series/14280/
State : warning

== Summary ==

Series 14280v1 drm/i915/lspcon: Work around resume failure
https://patchwork.freedesktop.org/api/1.0/series/14280/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
dmesg-warn -> PASS   (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /Patchwork_2801/

102441087e47f4892b88c4f6e308e3edf89eeda1 drm-intel-nightly: 
2016y-10m-24d-14h-28m-17s UTC integration manifest
eaa672c drm/i915/lspcon: Add workaround for resuming in PCON mode
eb04604 drm/i915/lspcon: Get DDC adapter via container_of() instead of cached 
ptr
0ca993d drm/i915/dp: Read DP descriptor for eDP and LSPCON too
0144d102 drm/i915/lspcon: Fail LSPCON probe if the start of DPCD can't be read
7568e07 drm/i915/dp: Print full branch/sink descriptor
3b4f6e9 drm/i915/dp: Print only sink or branch specific OUI based on dev type
b1439bc drm/i915/dp: Remove debug dependency of DPCD SW/HW revision read
2beca1a drm/dp: Factor out helper to distinguish between branch and sink devices

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

Re: [Intel-gfx] [PATCH v2 1/8] drm/dp: Factor out helper to distinguish between branch and sink devices

[Jani Nikula]

On Mon, 24 Oct 2016, Imre Deak  wrote:
> This check is open-coded in a few places, so it makes sense to simplify
> things by having a helper for it similar to the rest of DPCD feature
> helpers.
>
> v2: (Jani)
> - Move the helper to drm_dp_helper.h.
> - Split out this change to a separate patch.
>
> Cc: Jani Nikula 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Imre Deak 

DP 1.4 has changed the name of "branch" devices, but I think this is
good.

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_dp.c | 11 ---
>  include/drm/drm_dp_helper.h |  6 ++
>  2 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f30db8f..3c2293b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1459,8 +1459,7 @@ static void intel_dp_print_hw_revision(struct intel_dp 
> *intel_dp)
>   if ((drm_debug & DRM_UT_KMS) == 0)
>   return;
>  
> - if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> -   DP_DWN_STRM_PORT_PRESENT))
> + if (!drm_dp_is_branch(intel_dp->dpcd))
>   return;
>  
>   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
> @@ -1478,8 +1477,7 @@ static void intel_dp_print_sw_revision(struct intel_dp 
> *intel_dp)
>   if ((drm_debug & DRM_UT_KMS) == 0)
>   return;
>  
> - if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> -   DP_DWN_STRM_PORT_PRESENT))
> + if (!drm_dp_is_branch(intel_dp->dpcd))
>   return;
>  
>   len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
> @@ -3615,8 +3613,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
>   if (!is_edp(intel_dp) && !intel_dp->sink_count)
>   return false;
>  
> - if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> -   DP_DWN_STRM_PORT_PRESENT))
> + if (!drm_dp_is_branch(intel_dp->dpcd))
>   return true; /* native DP sink */
>  
>   if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
> @@ -4134,7 +4131,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
>   return connector_status_connected;
>  
>   /* if there's no downstream port, we're done */
> - if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
> + if (!drm_dp_is_branch(dpcd))
>   return connector_status_connected;
>  
>   /* If we're HPD-aware, SINK_COUNT changes dynamically */
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 2a79882..55bbeb0 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -690,6 +690,12 @@ drm_dp_tps3_supported(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE])
>   dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED;
>  }
>  
> +static inline bool
> +drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + return dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT;
> +}
> +
>  /*
>   * DisplayPort AUX channel
>   */

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

[Intel-gfx] [PATCH 4/4] tests/kms_draw_crc: add support for Y tiling

[Praveen Paneri]

From: Paulo Zanoni 

This is the program that's supposed to test lib/igt_draw. We just
added Y tiling support for the library, so add the tests now.

Change-Id: Id0a805aab2d804cf82c188326a8562f0ec75c874
Signed-off-by: Paulo Zanoni 
---
 tests/kms_draw_crc.c | 55 ++--
 1 file changed, 40 insertions(+), 15 deletions(-)

diff --git a/tests/kms_draw_crc.c b/tests/kms_draw_crc.c
index cb28052..e8c1fe1 100644
--- a/tests/kms_draw_crc.c
+++ b/tests/kms_draw_crc.c
@@ -47,6 +47,13 @@ static const uint32_t formats[N_FORMATS] = {
DRM_FORMAT_XRGB2101010,
 };
 
+#define N_TILING_METHODS 3
+static const uint64_t tilings[N_TILING_METHODS] = {
+   LOCAL_DRM_FORMAT_MOD_NONE,
+   LOCAL_I915_FORMAT_MOD_X_TILED,
+   LOCAL_I915_FORMAT_MOD_Y_TILED,
+};
+
 struct base_crc {
bool set;
igt_crc_t crc;
@@ -152,6 +159,9 @@ static void draw_method_subtest(enum igt_draw_method method,
 {
igt_crc_t crc;
 
+   if (tiling == LOCAL_I915_FORMAT_MOD_Y_TILED)
+   igt_require(intel_gen(intel_get_drm_devid(drm_fd)) >= 9);
+
kmstest_unset_all_crtcs(drm_fd, drm_res);
 
/* Use IGT_DRAW_MMAP_GTT on an untiled buffer as the parameter for
@@ -214,6 +224,11 @@ static void fill_fb_subtest(void)
get_fill_crc(LOCAL_I915_FORMAT_MOD_X_TILED, );
igt_assert_crc_equal(, _crc);
 
+   if (intel_gen(intel_get_drm_devid(drm_fd)) >= 9) {
+   get_fill_crc(LOCAL_I915_FORMAT_MOD_Y_TILED, );
+   igt_assert_crc_equal(, _crc);
+   }
+
kmstest_unset_all_crtcs(drm_fd, drm_res);
igt_remove_fb(drm_fd, );
 }
@@ -272,28 +287,38 @@ static const char *format_str(int format_index)
}
 }
 
+static const char *tiling_str(int tiling_index)
+{
+   switch (tilings[tiling_index]) {
+   case LOCAL_DRM_FORMAT_MOD_NONE:
+   return "untiled";
+   case LOCAL_I915_FORMAT_MOD_X_TILED:
+   return "xtiled";
+   case LOCAL_I915_FORMAT_MOD_Y_TILED:
+   return "ytiled";
+   default:
+   igt_assert(false);
+   }
+}
+
 igt_main
 {
enum igt_draw_method method;
-   int format_index;
+   int format_idx, tiling_idx;
 
igt_fixture
setup_environment();
 
-   for (format_index = 0; format_index < N_FORMATS; format_index++) {
-   for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
-   igt_subtest_f("draw-method-%s-%s-untiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
-   draw_method_subtest(method, format_index,
-   LOCAL_DRM_FORMAT_MOD_NONE);
-   igt_subtest_f("draw-method-%s-%s-tiled",
- format_str(format_index),
- igt_draw_get_method_name(method))
-   draw_method_subtest(method, format_index,
-   LOCAL_I915_FORMAT_MOD_X_TILED);
-   }
-   }
+   for (format_idx = 0; format_idx < N_FORMATS; format_idx++) {
+   for (method = 0; method < IGT_DRAW_METHOD_COUNT; method++) {
+   for (tiling_idx = 0; tiling_idx < N_TILING_METHODS; tiling_idx++) {
+   igt_subtest_f("draw-method-%s-%s-%s",
+ format_str(format_idx),
+ igt_draw_get_method_name(method),
+ tiling_str(tiling_idx))
+   draw_method_subtest(method, format_idx,
+   tilings[tiling_idx]);
+   } } }
 
igt_subtest("fill-fb")
fill_fb_subtest();
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/4] lib/igt_draw: Add Y-tiling support

[Praveen Paneri]

This patch adds Y-tiling support for igt_draw_rect function.

Change-Id: I139e9773b7df286febe9ffa3dce358df079dac14
Signed-off-by: Praveen Paneri 
---
 lib/igt_draw.c | 148 ++---
 1 file changed, 110 insertions(+), 38 deletions(-)

diff --git a/lib/igt_draw.c b/lib/igt_draw.c
index 3afb827..29a725f 100644
--- a/lib/igt_draw.c
+++ b/lib/igt_draw.c
@@ -137,7 +137,7 @@ static int swizzle_addr(int addr, int swizzle)
 /* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
  * if you need to. */
 static int linear_x_y_to_tiled_pos(int x, int y, uint32_t stride, int swizzle,
-  int bpp)
+  int bpp, int tiling)
 {
int x_tile_size, y_tile_size;
int x_tile_n, y_tile_n, x_tile_off, y_tile_off;
@@ -146,23 +146,54 @@ static int linear_x_y_to_tiled_pos(int x, int y, uint32_t 
stride, int swizzle,
int tiled_pos, tiles_per_line;
int pixel_size = bpp / 8;
 
-   line_size = stride;
-   x_tile_size = 512;
-   y_tile_size = 8;
-   tile_size = x_tile_size * y_tile_size;
-   tiles_per_line = line_size / x_tile_size;
-
-   y_tile_n = y / y_tile_size;
-   y_tile_off = y % y_tile_size;
-
-   x_tile_n = (x * pixel_size) / x_tile_size;
-   x_tile_off = (x * pixel_size) % x_tile_size;
-
-   tile_n = y_tile_n * tiles_per_line + x_tile_n;
-   tile_off = y_tile_off * x_tile_size + x_tile_off;
-   tiled_pos = tile_n * tile_size + tile_off;
-
-   tiled_pos = swizzle_addr(tiled_pos, swizzle);
+   if (tiling == I915_TILING_X ) {
+   line_size = stride;
+   x_tile_size = 512;
+   y_tile_size = 8;
+   tile_size = x_tile_size * y_tile_size;
+   tiles_per_line = line_size / x_tile_size;
+
+   y_tile_n = y / y_tile_size;
+   y_tile_off = y % y_tile_size;
+
+   x_tile_n = (x * pixel_size) / x_tile_size;
+   x_tile_off = (x * pixel_size) % x_tile_size;
+
+   tile_n = y_tile_n * tiles_per_line + x_tile_n;
+   tile_off = y_tile_off * x_tile_size + x_tile_off;
+   tiled_pos = tile_n * tile_size + tile_off;
+
+   tiled_pos = swizzle_addr(tiled_pos, swizzle);
+   } else {
+   int x_oword_n, x_oword_off;
+   int oword_size;
+
+   /* Y-tile arrangement */
+   line_size = stride;
+   oword_size = 16;
+   x_tile_size = 128;
+   y_tile_size = 32;
+   tile_size = x_tile_size * y_tile_size;
+   tiles_per_line = line_size / x_tile_size;
+
+   y_tile_n = y / y_tile_size;
+   y_tile_off = y % y_tile_size;
+
+   x_tile_n = (x * pixel_size) / x_tile_size;
+   x_tile_off = (x * pixel_size) % x_tile_size;
+
+   tile_n = y_tile_n * tiles_per_line + x_tile_n;
+
+   /* computation inside the tile */
+   x_oword_n = x_tile_off / oword_size;
+   x_oword_off = x_tile_off % oword_size;
+   tile_off = x_oword_n * y_tile_size * oword_size
+  + y_tile_off * oword_size
+  + x_oword_off;
+   tiled_pos = tile_n * tile_size + tile_off;
+
+   tiled_pos = swizzle_addr(tiled_pos, swizzle);
+   }
 
return tiled_pos / pixel_size;
 }
@@ -170,7 +201,8 @@ static int linear_x_y_to_tiled_pos(int x, int y, uint32_t 
stride, int swizzle,
 /* It's all in "pixel coordinates", so make sure you multiply/divide by the bpp
  * if you need to. */
 static void tiled_pos_to_x_y_linear(int tiled_pos, uint32_t stride,
-   int swizzle, int bpp, int *x, int *y)
+   int swizzle, int bpp, int *x, int *y,
+   int tiling)
 {
int tile_n, tile_off, tiles_per_line, line_size;
int x_tile_off, y_tile_off;
@@ -181,22 +213,50 @@ static void tiled_pos_to_x_y_linear(int tiled_pos, 
uint32_t stride,
tiled_pos = swizzle_addr(tiled_pos, swizzle);
 
line_size = stride;
-   x_tile_size = 512;
-   y_tile_size = 8;
-   tile_size = x_tile_size * y_tile_size;
-   tiles_per_line = line_size / x_tile_size;
+   if (tiling == I915_TILING_X ) {
+   x_tile_size = 512;
+   y_tile_size = 8;
+   tile_size = x_tile_size * y_tile_size;
+   tiles_per_line = line_size / x_tile_size;
+
+   tile_n = tiled_pos / tile_size;
+   tile_off = tiled_pos % tile_size;
+
+   y_tile_off = tile_off / x_tile_size;
+   x_tile_off = tile_off % x_tile_size;
 
-   tile_n = tiled_pos / tile_size;
-   tile_off = tiled_pos % tile_size;
+   x_tile_n = tile_n % tiles_per_line;
+   y_tile_n 

[Intel-gfx] [PATCH v2 6/8] drm/i915/dp: Read DP descriptor for eDP and LSPCON too

[Imre Deak]

As for external DP sink and branch devices read and print the DP
descriptor for eDP and LSPCON devices as well to aid debugging.

v2:
- Split out this change to a separate patch. (Jani)

Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 +++-
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_lspcon.c | 2 ++
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 62c5512..043993f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1461,7 +1461,7 @@ __intel_dp_read_desc(struct intel_dp *intel_dp, struct 
intel_dp_desc *desc)
   sizeof(*desc);
 }
 
-static bool intel_dp_read_desc(struct intel_dp *intel_dp)
+bool intel_dp_read_desc(struct intel_dp *intel_dp)
 {
struct intel_dp_desc *desc = _dp->desc;
bool oui_sup = intel_dp->dpcd[DP_DOWN_STREAM_PORT_COUNT] &
@@ -3519,6 +3519,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
if (!intel_dp_read_dpcd(intel_dp))
return false;
 
+   intel_dp_read_desc(intel_dp);
+
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
dev_priv->no_aux_handshake = intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
DP_NO_AUX_HANDSHAKE_LINK_TRAINING;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ff9d2dc..a79cbad 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1462,6 +1462,7 @@ static inline unsigned int intel_dp_unused_lane_mask(int 
lane_count)
 }
 
 bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool intel_dp_read_desc(struct intel_dp *intel_dp);
 
 /* intel_dp_aux_backlight.c */
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 23b817a..c5f278b 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -136,6 +136,8 @@ bool lspcon_init(struct intel_digital_port *intel_dig_port)
return false;
}
 
+   intel_dp_read_desc(dp);
+
DRM_DEBUG_KMS("Success: LSPCON init\n");
return true;
 }
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 8/8] drm/i915/lspcon: Add workaround for resuming in PCON mode

[Imre Deak]

On my APL the LSPCON firmware resumes in PCON mode as opposed to the
expected LS mode. It also appears to be in a state where AUX DPCD reads
will succeed but return garbage recovering only after a few hundreds of
milliseconds. After the recovery time DPCD reads will result in the
correct values and things will continue to work. If I2C over AUX is
attempted during this recovery time (implying an AUX write transaction)
the firmware won't recover and will stay in this broken state.

As a workaround check if the firmware is in PCON state after resume and
if so wait until the correct DPCD values are returned. For this we
compare the branch descriptor with the one we cached during init time.
If the firmware was in the LS state, we skip the w/a and continue as
before.

v2:
- Use the DP descriptor value cached in intel_dp. (Jani)
- Get to intel_dp using container_of(), instead of a cached ptr.
  (Shashank)
- Use usleep_range() instead of msleep().

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98353
Cc: Shashank Sharma 
Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c |  2 +-
 drivers/gpu/drm/i915/intel_drv.h|  3 +++
 drivers/gpu/drm/i915/intel_lspcon.c | 37 -
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 043993f..e9be955 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1451,7 +1451,7 @@ static void intel_dp_print_rates(struct intel_dp 
*intel_dp)
DRM_DEBUG_KMS("common rates: %s\n", str);
 }
 
-static bool
+bool
 __intel_dp_read_desc(struct intel_dp *intel_dp, struct intel_dp_desc *desc)
 {
u32 base = drm_dp_is_branch(intel_dp->dpcd) ? DP_BRANCH_OUI :
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 45f55b5..f2b6c59 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -974,6 +974,7 @@ struct intel_dp {
 struct intel_lspcon {
bool active;
enum drm_lspcon_mode mode;
+   bool desc_valid;
 };
 
 struct intel_digital_port {
@@ -1461,6 +1462,8 @@ static inline unsigned int intel_dp_unused_lane_mask(int 
lane_count)
 }
 
 bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
+bool __intel_dp_read_desc(struct intel_dp *intel_dp,
+ struct intel_dp_desc *desc);
 bool intel_dp_read_desc(struct intel_dp *intel_dp);
 
 /* intel_dp_aux_backlight.c */
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 3dc5a0b..daa5234 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -97,8 +97,43 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
return true;
 }
 
+static void lspcon_resume_in_pcon_wa(struct intel_lspcon *lspcon)
+{
+   struct intel_dp *intel_dp = lspcon_to_intel_dp(lspcon);
+   unsigned long start = jiffies;
+
+   if (!lspcon->desc_valid)
+   return;
+
+   while (1) {
+   struct intel_dp_desc desc;
+
+   /*
+* The w/a only applies in PCON mode and we don't expect any
+* AUX errors.
+*/
+   if (!__intel_dp_read_desc(intel_dp, ))
+   return;
+
+   if (!memcmp(_dp->desc, , sizeof(desc))) {
+   DRM_DEBUG_KMS("LSPCON recovering in PCON mode after %u 
ms\n",
+ jiffies_to_msecs(jiffies - start));
+   return;
+   }
+
+   if (time_after(jiffies, start + msecs_to_jiffies(1000)))
+   break;
+
+   usleep_range(1, 15000);
+   }
+
+   DRM_DEBUG_KMS("LSPCON DP descriptor mismatch after resume\n");
+}
+
 void lspcon_resume(struct intel_lspcon *lspcon)
 {
+   lspcon_resume_in_pcon_wa(lspcon);
+
if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
DRM_ERROR("LSPCON resume failed\n");
else
@@ -143,7 +178,7 @@ bool lspcon_init(struct intel_digital_port *intel_dig_port)
return false;
}
 
-   intel_dp_read_desc(dp);
+   lspcon->desc_valid = intel_dp_read_desc(dp);
 
DRM_DEBUG_KMS("Success: LSPCON init\n");
return true;
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 0/8] drm/i915/lspcon: Work around resume failure

[Imre Deak]

This is v2 of [1] addressing the review comments from Jani and Shashank.
Meanwhile I also checked that the SKL-6700 machine reported in bugzilla
(see the last patch) had the same problem as the APL where I saw this
first and the workaround seems to solve the problem there too.

[1]
https://lists.freedesktop.org/archives/intel-gfx/2016-October/109295.html

Cc: Jani Nikula 
Cc: Shashank Sharma 

Imre Deak (8):
  drm/dp: Factor out helper to distinguish between branch and sink
devices
  drm/i915/dp: Remove debug dependency of DPCD SW/HW revision read
  drm/i915/dp: Print only sink or branch specific OUI based on dev type
  drm/i915/dp: Print full branch/sink descriptor
  drm/i915/lspcon: Fail LSPCON probe if the start of DPCD can't be read
  drm/i915/dp: Read DP descriptor for eDP and LSPCON too
  drm/i915/lspcon: Get DDC adapter via container_of() instead of cached
ptr
  drm/i915/lspcon: Add workaround for resuming in PCON mode

 drivers/gpu/drm/i915/intel_dp.c | 78 -
 drivers/gpu/drm/i915/intel_drv.h| 17 +++-
 drivers/gpu/drm/i915/intel_lspcon.c | 57 +--
 include/drm/drm_dp_helper.h |  6 +++
 4 files changed, 100 insertions(+), 58 deletions(-)

-- 
2.5.0

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

[Intel-gfx] [PATCH v2 1/8] drm/dp: Factor out helper to distinguish between branch and sink devices

[Imre Deak]

This check is open-coded in a few places, so it makes sense to simplify
things by having a helper for it similar to the rest of DPCD feature
helpers.

v2: (Jani)
- Move the helper to drm_dp_helper.h.
- Split out this change to a separate patch.

Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c | 11 ---
 include/drm/drm_dp_helper.h |  6 ++
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f30db8f..3c2293b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1459,8 +1459,7 @@ static void intel_dp_print_hw_revision(struct intel_dp 
*intel_dp)
if ((drm_debug & DRM_UT_KMS) == 0)
return;
 
-   if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
- DP_DWN_STRM_PORT_PRESENT))
+   if (!drm_dp_is_branch(intel_dp->dpcd))
return;
 
len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_HW_REV, , 1);
@@ -1478,8 +1477,7 @@ static void intel_dp_print_sw_revision(struct intel_dp 
*intel_dp)
if ((drm_debug & DRM_UT_KMS) == 0)
return;
 
-   if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
- DP_DWN_STRM_PORT_PRESENT))
+   if (!drm_dp_is_branch(intel_dp->dpcd))
return;
 
len = drm_dp_dpcd_read(_dp->aux, DP_BRANCH_SW_REV, , 2);
@@ -3615,8 +3613,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (!is_edp(intel_dp) && !intel_dp->sink_count)
return false;
 
-   if (!(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
- DP_DWN_STRM_PORT_PRESENT))
+   if (!drm_dp_is_branch(intel_dp->dpcd))
return true; /* native DP sink */
 
if (intel_dp->dpcd[DP_DPCD_REV] == 0x10)
@@ -4134,7 +4131,7 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
return connector_status_connected;
 
/* if there's no downstream port, we're done */
-   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+   if (!drm_dp_is_branch(dpcd))
return connector_status_connected;
 
/* If we're HPD-aware, SINK_COUNT changes dynamically */
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 2a79882..55bbeb0 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -690,6 +690,12 @@ drm_dp_tps3_supported(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
dpcd[DP_MAX_LANE_COUNT] & DP_TPS3_SUPPORTED;
 }
 
+static inline bool
+drm_dp_is_branch(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
+{
+   return dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT;
+}
+
 /*
  * DisplayPort AUX channel
  */
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 2/8] drm/i915/dp: Remove debug dependency of DPCD SW/HW revision read

[Imre Deak]

Performing DPCD AUX reads based on debug settings may introduce obscure
bugs in other places that depend on the read being done (or being not
done). To reduce the uncertainty perform the reads unconditionally.

Cc: Mika Kahola 
Suggested-by: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3c2293b..1c1a8c8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1456,9 +1456,6 @@ static void intel_dp_print_hw_revision(struct intel_dp 
*intel_dp)
uint8_t rev;
int len;
 
-   if ((drm_debug & DRM_UT_KMS) == 0)
-   return;
-
if (!drm_dp_is_branch(intel_dp->dpcd))
return;
 
@@ -1474,9 +1471,6 @@ static void intel_dp_print_sw_revision(struct intel_dp 
*intel_dp)
uint8_t rev[2];
int len;
 
-   if ((drm_debug & DRM_UT_KMS) == 0)
-   return;
-
if (!drm_dp_is_branch(intel_dp->dpcd))
return;
 
-- 
2.5.0

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

[Intel-gfx] [PATCH] drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation

[ville . syrjala]

From: Ville Syrjälä 

Pass the framebuffer size in .16 fixed point coordinates to
drm_rect_rotate() since that's what the source coordinates are as well
at this stage. We used to do this part of the computation in integer
coordinates, but that got changed when moving the computation to
happen in the check phase of the operation. Unfortunately I forgot
to shift up the fb width and height appropriately.

With the bogus size we ended up with some negative fb offset, which when
added to the vma offset caused out scanout to start at an offset earlier
than we inteded. Eg. when testing on my SKL I saw a row of incorrect
tiles at the top of my screen.

Cc: Tvrtko Ursulin 
Cc: Sivakumar Thulasimani 
Cc: drm-intel-fi...@lists.freedesktop.org
Fixes: b63a16f6cd89 ("drm/i915: Compute display surface offset in the plane 
check hook for SKL+")
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5a036999487b..c783f884f85d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2985,7 +2985,8 @@ int skl_check_plane_surface(struct intel_plane_state 
*plane_state)
/* Rotate src coordinates to match rotated GTT view */
if (drm_rotation_90_or_270(rotation))
drm_rect_rotate(_state->base.src,
-   fb->width, fb->height, DRM_ROTATE_270);
+   fb->width << 16, fb->height << 16,
+   DRM_ROTATE_270);
 
/*
 * Handle the AUX surface first since
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915/dp: add lane_count check in intel_dp_check_link_status

[Jani Nikula]

On Thu, 20 Oct 2016, Matthew Auld  wrote:
> Currently it's entirely possible to go through the link training step
> without first determining the lane_count, which is silly since we end up
> doing a bunch of aux transfers of size = 0, as highlighted by
> WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
> 'failed to update link training' message. This can be observed during
> intel_dp_long_pulse where we can do the link training step, but before
> we have had a chance to set the link params. To avoid this we add an
> extra check for the lane_count in intel_dp_check_link_status, which
> should prevent us from doing the link training step prematurely.

Now we'll just have to fix the cases where we try to do this anyway:

https://bugs.freedesktop.org/show_bug.cgi?id=98374

BR,
Jani.


>
> v2: add WARN_ON_ONCE and FIXME comment (Ville)
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97344
> Cc: Ville Syrjälä 
> Cc: Mika Kahola 
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 88f3b74..fb760ad 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4032,6 +4032,11 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
>   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
>   return;
>  
> + /* FIXME: we need to synchronize this sort of stuff with hardware
> +  * readout */
> + if (WARN_ON_ONCE(!intel_dp->lane_count))
> + return;
> +
>   /* if link training is requested we should perform it always */
>   if ((intel_dp->compliance_test_type == DP_TEST_LINK_TRAINING) ||
>   (!drm_dp_channel_eq_ok(link_status, intel_dp->lane_count))) {

-- 
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: [Intel-gfx] [PATCH] drm/i915: remove AGP dependency from DRM_I915 kconfig help text

[Jani Nikula]

On Mon, 24 Oct 2016, Ville Syrjälä  wrote:
> On Mon, Oct 24, 2016 at 10:52:59AM +0200, Daniel Vetter wrote:
>> On Fri, Oct 21, 2016 at 12:14:17PM +0300, Jani Nikula wrote:
>> > We haven't required AGP since 3e99a6b95614 ("drm/i915: Stop depending
>> > upon CONFIG_AGP_INTEL"). Split/rearrange the paragraphs a bit while at
>> > it.
>> > 
>> > Signed-off-by: Jani Nikula 
>> 
>> Reviewed-by: Daniel Vetter 
>> 
>> > ---
>> >  drivers/gpu/drm/i915/Kconfig | 11 ++-
>> >  1 file changed, 6 insertions(+), 5 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> > index 1c1b19ccb92f..45a5eb71e8e6 100644
>> > --- a/drivers/gpu/drm/i915/Kconfig
>> > +++ b/drivers/gpu/drm/i915/Kconfig
>> > @@ -24,16 +24,17 @@ config DRM_I915
>> >  including 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G,
>> >  G35, G41, G43, G45 chipsets and Celeron, Pentium, Core i3,
>> >  Core i5, Core i7 as well as Atom CPUs with integrated graphics.
>> 
>> Hm, nowadays it's called Intel HD graphics. Maybe we should mention that?
>> Feel free to add that.
>
> HD graphics seems to be listed before the chipset names. But we do lack
> a mention of the "Exterme Graphics" :) moniker that was used for gen2 IIRC.

Pushed as-is, thanks for the review.

BR,
Jani.

>
>> 
>> > -If M is selected, the module will be called i915.  AGP support
>> > -is required for this driver to work. This driver is used by
>> > -the Intel driver in X.org 6.8 and XFree86 4.4 and above. It
>> > -replaces the older i830 module that supported a subset of the
>> > -hardware in older X.org releases.
>> > +
>> > +This driver is used by the Intel driver in X.org 6.8 and
>> > +XFree86 4.4 and above. It replaces the older i830 module that
>> > +supported a subset of the hardware in older X.org releases.
>> >  
>> >  Note that the older i810/i815 chipsets require the use of the
>> >  i810 driver instead, and the Atom z5xx series has an entirely
>> >  different implementation.
>> >  
>> > +If "M" is selected, the module will be called i915.
>> > +
>> >  config DRM_I915_PRELIMINARY_HW_SUPPORT
>> >bool "Enable preliminary support for prerelease Intel hardware by 
>> > default"
>> >depends on DRM_I915
>> > -- 
>> > 2.1.4
>> > 
>> 
>> -- 
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [Regression report] Weekly regression report WW43

[Jairo Miramontes]

Total regressions: 46

This week regressions:4
+---+---+++
| BugId | Summary   | Created on | 
Bisect |

+---+---+++
| 98402 | [HSW] [regression] 4.9-rc1 shows corruption w | 2016-10-23 | 
No |
| 98362 | [KBL] [Regression] kms_flip plain-flip-fb-rec | 2016-10-20 | 
No |
| 98289 | [BDW] kms_flip / vblank-vs-suspend-interrupti | 2016-10-17 | 
No |
| 98290 | [BDW] kms_frontbuffer_tracking fbc-suspend fa | 2016-10-17 | 
No |

+---+---+++

Previous regressions:42
+---+---+++
| BugId | Summary   | Created on | 
Bisect |

+---+---+++
| 98213 | [skl] fbc clobbers stolen | 2016-10-12 | 
Yes|
| 98211 | i915 / drm crash when undocking from DP monit | 2016-10-12 | 
No |
| 98036 | [BYT] constant screen flicker and rendering e | 2016-10-03 | 
No |
| 97994 | [REGRESS] [BISECT] [i915] Monitor resolution  | 2016-09-30 | 
Yes|
| 97918 | [bdw regression 4.8] Severe graphics regressi | 2016-09-25 | 
No |
| 97878 | [SKL][REGRESSION][BISECTED] Dropped frames an | 2016-09-20 | 
Yes|
| 97867 | [HSW][Regression] 4.6.7 and beyond causes scr | 2016-09-19 | 
No |
| 97666 | Kernel "NULL pointer dereference" with MST mo | 2016-09-08 | 
Yes|
| 97450 | [SKL] [regression] Random display flickering  | 2016-08-23 | 
No |
| 97017 | [SKL GT3e guc bisected] ~10% performance drop | 2016-07-21 | 
Yes|
| 96938 | [HSW modeset regression] i915/drm locks up wh | 2016-07-15 | 
No |
| 96916 | Regression: screen flashes with PSR enabled   | 2016-07-13 | 
No |
| 96800 | [regression] The drm-intel-nightly branch no  | 2016-07-04 | 
No |
| 96736 | kernel 4.6 regression: PSR causes screen to f | 2016-06-29 | 
Yes|
| 96704 | kernel 4.6 regression: PSR on Haswell causes  | 2016-06-28 | 
Yes|
| 96645 | [regression 4.7] [BISECT]Low package c-states | 2016-06-22 | 
Yes|
| 96428 | [IVB bisected] [drm:intel_dp_aux_ch] *ERROR*  | 2016-06-07 | 
Yes|
| 95736 | [IVB bisected] *ERROR* uncleared fifo underru | 2016-05-24 | 
Yes|
| 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode | 2016-04-28 | 
No |
| 95097 | [hdmi regression ilk] no signal to TV | 2016-04-24 | 
No |
| 94590 | [KBL] igt/kms_fbcon_fbt/psr-suspend regressio | 2016-03-17 | 
No |
| 94430 | [HSW+nvidia] regression: display becomes "dis | 2016-03-07 | 
No |
| 94337 | Linux 4.5 regression: FIFO underruns on Skyla | 2016-02-29 | 
No |
| 93971 | video framerate performance regression with U | 2016-02-02 | 
Yes|
| 93802 | [IVB bisected] switching to tty1 causes fifo  | 2016-01-20 | 
Yes|
| 93782 | [i9xx TV][BISECT] vblank wait timeout on crtc | 2016-01-19 | 
Yes|
| 93486 | [HP Compaq dc7800 Small Form Factor PC][REGRE | 2015-12-23 | 
No |
| 93393 | Regression for Skylake modesetting in kernel  | 2015-12-16 | 
No |
| 93263 | 945GM regression since 4.3| 2015-12-05 | 
No |
| 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will  | 2015-10-10 | 
Yes|
| 92237 | [SNB]Horrible noise (audio) via DisplayPort [ | 2015-10-02 | 
No |
| 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 | 
Yes|
| 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 | 
Yes|
| 91959 | [865g Linux regression] GPU hang and disabled | 2015-09-10 | 
No |
| 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 | 
Yes|
| 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 | 
Yes|
| 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 | 
Yes|
| 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 | 
No |
| 89629 | [i965 regression]igt/kms_rotation_crc/sprite- | 2015-03-18 | 
No |
| 87726 | [BDW Bisected] OglDrvCtx performance reduced  | 2014-12-26 | 
Yes|
| 87725 | [BDW Bisected] OglBatch7 performance reduced  | 2014-12-26 | 
Yes|
| 87131 | [PNV regression] igt/gem_exec_lut_handle take | 2014-12-09 | 
No |

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Move user fault tracking to a separate list

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/5] drm/i915: Move user fault tracking to a 
separate list
URL   : https://patchwork.freedesktop.org/series/14261/
State : success

== Summary ==

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


fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /Patchwork_2799/

4c02932868ae2c9912cfe09d4c877a141fccbe8f drm-intel-nightly: 
2016y-10m-24d-11h-53m-56s UTC integration manifest
a482955 drm/i915: Move fence cancellation to runtime suspend
e099188 drm/i915: Remove RPM sequence checking
7423e6b drm/i915: Remove superfluous locking around userfault_list
5718e0c drm/i915: Use RPM as the barrier for controlling user mmap access
284c3d0 drm/i915: Move user fault tracking to a separate list

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid: Only print the bad edid when aborting (rev3)

[Saarinen, Jani]

> == Summary ==
> 
> Series 13747v3 drm/edid: Only print the bad edid when aborting
> https://patchwork.freedesktop.org/api/1.0/series/13747/revisions/3/mbox/
> 
> Test drv_module_reload_basic:
> dmesg-warn -> PASS   (fi-skl-6700hq)
> Test gem_exec_suspend:
> Subgroup basic-s3:
> pass   -> DMESG-WARN (fi-skl-6700hq)
https://bugs.freedesktop.org/show_bug.cgi?id=98353
> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-skl-6700hq)
https://bugs.freedesktop.org/show_bug.cgi?id=98353
> Subgroup suspend-read-crc-pipe-b:
> pass   -> DMESG-WARN (fi-skl-6700hq)
https://bugs.freedesktop.org/show_bug.cgi?id=98353
> Subgroup suspend-read-crc-pipe-c:
> pass   -> DMESG-WARN (fi-skl-6700hq)
https://bugs.freedesktop.org/show_bug.cgi?id=98353
Waiting for Imre's patch to fix/rework these.
 
> fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23
> 
> Results at /Patchwork_2798/
> 
> 4c02932868ae2c9912cfe09d4c877a141fccbe8f drm-intel-nightly: 2016y-10m-
> 24d-11h-53m-56s UTC integration manifest
> 868a463 drm/edid: Only print the bad edid when aborting
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


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

Re: [Intel-gfx] i915 4.8.3: cdclk < crtc_clock

[Tvrtko Ursulin]

Hi Daniel,

On 24/10/2016 12:54, Daniel J Blueman wrote:

Hi Tvrtko,

I'm seeing this warning [1] on a Skylake Dell XPS 15 9550 with the
internal 3840x2160 panel with 4.8.4.

Let me know if you're interested in any debug.


I suggest best to add your logs to 
https://bugs.freedesktop.org/show_bug.cgi?id=98214 and go from there. 
Unfortunately I am not too knowledgable on the display side of things, 
just happened to add this warning since I was hitting it myself under 
some circumstances.


Regards,

Tvrtko



Many thanks!
  Daniel

-- [1]

[ 2236.760626] WARNING: CPU: 1 PID: 1150 at
/home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:14178
skl_max_scale.part.120+0x75/0x80 [i915]
[ 2236.760627] WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
[ 2236.760628] Modules linked in:
[ 2236.760629]  bnep ax88179_178a usbnet mii ebtable_filter ebtables
iptable_mangle xt_DSCP hid_multitouch snd_hda_codec_hdmi dell_led
snd_hda_codec_realtek snd_hda_codec_generic i2c_designware_platform
i2c_designware_core dell_wmi snd_hda_intel snd_hda_codec snd_hda_core
dell_laptop snd_hwdep dell_smbios intel_rapl dcdbas
x86_pkg_temp_thermal intel_powerclamp nls_iso8859_1 coretemp
crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel aesni_intel
snd_seq_midi snd_seq_midi_event aes_x86_64 lrw brcmfmac glue_helper
ablk_helper snd_rawmidi cryptd uvcvideo intel_cstate brcmutil
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 intel_rapl_perf
snd_seq videobuf2_core cfg80211 videodev input_leds joydev
snd_seq_device media snd_timer rtsx_pci_ms snd memstick serio_raw
soundcore idma64 virt_dma mei_me
[ 2236.760673]  shpchp processor_thermal_device mei intel_soc_dts_iosf
intel_lpss_pci hci_uart btbcm btqca btintel bluetooth int3403_thermal
intel_lpss_acpi dell_smo8800 intel_lpss int3402_thermal
int3400_thermal intel_hid int340x_thermal_zone acpi_als acpi_pad
acpi_thermal_rel sparse_keymap kfifo_buf mac_hid industrialio
kvm_intel kvm irqbypass xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6
ipt_REJECT nf_reject_ipv4 xt_limit xt_tcpudp xt_addrtype
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter
ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp
nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables
parport_pc ppdev lp parport autofs4 rtsx_pci_sdmmc nouveau i915
mxm_wmi ttm i2c_algo_bit drm_kms_helper psmouse syscopyarea
sysfillrect sysimgblt fb_sys_fops
[ 2236.760716]  nvme nvme_core drm rtsx_pci i2c_hid hid wmi
pinctrl_sunrisepoint video pinctrl_intel fjes
[ 2236.760726] CPU: 1 PID: 1150 Comm: Xorg Not tainted
4.8.4-040804-generic #201610220733
[ 2236.760727] Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS
01.02.00 04/07/2016
[ 2236.760729]  0286 66463e07 8ed2e4f2b930
afe12f12
[ 2236.760733]  8ed2e4f2b980  8ed2e4f2b970
afa82d9b
[ 2236.760736]  376200b0 8ed2e78896c0 8ed2e2fd5800
8ed2e36e5000
[ 2236.760739] Call Trace:
[ 2236.760744]  [] dump_stack+0x63/0x81
[ 2236.760748]  [] __warn+0xcb/0xf0
[ 2236.760751]  [] warn_slowpath_fmt+0x5f/0x80
[ 2236.760763]  [] ?
drm_atomic_helper_normalize_zpos+0x264/0x300 [drm_kms_helper]
[ 2236.760799]  [] skl_max_scale.part.120+0x75/0x80 [i915]
[ 2236.760830]  [] intel_check_primary_plane+0xc6/0xe0 [i915]
[ 2236.760841]  [] ?
drm_atomic_helper_normalize_zpos+0x264/0x300 [drm_kms_helper]
[ 2236.760875]  [] intel_plane_atomic_check+0x132/0x1f0 [i915]
[ 2236.760885]  []
drm_atomic_helper_check_planes+0x84/0x200 [drm_kms_helper]
[ 2236.760926]  [] intel_atomic_check+0x155/0x760 [i915]
[ 2236.760952]  [] drm_atomic_check_only+0x187/0x610 [drm]
[ 2236.760972]  [] drm_atomic_commit+0x17/0x60 [drm]
[ 2236.760983]  []
drm_atomic_helper_disable_plane+0xac/0xf0 [drm_kms_helper]
[ 2236.761003]  [] __setplane_internal+0x17b/0x270 [drm]
[ 2236.761006]  [] ? __wake_up_sync_key+0x50/0x60
[ 2236.761024]  [] drm_mode_cursor_universal+0x139/0x240 [drm]
[ 2236.761046]  [] drm_mode_cursor_common+0x7e/0x180 [drm]
[ 2236.761070]  [] drm_mode_cursor_ioctl+0x50/0x70 [drm]
[ 2236.761091]  [] drm_ioctl+0x200/0x4f0 [drm]
[ 2236.761115]  [] ? drm_mode_setcrtc+0x580/0x580 [drm]
[ 2236.761120]  [] ? __vfs_read+0x37/0x150
[ 2236.761124]  [] do_vfs_ioctl+0xa3/0x600
[ 2236.761129]  [] ? recalc_sigpending+0x1b/0x50
[ 2236.761134]  [] ? __set_task_blocked+0x41/0xa0
[ 2236.761138]  [] SyS_ioctl+0x79/0x90
[ 2236.761140]  [] ? SyS_rt_sigprocmask+0x8e/0xc0
[ 2236.761145]  [] entry_SYSCALL_64_fastpath+0x1e/0xa8
[ 2236.761148] ---[ end trace 0a69ec658ca26029 ]---
[ 2290.023659] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
update failure on pipe A (start=3183 end=3184) time 560 us, min 2146,
max 2159, scanline start 2120, end 2189
[ 3356.918317] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
update failure on pipe A (start=67193 end=67194) time 719 us, min
2146, max 2159, scanline start 2107, end 2197
[ 5485.971871] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
update failure on pipe A 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/edid: Only print the bad edid when aborting (rev3)

[Patchwork]

== Series Details ==

Series: drm/edid: Only print the bad edid when aborting (rev3)
URL   : https://patchwork.freedesktop.org/series/13747/
State : warning

== Summary ==

Series 13747v3 drm/edid: Only print the bad edid when aborting
https://patchwork.freedesktop.org/api/1.0/series/13747/revisions/3/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6700hq)
Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-WARN (fi-skl-6700hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-b:
pass   -> DMESG-WARN (fi-skl-6700hq)
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-skl-6700hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:215  dwarn:0   dfail:0   fail:0   skip:31 
fi-byt-n2820 total:246  pass:211  dwarn:0   dfail:0   fail:0   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:185  dwarn:0   dfail:0   fail:1   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:219  dwarn:4   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-skl-6770hqtotal:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /Patchwork_2798/

4c02932868ae2c9912cfe09d4c877a141fccbe8f drm-intel-nightly: 
2016y-10m-24d-11h-53m-56s UTC integration manifest
868a463 drm/edid: Only print the bad edid when aborting

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

[Intel-gfx] [CI 4/5] drm/i915: Remove RPM sequence checking

[Chris Wilson]

We only used the RPM sequence checking inside the lowlevel GTT
accessors, when we had to rely on callers taking the wakeref on our
behalf. Now that we take the RPM wakeref inside the GTT management
routines themselves, we can forgo the sanitycheck of the callers.

Signed-off-by: Chris Wilson 
Cc: Imre Deak 
Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h |  1 -
 drivers/gpu/drm/i915/i915_gem_gtt.c | 55 +
 drivers/gpu/drm/i915/intel_drv.h| 17 --
 drivers/gpu/drm/i915/intel_pm.c |  1 -
 drivers/gpu/drm/i915/intel_runtime_pm.c |  3 +-
 5 files changed, 2 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ba87a852c0db..ad1a1fbc5864 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1687,7 +1687,6 @@ struct skl_wm_level {
  */
 struct i915_runtime_pm {
atomic_t wakeref_count;
-   atomic_t atomic_seq;
bool suspended;
bool irqs_enabled;
 };
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 33036359c170..947d5ad51fb7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2395,16 +2395,11 @@ static void gen8_ggtt_insert_page(struct 
i915_address_space *vm,
gen8_pte_t __iomem *pte =
(gen8_pte_t __iomem *)dev_priv->ggtt.gsm +
(offset >> PAGE_SHIFT);
-   int rpm_atomic_seq;
-
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
 
gen8_set_pte(pte, gen8_pte_encode(addr, level));
 
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
-
-   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
 static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
@@ -2418,11 +2413,8 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
gen8_pte_t __iomem *gtt_entries;
gen8_pte_t gtt_entry;
dma_addr_t addr;
-   int rpm_atomic_seq;
int i = 0;
 
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
-
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm + (start >> PAGE_SHIFT);
 
for_each_sgt_dma(addr, sgt_iter, st) {
@@ -2446,8 +2438,6 @@ static void gen8_ggtt_insert_entries(struct 
i915_address_space *vm,
 */
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
-
-   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
 struct insert_entries {
@@ -2486,16 +2476,11 @@ static void gen6_ggtt_insert_page(struct 
i915_address_space *vm,
gen6_pte_t __iomem *pte =
(gen6_pte_t __iomem *)dev_priv->ggtt.gsm +
(offset >> PAGE_SHIFT);
-   int rpm_atomic_seq;
-
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
 
iowrite32(vm->pte_encode(addr, level, flags), pte);
 
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
-
-   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
 /*
@@ -2515,11 +2500,8 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
gen6_pte_t __iomem *gtt_entries;
gen6_pte_t gtt_entry;
dma_addr_t addr;
-   int rpm_atomic_seq;
int i = 0;
 
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
-
gtt_entries = (gen6_pte_t __iomem *)ggtt->gsm + (start >> PAGE_SHIFT);
 
for_each_sgt_dma(addr, sgt_iter, st) {
@@ -2542,8 +2524,6 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
 */
I915_WRITE(GFX_FLSH_CNTL_GEN6, GFX_FLSH_CNTL_EN);
POSTING_READ(GFX_FLSH_CNTL_GEN6);
-
-   assert_rpm_atomic_end(dev_priv, rpm_atomic_seq);
 }
 
 static void nop_clear_range(struct i915_address_space *vm,
@@ -2554,7 +2534,6 @@ static void nop_clear_range(struct i915_address_space *vm,
 static void gen8_ggtt_clear_range(struct i915_address_space *vm,
  uint64_t start, uint64_t length)
 {
-   struct drm_i915_private *dev_priv = to_i915(vm->dev);
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
unsigned first_entry = start >> PAGE_SHIFT;
unsigned num_entries = length >> PAGE_SHIFT;
@@ -2562,9 +2541,6 @@ static void gen8_ggtt_clear_range(struct 
i915_address_space *vm,
(gen8_pte_t __iomem *)ggtt->gsm + first_entry;
const int max_entries = ggtt_total_entries(ggtt) - first_entry;
int i;
-   int rpm_atomic_seq;
-
-   rpm_atomic_seq = assert_rpm_atomic_begin(dev_priv);
 
if (WARN(num_entries > max_entries,
 "First entry = %d; Num entries = %d (max=%d)\n",
@@ -2576,15 +2552,12 @@ static void gen8_ggtt_clear_range(struct 
i915_address_space *vm,
for (i = 0; i < num_entries; i++)

[Intel-gfx] [CI 3/5] drm/i915: Remove superfluous locking around userfault_list

[Chris Wilson]

Now that we have reduced the access to the list to either (a) under the
struct_mutex whilst holding the RPM wakeref (so that concurrent writers to
the list are serialised by struct_mutex) and (b) under the atomic
runtime suspend (which cannot run concurrently with any other accessor due
to the atomic nature of the runtime suspend) we can remove the extra
locking around the list itself.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h |  3 ---
 drivers/gpu/drm/i915/i915_gem.c | 33 -
 2 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a53172e7790f..ba87a852c0db 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1361,9 +1361,6 @@ struct i915_gem_mm {
 */
struct list_head unbound_list;
 
-   /** Protects access to the userfault_list */
-   spinlock_t userfault_lock;
-
/** List of all objects in gtt_space, currently mmaped by userspace.
 * All objects within this list must also be on bound_list.
 */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 744939f652fc..64a88ce4b3c6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1842,10 +1842,8 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
vm_fault *vmf)
 
/* Mark as being mmapped into userspace for later revocation */
assert_rpm_wakelock_held(dev_priv);
-   spin_lock(_priv->mm.userfault_lock);
if (list_empty(>userfault_link))
list_add(>userfault_link, _priv->mm.userfault_list);
-   spin_unlock(_priv->mm.userfault_lock);
 
/* Finally, remap it using the new GTT offset */
ret = remap_io_mapping(area,
@@ -1922,7 +1920,6 @@ void
 i915_gem_release_mmap(struct drm_i915_gem_object *obj)
 {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   bool zap = false;
 
/* Serialisation between user GTT access and our code depends upon
 * revoking the CPU's PTE whilst the mutex is held. The next user
@@ -1935,15 +1932,10 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
lockdep_assert_held(>drm.struct_mutex);
intel_runtime_pm_get(i915);
 
-   spin_lock(>mm.userfault_lock);
-   if (!list_empty(>userfault_link)) {
-   list_del_init(>userfault_link);
-   zap = true;
-   }
-   spin_unlock(>mm.userfault_lock);
-   if (!zap)
+   if (list_empty(>userfault_link))
goto out;
 
+   list_del_init(>userfault_link);
drm_vma_node_unmap(>base.vma_node,
   obj->base.dev->anon_inode->i_mapping);
 
@@ -1963,21 +1955,21 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
 void
 i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv)
 {
-   struct drm_i915_gem_object *obj;
+   struct drm_i915_gem_object *obj, *on;
 
-   spin_lock(_priv->mm.userfault_lock);
-   while ((obj = list_first_entry_or_null(_priv->mm.userfault_list,
-  struct drm_i915_gem_object,
-  userfault_link))) {
-   list_del_init(>userfault_link);
-   spin_unlock(_priv->mm.userfault_lock);
+   /*
+* Only called during RPM suspend. All users of the userfault_list
+* must be holding an RPM wakeref to ensure that this can not
+* run concurrently with themselves (and use the struct_mutex for
+* protection between themselves).
+*/
 
+   list_for_each_entry_safe(obj, on,
+_priv->mm.userfault_list, userfault_link) {
+   list_del_init(>userfault_link);
drm_vma_node_unmap(>base.vma_node,
   obj->base.dev->anon_inode->i_mapping);
-
-   spin_lock(_priv->mm.userfault_lock);
}
-   spin_unlock(_priv->mm.userfault_lock);
 }
 
 /**
@@ -4547,7 +4539,6 @@ int i915_gem_init(struct drm_device *dev)
int ret;
 
mutex_lock(>struct_mutex);
-   spin_lock_init(_priv->mm.userfault_lock);
 
if (!i915.enable_execlists) {
dev_priv->gt.resume = intel_legacy_submission_resume;
-- 
2.10.1

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

[Intel-gfx] [CI 1/5] drm/i915: Move user fault tracking to a separate list

[Chris Wilson]

We want to decouple RPM and struct_mutex, but currently RPM has to walk
the list of bound objects and remove userspace mmapping before we
suspend (otherwise userspace may continue to access the GTT whilst it is
powered down). This currently requires the struct_mutex to walk the
bound_list, but if we move that to a separate list and lock we can take
the first step towards removing the struct_mutex.

v2: Split runtime suspend unmapping vs regular unmapping, to make the
locking (and barriers) clearer. Add the object to the userfault_list
prior to inserting the first PTE, the race between add/revoke depends
upon struct_mutex for regular unmappings and rpm for runtime-suspend.

Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter  #v1
---
 drivers/gpu/drm/i915/i915_debugfs.c   |  2 +-
 drivers/gpu/drm/i915/i915_drv.h   | 20 +++--
 drivers/gpu/drm/i915/i915_gem.c   | 42 +++
 drivers/gpu/drm/i915/i915_gem_evict.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_fence.c |  2 +-
 5 files changed, 49 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 20638d22bbad..1b402eebd3d9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -107,7 +107,7 @@ static char get_tiling_flag(struct drm_i915_gem_object *obj)
 
 static char get_global_flag(struct drm_i915_gem_object *obj)
 {
-   return obj->fault_mappable ? 'g' : ' ';
+   return !list_empty(>userfault_link) ? 'g' : ' ';
 }
 
 static char get_pin_mapped_flag(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f022f438e5b9..a53172e7790f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1361,6 +1361,14 @@ struct i915_gem_mm {
 */
struct list_head unbound_list;
 
+   /** Protects access to the userfault_list */
+   spinlock_t userfault_lock;
+
+   /** List of all objects in gtt_space, currently mmaped by userspace.
+* All objects within this list must also be on bound_list.
+*/
+   struct list_head userfault_list;
+
/** Usable portion of the GTT for GEM */
unsigned long stolen_base; /* limited to low memory (32-bit) */
 
@@ -2205,6 +2213,11 @@ struct drm_i915_gem_object {
struct drm_mm_node *stolen;
struct list_head global_list;
 
+   /**
+* Whether the object is currently in the GGTT mmap.
+*/
+   struct list_head userfault_link;
+
/** Used in execbuf to temporarily hold a ref */
struct list_head obj_exec_link;
 
@@ -2232,13 +2245,6 @@ struct drm_i915_gem_object {
 */
unsigned int madv:2;
 
-   /**
-* Whether the current gtt mapping needs to be mappable (and isn't just
-* mappable by accident). Track pin and fault separate for a more
-* accurate mappable working set.
-*/
-   unsigned int fault_mappable:1;
-
/*
 * Is the object to be mapped as read-only to the GPU
 * Only honoured if hardware has relevant pte bit
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8ed8e24025ac..b7a6bcd15bc9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1839,16 +1839,19 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
vm_fault *vmf)
if (ret)
goto err_unpin;
 
+   /* Mark as being mmapped into userspace for later revocation */
+   spin_lock(_priv->mm.userfault_lock);
+   if (list_empty(>userfault_link))
+   list_add(>userfault_link, _priv->mm.userfault_list);
+   spin_unlock(_priv->mm.userfault_lock);
+
/* Finally, remap it using the new GTT offset */
ret = remap_io_mapping(area,
   area->vm_start + 
(vma->ggtt_view.params.partial.offset << PAGE_SHIFT),
   (ggtt->mappable_base + vma->node.start) >> 
PAGE_SHIFT,
   min_t(u64, vma->size, area->vm_end - 
area->vm_start),
   >mappable);
-   if (ret)
-   goto err_unpin;
 
-   obj->fault_mappable = true;
 err_unpin:
__i915_vma_unpin(vma);
 err_unlock:
@@ -1916,13 +1919,22 @@ int i915_gem_fault(struct vm_area_struct *area, struct 
vm_fault *vmf)
 void
 i915_gem_release_mmap(struct drm_i915_gem_object *obj)
 {
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   bool zap = false;
+
/* Serialisation between user GTT access and our code depends upon
 * revoking the CPU's PTE whilst the mutex is held. The next user
 * pagefault then has to wait until we release the mutex.
 */
-   lockdep_assert_held(>base.dev->struct_mutex);
+   lockdep_assert_held(>drm.struct_mutex);
 
-   if 

[Intel-gfx] [CI 5/5] drm/i915: Move fence cancellation to runtime suspend

[Chris Wilson]

At the moment, we have dependency on the RPM as a barrier itself in both
i915_gem_release_all_mmaps() and i915_gem_restore_fences().
i915_gem_restore_fences() is also called along !runtime pm paths, but we
can move the markup of lost fences alongside releasing the mmaps into a
common i915_gem_runtime_suspend(). This has the advantage of locating
all the tricky barrier dependencies into one location.

v2: Just mark the fence as invalid (fence->dirty) so that upon waking we
will be sure to clear the fence after use, or restore it to the correct
value before use. This makes sure that if the fence is left intact
across the sleep, we do not leave it pointing to a region of GTT for the
next unsuspecting user.

Suggested-by: Daniel Vetter 
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Imre Deak 
Reviewed-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c   |  6 ++
 drivers/gpu/drm/i915/i915_drv.h   |  3 ++-
 drivers/gpu/drm/i915/i915_gem.c   | 21 +++--
 drivers/gpu/drm/i915/i915_gem_fence.c | 12 +---
 4 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 885d33f341f3..99e4e044e958 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2278,10 +2278,8 @@ static int vlv_resume_prepare(struct drm_i915_private 
*dev_priv,
 
vlv_check_no_gt_access(dev_priv);
 
-   if (rpm_resume) {
+   if (rpm_resume)
intel_init_clock_gating(dev);
-   i915_gem_restore_fences(dev);
-   }
 
return ret;
 }
@@ -2307,7 +2305,7 @@ static int intel_runtime_suspend(struct device *kdev)
 * We are safe here against re-faults, since the fault handler takes
 * an RPM reference.
 */
-   i915_gem_release_all_mmaps(dev_priv);
+   i915_gem_runtime_suspend(dev_priv);
 
intel_guc_suspend(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ad1a1fbc5864..dd3acabb7edb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3130,9 +3130,10 @@ void i915_vma_destroy(struct i915_vma *vma);
 
 int i915_gem_object_unbind(struct drm_i915_gem_object *obj);
 int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
-void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
 void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
 
+void i915_gem_runtime_suspend(struct drm_i915_private *dev_priv);
+
 int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
 
 static inline int __sg_page_count(struct scatterlist *sg)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 64a88ce4b3c6..0e26ee96856e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1952,10 +1952,10 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
intel_runtime_pm_put(i915);
 }
 
-void
-i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv)
+void i915_gem_runtime_suspend(struct drm_i915_private *dev_priv)
 {
struct drm_i915_gem_object *obj, *on;
+   int i;
 
/*
 * Only called during RPM suspend. All users of the userfault_list
@@ -1970,6 +1970,23 @@ i915_gem_release_all_mmaps(struct drm_i915_private 
*dev_priv)
drm_vma_node_unmap(>base.vma_node,
   obj->base.dev->anon_inode->i_mapping);
}
+
+   /* The fence will be lost when the device powers down. If any were
+* in use by hardware (i.e. they are pinned), we should not be powering
+* down! All other fences will be reacquired by the user upon waking.
+*/
+   for (i = 0; i < dev_priv->num_fence_regs; i++) {
+   struct drm_i915_fence_reg *reg = _priv->fence_regs[i];
+
+   if (WARN_ON(reg->pin_count))
+   continue;
+
+   if (!reg->vma)
+   continue;
+
+   GEM_BUG_ON(!list_empty(>vma->obj->userfault_link));
+   reg->dirty = true;
+   }
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c 
b/drivers/gpu/drm/i915/i915_gem_fence.c
index 67013179b8ed..3c5a8082cac3 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence.c
@@ -343,6 +343,9 @@ i915_vma_get_fence(struct i915_vma *vma)
struct drm_i915_fence_reg *fence;
struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
 
+   /* Note that we revoke fences on runtime suspend. Therefore the user
+* must keep the device awake whilst using the fence.
+*/
assert_rpm_wakelock_held(to_i915(vma->vm->dev));
 
/* Just update our place in the LRU if our fence is getting reused. */
@@ -368,19 +371,14 @@ 

[Intel-gfx] [CI 2/5] drm/i915: Use RPM as the barrier for controlling user mmap access

[Chris Wilson]

We can remove the false coupling between RPM and struct mutex by the
observation that we can use the RPM wakeref as the barrier around user
mmap access. That is as we tear down the user's PTE atomically from
within rpm suspend and then to fault in new PTE requires the rpm
wakeref, means that no user access is possible through those PTE without
RPM being awake. Having made that observation, we can then remove the
presumption of having to take rpm outside of struct_mutex and so allow
fine grained acquisition of a wakeref around hw access rather than
having to remember to acquire the wakeref early on.

v2: Rejig placement of the new intel_runtime_pm_get() to be as tight
as possible around the GTT pread/pwrite.

Signed-off-by: Chris Wilson 
Cc: Imre Deak 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c| 56 --
 drivers/gpu/drm/i915/i915_drv.c| 19 
 drivers/gpu/drm/i915/i915_gem.c| 42 +
 drivers/gpu/drm/i915/i915_gem_gtt.c| 17 ---
 drivers/gpu/drm/i915/i915_gem_tiling.c |  4 ---
 5 files changed, 69 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1b402eebd3d9..88c9d222a7e6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -743,17 +743,32 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(VLV_IIR_RW));
seq_printf(m, "Display IMR:\t%08x\n",
   I915_READ(VLV_IMR));
-   for_each_pipe(dev_priv, pipe)
+   for_each_pipe(dev_priv, pipe) {
+   enum intel_display_power_domain power_domain;
+
+   power_domain = POWER_DOMAIN_PIPE(pipe);
+   if (!intel_display_power_get_if_enabled(dev_priv,
+   power_domain)) {
+   seq_printf(m, "Pipe %c power disabled\n",
+  pipe_name(pipe));
+   continue;
+   }
+
seq_printf(m, "Pipe %c stat:\t%08x\n",
   pipe_name(pipe),
   I915_READ(PIPESTAT(pipe)));
 
+   intel_display_power_put(dev_priv, power_domain);
+   }
+
+   intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
seq_printf(m, "Port hotplug:\t%08x\n",
   I915_READ(PORT_HOTPLUG_EN));
seq_printf(m, "DPFLIPSTAT:\t%08x\n",
   I915_READ(VLV_DPFLIPSTAT));
seq_printf(m, "DPINVGTT:\t%08x\n",
   I915_READ(DPINVGTT));
+   intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
 
for (i = 0; i < 4; i++) {
seq_printf(m, "GT Interrupt IMR %d:\t%08x\n",
@@ -1396,14 +1411,9 @@ static int i915_hangcheck_info(struct seq_file *m, void 
*unused)
 static int ironlake_drpc_info(struct seq_file *m)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_device *dev = _priv->drm;
u32 rgvmodectl, rstdbyctl;
u16 crstandvid;
-   int ret;
 
-   ret = mutex_lock_interruptible(>struct_mutex);
-   if (ret)
-   return ret;
intel_runtime_pm_get(dev_priv);
 
rgvmodectl = I915_READ(MEMMODECTL);
@@ -1411,7 +1421,6 @@ static int ironlake_drpc_info(struct seq_file *m)
crstandvid = I915_READ16(CRSTANDVID);
 
intel_runtime_pm_put(dev_priv);
-   mutex_unlock(>struct_mutex);
 
seq_printf(m, "HD boost: %s\n", yesno(rgvmodectl & MEMMODE_BOOST_EN));
seq_printf(m, "Boost freq: %d\n",
@@ -1757,6 +1766,7 @@ static int i915_sr_status(struct seq_file *m, void 
*unused)
bool sr_enabled = false;
 
intel_runtime_pm_get(dev_priv);
+   intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
 
if (HAS_PCH_SPLIT(dev_priv))
sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN;
@@ -1770,6 +1780,7 @@ static int i915_sr_status(struct seq_file *m, void 
*unused)
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
sr_enabled = I915_READ(FW_BLC_SELF_VLV) & FW_CSPWRDWNEN;
 
+   intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
intel_runtime_pm_put(dev_priv);
 
seq_printf(m, "self-refresh: %s\n",
@@ -2091,12 +2102,7 @@ static const char *swizzle_string(unsigned swizzle)
 static int i915_swizzle_info(struct seq_file *m, void *data)
 {
struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_device *dev = _priv->drm;
- 

[Intel-gfx] i915 4.8.3: cdclk < crtc_clock

[Daniel J Blueman]

Hi Tvrtko,

I'm seeing this warning [1] on a Skylake Dell XPS 15 9550 with the
internal 3840x2160 panel with 4.8.4.

Let me know if you're interested in any debug.

Many thanks!
  Daniel

-- [1]

[ 2236.760626] WARNING: CPU: 1 PID: 1150 at
/home/kernel/COD/linux/drivers/gpu/drm/i915/intel_display.c:14178
skl_max_scale.part.120+0x75/0x80 [i915]
[ 2236.760627] WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
[ 2236.760628] Modules linked in:
[ 2236.760629]  bnep ax88179_178a usbnet mii ebtable_filter ebtables
iptable_mangle xt_DSCP hid_multitouch snd_hda_codec_hdmi dell_led
snd_hda_codec_realtek snd_hda_codec_generic i2c_designware_platform
i2c_designware_core dell_wmi snd_hda_intel snd_hda_codec snd_hda_core
dell_laptop snd_hwdep dell_smbios intel_rapl dcdbas
x86_pkg_temp_thermal intel_powerclamp nls_iso8859_1 coretemp
crct10dif_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel aesni_intel
snd_seq_midi snd_seq_midi_event aes_x86_64 lrw brcmfmac glue_helper
ablk_helper snd_rawmidi cryptd uvcvideo intel_cstate brcmutil
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 intel_rapl_perf
snd_seq videobuf2_core cfg80211 videodev input_leds joydev
snd_seq_device media snd_timer rtsx_pci_ms snd memstick serio_raw
soundcore idma64 virt_dma mei_me
[ 2236.760673]  shpchp processor_thermal_device mei intel_soc_dts_iosf
intel_lpss_pci hci_uart btbcm btqca btintel bluetooth int3403_thermal
intel_lpss_acpi dell_smo8800 intel_lpss int3402_thermal
int3400_thermal intel_hid int340x_thermal_zone acpi_als acpi_pad
acpi_thermal_rel sparse_keymap kfifo_buf mac_hid industrialio
kvm_intel kvm irqbypass xt_hl ip6t_rt nf_conntrack_ipv6 nf_defrag_ipv6
ipt_REJECT nf_reject_ipv4 xt_limit xt_tcpudp xt_addrtype
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack ip6table_filter
ip6_tables nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp
nf_nat nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables
parport_pc ppdev lp parport autofs4 rtsx_pci_sdmmc nouveau i915
mxm_wmi ttm i2c_algo_bit drm_kms_helper psmouse syscopyarea
sysfillrect sysimgblt fb_sys_fops
[ 2236.760716]  nvme nvme_core drm rtsx_pci i2c_hid hid wmi
pinctrl_sunrisepoint video pinctrl_intel fjes
[ 2236.760726] CPU: 1 PID: 1150 Comm: Xorg Not tainted
4.8.4-040804-generic #201610220733
[ 2236.760727] Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS
01.02.00 04/07/2016
[ 2236.760729]  0286 66463e07 8ed2e4f2b930
afe12f12
[ 2236.760733]  8ed2e4f2b980  8ed2e4f2b970
afa82d9b
[ 2236.760736]  376200b0 8ed2e78896c0 8ed2e2fd5800
8ed2e36e5000
[ 2236.760739] Call Trace:
[ 2236.760744]  [] dump_stack+0x63/0x81
[ 2236.760748]  [] __warn+0xcb/0xf0
[ 2236.760751]  [] warn_slowpath_fmt+0x5f/0x80
[ 2236.760763]  [] ?
drm_atomic_helper_normalize_zpos+0x264/0x300 [drm_kms_helper]
[ 2236.760799]  [] skl_max_scale.part.120+0x75/0x80 [i915]
[ 2236.760830]  [] intel_check_primary_plane+0xc6/0xe0 [i915]
[ 2236.760841]  [] ?
drm_atomic_helper_normalize_zpos+0x264/0x300 [drm_kms_helper]
[ 2236.760875]  [] intel_plane_atomic_check+0x132/0x1f0 [i915]
[ 2236.760885]  []
drm_atomic_helper_check_planes+0x84/0x200 [drm_kms_helper]
[ 2236.760926]  [] intel_atomic_check+0x155/0x760 [i915]
[ 2236.760952]  [] drm_atomic_check_only+0x187/0x610 [drm]
[ 2236.760972]  [] drm_atomic_commit+0x17/0x60 [drm]
[ 2236.760983]  []
drm_atomic_helper_disable_plane+0xac/0xf0 [drm_kms_helper]
[ 2236.761003]  [] __setplane_internal+0x17b/0x270 [drm]
[ 2236.761006]  [] ? __wake_up_sync_key+0x50/0x60
[ 2236.761024]  [] drm_mode_cursor_universal+0x139/0x240 [drm]
[ 2236.761046]  [] drm_mode_cursor_common+0x7e/0x180 [drm]
[ 2236.761070]  [] drm_mode_cursor_ioctl+0x50/0x70 [drm]
[ 2236.761091]  [] drm_ioctl+0x200/0x4f0 [drm]
[ 2236.761115]  [] ? drm_mode_setcrtc+0x580/0x580 [drm]
[ 2236.761120]  [] ? __vfs_read+0x37/0x150
[ 2236.761124]  [] do_vfs_ioctl+0xa3/0x600
[ 2236.761129]  [] ? recalc_sigpending+0x1b/0x50
[ 2236.761134]  [] ? __set_task_blocked+0x41/0xa0
[ 2236.761138]  [] SyS_ioctl+0x79/0x90
[ 2236.761140]  [] ? SyS_rt_sigprocmask+0x8e/0xc0
[ 2236.761145]  [] entry_SYSCALL_64_fastpath+0x1e/0xa8
[ 2236.761148] ---[ end trace 0a69ec658ca26029 ]---
[ 2290.023659] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
update failure on pipe A (start=3183 end=3184) time 560 us, min 2146,
max 2159, scanline start 2120, end 2189
[ 3356.918317] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
update failure on pipe A (start=67193 end=67194) time 719 us, min
2146, max 2159, scanline start 2107, end 2197
[ 5485.971871] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
update failure on pipe A (start=194929 end=194930) time 785 us, min
2146, max 2159, scanline start 2073, end 2166
[ 5962.865923] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
update failure on pipe A (start=223541 end=223542) time 281 us, min
2146, max 2159, scanline start 2134, end 2160
[ 6072.139161] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
update failure on pipe A 

Re: [Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

[Ville Syrjälä]

On Mon, Oct 24, 2016 at 12:47:21PM +0200, Maarten Lankhorst wrote:
> Op 24-10-16 om 12:17 schreef Ville Syrjälä:
> > On Mon, Oct 24, 2016 at 12:12:59PM +0200, Maarten Lankhorst wrote:
> >> Op 24-10-16 om 12:04 schreef Ville Syrjälä:
> >>> On Mon, Oct 24, 2016 at 10:45:36AM +0200, Maarten Lankhorst wrote:
>  Op 21-10-16 om 16:16 schreef Ville Syrjälä:
> > On Fri, Oct 21, 2016 at 05:04:46PM +0300, Ville Syrjälä wrote:
> >> On Wed, Oct 19, 2016 at 03:55:35PM +0200, Maarten Lankhorst wrote:
> >>> drm_select_eld requires mode_config.mutex and connection_mutex
> >>> because it looks at the connector list and at the legacy encoders.
> >>>
> >>> This is not required, because when we call audio_codec_enable we know
> >>> which connector it was called for, so pass the state.
> >>>
> >>> This also removes having to look at crtc->config.
> >>>
> >>> Signed-off-by: Maarten Lankhorst 
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_audio.c | 17 ++---
> >>>  drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
> >>>  drivers/gpu/drm/i915/intel_dp.c| 11 ++-
> >>>  drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
> >>>  drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
> >>>  5 files changed, 21 insertions(+), 15 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> >>> b/drivers/gpu/drm/i915/intel_audio.c
> >>> index 7093cfbb62b1..63ef25893c7e 100644
> >>> --- a/drivers/gpu/drm/i915/intel_audio.c
> >>> +++ b/drivers/gpu/drm/i915/intel_audio.c
> >>> @@ -485,23 +485,26 @@ static void ilk_audio_codec_enable(struct 
> >>> drm_connector *connector,
> >>>  /**
> >>>   * intel_audio_codec_enable - Enable the audio codec for HD audio
> >>>   * @intel_encoder: encoder on which to enable audio
> >>> + * @crtc_state: pointer to the current crtc state.
> >>> + * @conn_state: pointer to the current connector state.
> >>>   *
> >>>   * The enable sequences may only be performed after enabling the 
> >>> transcoder and
> >>>   * port, and after completed link training.
> >>>   */
> >>> -void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
> >>> +void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
> >>> +   const struct intel_crtc_state *crtc_state,
> >>> +   const struct drm_connector_state 
> >>> *conn_state)
> >>>  {
> >>>   struct drm_encoder *encoder = _encoder->base;
> >>> - struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> >>> - const struct drm_display_mode *adjusted_mode = 
> >>> >config->base.adjusted_mode;
> >>> + const struct drm_display_mode *adjusted_mode = 
> >>> _state->base.adjusted_mode;
> >>>   struct drm_connector *connector;
> >>>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> >>>   struct i915_audio_component *acomp = dev_priv->audio_component;
> >>>   enum port port = intel_encoder->port;
> >>> - enum pipe pipe = crtc->pipe;
> >>> + enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);
> >> While we may require that to be true, I'm not sure I like this use.
> > I should say that otherwise I like this.
>  What do you mean with this comment?
> >>> That the rest of the patch makes sense.
> >>>
> >> Sorry, I meant the first comment you wrote.
> > I mean that 'enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);'
> > is not something that's done anywhere else. So it looks totally foreign.
> >
> Not directly I guess. Some places already assume that drm_crtc_index == pipe.
> But it's ok when I change it to to_intel_crtc(crtc)->pipe?

Yes.

If we wanted to, I guess we could just do

static inline enum pipe intel_crtc_pipe(crtc)
{
return drm_crtc_index(>base);
}

and just nuke crtc->pipe entirely.

And then we get to hope that the hw people aren't going to allow fusing
off pipes in some random order (eg. just fuse off pipe B on a three pipe
platform). That would obviously break this scheme.

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

[Intel-gfx] [PATCH v3] drm/edid: Only print the bad edid when aborting

[Chris Wilson]

Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
intermediate edid reads. This causes transient failures in CI which
flags up the sporadic EDID read failures, which are recovered by
rereading the EDID automatically. This patch combines the reporting done
by drm_do_get_edid() itself with the bad block printing from
get_edid_block(), into a single warning associated with the connector
once all attempts to retrieve the EDID fail.

v2: Print the whole EDID, marking up the bad/zero blocks. This requires
recording the whole of the raw edid, then a second pass to reduce it to
the valid extensions.
v3: Fix invalid/valid extension fumble.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/drm_edid.c | 79 --
 1 file changed, 56 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95de47ba1e77..9506933b41cd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1260,6 +1260,34 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int 
block, size_t len)
return ret == xfers ? 0 : -1;
 }
 
+static void connector_bad_edid(struct drm_connector *connector,
+  u8 *edid, int num_blocks)
+{
+   int i;
+
+   if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
+   return;
+
+   dev_warn(connector->dev->dev,
+"%s: EDID is invalid:\n",
+connector->name);
+   for (i = 0; i < num_blocks; i++) {
+   u8 *block = edid + i * EDID_LENGTH;
+   char prefix[20];
+
+   if (drm_edid_is_zero(block, EDID_LENGTH))
+   sprintf(prefix, "\t[%02x] ZERO ", i);
+   else if (!drm_edid_block_valid(block, i, false, NULL))
+   sprintf(prefix, "\t[%02x] BAD  ", i);
+   else
+   sprintf(prefix, "\t[%02x] GOOD ", i);
+
+   print_hex_dump(KERN_WARNING,
+  prefix, DUMP_PREFIX_NONE, 16, 1,
+  block, EDID_LENGTH, false);
+   }
+}
+
 /**
  * drm_do_get_edid - get EDID data using a custom EDID block read function
  * @connector: connector we're probing
@@ -1283,7 +1311,6 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
 {
int i, j = 0, valid_extensions = 0;
u8 *edid, *new;
-   bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
DRM_UT_KMS);
 
if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
@@ -1292,7 +1319,7 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
for (i = 0; i < 4; i++) {
if (get_edid_block(data, edid, 0, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(edid, 0, print_bad_edid,
+   if (drm_edid_block_valid(edid, 0, false,
 >edid_corrupt))
break;
if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
@@ -1304,54 +1331,60 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
goto carp;
 
/* if there's no extensions, we're done */
-   if (edid[0x7e] == 0)
+   valid_extensions = edid[0x7e];
+   if (valid_extensions == 0)
return (struct edid *)edid;
 
-   new = krealloc(edid, (edid[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
+   new = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH, GFP_KERNEL);
if (!new)
goto out;
edid = new;
 
for (j = 1; j <= edid[0x7e]; j++) {
-   u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
+   u8 *block = edid + j * EDID_LENGTH;
 
for (i = 0; i < 4; i++) {
if (get_edid_block(data, block, j, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(block, j,
-print_bad_edid, NULL)) {
-   valid_extensions++;
+   if (drm_edid_block_valid(block, j, false, NULL))
break;
-   }
}
 
-   if (i == 4 && print_bad_edid) {
-   dev_warn(connector->dev->dev,
-"%s: Ignoring invalid EDID block %d.\n",
-connector->name, j);
-
-   connector->bad_edid_counter++;
-   }
+   if (i == 4)
+   valid_extensions--;
}
 
if (valid_extensions != edid[0x7e]) {
+   u8 *base;
+
+   connector_bad_edid(connector, edid, edid[0x7e] + 1);
+

Re: [Intel-gfx] [PATCH v2] drm/edid: Only print the bad edid when aborting

[Chris Wilson]

On Mon, Oct 24, 2016 at 12:33:41PM +0100, Chris Wilson wrote:
>   for (j = 1; j <= edid[0x7e]; j++) {
> - u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
> + u8 *block = edid + j * EDID_LENGTH;
>  
>   for (i = 0; i < 4; i++) {
>   if (get_edid_block(data, block, j, EDID_LENGTH))
>   goto out;
> - if (drm_edid_block_valid(block, j,
> -  print_bad_edid, NULL)) {
> - valid_extensions++;
> + if (drm_edid_block_valid(block, j, false, NULL)) {
> + valid_extensions--;

Inverted.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/edid: Only print the bad edid when aborting

[Chris Wilson]

Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
intermediate edid reads. This causes transient failures in CI which
flags up the sporadic EDID read failures, which are recovered by
rereading the EDID automatically. This patch combines the reporting done
by drm_do_get_edid() itself with the bad block printing from
get_edid_block(), into a single warning associated with the connector
once all attempts to retrieve the EDID fail.

v2: Print the whole EDID, marking up the bad/zero blocks. This requires
recording the whole of the raw edid, then a second pass to reduce it to
the valid extensions.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_edid.c | 78 --
 1 file changed, 55 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95de47ba1e77..2789eb0b9162 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1260,6 +1260,34 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int 
block, size_t len)
return ret == xfers ? 0 : -1;
 }
 
+static void connector_bad_edid(struct drm_connector *connector,
+  u8 *edid, int num_blocks)
+{
+   int i;
+
+   if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
+   return;
+
+   dev_warn(connector->dev->dev,
+"%s: EDID is invalid:\n",
+connector->name);
+   for (i = 0; i < num_blocks; i++) {
+   u8 *block = edid + i * EDID_LENGTH;
+   char prefix[20];
+
+   if (drm_edid_is_zero(block, EDID_LENGTH))
+   sprintf(prefix, "\t[%02x] ZERO ", i);
+   else if (!drm_edid_block_valid(block, i, false, NULL))
+   sprintf(prefix, "\t[%02x] BAD  ", i);
+   else
+   sprintf(prefix, "\t[%02x] GOOD ", i);
+
+   print_hex_dump(KERN_WARNING,
+  prefix, DUMP_PREFIX_NONE, 16, 1,
+  block, EDID_LENGTH, false);
+   }
+}
+
 /**
  * drm_do_get_edid - get EDID data using a custom EDID block read function
  * @connector: connector we're probing
@@ -1283,7 +1311,6 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
 {
int i, j = 0, valid_extensions = 0;
u8 *edid, *new;
-   bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
DRM_UT_KMS);
 
if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
@@ -1292,7 +1319,7 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
for (i = 0; i < 4; i++) {
if (get_edid_block(data, edid, 0, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(edid, 0, print_bad_edid,
+   if (drm_edid_block_valid(edid, 0, false,
 >edid_corrupt))
break;
if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
@@ -1304,54 +1331,59 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
goto carp;
 
/* if there's no extensions, we're done */
-   if (edid[0x7e] == 0)
+   valid_extensions = edid[0x7e];
+   if (valid_extensions == 0)
return (struct edid *)edid;
 
-   new = krealloc(edid, (edid[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
+   new = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH, GFP_KERNEL);
if (!new)
goto out;
edid = new;
 
for (j = 1; j <= edid[0x7e]; j++) {
-   u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
+   u8 *block = edid + j * EDID_LENGTH;
 
for (i = 0; i < 4; i++) {
if (get_edid_block(data, block, j, EDID_LENGTH))
goto out;
-   if (drm_edid_block_valid(block, j,
-print_bad_edid, NULL)) {
-   valid_extensions++;
+   if (drm_edid_block_valid(block, j, false, NULL)) {
+   valid_extensions--;
break;
}
}
-
-   if (i == 4 && print_bad_edid) {
-   dev_warn(connector->dev->dev,
-"%s: Ignoring invalid EDID block %d.\n",
-connector->name, j);
-
-   connector->bad_edid_counter++;
-   }
}
 
if (valid_extensions != edid[0x7e]) {
+   u8 *base;
+
+   connector_bad_edid(connector, edid, edid[0x7e] + 1);
+
edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
edid[0x7e] = valid_extensions;
-   new 

Re: [Intel-gfx] [PATCH] drm/i915: fix comment referencing imaginary functions

[Arkadiusz Hiler]

On Fri, Oct 21, 2016 at 02:57:28PM +0100, Chris Wilson wrote:
> On Fri, Oct 21, 2016 at 04:00:10PM +0300, Mika Kuoppala wrote:
> > Chris Wilson  writes:
> > 
> > > On Fri, Oct 21, 2016 at 02:16:46PM +0200, Arkadiusz Hiler wrote:
> > >> On Wed, Aug 24, 2016 at 05:03:11PM +0100, Matthew Auld wrote:
> > >> > The comment which documents the proper usage of the *_FW family of 
> > >> > macros makes
> > >> > reference to intel_uncore_forcewake_irq{unlock, lock}, which is just
> > >> > confusing, seeing as such a set of functions don't even exist and 
> > >> > never have
> > >> > for that matter(according to git). Let's fix that by replacing them 
> > >> > with
> > >> > intel_uncore_forcewake_{get, put}.
> > >> > 
> > >> > Cc: Chris Wilson 
> > >> > Signed-off-by: Matthew Auld 
> > >> Reviewed-by: Arkadiusz Hiler 
> > >
> > > The downside is that this now doesn't mention the locking required to
> > > prevent machine hangs on some platforms.

Previous version neither mentioned that clearly. Imaginary
functions with irq in name is more confusing than helpful in my opinion.
The assumption that those were mistaken for {get,put} is easy enough
to make.

> > 
> > "intel_uncore_forcewake_get will acquire forcewake reference and also
> > take a uncore.lock to guarantee explicit access by one thread only. As
> > some registers don't need forcewake held, intel_uncore_forcewake_{get,put}
> > can be omitted. If you do so, be warned that on some gens (gen7),
> > concurrent access to the same cacheline by multiple cpu threads with the gpu
> > can risk a system hang. You need to grab uncore spinlock explicitly to
> > guard against this."
> > 
> > Would that be accurate addition?
> 
> intel_uncore_forcewake_get() doesn't acquire the spinlock for you, just
> for itself.
> 
> The full sequence would be
> 
> spin_lock_irq(_priv->uncore.lock);
> intel_uncore_forcewake_get()
> ...
> intel_uncore_forcewake_put()
> spin_unlock_irq(_priv->uncore.lock);
> 
> We very rarely do that either (a) presuming that we are serialised by
> some other lock, (b) don't care because it is safe or (c) completely
> forgotten about the risks.
> -Chris

Then all that should be mentioned?

My take on it:


These are untraced mmio-accessors that are only valid to be used inside
critical sections inside IRQ handlers where forcewake is explicitly
controlled.

Think twice, and think again, before using these.

Those possibly should be used between:

spin_lock_irq(_priv->uncore.lock);
intel_uncore_forcewake_get();

and

intel_uncore_forcewake_put();
spin_unlock_irq(_priv->uncore.lock);


Note: some registers may not need forcewake held, so
intel_uncore_forcewake_{get,put} can be omitted.

Code may be serialised by different lock, so immediate
spin_{lock,unlock}_irq() may not be necessary.


--
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

[Maarten Lankhorst]

Op 24-10-16 om 12:17 schreef Ville Syrjälä:
> On Mon, Oct 24, 2016 at 12:12:59PM +0200, Maarten Lankhorst wrote:
>> Op 24-10-16 om 12:04 schreef Ville Syrjälä:
>>> On Mon, Oct 24, 2016 at 10:45:36AM +0200, Maarten Lankhorst wrote:
 Op 21-10-16 om 16:16 schreef Ville Syrjälä:
> On Fri, Oct 21, 2016 at 05:04:46PM +0300, Ville Syrjälä wrote:
>> On Wed, Oct 19, 2016 at 03:55:35PM +0200, Maarten Lankhorst wrote:
>>> drm_select_eld requires mode_config.mutex and connection_mutex
>>> because it looks at the connector list and at the legacy encoders.
>>>
>>> This is not required, because when we call audio_codec_enable we know
>>> which connector it was called for, so pass the state.
>>>
>>> This also removes having to look at crtc->config.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>>> ---
>>>  drivers/gpu/drm/i915/intel_audio.c | 17 ++---
>>>  drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
>>>  drivers/gpu/drm/i915/intel_dp.c| 11 ++-
>>>  drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
>>>  drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
>>>  5 files changed, 21 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>>> b/drivers/gpu/drm/i915/intel_audio.c
>>> index 7093cfbb62b1..63ef25893c7e 100644
>>> --- a/drivers/gpu/drm/i915/intel_audio.c
>>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>>> @@ -485,23 +485,26 @@ static void ilk_audio_codec_enable(struct 
>>> drm_connector *connector,
>>>  /**
>>>   * intel_audio_codec_enable - Enable the audio codec for HD audio
>>>   * @intel_encoder: encoder on which to enable audio
>>> + * @crtc_state: pointer to the current crtc state.
>>> + * @conn_state: pointer to the current connector state.
>>>   *
>>>   * The enable sequences may only be performed after enabling the 
>>> transcoder and
>>>   * port, and after completed link training.
>>>   */
>>> -void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
>>> +void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
>>> + const struct intel_crtc_state *crtc_state,
>>> + const struct drm_connector_state 
>>> *conn_state)
>>>  {
>>> struct drm_encoder *encoder = _encoder->base;
>>> -   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
>>> -   const struct drm_display_mode *adjusted_mode = 
>>> >config->base.adjusted_mode;
>>> +   const struct drm_display_mode *adjusted_mode = 
>>> _state->base.adjusted_mode;
>>> struct drm_connector *connector;
>>> struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>>> struct i915_audio_component *acomp = dev_priv->audio_component;
>>> enum port port = intel_encoder->port;
>>> -   enum pipe pipe = crtc->pipe;
>>> +   enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);
>> While we may require that to be true, I'm not sure I like this use.
> I should say that otherwise I like this.
 What do you mean with this comment?
>>> That the rest of the patch makes sense.
>>>
>> Sorry, I meant the first comment you wrote.
> I mean that 'enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);'
> is not something that's done anywhere else. So it looks totally foreign.
>
Not directly I guess. Some places already assume that drm_crtc_index == pipe.
But it's ok when I change it to to_intel_crtc(crtc)->pipe?

~Maarten

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

Re: [Intel-gfx] [RESEND PATCH 4/6] drm/i915: Update atomic modeset state synchronously

[Maarten Lankhorst]

Op 24-10-16 om 12:19 schreef Ville Syrjälä:
> On Mon, Oct 24, 2016 at 12:07:30PM +0200, Maarten Lankhorst wrote:
>> Op 21-10-16 om 16:08 schreef Ville Syrjälä:
>>> On Wed, Oct 19, 2016 at 03:55:37PM +0200, Maarten Lankhorst wrote:
 All of this state should be updated as soon as possible. It shouldn't be
 done later because then future updates may not depend on it.

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/intel_display.c | 15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 69b9e91f071e..ba7f7be3aa4f 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -14341,14 +14341,8 @@ static void intel_atomic_commit_tail(struct 
 drm_atomic_state *state)
  
drm_atomic_helper_wait_for_dependencies(state);
  
 -  if (intel_state->modeset) {
 -  memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
 - sizeof(intel_state->min_pixclk));
 -  dev_priv->active_crtcs = intel_state->active_crtcs;
 -  dev_priv->atomic_cdclk_freq = intel_state->cdclk;
 -
 +  if (intel_state->modeset)
intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
 -  }
  
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 @@ -14558,6 +14552,13 @@ static int intel_atomic_commit(struct drm_device 
 *dev,
intel_atomic_track_fbs(state);
  
drm_atomic_state_get(state);
 +  if (intel_state->modeset) {
 +  memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
 + sizeof(intel_state->min_pixclk));
 +  dev_priv->active_crtcs = intel_state->active_crtcs;
 +  dev_priv->atomic_cdclk_freq = intel_state->cdclk;
 +  }
 +
>>> I'm not very happy about this whole intel_atomic_state <-> dev_priv
>>> mess. I think what might be nicer is to have an intel_atomic_device_state
>>> or something, which would be part of the top level atomic state just
>>> like the other states, and we would just a pointer to the current
>>> device state under dev_priv I suppose. This way the top level atomic
>>> state would be more like an atomic transaction thing.
>>>
>> Neither, but I don't see a way to separate it cleanly. The updated members 
>> are too random to be put together in a struct.
> What do you mean random? Just not related to each other. That doesn't
> prohibit from collecting them up in a struct. They're already there
> in intel_atomic_state after all.
>
>> And some are used read-only when !modeset, and others are not meant to be 
>> used at all in that case. Might even depend
>> on the platform.
> How is one supposed to tell when they're to be used or not?
Outside of modeset I think only intel_atomic_state->cdclk is valid. But only 
used by skl watermark sanitization. It uses a trick
in which intel_state->active_crtcs is valid too. I think that requirement can 
be removed though with some small changes. It
looks wrong anyway..

Some more looking shows that the wrong cdclk is used for scaler calculations 
with !modeset, only matters in the dpms off case.
But that needs fixing too..

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

Re: [Intel-gfx] [PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property

[Archit Taneja]

On 10/24/2016 03:45 PM, Ville Syrjälä wrote:

On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:

Hi Ville,

On 10/22/2016 12:52 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

The global mode_config.rotation_property is going away, switch over to
per-plane rotation_property.



I was trying to test this on msm/drm using modetest. The 180 rotation
works fine, but drm rejects reflect-x and reflect-y rotation prop
values. Is this expected?

I needed to make this modification to get reflect-x/y working too:

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a747bb1..9fcc2c9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property ||
   property == plane->rotation_property) {
-   if (!is_power_of_2(val & DRM_ROTATE_MASK))
+   if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))


That makes no sense. You _must_ to pass one and only one rotation angle.
In *addition* you can pass any number of the reflection flags.


Okay. Does the rotation property also include reflection flags, though?

When I dump plane properties using modetest, I get:

31 rotation:
 flags: bitmask
 values: rotate-0=0x1 rotate-180=0x4 reflect-x=0x10 reflect-y=0x20
 value: 1

If I use modetest to set 0x10 or 0x20, it returns an error. I wanted to
know if this is expected behavior or not?

Thanks,
Archit




return -EINVAL;
state->rotation = val;
} else if (property == plane->zpos_property) {



Otherwise, the patches look fine to me.

Thanks,
Archit



v2: Drop the BIT()

Cc: Rob Clark 
Cc: Jilai Wang 
Cc: Archit Taneja 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rob Clark 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 951c002b05df..2653ad893ebc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -75,15 +75,11 @@ static void mdp5_plane_install_rotation_property(struct 
drm_device *dev,
!(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
return;

-   if (!dev->mode_config.rotation_property)
-   dev->mode_config.rotation_property =
-   drm_mode_create_rotation_property(dev,
-   DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
-
-   if (dev->mode_config.rotation_property)
-   drm_object_attach_property(>base,
-   dev->mode_config.rotation_property,
-   DRM_ROTATE_0);
+   drm_plane_create_rotation_property(plane,
+  DRM_ROTATE_0,
+  DRM_ROTATE_0 |
+  DRM_REFLECT_X |
+  DRM_REFLECT_Y);
 }

 /* helper to install properties which are common to planes and crtcs */



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

[Ville Syrjälä]

On Mon, Oct 24, 2016 at 12:12:59PM +0200, Maarten Lankhorst wrote:
> Op 24-10-16 om 12:04 schreef Ville Syrjälä:
> > On Mon, Oct 24, 2016 at 10:45:36AM +0200, Maarten Lankhorst wrote:
> >> Op 21-10-16 om 16:16 schreef Ville Syrjälä:
> >>> On Fri, Oct 21, 2016 at 05:04:46PM +0300, Ville Syrjälä wrote:
>  On Wed, Oct 19, 2016 at 03:55:35PM +0200, Maarten Lankhorst wrote:
> > drm_select_eld requires mode_config.mutex and connection_mutex
> > because it looks at the connector list and at the legacy encoders.
> >
> > This is not required, because when we call audio_codec_enable we know
> > which connector it was called for, so pass the state.
> >
> > This also removes having to look at crtc->config.
> >
> > Signed-off-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/i915/intel_audio.c | 17 ++---
> >  drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
> >  drivers/gpu/drm/i915/intel_dp.c| 11 ++-
> >  drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
> >  drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
> >  5 files changed, 21 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 7093cfbb62b1..63ef25893c7e 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -485,23 +485,26 @@ static void ilk_audio_codec_enable(struct 
> > drm_connector *connector,
> >  /**
> >   * intel_audio_codec_enable - Enable the audio codec for HD audio
> >   * @intel_encoder: encoder on which to enable audio
> > + * @crtc_state: pointer to the current crtc state.
> > + * @conn_state: pointer to the current connector state.
> >   *
> >   * The enable sequences may only be performed after enabling the 
> > transcoder and
> >   * port, and after completed link training.
> >   */
> > -void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
> > +void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
> > + const struct intel_crtc_state *crtc_state,
> > + const struct drm_connector_state 
> > *conn_state)
> >  {
> > struct drm_encoder *encoder = _encoder->base;
> > -   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > -   const struct drm_display_mode *adjusted_mode = 
> > >config->base.adjusted_mode;
> > +   const struct drm_display_mode *adjusted_mode = 
> > _state->base.adjusted_mode;
> > struct drm_connector *connector;
> > struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> > struct i915_audio_component *acomp = dev_priv->audio_component;
> > enum port port = intel_encoder->port;
> > -   enum pipe pipe = crtc->pipe;
> > +   enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);
>  While we may require that to be true, I'm not sure I like this use.
> >>> I should say that otherwise I like this.
> >> What do you mean with this comment?
> > That the rest of the patch makes sense.
> >
> Sorry, I meant the first comment you wrote.

I mean that 'enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);'
is not something that's done anywhere else. So it looks totally foreign.

-- 
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 v2 1/6] drm/msm/mdp5: Use per-plane rotation property

[Ville Syrjälä]

On Mon, Oct 24, 2016 at 03:33:18PM +0530, Archit Taneja wrote:
> Hi Ville,
> 
> On 10/22/2016 12:52 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > The global mode_config.rotation_property is going away, switch over to
> > per-plane rotation_property.
> 
> 
> I was trying to test this on msm/drm using modetest. The 180 rotation
> works fine, but drm rejects reflect-x and reflect-y rotation prop
> values. Is this expected?
> 
> I needed to make this modification to get reflect-x/y working too:
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index a747bb1..9fcc2c9 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
>   state->src_h = val;
>   } else if (property == config->rotation_property ||
>  property == plane->rotation_property) {
> - if (!is_power_of_2(val & DRM_ROTATE_MASK))
> + if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))

That makes no sense. You _must_ to pass one and only one rotation angle.
In *addition* you can pass any number of the reflection flags.

>   return -EINVAL;
>   state->rotation = val;
>   } else if (property == plane->zpos_property) {
> 
> 
> 
> Otherwise, the patches look fine to me.
> 
> Thanks,
> Archit
> 
> >
> > v2: Drop the BIT()
> >
> > Cc: Rob Clark 
> > Cc: Jilai Wang 
> > Cc: Archit Taneja 
> > Signed-off-by: Ville Syrjälä 
> > Reviewed-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
> >  1 file changed, 5 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> > b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > index 951c002b05df..2653ad893ebc 100644
> > --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> > @@ -75,15 +75,11 @@ static void mdp5_plane_install_rotation_property(struct 
> > drm_device *dev,
> > !(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
> > return;
> >
> > -   if (!dev->mode_config.rotation_property)
> > -   dev->mode_config.rotation_property =
> > -   drm_mode_create_rotation_property(dev,
> > -   DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
> > -
> > -   if (dev->mode_config.rotation_property)
> > -   drm_object_attach_property(>base,
> > -   dev->mode_config.rotation_property,
> > -   DRM_ROTATE_0);
> > +   drm_plane_create_rotation_property(plane,
> > +  DRM_ROTATE_0,
> > +  DRM_ROTATE_0 |
> > +  DRM_REFLECT_X |
> > +  DRM_REFLECT_Y);
> >  }
> >
> >  /* helper to install properties which are common to planes and crtcs */
> >
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project

-- 
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/1] drm/i915: Give write permission to gt_boost_freq_mhz

[Kamble, Sagar A]

Hi Daniel, Chris,


Sorry for not clarifying the purpose and if any misunderstanding.
This was to allow running at fixed frequency.

Kindly clarify if it is intentional to have _store routine without S_IWUSR.

On 10/24/2016 2:42 PM, Chris Wilson wrote:

On Mon, Oct 24, 2016 at 11:05:13AM +0200, Daniel Vetter wrote:

On Mon, Oct 24, 2016 at 10:00:49AM +0530, Sagar Arun Kamble wrote:

And uabi change with 0 commit message. This needs to be _much_ better ;-)

A case where the author cut'n'paste the wrong thing because he can't
read S_INCOMPREHENSIBLELINENOISE as opposed to the traditional 0600.
-Chris



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

Re: [Intel-gfx] [PATCH igt] igt/kms_setmode: Clear all connectors before starting the test

[Ville Syrjälä]

On Mon, Oct 24, 2016 at 11:04:35AM +0200, Daniel Vetter wrote:
> On Sat, Oct 22, 2016 at 09:32:41AM +0100, Chris Wilson wrote:
> > Before we start trying random combinations of connectors and CRTCs, we
> > should first ensure we have a blank slate so that if we only change a
> > subset of the CRTC we do not conflict with a residual setup on the other
> > CRTC.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  tests/kms_setmode.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
> > index 24fb34c..df958f0 100644
> > --- a/tests/kms_setmode.c
> > +++ b/tests/kms_setmode.c
> > @@ -268,6 +268,10 @@ static void setup_crtcs(drmModeRes *resources, struct 
> > connector_config *cconf,
> > int i;
> > int encoder_usage_count[resources->count_encoders];
> >  
> > +   for (i = 0; i < resources->count_crtcs; i++)
> > +   drmModeSetCrtc(drm_fd, resources->crtcs[i],
> > +  0, 0, 0, 0, 0, NULL);
> 
> Shouldn't this be in some modeset helper library, or is kms_setmode not
> using that one?

Like kmstest_unset_all_crtcs() ?

> Especially with atomic it's much neater to just clear our
> software state (and then applying all the changes we want in one go).
> 
> But it does get the job done meanwhile, so ack.
> -Daniel
> > +
> > i = 0;
> > crtc_count = 0;
> > crtc = crtcs;
> > -- 
> > 2.9.3
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> 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] drm/i915: remove AGP dependency from DRM_I915 kconfig help text

[Ville Syrjälä]

On Mon, Oct 24, 2016 at 10:52:59AM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 12:14:17PM +0300, Jani Nikula wrote:
> > We haven't required AGP since 3e99a6b95614 ("drm/i915: Stop depending
> > upon CONFIG_AGP_INTEL"). Split/rearrange the paragraphs a bit while at
> > it.
> > 
> > Signed-off-by: Jani Nikula 
> 
> Reviewed-by: Daniel Vetter 
> 
> > ---
> >  drivers/gpu/drm/i915/Kconfig | 11 ++-
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> > index 1c1b19ccb92f..45a5eb71e8e6 100644
> > --- a/drivers/gpu/drm/i915/Kconfig
> > +++ b/drivers/gpu/drm/i915/Kconfig
> > @@ -24,16 +24,17 @@ config DRM_I915
> >   including 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G,
> >   G35, G41, G43, G45 chipsets and Celeron, Pentium, Core i3,
> >   Core i5, Core i7 as well as Atom CPUs with integrated graphics.
> 
> Hm, nowadays it's called Intel HD graphics. Maybe we should mention that?
> Feel free to add that.

HD graphics seems to be listed before the chipset names. But we do lack
a mention of the "Exterme Graphics" :) moniker that was used for gen2 IIRC.

> 
> > - If M is selected, the module will be called i915.  AGP support
> > - is required for this driver to work. This driver is used by
> > - the Intel driver in X.org 6.8 and XFree86 4.4 and above. It
> > - replaces the older i830 module that supported a subset of the
> > - hardware in older X.org releases.
> > +
> > + This driver is used by the Intel driver in X.org 6.8 and
> > + XFree86 4.4 and above. It replaces the older i830 module that
> > + supported a subset of the hardware in older X.org releases.
> >  
> >   Note that the older i810/i815 chipsets require the use of the
> >   i810 driver instead, and the Atom z5xx series has an entirely
> >   different implementation.
> >  
> > + If "M" is selected, the module will be called i915.
> > +
> >  config DRM_I915_PRELIMINARY_HW_SUPPORT
> > bool "Enable preliminary support for prerelease Intel hardware by 
> > default"
> > depends on DRM_I915
> > -- 
> > 2.1.4
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> 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

[Intel-gfx] [PATCH igt] igt/kms_setmode: Test that the vblank interval matches the dotclock

[Chris Wilson]

As we allow userspace to set the dotclock, we should try to respect it!
Userpsace will try to set its frametimings based upon the dotclock, so
ideally it should match the measured vblank interval.

Signed-off-by: Chris Wilson 
---
 tests/kms_setmode.c | 75 +++--
 1 file changed, 73 insertions(+), 2 deletions(-)

diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
index df958f0..966ad93 100644
--- a/tests/kms_setmode.c
+++ b/tests/kms_setmode.c
@@ -71,6 +71,7 @@ enum test_flags {
TEST_SINGLE_CRTC_CLONE  = 0x04,
TEST_EXCLUSIVE_CRTC_CLONE   = 0x08,
TEST_STEALING   = 0x10,
+   TEST_TIMINGS= 0x20,
 };
 
 struct test_config {
@@ -413,6 +414,75 @@ static int test_stealing(int fd, struct crtc_config *crtc, 
uint32_t *ids)
return ret;
 }
 
+static double frame_time(const drmModeModeInfo *kmode)
+{
+   return 1000.0 * kmode->htotal * kmode->vtotal / kmode->clock;
+}
+
+static void check_timings(int crtc_idx, const drmModeModeInfo *kmode)
+{
+#define CALIBRATE_TS_STEPS 120 /* ~2s has to be less than 128! */
+   drmVBlank wait;
+   igt_stats_t stats;
+   uint32_t last_seq;
+   uint64_t last_timestamp;
+   double expected;
+   double mean;
+   double stddev;
+   int n;
+
+   memset(, 0, sizeof(wait));
+   wait.request.type = kmstest_get_vbl_flag(crtc_idx);
+   wait.request.type |= DRM_VBLANK_ABSOLUTE | DRM_VBLANK_NEXTONMISS;
+   do_or_die(drmWaitVBlank(drm_fd, ));
+
+   last_seq = wait.reply.sequence;
+   last_timestamp = wait.reply.tval_sec;
+   last_timestamp *= 100;
+   last_timestamp += wait.reply.tval_usec;
+
+   memset(, 0, sizeof(wait));
+   wait.request.type = kmstest_get_vbl_flag(crtc_idx);
+   wait.request.type |= DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
+   wait.request.sequence = last_seq;
+   for (n = 0; n < CALIBRATE_TS_STEPS; n++) {
+   ++wait.request.sequence;
+   do_or_die(drmWaitVBlank(drm_fd, ));
+   }
+
+   igt_stats_init_with_size(, CALIBRATE_TS_STEPS);
+   for (n = 0; n < CALIBRATE_TS_STEPS; n++) {
+   struct drm_event_vblank ev;
+   uint64_t now;
+
+   igt_assert(read(drm_fd, , sizeof(ev)) == sizeof(ev));
+   igt_assert_eq(ev.sequence, last_seq + 1);
+
+   now = ev.tv_sec;
+   now *= 100;
+   now += ev.tv_usec;
+
+   igt_stats_push(, now - last_timestamp);
+
+   last_timestamp = now;
+   last_seq = ev.sequence;
+   }
+
+   expected = frame_time(kmode);
+
+   mean = igt_stats_get_mean();
+   stddev = igt_stats_get_std_deviation();
+
+   igt_info("Expected frametime: %.0fus; measured %.1fus +- %.3fus 
accuracy %.2f%%\n",
+expected, mean, stddev, 100 * 6 * stddev / mean);
+   igt_assert(6 * stddev / mean < 0.005); /* 99% accuracy within 0.5% */
+
+   igt_assert_f(fabs(mean - expected) < 2*stddev,
+ "vblank interval differs from modeline! expected %.1fus, 
measured %1.fus +- %.3fus, difference %.1fus (%.1f sigma)\n",
+ expected, mean, stddev,
+ fabs(mean - expected), fabs(mean - expected) / stddev);
+}
+
 static void test_crtc_config(const struct test_config *tconf,
 struct crtc_config *crtcs, int crtc_count)
 {
@@ -475,8 +545,8 @@ static void test_crtc_config(const struct test_config 
*tconf,
 
igt_assert(config_failed == !!(tconf->flags & TEST_INVALID));
 
-   if (ret == 0 && connector_connected && !(tconf->flags & TEST_INVALID))
-   sleep(5);
+   if (ret == 0 && connector_connected && tconf->flags & TEST_TIMINGS)
+   check_timings(crtcs[0].crtc_idx, [0].mode);
 
for (i = 0; i < crtc_count; i++) {
if (crtcs[i].fb_info.fb_id) {
@@ -732,6 +802,7 @@ int main(int argc, char **argv)
enum test_flags flags;
const char *name;
} tests[] = {
+   { TEST_TIMINGS, "basic" },
{ TEST_CLONE | TEST_SINGLE_CRTC_CLONE,
"basic-clone-single-crtc" },
{ TEST_INVALID | TEST_CLONE | TEST_SINGLE_CRTC_CLONE,
-- 
2.10.1

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

Re: [Intel-gfx] [RESEND PATCH 4/6] drm/i915: Update atomic modeset state synchronously

[Maarten Lankhorst]

Op 21-10-16 om 16:08 schreef Ville Syrjälä:
> On Wed, Oct 19, 2016 at 03:55:37PM +0200, Maarten Lankhorst wrote:
>> All of this state should be updated as soon as possible. It shouldn't be
>> done later because then future updates may not depend on it.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 15 ---
>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 69b9e91f071e..ba7f7be3aa4f 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14341,14 +14341,8 @@ static void intel_atomic_commit_tail(struct 
>> drm_atomic_state *state)
>>  
>>  drm_atomic_helper_wait_for_dependencies(state);
>>  
>> -if (intel_state->modeset) {
>> -memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
>> -   sizeof(intel_state->min_pixclk));
>> -dev_priv->active_crtcs = intel_state->active_crtcs;
>> -dev_priv->atomic_cdclk_freq = intel_state->cdclk;
>> -
>> +if (intel_state->modeset)
>>  intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
>> -}
>>  
>>  for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
>>  struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> @@ -14558,6 +14552,13 @@ static int intel_atomic_commit(struct drm_device 
>> *dev,
>>  intel_atomic_track_fbs(state);
>>  
>>  drm_atomic_state_get(state);
>> +if (intel_state->modeset) {
>> +memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
>> +   sizeof(intel_state->min_pixclk));
>> +dev_priv->active_crtcs = intel_state->active_crtcs;
>> +dev_priv->atomic_cdclk_freq = intel_state->cdclk;
>> +}
>> +
> I'm not very happy about this whole intel_atomic_state <-> dev_priv
> mess. I think what might be nicer is to have an intel_atomic_device_state
> or something, which would be part of the top level atomic state just
> like the other states, and we would just a pointer to the current
> device state under dev_priv I suppose. This way the top level atomic
> state would be more like an atomic transaction thing.
>
Neither, but I don't see a way to separate it cleanly. The updated members are 
too random to be put together in a struct.
And some are used read-only when !modeset, and others are not meant to be used 
at all in that case. Might even depend
on the platform.

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

Re: [Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

[Ville Syrjälä]

On Mon, Oct 24, 2016 at 10:45:36AM +0200, Maarten Lankhorst wrote:
> Op 21-10-16 om 16:16 schreef Ville Syrjälä:
> > On Fri, Oct 21, 2016 at 05:04:46PM +0300, Ville Syrjälä wrote:
> >> On Wed, Oct 19, 2016 at 03:55:35PM +0200, Maarten Lankhorst wrote:
> >>> drm_select_eld requires mode_config.mutex and connection_mutex
> >>> because it looks at the connector list and at the legacy encoders.
> >>>
> >>> This is not required, because when we call audio_codec_enable we know
> >>> which connector it was called for, so pass the state.
> >>>
> >>> This also removes having to look at crtc->config.
> >>>
> >>> Signed-off-by: Maarten Lankhorst 
> >>> ---
> >>>  drivers/gpu/drm/i915/intel_audio.c | 17 ++---
> >>>  drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
> >>>  drivers/gpu/drm/i915/intel_dp.c| 11 ++-
> >>>  drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
> >>>  drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
> >>>  5 files changed, 21 insertions(+), 15 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> >>> b/drivers/gpu/drm/i915/intel_audio.c
> >>> index 7093cfbb62b1..63ef25893c7e 100644
> >>> --- a/drivers/gpu/drm/i915/intel_audio.c
> >>> +++ b/drivers/gpu/drm/i915/intel_audio.c
> >>> @@ -485,23 +485,26 @@ static void ilk_audio_codec_enable(struct 
> >>> drm_connector *connector,
> >>>  /**
> >>>   * intel_audio_codec_enable - Enable the audio codec for HD audio
> >>>   * @intel_encoder: encoder on which to enable audio
> >>> + * @crtc_state: pointer to the current crtc state.
> >>> + * @conn_state: pointer to the current connector state.
> >>>   *
> >>>   * The enable sequences may only be performed after enabling the 
> >>> transcoder and
> >>>   * port, and after completed link training.
> >>>   */
> >>> -void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
> >>> +void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
> >>> +   const struct intel_crtc_state *crtc_state,
> >>> +   const struct drm_connector_state *conn_state)
> >>>  {
> >>>   struct drm_encoder *encoder = _encoder->base;
> >>> - struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> >>> - const struct drm_display_mode *adjusted_mode = 
> >>> >config->base.adjusted_mode;
> >>> + const struct drm_display_mode *adjusted_mode = 
> >>> _state->base.adjusted_mode;
> >>>   struct drm_connector *connector;
> >>>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> >>>   struct i915_audio_component *acomp = dev_priv->audio_component;
> >>>   enum port port = intel_encoder->port;
> >>> - enum pipe pipe = crtc->pipe;
> >>> + enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);
> >> While we may require that to be true, I'm not sure I like this use.
> > I should say that otherwise I like this.
> What do you mean with this comment?

That the rest of the patch makes sense.

-- 
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 v2 1/6] drm/msm/mdp5: Use per-plane rotation property

[Archit Taneja]

Hi Ville,

On 10/22/2016 12:52 AM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

The global mode_config.rotation_property is going away, switch over to
per-plane rotation_property.



I was trying to test this on msm/drm using modetest. The 180 rotation
works fine, but drm rejects reflect-x and reflect-y rotation prop
values. Is this expected?

I needed to make this modification to get reflect-x/y working too:

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index a747bb1..9fcc2c9 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -711,7 +711,7 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
state->src_h = val;
} else if (property == config->rotation_property ||
   property == plane->rotation_property) {
-   if (!is_power_of_2(val & DRM_ROTATE_MASK))
+   if (!is_power_of_2(val & (DRM_ROTATE_MASK | DRM_REFLECT_MASK)))
return -EINVAL;
state->rotation = val;
} else if (property == plane->zpos_property) {



Otherwise, the patches look fine to me.

Thanks,
Archit



v2: Drop the BIT()

Cc: Rob Clark 
Cc: Jilai Wang 
Cc: Archit Taneja 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Rob Clark 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 951c002b05df..2653ad893ebc 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -75,15 +75,11 @@ static void mdp5_plane_install_rotation_property(struct 
drm_device *dev,
!(mdp5_plane->caps & MDP_PIPE_CAP_VFLIP))
return;

-   if (!dev->mode_config.rotation_property)
-   dev->mode_config.rotation_property =
-   drm_mode_create_rotation_property(dev,
-   DRM_ROTATE_0 | DRM_REFLECT_X | DRM_REFLECT_Y);
-
-   if (dev->mode_config.rotation_property)
-   drm_object_attach_property(>base,
-   dev->mode_config.rotation_property,
-   DRM_ROTATE_0);
+   drm_plane_create_rotation_property(plane,
+  DRM_ROTATE_0,
+  DRM_ROTATE_0 |
+  DRM_REFLECT_X |
+  DRM_REFLECT_Y);
 }

 /* helper to install properties which are common to planes and crtcs */



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Move fence cancellation to runtime suspend

[Imre Deak]

On pe, 2016-10-21 at 15:05 +0100, Chris Wilson wrote:
> At the moment, we have dependency on the RPM as a barrier itself in both
> i915_gem_release_all_mmaps() and i915_gem_restore_fences().
> i915_gem_restore_fences() is also called along !runtime pm paths, but we
> can move the markup of lost fences alongside releasing the mmaps into a
> common i915_gem_runtime_suspend(). This has the advantage of locating
> all the tricky barrier dependencies into one location.
> 
> v2: Just mark the fence as invalid (fence->dirty) so that upon waking we
> will be sure to clear the fence after use, or restore it to the correct
> value before use. This makes sure that if the fence is left intact
> across the sleep, we do not leave it pointing to a region of GTT for the
> next unsuspecting user.
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Imre Deak 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_drv.c   |  6 ++
>  drivers/gpu/drm/i915/i915_drv.h   |  3 ++-
>  drivers/gpu/drm/i915/i915_gem.c   | 21 +++--
>  drivers/gpu/drm/i915/i915_gem_fence.c | 12 +---
>  4 files changed, 28 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 885d33f341f3..99e4e044e958 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2278,10 +2278,8 @@ static int vlv_resume_prepare(struct drm_i915_private 
> *dev_priv,
>  
>   vlv_check_no_gt_access(dev_priv);
>  
> - if (rpm_resume) {
> + if (rpm_resume)
>   intel_init_clock_gating(dev);
> - i915_gem_restore_fences(dev);
> - }
>  
>   return ret;
>  }
> @@ -2307,7 +2305,7 @@ static int intel_runtime_suspend(struct device *kdev)
>    * We are safe here against re-faults, since the fault handler takes
>    * an RPM reference.
>    */
> - i915_gem_release_all_mmaps(dev_priv);
> + i915_gem_runtime_suspend(dev_priv);
>  
>   intel_guc_suspend(dev);
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c388361ad717..9434734176a3 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3130,9 +3130,10 @@ void i915_vma_destroy(struct i915_vma *vma);
>  
>  int i915_gem_object_unbind(struct drm_i915_gem_object *obj);
>  int i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
> -void i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv);
>  void i915_gem_release_mmap(struct drm_i915_gem_object *obj);
>  
> +void i915_gem_runtime_suspend(struct drm_i915_private *dev_priv);
> +
>  int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
>  
>  static inline int __sg_page_count(struct scatterlist *sg)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 64a88ce4b3c6..0e26ee96856e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1952,10 +1952,10 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
>   intel_runtime_pm_put(i915);
>  }
>  
> -void
> -i915_gem_release_all_mmaps(struct drm_i915_private *dev_priv)
> +void i915_gem_runtime_suspend(struct drm_i915_private *dev_priv)
>  {
>   struct drm_i915_gem_object *obj, *on;
> + int i;
>  
>   /*
>    * Only called during RPM suspend. All users of the userfault_list
> @@ -1970,6 +1970,23 @@ i915_gem_release_all_mmaps(struct drm_i915_private 
> *dev_priv)
>   drm_vma_node_unmap(>base.vma_node,
>      obj->base.dev->anon_inode->i_mapping);
>   }
> +
> + /* The fence will be lost when the device powers down. If any were
> +  * in use by hardware (i.e. they are pinned), we should not be powering
> +  * down! All other fences will be reacquired by the user upon waking.
> +  */
> + for (i = 0; i < dev_priv->num_fence_regs; i++) {
> + struct drm_i915_fence_reg *reg = _priv->fence_regs[i];
> +
> + if (WARN_ON(reg->pin_count))
> + continue;
> +
> + if (!reg->vma)
> + continue;
> +
> + GEM_BUG_ON(!list_empty(®->vma->obj->userfault_link));
> + reg->dirty = true;
> + }
>  }
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/i915_gem_fence.c 
> b/drivers/gpu/drm/i915/i915_gem_fence.c
> index 67013179b8ed..3c5a8082cac3 100644
> --- a/drivers/gpu/drm/i915/i915_gem_fence.c
> +++ b/drivers/gpu/drm/i915/i915_gem_fence.c
> @@ -343,6 +343,9 @@ i915_vma_get_fence(struct i915_vma *vma)
>   struct drm_i915_fence_reg *fence;
>   struct i915_vma *set = i915_gem_object_is_tiled(vma->obj) ? vma : NULL;
>  
> + /* Note that we revoke fences on runtime suspend. Therefore the user
> +  * must keep the device 

Re: [Intel-gfx] [PATCH igt] igt/kms_flip: Calibrate timestamp errors

[Chris Wilson]

On Mon, Oct 24, 2016 at 11:14:31AM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 09:54:52AM +0100, Chris Wilson wrote:
> Also with this patch we should be able to throw out the hacks for tv-out.
> I only added those because the reported mode-timings are massively off
> (due to the magic tv scaler thing) from the real timestamps we receive.
> Auto-detecting this is much better.

Not quite just yet, we need to split the timing tests into a subgroup
with a subtest per output so that we can skip one without skipping the
others. At the moment, this check makes it bail out on my ctg/ilk who
have a difference of about 50us between measured and expected vblank
interval on LVDS (which is nigh on impossible given our confidence in the
measurement, i.e. about 7 sigma).
 
> And another issue: Failing to match the reported mode timings is a driver
> bug.

Not quite, remember we override the user for fixed mode panels. But yes,
piglit also has a similar expectation that the dotclock we report (via
GetMscRate) in someway corresponds to actual vblank interval.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/4] MAINTAINERS: Add "B:" for URI where to file bugs

[Andrew Donnellan]

On 20/10/16 23:22, Jani Nikula wrote:

Different subsystems and drivers have different preferences for where to
file bugs and what information to include. Add "B:" entry for specifying
the URI for the bug tracker directly, a web page for detailed info on
filing bugs, or a mailto: URI.

Cc: Daniel Vetter 
Cc: Joe Perches 
Cc: Andrew Morton 
Signed-off-by: Jani Nikula 


Both new fields seem like a very, very good idea to me. It'll definitely 
save me a bit of googling and wiki-searching on the rare occasion I 
venture outside powerpc...


For the whole series:

Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

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

Re: [Intel-gfx] [PATCH igt] igt/kms_setmode: Clear all connectors before starting the test

[Chris Wilson]

On Mon, Oct 24, 2016 at 11:04:35AM +0200, Daniel Vetter wrote:
> On Sat, Oct 22, 2016 at 09:32:41AM +0100, Chris Wilson wrote:
> > Before we start trying random combinations of connectors and CRTCs, we
> > should first ensure we have a blank slate so that if we only change a
> > subset of the CRTC we do not conflict with a residual setup on the other
> > CRTC.
> > 
> > Signed-off-by: Chris Wilson 
> > ---
> >  tests/kms_setmode.c | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
> > index 24fb34c..df958f0 100644
> > --- a/tests/kms_setmode.c
> > +++ b/tests/kms_setmode.c
> > @@ -268,6 +268,10 @@ static void setup_crtcs(drmModeRes *resources, struct 
> > connector_config *cconf,
> > int i;
> > int encoder_usage_count[resources->count_encoders];
> >  
> > +   for (i = 0; i < resources->count_crtcs; i++)
> > +   drmModeSetCrtc(drm_fd, resources->crtcs[i],
> > +  0, 0, 0, 0, 0, NULL);
> 
> Shouldn't this be in some modeset helper library, or is kms_setmode not
> using that one? Especially with atomic it's much neater to just clear our
> software state (and then applying all the changes we want in one go).

Otoh, something as simple as kms_setmode, one can argue should just be
using (cleanly and clearly, ofc) the raw interfaces and iterating over them.

kms_setmode_legacy / kms_setcrtc / drm_setcrtc,
kms_setmode_atomic,
igt_setmode / kms_setmode

would all then serve slightly different purposes (both testing and
pedagogy).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt/kms_flip: Calibrate timestamp errors

[Daniel Vetter]

On Mon, Oct 24, 2016 at 09:54:52AM +0100, Chris Wilson wrote:
> We assert that the interval between a vblank and a flip corresponds with
> the computed frametime derived from the modeline. However, historically
> the dotclock is unreliable (in error of about 1%) for VBT supplied data
> about LVDS panels - the situation looks to be much improved with eDP at
> least. The simple fact that we cannot rely on the manufacturer's supplied
> modeline causes us to fail the test. So before we claim a driver failure,
> do a calibration pass and check for inconsistencies with the modeline.
> 
> Signed-off-by: Chris Wilson 

Yeah, throwing some decent stats at this makes sense.

> ---
>  tests/kms_flip.c | 73 
> ++--
>  1 file changed, 71 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_flip.c b/tests/kms_flip.c
> index b30e07c..44aec75 100644
> --- a/tests/kms_flip.c
> +++ b/tests/kms_flip.c
> @@ -26,6 +26,7 @@
>  #endif
>  
>  #include "igt.h"
> +
>  #include 
>  #include 
>  #include 
> @@ -43,6 +44,7 @@
>  #include 
>  #include 
>  
> +#include "igt_stats.h"
>  
>  #define TEST_DPMS(1 << 0)
>  #define TEST_WITH_DUMMY_BCS  (1 << 1)
> @@ -175,6 +177,8 @@ struct test_output {
>   int seq_step;
>   unsigned int pending_events;
>   int flip_count;
> +
> + double ts_error;
>  };
>  
>  
> @@ -698,7 +702,7 @@ static void check_state(const struct test_output *o, 
> const struct event_state *e
> elapsed, expected, expected * 0.005,
> fabs((elapsed - expected) / expected) * 100);
>  
> - igt_assert_f(fabs((elapsed - expected) / expected) <= 0.005,
> + igt_assert_f(fabs(elapsed - expected) / expected <= o->ts_error,
>"inconsistent %s ts/seq: last %ld.%06ld/%u, 
> current %ld.%06ld/%u: elapsed=%.1fus expected=%.1fus\n",
>es->name, es->last_ts.tv_sec, es->last_ts.tv_usec, 
> es->last_seq,
>es->current_ts.tv_sec, es->current_ts.tv_usec, 
> es->current_seq,
> @@ -1301,6 +1305,71 @@ static void free_test_output(struct test_output *o)
>   }
>  }
>  
> +static double calibrate_ts(struct test_output *o, int crtc_idx)
> +{
> +#define CALIBRATE_TS_STEPS 16
> + drmVBlank wait;
> + igt_stats_t stats;
> + uint32_t last_seq;
> + uint64_t last_timestamp;
> + double expected;
> + double mean;
> + double stddev;
> + double median;
> + int n;
> +
> + memset(, 0, sizeof(wait));
> + wait.request.type = kmstest_get_vbl_flag(crtc_idx);
> + wait.request.type |= DRM_VBLANK_ABSOLUTE | DRM_VBLANK_NEXTONMISS;
> + do_or_die(drmWaitVBlank(drm_fd, ));
> +
> + last_seq = wait.reply.sequence;
> + last_timestamp = wait.reply.tval_sec;
> + last_timestamp *= 100;
> + last_timestamp += wait.reply.tval_usec;
> +
> + memset(, 0, sizeof(wait));
> + wait.request.type = kmstest_get_vbl_flag(crtc_idx);
> + wait.request.type |= DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
> + wait.request.sequence = last_seq;
> + for (n = 0; n < CALIBRATE_TS_STEPS; n++) {
> + ++wait.request.sequence;
> + do_or_die(drmWaitVBlank(drm_fd, ));
> + }
> +
> + igt_stats_init_with_size(, CALIBRATE_TS_STEPS);
> + for (n = 0; n < CALIBRATE_TS_STEPS; n++) {
> + struct drm_event_vblank ev;
> + uint64_t now;
> +
> + igt_assert(read(drm_fd, , sizeof(ev)) == sizeof(ev));
> + igt_assert_eq(ev.sequence, last_seq + 1);
> +
> + now = ev.tv_sec;
> + now *= 100;
> + now += ev.tv_usec;
> +
> + igt_stats_push(, now - last_timestamp);
> +
> + last_timestamp = now;
> + last_seq = ev.sequence;
> + }
> +
> + expected = frame_time(o);
> +
> + mean = igt_stats_get_mean();
> + stddev = igt_stats_get_std_deviation();
> + median = igt_stats_get_median();
> +
> + igt_info("Expected frametime: %.0fus; measured %.1fus +- %.3fus 
> accuracy %.2f%%; median %.1fus error=%.1f%%\n",
> +  expected, mean, stddev, 100 * 6 * stddev / mean,
> +  median, 100* fabs(median - expected) / expected);
> + igt_assert(6 * stddev / mean < 0.005); /* 99% accuracy within 0.5% */
> + igt_require(fabs(mean - expected) < 2*stddev);

I think an igt_require_f here with an explanation of what's going on would
be good here.

Also with this patch we should be able to throw out the hacks for tv-out.
I only added those because the reported mode-timings are massively off
(due to the magic tv scaler thing) from the real timestamps we receive.
Auto-detecting this is much better.

And another issue: Failing to match the reported mode timings is a driver
bug. I think a separate testcase which _only_ does the ts calibration (and
makes it a fail/pass instead of require/pass) would be great. 

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Give write permission to gt_boost_freq_mhz

[Chris Wilson]

On Mon, Oct 24, 2016 at 11:05:13AM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 10:00:49AM +0530, Sagar Arun Kamble wrote:
> 
> And uabi change with 0 commit message. This needs to be _much_ better ;-)

A case where the author cut'n'paste the wrong thing because he can't
read S_INCOMPREHENSIBLELINENOISE as opposed to the traditional 0600.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Give write permission to gt_boost_freq_mhz

[Daniel Vetter]

On Mon, Oct 24, 2016 at 11:05:13AM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 10:00:49AM +0530, Sagar Arun Kamble wrote:
> 
> And uabi change with 0 commit message. This needs to be _much_ better ;-)

Also the patch subject isn't really useful: It's a literal translation
from the patch to Enlish, which adds nothing. Much better to summarize a
patch in terms of impacts and goals, e.g. "Allow userspace to set gpu
boost".

Plus of course then explain in the commit message why that is a good idea,
why we need it, testcase and userspace for this and all this stuff.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] igt/kms_setmode: Clear all connectors before starting the test

[Daniel Vetter]

On Sat, Oct 22, 2016 at 09:32:41AM +0100, Chris Wilson wrote:
> Before we start trying random combinations of connectors and CRTCs, we
> should first ensure we have a blank slate so that if we only change a
> subset of the CRTC we do not conflict with a residual setup on the other
> CRTC.
> 
> Signed-off-by: Chris Wilson 
> ---
>  tests/kms_setmode.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
> index 24fb34c..df958f0 100644
> --- a/tests/kms_setmode.c
> +++ b/tests/kms_setmode.c
> @@ -268,6 +268,10 @@ static void setup_crtcs(drmModeRes *resources, struct 
> connector_config *cconf,
>   int i;
>   int encoder_usage_count[resources->count_encoders];
>  
> + for (i = 0; i < resources->count_crtcs; i++)
> + drmModeSetCrtc(drm_fd, resources->crtcs[i],
> +0, 0, 0, 0, 0, NULL);

Shouldn't this be in some modeset helper library, or is kms_setmode not
using that one? Especially with atomic it's much neater to just clear our
software state (and then applying all the changes we want in one go).

But it does get the job done meanwhile, so ack.
-Daniel
> +
>   i = 0;
>   crtc_count = 0;
>   crtc = crtcs;
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Give write permission to gt_boost_freq_mhz

[Daniel Vetter]

On Mon, Oct 24, 2016 at 10:00:49AM +0530, Sagar Arun Kamble wrote:

And uabi change with 0 commit message. This needs to be _much_ better ;-)
-Daniel

> Cc: Chris Wilson 
> Signed-off-by: Sagar Arun Kamble 
> ---
>  drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index 47590ab..3df8d3d 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -460,7 +460,7 @@ static ssize_t gt_min_freq_mhz_store(struct device *kdev,
>  
>  static DEVICE_ATTR(gt_act_freq_mhz, S_IRUGO, gt_act_freq_mhz_show, NULL);
>  static DEVICE_ATTR(gt_cur_freq_mhz, S_IRUGO, gt_cur_freq_mhz_show, NULL);
> -static DEVICE_ATTR(gt_boost_freq_mhz, S_IRUGO, gt_boost_freq_mhz_show, 
> gt_boost_freq_mhz_store);
> +static DEVICE_ATTR(gt_boost_freq_mhz, S_IRUGO | S_IWUSR, 
> gt_boost_freq_mhz_show, gt_boost_freq_mhz_store);
>  static DEVICE_ATTR(gt_max_freq_mhz, S_IRUGO | S_IWUSR, gt_max_freq_mhz_show, 
> gt_max_freq_mhz_store);
>  static DEVICE_ATTR(gt_min_freq_mhz, S_IRUGO | S_IWUSR, gt_min_freq_mhz_show, 
> gt_min_freq_mhz_store);
>  
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/8] drm/i915/gen9+: Program watermarks as a separate step during evasion

[Maarten Lankhorst]

Op 20-10-16 om 20:35 schreef Matt Roper:
> On Wed, Oct 12, 2016 at 03:28:20PM +0200, Maarten Lankhorst wrote:
>> Instead of running the watermark updates from the callbacks run
>> them from a separate hook atomic_evade_watermarks.
>>
>> This also gets rid of the global skl_results, which was required for
>> keeping track of the current atomic commit.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h  |  7 ---
>>  drivers/gpu/drm/i915/intel_display.c | 36 +-
>>  drivers/gpu/drm/i915/intel_drv.h |  7 ---
>>  drivers/gpu/drm/i915/intel_pm.c  | 38 
>> ++--
>>  drivers/gpu/drm/i915/intel_sprite.c  | 18 -
>>  5 files changed, 28 insertions(+), 78 deletions(-)
>>
> ...
>> @@ -14436,8 +14413,13 @@ static void intel_atomic_commit_tail(struct 
>> drm_atomic_state *state)
>>  intel_check_cpu_fifo_underruns(dev_priv);
>>  intel_check_pch_fifo_underruns(dev_priv);
>>  
>> -if (!crtc->state->active)
>> -intel_update_watermarks(crtc);
>> +if (!crtc->state->active) {
>> +if (dev_priv->display.initial_watermarks)
>> +
>> dev_priv->display.initial_watermarks(intel_state,
>> + 
>> to_intel_crtc_state(crtc->state));
>> +else
>> +intel_update_watermarks(crtc);
>> +}
>>  }
> This will change the behavior on ILK-style platforms won't it?
> Previously the intel_update_watermarks here was a noop on those
> platforms, but now we're calling initial_watermarks after the CRTC is
> disabled there (note that there's also a call to it in pre_plane_update
> that we purposely skip when doing any kind of modeset).
Yeah, it could be better to change it to if (HAS_DDI(dev_priv)), that way it's 
not going to matter..
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Always send a hotplug event after resume

[Daniel Vetter]

On Fri, Oct 21, 2016 at 04:27:53PM +0100, Chris Wilson wrote:
> On Fri, Oct 21, 2016 at 11:16:07AM +0100, Chris Wilson wrote:
> > Curently after resume we reset all connector status to unknown and then
> > try to tell userspace about the probable changes (e.g. a laptop being
> > unplugged from one dock and plugged into another). However, we call
> > drm_helper_hpd_irq_event() to send the hotplug event to userspace which
> > first does a check of connector->status before deciding if userspace
> > needs to know about the event. This will filter out the above scenario
> > of one output being replaced because it only checks the status and not
> > whether the output is the same.
> > 
> > Always send the hotplug uevent to userspace upon resume, and force it to
> > reprobe.
> 
> Bah, since we no longer set the status to unknown, this alone is not
> enough to undo the damage.

I think we could fix this with the probe timestamp - if we read a new edid
(the edid function in drm_mode.c could compare the contents) we increment
the refcount. If the probe count changes on any of them, we fire the uevent
away. At least that's kinda been my master plan to fix this mess: Instead
of trying to make the right guess at the top-level code (like resume
here), or trying to wire up fragile change reporting up our massive probe
call-chains we do the detection at the very leaves. And the top level
(well the helpers in drm_probe_helper.s) just watch that probe counter for
changes.

For even more safety we could store the probe counter for each uevent in
drm_connector.c (and compare it with the new one every time the uevent
helper is called), and so even avoid duplicating that bit of logic.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt/kms_flip: Calibrate timestamp errors

[Chris Wilson]

We assert that the interval between a vblank and a flip corresponds with
the computed frametime derived from the modeline. However, historically
the dotclock is unreliable (in error of about 1%) for VBT supplied data
about LVDS panels - the situation looks to be much improved with eDP at
least. The simple fact that we cannot rely on the manufacturer's supplied
modeline causes us to fail the test. So before we claim a driver failure,
do a calibration pass and check for inconsistencies with the modeline.

Signed-off-by: Chris Wilson 
---
 tests/kms_flip.c | 73 ++--
 1 file changed, 71 insertions(+), 2 deletions(-)

diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index b30e07c..44aec75 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -26,6 +26,7 @@
 #endif
 
 #include "igt.h"
+
 #include 
 #include 
 #include 
@@ -43,6 +44,7 @@
 #include 
 #include 
 
+#include "igt_stats.h"
 
 #define TEST_DPMS  (1 << 0)
 #define TEST_WITH_DUMMY_BCS(1 << 1)
@@ -175,6 +177,8 @@ struct test_output {
int seq_step;
unsigned int pending_events;
int flip_count;
+
+   double ts_error;
 };
 
 
@@ -698,7 +702,7 @@ static void check_state(const struct test_output *o, const 
struct event_state *e
  elapsed, expected, expected * 0.005,
  fabs((elapsed - expected) / expected) * 100);
 
-   igt_assert_f(fabs((elapsed - expected) / expected) <= 0.005,
+   igt_assert_f(fabs(elapsed - expected) / expected <= o->ts_error,
 "inconsistent %s ts/seq: last %ld.%06ld/%u, 
current %ld.%06ld/%u: elapsed=%.1fus expected=%.1fus\n",
 es->name, es->last_ts.tv_sec, es->last_ts.tv_usec, 
es->last_seq,
 es->current_ts.tv_sec, es->current_ts.tv_usec, 
es->current_seq,
@@ -1301,6 +1305,71 @@ static void free_test_output(struct test_output *o)
}
 }
 
+static double calibrate_ts(struct test_output *o, int crtc_idx)
+{
+#define CALIBRATE_TS_STEPS 16
+   drmVBlank wait;
+   igt_stats_t stats;
+   uint32_t last_seq;
+   uint64_t last_timestamp;
+   double expected;
+   double mean;
+   double stddev;
+   double median;
+   int n;
+
+   memset(, 0, sizeof(wait));
+   wait.request.type = kmstest_get_vbl_flag(crtc_idx);
+   wait.request.type |= DRM_VBLANK_ABSOLUTE | DRM_VBLANK_NEXTONMISS;
+   do_or_die(drmWaitVBlank(drm_fd, ));
+
+   last_seq = wait.reply.sequence;
+   last_timestamp = wait.reply.tval_sec;
+   last_timestamp *= 100;
+   last_timestamp += wait.reply.tval_usec;
+
+   memset(, 0, sizeof(wait));
+   wait.request.type = kmstest_get_vbl_flag(crtc_idx);
+   wait.request.type |= DRM_VBLANK_ABSOLUTE | DRM_VBLANK_EVENT;
+   wait.request.sequence = last_seq;
+   for (n = 0; n < CALIBRATE_TS_STEPS; n++) {
+   ++wait.request.sequence;
+   do_or_die(drmWaitVBlank(drm_fd, ));
+   }
+
+   igt_stats_init_with_size(, CALIBRATE_TS_STEPS);
+   for (n = 0; n < CALIBRATE_TS_STEPS; n++) {
+   struct drm_event_vblank ev;
+   uint64_t now;
+
+   igt_assert(read(drm_fd, , sizeof(ev)) == sizeof(ev));
+   igt_assert_eq(ev.sequence, last_seq + 1);
+
+   now = ev.tv_sec;
+   now *= 100;
+   now += ev.tv_usec;
+
+   igt_stats_push(, now - last_timestamp);
+
+   last_timestamp = now;
+   last_seq = ev.sequence;
+   }
+
+   expected = frame_time(o);
+
+   mean = igt_stats_get_mean();
+   stddev = igt_stats_get_std_deviation();
+   median = igt_stats_get_median();
+
+   igt_info("Expected frametime: %.0fus; measured %.1fus +- %.3fus 
accuracy %.2f%%; median %.1fus error=%.1f%%\n",
+expected, mean, stddev, 100 * 6 * stddev / mean,
+median, 100* fabs(median - expected) / expected);
+   igt_assert(6 * stddev / mean < 0.005); /* 99% accuracy within 0.5% */
+   igt_require(fabs(mean - expected) < 2*stddev);
+
+   return 2*fabs(median - expected) / expected;
+}
+
 static void run_test_on_crtc_set(struct test_output *o, int *crtc_idxs,
 int crtc_count, int duration_ms)
 {
@@ -1404,7 +1473,7 @@ static void run_test_on_crtc_set(struct test_output *o, 
int *crtc_idxs,
 
/* quiescent the hw a bit so ensure we don't miss a single frame */
if (o->flags & TEST_CHECK_TS)
-   sleep(1);
+   o->ts_error = calibrate_ts(o, crtc_idxs[0]);
 
igt_assert_eq(do_page_flip(o, o->fb_ids[1], true), 0);
wait_for_events(o);
-- 
2.10.1

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

Re: [Intel-gfx] [PATCH] drm/i915: remove AGP dependency from DRM_I915 kconfig help text

[Daniel Vetter]

On Fri, Oct 21, 2016 at 12:14:17PM +0300, Jani Nikula wrote:
> We haven't required AGP since 3e99a6b95614 ("drm/i915: Stop depending
> upon CONFIG_AGP_INTEL"). Split/rearrange the paragraphs a bit while at
> it.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/Kconfig | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 1c1b19ccb92f..45a5eb71e8e6 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -24,16 +24,17 @@ config DRM_I915
> including 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G,
> G35, G41, G43, G45 chipsets and Celeron, Pentium, Core i3,
> Core i5, Core i7 as well as Atom CPUs with integrated graphics.

Hm, nowadays it's called Intel HD graphics. Maybe we should mention that?
Feel free to add that.

> -   If M is selected, the module will be called i915.  AGP support
> -   is required for this driver to work. This driver is used by
> -   the Intel driver in X.org 6.8 and XFree86 4.4 and above. It
> -   replaces the older i830 module that supported a subset of the
> -   hardware in older X.org releases.
> +
> +   This driver is used by the Intel driver in X.org 6.8 and
> +   XFree86 4.4 and above. It replaces the older i830 module that
> +   supported a subset of the hardware in older X.org releases.
>  
> Note that the older i810/i815 chipsets require the use of the
> i810 driver instead, and the Atom z5xx series has an entirely
> different implementation.
>  
> +   If "M" is selected, the module will be called i915.
> +
>  config DRM_I915_PRELIMINARY_HW_SUPPORT
>   bool "Enable preliminary support for prerelease Intel hardware by 
> default"
>   depends on DRM_I915
> -- 
> 2.1.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Redo a modeset on link training failure

[Daniel Vetter]

On Fri, Oct 21, 2016 at 12:35:44PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 20, 2016 at 07:31:53PM -0700, Manasi Navare wrote:
> > Hi Ville,
> > 
> > I have implemented the code that we discussed where if the link training
> > fails, it would validate the modes on the new constraints and call
> > an atomic helper like drm_atomic_helper_connector_modeset() to redo
> > a modeset for the same mode. The two patches for this implemnetation is
> > are:
> > 
> > http://paste.ubuntu.com/23357104/
> > http://paste.ubuntu.com/23357105/
> > 
> > With this I can successfully trigger the modeset and retrain the link
> > at lower link rate. But I am getting a warning during 
> > intel_audio_codec_enable()
> > in intel_enable_ddi() during the commit phase on SKL.
> > Following is the dmesg log:
> > 
> > http://paste.ubuntu.com/23357075/
> > 
> > After further looking at it, I see that this calls drm_select_eld() function
> > that throws a warning if the mode_config mutex and modeset locks are held.
> 
> You get the warn when they're *not* held. And checking for the
> mode_config.mutex here looks like a bug. We call that during a modeset,
> so if we get there through the atomic ioctl as opposed to a legacy
> setcrtc we will not be holding the mode_config.mutex.
> 
> Walking the connector list with just the connection mutex should be safe
> in theory. Although last I looked it was still racy as hell, but as I
> said, in theory.
> 
> We could probably drop the connector list walk from there entirely since
> we should know exactly which connector's eld we want.

Yes, lets please avoid connector_list walks if we know what we're doing.
Which we really should here with link training.

Also spoiler on connector_list locking: It's probably going to be an
entirely new locking scheme for this one, independent of either
mode_config.mutex and mode_config.connection_mutex. Most likely invovling
some kind of rcu.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/8] drm/i915/gen9+: Preserve old allocation from crtc_state.

[Maarten Lankhorst]

Op 21-10-16 om 00:09 schreef Matt Roper:
> On Wed, Oct 12, 2016 at 03:28:21PM +0200, Maarten Lankhorst wrote:
>> This is the last bit required for making nonblocking modesets work
>> correctly. The state in intel_crtc->hw_ddb is not updated until
>> somewhere in atomic commit, while the previous crtc state should be
>> accurate if the ddb hasn't changed.
>>
>> Signed-off-by: Maarten Lankhorst 
> Can we get rid of hw_ddb completely and always pull from old state?  It
> looks like the only other place it's still used is
> skl_update_crtcs() -> skl_ddb_allocation_overlaps().
Probably as a followup patch. I kept it only for that reason indeed.

I suppose it could be changed to if (updated) state = new_state->ddb else state 
= old_state->ddb.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 0/3] Convert sh scripts to C variants.

[Daniel Vetter]

On Mon, Oct 24, 2016 at 10:46:14AM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 10:38:17AM +0300, Joonas Lahtinen wrote:
> > On pe, 2016-10-21 at 00:00 +0300, Jani Nikula wrote:
> > > > On Thu, 20 Oct 2016, Marius Vlad  wrote:
> > > > 
> > > > This series adds some library support to help converting sh
> > > > scripts to C version. Converted drv_module_reload_basic and
> > > > kms_sysfs_edid_timing.
> > > 
> > > > 
> > > >  18 files changed, 600 insertions(+), 180 deletions(-)
> > > 
> > > Someone please justify this, plus pulling in two new dependencies. I can
> > > think of a thing or two, but it needs to be in the commit messages. And
> > > I'm not convinced by the justification I came up with.
> 
> - Be able to reuse the subtest/logging/whatever else igt stuff for more
>   consistency, without having to reinvent the wheel in the bash world a
>   2nd time. Often this is also tricky (we have unit tests for igt
>   libraries for a reason). I rejected C++ as a new language for similar
>   reasons, I think getting rid of bash is useful.
> 
> - dmesg logging. Imo the piglit dmesg capturing serious sucks, it'd be
>   great to move it into igt. Reasons for that: a) in C it's much faster,
>   b) integrated with igt logging (consistent timestamps, ordering,
>   crashbox log, ...) c) we could put the filtering of dmesg next to the
>   tests, atm it's some rough filter in piglit's igt.py. c) has been one of
>   Chris' wishlist things, e.g. make underrun tests hunt for underruns
>   explicitly.
> 
> - It's a nice ramp-up task for igt, that's why I bumped it up a bit. Would
>   be fairly low-prio otherwise.
> 
> > Hmm, not sure how Daniel instructed things. Original idea was to just
> > execv the same commands as the scripts do. To get rid of the
> > interpreter differences and allow running in a minimal environment.
> 
> Yeah, I was thinking of a pretty minimal conversion to C with just lots of
> calls to system. Maybe long-term we could extract some shared code, but
> meh. Creating good libraries is a lot more work than it generally looks
> like, and code reuse for code reuse's sake is in my experience often not
> worth the hassle.

On that note, we'd probably need an igt helper to run a shell command with
full igt integration. The important bits there would be to read
stderr/stdout and feed them into igt_warn and igt_debug levels. Of course
in parallel to running the command to make sure the timestamps are
correct, and will line up with the dmesg timestampes. And long-term also
interleave with dmesg output (once we've moded that into igt proper).

That function also needs some flags to optionally ignore stderr or stdout,
which essentially would be reimplenting > /dev/null and &> /dev/null.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND PATCH 4/6] drm/i915: Update atomic modeset state synchronously

[Maarten Lankhorst]

Op 21-10-16 om 16:21 schreef Ville Syrjälä:
> On Wed, Oct 19, 2016 at 03:55:37PM +0200, Maarten Lankhorst wrote:
>> All of this state should be updated as soon as possible. It shouldn't be
>> done later because then future updates may not depend on it.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 15 ---
>>  1 file changed, 8 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 69b9e91f071e..ba7f7be3aa4f 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14341,14 +14341,8 @@ static void intel_atomic_commit_tail(struct 
>> drm_atomic_state *state)
>>  
>>  drm_atomic_helper_wait_for_dependencies(state);
>>  
>> -if (intel_state->modeset) {
>> -memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
>> -   sizeof(intel_state->min_pixclk));
>> -dev_priv->active_crtcs = intel_state->active_crtcs;
>> -dev_priv->atomic_cdclk_freq = intel_state->cdclk;
>> -
>> +if (intel_state->modeset)
>>  intel_display_power_get(dev_priv, POWER_DOMAIN_MODESET);
>> -}
>>  
>>  for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
>>  struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> @@ -14558,6 +14552,13 @@ static int intel_atomic_commit(struct drm_device 
>> *dev,
>>  intel_atomic_track_fbs(state);
>>  
>>  drm_atomic_state_get(state);
>> +if (intel_state->modeset) {
>> +memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
>> +   sizeof(intel_state->min_pixclk));
>> +dev_priv->active_crtcs = intel_state->active_crtcs;
>> +dev_priv->atomic_cdclk_freq = intel_state->cdclk;
>> +}
> The placement after the _get() looks a bit weird. The other parts of the
> state were flipped over before the _get(), so putting this next to the
> other would make it look less magicy.
>
That's fine, this patch was rebased after thje drm_atomic_state_get was added, 
which explains the placement.

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

Re: [Intel-gfx] [PATCH i-g-t 0/3] Convert sh scripts to C variants.

[Daniel Vetter]

On Fri, Oct 21, 2016 at 10:38:17AM +0300, Joonas Lahtinen wrote:
> On pe, 2016-10-21 at 00:00 +0300, Jani Nikula wrote:
> > > On Thu, 20 Oct 2016, Marius Vlad  wrote:
> > > 
> > > This series adds some library support to help converting sh
> > > scripts to C version. Converted drv_module_reload_basic and
> > > kms_sysfs_edid_timing.
> > 
> > > 
> > >  18 files changed, 600 insertions(+), 180 deletions(-)
> > 
> > Someone please justify this, plus pulling in two new dependencies. I can
> > think of a thing or two, but it needs to be in the commit messages. And
> > I'm not convinced by the justification I came up with.

- Be able to reuse the subtest/logging/whatever else igt stuff for more
  consistency, without having to reinvent the wheel in the bash world a
  2nd time. Often this is also tricky (we have unit tests for igt
  libraries for a reason). I rejected C++ as a new language for similar
  reasons, I think getting rid of bash is useful.

- dmesg logging. Imo the piglit dmesg capturing serious sucks, it'd be
  great to move it into igt. Reasons for that: a) in C it's much faster,
  b) integrated with igt logging (consistent timestamps, ordering,
  crashbox log, ...) c) we could put the filtering of dmesg next to the
  tests, atm it's some rough filter in piglit's igt.py. c) has been one of
  Chris' wishlist things, e.g. make underrun tests hunt for underruns
  explicitly.

- It's a nice ramp-up task for igt, that's why I bumped it up a bit. Would
  be fairly low-prio otherwise.

> Hmm, not sure how Daniel instructed things. Original idea was to just
> execv the same commands as the scripts do. To get rid of the
> interpreter differences and allow running in a minimal environment.

Yeah, I was thinking of a pretty minimal conversion to C with just lots of
calls to system. Maybe long-term we could extract some shared code, but
meh. Creating good libraries is a lot more work than it generally looks
like, and code reuse for code reuse's sake is in my experience often not
worth the hassle.

> I'm myself fine with using the libraries too, I think the tests can
> then be improved upon, just like Chris has commented on a few of them.

Yeah, not against it, but maybe as step 2.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

[Maarten Lankhorst]

Op 21-10-16 om 16:16 schreef Ville Syrjälä:
> On Fri, Oct 21, 2016 at 05:04:46PM +0300, Ville Syrjälä wrote:
>> On Wed, Oct 19, 2016 at 03:55:35PM +0200, Maarten Lankhorst wrote:
>>> drm_select_eld requires mode_config.mutex and connection_mutex
>>> because it looks at the connector list and at the legacy encoders.
>>>
>>> This is not required, because when we call audio_codec_enable we know
>>> which connector it was called for, so pass the state.
>>>
>>> This also removes having to look at crtc->config.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>>> ---
>>>  drivers/gpu/drm/i915/intel_audio.c | 17 ++---
>>>  drivers/gpu/drm/i915/intel_ddi.c   |  2 +-
>>>  drivers/gpu/drm/i915/intel_dp.c| 11 ++-
>>>  drivers/gpu/drm/i915/intel_drv.h   |  4 +++-
>>>  drivers/gpu/drm/i915/intel_hdmi.c  |  2 +-
>>>  5 files changed, 21 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_audio.c 
>>> b/drivers/gpu/drm/i915/intel_audio.c
>>> index 7093cfbb62b1..63ef25893c7e 100644
>>> --- a/drivers/gpu/drm/i915/intel_audio.c
>>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>>> @@ -485,23 +485,26 @@ static void ilk_audio_codec_enable(struct 
>>> drm_connector *connector,
>>>  /**
>>>   * intel_audio_codec_enable - Enable the audio codec for HD audio
>>>   * @intel_encoder: encoder on which to enable audio
>>> + * @crtc_state: pointer to the current crtc state.
>>> + * @conn_state: pointer to the current connector state.
>>>   *
>>>   * The enable sequences may only be performed after enabling the 
>>> transcoder and
>>>   * port, and after completed link training.
>>>   */
>>> -void intel_audio_codec_enable(struct intel_encoder *intel_encoder)
>>> +void intel_audio_codec_enable(struct intel_encoder *intel_encoder,
>>> + const struct intel_crtc_state *crtc_state,
>>> + const struct drm_connector_state *conn_state)
>>>  {
>>> struct drm_encoder *encoder = _encoder->base;
>>> -   struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
>>> -   const struct drm_display_mode *adjusted_mode = 
>>> >config->base.adjusted_mode;
>>> +   const struct drm_display_mode *adjusted_mode = 
>>> _state->base.adjusted_mode;
>>> struct drm_connector *connector;
>>> struct drm_i915_private *dev_priv = to_i915(encoder->dev);
>>> struct i915_audio_component *acomp = dev_priv->audio_component;
>>> enum port port = intel_encoder->port;
>>> -   enum pipe pipe = crtc->pipe;
>>> +   enum pipe pipe = drm_crtc_index(crtc_state->base.crtc);
>> While we may require that to be true, I'm not sure I like this use.
> I should say that otherwise I like this.
What do you mean with this comment?

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

Re: [Intel-gfx] [RESEND PATCH 3/6] drm/edid: Remove drm_select_eld

[Maarten Lankhorst]

Op 21-10-16 om 16:17 schreef Ville Syrjälä:
> On Fri, Oct 21, 2016 at 05:05:16PM +0300, Ville Syrjälä wrote:
>> On Wed, Oct 19, 2016 at 03:55:36PM +0200, Maarten Lankhorst wrote:
>>> The only user was i915, which is now gone.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>> cc: dri-devel missing
> Also
> Reviewed-by: Ville Syrjälä 
Indeed, I'll ask for a ack from a drm maintainer.
>>> ---
>>>  drivers/gpu/drm/drm_edid.c | 26 --
>>>  include/drm/drm_edid.h |  1 -
>>>  2 files changed, 27 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>>> index 95de47ba1e77..fc81e0eb6abf 100644
>>> --- a/drivers/gpu/drm/drm_edid.c
>>> +++ b/drivers/gpu/drm/drm_edid.c
>>> @@ -3578,32 +3578,6 @@ int drm_av_sync_delay(struct drm_connector 
>>> *connector,
>>>  EXPORT_SYMBOL(drm_av_sync_delay);
>>>  
>>>  /**
>>> - * drm_select_eld - select one ELD from multiple HDMI/DP sinks
>>> - * @encoder: the encoder just changed display mode
>>> - *
>>> - * It's possible for one encoder to be associated with multiple HDMI/DP 
>>> sinks.
>>> - * The policy is now hard coded to simply use the first HDMI/DP sink's ELD.
>>> - *
>>> - * Return: The connector associated with the first HDMI/DP sink that has 
>>> ELD
>>> - * attached to it.
>>> - */
>>> -struct drm_connector *drm_select_eld(struct drm_encoder *encoder)
>>> -{
>>> -   struct drm_connector *connector;
>>> -   struct drm_device *dev = encoder->dev;
>>> -
>>> -   WARN_ON(!mutex_is_locked(>mode_config.mutex));
>>> -   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>>> -
>>> -   drm_for_each_connector(connector, dev)
>>> -   if (connector->encoder == encoder && connector->eld[0])
>>> -   return connector;
>>> -
>>> -   return NULL;
>>> -}
>>> -EXPORT_SYMBOL(drm_select_eld);
>>> -
>>> -/**
>>>   * drm_detect_hdmi_monitor - detect whether monitor is HDMI
>>>   * @edid: monitor EDID information
>>>   *
>>> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
>>> index c3a7d440bc11..38eabf65f19d 100644
>>> --- a/include/drm/drm_edid.h
>>> +++ b/include/drm/drm_edid.h
>>> @@ -330,7 +330,6 @@ int drm_edid_to_sad(struct edid *edid, struct cea_sad 
>>> **sads);
>>>  int drm_edid_to_speaker_allocation(struct edid *edid, u8 **sadb);
>>>  int drm_av_sync_delay(struct drm_connector *connector,
>>>   const struct drm_display_mode *mode);
>>> -struct drm_connector *drm_select_eld(struct drm_encoder *encoder);
>>>  
>>>  #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
>>>  int drm_load_edid_firmware(struct drm_connector *connector);
>>> -- 
>>> 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


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