[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: BUG_ON when ggtt_view is NULL
== Series Details == Series: drm/i915: BUG_ON when ggtt_view is NULL URL : https://patchwork.freedesktop.org/series/4869/ State : success == Summary == Series 4869v1 drm/i915: BUG_ON when ggtt_view is NULL http://patchwork.freedesktop.org/api/1.0/series/4869/revisions/1/mbox/ bdw-nuci7total:192 pass:179 dwarn:0 dfail:0 fail:1 skip:12 bdw-ultratotal:192 pass:170 dwarn:0 dfail:0 fail:1 skip:21 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1714/ f5d413cccefa1f93d64c34f357151d42add63a84 drm-intel-nightly: 2016y-03m-24d-14h-34m-29s UTC integration manifest 2762cb3f5c3b27515488300257f4ebe7807a1670 drm/i915: BUG_ON when ggtt_view is NULL ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] shmem: Support for registration of Driver/file owner specific ops (rev2)
== Series Details == Series: series starting with [1/2] shmem: Support for registration of Driver/file owner specific ops (rev2) URL : https://patchwork.freedesktop.org/series/4780/ State : warning == Summary == Series 4780v2 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/4780/revisions/2/mbox/ Test pm_rpm: Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:192 pass:179 dwarn:0 dfail:0 fail:1 skip:12 bdw-ultratotal:192 pass:170 dwarn:0 dfail:0 fail:1 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1715/ f5d413cccefa1f93d64c34f357151d42add63a84 drm-intel-nightly: 2016y-03m-24d-14h-34m-29s UTC integration manifest bbbf884d78807182d2756e2c7606e92f529c4d71 drm/i915: Make pages of GFX allocations movable c01a1b101822ef3eb364395db02c1f0aeeddcb02 shmem: Support for registration of Driver/file owner specific ops ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/2,RESEND] drm/dp_helper: add workarounds from intel_dp_dpcd_read_wake()
== Series Details == Series: series starting with [v3,1/2,RESEND] drm/dp_helper: add workarounds from intel_dp_dpcd_read_wake() URL : https://patchwork.freedesktop.org/series/4828/ State : failure == Summary == Series 4828v1 Series without cover letter 2016-03-24T18:06:07.506472 http://patchwork.freedesktop.org/api/1.0/series/4828/revisions/1/mbox/ Applying: drm/dp_helper: add workarounds from intel_dp_dpcd_read_wake() Applying: drm/dp_helper: Always wait before retrying native aux transactions Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0002 drm/dp_helper: Always wait before retrying native aux transactions ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm: add picture aspect ratio flags
This patch adds drm flag bits for aspect ratio information Currently drm flag bits don't have field for mode's picture aspect ratio. This field will help the driver to pick mode with right aspect ratio, and help in setting right VIC field in avi infoframes. Signed-off-by: Shashank Sharma --- include/uapi/drm/drm_mode.h | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index c021743..0dc9f6b 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -73,6 +73,19 @@ #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14) #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14) +/* Picture aspect ratio options */ +#define DRM_MODE_PICTURE_ASPECT_NONE 0 +#define DRM_MODE_PICTURE_ASPECT_4_31 +#define DRM_MODE_PICTURE_ASPECT_16_9 2 + +/* Aspect ratio flag bitmask (4 bits 21:19) */ +#define DRM_MODE_FLAG_PARMASK (0x0F<<19) +#define DRM_MODE_FLAG_PARNONE \ + (DRM_MODE_PICTURE_ASPECT_NONE << 19) +#define DRM_MODE_FLAG_PAR4_3 \ + (DRM_MODE_PICTURE_ASPECT_4_3 << 19) +#define DRM_MODE_FLAG_PAR16_9 \ + (DRM_MODE_PICTURE_ASPECT_16_9 << 19) /* DPMS flags */ /* bit compatible with the xorg definitions. */ @@ -88,11 +101,6 @@ #define DRM_MODE_SCALE_CENTER 2 /* Centered, no scaling */ #define DRM_MODE_SCALE_ASPECT 3 /* Full screen, preserve aspect */ -/* Picture aspect ratio options */ -#define DRM_MODE_PICTURE_ASPECT_NONE 0 -#define DRM_MODE_PICTURE_ASPECT_4_31 -#define DRM_MODE_PICTURE_ASPECT_16_9 2 - /* Dithering mode options */ #define DRM_MODE_DITHERING_OFF 0 #define DRM_MODE_DITHERING_ON 1 -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm: Add aspect ratio parsing in DRM layer
Current DRM layer functions dont parse aspect ratio information
while converting a user mode->kernel mode or viceversa. This
causes modeset to pick mode with wrong aspect ratio, eventually
cauing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).
Signed-off-by: Shashank Sharma
Signed-off-by: Lin, Jia
Signed-off-by: Akashdeep Sharma
---
drivers/gpu/drm/drm_modes.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f7448a5..6e66136 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -939,6 +939,9 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode
*mode1, const struct
(mode2->flags & DRM_MODE_FLAG_3D_MASK))
return false;
+ if (mode1->picture_aspect_ratio != mode2->picture_aspect_ratio)
+ return false;
+
return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
}
EXPORT_SYMBOL(drm_mode_equal_no_clocks);
@@ -967,6 +970,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+ mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1469,6 +1473,22 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+ out->flags &= ~DRM_MODE_FLAG_PARMASK;
+
+ switch (in->picture_aspect_ratio) {
+ case HDMI_PICTURE_ASPECT_4_3:
+ out->flags |= DRM_MODE_FLAG_PAR4_3;
+ break;
+ case HDMI_PICTURE_ASPECT_16_9:
+ out->flags |= DRM_MODE_FLAG_PAR16_9;
+ break;
+ case HDMI_PICTURE_ASPECT_NONE:
+ case HDMI_PICTURE_ASPECT_RESERVED:
+ default:
+ out->flags |= DRM_MODE_FLAG_PARNONE;
+ break;
+ }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
}
@@ -1514,6 +1534,20 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
+ /* Clearing picture aspect ratio bits from out flags */
+ out->flags &= ~DRM_MODE_FLAG_PARMASK;
+
+ switch (in->flags & DRM_MODE_FLAG_PARMASK) {
+ case DRM_MODE_FLAG_PAR4_3:
+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+ break;
+ case DRM_MODE_FLAG_PAR16_9:
+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+ break;
+ default:
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+ }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] Add aspect ratio parsing
Currently DRM framework doesn't parse aspect ratio of a videomode while converting it from a umode->kmode or viceversa. This causes modeset of CEA modes with incorrect aspect ratio. While running HDMI complaince, tests (like 7-27) expect the DUT to apply the mode as per the VIC, but as driver does not consider the aspect ratio part while searching a mode from modedb, we end up setting mode with a wrong VIC, causing the test to fail. What this patch set does: Patch 1-2 - Adds aspect ratio flags in the DRM layer, in form of flags. - Adds parsing of aspect ratio, during conversion of a umode->kmode and viceversa. - Adds aspect ratio check while finding a mode, during modeset. Patch 3-5 - Adds some new aspect ratio defined in CEA-861-F specs to support HDMI 2.0 displays, in DRM and I915 layer. Shashank Sharma (5): drm: add picture aspect ratio flags drm: Add aspect ratio parsing in DRM layer video: Add new aspect ratios for HDMI 2.0 drm: Add flags for new aspect ratios drm/i915: Add support for new aspect ratios drivers/gpu/drm/drm_modes.c | 46 +++ drivers/gpu/drm/i915/intel_hdmi.c | 6 + drivers/gpu/drm/i915/intel_sdvo.c | 6 + drivers/video/hdmi.c | 4 include/linux/hdmi.h | 2 ++ include/uapi/drm/drm_mode.h | 24 +++- 6 files changed, 83 insertions(+), 5 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] video: Add new aspect ratios for HDMI 2.0
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.
Signed-off-by: Shashank Sharma
---
drivers/video/hdmi.c | 4
include/linux/hdmi.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+ case HDMI_PICTURE_ASPECT_64_27:
+ return "64:27";
+ case HDMI_PICTURE_ASPECT_256_135:
+ return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+ HDMI_PICTURE_ASPECT_64_27,
+ HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm: Add flags for new aspect ratios
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds DRM flags for the new aspect ratios in the existing aspect ratio flags. Signed-off-by: Shashank Sharma --- include/uapi/drm/drm_mode.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 0dc9f6b..05a808d 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -77,6 +77,8 @@ #define DRM_MODE_PICTURE_ASPECT_NONE 0 #define DRM_MODE_PICTURE_ASPECT_4_31 #define DRM_MODE_PICTURE_ASPECT_16_9 2 +#define DRM_MODE_PICTURE_ASPECT_64_27 3 +#define DRM_MODE_PICTURE_ASPECT_256_1354 /* Aspect ratio flag bitmask (4 bits 21:19) */ #define DRM_MODE_FLAG_PARMASK (0x0F<<19) @@ -86,6 +88,10 @@ (DRM_MODE_PICTURE_ASPECT_4_3 << 19) #define DRM_MODE_FLAG_PAR16_9 \ (DRM_MODE_PICTURE_ASPECT_16_9 << 19) +#define DRM_MODE_FLAG_PAR64_27 \ + (DRM_MODE_PICTURE_ASPECT_64_27 << 19) +#define DRM_MODE_FLAG_PAR256_135 \ + (DRM_MODE_PICTURE_ASPECT_256_135 << 19) /* DPMS flags */ /* bit compatible with the xorg definitions. */ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Add support for new aspect ratios
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds support for these aspect ratios in I915 driver, at various places. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_modes.c | 12 drivers/gpu/drm/i915/intel_hdmi.c | 6 ++ drivers/gpu/drm/i915/intel_sdvo.c | 6 ++ 3 files changed, 24 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 6e66136..11f219a 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1482,6 +1482,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out, case HDMI_PICTURE_ASPECT_16_9: out->flags |= DRM_MODE_FLAG_PAR16_9; break; + case HDMI_PICTURE_ASPECT_64_27: + out->flags |= DRM_MODE_FLAG_PAR64_27; + break; + case DRM_MODE_PICTURE_ASPECT_256_135: + out->flags |= DRM_MODE_FLAG_PAR256_135; + break; case HDMI_PICTURE_ASPECT_NONE: case HDMI_PICTURE_ASPECT_RESERVED: default: @@ -1544,6 +1550,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out, case DRM_MODE_FLAG_PAR16_9: out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_FLAG_PAR64_27: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_FLAG_PAR256_135: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135; + break; default: out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index e2dab48..bc8e2c8 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1545,6 +1545,12 @@ intel_hdmi_set_property(struct drm_connector *connector, case DRM_MODE_PICTURE_ASPECT_16_9: intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_PICTURE_ASPECT_64_27: + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_PICTURE_ASPECT_256_135: + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; + break; default: return -EINVAL; } diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index fae64bc..370e4f9 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -2071,6 +2071,12 @@ intel_sdvo_set_property(struct drm_connector *connector, case DRM_MODE_PICTURE_ASPECT_16_9: intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_PICTURE_ASPECT_64_27: + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_PICTURE_ASPECT_256_135: + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; + break; default: return -EINVAL; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v3,1/2] drm/i915/guc: Reset GuC and retry on firmware load failure
== Series Details == Series: series starting with [v3,1/2] drm/i915/guc: Reset GuC and retry on firmware load failure URL : https://patchwork.freedesktop.org/series/4876/ State : warning == Summary == Series 4876v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/4876/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-rte: dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:179 dwarn:0 dfail:0 fail:1 skip:12 bdw-ultratotal:192 pass:170 dwarn:0 dfail:0 fail:1 skip:21 bsw-nuc-2total:192 pass:153 dwarn:2 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:157 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1717/ f5d413cccefa1f93d64c34f357151d42add63a84 drm-intel-nightly: 2016y-03m-24d-14h-34m-29s UTC integration manifest cff00fb37026cf1e75d9317e8570938e89197515 drm/i915/guc: always reset GuC before loading firmware 6c406232a0289a937e4478901e3edc57c8f9f01a drm/i915/guc: Reset GuC and retry on firmware load failure ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for sna: Opt-out of the Kernel mmap workaround
== Series Details == Series: sna: Opt-out of the Kernel mmap workaround URL : https://patchwork.freedesktop.org/series/4879/ State : failure == Summary == Series 4879v1 sna: Opt-out of the Kernel mmap workaround http://patchwork.freedesktop.org/api/1.0/series/4879/revisions/1/mbox/ Test gem_exec_whisper: Subgroup basic: pass -> FAIL (ivb-t430s) Test kms_frontbuffer_tracking: Subgroup basic: pass -> FAIL (hsw-gt2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) Subgroup basic-rte: dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:179 dwarn:0 dfail:0 fail:1 skip:12 bdw-ultratotal:192 pass:170 dwarn:0 dfail:0 fail:1 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:157 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:174 dwarn:0 dfail:0 fail:1 skip:17 ivb-t430stotal:192 pass:166 dwarn:0 dfail:0 fail:1 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1718/ f5d413cccefa1f93d64c34f357151d42add63a84 drm-intel-nightly: 2016y-03m-24d-14h-34m-29s UTC integration manifest 45b98318dcf57f54457c65caa0bad4485fd587df drm/i915/fbc: enable FBC on gen 9+ too f19ee52a69b04e3bd7d861abf47b5a702aaf090b drm/i915: opt-out CPU and WC mmaps from FBC 8769c5983b6e33978226b0d84316f4f697c9ccff drm/i915/fbc: sanitize i915.enable_fbc during FBC init 417a12f1c1e47742fb21c15455fd5e27de0fdb8a drm/i915/fbc: update busy_bits even for GTT and flip flushes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for Add aspect ratio parsing (rev3)
== Series Details == Series: Add aspect ratio parsing (rev3) URL : https://patchwork.freedesktop.org/series/1915/ State : warning == Summary == Series 1915v3 Add aspect ratio parsing http://patchwork.freedesktop.org/api/1.0/series/1915/revisions/3/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (bsw-nuc-2) Test gem_sync: Subgroup basic-render: pass -> INCOMPLETE (bdw-nuci7) UNSTABLE Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> SKIP (hsw-brixbox) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (byt-nuc) Subgroup basic-rte: dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:173 pass:161 dwarn:0 dfail:0 fail:1 skip:10 bdw-ultratotal:192 pass:170 dwarn:0 dfail:0 fail:1 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1719/ f5d413cccefa1f93d64c34f357151d42add63a84 drm-intel-nightly: 2016y-03m-24d-14h-34m-29s UTC integration manifest 252f383818ab4a2d27d6ae803b442d02b5dce0fa drm/i915: Add support for new aspect ratios ec04b80c5d8c41af580fc86541d9bb7c0ee62bfa drm: Add flags for new aspect ratios 268689f385a5d80f2c222b0c987069a71931e0fd video: Add new aspect ratios for HDMI 2.0 3750467c2f437187ebf47dc6341298443a848ef2 drm: Add aspect ratio parsing in DRM layer d8edd4433f5c14388f962510e770d938a551153b drm: add picture aspect ratio flags ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Move execlists irq handler to a bottom half
On Thu, Mar 24, 2016 at 10:24:49PM +, Chris Wilson wrote: > On Thu, Mar 24, 2016 at 12:18:49PM +, Tvrtko Ursulin wrote: > > @@ -2016,6 +2015,8 @@ void intel_logical_ring_cleanup(struct > > intel_engine_cs *engine) > > if (!intel_engine_initialized(engine)) > > return; > > > > + tasklet_kill(&engine->irq_tasklet); > > Imre suggested that we assert that the irq_tasklet is idle. > WARN_ON(test_bit(TASK_STATE_SCHED, &engine->irq_tasklet.state)); Whilst it may not be necessary in cleanup(), we should put a tasklet_kill() in i915_reset_engine_cleanup() -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] drm/i915: Decouple execbuf uAPI from internal implementation
Hi everyone,
Yes, this breaks userspace ABI and in particular it broke VTune work.
Ring ids are seen via i915 tracepoints, and VTune Amplifier uses them.
We were relying on the old ring ids, and assuming that the new rings would be
added to the end of the enum.
I'm objecting just now because now this driver change reached our internal
users and they complained that VTune is reporting DMA packets on wrong engines.
I would request this change (the enum intel_ring_id change) to be rolled back.
Hope, it's still possible.
Regards,
Svetlana
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Chris Wilson
Sent: Friday, January 15, 2016 1:09 AM
To: Tvrtko Ursulin
Cc: Daniel Vetter ; Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Decouple execbuf uAPI from internal
implementation
On Thu, Jan 14, 2016 at 03:02:59PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> At the moment execbuf ring selection is fully coupled to internal ring
> ids which is not a good thing on its own.
>
> This dependency is also spread between two source files and not
> spelled out at either side which makes it hidden and fragile.
>
> This patch decouples this dependency by introducing an explicit
> translation table of execbuf uAPI to ring id close to the only call
> site (i915_gem_do_execbuffer).
>
> This way we are free to change driver internal implementation details
> without breaking userspace. All state relating to the uAPI is now
> contained in, or next to, i915_gem_do_execbuffer.
I was hesistant at first, since "why?" isn't fully developed, but the code won
me over.
> +#define I915_USER_RINGS (4)
> +
> +static const enum intel_ring_id user_ring_map[I915_USER_RINGS + 1] = {
> + [I915_EXEC_DEFAULT] = RCS,
> + [I915_EXEC_RENDER] = RCS,
> + [I915_EXEC_BLT] = BCS,
> + [I915_EXEC_BSD] = VCS,
> + [I915_EXEC_VEBOX] = VECS
> +};
I was wondering whether packing here mattered at all, but we're under a
cacheline so highly unlikely.
> static int
> i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> struct drm_file *file,
> @@ -1393,6 +1393,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> struct i915_execbuffer_params params_master; /* XXX: will be removed
> later */
> struct i915_execbuffer_params *params = ¶ms_master;
> const u32 ctx_id = i915_execbuffer2_get_context_id(*args);
> + unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
> u32 dispatch_flags;
> int ret;
> bool need_relocs;
> @@ -1414,49 +1415,39 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> if (args->flags & I915_EXEC_IS_PINNED)
> dispatch_flags |= I915_DISPATCH_PINNED;
>
> - if ((args->flags & I915_EXEC_RING_MASK) > LAST_USER_RING) {
> - DRM_DEBUG("execbuf with unknown ring: %d\n",
> - (int)(args->flags & I915_EXEC_RING_MASK));
> + if (user_ring_id > I915_USER_RINGS) {
> + DRM_DEBUG("execbuf with unknown ring: %u\n", user_ring_id);
> return -EINVAL;
> }
>
> - if (((args->flags & I915_EXEC_RING_MASK) != I915_EXEC_BSD) &&
> + if ((user_ring_id != I915_EXEC_BSD) &&
> ((args->flags & I915_EXEC_BSD_MASK) != 0)) {
> DRM_DEBUG("execbuf with non bsd ring but with invalid "
> "bsd dispatch flags: %d\n", (int)(args->flags));
> return -EINVAL;
> - }
> -
> - if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_DEFAULT)
> - ring = &dev_priv->ring[RCS];
> - else if ((args->flags & I915_EXEC_RING_MASK) == I915_EXEC_BSD) {
> - if (HAS_BSD2(dev)) {
> - int ring_id;
> -
> - switch (args->flags & I915_EXEC_BSD_MASK) {
> - case I915_EXEC_BSD_DEFAULT:
> - ring_id = gen8_dispatch_bsd_ring(dev, file);
> - ring = &dev_priv->ring[ring_id];
> - break;
> - case I915_EXEC_BSD_RING1:
> - ring = &dev_priv->ring[VCS];
> - break;
> - case I915_EXEC_BSD_RING2:
> - ring = &dev_priv->ring[VCS2];
> - break;
> - default:
> - DRM_DEBUG("execbuf with unknown bsd ring: %d\n",
> - (int)(args->flags &
> I915_EXEC_BSD_MASK));
> - return -EINVAL;
> - }
> - } else
> - ring = &dev_priv->ring[VCS];
> - } else
> - ring = &dev_priv->ring[(args->flags & I915_EXEC_RING_MASK) - 1];
> + }
> +
> + if (user_ring_id == I915_EXEC_BSD && HAS_BSD2(dev)) {
HAS_BSD2(dev_priv)
Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC
Em Qui, 2016-03-24 às 21:20 +, ch...@chris-wilson.co.uk escreveu:
> On Thu, Mar 24, 2016 at 09:03:59PM +, ch...@chris-wilson.co.uk
> wrote:
> >
> > On Thu, Mar 24, 2016 at 08:53:21PM +, Zanoni, Paulo R wrote:
> > >
> > > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > > >
> > > > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> > > > >
> > > > >
> > > > > FBC and the frontbuffer tracking infrastructure were designed
> > > > > assuming
> > > > > that user space applications would follow a specific set of
> > > > > rules
> > > > > regarding frontbuffer management and mmapping. I recently
> > > > > discovered
> > > > > that current user space is not exactly following these rules:
> > > > > my
> > > > > investigation led me to the conclusion that the generic
> > > > > backend
> > > > > from
> > > > > SNA - used by SKL and the other new platforms without a
> > > > > specific
> > > > > backend - is not issuing sw_finish/dirty_fb IOCTLs when using
> > > > > the
> > > > > CPU
> > > > > and WC mmaps. I discovered this when running lightdm: I would
> > > > > type
> > > > > the
> > > > > password and nothing would appear on the screen unless I
> > > > > moved the
> > > > > mouse over the place where the letters were supposed to
> > > > > appear.
> > > > Yes, that is a kernel bug. The protocol we said the kernel
> > > > would
> > > > follow
> > > > is to disable FBC/WC when userspace marks the object for
> > > > writing by
> > > > the
> > > > CPU and would only reestablish FBC/WC upon dirtyfb.
> > > But on WC mmaps we mark the object for writing by the GTT instead
> > > of
> > > the CPU, and while the tracking engine is able to see "normal"
> > > GTT mmap
> > > writes, it's not able to see WC mmap writes, so we established
> > > that
> > > we'd call dirtyfb after frontbuffer drawing through WC mmaps,
> > > which is
> > > something that the DDX never implemented. This was discussed on
> > > #intel-
> > > gfx on Nov 5 2014, and also possibly other places, but I can't
> > > find the
> > > logs. Daniel also confirmed this to me again on private IRC on
> > > Jun 16
> > > 2015. So I still don't understand why this is a Kernel bug
> > > instead of a
> > > DDX bug.
> > Because we said that once invalidated, it would not be restored
> > until
> > dirtyfb. The kernel is not doing that. Your patch does not do that.
> > To
> > be even close, you should be setting the origin flag based on the
> > existence
> > of wc mmaping for the object inside set-to-gtt-domain. Otherwise,
> > you
> > are not implementing even close to the protocol you say you are.
> > That is
> > invalidate on set-domain, flush on dirtyfb.
> >
> > The kernel's bug is that is not cancelling FBC. Userspace's bug is
> > not
> > signalling when to reenable it.
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 8dec2e8..0314346 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2145,6 +2145,7 @@ struct drm_i915_gem_object {
> unsigned int cache_dirty:1;
>
> unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
> + unsigned int has_wc_mmap:1;
>
> /** Count of VMA actually bound by this object */
> unsigned int bind_count;
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index 05ae706..29ca96d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1310,6 +1310,13 @@ unlock:
> return ret;
> }
>
> +static enum fb_op_origin
> +write_origin(struct drm_i915_gem_object *obj, unsigned domain)
> +{
> + return domain == I915_GEM_DOMAIN_GTT && !obj->has_wc_mmap ?
> + ORIGIN_GTT : ORIGIN_CPU;
What if I have both a WC mmap and a GTT mmap, and I'm actually using
the GTT mmap now? My set_domain call will be treated as WC mmap usage,
while in fact it should be treated as GTT usage. Is there a way to
differentiate between them with the current set_domain API?
> +}
> +
> /**
> * Called when user space prepares to use an object with the CPU,
> either
> * through the mmap ioctl's mapping or a GTT mapping.
> @@ -1363,9 +1370,7 @@ i915_gem_set_domain_ioctl(struct drm_device
> *dev, void *data,
> ret = i915_gem_object_set_to_cpu_domain(obj,
> write_domain != 0);
>
> if (write_domain != 0)
> - intel_fb_obj_invalidate(obj,
> - write_domain ==
> I915_GEM_DOMAIN_GTT ?
> - ORIGIN_GTT : ORIGIN_CPU);
> + intel_fb_obj_invalidate(obj, write_origin(obj,
> write_domain));
>
> unref:
> drm_gem_object_unreference(&obj->base);
> @@ -1466,6 +1471,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev,
> void *data,
> else
> addr = -ENOMEM;
> up_write(&mm->mmap_sem);
> +
> + /* This may race, but that's ok, it only gets set */
>
Re: [Intel-gfx] [PATCH 3/4] drm/i915: opt-out CPU and WC mmaps from FBC
On Fri, Mar 25, 2016 at 02:05:42PM +, Zanoni, Paulo R wrote: > What if I have both a WC mmap and a GTT mmap, and I'm actually using > the GTT mmap now? My set_domain call will be treated as WC mmap usage, > while in fact it should be treated as GTT usage. Is there a way to > differentiate between them with the current set_domain API? No, there is not. As far as the cache domain is regarded WC/GTT appear to be identical, i.e. GTT is just WC. That the GTT is not as coherent as previously regarded is yet another bug. -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 0/7] Add lspcon support
Hi Daniel, Ville, I reviewed Ville's code for dp++ adaptors, and as Ville rightly mentioned, a lot of the code can be reused for LSPCON as it is, as LSPCON is also working as a type2 DP adaptor. I need to add i2c-over-aux functionality, and then LSPCON will become one of the consumers of this code. How should we proceed on this? - Should I pull those patches, and re-publish in intel-gfx, get the review done, and then write LSPCON layer on top of it ? - Or Should I publish DP++ and modified LSPCON together ? Please suggest. Regards Shashank -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Wednesday, March 23, 2016 2:33 PM To: Sharma, Shashank Cc: Ville Syrjälä; Vetter, Daniel; intel-gfx@lists.freedesktop.org; Sharma, Akashdeep Subject: Re: [Intel-gfx] [PATCH 0/7] Add lspcon support On Tue, Mar 22, 2016 at 10:17:36PM +0530, Sharma, Shashank wrote: > Thanks Ville. > I will have a look at the series you posted, and if that's the case, > will try to merge this implementation on top of yours. Please try to review Ville's patches either way using the DP specs, so that we can pull it in. You have to read it carefully anyway to figure out whether it matches lspcon well enough, so might as well use that time ;-) Thanks, Daniel > > Regards > Shashank > > On 3/22/2016 9:50 PM, Ville Syrjälä wrote: > >On Tue, Mar 22, 2016 at 07:55:01PM +0530, Shashank Sharma wrote: > >>LSPCON is essentially an active DP-HDMI convertor. It has two modes > >>of operations: > >>- ls mode (for upto HDMI 1.4 outputs, 4k@30 resoution / 297MHz) > >>- pcon mode (for upto HDMI 2.0 outputs, 4k@60 resolution / 600 MHz) > >> > >>This patch set adds support for LS mode of operation for GEN9 > >>platforms. It adds a new connector for lspcon, whcih is a mix and > >>match of DP and HDMI connectors, matching dual personality of lspcon > >>devices. > >> > >>Notes: > >>- Daniel Vetter gave a review comment on LSPCON design, to make > >> it a separate encoder. This patch set tries to match that expectations > >> with a separate connector, as DDI encoder already fulfills all the > >> requirements of a lspcon_encoder. > >>- This patch set tagrets LS mode of operations only. > >>- PCON mode of operation will be added later, based on the requirements. > >> This is to primarily unbloc Linux devices with LSPCON port. > >>- This patch set is tested with BXT RVP + drm-nightly > >>- As we redesigned this code, to meet the review comments, this is a working > >> patch set, but not upto commercial quality yet. > > > >Quick glance tells me this is more or less just an in driver > >implementation of the DP dual mode standard at this point. I recently > >posted some patches [1] that implement dual mode support as a helper. > >So you should check it out and try to layer whatever lspcon specifics on top > >of that. > > > >The only thing missing from my patches was basically using > >i2c-over-aux instead of gmbus for type2 adapters, but that's mostly > >just a matter of passing the right i2c adapter to places. > > > >[1] > >https://lists.freedesktop.org/archives/dri-devel/2016-February/101494 > >.html > > > >> > >>Shashank Sharma (7): > >> drm/i915: add lspcon vbt bit parsing > >> drm/i915: Add lspcon data structures > >> drm/i915: Add new lspcon file > >> drm/i915: Add and initialize lspcon connector > >> drm/i915: Add and register lspcon connector functions > >> drm/i915: Add lspcon core functions > >> drm/i915: Add lspcon hpd handler > >> > >> drivers/gpu/drm/i915/Makefile | 3 +- > >> drivers/gpu/drm/i915/i915_drv.h | 1 + > >> drivers/gpu/drm/i915/intel_bios.c | 42 +++ > >> drivers/gpu/drm/i915/intel_ddi.c | 6 + > >> drivers/gpu/drm/i915/intel_dp.c | 31 ++ > >> drivers/gpu/drm/i915/intel_drv.h | 35 +- > >> drivers/gpu/drm/i915/intel_hdmi.c | 25 +- > >> drivers/gpu/drm/i915/intel_hotplug.c | 2 +- > >> drivers/gpu/drm/i915/intel_lspcon.c | 620 > >> ++ > >> drivers/gpu/drm/i915/intel_vbt_defs.h | 1 + > >> 10 files changed, 759 insertions(+), 7 deletions(-) create mode > >> 100644 drivers/gpu/drm/i915/intel_lspcon.c > >> > >>-- > >>1.9.1 > >> > >>___ > >>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 -- 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 0/2] drm/i915: Split up modeset state checker.
On Wed, Mar 23, 2016 at 02:58:05PM +0100, Maarten Lankhorst wrote: > Right now the state checker assumes that the global state is fixed, > with support for the atomic ioctl not all state will be locked any more, > so the state checker has to check only what's part of the state. > > This is done by first splitting up the state checker in one part that > checks all disabled connectors/encoders and global state, and then > split again to run for each crtc separately. While you're touching these functions, maybe it would be a good time to rename them as well? The 'check' in their names can mislead people into thinking that they're somehow related to the atomic 'check' phase, even though they're actually something we do after the commit is complete. Renaming these with s/check/confirm/ or s/check/verify/ might make it a little bit easier to understand what their purpose is and avoid confusion. Matt > > Maarten Lankhorst (2): > drm/i915: Make modeset state checker take crtc as argument. > drm/i915: Move modeset state checker calls. > > drivers/gpu/drm/i915/intel_display.c | 310 > +++ > 1 file changed, 173 insertions(+), 137 deletions(-) > > -- > 2.1.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Matt Roper Graphics Software Engineer IoTG Platform Enabling & Development Intel Corporation (916) 356-2795 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices
This patch adds new fields that are not yet added in drm code
in child devices struct
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_bios.c | 15 ++-
drivers/gpu/drm/i915/intel_vbt_defs.h | 16 +++-
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..e2f636c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1126,7 +1126,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
}
/* Parse the I_boost config for SKL and above */
- if (bdb->version >= 196 && (child->common.flags_1 & IBOOST_ENABLE)) {
+ if (bdb->version >= 196 && child->common.iboost) {
info->dp_boost_level =
translate_iboost(child->common.iboost_level & 0xF);
DRM_DEBUG_KMS("VBT (e)DP boost level for port %c: %d\n",
port_name(port), info->dp_boost_level);
@@ -1244,6 +1244,19 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
*/
memcpy(child_dev_ptr, p_child,
min_t(size_t, p_defs->child_dev_size, sizeof(*p_child)));
+
+ /*
+* copied full block, now init values when they are not
+* available in current version
+*/
+ if (bdb->version < 196) {
+ /* Set default values for bits added from v196 */
+ child_dev_ptr->common.iboost = 0;
+ child_dev_ptr->common.hpd_invert = 0;
+ }
+
+ if (bdb->version < 192)
+ child_dev_ptr->common.lspcon = 0;
}
return;
}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 749dcea..2da7be8 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -261,9 +261,6 @@ struct old_child_dev_config {
* versions. Notice that the meaning of the contents contents may still change,
* but at least the offsets are consistent. */
-/* Definitions for flags_1 */
-#define IBOOST_ENABLE (1<<3)
-
struct common_child_dev_config {
u16 handle;
u16 device_type;
@@ -272,8 +269,17 @@ struct common_child_dev_config {
u8 not_common2[2];
u8 ddc_pin;
u16 edid_ptr;
- u8 obsolete;
- u8 flags_1;
+ u8 dvo_cfg; /* See DEVICE_CFG_* above */
+ u8 efp_routed:1;
+ u8 lane_reversal:1;
+ u8 lspcon:1;
+ u8 iboost:1;
+ u8 hpd_invert:1;
+ u8 flag_reserved:3;
+ u8 hdmi_support:1;
+ u8 dp_support:1;
+ u8 tmds_support:1;
+ u8 support_reserved:5;
u8 not_common3[13];
u8 iboost_level;
} __packed;
--
2.6.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT
This patch sets the invert bit for hpd detection for each port
based on VBT configuration. Since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.
v2: Separated VBT parsing from the rest of the logic. (Jani)
v3: Moved setting invert bit logic to bxt_hpd_irq_setup()
and changed its logic to avoid looping twice. (Ville)
v4: Changed the logic to mask out the bits first and then
set them to remove need of temporary variable. (Ville)
v5: Moved defines to existing set of defines for the register
and added required breaks. (Ville)
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 20
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_bios.c | 38 ++
4 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08b88c0..4e8d78a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3378,6 +3378,8 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
+bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
+enum port port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a55a7cc..8fbec3e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3504,6 +3504,26 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
hotplug = I915_READ(PCH_PORT_HOTPLUG);
hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
PORTA_HOTPLUG_ENABLE;
+
+ DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x\n",
+ hotplug, enabled_irqs);
+ hotplug &= ~BXT_DDI_HPD_INVERT_MASK;
+
+ /*
+* For BXT invert bit has to be set based on AOB design
+* for HPD detection logic, update it based on VBT fields.
+*/
+
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDIA) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
+ hotplug |= BXT_DDIA_HPD_INVERT;
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDIB) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_B))
+ hotplug |= BXT_DDIB_HPD_INVERT;
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDIC) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_C))
+ hotplug |= BXT_DDIC_HPD_INVERT;
+
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f3ba43c..73a806c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6185,6 +6185,7 @@ enum skl_disp_power_wells {
/* digital port hotplug */
#define PCH_PORT_HOTPLUG _MMIO(0xc4030) /* SHOTPLUG_CTL */
#define PORTA_HOTPLUG_ENABLE (1 << 28) /* LPT:LP+ & BXT */
+#define BXT_DDIA_HPD_INVERT(1 << 27)
#define PORTA_HOTPLUG_STATUS_MASK (3 << 24) /* SPT+ & BXT */
#define PORTA_HOTPLUG_NO_DETECT (0 << 24) /* SPT+ & BXT */
#define PORTA_HOTPLUG_SHORT_DETECT(1 << 24) /* SPT+ & BXT */
@@ -6200,6 +6201,7 @@ enum skl_disp_power_wells {
#define PORTD_HOTPLUG_SHORT_DETECT(1 << 16)
#define PORTD_HOTPLUG_LONG_DETECT (2 << 16)
#define PORTC_HOTPLUG_ENABLE (1 << 12)
+#define BXT_DDIC_HPD_INVERT(1 << 11)
#define PORTC_PULSE_DURATION_2ms (0 << 10) /* pre-LPT */
#define PORTC_PULSE_DURATION_4_5ms(1 << 10) /* pre-LPT */
#define PORTC_PULSE_DURATION_6ms (2 << 10) /* pre-LPT */
@@ -6210,6 +6212,7 @@ enum skl_disp_power_wells {
#define PORTC_HOTPLUG_SHORT_DETECT(1 << 8)
#define PORTC_HOTPLUG_LONG_DETECT (2 << 8)
#define PORTB_HOTPLUG_ENABLE (1 << 4)
+#define BXT_DDIB_HPD_INVERT(1 << 3)
#define PORTB_PULSE_DURATION_2ms (0 << 2) /* pre-LPT */
#define PORTB_PULSE_DURATION_4_5ms(1 << 2) /* pre-LPT */
#define PORTB_PULSE_DURATION_6ms (2 << 2) /* pre-LPT */
@@ -6219,6 +6222,9 @@ enum skl_disp_power_wells {
#define PORTB_HOTPLUG_NO_DETECT (0 << 0)
#define PORTB_HOTPLUG_SHORT_DETECT(1 << 0)
#define PORTB_HOTPLUG_LONG_DETECT (2 << 0)
+#define BXT_DDI_HPD_INVERT_MASK (BXT_DDIA_HPD_INVERT | \
+ BXT_DDIB_HPD_INVERT | \
+ BXT_DDIC_HPD_INVERT)
#define PCH_PORT_HOTPLUG2 _MMIO(0xc403
[Intel-gfx] [PATCH] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns
In order to ensure that all invalidations are completed before the
operation returns to userspace (i.e. before the mmap() syscall returns)
we need to flush the outstanding operations. To this end, we submit all
the per-object invalidation work to a private workqueue and then flush
the workqueue at the end of the function. We are allowed to block inside
invalidate_range_start, and struct_mutex is the inner lock so the worker
is not hiding any lock inversions. The advantage of using the workqueue
over direct calling of cancel_userptr() is that it allows us to
parallelise the potential waits and unpinning of large objects.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94699
Testcase: igt/gem_userptr_blits/sync-unmap-cycles
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Winiarski
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 48 -
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c
b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 54088a4d6498..f6b3665ee09f 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -49,6 +49,7 @@ struct i915_mmu_notifier {
struct hlist_node node;
struct mmu_notifier mn;
struct rb_root objects;
+ struct workqueue_struct *wq;
};
struct i915_mmu_object {
@@ -60,6 +61,40 @@ struct i915_mmu_object {
bool attached;
};
+static void wait_rendering(struct drm_i915_gem_object *obj)
+{
+ struct drm_device *dev = obj->base.dev;
+ struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
+ unsigned reset_counter;
+ int i, n;
+
+ if (!obj->active)
+ return;
+
+ n = 0;
+ for (i = 0; i < I915_NUM_ENGINES; i++) {
+ struct drm_i915_gem_request *req;
+
+ req = obj->last_read_req[i];
+ if (req == NULL)
+ continue;
+
+ requests[n++] = i915_gem_request_reference(req);
+ }
+
+ reset_counter = atomic_read(&to_i915(dev)->gpu_error.reset_counter);
+ mutex_unlock(&dev->struct_mutex);
+
+ for (i = 0; i < n; i++)
+ __i915_wait_request(requests[i], reset_counter, false,
+ NULL, NULL);
+
+ mutex_lock(&dev->struct_mutex);
+
+ for (i = 0; i < n; i++)
+ i915_gem_request_unreference(requests[i]);
+}
+
static void cancel_userptr(struct work_struct *work)
{
struct i915_mmu_object *mo = container_of(work, typeof(*mo), work);
@@ -75,6 +110,8 @@ static void cancel_userptr(struct work_struct *work)
struct i915_vma *vma, *tmp;
bool was_interruptible;
+ wait_rendering(obj);
+
was_interruptible = dev_priv->mm.interruptible;
dev_priv->mm.interruptible = false;
@@ -140,7 +177,7 @@ static void
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
*/
mo = container_of(it, struct i915_mmu_object, it);
if (kref_get_unless_zero(&mo->obj->base.refcount))
- schedule_work(&mo->work);
+ queue_work(mn->wq, &mo->work);
list_add(&mo->link, &cancelled);
it = interval_tree_iter_next(it, start, end);
@@ -148,6 +185,8 @@ static void
i915_gem_userptr_mn_invalidate_range_start(struct mmu_notifier *_mn,
list_for_each_entry(mo, &cancelled, link)
del_object(mo);
spin_unlock(&mn->lock);
+
+ flush_workqueue(mn->wq);
}
static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
@@ -167,10 +206,16 @@ i915_mmu_notifier_create(struct mm_struct *mm)
spin_lock_init(&mn->lock);
mn->mn.ops = &i915_gem_userptr_notifier;
mn->objects = RB_ROOT;
+ mn->wq = alloc_workqueue("i915-userptr-release", WQ_UNBOUND, 0);
+ if (mn->wq == NULL) {
+ kfree(mn);
+ return ERR_PTR(-ENOMEM);
+ }
/* Protected by mmap_sem (write-lock) */
ret = __mmu_notifier_register(&mn->mn, mm);
if (ret) {
+ destroy_workqueue(mn->wq);
kfree(mn);
return ERR_PTR(ret);
}
@@ -256,6 +301,7 @@ i915_mmu_notifier_free(struct i915_mmu_notifier *mn,
return;
mmu_notifier_unregister(&mn->mn, mm);
+ destroy_workqueue(mn->wq);
kfree(mn);
}
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/userptr: Flush cancellations before mmu-notifier invalidate returns
Hi Chris,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160324]
[cannot apply to v4.5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-userptr-Flush-cancellations-before-mmu-notifier-invalidate-returns/20160326-021543
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x010-201612 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/i915_gem_userptr.c: In function 'wait_rendering':
>> drivers/gpu/drm/i915/i915_gem_userptr.c:67:40: error: 'I915_NUM_ENGINES'
>> undeclared (first use in this function)
struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
^
drivers/gpu/drm/i915/i915_gem_userptr.c:67:40: note: each undeclared
identifier is reported only once for each function it appears in
>> drivers/gpu/drm/i915/i915_gem_userptr.c:67:31: warning: unused variable
>> 'requests' [-Wunused-variable]
struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
^
vim +/I915_NUM_ENGINES +67 drivers/gpu/drm/i915/i915_gem_userptr.c
61 bool attached;
62 };
63
64 static void wait_rendering(struct drm_i915_gem_object *obj)
65 {
66 struct drm_device *dev = obj->base.dev;
> 67 struct drm_i915_gem_request *requests[I915_NUM_ENGINES];
68 unsigned reset_counter;
69 int i, n;
70
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [intelddx][strlcpy | strlcat | clock_gettime] clang-3.8: error: linker command failed with exit code 1
On Thu, Mar 24, 2016 at 2:09 PM, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 12:47:51PM +, Dave Gordon wrote:
>> On 24/03/16 11:11, Sedat Dilek wrote:
>> > From b35261adb49107e7dd6e480b1f7c5d4fb7552f9f Mon Sep 17 00:00:00 2001
>> >From: Sedat Dilek
>> >Date: Thu, 24 Mar 2016 12:01:37 +0100
>> >Subject: [PATCH 1/3] configure: Remove ACLOCAL_FLAGS to fix libtool vs
>> > automake problem
>> >
>> >---
>> > Makefile.am | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> >diff --git a/Makefile.am b/Makefile.am
>> >index c60e8a729271..396f41fdc4df 100644
>> >--- a/Makefile.am
>> >+++ b/Makefile.am
>> >@@ -18,7 +18,7 @@
>> > # IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
>> > # CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
>> > SOFTWARE.
>> >
>> >-ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
>> >+ACLOCAL_AMFLAGS = -I m4
>> >
>> > SUBDIRS = man libobj xvmc src tools
>> >
>> >--
>>
>> Looks like the issue is related to trying to layer the Make-variable
>> expansion.
>>
>> In the shell (and most other languages) an assignment like:
>>
>> $ ACLOCAL_AMFLAGS="${ACLOCAL_FLAGS} -I m4"
>>
>> would take the current value of the existing ACLOCAL_FLAGS variable
>> and use it construct the value of the new variable ACLOCAL_AMFLAGS.
>> Thus if ACLOCAL_were "--XXX" this would yield "-XXX -I m4". Then
>> later we'd see:
>>
>> $ aclocal ${ACLOCAL_AMFLAGS} ...
>>
>> which would use the value as previously defined.
>>
>> Make doesn't do that. It sets ACLOCAL_AMFLAGS to "$(ACLOCAL_FLAGS)
>> -I m4" and then later, when ACLOCAL_AMFLAGS is *used* it expands it,
>> and then notices that the expanded version still contains a $(var)
>> construct and expands *that* ... and so on until there are none
>> left. This is sometimes useful, but often confusing. So GNU make (as
>> POSIX, from 2012 on) supports another type of assignment,
>>
>> VAR ::= expression
>>
>> which does the expansion of just once, at this point,
>> and stores the result rather than the itself. So, try
>> changing the line
>>
>> ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
>>
>> in the Makefile into:
>>
>> ACLOCAL_AMFLAGS ::= $(ACLOCAL_FLAGS) -I m4
>>
>> and see whether that helps :)
>
> ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
> => autoreconf: running: aclocal ${ACLOCAL_FLAGS} -I m4
> ...
>
> With setenv ACLOCAL_FLAGS "-I /opt/xorg/share/aclocal":
>
> => autoreconf: running: aclocal -I /opt/xorg/share/aclocal/ ${ACLOCAL_FLAGS}
> -I m4
> autoreconf: configure.ac: tracing
> autoreconf: running: libtoolize --copy
> libtoolize: error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
> ACLOCAL_AMFLAGS=-I /opt/xorg/share/aclocal.
>
> Using ACLOCAL_AMFLAGS ::= $(ACLOCAL_FLAGS) -I m4
>
> => autoreconf: running: aclocal -I /opt/xorg/share/aclocal/
> autoreconf: configure.ac: tracing
> autoreconf: running: libtoolize --copy
> libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
>
> It looks like using
> ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
> is obsolete in autoreconf (GNU Autoconf) 2.69.
> So looks like the answer is
> AC_PREREQ([2.69])
> ACLOCAL_AMFLAGS = -I m4
Not sure what the real fix of the reported "ACLOCAL_FLAGS issue" is.
As said in my initial asking I have here on Ubuntu/precise AMD64 autoconf v2.68.
Being no autotools-guru, version and feature check might make sense.
- Sedat -
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
