[Intel-gfx] [PATCH] drm/atomic: Clear crtcs, connectors and planes when clearing state
Users of the atomic state assume that if the pointer to a crtc, plane or connector is not NULL in the respective object vector, than the state for that object in *_states vector also won't be NULL. That assumption was broken by drm_atomic_state_clear(), which would clear the state pointer but leave the pointer to the object still set. This fixes a NULL pointer dereference in i915 caused by the use of drm_atomic_state_clear(). Cc: dri-de...@lists.freedesktop.org Signed-off-by: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com --- drivers/gpu/drm/drm_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 5d3abe3..00ea881 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -134,6 +134,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state) connector-funcs-atomic_destroy_state(connector, state-connector_states[i]); + state-connectors[i] = NULL; state-connector_states[i] = NULL; } @@ -145,6 +146,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state) crtc-funcs-atomic_destroy_state(crtc, state-crtc_states[i]); + state-crtcs[i] = NULL; state-crtc_states[i] = NULL; } @@ -156,6 +158,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state) plane-funcs-atomic_destroy_state(plane, state-plane_states[i]); + state-planes[i] = NULL; state-plane_states[i] = NULL; } } -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check lane sharing between pipes B C using atomic state
On Mon, Mar 30, 2015 at 08:33:12AM +0300, Ander Conselvan de Oliveira wrote:
Makes that code atomic ready.
v2: Acquire crtc_state for the other pipe only when needed. (Daniel)
v3: Really only acquire the other state if necessary. (Daniel)
Missing sob added and queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 69
++--
1 file changed, 42 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 75955fe..cfe34c3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5667,65 +5667,80 @@ bool intel_connector_get_hw_state(struct
intel_connector *connector)
return encoder-get_hw_state(encoder, pipe);
}
-static int pipe_required_fdi_lanes(struct drm_device *dev, enum pipe pipe)
+static int pipe_required_fdi_lanes(struct intel_crtc_state *crtc_state)
{
- struct intel_crtc *crtc =
- to_intel_crtc(intel_get_crtc_for_pipe(dev, pipe));
-
- if (crtc-base.state-enable
- crtc-config-has_pch_encoder)
- return crtc-config-fdi_lanes;
+ if (crtc_state-base.enable crtc_state-has_pch_encoder)
+ return crtc_state-fdi_lanes;
return 0;
}
-static bool ironlake_check_fdi_lanes(struct drm_device *dev, enum pipe pipe,
+static int ironlake_check_fdi_lanes(struct drm_device *dev, enum pipe pipe,
struct intel_crtc_state *pipe_config)
{
+ struct drm_atomic_state *state = pipe_config-base.state;
+ struct intel_crtc *other_crtc;
+ struct intel_crtc_state *other_crtc_state;
+
DRM_DEBUG_KMS(checking fdi config on pipe %c, lanes %i\n,
pipe_name(pipe), pipe_config-fdi_lanes);
if (pipe_config-fdi_lanes 4) {
DRM_DEBUG_KMS(invalid fdi lane config on pipe %c: %i lanes\n,
pipe_name(pipe), pipe_config-fdi_lanes);
- return false;
+ return -EINVAL;
}
if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
if (pipe_config-fdi_lanes 2) {
DRM_DEBUG_KMS(only 2 lanes on haswell, required: %i
lanes\n,
pipe_config-fdi_lanes);
- return false;
+ return -EINVAL;
} else {
- return true;
+ return 0;
}
}
if (INTEL_INFO(dev)-num_pipes == 2)
- return true;
+ return 0;
/* Ivybridge 3 pipe is really complicated */
switch (pipe) {
case PIPE_A:
- return true;
+ return 0;
case PIPE_B:
- if (pipe_config-fdi_lanes 2
- pipe_required_fdi_lanes(dev, PIPE_C) 0) {
+ if (pipe_config-fdi_lanes = 2)
+ return 0;
+
+ other_crtc = to_intel_crtc(intel_get_crtc_for_pipe(dev,
PIPE_C));
+ other_crtc_state =
+ intel_atomic_get_crtc_state(state, other_crtc);
+ if (IS_ERR(other_crtc_state))
+ return PTR_ERR(other_crtc_state);
+
+ if (pipe_required_fdi_lanes(other_crtc_state) 0) {
DRM_DEBUG_KMS(invalid shared fdi lane config on pipe
%c: %i lanes\n,
pipe_name(pipe), pipe_config-fdi_lanes);
- return false;
+ return -EINVAL;
}
- return true;
+ return 0;
case PIPE_C:
if (pipe_config-fdi_lanes 2) {
DRM_DEBUG_KMS(only 2 lanes on pipe %c: required %i
lanes\n,
pipe_name(pipe), pipe_config-fdi_lanes);
- return false;
+ return -EINVAL;
}
- if (pipe_required_fdi_lanes(dev, PIPE_B) 2) {
+
+ other_crtc = to_intel_crtc(intel_get_crtc_for_pipe(dev,
PIPE_B));
+ other_crtc_state =
+ intel_atomic_get_crtc_state(state, other_crtc);
+ if (IS_ERR(other_crtc_state))
+ return PTR_ERR(other_crtc_state);
+
+ if (pipe_required_fdi_lanes(other_crtc_state) 2) {
DRM_DEBUG_KMS(fdi link B uses too many lanes to enable
link C\n);
- return false;
+ return -EINVAL;
}
- return true;
+ return 0;
default:
BUG();
}
@@ -5737,8 +5752,8 @@ static int ironlake_fdi_compute_config(struct
intel_crtc *intel_crtc,
{
struct drm_device *dev = intel_crtc-base.dev;
struct drm_display_mode *adjusted_mode =
pipe_config-base.adjusted_mode;
- int lane, link_bw, fdi_dotclock;
-
[Intel-gfx] [PATCH i-g-t 1/2] lib/kms: Add a way to override an output's mode
So that it is possible to use a custom mode with the simplified mode set API.
v2: Add documentation for igt_output_override_mode(). (Thomas)
---
lib/igt_kms.c | 18 ++
lib/igt_kms.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 6cb1f08..9cdb204 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -905,6 +905,9 @@ static void igt_output_refresh(igt_output_t *output)
if (!output-valid)
return;
+ if (output-use_override_mode)
+ output-config.default_mode = output-override_mode;
+
if (!output-name) {
drmModeConnector *c = output-config.connector;
@@ -1656,6 +1659,21 @@ drmModeModeInfo *igt_output_get_mode(igt_output_t
*output)
return output-config.default_mode;
}
+/**
+ * igt_output_override_mode:
+ * @output: Output of which the mode will be overriden
+ * @mode: New mode
+ *
+ * Overrides the output's mode with @mode, so that it is used instead of the
+ * mode obtained with get connectors. Note that the mode is used without
+ * checking if the output supports it, so this might lead to unexpect results.
+ */
+void igt_output_override_mode(igt_output_t *output, drmModeModeInfo *mode)
+{
+ output-override_mode = *mode;
+ output-use_override_mode = true;
+}
+
void igt_output_set_pipe(igt_output_t *output, enum pipe pipe)
{
igt_display_t *display = output-display;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 565df14..067402c 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -217,6 +217,8 @@ typedef struct {
char *name;
bool valid;
unsigned long pending_crtc_idx_mask;
+ bool use_override_mode;
+ drmModeModeInfo override_mode;
} igt_output_t;
struct igt_display {
@@ -239,6 +241,7 @@ int igt_display_get_n_pipes(igt_display_t *display);
const char *igt_output_name(igt_output_t *output);
drmModeModeInfo *igt_output_get_mode(igt_output_t *output);
+void igt_output_override_mode(igt_output_t *output, drmModeModeInfo *mode);
void igt_output_set_pipe(igt_output_t *output, enum pipe pipe);
igt_plane_t *igt_output_get_plane(igt_output_t *output, enum igt_plane plane);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] tests: Add test for pipe B and C interactions in IVB
The tests exercise different combinations of enabling pipe B with modes
that require more than 2 lanes and then enabling pipe C.
v2: Added a couple more tests for different pipe transitions. (Ander)
Use custom modes to make the test reliable. (Daniel)
v3: Add IGT_TEST_DESCRIPTION. (Thomas)
Add test to .gitignore. (Thomas)
Rename test to kms_pipe_b_c_ivb. (Ander)
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/kms_pipe_b_c_ivb.c | 290 +++
3 files changed, 292 insertions(+)
create mode 100644 tests/kms_pipe_b_c_ivb.c
diff --git a/tests/.gitignore b/tests/.gitignore
index 843db4a..1f0e2d1 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -132,6 +132,7 @@ kms_flip_event_leak
kms_flip_tiling
kms_force_connector
kms_mmio_vs_cs_flip
+kms_pipe_b_c_ivb
kms_pipe_crc_basic
kms_plane
kms_psr_sink_crc
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 0a974a6..93e05e4 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -75,6 +75,7 @@ TESTS_progs_M = \
kms_flip_tiling \
kms_flip_event_leak \
kms_mmio_vs_cs_flip \
+ kms_pipe_b_c_ivb \
kms_pipe_crc_basic \
kms_plane \
kms_psr_sink_crc \
diff --git a/tests/kms_pipe_b_c_ivb.c b/tests/kms_pipe_b_c_ivb.c
new file mode 100644
index 000..74d84f1
--- /dev/null
+++ b/tests/kms_pipe_b_c_ivb.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright © 2015 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 the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER 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.
+ *
+ * Authors:
+ * Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
+ */
+
+#include drmtest.h
+#include igt_kms.h
+#include intel_chipset.h
+
+IGT_TEST_DESCRIPTION(
+Exercise the FDI lane bifurcation code for IVB in the kernel by setting
+different combinations of modes for pipes B and C.);
+
+typedef struct {
+ int drm_fd;
+ igt_display_t display;
+} data_t;
+
+drmModeModeInfo mode_3_lanes = {
+ .clock = 173000,
+ .hdisplay = 1920,
+ .hsync_start = 2048,
+ .hsync_end = 2248,
+ .htotal = 2576,
+ .vdisplay = 1080,
+ .vsync_start = 1083,
+ .vsync_end = 1088,
+ .vtotal = 1120,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC,
+ .name = 3_lanes,
+};
+
+drmModeModeInfo mode_2_lanes = {
+ .clock = 138500,
+ .hdisplay = 1920,
+ .hsync_start = 1968,
+ .hsync_end = 2000,
+ .htotal = 2080,
+ .vdisplay = 1080,
+ .vsync_start = 1083,
+ .vsync_end = 1088,
+ .vtotal = ,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .name = 2_lanes,
+};
+
+static int
+disable_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+ igt_plane_t *primary;
+
+ igt_output_set_pipe(output, pipe);
+ primary = igt_output_get_plane(output, 0);
+ igt_plane_set_fb(primary, NULL);
+ return igt_display_commit(data-display);
+}
+
+static int
+set_mode_on_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+ igt_plane_t *primary;
+ drmModeModeInfo *mode;
+ struct igt_fb fb;
+ int fb_id;
+
+ igt_output_set_pipe(output, pipe);
+
+ mode = igt_output_get_mode(output);
+
+ primary = igt_output_get_plane(output, 0);
+
+ fb_id = igt_create_color_fb(data-drm_fd,
+ mode-hdisplay, mode-vdisplay,
+ DRM_FORMAT_XRGB, I915_TILING_NONE,
+ 1.0, 1.0, 1.0, fb);
+ igt_assert(fb_id = 0);
+
+ igt_plane_set_fb(primary, fb);
+ return igt_display_try_commit2(data-display, COMMIT_LEGACY);
+}
+
+static int
+set_big_mode_on_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+ igt_output_override_mode(output, mode_3_lanes);
+ return
Re: [Intel-gfx] [PATCH] drm/i915: fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl
On Fri, Mar 27, 2015 at 08:18:28AM -0700, Jesse Barnes wrote: On 03/27/2015 01:04 AM, Daniel Vetter wrote: On Fri, Mar 27, 2015 at 08:39:56AM +0200, Jani Nikula wrote: On Thu, 26 Mar 2015, Tommi Rantala tt.rant...@gmail.com wrote: Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl. Signed-off-by: Tommi Rantala tt.rant...@gmail.com Whoa. Broken since its introduction in commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e Author: Jesse Barnes jbar...@virtuousgeek.org Date: Tue Jan 3 08:05:39 2012 -0800 drm/i915: add color key support v4 Cc: sta...@vger.kernel.org Nope, we'll just rip it out and replace it all with the drm_noop ioctl. At least I didn't find any userspace anywhere and only broken definitions. Proof enough this isn't useful. Even more so since that means we don't have to convert the get ioctl over to atomic, yay! I'll send patches. Can we just skip the noop part and delete it altogether? It was only added speculatively and obviously never used at all... The table is indexed, we need a dummy entry. I guess we could do a drm_invalid_ioctl function too for these, but then whether you get an error or not doesn't really matter for unused ioctls. Hence I've stuck with drm_noop for all these removed ioctl (except when we need a more tailore-made lie to keep userspace happy). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] kms_rotation_crc: Adding test for 90/270 rotation
Adding 90/270 rotation testcase for primary and sprite planes.
v2: Added position test for sprite. Checking for gen 9 for 90/270.
Some cleanup and rebase.
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
tests/kms_rotation_crc.c | 175 +-
1 file changed, 142 insertions(+), 33 deletions(-)
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index e11d7a9..cf946ea 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -28,14 +28,19 @@
#include igt_debugfs.h
#include igt_kms.h
#include igt_core.h
+#include intel_chipset.h
typedef struct {
int gfx_fd;
igt_display_t display;
struct igt_fb fb;
struct igt_fb fb_cursor;
+ struct igt_fb fb_full;
igt_crc_t ref_crc;
igt_pipe_crc_t *pipe_crc;
+ igt_rotation_t rotation;
+ int pos_x;
+ int pos_y;
} data_t;
static void
@@ -63,18 +68,46 @@ paint_squares(data_t *data, struct igt_fb *fb,
drmModeModeInfo *mode,
w = mode-hdisplay;
h = mode-vdisplay;
- cr = igt_get_cairo_ctx(data-gfx_fd, data-fb);
+ cr = igt_get_cairo_ctx(data-gfx_fd, fb);
if (rotation == IGT_ROTATION_180) {
cairo_translate(cr, w, h);
cairo_rotate(cr, M_PI);
}
- /* Paint with 4 squares of Red, Green, White, Blue Clockwise */
- igt_paint_color(cr, 0, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
- igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 0.0, 1.0, 0.0);
- igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 0.0, 0.0, 1.0);
- igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 1.0, 1.0, 1.0);
+ /*
+* rotation is used for creating ref rotated fb and
+* data-rotation is used to determine the required size
+* while creating unrotated fb.
+*/
+ if (rotation == IGT_ROTATION_90) {
+ /* Paint 4 squares with width == height in Blue, Red,
+ Green, White Clockwise order to look like 90 degree
rotated*/
+ w = h = mode-vdisplay;
+ igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 0.0, 1.0);
+ igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 0.0,
0.0);
+ igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 1.0,
1.0);
+ igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0,
1.0, 0.0);
+
+ } else if (rotation == IGT_ROTATION_270) {
+ /* Paint 4 squares with width == height in Green, White,
+ Blue, Red Clockwise order to look like 270 degree
rotated*/
+ w = h = mode-vdisplay;
+ igt_paint_color(cr, 0, 0, w / 2, h / 2, 0.0, 1.0, 0.0);
+ igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 1.0, 1.0,
1.0);
+ igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 1.0, 0.0,
0.0);
+ igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 0.0,
0.0, 1.0);
+
+ } else {
+ if (data-rotation == IGT_ROTATION_90 ||
+ data-rotation == IGT_ROTATION_270)
+ w = h = mode-vdisplay;
+ /* Paint with 4 squares of Red, Green, White, Blue
Clockwise */
+ igt_paint_color(cr, 0, 0, w / 2, h / 2, 1.0, 0.0, 0.0);
+ igt_paint_color(cr, w / 2, 0, w / 2, h / 2, 0.0, 1.0,
0.0);
+ igt_paint_color(cr, 0, h / 2, w / 2, h / 2, 0.0, 0.0,
1.0);
+ igt_paint_color(cr, w / 2, h / 2, w / 2, h / 2, 1.0,
1.0, 1.0);
+ }
}
cairo_destroy(cr);
}
@@ -84,7 +117,12 @@ static void prepare_crtc(data_t *data, igt_output_t
*output, enum pipe pipe,
{
drmModeModeInfo *mode;
igt_display_t *display = data-display;
- int fb_id, fb_cursor_id;
+ int fb_id, fb_cursor_id, fb_full_id;
+ int w, h;
+ uint64_t tiling = LOCAL_DRM_FORMAT_MOD_NONE;
+ enum igt_commit_style commit = COMMIT_LEGACY;
+ int old_rotation;
+ igt_plane_t *primary;
igt_output_set_pipe(output, pipe);
@@ -94,10 +132,45 @@ static void prepare_crtc(data_t *data, igt_output_t
*output, enum pipe pipe,
mode = igt_output_get_mode(output);
+ w = mode-hdisplay;
+ h = mode-vdisplay;
+
+ fb_full_id = igt_create_fb(data-gfx_fd,
+ w, h,
+ DRM_FORMAT_XRGB,
+ tiling,
+ data-fb_full);
+ igt_assert(fb_full_id);
+
+ /*
+* With igt_display_commit2 and COMMIT_UNIVERSAL, we call just the
+* setplane without a modeset. So, to be able to call
+*
[Intel-gfx] [PATCH 2/2] drm/i915/skl: Support for 90/270 rotation
v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding check for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using src_* params instead of crtc_* for offset
and size programming (Ville)
v5: Rebased on -nightly and Tvrtko's series for gtt remapping.
v6: Rebased on -nightly (Tvrtko's series merged)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_display.c | 103 +++---
drivers/gpu/drm/i915/intel_drv.h |6 ++
drivers/gpu/drm/i915/intel_sprite.c | 52 -
4 files changed, 129 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6..564bbd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4854,7 +4854,9 @@ enum skl_disp_power_wells {
#define PLANE_CTL_ALPHA_HW_PREMULTIPLY ( 3 4)
#define PLANE_CTL_ROTATE_MASK0x3
#define PLANE_CTL_ROTATE_0 0x0
+#define PLANE_CTL_ROTATE_90 0x1
#define PLANE_CTL_ROTATE_180 0x2
+#define PLANE_CTL_ROTATE_270 0x3
#define _PLANE_STRIDE_1_A 0x70188
#define _PLANE_STRIDE_2_A 0x70288
#define _PLANE_STRIDE_3_A 0x70388
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0bbc22..86ee0f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2318,6 +2318,28 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
return -EINVAL;
}
+ switch (fb-pixel_format) {
+ case DRM_FORMAT_XRGB:
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_XBGR:
+ case DRM_FORMAT_ABGR:
+ case DRM_FORMAT_XRGB2101010:
+ case DRM_FORMAT_ARGB2101010:
+ case DRM_FORMAT_XBGR2101010:
+ case DRM_FORMAT_ABGR2101010:
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_YVYU:
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_NV12:
+ break;
+
+ default:
+ DRM_DEBUG_KMS(Unsupported pixel format:%d for 90/270
rotation!\n,
+ fb-pixel_format);
+ return -EINVAL;
+ }
+
return 0;
}
@@ -2919,8 +2941,12 @@ static void skylake_update_primary_plane(struct drm_crtc
*crtc,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct drm_i915_gem_object *obj;
int pipe = intel_crtc-pipe;
- u32 plane_ctl, stride_div;
+ u32 plane_ctl, stride_div, stride;
+ u32 tile_height, plane_offset, plane_size;
+ unsigned int rotation;
+ int x_offset, y_offset;
unsigned long surf_addr;
+ struct drm_plane *plane;
if (!intel_crtc-primary_enabled) {
I915_WRITE(PLANE_CTL(pipe, 0), 0);
@@ -2981,21 +3007,51 @@ static void skylake_update_primary_plane(struct
drm_crtc *crtc,
}
plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE;
- if (crtc-primary-state-rotation == BIT(DRM_ROTATE_180))
+
+ plane = crtc-primary;
+ rotation = plane-state-rotation;
+ switch (rotation) {
+ case BIT(DRM_ROTATE_90):
+ plane_ctl |= PLANE_CTL_ROTATE_90;
+ break;
+
+ case BIT(DRM_ROTATE_180):
plane_ctl |= PLANE_CTL_ROTATE_180;
+ break;
+
+ case BIT(DRM_ROTATE_270):
+ plane_ctl |= PLANE_CTL_ROTATE_270;
+ break;
+ }
obj = intel_fb_obj(fb);
stride_div = intel_fb_stride_alignment(dev, fb-modifier[0],
fb-pixel_format);
- surf_addr = intel_plane_obj_offset(to_intel_plane(crtc-primary), obj);
+ surf_addr = intel_plane_obj_offset(to_intel_plane(plane), obj);
+
+ if (rotation (BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_270))) {
+ /* stride = Surface height in tiles */
+ tile_height = intel_tile_height(dev, fb-bits_per_pixel,
+ fb-modifier[0]);
+ stride = DIV_ROUND_UP(fb-height, tile_height);
+ x_offset = stride * tile_height - y - (plane-state-src_h
16);
+ y_offset = x;
+ plane_size = ((plane-state-src_w 16) - 1) 16 |
+ ((plane-state-src_h 16) - 1);
+ } else {
+ stride = fb-pitches[0] / stride_div;
+ x_offset = x;
+ y_offset = y;
+ plane_size = ((plane-state-src_h 16) - 1) 16 |
+ ((plane-state-src_w 16) - 1);
+ }
+
Re: [Intel-gfx] [PATCH] Enable dithering on intel VCH DVO chips on 18bpp panels
On Sat, Mar 28, 2015 at 11:07:09AM +0100, Thomas Richter wrote:
Hi folks,
this is a patch against drm-intel-nightly that enables an apparently
undocumented feature of the intel VCH DVO chips. Bit 4 of the VR01 register
controls an automatic dithering for 18bpp outputs which greatly improves the
visual image quality for 24bpp display buffers.
The bios of my IBM R31 automatically enables this feature, it is disabled
again by the ivchr driver. The following patch checks whether the display is
connected with a 18bpp connection and if so, re-enables dithering.
This feature has been tested to work fine on 16bpp images and with the
scaler on and off. There are no ill side effects.
Please let me know whether this patch is acceptable.
Thanks and greetings,
Thomas
Signed-off-by: Thomas Richter t...@math.tu-berlin.de
Patch looks good but seems mangled. Can you please resend using git
send-email? That tool takes care of all the details. Also if you want to
add a few things which should not be part of the commit message you can
put them below the the s-o-b line like this:
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
Further explanations and context goes here
Cheers, Daniel
git apply-mbox will the automatically cut away everything below the ---
line and only take the text above it as the commit message.
Thanks, Daniel
---
drivers/gpu/drm/i915/dvo_ivch.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ivch.c
b/drivers/gpu/drm/i915/dvo_ivch.c
index 0f2587f..89b08a8 100644
--- a/drivers/gpu/drm/i915/dvo_ivch.c
+++ b/drivers/gpu/drm/i915/dvo_ivch.c
@@ -23,6 +23,9 @@
* Authors:
*Eric Anholt e...@anholt.net
*
+ * Minor modifications (Dithering enable):
+ *Thomas Richter t...@math.tu-berlin.de
+ *
*/
#include dvo.h
@@ -59,6 +62,8 @@
# define VR01_DVO_BYPASS_ENABLE(1 1)
/** Enables the DVO clock */
# define VR01_DVO_ENABLE (1 0)
+/** Enable dithering for 18bpp panels. Not documented. */
+# define VR01_DITHER_ENABLE (1 4)
/*
* LCD Interface Format
@@ -74,6 +79,8 @@
# define VR10_INTERFACE_2X18 (2 2)
/** Enables 2x24-bit LVDS output */
# define VR10_INTERFACE_2X24 (3 2)
+/** Mask that defines the depth of the pipeline */
+# define VR10_INTERFACE_DEPTH_MASK (3 2)
/*
* VR20 LCD Horizontal Display Size
@@ -342,9 +349,15 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
struct drm_display_mode *adjusted_mode)
{
uint16_t vr40 = 0;
- uint16_t vr01;
+ uint16_t vr01 = 0;
+ uint16_t vr10;
+
+ ivch_read(dvo, VR10, vr10);
+ /* Enable dithering for 18 bpp pipelines */
+ vr10 = VR10_INTERFACE_DEPTH_MASK;
+ if (vr10 == VR10_INTERFACE_2X18 || vr10 == VR10_INTERFACE_1X18)
+ vr01 = VR01_DITHER_ENABLE;
- vr01 = 0;
vr40 = (VR40_STALL_ENABLE | VR40_VERTICAL_INTERP_ENABLE |
VR40_HORIZONTAL_INTERP_ENABLE);
@@ -353,7 +366,7 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
uint16_t x_ratio, y_ratio;
vr01 |= VR01_PANEL_FIT_ENABLE;
- vr40 |= VR40_CLOCK_GATING_ENABLE;
+ vr40 |= VR40_CLOCK_GATING_ENABLE |
VR40_ENHANCED_PANEL_FITTING;
x_ratio = (((mode-hdisplay - 1) 16) /
(adjusted_mode-hdisplay - 1)) 2;
y_ratio = (((mode-vdisplay - 1) 16) /
@@ -380,6 +393,8 @@ static void ivch_dump_regs(struct intel_dvo_device *dvo)
DRM_DEBUG_KMS(VR00: 0x%04x\n, val);
ivch_read(dvo, VR01, val);
DRM_DEBUG_KMS(VR01: 0x%04x\n, val);
+ ivch_read(dvo, VR10, val);
+ DRM_DEBUG_KMS(VR10: 0x%04x\n, val);
ivch_read(dvo, VR30, val);
DRM_DEBUG_KMS(VR30: 0x%04x\n, val);
ivch_read(dvo, VR40, val);
--
1.7.10.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: map GTT as uncached
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com
On 03/27/2015 01:07 PM, Imre Deak wrote:
On Broxton per specification the GTT has to be mapped as uncached.
This was caught by the PTE write readback warning, which showed a
corrupted PTE value with using the current write-combine mapping.
v2:
- add comment explaining how the problem with WC mapping manifests
(Daniel)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e33b121..4d15237 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2256,7 +2256,17 @@ static int ggtt_probe_common(struct drm_device *dev,
gtt_phys_addr = pci_resource_start(dev-pdev, 0) +
(pci_resource_len(dev-pdev, 0) / 2);
- dev_priv-gtt.gsm = ioremap_wc(gtt_phys_addr, gtt_size);
+ /*
+ * On BXT writes larger than 64 bit to the GTT pagetable range will be
+ * dropped. For WC mappings in general we have 64 byte burst writes
+ * when the WC buffer is flushed, so we can't use it, but have to
+ * resort to an uncached mapping. The WC issue is easily caught by the
+ * readback check when writing GTT PTE entries.
+ */
+ if (IS_BROXTON(dev))
+ dev_priv-gtt.gsm = ioremap_nocache(gtt_phys_addr, gtt_size);
+ else
+ dev_priv-gtt.gsm = ioremap_wc(gtt_phys_addr, gtt_size);
if (!dev_priv-gtt.gsm) {
DRM_ERROR(Failed to map the gtt page table\n);
return -ENOMEM;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/49] drm/i915/bxt: BXT FBC enablement
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com
On 03/17/2015 11:39 AM, Imre Deak wrote:
From: Daisy Sun daisy@intel.com
Enable FBC feature on Broxton
Issue: VIZ-3784
Signed-off-by: Daisy Sun daisy@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4d50785..48434cb6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -388,6 +388,7 @@ static const struct intel_device_info intel_broxton_info
= {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_pipes = 3,
.has_ddi = 1,
+ .has_fbc = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Copy the staged connector config to the legacy atomic state
On Fri, 2015-03-27 at 17:36 +0300, Dan Carpenter wrote:
Hello Ander Conselvan de Oliveira,
This is a semi-automatic email about new static checker warnings.
The patch 944b0c765757: drm/i915: Copy the staged connector config
to the legacy atomic state from Mar 20, 2015, leads to the following
Smatch complaint:
drivers/gpu/drm/i915/intel_display.c:9118 intel_release_load_detect_pipe()
error: we previously assumed 'state' could be null (see line 9082)
drivers/gpu/drm/i915/intel_display.c
9081state = drm_atomic_state_alloc(dev);
9082if (!state)
9083goto fail;
^
Patch changes a return into a goto.
9084
9085state-acquire_ctx = ctx;
9086
9087connector_state =
drm_atomic_get_connector_state(state, connector);
9088if (IS_ERR(connector_state))
9089goto fail;
9090
9091to_intel_connector(connector)-new_encoder =
NULL;
9092intel_encoder-new_crtc = NULL;
9093intel_crtc-new_enabled = false;
9094intel_crtc-new_config = NULL;
9095
9096connector_state-best_encoder = NULL;
9097connector_state-crtc = NULL;
9098
9099intel_set_mode(crtc, NULL, 0, 0, NULL, state);
9100
9101drm_atomic_state_free(state);
9102
9103if (old-release_fb) {
9104
drm_framebuffer_unregister_private(old-release_fb);
9105
drm_framebuffer_unreference(old-release_fb);
9106}
9107
9108return;
9109}
9110
9111/* Switch crtc and encoder back off if necessary */
9112if (old-dpms_mode != DRM_MODE_DPMS_ON)
9113connector-funcs-dpms(connector,
old-dpms_mode);
9114
9115return;
9116fail:
9117DRM_DEBUG_KMS(Couldn't release load detect pipe.\n);
9118drm_atomic_state_free(state);
^
Dereferenced inside function call.
That's odd, this is checking the fail label inside another function.
The change above was in intel_get_load_detect_pipe(), and this is in
intel_release_load_detect_pipe().
Anyway, the fail path in intel_get_load_detect_pipe() does check for
state being NULL before using it.
Cheers,
Ander
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check lane sharing between pipes B C using atomic state
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6087 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -2 270/270 268/270 ILK 303/303 303/303 SNB 304/304 304/304 IVB 337/337 337/337 BYT 287/287 287/287 HSW 361/361 361/361 BDW 309/309 309/309 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt@gem_userptr_blits@coherency-sync CRASH(1)PASS(2) CRASH(1)PASS(1) *PNV igt@gem_tiled_pread_pwrite PASS(3) FAIL(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Clear crtcs, connectors and planes when clearing state
On Mon, Mar 30, 2015 at 10:41:19AM +0300, Ander Conselvan de Oliveira wrote: Users of the atomic state assume that if the pointer to a crtc, plane or connector is not NULL in the respective object vector, than the state for that object in *_states vector also won't be NULL. That assumption was broken by drm_atomic_state_clear(), which would clear the state pointer but leave the pointer to the object still set. This fixes a NULL pointer dereference in i915 caused by the use of drm_atomic_state_clear(). Cc: dri-de...@lists.freedesktop.org Signed-off-by: Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com Oops. Applied to topic/drm-misc. Thanks, Daniel --- drivers/gpu/drm/drm_atomic.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 5d3abe3..00ea881 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -134,6 +134,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state) connector-funcs-atomic_destroy_state(connector, state-connector_states[i]); + state-connectors[i] = NULL; state-connector_states[i] = NULL; } @@ -145,6 +146,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state) crtc-funcs-atomic_destroy_state(crtc, state-crtc_states[i]); + state-crtcs[i] = NULL; state-crtc_states[i] = NULL; } @@ -156,6 +158,7 @@ void drm_atomic_state_clear(struct drm_atomic_state *state) plane-funcs-atomic_destroy_state(plane, state-plane_states[i]); + state-planes[i] = NULL; state-plane_states[i] = NULL; } } -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://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 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reject the colorkey ioctls for primary and cursor planes
On Fri, Mar 27, 2015 at 07:59:40PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The legcy colorkey ioctls are only implemented for sprite planes, so
reject the ioctl for primary/cursor planes. If we want to support
colorkeying with these planes (assuming we have hw support of course)
we should just move ahead with the colorkey property conversion.
Cc: Tommi Rantala tt.rant...@gmail.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Testcase: kms_legacy_colorkey
Cc: sta...@vger.kernel.org
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index f41e872..7017384 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1113,7 +1113,7 @@ int intel_sprite_set_colorkey(struct drm_device *dev,
void *data,
drm_modeset_lock_all(dev);
plane = drm_plane_find(dev, set-plane_id);
- if (!plane) {
+ if (!plane || plane-type != DRM_PLANE_TYPE_OVERLAY) {
ret = -ENOENT;
goto out_unlock;
}
@@ -1145,7 +1145,7 @@ int intel_sprite_get_colorkey(struct drm_device *dev,
void *data,
drm_modeset_lock_all(dev);
plane = drm_plane_find(dev, get-plane_id);
- if (!plane) {
+ if (!plane || plane-type != DRM_PLANE_TYPE_OVERLAY) {
ret = -ENOENT;
goto out_unlock;
}
--
2.0.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: PSR: Keep sink state consistent with source
On Fri, Mar 27, 2015 at 06:51:57PM +, Vivi, Rodrigo wrote:
Thanks
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Tested-by: Rodrigo Vivi rodrigo.v...@intel.com
Queued for -next, thanks for the patch.
-Daniel
On Fri, 2015-03-27 at 17:21 +0530, Durgadoss R wrote:
BSpec recommends to keep the main link state consistent
between the source and the sink. As per that, update
the main link state in sink DPCD register to 'active',
for Valleyview based platforms.
Signed-off-by: Durgadoss R durgados...@intel.com
---
drivers/gpu/drm/i915/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c
b/drivers/gpu/drm/i915/intel_psr.c
index b9f40c2..94e14f2 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -133,7 +133,7 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
static void vlv_psr_enable_sink(struct intel_dp *intel_dp)
{
drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
- DP_PSR_ENABLE);
+ DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE);
}
static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only enabled DRRS if PRS won't be enabled on this pipe.
Looks good to me..
Reviewed-by: Ramalingam C ramalinga...@intel.com
On Friday 27 March 2015 12:51 AM, Rodrigo Vivi wrote:
With PSR enabled being pre computed on pipe_config we can now
prevent DRRS to be enabled along with PSR.
v2: Rebase after changing previous patch
Cc: Ramalingam C ramalinga...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e6b1c42..5551b3c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4994,11 +4994,6 @@ static void intel_dp_set_drrs_state(struct drm_device
*dev, int refresh_rate)
return;
}
- /*
-* FIXME: This needs proper synchronization with psr state for some
-* platforms that cannot have PSR and DRRS enabled at the same time.
-*/
-
dig_port = dp_to_dig_port(intel_dp);
encoder = dig_port-base;
intel_crtc = encoder-new_crtc;
@@ -5084,6 +5079,11 @@ void intel_edp_drrs_enable(struct intel_dp *intel_dp)
return;
}
+ if (intel_crtc-config-psr_ready) {
+ DRM_DEBUG_KMS(DRRS: PSR will be enabled on this crtc\n);
+ return;
+ }
+
mutex_lock(dev_priv-drrs.mutex);
if (WARN_ON(dev_priv-drrs.dp)) {
DRM_ERROR(DRRS already enabled\n);
--
Thanks,
--Ram
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915: Setup static bias for GPU
On Sat, Mar 28, 2015 at 03:23:38PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.
My understanding is that this would only improve the GPU performance
under TDP constrained use cases, at the cost of CPU performance. So
it's not some magic bullet that makes things just faster (tm).
Signed-off-by: Deepak S deepa...@linux.intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_pm.c | 12
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6..ea708ba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -670,6 +670,11 @@ enum skl_disp_power_wells {
#define FB_FMAX_VMIN_FREQ_LO_SHIFT 27
#define FB_FMAX_VMIN_FREQ_LO_MASK 0xf800
+#define VLV_IOSFB_RPS_OVERRIDE 0x04
+#define VLV_OVERRIDE_RPS_MASK1
+#define VLV_ENABLE_BIAS_SHARE(1 1)
+#define VLV_BIAS_VAL (6 2)
Can we use better names for these (from configdb, say)?
+
#define VLV_CZ_CLOCK_TO_MILLI_SEC10
#define VLV_RP_UP_EI_THRESHOLD 90
#define VLV_RP_DOWN_EI_THRESHOLD 70
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 88e71a3..673612b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5015,6 +5015,12 @@ static void cherryview_enable_rps(struct drm_device
*dev)
GEN6_RP_UP_BUSY_AVG |
GEN6_RP_DOWN_IDLE_AVG);
+ /* Setting Fixed Bias */
+ val = VLV_OVERRIDE_RPS_MASK |
+ VLV_ENABLE_BIAS_SHARE |
+ VLV_BIAS_VAL;
+ vlv_punit_write(dev_priv, VLV_IOSFB_RPS_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
/* RPS code assumes GPLL is used */
@@ -5099,6 +5105,12 @@ static void valleyview_enable_rps(struct drm_device
*dev)
I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
+ /* Setting Fixed Bias */
+ val = VLV_OVERRIDE_RPS_MASK |
+ VLV_ENABLE_BIAS_SHARE |
+ VLV_BIAS_VAL;
+ vlv_punit_write(dev_priv, VLV_IOSFB_RPS_OVERRIDE, val);
+
val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
/* RPS code assumes GPLL is used */
--
1.9.1
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add psr_ready on pipe_config
Looks good to me..
Reviewed-by: Ramalingam C ramalinga...@intel.com
On Friday 27 March 2015 12:50 AM, Rodrigo Vivi wrote:
Let's know beforehand if PSR is ready and will be enabled so we can
prevent DRRS to get enabled.
v2: Removing is_edp_psr func that is not used after this patch.
Rename match_conditions and document it since it is now external.
Moving to a propper place as pointed out by Sivakumar.
Use a better name as pointed out by Ram.
Cc: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
Cc: Ramalingam C ramalinga...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_dp.c | 2 ++
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_psr.c | 50 +---
4 files changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 35cdb48..9112ad9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10367,6 +10367,7 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
pipe_config-pch_pfit.pos,
pipe_config-pch_pfit.size,
pipe_config-pch_pfit.enabled ? enabled : disabled);
+ DRM_DEBUG_KMS(psr ready: %i\n, pipe_config-psr_ready);
DRM_DEBUG_KMS(ips: %i\n, pipe_config-ips_enabled);
DRM_DEBUG_KMS(double wide: %i\n, pipe_config-double_wide);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 637dd53..e6b1c42 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1388,6 +1388,8 @@ intel_dp_compute_config(struct intel_encoder *encoder,
*/
min_lane_count = max_lane_count;
min_clock = max_clock;
+
+ pipe_config-psr_ready = intel_psr_ready(intel_dp);
}
for (; bpp = 6*3; bpp -= 2*3) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c0fa1cb..250d70c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -384,6 +384,7 @@ struct intel_crtc_state {
int fdi_lanes;
struct intel_link_m_n fdi_m_n;
+ bool psr_ready;
bool ips_enabled;
bool double_wide;
@@ -1206,6 +1207,7 @@ void intel_backlight_unregister(struct drm_device *dev);
/* intel_psr.c */
+bool intel_psr_ready(struct intel_dp *intel_dp);
void intel_psr_enable(struct intel_dp *intel_dp);
void intel_psr_disable(struct intel_dp *intel_dp);
void intel_psr_invalidate(struct drm_device *dev,
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index c1ca923..2f22ab6 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -56,11 +56,6 @@
#include intel_drv.h
#include i915_drv.h
-static bool is_edp_psr(struct intel_dp *intel_dp)
-{
- return intel_dp-psr_dpcd[0] DP_PSR_IS_SUPPORTED;
-}
-
static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -249,7 +244,19 @@ static void hsw_psr_enable_source(struct intel_dp
*intel_dp)
EDP_PSR_ENABLE);
}
-static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
+/**
+ * intel_psr_ready - PSR ready
+ * @intel_dp: Intel DP
+ *
+ * This function Checks if PSR is supported by Hardware/Source and
+ * Panel/Sink and if all conditions to be enabled are fulfilled.
+ *
+ * It is used to know beforehand if PSR is going to be enabled.
+ *
+ * Returns:
+ * True when PSR is ready to be enabled, false otherwise.
+ */
+bool intel_psr_ready(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port-base.base.dev;
@@ -257,12 +264,14 @@ static bool intel_psr_match_conditions(struct intel_dp
*intel_dp)
struct drm_crtc *crtc = dig_port-base.base.crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- lockdep_assert_held(dev_priv-psr.lock);
+ if (!HAS_PSR(dev)) {
+ DRM_DEBUG_KMS(PSR not supported on this platform\n);
+ return false;
+ }
+
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
WARN_ON(!drm_modeset_is_locked(crtc-mutex));
- dev_priv-psr.source_ok = false;
-
if (IS_HASWELL(dev) dig_port-port != PORT_A) {
DRM_DEBUG_KMS(HSW ties PSR to DDI A (eDP)\n);
return false;
@@ -292,10 +301,19 @@ static bool intel_psr_match_conditions(struct intel_dp
*intel_dp)
return false;
}
+ /* At this point we can tell HW/Source supports PSR */
dev_priv-psr.source_ok = true;
+
+ /* Now check if Panel/Sink supports it */
+ if (!dev_priv-psr.sink_support) {
+
Re: [Intel-gfx] [PATCH 02.1/49] drm/i915: use proper FBC base register on all new platforms
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com
On 03/26/2015 05:35 PM, Imre Deak wrote:
Starting from GEN5 the FBC base register is the same on all platforms.
GEN=5 is the same condition as HAS_PCH_SPLIT except on BXT, so make
things work on BXT as well.
Motivated by Rodrigo's request to check FBC support on BXT.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index f8da716..348ed5a 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -209,7 +209,7 @@ static int i915_setup_compression(struct drm_device *dev,
int size, int fb_cpp)
dev_priv-fbc.threshold = ret;
- if (HAS_PCH_SPLIT(dev))
+ if (INTEL_INFO(dev_priv)-gen = 5)
I915_WRITE(ILK_DPFC_CB_BASE, dev_priv-fbc.compressed_fb.start);
else if (IS_GM45(dev)) {
I915_WRITE(DPFC_CB_BASE, dev_priv-fbc.compressed_fb.start);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/49] drm/i915/bxt: BXT FBC enablement
Reviewed-by: Antti Koskipää antti.koski...@linux.intel.com
On 03/17/2015 11:39 AM, Imre Deak wrote:
From: Daisy Sun daisy@intel.com
Enable FBC feature on Broxton
Issue: VIZ-3784
Signed-off-by: Daisy Sun daisy@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4d50785..48434cb6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -388,6 +388,7 @@ static const struct intel_device_info intel_broxton_info
= {
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
.num_pipes = 3,
.has_ddi = 1,
+ .has_fbc = 1,
GEN_DEFAULT_PIPEOFFSETS,
IVB_CURSOR_OFFSETS,
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Clear crtcs, connectors and planes when clearing state
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6090 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 270/270 270/270 ILK -1 303/303 302/303 SNB 304/304 304/304 IVB 337/337 337/337 BYT 287/287 287/287 HSW -1 361/361 360/361 BDW 309/309 309/309 -Detailed- Platform Testdrm-intel-nightly Series Applied *ILK igt@gem_unfence_active_buffers PASS(2) DMESG_WARN(1)PASS(1) (dmesg patch applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...bsd_ring_idle@Hangcheck timer elapsed... bsd ring idle *HSW igt@gem_storedw_loop_bsd PASS(2) DMESG_WARN(1)PASS(1) (dmesg patch applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...bsd_ring_idle@Hangcheck timer elapsed... bsd ring idle Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl
On Mon, Mar 30, 2015 at 08:54:55AM +0200, Daniel Vetter wrote: On Fri, Mar 27, 2015 at 08:18:28AM -0700, Jesse Barnes wrote: On 03/27/2015 01:04 AM, Daniel Vetter wrote: On Fri, Mar 27, 2015 at 08:39:56AM +0200, Jani Nikula wrote: On Thu, 26 Mar 2015, Tommi Rantala tt.rant...@gmail.com wrote: Fix definition of the DRM_IOCTL_I915_GET_SPRITE_COLORKEY ioctl, so that it is different from the DRM_IOCTL_I915_SET_SPRITE_COLORKEY ioctl. Signed-off-by: Tommi Rantala tt.rant...@gmail.com Whoa. Broken since its introduction in commit 8ea30864229e54b01ac0e9fe88c4b733a940ec4e Author: Jesse Barnes jbar...@virtuousgeek.org Date: Tue Jan 3 08:05:39 2012 -0800 drm/i915: add color key support v4 Cc: sta...@vger.kernel.org Nope, we'll just rip it out and replace it all with the drm_noop ioctl. At least I didn't find any userspace anywhere and only broken definitions. Proof enough this isn't useful. Even more so since that means we don't have to convert the get ioctl over to atomic, yay! I'll send patches. Can we just skip the noop part and delete it altogether? It was only added speculatively and obviously never used at all... The table is indexed, we need a dummy entry. We shouldn't need any dummies. Any missing entry in the table will be zeroed, so we should simply return -EINVAL due to ioctl-func==NULL. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Enable dithering for intel VCH DVO
On Mon, Mar 30, 2015 at 10:18:53AM +0200, Thomas Richter wrote:
Hi Daniel, hi Ville,
did you get the attached patch? This enables dithering for the iVCH DVO
chip and improves image quality for 24 pipes on 18bpp displays greatly.
Thanks for reviewing and considering this patch.
Yeah that one worked better. Queued for -next, thanks for the patch.
-Daniel
Thomas Richter
From 3d0b1a15302aa704c7cf4ebbf7c2b8a1566b9beb Mon Sep 17 00:00:00 2001
From: Thomas Richter t...@math.tu-berlin.de
Date: Sat, 28 Mar 2015 10:57:46 +0100
Subject: [PATCH 1/1] Enabled dithering in the intel VCH DVO for 18bpp
pipelines.
Signed-off-by: Thomas Richter t...@math.tu-berlin.de
---
drivers/gpu/drm/i915/dvo_ivch.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ivch.c b/drivers/gpu/drm/i915/dvo_ivch.c
index 0f2587f..89b08a8 100644
--- a/drivers/gpu/drm/i915/dvo_ivch.c
+++ b/drivers/gpu/drm/i915/dvo_ivch.c
@@ -23,6 +23,9 @@
* Authors:
*Eric Anholt e...@anholt.net
*
+ * Minor modifications (Dithering enable):
+ *Thomas Richter t...@math.tu-berlin.de
+ *
*/
#include dvo.h
@@ -59,6 +62,8 @@
# define VR01_DVO_BYPASS_ENABLE (1 1)
/** Enables the DVO clock */
# define VR01_DVO_ENABLE (1 0)
+/** Enable dithering for 18bpp panels. Not documented. */
+# define VR01_DITHER_ENABLE (1 4)
/*
* LCD Interface Format
@@ -74,6 +79,8 @@
# define VR10_INTERFACE_2X18 (2 2)
/** Enables 2x24-bit LVDS output */
# define VR10_INTERFACE_2X24 (3 2)
+/** Mask that defines the depth of the pipeline */
+# define VR10_INTERFACE_DEPTH_MASK (3 2)
/*
* VR20 LCD Horizontal Display Size
@@ -342,9 +349,15 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
struct drm_display_mode *adjusted_mode)
{
uint16_t vr40 = 0;
- uint16_t vr01;
+ uint16_t vr01 = 0;
+ uint16_t vr10;
+
+ ivch_read(dvo, VR10, vr10);
+ /* Enable dithering for 18 bpp pipelines */
+ vr10 = VR10_INTERFACE_DEPTH_MASK;
+ if (vr10 == VR10_INTERFACE_2X18 || vr10 == VR10_INTERFACE_1X18)
+ vr01 = VR01_DITHER_ENABLE;
- vr01 = 0;
vr40 = (VR40_STALL_ENABLE | VR40_VERTICAL_INTERP_ENABLE |
VR40_HORIZONTAL_INTERP_ENABLE);
@@ -353,7 +366,7 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
uint16_t x_ratio, y_ratio;
vr01 |= VR01_PANEL_FIT_ENABLE;
- vr40 |= VR40_CLOCK_GATING_ENABLE;
+ vr40 |= VR40_CLOCK_GATING_ENABLE | VR40_ENHANCED_PANEL_FITTING;
x_ratio = (((mode-hdisplay - 1) 16) /
(adjusted_mode-hdisplay - 1)) 2;
y_ratio = (((mode-vdisplay - 1) 16) /
@@ -380,6 +393,8 @@ static void ivch_dump_regs(struct intel_dvo_device *dvo)
DRM_DEBUG_KMS(VR00: 0x%04x\n, val);
ivch_read(dvo, VR01, val);
DRM_DEBUG_KMS(VR01: 0x%04x\n, val);
+ ivch_read(dvo, VR10, val);
+ DRM_DEBUG_KMS(VR10: 0x%04x\n, val);
ivch_read(dvo, VR30, val);
DRM_DEBUG_KMS(VR30: 0x%04x\n, val);
ivch_read(dvo, VR40, val);
--
1.7.10.4
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off
On Sat, Mar 28, 2015 at 03:23:34PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Signed-off-by: Deepak S deepa...@linux.intel.com
Yeah seems OK. We still do the allow wake dance even though we skip
the gunit register save, so I guess the force gfx clock makes sense as
part of that.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 82f8be4..182d6a7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,11 +1194,13 @@ int vlv_force_gfx_clock(struct drm_i915_private
*dev_priv, bool force_on)
int err;
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
- WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG) VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force-off to settle */
- if (force_on) {
+ if (force_on !IS_CHERRYVIEW(dev_priv-dev)) {
+ /* WARN_ON only for the Valleyview */
+ WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off
(%08x)\n,
--
1.9.1
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/skl: Allow universal planes to position
Signed-off-by: Sonika Jindal sonika.jin...@intel.com --- drivers/gpu/drm/i915/intel_display.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ceb2e61..f0bbc22 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12150,16 +12150,21 @@ intel_check_primary_plane(struct drm_plane *plane, struct drm_rect *dest = state-dst; struct drm_rect *src = state-src; const struct drm_rect *clip = state-clip; + bool can_position = false; int ret; crtc = crtc ? crtc : plane-crtc; intel_crtc = to_intel_crtc(crtc); + if (INTEL_INFO(dev)-gen = 9) + can_position = true; + ret = drm_plane_helper_check_update(plane, crtc, fb, src, dest, clip, DRM_PLANE_HELPER_NO_SCALING, DRM_PLANE_HELPER_NO_SCALING, - false, true, state-visible); + can_position, true, + state-visible); if (ret) return ret; -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Enable dithering for intel VCH DVO
Hi Daniel, hi Ville,
did you get the attached patch? This enables dithering for the iVCH DVO
chip and improves image quality for 24 pipes on 18bpp displays greatly.
Thanks for reviewing and considering this patch.
Thomas Richter
From 3d0b1a15302aa704c7cf4ebbf7c2b8a1566b9beb Mon Sep 17 00:00:00 2001
From: Thomas Richter t...@math.tu-berlin.de
Date: Sat, 28 Mar 2015 10:57:46 +0100
Subject: [PATCH 1/1] Enabled dithering in the intel VCH DVO for 18bpp
pipelines.
Signed-off-by: Thomas Richter t...@math.tu-berlin.de
---
drivers/gpu/drm/i915/dvo_ivch.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ivch.c b/drivers/gpu/drm/i915/dvo_ivch.c
index 0f2587f..89b08a8 100644
--- a/drivers/gpu/drm/i915/dvo_ivch.c
+++ b/drivers/gpu/drm/i915/dvo_ivch.c
@@ -23,6 +23,9 @@
* Authors:
*Eric Anholt e...@anholt.net
*
+ * Minor modifications (Dithering enable):
+ *Thomas Richter t...@math.tu-berlin.de
+ *
*/
#include dvo.h
@@ -59,6 +62,8 @@
# define VR01_DVO_BYPASS_ENABLE (1 1)
/** Enables the DVO clock */
# define VR01_DVO_ENABLE (1 0)
+/** Enable dithering for 18bpp panels. Not documented. */
+# define VR01_DITHER_ENABLE (1 4)
/*
* LCD Interface Format
@@ -74,6 +79,8 @@
# define VR10_INTERFACE_2X18 (2 2)
/** Enables 2x24-bit LVDS output */
# define VR10_INTERFACE_2X24 (3 2)
+/** Mask that defines the depth of the pipeline */
+# define VR10_INTERFACE_DEPTH_MASK (3 2)
/*
* VR20 LCD Horizontal Display Size
@@ -342,9 +349,15 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
struct drm_display_mode *adjusted_mode)
{
uint16_t vr40 = 0;
- uint16_t vr01;
+ uint16_t vr01 = 0;
+ uint16_t vr10;
+
+ ivch_read(dvo, VR10, vr10);
+ /* Enable dithering for 18 bpp pipelines */
+ vr10 = VR10_INTERFACE_DEPTH_MASK;
+ if (vr10 == VR10_INTERFACE_2X18 || vr10 == VR10_INTERFACE_1X18)
+ vr01 = VR01_DITHER_ENABLE;
- vr01 = 0;
vr40 = (VR40_STALL_ENABLE | VR40_VERTICAL_INTERP_ENABLE |
VR40_HORIZONTAL_INTERP_ENABLE);
@@ -353,7 +366,7 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
uint16_t x_ratio, y_ratio;
vr01 |= VR01_PANEL_FIT_ENABLE;
- vr40 |= VR40_CLOCK_GATING_ENABLE;
+ vr40 |= VR40_CLOCK_GATING_ENABLE | VR40_ENHANCED_PANEL_FITTING;
x_ratio = (((mode-hdisplay - 1) 16) /
(adjusted_mode-hdisplay - 1)) 2;
y_ratio = (((mode-vdisplay - 1) 16) /
@@ -380,6 +393,8 @@ static void ivch_dump_regs(struct intel_dvo_device *dvo)
DRM_DEBUG_KMS(VR00: 0x%04x\n, val);
ivch_read(dvo, VR01, val);
DRM_DEBUG_KMS(VR01: 0x%04x\n, val);
+ ivch_read(dvo, VR10, val);
+ DRM_DEBUG_KMS(VR10: 0x%04x\n, val);
ivch_read(dvo, VR30, val);
DRM_DEBUG_KMS(VR30: 0x%04x\n, val);
ivch_read(dvo, VR40, val);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Enable dithering on intel VCH DVO chips on 18bpp panels
On Sat, Mar 28, 2015 at 11:07:09AM +0100, Thomas Richter wrote:
Hi folks,
this is a patch against drm-intel-nightly that enables an apparently
undocumented feature of the intel VCH DVO chips. Bit 4 of the VR01
register controls an automatic dithering for 18bpp outputs which greatly
improves the visual image quality for 24bpp display buffers.
The bios of my IBM R31 automatically enables this feature, it is
disabled again by the ivchr driver. The following patch checks whether
the display is connected with a 18bpp connection and if so, re-enables
dithering.
This feature has been tested to work fine on 16bpp images and with the
scaler on and off. There are no ill side effects.
Please let me know whether this patch is acceptable.
Thanks and greetings,
Thomas
Signed-off-by: Thomas Richter t...@math.tu-berlin.de
---
drivers/gpu/drm/i915/dvo_ivch.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ivch.c
b/drivers/gpu/drm/i915/dvo_ivch.c
index 0f2587f..89b08a8 100644
--- a/drivers/gpu/drm/i915/dvo_ivch.c
+++ b/drivers/gpu/drm/i915/dvo_ivch.c
@@ -23,6 +23,9 @@
* Authors:
*Eric Anholt e...@anholt.net
*
+ * Minor modifications (Dithering enable):
+ *Thomas Richter t...@math.tu-berlin.de
+ *
*/
#include dvo.h
@@ -59,6 +62,8 @@
# define VR01_DVO_BYPASS_ENABLE(1 1)
/** Enables the DVO clock */
# define VR01_DVO_ENABLE (1 0)
+/** Enable dithering for 18bpp panels. Not documented. */
+# define VR01_DITHER_ENABLE (1 4)
/*
* LCD Interface Format
@@ -74,6 +79,8 @@
# define VR10_INTERFACE_2X18 (2 2)
/** Enables 2x24-bit LVDS output */
# define VR10_INTERFACE_2X24 (3 2)
+/** Mask that defines the depth of the pipeline */
+# define VR10_INTERFACE_DEPTH_MASK (3 2)
/*
* VR20 LCD Horizontal Display Size
@@ -342,9 +349,15 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
struct drm_display_mode *adjusted_mode)
{
uint16_t vr40 = 0;
- uint16_t vr01;
+ uint16_t vr01 = 0;
+ uint16_t vr10;
+
+ ivch_read(dvo, VR10, vr10);
+ /* Enable dithering for 18 bpp pipelines */
+ vr10 = VR10_INTERFACE_DEPTH_MASK;
+ if (vr10 == VR10_INTERFACE_2X18 || vr10 == VR10_INTERFACE_1X18)
+ vr01 = VR01_DITHER_ENABLE;
- vr01 = 0;
vr40 = (VR40_STALL_ENABLE | VR40_VERTICAL_INTERP_ENABLE |
VR40_HORIZONTAL_INTERP_ENABLE);
@@ -353,7 +366,7 @@ static void ivch_mode_set(struct intel_dvo_device *dvo,
uint16_t x_ratio, y_ratio;
vr01 |= VR01_PANEL_FIT_ENABLE;
- vr40 |= VR40_CLOCK_GATING_ENABLE;
+ vr40 |= VR40_CLOCK_GATING_ENABLE |
VR40_ENHANCED_PANEL_FITTING;
You're also enabling this other bit. The spec isn't very clear on most
things, but I might assume this enables the higher order upscale filter.
I don't see any programmable parameters for the filter in spec, so it
might be safe to just enable it always. But yeah, not really sure about
that. OTOH I don't expect this DVO chip to be in use in many other
machines, so chances of breaking some other machine seem rather low.
However it would seems better if this was a separate patch, or of it's
really just a part of getting the dither bit to work then it would be
good to at least mention that fact in the commit message, or maybe
add a comment into the code explaining the relationship of the two bits
(assuming there is one).
x_ratio = (((mode-hdisplay - 1) 16) /
(adjusted_mode-hdisplay - 1)) 2;
y_ratio = (((mode-vdisplay - 1) 16) /
@@ -380,6 +393,8 @@ static void ivch_dump_regs(struct intel_dvo_device *dvo)
DRM_DEBUG_KMS(VR00: 0x%04x\n, val);
ivch_read(dvo, VR01, val);
DRM_DEBUG_KMS(VR01: 0x%04x\n, val);
+ ivch_read(dvo, VR10, val);
+ DRM_DEBUG_KMS(VR10: 0x%04x\n, val);
ivch_read(dvo, VR30, val);
DRM_DEBUG_KMS(VR30: 0x%04x\n, val);
ivch_read(dvo, VR40, val);
--
1.7.10.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/49] drm/i915: Implement inter-engine read-read optimisations
On Mon, Mar 30, 2015 at 02:52:26PM +0100, Tvrtko Ursulin wrote:
+static void
+__i915_gem_request_retire__upto(struct drm_i915_gem_request *rq)
It is a bit annoying (for readability) that it can be rq, req and request.
Nonsense they are all rq and struct i915_request. Or once have been and
so will again. /prophecy
+err:
+for (i = 0; i n; i++) {
+if (ret == 0) {
+int ring = requests[i]-ring-id;
+if (obj-last_read_req[ring] == requests[i])
+i915_gem_object_retire__read(obj, ring);
+if (obj-last_write_req == requests[i])
+i915_gem_object_retire__write(obj);
Above four lines seem to be identical functionality to similar four
in __i915_gem_object_sync.
Yes. Extracting them ended up looking worse (imo).
Also, _retire__read will do _retire__write if there is one on the
same ring. And here by definition they are since it is the same
request, no?
No. It's subtle but here is the bug I pointed out from before. Once we
drop the lock, we no longer can make assumptions about the state of obj.
@@ -2698,16 +2747,13 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
if (!i915_gem_request_completed(request, true))
break;
-trace_i915_gem_request_retire(request);
-
/* We know the GPU must have read the request to have
* sent us the seqno + interrupt, so use the position
* of tail of the request to update the last known position
* of the GPU head.
*/
request-ringbuf-last_retired_head = request-postfix;
-
-i915_gem_free_request(request);
+i915_gem_request_retire(request);
}
This loop could also use __i915_gem_request_retire__upto if it found
the first completed request first. Not sure how much code would that
save but would maube be more readable, a little bit more self
documenting.
Actually this loop here should be pushed back to the engine (as part of
later patches). After that transformation, using i915_gem_request_retire()
is even clearer. But _retire__upto does become the main way in which we
retire requests (having killed off retire_requests_ring in favour of
explict wait/poll+retire).
So far it all looks reasonable to me, but apart from the comments
above, I want to do another pass anyway.
There's a few more changes afoot as well (minor ones concerning
retire__upto and unexporting retire_requests_rig).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] R31 dithering
Am 30.03.2015 um 13:55 schrieb Ville Syrjälä: On Fri, Mar 27, 2015 at 07:57:52PM +0100, Thomas Richter wrote: Thanks and have a nice weekend, BTW I think this bug is about failure to restore the ivch to proper state after suspend (on X30): https://bugs.freedesktop.org/show_bug.cgi?id=49838 Just in case you're looking for more stuff to do around the ivch ;) Well, no x30 around here unfortunately, though I can possibly check for helpers in a German Thinkpad forum. Maybe somebody with enough Linux-awareness can remote-debug and provide a couple of register listings to re-enable the DVO as required during wake-up. Or provides an x30. (-: I'll check and let you know. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] R31 dithering
On Mon, Mar 30, 2015 at 03:54:29PM +0200, Thomas Richter wrote: Am 30.03.2015 um 13:55 schrieb Ville Syrjälä: On Fri, Mar 27, 2015 at 07:57:52PM +0100, Thomas Richter wrote: Thanks and have a nice weekend, BTW I think this bug is about failure to restore the ivch to proper state after suspend (on X30): https://bugs.freedesktop.org/show_bug.cgi?id=49838 Just in case you're looking for more stuff to do around the ivch ;) Well, no x30 around here unfortunately, though I can possibly check for helpers in a German Thinkpad forum. Maybe somebody with enough Linux-awareness can remote-debug and provide a couple of register listings to re-enable the DVO as required during wake-up. Or provides an x30. (-: I'll check and let you know. I was assuming your R31 or whatever would have the same problems. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_tiled_fence_blits: split into subtests
On Tue, Mar 24, 2015 at 02:16:04PM +, tim.g...@intel.com wrote: From: Tim Gore tim.g...@intel.com The gem_tiled_fence_blits test tends to get oom killed on low memory ( 4GB) Android systems. This is because the test tries to allocate (sysinfo.totalram * 9 / 10) in buffer objects and the remaining 10% of memory is not always enough for the Android system. As with a similar issue with gem_render_linear_blits, this problem is resolved by splitting into subtests. A basic subtest uses minimal memory buffers to test the basic operation, and a normal subtest which is skipped if there is insufficient memory. I also took the opportunity to cull some numeric literals. Signed-off-by: Tim Gore tim.g...@intel.com Looks good, thanks. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Don't try to free a NULL state
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6092 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 270/270 269/270 ILK 303/303 303/303 SNB 304/304 304/304 IVB 337/337 337/337 BYT 287/287 287/287 HSW 361/361 361/361 BDW 309/309 309/309 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt@gem_userptr_blits@coherency-sync CRASH(3)PASS(2) CRASH(2) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/49] drm/i915: Implement inter-engine read-read optimisations
Hi,
On 03/27/2015 11:01 AM, Chris Wilson wrote:
Currently, we only track the last request globally across all engines.
This prevents us from issuing concurrent read requests on e.g. the RCS
and BCS engines (or more likely the render and media engines). Without
semaphores, we incur costly stalls as we synchronise between rings -
greatly impacting the current performance of Broadwell versus Haswell in
certain workloads (like video decode). With the introduction of
reference counted requests, it is much easier to track the last request
per ring, as well as the last global write request so that we can
optimise inter-engine read read requests (as well as better optimise
certain CPU waits).
v2: Fix inverted readonly condition for nonblocking waits.
v3: Handle non-continguous engine array after waits
v4: Rebase, tidy, rewrite ring list debugging
v5: Use obj-active as a bitfield, it looks cool
v6: Micro-optimise, mostly involving moving code around
Benchmark: igt/gem_read_read_speed
hsw:gt3e (with semaphores):
Before: Time to read-read 1024k:275.794µs
After: Time to read-read 1024k:123.260µs
hsw:gt3e (w/o semaphores):
Before: Time to read-read 1024k:230.433µs
After: Time to read-read 1024k:124.593µs
bdw-u (w/o semaphores): Before After
Time to read-read 1x1:26.274µs 10.350µs
Time to read-read 128x128:40.097µs 21.366µs
Time to read-read 256x256:77.087µs 42.608µs
Time to read-read 512x512: 281.999µs 181.155µs
Time to read-read 1024x1024:1196.141µs 1118.223µs
Time to read-read 2048x2048:5639.072µs 5225.837µs
Time to read-read 4096x4096: 22401.662µs21137.067µs
Time to read-read 8192x8192: 89617.735µs85637.681µs
Testcase: igt/gem_concurrent_blit (read-read and friends)
Cc: Lionel Landwerlin lionel.g.landwer...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 16 +-
drivers/gpu/drm/i915/i915_drv.h | 19 +-
drivers/gpu/drm/i915/i915_gem.c | 516 +++-
drivers/gpu/drm/i915/i915_gem_context.c | 2 -
drivers/gpu/drm/i915/i915_gem_debug.c | 92 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 19 +-
drivers/gpu/drm/i915/intel_display.c| 4 +-
drivers/gpu/drm/i915/intel_lrc.c| 15 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +-
9 files changed, 386 insertions(+), 307 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7ef6295438e9..5cea9a9c1cb9 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -120,10 +120,13 @@ static inline const char *get_global_flag(struct
drm_i915_gem_object *obj)
static void
describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
{
+ struct drm_i915_private *dev_priv = to_i915(obj-base.dev);
+ struct intel_engine_cs *ring;
struct i915_vma *vma;
int pin_count = 0;
+ int i;
- seq_printf(m, %pK: %s%s%s%s %8zdKiB %02x %02x %x %x %x%s%s%s,
+ seq_printf(m, %pK: %s%s%s%s %8zdKiB %02x %02x [ ,
obj-base,
obj-active ? * : ,
get_pin_flag(obj),
@@ -131,8 +134,11 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
get_global_flag(obj),
obj-base.size / 1024,
obj-base.read_domains,
- obj-base.write_domain,
- i915_gem_request_get_seqno(obj-last_read_req),
+ obj-base.write_domain);
+ for_each_ring(ring, dev_priv, i)
+ seq_printf(m, %x ,
+
i915_gem_request_get_seqno(obj-last_read_req[i]));
+ seq_printf(m, ] %x %x%s%s%s,
i915_gem_request_get_seqno(obj-last_write_req),
i915_gem_request_get_seqno(obj-last_fenced_req),
i915_cache_level_str(to_i915(obj-base.dev),
obj-cache_level),
@@ -169,9 +175,9 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
*t = '\0';
seq_printf(m, (%s mappable), s);
}
- if (obj-last_read_req != NULL)
+ if (obj-last_write_req != NULL)
seq_printf(m, (%s),
- i915_gem_request_get_ring(obj-last_read_req)-name);
+
i915_gem_request_get_ring(obj-last_write_req)-name);
if (obj-frontbuffer_bits)
seq_printf(m, (frontbuffer: 0x%03x), obj-frontbuffer_bits);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 896aae1c10ac..7cf5d1b0a749 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -500,7 +500,7 @@ struct drm_i915_error_state {
struct drm_i915_error_buffer {
u32 size;
Re: [Intel-gfx] R31 dithering
Am 30.03.2015 um 15:59 schrieb Ville Syrjälä: On Mon, Mar 30, 2015 at 03:54:29PM +0200, Thomas Richter wrote: Am 30.03.2015 um 13:55 schrieb Ville Syrjälä: On Fri, Mar 27, 2015 at 07:57:52PM +0100, Thomas Richter wrote: Thanks and have a nice weekend, BTW I think this bug is about failure to restore the ivch to proper state after suspend (on X30): https://bugs.freedesktop.org/show_bug.cgi?id=49838 Just in case you're looking for more stuff to do around the ivch ;) Well, no x30 around here unfortunately, though I can possibly check for helpers in a German Thinkpad forum. Maybe somebody with enough Linux-awareness can remote-debug and provide a couple of register listings to re-enable the DVO as required during wake-up. Or provides an x30. (-: I'll check and let you know. I was assuming your R31 or whatever would have the same problems. No, astonishingly, not. Suspend/resume and hibernate work fine. Well, somewhat... Actually, the R31 only supports S1 (standby) correctly and not S3 (suspend to RAM), even though ACPI (the DSDT) makes you believe that S3 would work. Problem is that the bios does not even enter the kernel anymore once you wake it up from S3 - it's completely dead then and the user mode entry point of the kernel is never reached. So the kernel can hardly do anything about this in first place I personally solved the problem by providing a custom DSDT which just disables S3, and it worked happily ever after... Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests: Add kms_legacy_colorkey
On 27 March 2015 at 19:18, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a quick test to make sure the legacy set colorkey ioctl only works
for sprite planes.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
lib/igt_kms.h | 4 +++
tests/.gitignore| 1 +
tests/Makefile.sources | 1 +
tests/kms_legacy_colorkey.c | 77
+
4 files changed, 83 insertions(+)
create mode 100644 tests/kms_legacy_colorkey.c
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 565df14..a2ba19e 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -262,6 +262,10 @@ void igt_wait_for_vblank(int drm_fd, enum pipe pipe);
#define for_each_pipe(display, pipe) \
for (pipe = 0; pipe igt_display_get_n_pipes(display); pipe++) \
Please add some API documentation here for the new macro.
+#define for_each_plane_on_pipe(display, pipe, plane) \
+ for (int i__ = 0; (plane) = (display)-pipes[(pipe)].planes[i__], \
+i__ (display)-pipes[(pipe)].n_planes; i__++)
+
/*
* Can be used with igt_output_set_pipe() to mean we don't care about the
pipe
* that should drive this output
diff --git a/tests/.gitignore b/tests/.gitignore
index 843db4a..981ebfe 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -131,6 +131,7 @@ kms_flip
kms_flip_event_leak
kms_flip_tiling
kms_force_connector
+kms_legacy_colorkey
kms_mmio_vs_cs_flip
kms_pipe_crc_basic
kms_plane
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 0a974a6..fbb617e 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -74,6 +74,7 @@ TESTS_progs_M = \
kms_flip_event_leak \
kms_flip_tiling \
kms_flip_event_leak \
+ kms_legacy_colorkey \
kms_mmio_vs_cs_flip \
kms_pipe_crc_basic \
kms_plane \
diff --git a/tests/kms_legacy_colorkey.c b/tests/kms_legacy_colorkey.c
new file mode 100644
index 000..c0725fe
--- /dev/null
+++ b/tests/kms_legacy_colorkey.c
@@ -0,0 +1,77 @@
+/*
+ * Copyright © 2015 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 the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER 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.
+ */
+
+#include errno.h
+
+#include drmtest.h
+#include igt_kms.h
+#include igt_aux.h
+
+IGT_TEST_DESCRIPTION(Check that the legacy set colorkey ioctl only works on
sprite planes.);
+
+static int drm_fd;
+static igt_display_t display;
+static int p;
+static igt_plane_t *plane;
+static uint32_t max_id;
+
+
+static void test_plane(uint32_t plane_id, int expected_ret)
+{
+ struct drm_intel_sprite_colorkey ckey = {
+ .plane_id = plane_id,
+ };
+
+ igt_assert(drmCommandWrite(drm_fd, DRM_I915_SET_SPRITE_COLORKEY,
ckey,
+ sizeof(ckey)) == expected_ret);
+}
+
+igt_simple_main
+{
+ igt_skip_on_simulation();
+
+ igt_fixture {
Since this is a simple test without subtests, using igt_fixture blocks
isn't necessary.
+ drm_fd = drm_open_any_master();
+
+ kmstest_set_vt_graphics_mode();
+
+ igt_display_init(display, drm_fd);
+ }
+
+ for_each_pipe(display, p) {
+ for_each_plane_on_pipe(display, p, plane) {
+ test_plane(plane-drm_plane-plane_id,
+ (plane-is_cursor || plane-is_primary) ?
-ENOENT : 0);
+
+ max_id = max(max_id, plane-drm_plane-plane_id);
+ }
+ }
+
+ /* try some invalid IDs too */
+ test_plane(0, -ENOENT);
+ test_plane(max_id + 1, -ENOENT);
+
+ igt_fixture {
+ igt_display_fini(display);
+ }
+}
--
2.0.5
___
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Support for 90/270 rotation
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6091 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -4 270/270 266/270 ILK 303/303 303/303 SNB -1 304/304 303/304 IVB 337/337 337/337 BYT 287/287 287/287 HSW 361/361 361/361 BDW 309/309 309/309 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt@gem_userptr_blits@coherency-sync CRASH(2)PASS(2) CRASH(2) *PNV igt@gem_fence_thrash@bo-write-verify-threaded-none PASS(2) FAIL(1)PASS(1) *PNV igt@gem_fence_thrash@bo-write-verify-x PASS(2) FAIL(1)PASS(1) *PNV igt@gem_fence_thrash@bo-write-verify-y PASS(2) FAIL(1)PASS(1) *SNB igt@kms_rotation_crc@sprite-rotation PASS(3) FAIL(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/atomic: Don't try to free a NULL state
Consistently with other free functions, handle the NULL case without
oopsing.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/drm_atomic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 23034e8..88b2790 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -179,6 +179,9 @@ EXPORT_SYMBOL(drm_atomic_state_clear);
*/
void drm_atomic_state_free(struct drm_atomic_state *state)
{
+ if (!state)
+ return;
+
drm_atomic_state_clear(state);
DRM_DEBUG_ATOMIC(Freeing atomic state %p\n, state);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] tests: Add test for pipe B and C interactions in IVB
The tests exercise different combinations of enabling pipe B with modes
that require more than 2 lanes and then enabling pipe C.
v2: Added a couple more tests for different pipe transitions. (Ander)
Use custom modes to make the test reliable. (Daniel)
v3: Add IGT_TEST_DESCRIPTION. (Thomas)
Rename test to kms_pipe_b_c_ivb. (Ander)
v4: Fix subtest enumeration. (Thomas)
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/kms_pipe_b_c_ivb.c | 289 +++
3 files changed, 291 insertions(+)
create mode 100644 tests/kms_pipe_b_c_ivb.c
diff --git a/tests/.gitignore b/tests/.gitignore
index 843db4a..1f0e2d1 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -132,6 +132,7 @@ kms_flip_event_leak
kms_flip_tiling
kms_force_connector
kms_mmio_vs_cs_flip
+kms_pipe_b_c_ivb
kms_pipe_crc_basic
kms_plane
kms_psr_sink_crc
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 0a974a6..93e05e4 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -75,6 +75,7 @@ TESTS_progs_M = \
kms_flip_tiling \
kms_flip_event_leak \
kms_mmio_vs_cs_flip \
+ kms_pipe_b_c_ivb \
kms_pipe_crc_basic \
kms_plane \
kms_psr_sink_crc \
diff --git a/tests/kms_pipe_b_c_ivb.c b/tests/kms_pipe_b_c_ivb.c
new file mode 100644
index 000..b6e234c
--- /dev/null
+++ b/tests/kms_pipe_b_c_ivb.c
@@ -0,0 +1,289 @@
+/*
+ * Copyright © 2015 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 the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER 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.
+ *
+ * Authors:
+ * Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
+ */
+
+#include drmtest.h
+#include igt_kms.h
+#include intel_chipset.h
+
+IGT_TEST_DESCRIPTION(
+Exercise the FDI lane bifurcation code for IVB in the kernel by setting
+different combinations of modes for pipes B and C.);
+
+typedef struct {
+ int drm_fd;
+ igt_display_t display;
+} data_t;
+
+drmModeModeInfo mode_3_lanes = {
+ .clock = 173000,
+ .hdisplay = 1920,
+ .hsync_start = 2048,
+ .hsync_end = 2248,
+ .htotal = 2576,
+ .vdisplay = 1080,
+ .vsync_start = 1083,
+ .vsync_end = 1088,
+ .vtotal = 1120,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC,
+ .name = 3_lanes,
+};
+
+drmModeModeInfo mode_2_lanes = {
+ .clock = 138500,
+ .hdisplay = 1920,
+ .hsync_start = 1968,
+ .hsync_end = 2000,
+ .htotal = 2080,
+ .vdisplay = 1080,
+ .vsync_start = 1083,
+ .vsync_end = 1088,
+ .vtotal = ,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .name = 2_lanes,
+};
+
+static int
+disable_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+ igt_plane_t *primary;
+
+ igt_output_set_pipe(output, pipe);
+ primary = igt_output_get_plane(output, 0);
+ igt_plane_set_fb(primary, NULL);
+ return igt_display_commit(data-display);
+}
+
+static int
+set_mode_on_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+ igt_plane_t *primary;
+ drmModeModeInfo *mode;
+ struct igt_fb fb;
+ int fb_id;
+
+ igt_output_set_pipe(output, pipe);
+
+ mode = igt_output_get_mode(output);
+
+ primary = igt_output_get_plane(output, 0);
+
+ fb_id = igt_create_color_fb(data-drm_fd,
+ mode-hdisplay, mode-vdisplay,
+ DRM_FORMAT_XRGB, I915_TILING_NONE,
+ 1.0, 1.0, 1.0, fb);
+ igt_assert(fb_id = 0);
+
+ igt_plane_set_fb(primary, fb);
+ return igt_display_try_commit2(data-display, COMMIT_LEGACY);
+}
+
+static int
+set_big_mode_on_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+ igt_output_override_mode(output, mode_3_lanes);
+ return
Re: [Intel-gfx] R31 dithering
On Fri, Mar 27, 2015 at 07:57:52PM +0100, Thomas Richter wrote: Hi Daniel, hi Ville, thanks for your help. I used now the debug output to research how to enable dithering on the intel VCH. Apparently, it is bit #4 in register VR01 that enables dithering. This is cross-checked by enabling in the dvo_ivch.c file, which greatly improves image quality for 24bpp output. The bit itself is documented as reserved in the intel documentation, though it works quite nicely here. I will now cross-check a little bit which other side effects this bit has if combined with other DVO features (16bpp output, and scaler enabled). As soon as I have more, I'll prepare a small kernel patch for it. Thanks and have a nice weekend, BTW I think this bug is about failure to restore the ivch to proper state after suspend (on X30): https://bugs.freedesktop.org/show_bug.cgi?id=49838 Just in case you're looking for more stuff to do around the ivch ;) -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Copy the staged connector config to the legacy atomic state
This is a typical one err bug which is a kind of bug where there is just one err: label which does all the error handling. One err bugs are one of the most common class of bugs in the kernel. Oh, we didn't initialize that struct member or That pointer is NULL. In networking they have resisted patches to add sanity checks to free_netdev() so that people can't do one err style error handling. You always have to know if the dev is allocated or not. Having one error label makes sense if the label is unlock: but labels like fail:, err:, out:, or bail are not very good label names. The disadvantage of having multiple returns is that it means you can't have a debug statement, but debug statements are mostly a waste of RAM and we can use ftrace for that. regards, dan carpenter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 38/49] drm/i915: Skip allocating shadow batch for 0-length batches
On Fri, Mar 27, 2015 at 11:02:10AM +, Chris Wilson wrote: Since commit 17cabf571e50677d980e9ab2a43c5f11213003ae Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Jan 14 11:20:57 2015 + drm/i915: Trim the command parser allocations we may then try to allocate a zero-sized object and attempt to extract its pages. Understandably this fails. The original failure was in committ b9ffd80ed659c559152c042e74741f4f60cac691 Author: Brad Volkin bradley.d.vol...@intel.com Date: Thu Dec 11 12:13:10 2014 -0800 drm/i915: Use batch length instead of object size in command parser merged in the v4.0 cycle. Jani, pretty please? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] lib: add debug flags
Signed-off-by: Thomas Wood thomas.w...@intel.com --- lib/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Makefile.am b/lib/Makefile.am index 4db90d4..870b1a1 100644 --- a/lib/Makefile.am +++ b/lib/Makefile.am @@ -9,7 +9,7 @@ noinst_LTLIBRARIES = libintel_tools.la noinst_HEADERS = check-ndebug.h AM_CPPFLAGS = -I$(top_srcdir) -AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(LIBUNWIND_CFLAGS) \ +AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(LIBUNWIND_CFLAGS) $(DEBUG_CFLAGS) \ -DIGT_DATADIR=\$(abs_top_srcdir)/tests\ \ -DIGT_LOG_DOMAIN=\$(subst _,-,$*)\ \ -pthread -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] gem_exec_blt: fix subtest enumeration
Wrap the sysfs_read and sysfs_write calls in an igt_fixture block so
they are not executed during subtest enumeration.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
tests/gem_exec_blt.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tests/gem_exec_blt.c b/tests/gem_exec_blt.c
index 8f03b20..820478c 100644
--- a/tests/gem_exec_blt.c
+++ b/tests/gem_exec_blt.c
@@ -384,8 +384,10 @@ int main(int argc, char **argv)
return 0;
}
- min = sysfs_read(gt_min_freq_mhz);
- max = sysfs_read(gt_max_freq_mhz);
+ igt_fixture {
+ min = sysfs_read(gt_min_freq_mhz);
+ max = sysfs_read(gt_max_freq_mhz);
+ }
for (r = rps; r-suffix; r++) {
igt_fixture r-func();
@@ -400,10 +402,12 @@ int main(int argc, char **argv)
run(OBJECT_SIZE, true);
}
- if (min 0)
- sysfs_write(gt_min_freq_mhz, min);
- if (max 0)
- sysfs_write(gt_max_freq_mhz, max);
+ igt_fixture {
+ if (min 0)
+ sysfs_write(gt_min_freq_mhz, min);
+ if (max 0)
+ sysfs_write(gt_max_freq_mhz, max);
+ }
igt_exit();
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Copy the staged connector config to the legacy atomic state
On Mon, 2015-03-30 at 13:50 +0300, David Weinehall wrote:
On Fri, Mar 27, 2015 at 05:36:40PM +0300, Dan Carpenter wrote:
Hello Ander Conselvan de Oliveira,
This is a semi-automatic email about new static checker warnings.
The patch 944b0c765757: drm/i915: Copy the staged connector config
to the legacy atomic state from Mar 20, 2015, leads to the following
Smatch complaint:
drivers/gpu/drm/i915/intel_display.c:9118 intel_release_load_detect_pipe()
error: we previously assumed 'state' could be null (see line 9082)
drivers/gpu/drm/i915/intel_display.c
9081 state = drm_atomic_state_alloc(dev);
9082 if (!state)
9083 goto fail;
^
Patch changes a return into a goto.
9084
9085 state-acquire_ctx = ctx;
9086
9087 connector_state =
drm_atomic_get_connector_state(state, connector);
9088 if (IS_ERR(connector_state))
9089 goto fail;
9090
9091 to_intel_connector(connector)-new_encoder =
NULL;
9092 intel_encoder-new_crtc = NULL;
9093 intel_crtc-new_enabled = false;
9094 intel_crtc-new_config = NULL;
9095
9096 connector_state-best_encoder = NULL;
9097 connector_state-crtc = NULL;
9098
9099 intel_set_mode(crtc, NULL, 0, 0, NULL, state);
9100
9101 drm_atomic_state_free(state);
9102
9103 if (old-release_fb) {
9104
drm_framebuffer_unregister_private(old-release_fb);
9105
drm_framebuffer_unreference(old-release_fb);
9106 }
9107
9108 return;
9109 }
9110
9111 /* Switch crtc and encoder back off if necessary */
9112 if (old-dpms_mode != DRM_MODE_DPMS_ON)
9113 connector-funcs-dpms(connector,
old-dpms_mode);
9114
9115 return;
9116 fail:
9117 DRM_DEBUG_KMS(Couldn't release load detect pipe.\n);
9118 drm_atomic_state_free(state);
^
Dereferenced inside function call.
9119 }
9120
Wouldn't it make more sense to make drm_atomic_state_free() follow
the same semantics as *free() functions typically do
(no operation performed)?
It would. I already signed up to send that patch, even. Just didn't get
around to yet.
Ander
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync
On 3/26/2015 5:09 PM, R, Durgadoss wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Sonika Jindal
Sent: Thursday, March 26, 2015 1:57 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH] drm/i915/skl: Enabling PSR2 SU with frame sync
We make use of HW tracking for Selective update region and enable frame sync on
sink. We use hardware's hardcoded data values for frame sync and GTC.
v2: Add 3200x2000 resolution restriction with PSR2, move psr2_support to
i915_psr
struct, add aux_frame_sync to independently control aux frame sync, rename the
TP2 TIME macro for 2500us (Rodrigo, Siva)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_reg.h | 14 ++
drivers/gpu/drm/i915/intel_dp.c | 15 +++
drivers/gpu/drm/i915/intel_psr.c | 34 +-
4 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eb38cd1..65d3dae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -879,6 +879,8 @@ struct i915_psr {
struct delayed_work work;
unsigned busy_frontbuffer_bits;
bool link_standby;
+ bool psr2_support;
+ bool aux_frame_sync;
};
enum intel_pch {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5b84ee6..0b42ef3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2745,6 +2745,20 @@ enum skl_disp_power_wells {
#define EDP_PSR_DEBUG_MASK_MEMUP (126)
#define EDP_PSR_DEBUG_MASK_HPD(125)
+#define EDP_PSR2_CTL 0x6f900
+#define EDP_PSR2_ENABLE (131)
+#define EDP_SU_TRACK_ENABLE (130)
+#define EDP_MAX_SU_DISABLE_TIME(t) ((t)20)
+#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f20)
+#define EDP_PSR2_TP2_TIME_500(08)
+#define EDP_PSR2_TP2_TIME_100(18)
+#define EDP_PSR2_TP2_TIME_2500 (28)
+#define EDP_PSR2_TP2_TIME_50 (38)
+#define EDP_PSR2_TP2_TIME_MASK (38)
+#define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
+#define EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf4)
+#define EDP_PSR2_IDLE_MASK 0xf
+
/* VGA port control */
#define ADPA0x61100
#define PCH_ADPA0xe1100
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3967af1..b0ae45e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3786,6 +3786,21 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
dev_priv-psr.sink_support = true;
DRM_DEBUG_KMS(Detected EDP PSR Panel.\n);
}
+
+ if (INTEL_INFO(dev)-gen = 9
+ (intel_dp-psr_dpcd[0] DP_PSR2_IS_SUPPORTED)) {
+ uint8_t frame_sync_cap;
+
+ dev_priv-psr.sink_support = true;
+ intel_dp_dpcd_read_wake(intel_dp-aux,
+ DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+ frame_sync_cap, 1);
+ dev_priv-psr.aux_frame_sync = frame_sync_cap ? true :
false;
+ /* PSR2 needs frame sync as well */
+ dev_priv-psr.psr2_support =
dev_priv-psr.aux_frame_sync;
+ DRM_DEBUG_KMS(PSR2 %s on sink,
+ dev_priv-psr.psr2_support ? supported : not
supported);
+ }
}
/* Training Pattern 3 support, both source and sink */
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b9f40c2..d52623d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -117,6 +117,19 @@ static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
I915_WRITE(VLV_VSCSDP(pipe), val);
}
+static void skl_psr_setup_su_vsc(struct intel_dp *intel_dp)
+{
+ struct edp_vsc_psr psr_vsc;
+
+ /* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
+ memset(psr_vsc, 0, sizeof(psr_vsc));
+ psr_vsc.sdp_header.HB0 = 0;
+ psr_vsc.sdp_header.HB1 = 0x7;
+ psr_vsc.sdp_header.HB2 = 0x3;
+ psr_vsc.sdp_header.HB3 = 0xb;
+ intel_psr_write_vsc(intel_dp, psr_vsc);
+}
+
static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
{
struct edp_vsc_psr psr_vsc;
@@ -165,6 +178,12 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
DP_PSR_ENABLE ~DP_PSR_MAIN_LINK_ACTIVE);
+ /* Enable AUX frame sync at sink */
+ if (dev_priv-psr.aux_frame_sync)
+ drm_dp_dpcd_writeb(intel_dp-aux,
+
[Intel-gfx] [PATCH 33/49] drm/i915/bxt: Add DC9 Trigger sequence
+static int bxt_suspend_complete(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+
+ /* TODO: when DC5 support is added disable DC5 here. */
+
+ bxt_uninit_cdclk(dev);
+ bxt_enable_dc9(dev_priv);
+
+ return 0;
+}
+
static int hsw_suspend_complete(struct drm_i915_private *dev_priv)
{
hsw_enable_pc8(dev_priv);
@@ -1009,6 +1021,20 @@ static int hsw_suspend_complete(struct
drm_i915_private *dev_priv)
return 0;
}
+static int bxt_resume_prepare(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+
+ /* TODO: When CSR FW support is added make sure the FW is loaded. */
+
+ bxt_disable_dc9(dev_priv);
Kindly add below comment as well:
/* TODO: when DC5 support is added enable DC5 here if conditions are
met. */
+ bxt_init_cdclk(dev);
+ bxt_ddi_phy_init(dev);
+ intel_prepare_ddi(dev);
+
+ return 0;
+}
+
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: Copy the staged connector config to the legacy atomic state
On Fri, Mar 27, 2015 at 05:36:40PM +0300, Dan Carpenter wrote:
Hello Ander Conselvan de Oliveira,
This is a semi-automatic email about new static checker warnings.
The patch 944b0c765757: drm/i915: Copy the staged connector config
to the legacy atomic state from Mar 20, 2015, leads to the following
Smatch complaint:
drivers/gpu/drm/i915/intel_display.c:9118 intel_release_load_detect_pipe()
error: we previously assumed 'state' could be null (see line 9082)
drivers/gpu/drm/i915/intel_display.c
9081state = drm_atomic_state_alloc(dev);
9082if (!state)
9083goto fail;
^
Patch changes a return into a goto.
9084
9085state-acquire_ctx = ctx;
9086
9087connector_state =
drm_atomic_get_connector_state(state, connector);
9088if (IS_ERR(connector_state))
9089goto fail;
9090
9091to_intel_connector(connector)-new_encoder =
NULL;
9092intel_encoder-new_crtc = NULL;
9093intel_crtc-new_enabled = false;
9094intel_crtc-new_config = NULL;
9095
9096connector_state-best_encoder = NULL;
9097connector_state-crtc = NULL;
9098
9099intel_set_mode(crtc, NULL, 0, 0, NULL, state);
9100
9101drm_atomic_state_free(state);
9102
9103if (old-release_fb) {
9104
drm_framebuffer_unregister_private(old-release_fb);
9105
drm_framebuffer_unreference(old-release_fb);
9106}
9107
9108return;
9109}
9110
9111/* Switch crtc and encoder back off if necessary */
9112if (old-dpms_mode != DRM_MODE_DPMS_ON)
9113connector-funcs-dpms(connector,
old-dpms_mode);
9114
9115return;
9116fail:
9117DRM_DEBUG_KMS(Couldn't release load detect pipe.\n);
9118drm_atomic_state_free(state);
^
Dereferenced inside function call.
9119}
9120
Wouldn't it make more sense to make drm_atomic_state_free() follow
the same semantics as *free() functions typically do
(no operation performed)?
Kind regards, David Weinehall
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/2] tests: Add test for pipe B and C interactions in IVB
On 30 March 2015 at 08:03, Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com wrote:
The tests exercise different combinations of enabling pipe B with modes
that require more than 2 lanes and then enabling pipe C.
v2: Added a couple more tests for different pipe transitions. (Ander)
Use custom modes to make the test reliable. (Daniel)
v3: Add IGT_TEST_DESCRIPTION. (Thomas)
Add test to .gitignore. (Thomas)
Rename test to kms_pipe_b_c_ivb. (Ander)
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/kms_pipe_b_c_ivb.c | 290
+++
3 files changed, 292 insertions(+)
create mode 100644 tests/kms_pipe_b_c_ivb.c
diff --git a/tests/.gitignore b/tests/.gitignore
index 843db4a..1f0e2d1 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -132,6 +132,7 @@ kms_flip_event_leak
kms_flip_tiling
kms_force_connector
kms_mmio_vs_cs_flip
+kms_pipe_b_c_ivb
kms_pipe_crc_basic
kms_plane
kms_psr_sink_crc
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 0a974a6..93e05e4 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -75,6 +75,7 @@ TESTS_progs_M = \
kms_flip_tiling \
kms_flip_event_leak \
kms_mmio_vs_cs_flip \
+ kms_pipe_b_c_ivb \
kms_pipe_crc_basic \
kms_plane \
kms_psr_sink_crc \
diff --git a/tests/kms_pipe_b_c_ivb.c b/tests/kms_pipe_b_c_ivb.c
new file mode 100644
index 000..74d84f1
--- /dev/null
+++ b/tests/kms_pipe_b_c_ivb.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright © 2015 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 the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER 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.
+ *
+ * Authors:
+ * Ander Conselvan de Oliveira ander.conselvan.de.olive...@intel.com
+ */
+
+#include drmtest.h
+#include igt_kms.h
+#include intel_chipset.h
+
+IGT_TEST_DESCRIPTION(
+Exercise the FDI lane bifurcation code for IVB in the kernel by setting
+different combinations of modes for pipes B and C.);
+
+typedef struct {
+ int drm_fd;
+ igt_display_t display;
+} data_t;
+
+drmModeModeInfo mode_3_lanes = {
+ .clock = 173000,
+ .hdisplay = 1920,
+ .hsync_start = 2048,
+ .hsync_end = 2248,
+ .htotal = 2576,
+ .vdisplay = 1080,
+ .vsync_start = 1083,
+ .vsync_end = 1088,
+ .vtotal = 1120,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC,
+ .name = 3_lanes,
+};
+
+drmModeModeInfo mode_2_lanes = {
+ .clock = 138500,
+ .hdisplay = 1920,
+ .hsync_start = 1968,
+ .hsync_end = 2000,
+ .htotal = 2080,
+ .vdisplay = 1080,
+ .vsync_start = 1083,
+ .vsync_end = 1088,
+ .vtotal = ,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,
+ .name = 2_lanes,
+};
+
+static int
+disable_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+ igt_plane_t *primary;
+
+ igt_output_set_pipe(output, pipe);
+ primary = igt_output_get_plane(output, 0);
+ igt_plane_set_fb(primary, NULL);
+ return igt_display_commit(data-display);
+}
+
+static int
+set_mode_on_pipe(data_t *data, enum pipe pipe, igt_output_t *output)
+{
+ igt_plane_t *primary;
+ drmModeModeInfo *mode;
+ struct igt_fb fb;
+ int fb_id;
+
+ igt_output_set_pipe(output, pipe);
+
+ mode = igt_output_get_mode(output);
+
+ primary = igt_output_get_plane(output, 0);
+
+ fb_id = igt_create_color_fb(data-drm_fd,
+ mode-hdisplay, mode-vdisplay,
+ DRM_FORMAT_XRGB, I915_TILING_NONE,
+ 1.0, 1.0, 1.0, fb);
+ igt_assert(fb_id = 0);
+
+ igt_plane_set_fb(primary, fb);
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off
On Monday 30 March 2015 03:37 PM, Ville Syrjälä wrote:
On Sat, Mar 28, 2015 at 03:23:34PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Signed-off-by: Deepak S deepa...@linux.intel.com
Yeah seems OK. We still do the allow wake dance even though we skip
the gunit register save, so I guess the force gfx clock makes sense as
part of that.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Thanks Ville for reviewing.
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 82f8be4..182d6a7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,11 +1194,13 @@ int vlv_force_gfx_clock(struct drm_i915_private
*dev_priv, bool force_on)
int err;
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
- WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG) VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force-off to settle */
- if (force_on) {
+ if (force_on !IS_CHERRYVIEW(dev_priv-dev)) {
+ /* WARN_ON only for the Valleyview */
+ WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off
(%08x)\n,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Clean-up idr table if context create fails.
From: Deepak S deepa...@linux.intel.com Cleanup idr table if any error happens after __create_hw_context() in i915_gem_create_context() Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/i915_gem_context.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index f3e84c4..69bebe5 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -287,6 +287,8 @@ err_unpin: if (is_global_default_ctx ctx-legacy_hw_ctx.rcs_state) i915_gem_object_ggtt_unpin(ctx-legacy_hw_ctx.rcs_state); err_destroy: + if (ctx-file_priv) + idr_remove(ctx-file_priv-context_idr, ctx-user_handle); i915_gem_context_unreference(ctx); return ERR_PTR(ret); } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 38/49] drm/i915: Skip allocating shadow batch for 0-length batches
On Mon, Mar 30, 2015 at 01:02:50PM +0100, Chris Wilson wrote: On Fri, Mar 27, 2015 at 11:02:10AM +, Chris Wilson wrote: Since commit 17cabf571e50677d980e9ab2a43c5f11213003ae Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Jan 14 11:20:57 2015 + drm/i915: Trim the command parser allocations we may then try to allocate a zero-sized object and attempt to extract its pages. Understandably this fails. The original failure was in committ b9ffd80ed659c559152c042e74741f4f60cac691 Author: Brad Volkin bradley.d.vol...@intel.com Date: Thu Dec 11 12:13:10 2014 -0800 drm/i915: Use batch length instead of object size in command parser merged in the v4.0 cycle. Jani, pretty please? Cherry-picked and added the real sha1 citation, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/49] drm/i915: Implement inter-engine read-read optimisations
On Mon, Mar 30, 2015 at 03:45:04PM +0100, Tvrtko Ursulin wrote:
On 03/30/2015 03:09 PM, Chris Wilson wrote:
On Mon, Mar 30, 2015 at 02:52:26PM +0100, Tvrtko Ursulin wrote:
+static void
+__i915_gem_request_retire__upto(struct drm_i915_gem_request *rq)
It is a bit annoying (for readability) that it can be rq, req and request.
Nonsense they are all rq and struct i915_request. Or once have been and
so will again. /prophecy
rq is least spread in the codebase, and even the worst option of the
three since it sounds like a queue of some sort.
It's much clearer than req, matches equivalent implementations in
userspace ;-) rq is the local variable, and request the verbose version
for structure memers.
+err:
+ for (i = 0; i n; i++) {
+ if (ret == 0) {
+ int ring = requests[i]-ring-id;
+ if (obj-last_read_req[ring] == requests[i])
+ i915_gem_object_retire__read(obj, ring);
+ if (obj-last_write_req == requests[i])
+ i915_gem_object_retire__write(obj);
Above four lines seem to be identical functionality to similar four
in __i915_gem_object_sync.
Yes. Extracting them ended up looking worse (imo).
It would be a single function call taking object and request, how
can it be worse? Should be more readable with a good name.
I wanted i915_gem_object_retire_request. However, done.
Also, _retire__read will do _retire__write if there is one on the
same ring. And here by definition they are since it is the same
request, no?
No. It's subtle but here is the bug I pointed out from before. Once we
drop the lock, we no longer can make assumptions about the state of obj.
You mean request might have disappeared from last_read_req but is
still on last_write_req? But how, since if it was retired that
shouldn't be possible.
Just that last_write_req != last_read_req either before or after the
wait (and doubly so after the wait, which is where we had the previous
bug).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/49] drm/i915: Implement inter-engine read-read optimisations
On 03/30/2015 03:09 PM, Chris Wilson wrote:
On Mon, Mar 30, 2015 at 02:52:26PM +0100, Tvrtko Ursulin wrote:
+static void
+__i915_gem_request_retire__upto(struct drm_i915_gem_request *rq)
It is a bit annoying (for readability) that it can be rq, req and request.
Nonsense they are all rq and struct i915_request. Or once have been and
so will again. /prophecy
rq is least spread in the codebase, and even the worst option of the
three since it sounds like a queue of some sort.
+err:
+ for (i = 0; i n; i++) {
+ if (ret == 0) {
+ int ring = requests[i]-ring-id;
+ if (obj-last_read_req[ring] == requests[i])
+ i915_gem_object_retire__read(obj, ring);
+ if (obj-last_write_req == requests[i])
+ i915_gem_object_retire__write(obj);
Above four lines seem to be identical functionality to similar four
in __i915_gem_object_sync.
Yes. Extracting them ended up looking worse (imo).
It would be a single function call taking object and request, how can it
be worse? Should be more readable with a good name.
Also, _retire__read will do _retire__write if there is one on the
same ring. And here by definition they are since it is the same
request, no?
No. It's subtle but here is the bug I pointed out from before. Once we
drop the lock, we no longer can make assumptions about the state of obj.
You mean request might have disappeared from last_read_req but is still
on last_write_req? But how, since if it was retired that shouldn't be
possible.
@@ -2698,16 +2747,13 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
if (!i915_gem_request_completed(request, true))
break;
- trace_i915_gem_request_retire(request);
-
/* We know the GPU must have read the request to have
* sent us the seqno + interrupt, so use the position
* of tail of the request to update the last known position
* of the GPU head.
*/
request-ringbuf-last_retired_head = request-postfix;
-
- i915_gem_free_request(request);
+ i915_gem_request_retire(request);
}
This loop could also use __i915_gem_request_retire__upto if it found
the first completed request first. Not sure how much code would that
save but would maube be more readable, a little bit more self
documenting.
Actually this loop here should be pushed back to the engine (as part of
later patches). After that transformation, using i915_gem_request_retire()
is even clearer. But _retire__upto does become the main way in which we
retire requests (having killed off retire_requests_ring in favour of
explict wait/poll+retire).
That sounds good.
So far it all looks reasonable to me, but apart from the comments
above, I want to do another pass anyway.
There's a few more changes afoot as well (minor ones concerning
retire__upto and unexporting retire_requests_rig).
Ok.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Don't try to free a NULL state
On Mon, Mar 30, 2015 at 02:35:33PM +0300, David Weinehall wrote:
On Mon, Mar 30, 2015 at 02:05:43PM +0300, Ander Conselvan de Oliveira wrote:
Consistently with other free functions, handle the NULL case without
oopsing.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/drm_atomic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 23034e8..88b2790 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -179,6 +179,9 @@ EXPORT_SYMBOL(drm_atomic_state_clear);
*/
void drm_atomic_state_free(struct drm_atomic_state *state)
{
+ if (!state)
+ return;
+
drm_atomic_state_clear(state);
DRM_DEBUG_ATOMIC(Freeing atomic state %p\n, state);
It'd probably make sense to fix all code that uses
drm_atomic_state_free() at the same time.
Imo we can do that as follow-ups as needed. Applied to topic/drm-misc,
thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only enabled DRRS if PRS won't be enabled on this pipe.
On Mon, Mar 30, 2015 at 03:19:29PM +0530, Ramalingam C wrote:
Looks good to me..
Reviewed-by: Ramalingam C ramalinga...@intel.com
On Friday 27 March 2015 12:51 AM, Rodrigo Vivi wrote:
With PSR enabled being pre computed on pipe_config we can now
prevent DRRS to be enabled along with PSR.
v2: Rebase after changing previous patch
Cc: Ramalingam C ramalinga...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Both patches applied, thanks.
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index e6b1c42..5551b3c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4994,11 +4994,6 @@ static void intel_dp_set_drrs_state(struct drm_device
*dev, int refresh_rate)
return;
}
-/*
- * FIXME: This needs proper synchronization with psr state for some
- * platforms that cannot have PSR and DRRS enabled at the same time.
- */
-
dig_port = dp_to_dig_port(intel_dp);
encoder = dig_port-base;
intel_crtc = encoder-new_crtc;
@@ -5084,6 +5079,11 @@ void intel_edp_drrs_enable(struct intel_dp *intel_dp)
return;
}
+if (intel_crtc-config-psr_ready) {
+DRM_DEBUG_KMS(DRRS: PSR will be enabled on this crtc\n);
+return;
+}
+
mutex_lock(dev_priv-drrs.mutex);
if (WARN_ON(dev_priv-drrs.dp)) {
DRM_ERROR(DRRS already enabled\n);
--
Thanks,
--Ram
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/chv: Remove Wait for a previous gfx force-off
On Mon, Mar 30, 2015 at 01:07:21PM +0300, Ville Syrjälä wrote:
On Sat, Mar 28, 2015 at 03:23:34PM +0530, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Signed-off-by: Deepak S deepa...@linux.intel.com
Yeah seems OK. We still do the allow wake dance even though we skip
the gunit register save, so I guess the force gfx clock makes sense as
part of that.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 82f8be4..182d6a7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,11 +1194,13 @@ int vlv_force_gfx_clock(struct drm_i915_private
*dev_priv, bool force_on)
int err;
val = I915_READ(VLV_GTLC_SURVIVABILITY_REG);
- WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
#define COND (I915_READ(VLV_GTLC_SURVIVABILITY_REG)
VLV_GFX_CLK_STATUS_BIT)
/* Wait for a previous force-off to settle */
- if (force_on) {
+ if (force_on !IS_CHERRYVIEW(dev_priv-dev)) {
+ /* WARN_ON only for the Valleyview */
+ WARN_ON(!!(val VLV_GFX_CLK_FORCE_ON_BIT) == force_on);
+
err = wait_for(!COND, 20);
if (err) {
DRM_ERROR(timeout waiting for GFX clock force-off
(%08x)\n,
--
1.9.1
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clean-up idr table if context create fails.
On Mon, Mar 30, 2015 at 08:03:58PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com Cleanup idr table if any error happens after __create_hw_context() in i915_gem_create_context() Signed-off-by: Deepak S deepa...@linux.intel.com --- drivers/gpu/drm/i915/i915_gem_context.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index f3e84c4..69bebe5 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -287,6 +287,8 @@ err_unpin: if (is_global_default_ctx ctx-legacy_hw_ctx.rcs_state) i915_gem_object_ggtt_unpin(ctx-legacy_hw_ctx.rcs_state); err_destroy: + if (ctx-file_priv) + idr_remove(ctx-file_priv-context_idr, ctx-user_handle); The common approach is to add a new err_idr: label at the op of the unwind code and make the call to idr_remove unconditional. Thanks, Daniel i915_gem_context_unreference(ctx); return ERR_PTR(ret); } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://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 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] tests: apply igt.cocci
Signed-off-by: Thomas Wood thomas.w...@intel.com
---
tests/core_getclient.c | 2 +-
tests/core_getstats.c | 2 +-
tests/drm_import_export.c | 2 --
tests/eviction_common.c| 7 ---
tests/gem_close_race.c | 2 +-
tests/gem_cs_prefetch.c| 2 +-
tests/gem_ctx_bad_exec.c | 8
tests/gem_ctx_create.c | 4 ++--
tests/gem_ctx_exec.c | 12 +++-
tests/gem_exec_bad_domains.c | 14 +++---
tests/gem_fence_thrash.c | 38 +-
tests/gem_fenced_exec_thrash.c | 4 ++--
tests/gem_mmap.c | 4 ++--
tests/gem_readwrite.c | 12 ++--
tests/gem_threaded_access_tiled.c | 1 -
tests/gem_unfence_active_buffers.c | 2 +-
tests/gem_userptr_blits.c | 1 -
tests/gem_workarounds.c| 8
tests/kms_3d.c | 8
tests/kms_flip.c | 29 +
tests/pm_rc6_residency.c | 8
tests/pm_rps.c | 4 ++--
tests/prime_nv_test.c | 2 +-
tests/prime_udl.c | 6 +++---
24 files changed, 99 insertions(+), 83 deletions(-)
diff --git a/tests/core_getclient.c b/tests/core_getclient.c
index 7598e0f..986fed1 100644
--- a/tests/core_getclient.c
+++ b/tests/core_getclient.c
@@ -47,7 +47,7 @@ igt_simple_main
*/
client.idx = 0;
ret = ioctl(fd, DRM_IOCTL_GET_CLIENT, client);
- igt_assert(ret == 0);
+ igt_assert_eq(ret, 0);
/* Look for some absurd client index and make sure it's invalid.
* The DRM drivers currently always return data, so the user has
diff --git a/tests/core_getstats.c b/tests/core_getstats.c
index 52a2d20..4c33457 100644
--- a/tests/core_getstats.c
+++ b/tests/core_getstats.c
@@ -51,7 +51,7 @@ igt_simple_main
fd = drm_open_any();
ret = ioctl(fd, DRM_IOCTL_GET_STATS, stats);
- igt_assert(ret == 0);
+ igt_assert_eq(ret, 0);
close(fd);
}
diff --git a/tests/drm_import_export.c b/tests/drm_import_export.c
index 57b13dd..8f61d55 100644
--- a/tests/drm_import_export.c
+++ b/tests/drm_import_export.c
@@ -139,14 +139,12 @@ pthread_t test_thread_id4;
igt_main {
igt_fixture {
fd1 = drm_open_any();
- igt_assert(fd1 = 0);
bufmgr1 = drm_intel_bufmgr_gem_init(fd1, 8 *1024);
igt_assert(bufmgr1);
drm_intel_bufmgr_gem_enable_reuse(bufmgr1);
fd = drm_open_any();
- igt_assert(fd = 0);
bufmgr = drm_intel_bufmgr_gem_init(fd, 8 *1024);
igt_assert(bufmgr);
diff --git a/tests/eviction_common.c b/tests/eviction_common.c
index 4fa5c04..9e06cbb 100644
--- a/tests/eviction_common.c
+++ b/tests/eviction_common.c
@@ -200,18 +200,19 @@ static void mlocked_evictions(int fd, struct
igt_eviction_test_ops *ops,
ops-close(fd, bo[n]);
out:
- write(result[1], ret, sizeof(ret));
+ igt_assert_eq(write(result[1], ret, sizeof(ret)),
+ sizeof(ret));
}
igt_waitchildren();
fcntl(result[0], F_SETFL, fcntl(result[0], F_GETFL) | O_NONBLOCK);
- read(result[0], ret, sizeof(ret));
+ igt_assert_eq(read(result[0], ret, sizeof(ret)), sizeof(ret));
close(result[0]);
close(result[1]);
errno = ret;
- igt_assert(ret == 0);
+ igt_assert_eq(ret, 0);
}
static int swapping_evictions(int fd, struct igt_eviction_test_ops *ops,
diff --git a/tests/gem_close_race.c b/tests/gem_close_race.c
index f89b3b6..d03fdcf 100644
--- a/tests/gem_close_race.c
+++ b/tests/gem_close_race.c
@@ -232,7 +232,7 @@ igt_main
sprintf(device, /dev/dri/card%d, drm_get_card());
fd = open(device, O_RDWR);
- igt_assert(fd != -1);
+ igt_assert_neq(fd, -1);
devid = intel_get_drm_devid(fd);
has_64bit_relocations = intel_gen(devid) = 8;
close(fd);
diff --git a/tests/gem_cs_prefetch.c b/tests/gem_cs_prefetch.c
index ac3da6d..a051540 100644
--- a/tests/gem_cs_prefetch.c
+++ b/tests/gem_cs_prefetch.c
@@ -109,7 +109,7 @@ igt_simple_main
igt_assert(sample_batch_bo);
ret = drm_intel_bo_subdata(sample_batch_bo, 4096-sizeof(batch_end),
sizeof(batch_end), batch_end);
- igt_assert(ret == 0);
+ igt_assert_eq(ret, 0);
/* fill the entire gart with batches and run them */
for (i = 0; i count; i++) {
diff --git a/tests/gem_ctx_bad_exec.c b/tests/gem_ctx_bad_exec.c
index 36afd7d..89d26c1 100644
--- a/tests/gem_ctx_bad_exec.c
+++ b/tests/gem_ctx_bad_exec.c
@@ -102,15 +102,15 @@ igt_main
}
igt_subtest(render)
-
[Intel-gfx] [PATCH i-g-t 1/2] lib: add some defines to help spatch parsing
Add simple definitions for various macros to help spatch parse the special igt control flow blocks and other macros correctly. Signed-off-by: Thomas Wood thomas.w...@intel.com --- lib/igt-spatch.h | 41 + lib/igt.cocci| 6 +++--- 2 files changed, 44 insertions(+), 3 deletions(-) create mode 100644 lib/igt-spatch.h diff --git a/lib/igt-spatch.h b/lib/igt-spatch.h new file mode 100644 index 000..f9d53ea --- /dev/null +++ b/lib/igt-spatch.h @@ -0,0 +1,41 @@ +/* + * Copyright © 2015 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 the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER 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. + * + */ + +/* various macros to help spatch parsing */ + +#error This header should only be used with spatch + +/* define igt control flow blocks as ordinary code blocks */ +#define igt_fixture +#define igt_subtest(name) +#define igt_subtest_f(f...) +#define igt_fork(child, num_children) +#define igt_fork_helper(proc) + +#define igt_main int main(int argc, char *argv) +#define igt_simple_main int main(int argc, char *argv) + +/* the third parameter of timercmp is an operator, so needs to be defined as a + * macro to be parsed correctly */ +#define timercmp(a, b, CMP) (1) diff --git a/lib/igt.cocci b/lib/igt.cocci index 156f0cf..e7bef8d 100644 --- a/lib/igt.cocci +++ b/lib/igt.cocci @@ -1,7 +1,7 @@ -// Semantic patch for common patters and their replacement by igt infrastructure -// and macros. Please run with +// Semantic patch for common patterns and their replacement by igt +// infrastructure and macros. Please run with // -// spatch --sp-file lib/igt.cocci --in-place tests/*.c +// spatch --sp-file lib/igt.cocci --macro-file lib/igt-spatch.h --in-place tests/*.c // // on your new testcase. -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clean-up idr table if context create fails.
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6093 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -3 270/270 267/270 ILK 303/303 303/303 SNB 304/304 304/304 IVB 337/337 337/337 BYT 287/287 287/287 HSW 361/361 361/361 BDW 309/309 309/309 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt@gem_userptr_blits@coherency-sync CRASH(4)PASS(2) CRASH(2) *PNV igt@gem_pwrite_pread@snooped-pwrite-blt-cpu_mmap-correctness PASS(2) CRASH(1)PASS(1) PNV igt@gem_tiled_pread_pwrite FAIL(1)PASS(3) FAIL(2) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/18] drm/i915: Defer default hardware context initialisation until first open
On 03/27/2015 01:45 AM, Daniel Vetter wrote: On Thu, Mar 26, 2015 at 12:41:13PM -0700, yu@intel.com wrote: From: Dave Gordon david.s.gor...@intel.com In order to fully initialise the default contexts, we have to execute batchbuffer commands on the GPU engines. But we can't do that until any required firmware has been loaded, which may not be possible during driver load, because the filesystem(s) containing the firmware may not be mounted until later. Therefore, we now allow the first call to the firmware-loading code to return -EAGAIN to indicate that it's not yet ready, and that it should be retried when the device is first opened from user code, by which time we expect that all required filesystems will have been mounted. The late-retry code will then re-attempt to load the firmware if the early attempt failed. We've tried a similar approach a while back and it doesn't work well in conjunction with rps - the hw tends to fall over if the context state isn't properly initialized when going into rc6. I believe patch 18/18 of this series is to notify GuC when RC6 is on and off. I don't know much details of implementation inside firmware, but I believe GuC will take care of it properly. Why exactly can't we load that firmware right at boot-up, or at least stall correctly until it's there? Dave G. wrote a very good comment about this. Sorry I lost it during patch squashing. Here is a copy of it. I will amend the comment in next version. The GuC loader uses an asynchronous thread to fetch the firmware image (aka binary blob) from a file. This thread has then had to wait for the mainline driver loading code to complete GEM initialisation before it can convert the blob into a GEM object and transfer it to the GuC's memory. Unfortunately, with this scheme, the GuC loading was occurring*after* the internally-generated batches used to initialise contexts had already been submitted (using direct access to the ELSP, since the GuC wasn't ready). In addition, the one-way synchronisation mechanism resulted in the firmware image being transfeered to the GuC at an indeterminate time (just sometime after the mainline thread releases the device's struct_mutex), with consequent confusion. Rather than complicate the loader further by adding a second sync point and arranging the handover of the struct_mutex from one thread to the other, this commit reverses the synchronisation so that the mainline thread waits for the asynchronous thread rather than vice versa. The firmware loader now only has to save the reference to the blob and signal a completion; the mainline thread can then continue with the rest of the loading process when it catches up. The result is a much simpler (and fully deterministic) process for loading the GuC firmware. -Alex ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/49] drm/i915: Reduce frequency of unspecific HSW reg debugging
2015-03-27 13:12 GMT-03:00 Chris Wilson ch...@chris-wilson.co.uk:
On Fri, Mar 27, 2015 at 12:34:05PM -0300, Paulo Zanoni wrote:
2015-03-27 8:01 GMT-03:00 Chris Wilson ch...@chris-wilson.co.uk:
Delay the expensive read on the FPGA_DBG register from once per mmio to
once per forcewake section when we are doing the general wellbeing
check rather than the targetted error detection. This almost reduces
the overhead of the debug facility (for example when submitting execlists)
to zero whilst keeping the debug checks around.
v2: Enable one-shot mmio debugging from the interrupt check as well as a
safeguard to catch invalid display writes from outside the powerwell.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Mika Kuoppala mika.kuopp...@intel.com
Cc: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 56
-
1 file changed, 30 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index ab5cc94588e1..0e32bbbcada8 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -149,6 +149,30 @@ fw_domains_put(struct drm_i915_private *dev_priv,
enum forcewake_domains fw_doma
}
static void
+hsw_unclaimed_reg_detect(struct drm_i915_private *dev_priv)
+{
+ static bool mmio_debug_once = true;
+
+ if (i915.mmio_debug || !mmio_debug_once)
+ return;
+
+ if (__raw_i915_read32(dev_priv, FPGA_DBG) FPGA_DBG_RM_NOCLAIM) {
+ DRM_DEBUG(Unclaimed register detected,
+ enabling oneshot unclaimed register reporting.
+ Please use i915.mmio_debug=N for more
information.\n);
+ __raw_i915_write32(dev_priv, FPGA_DBG,
FPGA_DBG_RM_NOCLAIM);
+ i915.mmio_debug = mmio_debug_once--;
+ }
+}
+
+static void
+fw_domains_put_debug(struct drm_i915_private *dev_priv, enum
forcewake_domains fw_domains)
+{
+ hsw_unclaimed_reg_detect(dev_priv);
+ fw_domains_put(dev_priv, fw_domains);
+}
This means we won't check during the forcewake puts that are on the
register read/write macros. Is this intentional?
Not really. But the check still catches any mistakes there even though
we know they are by safe.
I tried checking the
FW code calls, and it seems to me that we're not really going to run
hsw_unclaimed_reg_detect very frequently anymore. I wonder if there's
the risk of staying a long time without running it. But maybe I'm just
wrong.
It gets run after every set of register writes (where set is defined as
activity on a single cpu within 1ms). It gets run before the powerwell
is disabled. Look at the profiles, you will see that hsw detect is still
called quite frequently. And by virtue it does not need to be run very
often to catch issues anyway.
+ if (HAS_FPGA_DBG_UNCLAIMED(dev)
+ dev_priv-uncore.funcs.force_wake_put == fw_domains_put)
My fear here is that simple changes to the FW code by a future
programmer could unintentionally kill the unclaimed register detection
feature, and we probably wouldn't notice for a looong time. Why not
just omit this fw_domains_put check, since it is true for all
platforms where HAS_FPG_DBG_UNCLAIMED is also true? The side effect of
calling fw_domains_put() when we shouldn't is probably more noticeable
than having unclaimed register detection gone.
Pardon?
My suggestion was to find a way to transform this if statement above
somehow into a check just for if (has_fpga_dbg_unclaimed()), without
relying on whatever is assigned to funcs.force_wake_put, due to the
fear that a refactoring could accidentally kill the unclaimed register
detection. But it was just a suggestion.
+ dev_priv-uncore.funcs.force_wake_put =
fw_domains_put_debug;
+
/* All future platforms are expected to require complex power
gating */
WARN_ON(dev_priv-uncore.fw_domains == 0);
}
@@ -1411,11 +1420,6 @@ int intel_gpu_reset(struct drm_device *dev)
void intel_uncore_check_errors(struct drm_device *dev)
{
- struct drm_i915_private *dev_priv = dev-dev_private;
-
- if (HAS_FPGA_DBG_UNCLAIMED(dev)
- (__raw_i915_read32(dev_priv, FPGA_DBG) FPGA_DBG_RM_NOCLAIM))
{
- DRM_ERROR(Unclaimed register before interrupt\n);
- __raw_i915_write32(dev_priv, FPGA_DBG,
FPGA_DBG_RM_NOCLAIM);
- }
+ if (HAS_FPGA_DBG_UNCLAIMED(dev))
+ hsw_unclaimed_reg_detect(to_i915(dev));
This means we won't check for unclaimed registers during interrupts if
i915.mmio_debug is being used, which is probably not what we want.
It's exactly what you want. It still does the debug check if you have
mmio_debug unset. If you have
Re: [Intel-gfx] [PATCH 7/7] lib: add igt_draw
2015-03-26 7:19 GMT-03:00 Daniel Vetter dan...@ffwll.ch:
On Wed, Mar 25, 2015 at 06:50:39PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
For all those IGT tests that need an easy way to draw rectangles on
buffers using different methods. Current planned users: FBC and PSR
CRC tests.
There is also a lib/tests/igt_draw program to check if the library is
sane.
We need to move that to tests/igt_draw. The testcase in lib/tests/* get
run with make check, which must be possible as non-root on a non-intel
(build) machine. If you need an gpu to run your test it must be in tests/*
as a normal igt kernel test.
Wrt the library itself I'm unsure about the explicit tiling/swizzling.
Your current code only works on gen5-8 and maintaining a full-blown
swizzle/tiling library is real work, and means some of the tests can't be
converted to this.
This would just be a problem for the tests that use it, and no test is
using it yet. This is just for the cases where you want to use the CPU
to write into tiled buffers.
If we start using this in a test, then we need to properly test all
the affected platforms. I have some local FBC tests that use it -
which I was going to submit after getting feedback on this lib -, and
I don't think we'll end needing to run these tests on the older
platforms.
We do have all the tiling modes encoded in the tiling
tests though, so if you have a lot of time it might be useful to extract
tiling helpers into the igt library which work on all generations.
Can you please be more precise here? Where exactly should I look?
I think we should at least have a fallback mode which allows us to fill an
entire buffer completely (i.e. not just the hxw area) and treat it as
untiled.
That is not the goal of the library. Still, if we ever need this
function, it would be easy to add.
More comments below.
More below too :)
-Daniel
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
lib/Makefile.sources | 2 +
lib/igt_draw.c | 467
+
lib/igt_draw.h | 54 ++
lib/tests/.gitignore | 1 +
lib/tests/Makefile.sources | 1 +
lib/tests/igt_draw.c | 247
6 files changed, 772 insertions(+)
create mode 100644 lib/igt_draw.c
create mode 100644 lib/igt_draw.h
create mode 100644 lib/tests/igt_draw.c
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 3d93629..85dc321 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -52,6 +52,8 @@ libintel_tools_la_SOURCES = \
igt_fb.h\
igt_core.c \
igt_core.h \
+ igt_draw.c \
+ igt_draw.h \
$(NULL)
.PHONY: version.h.tmp
diff --git a/lib/igt_draw.c b/lib/igt_draw.c
new file mode 100644
index 000..4eb7507
--- /dev/null
+++ b/lib/igt_draw.c
@@ -0,0 +1,467 @@
+/*
+ * Copyright © 2015 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 the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER
+ * LIABILITY, WHETHER 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.
+ *
+ */
+
+#include sys/mman.h
+
+#include igt_draw.h
+
+#include drmtest.h
+#include intel_chipset.h
+#include igt_core.h
+#include igt_fb.h
+#include ioctl_wrappers.h
+
+/**
+ * SECTION:igt_draw
+ * @short_description: drawing helpers for tests
+ * @title: i-g-t draw
+ * @include: igt_draw.h
+ *
+ * This library contains some functions for drawing rectangles on buffers
using
+ * the many different drawing methods we have. It also contains some
wrappers
+ * that make the process easier if you have the abstract objects in hand.
+ *
+ * All functions assume the buffers are in the XRGB 8:8:8 format.
+ *
+ */
+
+/* Some internal data structures to avoid having to pass tons of parameters
+ * around everything. */
+struct cmd_data {
+ drm_intel_bufmgr *bufmgr;
+
Re: [Intel-gfx] [PATCH 10/21 v2] drm/i915: Helper function to detach a scaler from a plane or crtc
-Original Message- From: Roper, Matthew D Sent: Friday, March 27, 2015 5:22 PM To: Konduru, Chandra Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel; Conselvan De Oliveira, Ander Subject: Re: [PATCH 10/21 v2] drm/i915: Helper function to detach a scaler from a plane or crtc On Wed, Mar 25, 2015 at 02:28:16PM -0700, Konduru, Chandra wrote: -Original Message- From: Roper, Matthew D Sent: Wednesday, March 25, 2015 2:14 PM To: Konduru, Chandra Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel; Conselvan De Oliveira, Ander Subject: Re: [PATCH 10/21 v2] drm/i915: Helper function to detach a scaler from a plane or crtc On Wed, Mar 25, 2015 at 01:14:40PM -0700, Konduru, Chandra wrote: -Original Message- From: Roper, Matthew D Sent: Tuesday, March 24, 2015 10:16 PM To: Konduru, Chandra Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel; Conselvan De Oliveira, Ander Subject: Re: [PATCH 10/21 v2] drm/i915: Helper function to detach a scaler from a plane or crtc On Fri, Mar 20, 2015 at 05:04:31PM -0700, Chandra Konduru wrote: This function is called from commit path of a plane or crtc. It programs scaler registers to detach (aka. unbinds) scaler from requested plane or crtc if it isn't in use. It also resets scaler_id in crtc/plane state. v2: -improved a log message (me) Signed-off-by: Chandra Konduru chandra.kond...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 39 ++ drivers/gpu/drm/i915/intel_drv.h |1 + 2 files changed, 40 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 976bfb1..7150c33 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2836,6 +2836,45 @@ u32 intel_fb_stride_alignment(struct drm_device *dev, uint64_t fb_modifier, } } +/* + * This function detaches (aka. unbinds) a scaler from plane +or crtc You might want to clarify that detach/unbind refers to the actual hardware programming, not the state calculation. I'm a bit surprised we need this function; I figured we'd just be looping over all scalers at the end of the commit step and programming them to either on or off depending on what the scaling state contained. This is bit tricky and isn't that straight forward. Staged scaler state can trigger freeing a scaler that can lead to two scenarios: 1) freed scaler is not attached to any other user. In this case, reg programming needed to update hw. And reset scaler_id to -1 to indicate scaler isn't used. Once done, both sw and hw states are in sync. 2) freed scaler is allocated to someone. In this case, registers shouldn't be programmed by previous owner because scaler may be in use by new owner. I think I explained these details in comments already. But will check and update if needed. I might not have been clear in my earlier email. What I meant was that I didn't expect scalers to be programmed as part of their owner's programming at all. At the moment you seem to be programming them in the low-level plane programming functions (skl_update_plane and such). Instead, I had expected a single loop over each scaler at the very end of the entire commit process, after you're done with the plane programming functions. The scaler state would already indicate whether the scaler is supposed to be associated with a plane/crtc (which may or may not be the same as the previous frame; we don't care) or whether it is unused and should be programmed to off. So basically you would wind up programming all of the scaler registers on each atomic commit, even if they didn't change, but you wouldn't have to worry about whether the scaler's owner is changing or who is responsible for doing the programming of that scaler this time around --- basically just treat scalers as an independent resource that have their own programming step at the end of processing a CRTC. OK. Now I understand what you meant. In early versions, I tried something similar, but that approach required back pointers from scaler to its owner to program scaler output window coordinates. And it also requires managing back pointer assignment and resetting. It is certainly doable but I didn't see any advantage than current approach. As I mentioned on a previous patch, these overloaded functions that might operate on a plane or might operate on a CRTC can be a bit confusing, especially when we have multi-nested ternary operators like you do below. + * if scaler is not in use. + * It
[Intel-gfx] [PATCH 1/2] i-g-t: Adding plane scaling test case
From: chandra konduru chandra.kond...@intel.com
This patch is adding i-g-t plane scaling test case to test couple basic
display plane scaling usages. Additional test scenarios can be added later.
v2:
-Added iterative scaling to visually observe scaling (me)
v3:
-Added a flag to control primary plane scaling (me)
v4:
-Use new tiled types when calling igt_create_fb (me)
Signed-off-by: chandra konduru chandra.kond...@intel.com
---
lib/igt_fb.h |4 +
lib/igt_kms.c | 122 +--
lib/igt_kms.h |5 +
tests/.gitignore |1 +
tests/Android.mk |1 +
tests/Makefile.sources|1 +
tests/kms_plane_scaling.c | 370 +
7 files changed, 488 insertions(+), 16 deletions(-)
create mode 100644 tests/kms_plane_scaling.c
diff --git a/lib/igt_fb.h b/lib/igt_fb.h
index bafafcd..a07acd2 100644
--- a/lib/igt_fb.h
+++ b/lib/igt_fb.h
@@ -54,6 +54,10 @@ struct igt_fb {
uint64_t tiling;
unsigned size;
cairo_surface_t *cairo_surface;
+ uint32_t src_x;
+ uint32_t src_y;
+ uint32_t src_w;
+ uint32_t src_h;
};
enum igt_text_align {
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 9c46e18..b5d5832 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -1313,6 +1313,14 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
igt_display_t *display = output-display;
uint32_t fb_id, crtc_id;
int ret;
+ uint32_t src_x;
+ uint32_t src_y;
+ uint32_t src_w;
+ uint32_t src_h;
+ int32_t crtc_x;
+ int32_t crtc_y;
+ uint32_t crtc_w;
+ uint32_t crtc_h;
igt_assert(plane-drm_plane);
@@ -1343,32 +1351,43 @@ static int igt_drm_plane_commit(igt_plane_t *plane,
IGT_FIXED(0,0) /* src_h */);
CHECK_RETURN(ret, fail_on_error);
- } else if (plane-fb_changed || plane-position_changed) {
+ } else if (plane-fb_changed || plane-position_changed ||
+ plane-size_changed) {
+ src_x = IGT_FIXED(plane-fb-src_x,0); /* src_x */
+ src_y = IGT_FIXED(plane-fb-src_y,0); /* src_y */
+ src_w = IGT_FIXED(plane-fb-src_w,0); /* src_w */
+ src_h = IGT_FIXED(plane-fb-src_h,0); /* src_h */
+ crtc_x = plane-crtc_x;
+ crtc_y = plane-crtc_y;
+ crtc_w = plane-crtc_w;
+ crtc_h = plane-crtc_h;
+
LOG(display,
- %s: SetPlane %s.%d, fb %u, position (%d, %d)\n,
+ %s: SetPlane %s.%d, fb %u, src = (%d, %d)
+ %ux%u dst = (%u, %u) %ux%u\n,
igt_output_name(output),
kmstest_pipe_name(output-config.pipe),
plane-index,
fb_id,
- plane-crtc_x, plane-crtc_y);
+ src_x 16, src_y 16, src_w 16, src_h 16,
+ crtc_x, crtc_y, crtc_w, crtc_h);
ret = drmModeSetPlane(display-drm_fd,
plane-drm_plane-plane_id,
crtc_id,
fb_id,
0,/* flags */
- plane-crtc_x, plane-crtc_y,
- plane-crtc_w, plane-crtc_h,
- IGT_FIXED(0,0), /* src_x */
- IGT_FIXED(0,0), /* src_y */
- IGT_FIXED(plane-fb-width,0), /* src_w */
- IGT_FIXED(plane-fb-height,0) /* src_h
*/);
+ crtc_x, crtc_y,
+ crtc_w, crtc_h,
+ src_x, src_y,
+ src_w, src_h);
CHECK_RETURN(ret, fail_on_error);
}
plane-fb_changed = false;
plane-position_changed = false;
+ plane-size_changed = false;
if (plane-rotation_changed) {
igt_plane_set_property(plane, plane-rotation_property,
@@ -1463,7 +1482,7 @@ static int igt_primary_plane_commit_legacy(igt_plane_t
*primary,
igt_assert(!primary-rotation_changed);
if (!primary-fb_changed !primary-position_changed
- !primary-panning_changed)
+ !primary-size_changed !primary-panning_changed)
return 0;
crtc_id = output-config.crtc-crtc_id;
@@ -1510,6 +1529,7 @@ static int igt_primary_plane_commit_legacy(igt_plane_t
*primary,
primary-pipe-enabled = (fb_id != 0);
primary-fb_changed = false;
primary-position_changed = false;
+ primary-size_changed = false;
primary-panning_changed = false;
return 0;
@@ -1567,7 +1587,7 @@ static int igt_output_commit(igt_output_t *output,
[Intel-gfx] [PATCH 2/2] i-g-t: Adding panel fitting test case
From: chandra konduru chandra.kond...@intel.com
This patch is adding i-g-t test case to test panel fitting usages.
v2:
-use new tiled types when calling igt_create_fb (me)
Signed-off-by: chandra konduru chandra.kond...@intel.com
---
tests/.gitignore |1 +
tests/Android.mk |1 +
tests/Makefile.sources|1 +
tests/kms_panel_fitting.c | 270 +
4 files changed, 273 insertions(+)
create mode 100644 tests/kms_panel_fitting.c
diff --git a/tests/.gitignore b/tests/.gitignore
index 0d03fbe..59b12ee 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -143,6 +143,7 @@ kms_universal_plane
kms_vblank
kms_crtc_background_color
kms_plane_scaling
+kms_panel_fitting
multi-tests.txt
pm_lpsp
pm_rc6_residency
diff --git a/tests/Android.mk b/tests/Android.mk
index c024296..ee508ec 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -77,6 +77,7 @@ else
kms_flip_event_leak \
kms_crtc_background_color \
kms_plane_scaling \
+kms_panel_fitting \
kms_pwrite_crc
IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0
endif
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index a04c31e..ab1f40e 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -84,6 +84,7 @@ TESTS_progs_M = \
kms_vblank \
kms_crtc_background_color \
kms_plane_scaling \
+ kms_panel_fitting \
pm_lpsp \
pm_rpm \
pm_rps \
diff --git a/tests/kms_panel_fitting.c b/tests/kms_panel_fitting.c
new file mode 100644
index 000..d541091
--- /dev/null
+++ b/tests/kms_panel_fitting.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright © 2013,2014 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 the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER 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.
+ *
+ */
+
+#include math.h
+
+#include drmtest.h
+#include igt_debugfs.h
+#include igt_kms.h
+#include igt_core.h
+#include intel_chipset.h
+#include igt_aux.h
+
+IGT_TEST_DESCRIPTION(Test display panel fitting);
+
+typedef struct {
+ uint32_t devid;
+ int drm_fd;
+ igt_display_t display;
+ igt_crc_t ref_crc;
+ igt_pipe_crc_t *pipe_crc;
+
+ int image_w;
+ int image_h;
+
+ int num_scalers;
+
+ struct igt_fb fb1;
+ struct igt_fb fb2;
+ struct igt_fb fb3;
+ int fb_id1;
+ int fb_id2;
+ int fb_id3;
+
+ igt_plane_t *plane1;
+ igt_plane_t *plane2;
+ igt_plane_t *plane3;
+ igt_plane_t *plane4;
+} data_t;
+
+#define FILE_NAME 1080p-left.png
+
+static void
+paint_color(data_t *d, struct igt_fb *fb, uint16_t w, uint16_t h)
+{
+ cairo_t *cr;
+
+ cr = igt_get_cairo_ctx(d-drm_fd, fb);
+ igt_paint_test_pattern(cr, w, h);
+ cairo_destroy(cr);
+}
+
+static void
+paint_image(data_t *d, struct igt_fb *fb, uint16_t w, uint16_t h)
+{
+ cairo_t *cr;
+
+ cr = igt_get_cairo_ctx(d-drm_fd, fb);
+ igt_paint_image(cr, FILE_NAME, 0, 0, w, h);
+ cairo_destroy(cr);
+}
+
+static void prepare_crtc(data_t *data, igt_output_t *output, enum pipe pipe,
+ igt_plane_t *plane, drmModeModeInfo *mode, enum
igt_commit_style s)
+{
+ igt_display_t *display = data-display;
+
+ igt_output_set_pipe(output, pipe);
+
+ /* create the pipe_crc object for this pipe */
+ igt_pipe_crc_free(data-pipe_crc);
+ data-pipe_crc = igt_pipe_crc_new(pipe, INTEL_PIPE_CRC_SOURCE_AUTO);
+
+ /* before allocating, free if any older fb */
+ if (data-fb_id1) {
+ igt_remove_fb(data-drm_fd, data-fb1);
+ data-fb_id1 = 0;
+ }
+
+ /* allocate fb for plane 1 */
+ data-fb_id1 = igt_create_fb(data-drm_fd,
+ mode-hdisplay, mode-vdisplay,
+ DRM_FORMAT_XRGB,
+ LOCAL_I915_FORMAT_MOD_X_TILED, /* tiled */
+ data-fb1);
+ igt_assert(data-fb_id1);
+
+
[Intel-gfx] [PATCH 1/5] i965/skl: Add macros for Yf/Ys tiling formats
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
include/drm/i915_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..a6c167c 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -842,6 +842,8 @@ struct drm_i915_gem_caching {
#define I915_TILING_NONE 0
#define I915_TILING_X 1
#define I915_TILING_Y 2
+#define I915_TILING_YF 3
+#define I915_TILING_YS 4
#define I915_BIT_6_SWIZZLE_NONE0
#define I915_BIT_6_SWIZZLE_9 1
--
2.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] i965/skl: Add YF/YS tiling support
Series is available at: https://github.com/aphogat/drm.git, branch: tiling-yf-ys Anuj Phogat (5): i965/skl: Add macros for Yf/Ys tiling formats i965/skl: Move tile_width computations out of drm_intel_gem_bo_tile_pitch i965/skl: Set tile width and height for YF/YS tiling Align YS tile base address to 64KB build: Bump the version to 2.4.61 configure.ac | 2 +- include/drm/i915_drm.h | 2 ++ intel/intel_bufmgr_gem.c | 77 +++- 3 files changed, 66 insertions(+), 15 deletions(-) -- 2.3.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] i965/skl: Set tile width and height for YF/YS tiling
I'm still passing tiling=I915_TILING_Y in drm_intel_gem_bo_alloc_internal()
in case of YF/YS tiling. Passing tiling=I915_TILING_{YF,YS} causes bo
allocation failure. Any advice what's the right thing to do here?
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
intel/intel_bufmgr_gem.c | 49 +++-
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index af44ba5..7c50e26 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -803,6 +803,39 @@ drm_intel_gem_bo_alloc(drm_intel_bufmgr *bufmgr,
I915_TILING_NONE, 0);
}
+/* This function does tile height computations valid only for Yf/Ys tiled
+ * surfaces.
+ */
+static unsigned
+drm_intel_gem_tile_height(unsigned bpp, uint32_t tiling)
+{
+ unsigned tile_height;
+ assert(tiling == I915_TILING_YF || tiling == I915_TILING_YS);
+
+ switch (bpp) {
+ case 8:
+ tile_height = 64;
+ break;
+ case 16:
+ case 32:
+ tile_height = 32;
+ break;
+ case 64:
+ case 128:
+ tile_height = 16;
+ break;
+ default:
+ printf(Invalid bits per pixel in %s: bpp = %d\n,
+ __FUNCTION__, bpp);
+ return 0;
+ }
+
+ if (tiling == I915_TILING_YS)
+ tile_height *= 4;
+
+ return tile_height;
+}
+
static drm_intel_bo *
drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
int x, int y, int cpp, uint32_t *tiling_mode,
@@ -838,7 +871,15 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
tiling == I915_TILING_Y)) {
height_alignment = 8;
tile_width = 512;
- } else if (tiling == I915_TILING_Y)
+ } else if (tiling == I915_TILING_YF ||
+ tiling == I915_TILING_YS) {
+ unsigned bpp = cpp * 8;
+ unsigned aspect_ratio =
+ (bpp == 16 || bpp == 64) ? 2 : 1;
+ height_alignment =
+ drm_intel_gem_tile_height(bpp, tiling);
+ tile_width = height_alignment * cpp * aspect_ratio;
+ } else if (tiling == I915_TILING_Y){
height_alignment = 32;
tile_width = 128;
}
@@ -855,6 +896,12 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
if (tiling == I915_TILING_NONE)
stride = 0;
+ /* Use I915_TILING_Y in drm_intel_gem_bo_alloc_internal() in case of
+* YF/YS tiling.
+*/
+ tiling = (tiling == I915_TILING_YF || tiling == I915_TILING_YS) ?
+ I915_TILING_Y : tiling;
+
return drm_intel_gem_bo_alloc_internal(bufmgr, name, size, flags,
tiling, stride);
}
--
2.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] build: Bump the version to 2.4.61
This is required due to new macros added to i915_drm.h. These macros are used by i965 driver. Signed-off-by: Anuj Phogat anuj.pho...@gmail.com --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 155d577..17c0e71 100644 --- a/configure.ac +++ b/configure.ac @@ -20,7 +20,7 @@ AC_PREREQ([2.63]) AC_INIT([libdrm], -[2.4.60], +[2.4.61], [https://bugs.freedesktop.org/enter_bug.cgi?product=DRI], [libdrm]) -- 2.3.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] i965/skl: Move tile_width computations out of drm_intel_gem_bo_tile_pitch
This will be utilized by next patch in this series.
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com
---
intel/intel_bufmgr_gem.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 5a67f53..af44ba5 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -324,9 +324,9 @@ drm_intel_gem_bo_tile_size(drm_intel_bufmgr_gem
*bufmgr_gem, unsigned long size,
*/
static unsigned long
drm_intel_gem_bo_tile_pitch(drm_intel_bufmgr_gem *bufmgr_gem,
- unsigned long pitch, uint32_t *tiling_mode)
+ unsigned long pitch, unsigned long tile_width,
+ uint32_t *tiling_mode)
{
- unsigned long tile_width;
unsigned long i;
/* If untiled, then just align it so that we can do rendering
@@ -335,13 +335,6 @@ drm_intel_gem_bo_tile_pitch(drm_intel_bufmgr_gem
*bufmgr_gem,
if (*tiling_mode == I915_TILING_NONE)
return ALIGN(pitch, 64);
- if (*tiling_mode == I915_TILING_X
- || (IS_915(bufmgr_gem-pci_device)
-*tiling_mode == I915_TILING_Y))
- tile_width = 512;
- else
- tile_width = 128;
-
/* 965 is flexible */
if (bufmgr_gem-gen = 4)
return ROUND_UP_TO(pitch, tile_width);
@@ -816,7 +809,7 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
unsigned long *pitch, unsigned long flags)
{
drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bufmgr;
- unsigned long size, stride;
+ unsigned long size, stride, tile_width;
uint32_t tiling;
do {
@@ -842,14 +835,18 @@ drm_intel_gem_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
const char *name,
height_alignment = 16;
else if (tiling == I915_TILING_X
|| (IS_915(bufmgr_gem-pci_device)
-tiling == I915_TILING_Y))
+tiling == I915_TILING_Y)) {
height_alignment = 8;
- else if (tiling == I915_TILING_Y)
+ tile_width = 512;
+ } else if (tiling == I915_TILING_Y)
height_alignment = 32;
+ tile_width = 128;
+ }
aligned_y = ALIGN(y, height_alignment);
stride = x * cpp;
- stride = drm_intel_gem_bo_tile_pitch(bufmgr_gem, stride,
tiling_mode);
+ stride = drm_intel_gem_bo_tile_pitch(bufmgr_gem, stride,
+tile_width, tiling_mode);
size = stride * aligned_y;
size = drm_intel_gem_bo_tile_size(bufmgr_gem, size,
tiling_mode);
} while (*tiling_mode != tiling);
--
2.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] i-g-t: Adding test case to test background color.
From: chandra konduru chandra.kond...@intel.com
Adding i-g-t test case to test display crtc background color.
v2:
- Added IGT_TEST_DESCRIPTION() (Thomas Wood)
- Added to .gitignore (Thomas Wood)
- Added additional details to function header (Thomas Wood)
- Simplified igt_main (Thomas Wood)
v3:
- rebased to latest master (me)
- took sleep calls out (Daniel)
- use new tiled types when calling igt_create_fb (me)
Signed-off-by: chandra konduru chandra.kond...@intel.com
---
lib/igt_kms.c | 61
lib/igt_kms.h | 4 +
tests/.gitignore | 1 +
tests/Android.mk | 1 +
tests/Makefile.sources| 1 +
tests/kms_crtc_background_color.c | 195 ++
6 files changed, 263 insertions(+)
create mode 100644 tests/kms_crtc_background_color.c
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 9c131f0..9c46e18 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -940,6 +940,22 @@ igt_plane_set_property(igt_plane_t *plane, uint32_t
prop_id, uint64_t value)
DRM_MODE_OBJECT_PLANE, prop_id, value);
}
+static bool
+get_crtc_property(int drm_fd, uint32_t crtc_id, const char *name,
+ uint32_t *prop_id /* out */, uint64_t *value /* out */,
+ drmModePropertyPtr *prop /* out */)
+{
+ return kmstest_get_property(drm_fd, crtc_id, DRM_MODE_OBJECT_CRTC,
+ name, prop_id, value, prop);
+}
+
+static void
+igt_crtc_set_property(igt_output_t *output, uint32_t prop_id, uint64_t value)
+{
+ drmModeObjectSetProperty(output-display-drm_fd,
+ output-config.crtc-crtc_id, DRM_MODE_OBJECT_CRTC, prop_id,
value);
+}
+
/*
* Walk a plane's property list to determine its type. If we don't
* find a type property, then the kernel doesn't support universal
@@ -1097,6 +1113,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
igt_assert(display-outputs);
for (i = 0; i display-n_outputs; i++) {
+ int j;
igt_output_t *output = display-outputs[i];
/*
@@ -1108,6 +1125,19 @@ void igt_display_init(igt_display_t *display, int drm_fd)
output-display = display;
igt_output_refresh(output);
+
+ for (j = 0; j display-n_pipes; j++) {
+ uint64_t prop_value;
+ igt_pipe_t *pipe = display-pipes[j];
+ if (output-config.crtc) {
+ get_crtc_property(display-drm_fd,
output-config.crtc-crtc_id,
+ background_color,
+ pipe-background_property,
+ prop_value,
+ NULL);
+ pipe-background = (uint32_t)prop_value;
+ }
+ }
}
drmModeFreePlaneResources(plane_resources);
@@ -1527,6 +1557,13 @@ static int igt_output_commit(igt_output_t *output,
pipe = igt_output_get_driving_pipe(output);
+ if (pipe-background_changed) {
+ igt_crtc_set_property(output, pipe-background_property,
+ pipe-background);
+
+ pipe-background_changed = false;
+ }
+
for (i = 0; i pipe-n_planes; i++) {
igt_plane_t *plane = pipe-planes[i];
@@ -1779,6 +1816,30 @@ void igt_plane_set_rotation(igt_plane_t *plane,
igt_rotation_t rotation)
plane-rotation_changed = true;
}
+/**
+ * igt_crtc_set_background:
+ * @pipe: pipe pointer to which background color to be set
+ * @background: background color value in BGR 16bpc
+ *
+ * Sets background color for requested pipe. Color value provided here
+ * will be actually submitted at output commit time via background_color
+ * property.
+ * For example to get red as background, set background = 0x.
+ */
+void igt_crtc_set_background(igt_pipe_t *pipe, uint64_t background)
+{
+ igt_display_t *display = pipe-display;
+
+ LOG(display, %s.%d: crtc_set_background(%lu)\n,
+ kmstest_pipe_name(pipe-pipe),
+ pipe-pipe, background);
+
+ pipe-background = background;
+
+ pipe-background_changed = true;
+}
+
+
void igt_wait_for_vblank(int drm_fd, enum pipe pipe)
{
drmVBlank wait_vbl;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 565df14..84e8456 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -207,6 +207,9 @@ struct igt_pipe {
#define IGT_MAX_PLANES 4
int n_planes;
igt_plane_t planes[IGT_MAX_PLANES];
+ uint64_t background; /* Background color MSB BGR 16bpc LSB */
+ uint32_t background_changed : 1;
+ uint32_t background_property;
};
typedef struct {
@@ -252,6 +255,7 @@ void igt_plane_set_position(igt_plane_t *plane, int x,
[Intel-gfx] [PATCH 4/5] Align YS tile base address to 64KB
Signed-off-by: Anuj Phogat anuj.pho...@gmail.com --- intel/intel_bufmgr_gem.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c index 7c50e26..775a9f9 100644 --- a/intel/intel_bufmgr_gem.c +++ b/intel/intel_bufmgr_gem.c @@ -289,8 +289,13 @@ drm_intel_gem_bo_tile_size(drm_intel_bufmgr_gem *bufmgr_gem, unsigned long size, if (*tiling_mode == I915_TILING_NONE) return size; + /* Tiled surface base addresses must be tile aligned (64KB aligned +* for TileYS, 4KB aligned for all other tile modes). +*/ + if (*tiling_mode == I915_TILING_YS) + return ROUND_UP_TO(size, 64 * 1024); /* 965+ just need multiples of page size for tiling */ - if (bufmgr_gem-gen = 4) + else if (bufmgr_gem-gen = 4) return ROUND_UP_TO(size, 4096); /* Older chips need powers of two, of at least 512k or 1M */ -- 2.3.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/2] tests: apply igt.cocci
On Mon, Mar 30, 2015 at 04:53:38PM +0100, Thomas Wood wrote: diff --git a/tests/eviction_common.c b/tests/eviction_common.c index 4fa5c04..9e06cbb 100644 --- a/tests/eviction_common.c +++ b/tests/eviction_common.c @@ -200,18 +200,19 @@ static void mlocked_evictions(int fd, struct igt_eviction_test_ops *ops, ops-close(fd, bo[n]); out: - write(result[1], ret, sizeof(ret)); + igt_assert_eq(write(result[1], ret, sizeof(ret)), + sizeof(ret)); } igt_waitchildren(); fcntl(result[0], F_SETFL, fcntl(result[0], F_GETFL) | O_NONBLOCK); - read(result[0], ret, sizeof(ret)); + igt_assert_eq(read(result[0], ret, sizeof(ret)), sizeof(ret)); No. This read() may return -1 (with ret then being == -1 due to the earlier initialisation) if the child is killed by a sigbus Hah, and now I realise my overcomplication, if we just get the status back via igt_waitchildren passing the result back via a pipe is silly. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
