[Intel-gfx] Intel eDP and fixed_mode probing/initialization
Hoping someone can point me in the right direction to understanding how intel_connector->panel.fixed_mode gets probed, as it's referenced in function "intel_dp_mode_valid" at drivers/gpu/drm/i915/intel_dp.c. I am working with a panel hooked up via DSUB to a port that is internally wired as eDP-1. The kernel is correctly probing its EDID-advertised preferred mode, 1360x768@60. However, in the above-named function, that mode is then being discarded with status MODE_PANEL (exceeds panel dimensions). After poking around a bit and adding some debugging output, I've gotten as far as the above-named function and found that fixed_mode is coming in to that function as 1280x800. Trying to trace back farther than that I get a bit lost. Thanks in advance if anyone can help me figure out where that spurious mode limitation is coming from. Incidentally, commenting out the checks against fixed_mode->hdisplay and fixed_mode->vdisplay make the panel work correctly, but I'd like to come at this from the other direction and find out why the probe failed in the first place. Thanks! Kernel is 3.16.0-4-686-pae from Debian Jessie Device is Intel Atom Processor Z36xxx/Z37xxx (8086:0f31) Dmesg here, interesting bit starts around line 807: http://pastebin.com/kpeWW0iB -- Josh Litherland (j...@temp123.org) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] Add automation support for DP compliance Tests
This patch series adds the automation support for DP Compliance Tests for EDID and Video Pattern generation from CTS specification 1.2 Rev 1.1. Jim Bride (1): Add support for forcing 6 bpc on DP pipes. Manasi Navare (4): drm/i915: Invoke the DP Compliance test request handler in the short pulse path drm/i915: Disable the Link training automation support drm/i915: Fixes to support the DP Compliance EDID tests. drm/i915: Implement intel_dp_autotest_video_pattern function for DP Video pattern compliance tests drivers/gpu/drm/i915/i915_debugfs.c | 14 +- drivers/gpu/drm/i915/intel_display.c | 32 +- drivers/gpu/drm/i915/intel_dp.c | 86 +--- drivers/gpu/drm/i915/intel_drv.h | 10 + include/drm/drm_dp_helper.h | 14 +- 5 files changed, 147 insertions(+), 9 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] Add support for forcing 6 bpc on DP pipes.
From: Jim BrideFor DP compliance we need to be able to control the output color type for the pipe associated with the DP port. To do this we rely on the intel_dp_test_force_bpc debugfs file and the associated value stored in struct intel_dp. If the debugfs file has a non-zero value and we're on a display port connector, then we use the value from debugfs to calculate the bpp for the pipe. For cases where we are not on DP or there has not been an overridden value then we behave as normal. Signed-off-by: Jim Bride Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/intel_display.c | 32 ++-- drivers/gpu/drm/i915/intel_drv.h | 1 + 2 files changed, 31 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 5ffccf6..1618d36 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12102,11 +12102,39 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc, /* Clamp display bpp to EDID value */ for_each_connector_in_state(state, connector, connector_state, i) { + int type = 0; + + if (connector_state->best_encoder) { + struct intel_encoder *ienc; + + ienc = to_intel_encoder(connector_state->best_encoder); + type = ienc->type; + } + if (connector_state->crtc != >base) continue; - connected_sink_compute_bpp(to_intel_connector(connector), - pipe_config); + /* For DP compliance we need to ensure that we can override +* the computed bpp for the pipe. +*/ + if (type == INTEL_OUTPUT_DISPLAYPORT) { + struct intel_dp *intel_dp = + enc_to_intel_dp(connector_state->best_encoder); + + if (intel_dp && + (intel_dp->compliance_force_bpc != 0)) { + pipe_config->pipe_bpp = + intel_dp->compliance_force_bpc*3; + DRM_DEBUG_KMS("JMB Setting pipe_bpp to %d\n", + pipe_config->pipe_bpp); + } else { + connected_sink_compute_bpp(to_intel_connector(connector), + pipe_config); + } + } else { + connected_sink_compute_bpp(to_intel_connector(connector), + pipe_config); + } } return bpp; diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index e23eed7..10eaff8 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -865,6 +865,7 @@ struct intel_dp { unsigned long compliance_test_type; unsigned long compliance_test_data; bool compliance_test_active; + unsigned long compliance_force_bpc; /* 0 for default or bpc to use */ }; struct intel_digital_port { -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Fixes to support the DP Compliance EDID tests.
This patch addresses a few issues from the original patch for DP Compliance EDID test support submitted by Todd PreviteVideo Mode requested in the EDID test handler for the EDID Read test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec. Intel connector status should be connected even if detect_edid is NULL when compliance_test flag is set. This is required to handle the corrupt EDID (CTS 4.2.2.6) or EDID Read Failure I2C NACK/I2C DEFER (CTS 4.2.2.4 and 4.2.2.5) tests from CTS spec. Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/intel_dp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 0961f22..456fc17 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4023,7 +4023,7 @@ static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp) static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp) { - uint8_t test_result = DP_TEST_NAK; + uint8_t test_result = DP_TEST_ACK; struct intel_connector *intel_connector = intel_dp->attached_connector; struct drm_connector *connector = _connector->base; @@ -4058,7 +4058,7 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp) DRM_DEBUG_KMS("Failed to write EDID checksum\n"); test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE; - intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_STANDARD; + intel_dp->compliance_test_data = INTEL_DP_RESOLUTION_PREFERRED; } /* Set test active flag here so userspace doesn't interrupt things */ @@ -4650,7 +4650,7 @@ intel_dp_detect(struct drm_connector *connector, bool force) intel_dp->detect_done = false; - if (intel_connector->detect_edid) + if (intel_connector->detect_edid || intel_dp->compliance_test_active) return connector_status_connected; else return connector_status_disconnected; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Implement intel_dp_autotest_video_pattern function for DP Video pattern compliance tests
This video pattern test function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. Signed-off-by: Manasi Navare--- drivers/gpu/drm/i915/i915_debugfs.c | 14 ++- drivers/gpu/drm/i915/intel_dp.c | 76 + drivers/gpu/drm/i915/intel_drv.h| 9 + include/drm/drm_dp_helper.h | 14 ++- 4 files changed, 111 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 6ee69b1..c8d0805 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4458,7 +4458,19 @@ static int i915_displayport_test_data_show(struct seq_file *m, void *data) if (connector->status == connector_status_connected && connector->encoder != NULL) { intel_dp = enc_to_intel_dp(connector->encoder); - seq_printf(m, "%lx", intel_dp->compliance_test_data); + if (intel_dp->compliance_test_type == + DP_TEST_LINK_EDID_READ) + seq_printf(m, "%lx", + intel_dp->compliance_test_data); + else if (intel_dp->compliance_test_type == +DP_TEST_LINK_VIDEO_PATTERN) { + seq_printf(m, "hdisplay: %lu\n", + intel_dp->test_data.hdisplay); + seq_printf(m, "vdisplay: %lu\n", + intel_dp->test_data.vdisplay); + seq_printf(m, "bpc: %u\n", + intel_dp->test_data.bpc); + } } else seq_puts(m, "0"); } diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 456fc17..134cff8 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4018,6 +4018,82 @@ static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp) static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp) { uint8_t test_result = DP_TEST_NAK; + uint8_t test_pattern; + uint16_t h_width, v_height, test_misc; + int status = 0; + + /* Automation support for Video Pattern Tests has a dependency +* on Link training Automation support (CTS Test 4.3.1.11) +* Hence it returns a TEST NAK until the Link Training automation +* support is added to the kernel +*/ + return test_result; + + /* Read the TEST_PATTERN (DP CTS 3.1.5) */ + status = drm_dp_dpcd_read(_dp->aux, DP_TEST_PATTERN, + _pattern, 1); + if (status <= 0) { + DRM_DEBUG_KMS("Could not read test pattern from" + "refernce sink\n"); + return 0; + } + if (test_pattern != DP_COLOR_RAMP) + return test_result; + intel_dp->test_data.video_pattern = test_pattern; + + status = drm_dp_dpcd_read(_dp->aux, DP_TEST_H_WIDTH, + _width, 2); + if (status <= 0) { + DRM_DEBUG_KMS("Could not read H Width from" + "refernce sink\n"); + return 0; + } + intel_dp->test_data.hdisplay = (h_width & DP_TEST_MSB_MASK) >> 8 | + (h_width << 8); + + status = drm_dp_dpcd_read(_dp->aux, DP_TEST_V_HEIGHT, + _height, 2); + if (status <= 0) { + DRM_DEBUG_KMS("Could not read V Height from" + "refernce sink\n"); + return 0; + } + intel_dp->test_data.vdisplay = (v_height & DP_TEST_MSB_MASK) >> 8 | + (v_height << 8); + + status = drm_dp_dpcd_read(_dp->aux, DP_TEST_MISC, + _misc, 1); + if (status <= 0) { + DRM_DEBUG_KMS("Could not read TEST MISC from" + "refernce sink\n"); + return 0; + } + if (((test_misc & DP_TEST_COLOR_FORMAT_MASK) >> 1) != + DP_VIDEO_PATTERN_RGB_FORMAT) +
[Intel-gfx] [PATCH 1/5] drm/i915: Invoke the DP Compliance test request handler in the short pulse path
HPD Short pulse test requests occur for DP Compliance Link Training and Video Pattern tests.The DP Test request handler needs to be invoked by these tests in the short pulse path in order to support automated DP Compliance tests. Signed-off-by: Manasi Navare--- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index c12c414..19a95ed 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4257,7 +4257,7 @@ intel_dp_short_pulse(struct intel_dp *intel_dp) sink_irq_vector); if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST) - DRM_DEBUG_DRIVER("Test request in short pulse not handled\n"); + intel_dp_handle_test_request(intel_dp); if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ)) DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n"); } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Disable the Link training automation support
Kernel does not have automation support for DP compliance Link training tests. So the Link Training test handler should return a TEST_NAK. Signed-off-by: Manasi Navare--- drivers/gpu/drm/i915/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 19a95ed..0961f22 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4011,7 +4011,7 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 *sink_irq_vector) static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp) { - uint8_t test_result = DP_TEST_ACK; + uint8_t test_result = DP_TEST_NAK; return test_result; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation
This is the userspace component of the Displayport Compliance testing software required for compliance testing of the I915 Display Port driver. This must be running in order to successfully complete Display Port compliance testing. This app and the kernel code that accompanies it has been written to satify the requirements of the Displayport Link CTS 1.2 rev1.1 specification from VESA. Note that this application does not support eDP compliance testing. This utility ahs an automation support for the EDID tests (4.2.2.3 - 4.2.2.6) and Video Pattern generation tests (400.3.3.1) from CTS specification 1.2 Rev 1.1. Currently the video pattern automation has been explicitly disabled until the link training automation is fully supported in the kernel. The Linux DUT running this utility must be in text (console) mode and cannot have any other display manager running. Since this uses sysfs nodes for kernel interaction, this utility should be run as Root. Once this user application is up and running, waiting for test requests, the test appliance software on the windows host can now be used to execute the compliance tests. This app is based on some prior work done in April 2015 (by Todd Previte) Signed-off-by: Todd Previte Signed-off-by: Manasi Navare --- tools/Makefile.sources |1 + tools/intel_dp_compliance.c | 1091 +++ 2 files changed, 1092 insertions(+) create mode 100644 tools/intel_dp_compliance.c diff --git a/tools/Makefile.sources b/tools/Makefile.sources index 5d5958d..3054856 100644 --- a/tools/Makefile.sources +++ b/tools/Makefile.sources @@ -13,6 +13,7 @@ bin_PROGRAMS =\ intel_bios_reader \ intel_display_crc \ intel_display_poller\ + intel_dp_compliance \ intel_dump_decode \ intel_error_decode \ intel_forcewaked\ diff --git a/tools/intel_dp_compliance.c b/tools/intel_dp_compliance.c new file mode 100644 index 000..f3449e2 --- /dev/null +++ b/tools/intel_dp_compliance.c @@ -0,0 +1,1091 @@ +/* + * Displayport Compliance Testing Application + * + * This is the userspace component of the Displayport Compliance testing + * software required for compliance testing of the I915 Display Port driver. + * This must be running in order to successfully complete Display Port + * compliance testing. This app and the kernel code that accompanies it has been + * written to satify the requirements of the Displayport Link CTS 1.2 rev1.1 + * specification from VESA. Note that this application does not support eDP + * compliance testing. + * + * Complaince Testing requires several components: + * - A kernel build that contains the patch set for DP compliance support + * Make sure it has the EDID compliance automation patch + * - A Displayport Compliance Testing appliance such as Unigraf-DPR120 + * - This user application + * - A windows host machine to run the DPR test software + * - Root access on the DUT due to the use of sysfs utility + * + * Test Setup: + * It is strongly recommended that the windows host, test appliance and DUT + * be freshly restarted before any testing begins to ensure that any previous + * configurations and settings will not interfere with test process. Refer to + * the test appliance documentation for setup, software installation and + * operation specific to that device. + * + * The Linux DUT must be in text (console) mode and cannot have any other + * display manager running. You must be logged in as root to run this user app. + * Once the user application is up and running, waiting for test requests, the + * software on the windows host can now be used to execute the compliance tests. + * + * This userspace application supports following tests from the DP CTS Spec + * Rev 1.1: + * - EDID Tests: Supports EDID read (4.2.2.3),EDID Read failure and corruption + * detection tests (4.2.2.4, 4.2.2.5, 4.2.2.6) + * - Video Pattern generation tests: This supports only the 24 and 18bpp color + * ramp test pattern (400.3.3.1). + * + * Connections (required): + * - Test Appliance connected to the external Displayport connector on the DUT + * - Test Appliance Monitor Out connected to Displayport connector on the + * monitor + * - Test appliance connected to the Windows Host via USB + * + * Debugfs Files: + * The file root for all the debugfs file: + * /sys/kernel/debug/dri/0/ + * + * The specific files are as follows: + * + * i915_dp_test_active + * A simple flag that indicates whether or not compliance testing is currently + * active in the kernel. This flag is polled by userspace and once set, invokes + * the test handler in the user app.This flag is set by the test handler in the + * kernel after reading the registers requested by the test appliance. + * + *
[Intel-gfx] [PATCH v2 1/2] drm/i915/execlists: Refactor common engine setup
Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set together. v3: Sanitize the engine's IMR to disable any potential interrupt before we are ready (enabled in init_hw). Signed-off-by: Chris WilsonCc: Tvrtko Ursulin Cc: Dave Gordon --- drivers/gpu/drm/i915/intel_lrc.c | 180 +-- 1 file changed, 97 insertions(+), 83 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index d8763524319d..8106316ce56f 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1918,8 +1918,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs *engine) } static void -logical_ring_default_vfuncs(struct drm_device *dev, - struct intel_engine_cs *engine) +logical_ring_default_vfuncs(struct intel_engine_cs *engine) { /* Default vfuncs which can be overriden by each engine. */ engine->init_hw = gen8_init_common_ring; @@ -1930,7 +1929,7 @@ logical_ring_default_vfuncs(struct drm_device *dev, engine->emit_bb_start = gen8_emit_bb_start; engine->get_seqno = gen8_get_seqno; engine->set_seqno = gen8_set_seqno; - if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) { + if (IS_BXT_REVID(engine->dev, 0, BXT_REVID_A1)) { engine->irq_seqno_barrier = bxt_a_seqno_barrier; engine->set_seqno = bxt_a_set_seqno; } @@ -1941,6 +1940,7 @@ logical_ring_default_irqs(struct intel_engine_cs *engine, unsigned shift) { engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT << shift; engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift; + init_waitqueue_head(>irq_queue); } static int @@ -1961,31 +1961,72 @@ lrc_setup_hws(struct intel_engine_cs *engine, return 0; } -static int -logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine) +static const struct logical_ring_info { + const char *name; + unsigned exec_id; + unsigned guc_id; + u32 mmio_base; + unsigned irq_shift; +} logical_rings[] = { + [RCS] = { + .name = "render ring", + .exec_id = I915_EXEC_RENDER, + .guc_id = GUC_RENDER_ENGINE, + .mmio_base = RENDER_RING_BASE, + .irq_shift = GEN8_RCS_IRQ_SHIFT, + }, + [BCS] = { + .name = "blitter ring", + .exec_id = I915_EXEC_BLT, + .guc_id = GUC_BLITTER_ENGINE, + .mmio_base = BLT_RING_BASE, + .irq_shift = GEN8_BCS_IRQ_SHIFT, + }, + [VCS] = { + .name = "bsd ring", + .exec_id = I915_EXEC_BSD, + .guc_id = GUC_VIDEO_ENGINE, + .mmio_base = GEN6_BSD_RING_BASE, + .irq_shift = GEN8_VCS1_IRQ_SHIFT, + }, + [VCS2] = { + .name = "bsd2 ring", + .exec_id = I915_EXEC_BSD, + .guc_id = GUC_VIDEO_ENGINE2, + .mmio_base = GEN8_BSD2_RING_BASE, + .irq_shift = GEN8_VCS2_IRQ_SHIFT, + }, + [VECS] = { + .name = "video enhancement ring", + .exec_id = I915_EXEC_VEBOX, + .guc_id = GUC_VIDEOENHANCE_ENGINE, + .mmio_base = VEBOX_RING_BASE, + .irq_shift = GEN8_VECS_IRQ_SHIFT, + }, +}; + +static struct intel_engine_cs * +logical_ring_setup(struct drm_device *dev, enum intel_engine_id id) { + const struct logical_ring_info *info = _rings[id]; struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_context *dctx = dev_priv->kernel_context; + struct intel_engine_cs *engine = _priv->engine[id]; enum forcewake_domains fw_domains; - int ret; - /* Intentionally left blank. */ - engine->buffer = NULL; + engine->id = id; + engine->name = info->name; + engine->exec_id = info->exec_id; + engine->guc_id = info->guc_id; + engine->mmio_base = info->mmio_base; - engine->dev = dev; - INIT_LIST_HEAD(>active_list); - INIT_LIST_HEAD(>request_list); - i915_gem_batch_pool_init(dev, >batch_pool); - init_waitqueue_head(>irq_queue); + /* disable interrupts to this engine before we install ourselves */ + I915_WRITE_IMR(engine, ~0); + POSTING_READ(RING_IMR(engine->mmio_base)); - INIT_LIST_HEAD(>buffers); - INIT_LIST_HEAD(>execlist_queue); - spin_lock_init(>execlist_lock); - - tasklet_init(>irq_tasklet, -intel_lrc_irq_handler, (unsigned long)engine); + engine->dev = dev; - logical_ring_init_platform_invariants(engine); + /*
Re: [Intel-gfx] [PATCH v2 06/10] drm/i915: Enable i915 perf stream for Haswell OA unit
> + bo = i915_gem_object_create(dev_priv->dev, OA_BUFFER_SIZE); > + if (bo == NULL) { IS_ERR() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/10] drm/i915: Add more Haswell OA metric sets
This adds 'compute', 'compute extended', 'memory reads', 'memory writes' and 'sampler balance' metric sets for Haswell. Signed-off-by: Robert Bragg--- drivers/gpu/drm/i915/i915_oa_hsw.c | 483 - 1 file changed, 482 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c b/drivers/gpu/drm/i915/i915_oa_hsw.c index 3aa22eb..4a2de8a 100644 --- a/drivers/gpu/drm/i915/i915_oa_hsw.c +++ b/drivers/gpu/drm/i915/i915_oa_hsw.c @@ -30,9 +30,14 @@ enum metric_set_id { METRIC_SET_ID_RENDER_BASIC = 1, + METRIC_SET_ID_COMPUTE_BASIC, + METRIC_SET_ID_COMPUTE_EXTENDED, + METRIC_SET_ID_MEMORY_READS, + METRIC_SET_ID_MEMORY_WRITES, + METRIC_SET_ID_SAMPLER_BALANCE, }; -int i915_oa_n_builtin_metric_sets_hsw = 1; +int i915_oa_n_builtin_metric_sets_hsw = 6; static const struct i915_oa_reg b_counter_config_render_basic[] = { { _MMIO(0x2724), 0x0080 }, @@ -118,6 +123,332 @@ static int select_render_basic_config(struct drm_i915_private *dev_priv) return 0; } +static const struct i915_oa_reg b_counter_config_compute_basic[] = { + { _MMIO(0x2710), 0x }, + { _MMIO(0x2714), 0x0080 }, + { _MMIO(0x2718), 0x }, + { _MMIO(0x271C), 0x }, + { _MMIO(0x2720), 0x }, + { _MMIO(0x2724), 0x0080 }, + { _MMIO(0x2728), 0x }, + { _MMIO(0x272C), 0x }, + { _MMIO(0x2740), 0x }, + { _MMIO(0x2744), 0x }, + { _MMIO(0x2748), 0x }, + { _MMIO(0x274C), 0x }, + { _MMIO(0x2750), 0x }, + { _MMIO(0x2754), 0x }, + { _MMIO(0x2758), 0x }, + { _MMIO(0x275C), 0x }, +}; + +static const struct i915_oa_reg mux_config_compute_basic[] = { + { _MMIO(0x253A4), 0x }, + { _MMIO(0x2681C), 0x01F00800 }, + { _MMIO(0x26820), 0x1000 }, + { _MMIO(0x2781C), 0x01F00800 }, + { _MMIO(0x26520), 0x0007 }, + { _MMIO(0x265A0), 0x0007 }, + { _MMIO(0x25380), 0x0010 }, + { _MMIO(0x2538C), 0x0030 }, + { _MMIO(0x25384), 0xAA8A }, + { _MMIO(0x25404), 0x }, + { _MMIO(0x26800), 0x4202 }, + { _MMIO(0x26808), 0x00605817 }, + { _MMIO(0x2680C), 0x10001005 }, + { _MMIO(0x26804), 0x }, + { _MMIO(0x27800), 0x0102 }, + { _MMIO(0x27808), 0x0C0701E0 }, + { _MMIO(0x2780C), 0x000200A0 }, + { _MMIO(0x27804), 0x }, + { _MMIO(0x26484), 0x4400 }, + { _MMIO(0x26704), 0x4400 }, + { _MMIO(0x26500), 0x0006 }, + { _MMIO(0x26510), 0x0001 }, + { _MMIO(0x26504), 0x8800 }, + { _MMIO(0x26580), 0x0006 }, + { _MMIO(0x26590), 0x0020 }, + { _MMIO(0x26584), 0x }, + { _MMIO(0x26104), 0x5582 }, + { _MMIO(0x26184), 0xAA86 }, + { _MMIO(0x25420), 0x08320C83 }, + { _MMIO(0x25424), 0x06820C83 }, + { _MMIO(0x2541C), 0x }, + { _MMIO(0x25428), 0x0C03 }, +}; + +static int select_compute_basic_config(struct drm_i915_private *dev_priv) +{ + dev_priv->perf.oa.mux_regs = + mux_config_compute_basic; + dev_priv->perf.oa.mux_regs_len = + ARRAY_SIZE(mux_config_compute_basic); + + dev_priv->perf.oa.b_counter_regs = + b_counter_config_compute_basic; + dev_priv->perf.oa.b_counter_regs_len = + ARRAY_SIZE(b_counter_config_compute_basic); + + return 0; +} + +static const struct i915_oa_reg b_counter_config_compute_extended[] = { + { _MMIO(0x2724), 0xf080 }, + { _MMIO(0x2720), 0x }, + { _MMIO(0x2714), 0xf080 }, + { _MMIO(0x2710), 0x }, + { _MMIO(0x2770), 0x0007fe2a }, + { _MMIO(0x2774), 0xff00 }, + { _MMIO(0x2778), 0x0007fe6a }, + { _MMIO(0x277c), 0xff00 }, + { _MMIO(0x2780), 0x0007fe92 }, + { _MMIO(0x2784), 0xff00 }, + { _MMIO(0x2788), 0x0007fea2 }, + { _MMIO(0x278c), 0xff00 }, + { _MMIO(0x2790), 0x0007fe32 }, + { _MMIO(0x2794), 0xff00 }, + { _MMIO(0x2798), 0x0007fe9a }, + { _MMIO(0x279c), 0xff00 }, + { _MMIO(0x27a0), 0x0007ff23 }, + { _MMIO(0x27a4), 0xff00 }, + { _MMIO(0x27a8), 0x0007fff3 }, + { _MMIO(0x27ac), 0xfffe }, +}; + +static const struct i915_oa_reg mux_config_compute_extended[] = { + { _MMIO(0x2681C), 0x3EB00800 }, + { _MMIO(0x26820), 0x0090 }, + { _MMIO(0x25384), 0x02AA }, + { _MMIO(0x25404), 0x03FF }, + { _MMIO(0x26800), 0x00142284 }, + { _MMIO(0x26808), 0x0E629062 }, + { _MMIO(0x2680C), 0x3F6F55CB }, + { _MMIO(0x26810), 0x0014 }, + { _MMIO(0x26804), 0x }, + { _MMIO(0x26104), 0x02AA }, + { _MMIO(0x26184), 0x02AA }, +
[Intel-gfx] [PATCH v2 09/10] drm/i915: add oa_event_min_timer_exponent sysctl
The minimal sampling period is now configurable via a dev.i915.oa_min_timer_exponent sysctl parameter. Following the precedent set by perf, the default is the minimum that won't (on its own) exceed the default kernel.perf_event_max_sample_rate default of 10 samples/s. Signed-off-by: Robert Bragg--- drivers/gpu/drm/i915/i915_perf.c | 42 1 file changed, 30 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index 3789378..045ffe8 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -71,6 +71,23 @@ static u32 i915_perf_stream_paranoid = true; */ #define OA_EXPONENT_MAX 31 +/* for sysctl proc_dointvec_minmax of i915_oa_min_timer_exponent */ +static int zero; +static int oa_exponent_max = OA_EXPONENT_MAX; + +/* Theoretically we can program the OA unit to sample every 160ns but don't + * allow that by default unless root... + * + * The period is derived from the exponent as: + * + * period = 80ns * 2^(exponent + 1) + * + * Referring to perf's kernel.perf_event_max_sample_rate for a precedent + * (10 by default); with an OA exponent of 6 we get a period of 10.240 + * microseconds - just under 10Hz + */ +static u32 i915_oa_min_timer_exponent = 6; + /* XXX: beware if future OA HW adds new report formats that the current * code assumes all reports have a power-of-two size and ~(size - 1) can * be used as a mask to align the OA tail pointer. @@ -1229,21 +1246,13 @@ static int read_properties_unlocked(struct drm_i915_private *dev_priv, return -EINVAL; } - /* NB: The exponent represents a period as follows: -* -* 80ns * 2^(period_exponent + 1) -* -* Theoretically we can program the OA unit to sample + /* Theoretically we can program the OA unit to sample * every 160ns but don't allow that by default unless * root. -* -* Referring to perf's -* kernel.perf_event_max_sample_rate for a precedent -* (10 by default); with an OA exponent of 6 we get -* a period of 10.240 microseconds -just under 10Hz */ - if (value < 6 && !capable(CAP_SYS_ADMIN)) { - DRM_ERROR("Sampling period too high without root privileges\n"); + if (value < i915_oa_min_timer_exponent && + !capable(CAP_SYS_ADMIN)) { + DRM_ERROR("OA timer exponent too low without root privileges\n"); return -EACCES; } @@ -1305,6 +1314,15 @@ static struct ctl_table oa_table[] = { .mode = 0644, .proc_handler = proc_dointvec, }, + { +.procname = "oa_min_timer_exponent", +.data = _oa_min_timer_exponent, +.maxlen = sizeof(i915_oa_min_timer_exponent), +.mode = 0644, +.proc_handler = proc_dointvec_minmax, +.extra1 = , +.extra2 = _exponent_max, +}, {} }; -- 2.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/10] drm/i915: advertise available metrics via sysfs
Each metric set is given a sysfs entry like: /sys/class/drm/card0/metrics//id This allows userspace to enumerate the specific sets that are available for the current system. The 'id' file contains an unsigned integer that can be used to open the associated metric set via DRM_IOCTL_I915_PERF_OPEN. The is a globally unique ID for a specific OA unit configuration that can be reliably used as a key to lookup corresponding counter meta data and normalization equations. Signed-off-by: Robert Bragg--- drivers/gpu/drm/i915/i915_drv.h| 2 ++ drivers/gpu/drm/i915/i915_oa_hsw.c | 45 ++ drivers/gpu/drm/i915/i915_oa_hsw.h | 4 drivers/gpu/drm/i915/i915_perf.c | 18 ++- 4 files changed, 68 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 602eb03..68fdf1a 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2097,6 +2097,8 @@ struct drm_i915_private { struct { bool initialized; + struct kobject *metrics_kobj; + struct mutex lock; struct list_head streams; diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c b/drivers/gpu/drm/i915/i915_oa_hsw.c index 5472aa0..3aa22eb 100644 --- a/drivers/gpu/drm/i915/i915_oa_hsw.c +++ b/drivers/gpu/drm/i915/i915_oa_hsw.c @@ -24,6 +24,8 @@ * */ +#include + #include "i915_drv.h" enum metric_set_id { @@ -130,3 +132,46 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private *dev_priv) return -ENODEV; } } + +static ssize_t +show_render_basic_id(struct device *kdev, struct device_attribute *attr, char *buf) +{ + return sprintf(buf, "%d\n", METRIC_SET_ID_RENDER_BASIC); +} + +static struct device_attribute dev_attr_render_basic_id = { + .attr = { .name = "id", .mode = S_IRUGO }, + .show = show_render_basic_id, + .store = NULL, +}; + +static struct attribute *attrs_render_basic[] = { + _attr_render_basic_id.attr, + NULL, +}; + +static struct attribute_group group_render_basic = { + .name = "403d8832-1a27-4aa6-a64e-f5389ce7b212", + .attrs = attrs_render_basic, +}; + +int +i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv) +{ + int ret; + + ret = sysfs_create_group(dev_priv->perf.metrics_kobj, _render_basic); + if (ret) + goto error_render_basic; + + return 0; + +error_render_basic: + return ret; +} + +void +i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv) +{ + sysfs_remove_group(dev_priv->perf.metrics_kobj, _render_basic); +} diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.h b/drivers/gpu/drm/i915/i915_oa_hsw.h index b618a1f..e4ba89d 100644 --- a/drivers/gpu/drm/i915/i915_oa_hsw.h +++ b/drivers/gpu/drm/i915/i915_oa_hsw.h @@ -31,4 +31,8 @@ extern int i915_oa_n_builtin_metric_sets_hsw; extern int i915_oa_select_metric_set_hsw(struct drm_i915_private *dev_priv); +extern int i915_perf_init_sysfs_hsw(struct drm_i915_private *dev_priv); + +extern void i915_perf_deinit_sysfs_hsw(struct drm_i915_private *dev_priv); + #endif diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index 094c6ed..ef0a240 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -1295,6 +1295,11 @@ void i915_perf_init(struct drm_device *dev) if (!IS_HASWELL(dev)) return; + dev_priv->perf.metrics_kobj = + kobject_create_and_add("metrics", >primary->kdev->kobj); + if (!dev_priv->perf.metrics_kobj) + return; + hrtimer_init(_priv->perf.oa.poll_check_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); dev_priv->perf.oa.poll_check_timer.function = oa_poll_check_timer_cb; @@ -1322,9 +1327,15 @@ void i915_perf_init(struct drm_device *dev) dev_priv->perf.oa.n_builtin_sets = i915_oa_n_builtin_metric_sets_hsw; - dev_priv->perf.oa.oa_formats = hsw_oa_formats; + if (i915_perf_init_sysfs_hsw(dev_priv)) { + kobject_put(dev_priv->perf.metrics_kobj); + dev_priv->perf.metrics_kobj = NULL; + return; + } dev_priv->perf.initialized = true; + + return; } void i915_perf_fini(struct drm_device *dev) @@ -1334,6 +1345,11 @@ void i915_perf_fini(struct drm_device *dev) if (!dev_priv->perf.initialized) return; + i915_perf_deinit_sysfs_hsw(dev_priv); + + kobject_put(dev_priv->perf.metrics_kobj); + dev_priv->perf.metrics_kobj = NULL; + dev_priv->perf.oa.ops.init_oa_buffer = NULL; dev_priv->perf.initialized = false; -- 2.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/10] drm/i915: Add dev.i915.perf_event_paranoid sysctl option
Consistent with the kernel.perf_event_paranoid sysctl option that can allow non-root users to access system wide cpu metrics, this can optionally allow non-root users to access system wide OA counter metrics from Gen graphics hardware. Signed-off-by: Robert Bragg--- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_perf.c | 46 +++- 2 files changed, 46 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 68fdf1a..91a88fe 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2098,6 +2098,7 @@ struct drm_i915_private { bool initialized; struct kobject *metrics_kobj; + struct ctl_table_header *sysctl_header; struct mutex lock; struct list_head streams; diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index ef0a240..3789378 100644 --- a/drivers/gpu/drm/i915/i915_perf.c +++ b/drivers/gpu/drm/i915/i915_perf.c @@ -59,6 +59,8 @@ #define POLL_FREQUENCY 200 #define POLL_PERIOD (NSEC_PER_SEC / POLL_FREQUENCY) +static u32 i915_perf_stream_paranoid = true; + /* The maximum exponent the hardware accepts is 63 (essentially it selects one * of the 64bit timestamp bits to trigger reports from) but there's currently * no known use case for sampling as infrequently as once per 47 thousand years. @@ -1084,7 +1086,13 @@ int i915_perf_open_ioctl_locked(struct drm_device *dev, } } - if (!specific_ctx && !capable(CAP_SYS_ADMIN)) { + /* Similar to perf's kernel.perf_paranoid_cpu sysctl option +* we check a dev.i915.perf_stream_paranoid sysctl option +* to determine if it's ok to access system wide OA counters +* without CAP_SYS_ADMIN privileges. +*/ + if (!specific_ctx && + i915_perf_stream_paranoid && !capable(CAP_SYS_ADMIN)) { DRM_ERROR("Insufficient privileges to open system-wide i915 perf stream\n"); ret = -EACCES; goto err_ctx; @@ -1288,6 +1296,38 @@ int i915_perf_open_ioctl(struct drm_device *dev, void *data, return ret; } + +static struct ctl_table oa_table[] = { + { +.procname = "perf_stream_paranoid", +.data = _perf_stream_paranoid, +.maxlen = sizeof(i915_perf_stream_paranoid), +.mode = 0644, +.proc_handler = proc_dointvec, +}, + {} +}; + +static struct ctl_table i915_root[] = { + { +.procname = "i915", +.maxlen = 0, +.mode = 0555, +.child = oa_table, +}, + {} +}; + +static struct ctl_table dev_root[] = { + { +.procname = "dev", +.maxlen = 0, +.mode = 0555, +.child = i915_root, +}, + {} +}; + void i915_perf_init(struct drm_device *dev) { struct drm_i915_private *dev_priv = to_i915(dev); @@ -1333,6 +1373,8 @@ void i915_perf_init(struct drm_device *dev) return; } + dev_priv->perf.sysctl_header = register_sysctl_table(dev_root); + dev_priv->perf.initialized = true; return; @@ -1345,6 +1387,8 @@ void i915_perf_fini(struct drm_device *dev) if (!dev_priv->perf.initialized) return; + unregister_sysctl_table(dev_priv->perf.sysctl_header); + i915_perf_deinit_sysfs_hsw(dev_priv); kobject_put(dev_priv->perf.metrics_kobj); -- 2.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/10] drm/i915: Add 'render basic' Haswell OA unit config
Adds a static OA unit, MUX + B Counter configuration for basic render metrics on Haswell. This is autogenerated from an internal XML description of metric sets. Signed-off-by: Robert Bragg--- drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_drv.h| 14 drivers/gpu/drm/i915/i915_oa_hsw.c | 132 + drivers/gpu/drm/i915/i915_oa_hsw.h | 34 ++ 4 files changed, 182 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index d90d907..5293fc7 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -100,7 +100,8 @@ i915-y += dvo_ch7017.o \ i915-y += i915_vgpu.o # perf code -i915-y += i915_perf.o +i915-y += i915_perf.o \ + i915_oa_hsw.o # legacy horrors i915-y += i915_dma.o diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 3d2450f..f85fd72 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1712,6 +1712,11 @@ struct intel_wm_config { bool sprites_scaled; }; +struct i915_oa_reg { + i915_reg_t addr; + u32 value; +}; + struct i915_perf_read_state { int count; ssize_t read; @@ -2073,6 +2078,15 @@ struct drm_i915_private { bool initialized; struct mutex lock; struct list_head streams; + + struct { + u32 metrics_set; + + const struct i915_oa_reg *mux_regs; + int mux_regs_len; + const struct i915_oa_reg *b_counter_regs; + int b_counter_regs_len; + } oa; } perf; /* Abstract the submission mechanism (legacy ringbuffer or execlists) away */ diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c b/drivers/gpu/drm/i915/i915_oa_hsw.c new file mode 100644 index 000..5472aa0 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_oa_hsw.c @@ -0,0 +1,132 @@ +/* + * Autogenerated file, DO NOT EDIT manually! + * + * Copyright (c) 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 "i915_drv.h" + +enum metric_set_id { + METRIC_SET_ID_RENDER_BASIC = 1, +}; + +int i915_oa_n_builtin_metric_sets_hsw = 1; + +static const struct i915_oa_reg b_counter_config_render_basic[] = { + { _MMIO(0x2724), 0x0080 }, + { _MMIO(0x2720), 0x }, + { _MMIO(0x2714), 0x0080 }, + { _MMIO(0x2710), 0x }, +}; + +static const struct i915_oa_reg mux_config_render_basic[] = { + { _MMIO(0x253A4), 0x0160 }, + { _MMIO(0x25440), 0x0010 }, + { _MMIO(0x25128), 0x }, + { _MMIO(0x2691C), 0x0800 }, + { _MMIO(0x26AA0), 0x0150 }, + { _MMIO(0x26B9C), 0x6000 }, + { _MMIO(0x2791C), 0x0800 }, + { _MMIO(0x27AA0), 0x0150 }, + { _MMIO(0x27B9C), 0x6000 }, + { _MMIO(0x2641C), 0x0400 }, + { _MMIO(0x25380), 0x0010 }, + { _MMIO(0x2538C), 0x }, + { _MMIO(0x25384), 0x0800 }, + { _MMIO(0x25400), 0x0004 }, + { _MMIO(0x2540C), 0x06029000 }, + { _MMIO(0x25410), 0x0002 }, + { _MMIO(0x25404), 0x5C30 }, + { _MMIO(0x25100), 0x0016 }, + { _MMIO(0x25110), 0x0400 }, + { _MMIO(0x25104), 0x }, + { _MMIO(0x26804), 0x1211 }, + { _MMIO(0x26884), 0x0100 }, + { _MMIO(0x26900), 0x0002 }, + { _MMIO(0x26908), 0x0070 }, + { _MMIO(0x26904), 0x }, + { _MMIO(0x26984), 0x1022 }, + { _MMIO(0x26A04), 0x0011 }, + { _MMIO(0x26A80), 0x0006 }, + { _MMIO(0x26A88), 0x0C02 }, +
[Intel-gfx] [PATCH v2 03/10] drm/i915: return EACCES for check_cmd() failures
check_cmd() is checking whether a command adheres to certain restrictions that ensure it's safe to execute within a privileged batch buffer. Returning false implies a privilege problem, not that the command is invalid. The distinction makes the difference between allowing the buffer to be executed as an unprivileged batch buffer or returning an EINVAL error to userspace without executing anything. In a case where userspace may want to test whether it can successfully write to a register that needs privileges the distinction may be important and an EINVAL error may be considered fatal. In particular this is currently true for Mesa, which includes a test for whether OACONTROL can be written too, but Mesa treats any error when flushing a batch buffer as fatal, calling exit(1). As it is currently Mesa can gracefully handle a failure to write to OACONTROL if the command parser is disabled, but if we were to remove OACONTROL from the parser's whitelist then the returned EINVAL would break Mesa applications as they attempt an OACONTROL write. Signed-off-by: Robert Bragg--- drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c index 035f2dd..5724d80 100644 --- a/drivers/gpu/drm/i915/i915_cmd_parser.c +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c @@ -1245,7 +1245,7 @@ int i915_parse_cmds(struct intel_engine_cs *engine, if (!check_cmd(engine, desc, cmd, length, is_master, _set)) { - ret = -EINVAL; + ret = -EACCES; break; } -- 2.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/10] drm/i915: Add i915 perf infrastructure
Adds base i915 perf infrastructure for Gen performance metrics. This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 properties to configure a stream of metrics and returns a new fd usable with standard VFS system calls including read() to read typed and sized records; ioctl() to enable or disable capture and poll() to wait for data. A stream is opened something like: uint64_t properties[] = { /* Single context sampling */ DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle, /* Include OA reports in samples */ DRM_I915_PERF_PROP_SAMPLE_OA, true, /* OA unit configuration */ DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id, DRM_I915_PERF_PROP_OA_FORMAT, report_format, DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent, }; struct drm_i915_perf_open_param parm = { .flags = I915_PERF_FLAG_FD_CLOEXEC | I915_PERF_FLAG_FD_NONBLOCK | I915_PERF_FLAG_DISABLED, .properties_ptr = (uint64_t)properties, .num_properties = sizeof(properties) / 16, }; int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ); Records read all start with a common { type, size } header with DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records contain an extensible number of fields and it's the DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that determine what's included in every sample. No specific streams are supported yet so any attempt to open a stream will return an error. Signed-off-by: Robert Bragg--- drivers/gpu/drm/i915/Makefile| 3 + drivers/gpu/drm/i915/i915_dma.c | 8 + drivers/gpu/drm/i915/i915_drv.h | 92 + drivers/gpu/drm/i915/i915_perf.c | 431 +++ include/uapi/drm/i915_drm.h | 67 ++ 5 files changed, 601 insertions(+) create mode 100644 drivers/gpu/drm/i915/i915_perf.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 723c502..d90d907 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -99,6 +99,9 @@ i915-y += dvo_ch7017.o \ # virtual gpu code i915-y += i915_vgpu.o +# perf code +i915-y += i915_perf.o + # legacy horrors i915-y += i915_dma.o diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index f69330c..89cec21 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1074,6 +1074,11 @@ static int i915_driver_init_early(struct drm_i915_private *dev_priv, if (ret < 0) return ret; + /* Must at least be initialized before trying to pin any context +* which i915_perf hooks into. +*/ + i915_perf_init(dev); + /* This must be called before any calls to HAS_PCH_* */ intel_detect_pch(dev); @@ -1460,6 +1465,8 @@ int i915_driver_unload(struct drm_device *dev) i915_driver_unregister(dev_priv); + i915_perf_fini(dev); + drm_vblank_cleanup(dev); intel_modeset_cleanup(dev); @@ -1611,6 +1618,7 @@ const struct drm_ioctl_desc i915_ioctls[] = { DRM_IOCTL_DEF_DRV(I915_GEM_USERPTR, i915_gem_userptr_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_GETPARAM, i915_gem_context_getparam_ioctl, DRM_RENDER_ALLOW), DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_SETPARAM, i915_gem_context_setparam_ioctl, DRM_RENDER_ALLOW), + DRM_IOCTL_DEF_DRV(I915_PERF_OPEN, i915_perf_open_ioctl, DRM_RENDER_ALLOW), }; int i915_max_ioctl = ARRAY_SIZE(i915_ioctls); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index e2abbcc..3d2450f 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1712,6 +1712,85 @@ struct intel_wm_config { bool sprites_scaled; }; +struct i915_perf_read_state { + int count; + ssize_t read; + char __user *buf; +}; + +struct i915_perf_stream; + +struct i915_perf_stream_ops { + /* Enables the collection of HW samples, either in response to +* I915_PERF_IOCTL_ENABLE or implicitly called when stream is +* opened without I915_PERF_FLAG_DISABLED. +*/ + void (*enable)(struct i915_perf_stream *stream); + + /* Disables the collection of HW samples, either in response to +* I915_PERF_IOCTL_DISABLE or implicitly called before +* destroying the stream. +*/ + void (*disable)(struct i915_perf_stream *stream); + + /* Return: true if any i915 perf records are ready to read() +* for this stream. +*/ + bool (*can_read)(struct i915_perf_stream *stream); + + /* Call poll_wait, passing a wait queue that will be woken +* once there is something ready to read() for the stream +*/ + void (*poll_wait)(struct i915_perf_stream *stream, + struct file *file, + poll_table *wait); +
[Intel-gfx] [PATCH v2 04/10] drm/i915: don't whitelist oacontrol in cmd parser
Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable Mesa to expose OA counters via the INTEL_performance_query extension, but the current implementation based on programming OACONTROL via a batch buffer isn't able to report useable data without a more complete OA unit configuration. Mesa handles the possibility that writes to OACONTROL may not be allowed and so only advertises the extension after explicitly testing that a write to OACONTROL succeeds. Based on this; removing OACONTROL from the whitelist should be ok for userspace. Removing this simplifies adding a new kernel api for configuring the OA unit without needing to consider the possibility that userspace might trample on OACONTROL state which we'd like to start managing within the kernel instead. In particular running any Mesa based GL application currently results in clearing OACONTROL when initializing which would disable the capturing of metrics. Signed-off-by: Robert Bragg--- drivers/gpu/drm/i915/i915_cmd_parser.c | 33 ++--- 1 file changed, 2 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c index 5724d80..ff2b57b 100644 --- a/drivers/gpu/drm/i915/i915_cmd_parser.c +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c @@ -445,7 +445,6 @@ static const struct drm_i915_reg_descriptor gen7_render_regs[] = { REG64(PS_INVOCATION_COUNT), REG64(PS_DEPTH_COUNT), REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE), - REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */ REG64(MI_PREDICATE_SRC0), REG64(MI_PREDICATE_SRC1), REG32(GEN7_3DPRIM_END_OFFSET), @@ -1044,8 +1043,7 @@ bool i915_needs_cmd_parser(struct intel_engine_cs *engine) static bool check_cmd(const struct intel_engine_cs *engine, const struct drm_i915_cmd_descriptor *desc, const u32 *cmd, u32 length, - const bool is_master, - bool *oacontrol_set) + const bool is_master) { if (desc->flags & CMD_DESC_REJECT) { DRM_DEBUG_DRIVER("CMD: Rejected command: 0x%08X\n", *cmd); @@ -1083,26 +1081,6 @@ static bool check_cmd(const struct intel_engine_cs *engine, } /* -* OACONTROL requires some special handling for -* writes. We want to make sure that any batch which -* enables OA also disables it before the end of the -* batch. The goal is to prevent one process from -* snooping on the perf data from another process. To do -* that, we need to check the value that will be written -* to the register. Hence, limit OACONTROL writes to -* only MI_LOAD_REGISTER_IMM commands. -*/ - if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) { - if (desc->cmd.value == MI_LOAD_REGISTER_MEM) { - DRM_DEBUG_DRIVER("CMD: Rejected LRM to OACONTROL\n"); - return false; - } - - if (desc->cmd.value == MI_LOAD_REGISTER_IMM(1)) - *oacontrol_set = (cmd[offset + 1] != 0); - } - - /* * Check the value written to the register against the * allowed mask/value pair given in the whitelist entry. */ @@ -1186,7 +1164,6 @@ int i915_parse_cmds(struct intel_engine_cs *engine, { u32 *cmd, *batch_base, *batch_end; struct drm_i915_cmd_descriptor default_desc = { 0 }; - bool oacontrol_set = false; /* OACONTROL tracking. See check_cmd() */ int ret = 0; batch_base = copy_batch(shadow_batch_obj, batch_obj, @@ -1243,8 +1220,7 @@ int i915_parse_cmds(struct intel_engine_cs *engine, break; } - if (!check_cmd(engine, desc, cmd, length, is_master, - _set)) { + if (!check_cmd(engine, desc, cmd, length, is_master)) { ret = -EACCES; break; } @@ -1252,11 +1228,6 @@ int i915_parse_cmds(struct intel_engine_cs *engine, cmd += length; } - if (oacontrol_set) { - DRM_DEBUG_DRIVER("CMD: batch set OACONTROL but did not clear it\n"); - ret = -EINVAL; - } - if (cmd >= batch_end) { DRM_DEBUG_DRIVER("CMD: Got to the end of the buffer w/o a BBE cmd!\n");
[Intel-gfx] [PATCH v2 00/10] Enable Gen 7 Observation Architecture
Hopefully covers the last issues raised by Chris and addresses the open issue I had with removing OACONTROL from the command parser whitelist. - Robert Robert Bragg (10): drm/i915: Add i915 perf infrastructure drm/i915: rename OACONTROL GEN7_OACONTROL drm/i915: return EACCES for check_cmd() failures drm/i915: don't whitelist oacontrol in cmd parser drm/i915: Add 'render basic' Haswell OA unit config drm/i915: Enable i915 perf stream for Haswell OA unit drm/i915: advertise available metrics via sysfs drm/i915: Add dev.i915.perf_event_paranoid sysctl option drm/i915: add oa_event_min_timer_exponent sysctl drm/i915: Add more Haswell OA metric sets drivers/gpu/drm/i915/Makefile |4 + drivers/gpu/drm/i915/i915_cmd_parser.c | 35 +- drivers/gpu/drm/i915/i915_dma.c |8 + drivers/gpu/drm/i915/i915_drv.h | 161 drivers/gpu/drm/i915/i915_gem_context.c | 24 +- drivers/gpu/drm/i915/i915_oa_hsw.c | 658 ++ drivers/gpu/drm/i915/i915_oa_hsw.h | 38 + drivers/gpu/drm/i915/i915_perf.c| 1418 +++ drivers/gpu/drm/i915/i915_reg.h | 340 +++- include/uapi/drm/i915_drm.h | 133 +++ 10 files changed, 2781 insertions(+), 38 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.c create mode 100644 drivers/gpu/drm/i915/i915_oa_hsw.h create mode 100644 drivers/gpu/drm/i915/i915_perf.c -- 2.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/10] drm/i915: Enable i915 perf stream for Haswell OA unit
Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. Cc: Chris WilsonSigned-off-by: Robert Bragg Signed-off-by: Zhenyu Wang --- drivers/gpu/drm/i915/i915_drv.h | 56 +- drivers/gpu/drm/i915/i915_gem_context.c | 24 +- drivers/gpu/drm/i915/i915_perf.c| 931 +++- drivers/gpu/drm/i915/i915_reg.h | 338 include/uapi/drm/i915_drm.h | 70 ++- 5 files changed, 1399 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index f85fd72..602eb03 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1712,6 +1712,11 @@ struct intel_wm_config { bool sprites_scaled; }; +struct i915_oa_format { + u32 format; + int size; +}; + struct i915_oa_reg { i915_reg_t addr; u32 value; @@ -1789,11 +1794,26 @@ struct i915_perf_stream { struct list_head link; u32 sample_flags; + int sample_size; struct intel_context *ctx; bool enabled; - struct i915_perf_stream_ops *ops; + const struct i915_perf_stream_ops *ops; +}; + +struct i915_oa_ops { + void (*init_oa_buffer)(struct drm_i915_private *dev_priv); + int (*enable_metric_set)(struct drm_i915_private *dev_priv); + void (*disable_metric_set)(struct drm_i915_private *dev_priv); + void (*oa_enable)(struct drm_i915_private *dev_priv); + void (*oa_disable)(struct drm_i915_private *dev_priv); + void (*update_oacontrol)(struct drm_i915_private *dev_priv); + void (*update_hw_ctx_id_locked)(struct drm_i915_private *dev_priv, + u32 ctx_id); + int (*read)(struct i915_perf_stream *stream, + struct i915_perf_read_state *read_state); + bool (*oa_buffer_is_empty)(struct drm_i915_private *dev_priv); }; struct drm_i915_private { @@ -2076,16 +2096,46 @@ struct drm_i915_private { struct { bool initialized; + struct mutex lock; struct list_head streams; + spinlock_t hook_lock; + struct { - u32 metrics_set; + struct i915_perf_stream *exclusive_stream; + + u32 specific_ctx_id; + + struct hrtimer poll_check_timer; + wait_queue_head_t poll_wq; + + bool periodic; + int period_exponent; + int timestamp_frequency; + + int tail_margin; + + int metrics_set; const struct i915_oa_reg *mux_regs; int mux_regs_len; const struct i915_oa_reg *b_counter_regs; int b_counter_regs_len; + + struct { + struct drm_i915_gem_object *obj; + u32 gtt_offset; + u8 *addr; + int format; + int format_size; + } oa_buffer; + + u32 gen7_latched_oastatus1; + + struct i915_oa_ops ops; + const struct i915_oa_format *oa_formats; + int n_builtin_sets; } oa; } perf; @@ -3441,6 +3491,8 @@ int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data, int i915_perf_open_ioctl(struct drm_device *dev, void *data, struct drm_file *file); +void i915_oa_context_pin_notify(struct drm_i915_private *dev_priv, + struct intel_context *context); /* i915_gem_evict.c */ int __must_check i915_gem_evict_something(struct drm_device *dev, diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index b1b704c..4fec631 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -135,6 +135,23 @@ static int get_context_size(struct drm_device *dev) return ret; } +static int i915_gem_context_pin_state(struct drm_device *dev, + struct intel_context *ctx) +{ + int ret; + + BUG_ON(!mutex_is_locked(>struct_mutex)); + + ret = i915_gem_obj_ggtt_pin(ctx->legacy_hw_ctx.rcs_state, + get_context_alignment(dev), 0); + if (ret) + return ret; + + i915_oa_context_pin_notify(dev->dev_private, ctx); + + return 0; +} + static void i915_gem_context_clean(struct intel_context *ctx) {
[Intel-gfx] [PATCH v2 02/10] drm/i915: rename OACONTROL GEN7_OACONTROL
OACONTROL changes quite a bit for gen8, with some bits split out into a per-context OACTXCONTROL register. Rename now before adding more gen7 OA registers Signed-off-by: Robert Bragg--- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c index a337f33..035f2dd 100644 --- a/drivers/gpu/drm/i915/i915_cmd_parser.c +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c @@ -445,7 +445,7 @@ static const struct drm_i915_reg_descriptor gen7_render_regs[] = { REG64(PS_INVOCATION_COUNT), REG64(PS_DEPTH_COUNT), REG64_IDX(RING_TIMESTAMP, RENDER_RING_BASE), - REG32(OACONTROL), /* Only allowed for LRI and SRM. See below. */ + REG32(GEN7_OACONTROL), /* Only allowed for LRI and SRM. See below. */ REG64(MI_PREDICATE_SRC0), REG64(MI_PREDICATE_SRC1), REG32(GEN7_3DPRIM_END_OFFSET), @@ -1092,7 +1092,7 @@ static bool check_cmd(const struct intel_engine_cs *engine, * to the register. Hence, limit OACONTROL writes to * only MI_LOAD_REGISTER_IMM commands. */ - if (reg_addr == i915_mmio_reg_offset(OACONTROL)) { + if (reg_addr == i915_mmio_reg_offset(GEN7_OACONTROL)) { if (desc->cmd.value == MI_LOAD_REGISTER_MEM) { DRM_DEBUG_DRIVER("CMD: Rejected LRM to OACONTROL\n"); return false; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 0a2fd30..11eccf4 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -611,7 +611,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define HSW_CS_GPR(n) _MMIO(0x2600 + (n) * 8) #define HSW_CS_GPR_UDW(n) _MMIO(0x2600 + (n) * 8 + 4) -#define OACONTROL _MMIO(0x2360) +#define GEN7_OACONTROL _MMIO(0x2360) #define _GEN7_PIPEA_DE_LOAD_SL 0x70068 #define _GEN7_PIPEB_DE_LOAD_SL 0x71068 -- 2.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] xserver crash with linux 4.6.0-rc3 and later
On Fri, Apr 29, 2016 at 01:25:30PM -0400, John S Gruber wrote: > Starting with linux 4.6.0-rc3 my Ubuntu Wily system no longer allows logons > from > due to an immediate abort in xserver after just after entering my > userid and password. (lightdm drew the sign on screen OK). > > The xserver problem seems to result from a null reference from > __kgem_retire_rq from package xserver-xorg-video-intel version > 2:2.99.917+git20150808-0ubuntu4. > > Bisecting the kernel I found that this was triggered by commit > 426960bed3217f72a1b7bb94f084d79cc616ec0f. Reverting this commit based on > 4.6-rc5 eliminated my crash. > > The problem was specific to my HP Pavilion laptop with Intel HD 5500 > integrated graphics . A desktop Acer, also using Intel graphics, was > fine. On the laptop it was completely consistent. > > The laptop has: > > 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U > Integrated Graphics (rev 09) (prog-if 00 [VGA controller]) > DeviceName: Intel(R) Graphics GT2 > > Testing the laptop with Ubuntu xenial (with xserver-xorg-video-intel > version 2:2.99.917+git20160325-1ubuntu1) was fine, however. > > Please let me know if this is problematic, and if so, if I should provide > additional information. I don't follow the list. > > -- > > The triggering commit: > > drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids The seeds of that crash were already sown. The error is that on a batch buffer allocation failure, the preallocated failsafe ended up on the request list (which is not supposed to happen and so it runs off the end of the list). commit 69d8edc11173df021aa2e158b2530257113141fd Author: Chris WilsonDate: Fri Aug 7 10:08:17 2015 +0100 sna: Handle batch allocation failure Whilst we currently do not try and submit a failed batch buffer allocation, we still treat it as a valid request. This explodes much later when we inspect the NULL rq->bo. References: https://bugs.freedesktop.org/show_bug.cgi?id=91577 Signed-off-by: Chris Wilson is the cause of the crash, but commit 2d26643cab33a32847afaf13b50d326d09d58bf7 Author: Chris Wilson Date: Fri Nov 13 19:03:36 2015 + sna/dri2: Drop the reference on the fence when complete Fixes regression from commit 8d9e496670f48b4eec64dfe1bcedb49793cf3073 Author: Chris Wilson Date: Wed Jul 22 11:14:01 2015 +0100 sna/dri2: Take over the placeholder vblank After noting the fence was complete, we would clear it. But I forgot that we actually held a reference on to it, and so we would leak the 64k batch, and starve the system of available memory in about 18 minutes of SwapBuffers. Reported-by: Arkadiusz Miskiewicz Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92911 Signed-off-by: Chris Wilson is where the bug began. The kernel just made it easier to hit the pre-existing bugs in userspace. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915/execlists: Refactor common engine setup
== Series Details == Series: series starting with [v2,1/2] drm/i915/execlists: Refactor common engine setup URL : https://patchwork.freedesktop.org/series/6549/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/igb/e1000_82575.o CONMK drivers/tty/vt/consolemap_deftbl.c CC drivers/tty/vt/vt.o CC [M] drivers/net/ethernet/intel/igbvf/mbx.o CC [M] drivers/net/ethernet/intel/igbvf/ethtool.o SHIPPED drivers/tty/vt/defkeymap.c CC drivers/tty/vt/consolemap_deftbl.o CC drivers/tty/vt/defkeymap.o CC [M] drivers/net/ethernet/intel/igb/e1000_mac.o CC [M] drivers/net/ethernet/intel/igbvf/netdev.o CC drivers/usb/host/xhci-pci.o CC [M] drivers/net/ethernet/intel/igb/e1000_nvm.o CC [M] drivers/net/ethernet/intel/igb/e1000_phy.o CC [M] drivers/net/ethernet/intel/igb/e1000_mbx.o CC [M] drivers/net/ethernet/intel/igb/e1000_i210.o CC [M] drivers/net/ethernet/intel/igb/igb_ptp.o CC [M] drivers/net/ethernet/intel/igb/igb_hwmon.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o LD drivers/usb/host/xhci-hcd.o LD drivers/usb/host/built-in.o LD drivers/usb/built-in.o LD drivers/tty/vt/built-in.o LD drivers/tty/built-in.o LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o LD [M] drivers/net/ethernet/intel/igb/igb.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o Makefile:962: recipe for target 'drivers' failed make: *** [drivers] Error 2 Full logs at /archive/deploy/logs/CI_Patchwork_build_2117 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/execlists: Refactor common engine setup
Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set together. v3: Sanitize the engine's IMR to disable any potential interrupt before we are ready (enabled in init_hw). Signed-off-by: Chris WilsonCc: Tvrtko Ursulin Cc: Dave Gordon --- drivers/gpu/drm/i915/intel_lrc.c | 180 +-- 1 file changed, 97 insertions(+), 83 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index d8763524319d..8106316ce56f 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1918,8 +1918,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs *engine) } static void -logical_ring_default_vfuncs(struct drm_device *dev, - struct intel_engine_cs *engine) +logical_ring_default_vfuncs(struct intel_engine_cs *engine) { /* Default vfuncs which can be overriden by each engine. */ engine->init_hw = gen8_init_common_ring; @@ -1930,7 +1929,7 @@ logical_ring_default_vfuncs(struct drm_device *dev, engine->emit_bb_start = gen8_emit_bb_start; engine->get_seqno = gen8_get_seqno; engine->set_seqno = gen8_set_seqno; - if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) { + if (IS_BXT_REVID(engine->dev, 0, BXT_REVID_A1)) { engine->irq_seqno_barrier = bxt_a_seqno_barrier; engine->set_seqno = bxt_a_set_seqno; } @@ -1941,6 +1940,7 @@ logical_ring_default_irqs(struct intel_engine_cs *engine, unsigned shift) { engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT << shift; engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift; + init_waitqueue_head(>irq_queue); } static int @@ -1961,31 +1961,72 @@ lrc_setup_hws(struct intel_engine_cs *engine, return 0; } -static int -logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine) +static const struct logical_ring_info { + const char *name; + unsigned exec_id; + unsigned guc_id; + u32 mmio_base; + unsigned irq_shift; +} logical_rings[] = { + [RCS] = { + .name = "render ring", + .exec_id = I915_EXEC_RENDER, + .guc_id = GUC_RENDER_ENGINE, + .mmio_base = RENDER_RING_BASE, + .irq_shift = GEN8_RCS_IRQ_SHIFT, + }, + [BCS] = { + .name = "blitter ring", + .exec_id = I915_EXEC_BLT, + .guc_id = GUC_BLITTER_ENGINE, + .mmio_base = BLT_RING_BASE, + .irq_shift = GEN8_BCS_IRQ_SHIFT, + }, + [VCS] = { + .name = "bsd ring", + .exec_id = I915_EXEC_BSD, + .guc_id = GUC_VIDEO_ENGINE, + .mmio_base = GEN6_BSD_RING_BASE, + .irq_shift = GEN8_VCS1_IRQ_SHIFT, + }, + [VCS2] = { + .name = "bsd2 ring", + .exec_id = I915_EXEC_BSD, + .guc_id = GUC_VIDEO_ENGINE2, + .mmio_base = GEN8_BSD2_RING_BASE, + .irq_shift = GEN8_VCS2_IRQ_SHIFT, + }, + [VECS] = { + .name = "video enhancement ring", + .exec_id = I915_EXEC_VEBOX, + .guc_id = GUC_VIDEOENHANCE_ENGINE, + .mmio_base = VEBOX_RING_BASE, + .irq_shift = GEN8_VECS_IRQ_SHIFT, + }, +}; + +static struct intel_engine_cs * +logical_ring_setup(struct drm_device *dev, enum intel_engine_id id) { + const struct logical_ring_info *info = _rings[id]; struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_context *dctx = dev_priv->kernel_context; + struct intel_engine_cs *engine = _priv->engine[id]; enum forcewake_domains fw_domains; - int ret; - /* Intentionally left blank. */ - engine->buffer = NULL; + engine->id = id; + engine->name = info->name; + engine->exec_id = info->exec_id; + engine->guc_id = info->guc_id; + engine->mmio_base = info->mmio_base; - engine->dev = dev; - INIT_LIST_HEAD(>active_list); - INIT_LIST_HEAD(>request_list); - i915_gem_batch_pool_init(dev, >batch_pool); - init_waitqueue_head(>irq_queue); + /* disable interrupts to this engine before we install ourselves */ + I915_WRITE_IMR(engine, ~0); + POSTING_READ(RING_IMR(engine->mmio_base)); - INIT_LIST_HEAD(>buffers); - INIT_LIST_HEAD(>execlist_queue); - spin_lock_init(>execlist_lock); - - tasklet_init(>irq_tasklet, -intel_lrc_irq_handler, (unsigned long)engine); + engine->dev = dev; - logical_ring_init_platform_invariants(engine); + /*
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk
== Series Details == Series: series starting with [1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk URL : https://patchwork.freedesktop.org/series/6544/ State : success == Summary == Series 6544v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/6544/revisions/1/mbox/ bdw-nuci7-2 total:201 pass:189 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:201 pass:176 dwarn:0 dfail:0 fail:0 skip:25 bsw-nuc-2total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 byt-nuc total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 hsw-brixbox total:201 pass:175 dwarn:0 dfail:0 fail:0 skip:26 hsw-gt2 total:201 pass:179 dwarn:0 dfail:0 fail:1 skip:21 ivb-t430stotal:201 pass:170 dwarn:0 dfail:0 fail:0 skip:31 skl-i7k-2total:201 pass:174 dwarn:0 dfail:0 fail:0 skip:27 skl-nuci5total:201 pass:190 dwarn:0 dfail:0 fail:0 skip:11 snb-x220ttotal:201 pass:159 dwarn:0 dfail:0 fail:1 skip:41 snb-dellxps failed to collect. IGT log at Patchwork_2116/snb-dellxps/igt.log Results at /archive/results/CI_IGT_test/Patchwork_2116/ e88c818eb230a7b07d71843f5eaca1786544c709 drm-intel-nightly: 2016y-04m-29d-13h-05m-14s UTC integration manifest f89860a drm/i915: Add a FIXME about crtc !active vs. watermarks 2555e64 drm/i915: Calculate IPS linetime watermark based on future cdclk ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()
On Fri, Apr 29, 2016 at 04:44:24PM +0100, Tvrtko Ursulin wrote: > > On 27/04/16 19:03, Dave Gordon wrote: > >Mostly little optimisations; for instance, if the driver is correctly > >following the submission protocol, the "out of space" condition is > >impossible, so the previous runtime WARN_ON() is promoted to a > >GEM_BUG_ON() for a more dramatic effect in development and less impact > >in end-user systems. > > > >Similarly we can replace other WARN_ON() conditions that don't relate to > >the hardware state with either BUILD_BUG_ON() for compile-time- > >detectable issues, or GEM_BUG_ON() for logical "can't happen" errors. > > > >With those changes, we can convert it to void, as suggested by Chris > >Wilson, and update the calling code appropriately. > > > >Signed-off-by: Dave Gordon> >Cc: Chris Wilson > > > >--- > > drivers/gpu/drm/i915/i915_guc_submission.c | 69 > > +++--- > > drivers/gpu/drm/i915/intel_guc.h | 2 +- > > drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +- > > 3 files changed, 37 insertions(+), 37 deletions(-) > > > >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c > >b/drivers/gpu/drm/i915/i915_guc_submission.c > >index 6626eff..4d2ea84 100644 > >--- a/drivers/gpu/drm/i915/i915_guc_submission.c > >+++ b/drivers/gpu/drm/i915/i915_guc_submission.c > >@@ -470,23 +470,28 @@ int i915_guc_wq_check_space(struct > >drm_i915_gem_request *request) > > return -EAGAIN; > > } > > > >-static int guc_add_workqueue_item(struct i915_guc_client *gc, > >- struct drm_i915_gem_request *rq) > >+static void guc_add_workqueue_item(struct i915_guc_client *gc, > >+ struct drm_i915_gem_request *rq) > > { > >+/* wqi_len is in DWords, and does not include the one-word header */ > >+const size_t wqi_size = sizeof(struct guc_wq_item); > > Again, u32 is correct I think. > > >+const u32 wqi_len = wqi_size/sizeof(u32) - 1; > > struct guc_process_desc *desc; > > struct guc_wq_item *wqi; > > void *base; > >-u32 tail, wq_len, wq_off, space; > >+u32 space, tail, wq_off, wq_page; > > > > desc = gc->client_base + gc->proc_desc_offset; > >+ > >+/* Space was checked earlier, in i915_guc_wq_check_space() above */ > > It may be above in the file, but the two do not call one another so > I recommend saying exactly who called it. > > > space = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size); > >-if (WARN_ON(space < sizeof(struct guc_wq_item))) > >-return -ENOSPC; /* shouldn't happen */ > >+GEM_BUG_ON(space < wqi_size); > > It is impossible to hit this only because of the struct_mutex > guarding the whole time window from request creation to submission. > If in the future, near or far, that gets fixed, then this will need > reworking. Request submission will still have to serialised by a "ring" mutex, from the time we allocate the request to the time we add it to whatever submission queue. It should still hold that we can pin all the required resources (ringbuffer, context state, vm page tables, workqueues) up front and take any errors early and then rely on our preallocation when submitting the request. > I don't have any better ideas though. > > But a WARN_ON and return would be almost as good. Everything is > better than a dead machine one can't ssh into... > > So I appeal to make this a WARN_ON and return. Nothing bad would > happen apart from software thinking GPU has hung. Hence why not make it a bug? If you can't ssh in because the driver died inside GEM, something is very wrong. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full
One late comment: On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a counter to the GuC client statistics, to see how often we find the WQ full. Signed-off-by: Dave Gordon--- drivers/gpu/drm/i915/i915_debugfs.c| 1 + drivers/gpu/drm/i915/i915_guc_submission.c | 16 +--- drivers/gpu/drm/i915/intel_guc.h | 8 3 files changed, 10 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 8b8d6f0..1024947 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2509,6 +2509,7 @@ static void i915_guc_client_info(struct seq_file *m, seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n", client->wq_size, client->wq_offset, client->wq_tail); + seq_printf(m, "\tWork queue full: %u\n", client->no_wq_space); seq_printf(m, "\tFailed to queue: %u\n", client->q_fail); seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail); seq_printf(m, "\tLast submission result: %d\n", client->retcode); diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 66af5ce..6626eff 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -453,27 +453,21 @@ static void guc_fini_ctx_desc(struct intel_guc *guc, int i915_guc_wq_check_space(struct drm_i915_gem_request *request) { - const size_t size = sizeof(struct guc_wq_item); + const size_t wqi_size = sizeof(struct guc_wq_item); struct i915_guc_client *gc = request->i915->guc.execbuf_client; struct guc_process_desc *desc; - int ret = -ETIMEDOUT, timeout_counter = 200; if (!gc) return 0; desc = gc->client_base + gc->proc_desc_offset; - while (timeout_counter-- > 0) { - if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) { - ret = 0; - break; - } + if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= wqi_size) + return 0; - if (timeout_counter) - usleep_range(1000, 2000); - }; + gc->no_wq_space += 1; - return ret; + return -EAGAIN; } static int guc_add_workqueue_item(struct i915_guc_client *gc, diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index b37c731..436f2d6 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -73,10 +73,10 @@ struct i915_guc_client { /* GuC submission statistics & status */ uint64_t submissions[GUC_MAX_ENGINES_NUM]; - uint32_t q_fail; - uint32_t b_fail; - int retcode; - int spare; /* pad to 32 DWords */ + uint32_t no_wq_space; /* Space pre-check failed */ + uint32_t q_fail;/* Failed to queue (MBZ)*/ + uint32_t b_fail;/* Doorbell failure (MBZ) */ Why MBZ? It is not all used in this context so this will just confuse people. + int retcode;/* Result of last guc_submit() */ }; enum intel_guc_fw_status { Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()
On 27/04/16 19:03, Dave Gordon wrote: Mostly little optimisations; for instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic effect in development and less impact in end-user systems. Similarly we can replace other WARN_ON() conditions that don't relate to the hardware state with either BUILD_BUG_ON() for compile-time- detectable issues, or GEM_BUG_ON() for logical "can't happen" errors. With those changes, we can convert it to void, as suggested by Chris Wilson, and update the calling code appropriately. Signed-off-by: Dave GordonCc: Chris Wilson --- drivers/gpu/drm/i915/i915_guc_submission.c | 69 +++--- drivers/gpu/drm/i915/intel_guc.h | 2 +- drivers/gpu/drm/i915/intel_guc_fwif.h | 3 +- 3 files changed, 37 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 6626eff..4d2ea84 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -470,23 +470,28 @@ int i915_guc_wq_check_space(struct drm_i915_gem_request *request) return -EAGAIN; } -static int guc_add_workqueue_item(struct i915_guc_client *gc, - struct drm_i915_gem_request *rq) +static void guc_add_workqueue_item(struct i915_guc_client *gc, + struct drm_i915_gem_request *rq) { + /* wqi_len is in DWords, and does not include the one-word header */ + const size_t wqi_size = sizeof(struct guc_wq_item); Again, u32 is correct I think. + const u32 wqi_len = wqi_size/sizeof(u32) - 1; struct guc_process_desc *desc; struct guc_wq_item *wqi; void *base; - u32 tail, wq_len, wq_off, space; + u32 space, tail, wq_off, wq_page; desc = gc->client_base + gc->proc_desc_offset; + + /* Space was checked earlier, in i915_guc_wq_check_space() above */ It may be above in the file, but the two do not call one another so I recommend saying exactly who called it. space = CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size); - if (WARN_ON(space < sizeof(struct guc_wq_item))) - return -ENOSPC; /* shouldn't happen */ + GEM_BUG_ON(space < wqi_size); It is impossible to hit this only because of the struct_mutex guarding the whole time window from request creation to submission. If in the future, near or far, that gets fixed, then this will need reworking. I don't have any better ideas though. But a WARN_ON and return would be almost as good. Everything is better than a dead machine one can't ssh into... So I appeal to make this a WARN_ON and return. Nothing bad would happen apart from software thinking GPU has hung. - /* postincrement WQ tail for next time */ - wq_off = gc->wq_tail; - gc->wq_tail += sizeof(struct guc_wq_item); - gc->wq_tail &= gc->wq_size - 1; + /* The GuC firmware wants the tail index in QWords, not bytes */ + tail = rq->tail; Used to be sampled from rq->ringbuf->tail - are those the same? + GEM_BUG_ON(tail & 7); + tail >>= 3; + GEM_BUG_ON(tail > WQ_RING_TAIL_MAX); /* For now workqueue item is 4 DWs; workqueue buffer is 2 pages. So we * should not have the case where structure wqi is across page, neither @@ -495,19 +500,23 @@ static int guc_add_workqueue_item(struct i915_guc_client *gc, * XXX: if not the case, we need save data to a temp wqi and copy it to * workqueue buffer dw by dw. */ - WARN_ON(sizeof(struct guc_wq_item) != 16); - WARN_ON(wq_off & 3); + BUILD_BUG_ON(wqi_size != 16); - /* wq starts from the page after doorbell / process_desc */ - base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, - (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT)); + /* postincrement WQ tail for next time */ + wq_off = gc->wq_tail; + gc->wq_tail += wqi_size; + gc->wq_tail &= gc->wq_size - 1; + GEM_BUG_ON(wq_off & (wqi_size - 1)); Use to be wq_off & 3, now is wq_off & 15, which one is correct? + + /* WQ starts from the page after doorbell / process_desc */ + wq_page = (wq_off + GUC_DB_SIZE) >> PAGE_SHIFT; wq_off &= PAGE_SIZE - 1; + base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, wq_page)); wqi = (struct guc_wq_item *)((char *)base + wq_off); - /* len does not include the header */ - wq_len = sizeof(struct guc_wq_item) / sizeof(u32) - 1; + /* Now fill in the 4-word work queue item */ wqi->header = WQ_TYPE_INORDER | - (wq_len << WQ_LEN_SHIFT) | + (wqi_len << WQ_LEN_SHIFT) |
Re: [Intel-gfx] [PATCH] prime_mmap_kms: show case dma-buf new API and processes restrictions
On Mon, Apr 25, 2016 at 11:07:48AM -0300, Tiago Vignatti wrote: > dma-buf new API consists of: > > - mmap(dma_buf_fd): the ability to map a dma-buf file-descriptor to the > user-space, and most importantly, to actually write on the mapped pointer. > Worth to note that the Direct Rendering Manager (DRM) and the hardware driver > implementation are fundamentally important to safely exporting the graphics > handle to be mapped. > > - ioctl(dma_buf_fd, DMA_BUF_IOCTL_SYNC): cache coherency management in cases > where the CPU and GPU devices are being accessed through dma-buf at the same > time. Coherency markers, that forward directly to existing dma-buf device > drivers vfunc hooks, are exposed to the user-space through the > DMA_BUF_IOCTL_SYNC ioctl and have to be used before and after the mapped area > is accessed. > > Signed-off-by: Tiago Vignatti> --- > tests/Makefile.sources | 1 + > tests/prime_mmap_kms.c | 250 > + > 2 files changed, 251 insertions(+) > create mode 100644 tests/prime_mmap_kms.c > > diff --git a/tests/Makefile.sources b/tests/Makefile.sources > index abcf325..d672c13 100644 > --- a/tests/Makefile.sources > +++ b/tests/Makefile.sources > @@ -111,6 +111,7 @@ TESTS_progs_M = \ > pm_sseu \ > prime_mmap \ > prime_mmap_coherency \ > + prime_mmap_kms \ > prime_self_import \ > template \ > $(NULL) > diff --git a/tests/prime_mmap_kms.c b/tests/prime_mmap_kms.c > new file mode 100644 > index 000..c65e208 > --- /dev/null > +++ b/tests/prime_mmap_kms.c > @@ -0,0 +1,250 @@ > +/* > + * Copyright © 2016 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of 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: > + *Tiago Vignatti > + */ > + > +#include "igt.h" > + > +IGT_TEST_DESCRIPTION( > + "Efficiently sharing CPU and GPU buffers"); > + > +/* > + * render_process_t: > + * > + * Render is basically a user-space regular client. It's the unprivileged > + * process with limited system accesses. > + * > + * Worth note the vendor-independent characteristic, meaning that the > + * client doesn't need to perform any vendor specific calls for buffer > + * handling. Mesa GBM library is a counter-example because, even though its > API > + * is vendor-independent, under-the-hood the library actually calls vendor > + * specific ioctls, which is not really sandboxable and not the goal here. > + */ > +typedef struct { > + int prime_fd; > + size_t size; > + int width; > + int height; > +} render_process_t; > + > +typedef struct { > + int x; > + int y; > + int w; > + int h; > +} rect_t; > + > +/* set ptr in a linear view */ > +static void set_pixel(void *_ptr, int index, uint32_t color, int bpp) > +{ > + if (bpp == 16) { > + uint16_t *ptr = _ptr; > + ptr[index] = color; > + } else if (bpp == 32) { > + uint32_t *ptr = _ptr; > + ptr[index] = color; > + } else { > + igt_assert_f(false, "bpp: %d\n", bpp); > + } > +} > + > +static void paint(render_process_t *render) > +{ > + void *frame; > + rect_t rect = { > + .x = 200, > + .y = 200, > + .w = render->width / 4, > + .h = render->height / 4, > + }; > + int stride, bpp, color = 0xFF; uint32_t color; > + int x, y, line_begin; > + > + frame = mmap(NULL, render->size, PROT_READ | PROT_WRITE, MAP_SHARED, > + render->prime_fd, 0); > + igt_assert(frame != MAP_FAILED); > + > + /* TODO: what's the mmap'ed buffer semantics on tiling, format etc. How > + * does the client know whether that the BO was created X-tiled, > + * Y-tiled and how it will map back? This is something we need to > + * address in this API still. */ > + stride = render->width *
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full
On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a counter to the GuC client statistics, to see how often we find the WQ full. Signed-off-by: Dave Gordon--- drivers/gpu/drm/i915/i915_debugfs.c| 1 + drivers/gpu/drm/i915/i915_guc_submission.c | 16 +--- drivers/gpu/drm/i915/intel_guc.h | 8 3 files changed, 10 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 8b8d6f0..1024947 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2509,6 +2509,7 @@ static void i915_guc_client_info(struct seq_file *m, seq_printf(m, "\tWQ size %d, offset: 0x%x, tail %d\n", client->wq_size, client->wq_offset, client->wq_tail); + seq_printf(m, "\tWork queue full: %u\n", client->no_wq_space); seq_printf(m, "\tFailed to queue: %u\n", client->q_fail); seq_printf(m, "\tFailed doorbell: %u\n", client->b_fail); seq_printf(m, "\tLast submission result: %d\n", client->retcode); diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 66af5ce..6626eff 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -453,27 +453,21 @@ static void guc_fini_ctx_desc(struct intel_guc *guc, int i915_guc_wq_check_space(struct drm_i915_gem_request *request) { - const size_t size = sizeof(struct guc_wq_item); + const size_t wqi_size = sizeof(struct guc_wq_item); struct i915_guc_client *gc = request->i915->guc.execbuf_client; struct guc_process_desc *desc; - int ret = -ETIMEDOUT, timeout_counter = 200; if (!gc) return 0; Not part of this patch but spotted it - can this really happen, and if so, does it warrant a WARN_ONCE, GEM_BUG_ON or something? desc = gc->client_base + gc->proc_desc_offset; - while (timeout_counter-- > 0) { - if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= size) { - ret = 0; - break; - } + if (CIRC_SPACE(gc->wq_tail, desc->head, gc->wq_size) >= wqi_size) + return 0; Could stick a likely here to lay out the code for the expected case but it could be just OCD. :) - if (timeout_counter) - usleep_range(1000, 2000); - }; + gc->no_wq_space += 1; - return ret; + return -EAGAIN; I suppose it is OK to make userspace pay the cost since this should be extremely rare, correct? } static int guc_add_workqueue_item(struct i915_guc_client *gc, diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index b37c731..436f2d6 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -73,10 +73,10 @@ struct i915_guc_client { /* GuC submission statistics & status */ uint64_t submissions[GUC_MAX_ENGINES_NUM]; - uint32_t q_fail; - uint32_t b_fail; - int retcode; - int spare; /* pad to 32 DWords */ + uint32_t no_wq_space; /* Space pre-check failed */ + uint32_t q_fail;/* Failed to queue (MBZ)*/ + uint32_t b_fail;/* Doorbell failure (MBZ) */ + int retcode;/* Result of last guc_submit() */ }; enum intel_guc_fw_status { Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()
On 27/04/16 19:03, Dave Gordon wrote: The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process. And all the information the GuC code needs should be encapsulated in (or reachable from) the request. Signed-off-by: Dave Gordon--- drivers/gpu/drm/i915/i915_guc_submission.c | 11 ++- drivers/gpu/drm/i915/intel_guc.h | 5 ++--- drivers/gpu/drm/i915/intel_lrc.c | 9 +++-- 3 files changed, 11 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 42d2efa..66af5ce 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -451,10 +451,11 @@ static void guc_fini_ctx_desc(struct intel_guc *guc, sizeof(desc) * client->ctx_index); } -int i915_guc_wq_check_space(struct i915_guc_client *gc) +int i915_guc_wq_check_space(struct drm_i915_gem_request *request) { + const size_t size = sizeof(struct guc_wq_item); All the other variables passed to CIRC_SPACE are u32 so this is for the worse I think. + struct i915_guc_client *gc = request->i915->guc.execbuf_client; struct guc_process_desc *desc; - u32 size = sizeof(struct guc_wq_item); int ret = -ETIMEDOUT, timeout_counter = 200; if (!gc) @@ -537,11 +538,11 @@ static int guc_add_workqueue_item(struct i915_guc_client *gc, * * Return:0 if succeed */ -int i915_guc_submit(struct i915_guc_client *client, - struct drm_i915_gem_request *rq) +int i915_guc_submit(struct drm_i915_gem_request *rq) { - struct intel_guc *guc = client->guc; unsigned int engine_id = rq->engine->guc_id; + struct intel_guc *guc = >i915->guc; + struct i915_guc_client *client = guc->execbuf_client; int q_ret, b_ret; q_ret = guc_add_workqueue_item(client, rq); diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index 9d79c4c..b37c731 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -148,10 +148,9 @@ extern int intel_guc_resume(struct drm_device *dev); /* i915_guc_submission.c */ int i915_guc_submission_init(struct drm_device *dev); int i915_guc_submission_enable(struct drm_device *dev); -int i915_guc_submit(struct i915_guc_client *client, - struct drm_i915_gem_request *rq); +int i915_guc_wq_check_space(struct drm_i915_gem_request *rq); +int i915_guc_submit(struct drm_i915_gem_request *rq); void i915_guc_submission_disable(struct drm_device *dev); void i915_guc_submission_fini(struct drm_device *dev); -int i915_guc_wq_check_space(struct i915_guc_client *client); #endif diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 2b7e6bb..b8ec8c6 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -708,9 +708,7 @@ int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request *request * going any further, as the i915_add_request() call * later on mustn't fail ... */ - struct intel_guc *guc = >i915->guc; - - ret = i915_guc_wq_check_space(guc->execbuf_client); + ret = i915_guc_wq_check_space(request); if (ret) return ret; } @@ -776,7 +774,6 @@ static int logical_ring_wait_for_space(struct drm_i915_gem_request *req, intel_logical_ring_advance_and_submit(struct drm_i915_gem_request *request) { struct intel_ringbuffer *ringbuf = request->ringbuf; - struct drm_i915_private *dev_priv = request->i915; struct intel_engine_cs *engine = request->engine; intel_logical_ring_advance(ringbuf); @@ -806,8 +803,8 @@ static int logical_ring_wait_for_space(struct drm_i915_gem_request *req, } } - if (dev_priv->guc.execbuf_client) - i915_guc_submit(dev_priv->guc.execbuf_client, request); + if (i915.enable_guc_submission) + i915_guc_submit(request); else execlists_context_queue(request); With the datatype fix (revert) in i915_guc_wq_check_space: Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter
Hi, On 27/04/16 19:03, Dave Gordon wrote: Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for batch submission once the firmware is loaded. In addition, the degree of control has been refined from a simple bool to an integer key, allowing several options: -1 (default) whatever the platform default is 0 DISABLE don't load/use the GuC 1 BEST EFFORT try to load/use the GuC, fallback if not available 2 REQUIRE must load/use the GuC, else leave the GPU wedged The new platform default (as coded here) will be to attempt to load the GuC iff the device has a GuC that requires firmware, but not yet to use it for submission. A later patch will change to enable it if appropriate. Signed-off-by: Dave Gordon--- drivers/gpu/drm/i915/i915_gem.c| 1 - drivers/gpu/drm/i915/i915_guc_submission.c | 4 +- drivers/gpu/drm/i915/i915_params.c | 14 - drivers/gpu/drm/i915/i915_params.h | 3 +- drivers/gpu/drm/i915/intel_guc_loader.c| 98 -- drivers/gpu/drm/i915/intel_uncore.c| 2 +- 6 files changed, 70 insertions(+), 52 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index d493e79..b04effc 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4910,7 +4910,6 @@ int i915_gem_init_engines(struct drm_device *dev) ret = intel_guc_ucode_load(dev); if (ret) { DRM_ERROR("Failed to initialize GuC, error %d\n", ret); - ret = -EIO; goto out; } } diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 72d6665..42d2efa 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -970,7 +970,7 @@ int intel_guc_suspend(struct drm_device *dev) struct intel_context *ctx; u32 data[3]; - if (!i915.enable_guc_submission) + if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS) return 0; ctx = dev_priv->kernel_context; @@ -996,7 +996,7 @@ int intel_guc_resume(struct drm_device *dev) struct intel_context *ctx; u32 data[3]; - if (!i915.enable_guc_submission) + if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS) return 0; Not terribly important and probably predates your work, but just spotted how this reads very redundant - guc->guc_fw.guc_fw_something, while it could be much more readable as guc->fw.load_status. Observation only. ctx = dev_priv->kernel_context; diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 383c076..6a5578c 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -54,7 +54,8 @@ struct i915_params i915 __read_mostly = { .verbose_state_checks = 1, .nuclear_pageflip = 0, .edp_vswing = 0, - .enable_guc_submission = false, + .enable_guc_loading = -1, + .enable_guc_submission = 0, .guc_log_level = -1, .enable_dp_mst = true, .inject_load_failure = 0, @@ -198,8 +199,15 @@ struct i915_params i915 __read_mostly = { "(0=use value from vbt [default], 1=low power swing(200mV)," "2=default swing(400mV))"); -module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, bool, 0400); -MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission (default:false)"); +module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int, 0400); +MODULE_PARM_DESC(enable_guc_loading, + "Enable GuC firmware loading " + "(-1=auto [default], 0=never, 1=if available, 2=required)"); + +module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission, int, 0400); +MODULE_PARM_DESC(enable_guc_submission, + "Enable GuC submission " + "(-1=auto, 0=never [default], 1=if available, 2=required)"); module_param_named(guc_log_level, i915.guc_log_level, int, 0400); MODULE_PARM_DESC(guc_log_level, diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 65e73dd..1323261 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -45,6 +45,8 @@ struct i915_params { int enable_ips; int invert_brightness; int enable_cmd_parser; + int enable_guc_loading; + int enable_guc_submission; int guc_log_level; int use_mmio_flip; int mmio_debug; @@ -57,7 +59,6 @@ struct i915_params { bool load_detect_test; bool
[Intel-gfx] [PATCH i-g-t] tools/intel_reg_decode: drop confusing use of IS_965()
Unlike in the kernel driver coding style, IS_965() matches the platform and all subsequent ones. Replace IS_965() with suitable but less confusing alternatives. Most occurences are on code paths that only get called for gens 2, 3 and 4, so replace those with IS_GEN4(). In the one other call site just flip the condition to check for gens 2 and 3 instead. Signed-off-by: Jani Nikula--- tools/intel_reg_decode.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tools/intel_reg_decode.c b/tools/intel_reg_decode.c index 470fecc165c6..253655482290 100644 --- a/tools/intel_reg_decode.c +++ b/tools/intel_reg_decode.c @@ -54,7 +54,7 @@ DEBUGSTRING(i830_debug_dcc) if (!IS_MOBILE(devid)) return; - if (IS_965(devid)) { + if (IS_GEN4(devid)) { if (val & (1 << 1)) addressing = "dual channel interleaved"; else @@ -151,11 +151,11 @@ DEBUGSTRING(i830_debug_pipeconf) char buf[256]; int buf_len; - if (IS_965(devid)) - bit30 = val & I965_PIPECONF_ACTIVE ? "active" : "inactive"; + if (IS_GEN2(devid) || IS_GEN3(devid)) + bit30 = val & PIPEACONF_DOUBLE_WIDE ? + "double-wide" : "single-wide"; else - bit30 = - val & PIPEACONF_DOUBLE_WIDE ? "double-wide" : "single-wide"; + bit30 = val & I965_PIPECONF_ACTIVE ? "active" : "inactive"; buf_len = snprintf(buf, sizeof(buf), "%s, %s", enabled, bit30); @@ -701,7 +701,7 @@ DEBUGSTRING(i810_debug_915_fence) unsigned int offset = val & 0x0ff0; int size = (1024 * 1024) << ((val & 0x700) >> 8); - if (IS_965(devid) || (IS_915(devid) && reg >= FENCE_NEW)) + if (IS_GEN4(devid) || (IS_915(devid) && reg >= FENCE_NEW)) return; if (format == 'X') @@ -722,7 +722,7 @@ DEBUGSTRING(i810_debug_965_fence_start) int pitch = ((val & 0xffc) >> 2) * 128 + 128; unsigned int offset = val & 0xf000; - if (!IS_965(devid)) + if (!IS_GEN4(devid)) return; snprintf(result, len, "%s, %c tile walk, %4d pitch, 0x%08x start", @@ -733,7 +733,7 @@ DEBUGSTRING(i810_debug_965_fence_end) { unsigned int end = val & 0xf000; - if (!IS_965(devid)) + if (!IS_GEN4(devid)) return; snprintf(result, len, " 0x%08x end", end); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib/intel_chipset: drop unused IS_9XX()
It's also confusing as the style differs from the kernel (exact platform in the kernel vs. the platform and any later ones in igt). Signed-off-by: Jani Nikula--- lib/intel_chipset.h | 8 1 file changed, 8 deletions(-) diff --git a/lib/intel_chipset.h b/lib/intel_chipset.h index 4b4061253e75..2f2e435281cc 100644 --- a/lib/intel_chipset.h +++ b/lib/intel_chipset.h @@ -477,14 +477,6 @@ void intel_check_pch(void); IS_GEN8(devid) || \ IS_GEN9(devid)) -#define IS_9XX(devid) (IS_GEN3(devid) || \ -IS_GEN4(devid) || \ -IS_GEN5(devid) || \ -IS_GEN6(devid) || \ -IS_GEN7(devid) || \ -IS_GEN8(devid) || \ -IS_GEN9(devid)) - #define IS_INTEL(devid)(IS_GEN2(devid) || \ IS_GEN3(devid) || \ IS_GEN4(devid) || \ -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Render decompression support for Gen9 and above
On Fri, Apr 29, 2016 at 08:27:00PM +0530, Vandana Kannan wrote: > This patch includes enabling render decompression (RC) after checking > all the requirements (format, tiling, rotation etc.). > > TODO: > 1. Disable stereo 3D when render decomp is enabled (bit 7:6) > 2. Render decompression must not be used in VTd pass-through mode > 3. Program hashing select CHICKEN_MISC1 bit 15 > 4. For Gen10, add support for RGB 1010102 > 5. RC-FBC workaround > 6. RC watermark calculation > > The reason for using a plane property instead of fb modifier:- > In Android, OGL passes a render compressed buffer to hardware composer > (HWC), which would then request a flip on that buffer after checking if > the target can support render compressed buffer. For example, only planes > 1 and 2 on pipes 1 and 2 can support RC. In case the target cannot > support it, HWC will revert back to OGL requesting for uncompressed > buffer. > Here, > if plane property is used, OGL would send back the buffer (same ID) after > decompression, marked uncompressed. If fb modifier was used, a different > version of the buffer would have to be maintained for different > combinations - in the simple case of render compressed vs uncompressed > buffer, there would be 2 fbs with 2 IDs. So, in this case, OGL would give > a reference to a fb with a different ID. > To avoid the difficulty of keeping track of multiple fbs and the subsequent > complexity in debug, the architecture forum decided to go ahead with a > plane property for RC. > > [Mayuresh] Added the plane check in skl_check_compression() > > v2: Ville's review comments addressed > - Removed WAs specific to SKL-C and BXT-A > - Assign capabilities according to pipe and plane during property creation > - in skl_check_compression(), check for conditions that must be satisifed > > Maintaining the check for pixel format, even though compressed fb of format > other RGB should not have been created, to be on the safer side. > Added checks for BGR too. > Bitmask is being used for the property to accommodate 2 more options > expected to be added in future. > > This patch depends on Ville's patch series on fb->offsets. > (Ref: git://github.com/vsyrjala/linux.git fb_offsets_14) > > Testing is in progress for v2 of the patch. > > Signed-off-by: Vandana Kannan> Cc: Ville Syrjälä > Cc: Smith, Gary K > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_reg.h | 22 + > drivers/gpu/drm/i915/intel_atomic_plane.c | 24 +- > drivers/gpu/drm/i915/intel_display.c | 135 > +- > drivers/gpu/drm/i915/intel_drv.h | 10 +++ > drivers/gpu/drm/i915/intel_sprite.c | 27 +- > 6 files changed, 213 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 32f0597..ba32e7c 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1901,6 +1901,7 @@ struct drm_i915_private { > > struct drm_property *broadcast_rgb_property; > struct drm_property *force_audio_property; > + struct drm_property *render_comp_property; > > /* hda/i915 audio component */ > struct i915_audio_component *audio_component; > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 25e229b..da45cc9 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -5816,6 +5816,28 @@ enum skl_disp_power_wells { > _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \ > _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B)) > > +#define PLANE_AUX_DIST_1_A 0x701c0 > +#define PLANE_AUX_DIST_2_A 0x702c0 > +#define PLANE_AUX_DIST_1_B 0x711c0 > +#define PLANE_AUX_DIST_2_B 0x712c0 > +#define _PLANE_AUX_DIST_1(pipe) \ > + _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B) > +#define _PLANE_AUX_DIST_2(pipe) \ > + _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B) > +#define PLANE_AUX_DIST(pipe, plane) \ > + _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe)) > + > +#define PLANE_AUX_OFFSET_1_A 0x701c4 > +#define PLANE_AUX_OFFSET_2_A 0x702c4 > +#define PLANE_AUX_OFFSET_1_B 0x711c4 > +#define PLANE_AUX_OFFSET_2_B 0x712c4 > +#define _PLANE_AUX_OFFSET_1(pipe) \ > + _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B) > +#define _PLANE_AUX_OFFSET_2(pipe) \ > + _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B) > +#define PLANE_AUX_OFFSET(pipe, plane) \ > + _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe)) > + > /* legacy palette */ > #define _LGC_PALETTE_A 0x4a000 > #define _LGC_PALETTE_B 0x4a800 > diff --git
[Intel-gfx] [PATCH 2/2] drm/i915: Add a FIXME about crtc !active vs. watermarks
From: Ville SyrjäläWhen the crtc is enabled but !active, we should still compute the watermarks as if the planes were visible. That would make it more likely that the we can later transition to active without errors. Add a FIXME to remind people that we're doing the wrong thing now. We should perhaps just move the wm computation for each individual plane into the .check_plane hook, and later we'd just combine the results from all active planes. Cc: Maarten Lankhorst Cc: Matt Roper Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 5ffccf6e7f36..00059d18b0f0 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11833,6 +11833,11 @@ int intel_plane_atomic_calc_changes(struct drm_crtc_state *crtc_state, * Visibility is calculated as if the crtc was on, but * after scaler setup everything depends on it being off * when the crtc isn't active. +* +* FIXME this is wrong for watermarks. Watermarks should also +* be computed as if the pipe would be active. Perhaps move +* per-plane wm computation to the .check_plane() hook, and +* only combine the results from all planes in the current place? */ if (!is_crtc_enabled) to_intel_plane_state(plane_state)->visible = visible = false; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm: Add aux plane verification in addFB2 (rev2)
== Series Details == Series: series starting with [1/2] drm: Add aux plane verification in addFB2 (rev2) URL : https://patchwork.freedesktop.org/series/4641/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/igb/e1000_nvm.o CC [M] drivers/net/ethernet/intel/igb/e1000_phy.o CC [M] drivers/net/ethernet/intel/igbvf/vf.o LD drivers/usb/host/built-in.o CC [M] drivers/net/ethernet/intel/igbvf/mbx.o LD drivers/usb/built-in.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o CC [M] drivers/net/ethernet/intel/igbvf/ethtool.o CC [M] drivers/net/ethernet/intel/igb/e1000_mbx.o CC [M] drivers/net/ethernet/intel/igbvf/netdev.o CC [M] drivers/net/ethernet/intel/igb/e1000_i210.o CC [M] drivers/net/ethernet/intel/igb/igb_ptp.o CC [M] drivers/net/ethernet/intel/igb/igb_hwmon.o cc1: some warnings being treated as errors scripts/Makefile.build:291: recipe for target 'drivers/gpu/drm/i915/intel_display.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_display.o] Error 1 scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:440: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:440: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 make[1]: *** Waiting for unfinished jobs LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o LD [M] drivers/net/ethernet/intel/igb/igb.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o Makefile:962: recipe for target 'drivers' failed make: *** [drivers] Error 2 Full logs at /archive/deploy/logs/CI_Patchwork_build_2115 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Calculate IPS linetime watermark based on future cdclk
From: Ville SyrjäläUse the cdclk we're going to be using when the pipe gets enabled to compute the IPS linetime watermark. The current cdclk frequency is irrelevant at this point since it can still change. Cc: Maarten Lankhorst Cc: Matt Roper Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 2422ac38ce5d..964b4eff3087 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -2012,10 +2012,10 @@ static void ilk_compute_wm_level(const struct drm_i915_private *dev_priv, } static uint32_t -hsw_compute_linetime_wm(struct drm_device *dev, - struct intel_crtc_state *cstate) +hsw_compute_linetime_wm(const struct intel_crtc_state *cstate) { - struct drm_i915_private *dev_priv = dev->dev_private; + const struct intel_atomic_state *intel_state = + to_intel_atomic_state(cstate->base.state); const struct drm_display_mode *adjusted_mode = >base.adjusted_mode; u32 linetime, ips_linetime; @@ -2024,7 +2024,7 @@ hsw_compute_linetime_wm(struct drm_device *dev, return 0; if (WARN_ON(adjusted_mode->crtc_clock == 0)) return 0; - if (WARN_ON(dev_priv->cdclk_freq == 0)) + if (WARN_ON(intel_state->cdclk == 0)) return 0; /* The WM are computed with base on how long it takes to fill a single @@ -2033,7 +2033,7 @@ hsw_compute_linetime_wm(struct drm_device *dev, linetime = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8, adjusted_mode->crtc_clock); ips_linetime = DIV_ROUND_CLOSEST(adjusted_mode->crtc_htotal * 1000 * 8, -dev_priv->cdclk_freq); +intel_state->cdclk); return PIPE_WM_LINETIME_IPS_LINETIME(ips_linetime) | PIPE_WM_LINETIME_TIME(linetime); @@ -2352,7 +2352,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate) pipe_wm->wm[0] = pipe_wm->raw_wm[0]; if (IS_HASWELL(dev) || IS_BROADWELL(dev)) - pipe_wm->linetime = hsw_compute_linetime_wm(dev, cstate); + pipe_wm->linetime = hsw_compute_linetime_wm(cstate); if (!ilk_validate_pipe_wm(dev, pipe_wm)) return -EINVAL; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: Render decompression support for Gen9 and above
This patch includes enabling render decompression (RC) after checking all the requirements (format, tiling, rotation etc.). TODO: 1. Disable stereo 3D when render decomp is enabled (bit 7:6) 2. Render decompression must not be used in VTd pass-through mode 3. Program hashing select CHICKEN_MISC1 bit 15 4. For Gen10, add support for RGB 1010102 5. RC-FBC workaround 6. RC watermark calculation The reason for using a plane property instead of fb modifier:- In Android, OGL passes a render compressed buffer to hardware composer (HWC), which would then request a flip on that buffer after checking if the target can support render compressed buffer. For example, only planes 1 and 2 on pipes 1 and 2 can support RC. In case the target cannot support it, HWC will revert back to OGL requesting for uncompressed buffer. Here, if plane property is used, OGL would send back the buffer (same ID) after decompression, marked uncompressed. If fb modifier was used, a different version of the buffer would have to be maintained for different combinations - in the simple case of render compressed vs uncompressed buffer, there would be 2 fbs with 2 IDs. So, in this case, OGL would give a reference to a fb with a different ID. To avoid the difficulty of keeping track of multiple fbs and the subsequent complexity in debug, the architecture forum decided to go ahead with a plane property for RC. [Mayuresh] Added the plane check in skl_check_compression() v2: Ville's review comments addressed - Removed WAs specific to SKL-C and BXT-A - Assign capabilities according to pipe and plane during property creation - in skl_check_compression(), check for conditions that must be satisifed Maintaining the check for pixel format, even though compressed fb of format other RGB should not have been created, to be on the safer side. Added checks for BGR too. Bitmask is being used for the property to accommodate 2 more options expected to be added in future. This patch depends on Ville's patch series on fb->offsets. (Ref: git://github.com/vsyrjala/linux.git fb_offsets_14) Testing is in progress for v2 of the patch. Signed-off-by: Vandana KannanCc: Ville Syrjälä Cc: Smith, Gary K --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 22 + drivers/gpu/drm/i915/intel_atomic_plane.c | 24 +- drivers/gpu/drm/i915/intel_display.c | 135 +- drivers/gpu/drm/i915/intel_drv.h | 10 +++ drivers/gpu/drm/i915/intel_sprite.c | 27 +- 6 files changed, 213 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 32f0597..ba32e7c 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1901,6 +1901,7 @@ struct drm_i915_private { struct drm_property *broadcast_rgb_property; struct drm_property *force_audio_property; + struct drm_property *render_comp_property; /* hda/i915 audio component */ struct i915_audio_component *audio_component; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 25e229b..da45cc9 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -5816,6 +5816,28 @@ enum skl_disp_power_wells { _ID(id, _PS_ECC_STAT_1A, _PS_ECC_STAT_2A), \ _ID(id, _PS_ECC_STAT_1B, _PS_ECC_STAT_2B)) +#define PLANE_AUX_DIST_1_A 0x701c0 +#define PLANE_AUX_DIST_2_A 0x702c0 +#define PLANE_AUX_DIST_1_B 0x711c0 +#define PLANE_AUX_DIST_2_B 0x712c0 +#define _PLANE_AUX_DIST_1(pipe) \ + _PIPE(pipe, PLANE_AUX_DIST_1_A, PLANE_AUX_DIST_1_B) +#define _PLANE_AUX_DIST_2(pipe) \ + _PIPE(pipe, PLANE_AUX_DIST_2_A, PLANE_AUX_DIST_2_B) +#define PLANE_AUX_DIST(pipe, plane) \ + _MMIO_PLANE(plane, _PLANE_AUX_DIST_1(pipe), _PLANE_AUX_DIST_2(pipe)) + +#define PLANE_AUX_OFFSET_1_A 0x701c4 +#define PLANE_AUX_OFFSET_2_A 0x702c4 +#define PLANE_AUX_OFFSET_1_B 0x711c4 +#define PLANE_AUX_OFFSET_2_B 0x712c4 +#define _PLANE_AUX_OFFSET_1(pipe) \ + _PIPE(pipe, PLANE_AUX_OFFSET_1_A, PLANE_AUX_OFFSET_1_B) +#define _PLANE_AUX_OFFSET_2(pipe) \ + _PIPE(pipe, PLANE_AUX_OFFSET_2_A, PLANE_AUX_OFFSET_2_B) +#define PLANE_AUX_OFFSET(pipe, plane) \ + _MMIO_PLANE(plane, _PLANE_AUX_OFFSET_1(pipe), _PLANE_AUX_OFFSET_2(pipe)) + /* legacy palette */ #define _LGC_PALETTE_A 0x4a000 #define _LGC_PALETTE_B 0x4a800 diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c index 7de7721..2617b75 100644 --- a/drivers/gpu/drm/i915/intel_atomic_plane.c +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c @@ -228,8 +228,16 @@
Re: [Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV
On Fri, 29 Apr 2016, Ville Syrjäläwrote: > On Fri, Apr 29, 2016 at 03:34:03PM +0300, Jani Nikula wrote: >> VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use >> the border enable software state for anything, so don't set it >> either. This should avoid a state checker warning on lvds_border_bits, >> although one hasn't been spotted in the wild. >> >> Signed-off-by: Jani Nikula >> --- >> drivers/gpu/drm/i915/intel_panel.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_panel.c >> b/drivers/gpu/drm/i915/intel_panel.c >> index 828f0fcaaaf8..d0606b8714a4 100644 >> --- a/drivers/gpu/drm/i915/intel_panel.c >> +++ b/drivers/gpu/drm/i915/intel_panel.c >> @@ -371,7 +371,8 @@ out: >> >> pipe_config->gmch_pfit.control = pfit_control; >> pipe_config->gmch_pfit.pgm_ratios = pfit_pgm_ratios; >> -pipe_config->gmch_pfit.lvds_border_bits = border; >> +if (INTEL_INFO(dev)->gen < 5) >> +pipe_config->gmch_pfit.lvds_border_bits = border; > > Shouldn't actually be needed since we reject the "center" scaling mode > on eDP and DSI, and that's the only one to use the border bit on gen4+. > So no way to get here w/ border!=0 on VLV/CHV I think. Right. It's more than a little tricky to check all the places to make sure... BR, Jani. > >> } >> >> enum drm_connector_status >> -- >> 2.1.4 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV
On Fri, Apr 29, 2016 at 03:34:03PM +0300, Jani Nikula wrote: > VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use > the border enable software state for anything, so don't set it > either. This should avoid a state checker warning on lvds_border_bits, > although one hasn't been spotted in the wild. > > Signed-off-by: Jani Nikula> --- > drivers/gpu/drm/i915/intel_panel.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index 828f0fcaaaf8..d0606b8714a4 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -371,7 +371,8 @@ out: > > pipe_config->gmch_pfit.control = pfit_control; > pipe_config->gmch_pfit.pgm_ratios = pfit_pgm_ratios; > - pipe_config->gmch_pfit.lvds_border_bits = border; > + if (INTEL_INFO(dev)->gen < 5) > + pipe_config->gmch_pfit.lvds_border_bits = border; Shouldn't actually be needed since we reject the "center" scaling mode on eDP and DSI, and that's the only one to use the border bit on gen4+. So no way to get here w/ border!=0 on VLV/CHV I think. > } > > enum drm_connector_status > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/lvds: separate border enable readout from panel fitter
On Fri, Apr 29, 2016 at 03:34:02PM +0300, Jani Nikula wrote: > The LVDS border enable is independent from the panel fitter. Move the > readout of the "border bits" from i9xx_get_pfit_config() to > intel_lvds_get_config(), where it will be read if LVDS is enabled even > if the panel fitter is not. > > This fixes the state checker warning: > > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in > gmch_pfit.lvds_border_bits (expected 0x8000, found 0x) > > Cc: Ville Syrjälä> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632 > Signed-off-by: Jani Nikula Makes sense to me Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_display.c | 3 --- > drivers/gpu/drm/i915/intel_lvds.c| 4 > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 5ffccf6e7f36..0fccebbd41a3 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8022,9 +8022,6 @@ static void i9xx_get_pfit_config(struct intel_crtc > *crtc, > > pipe_config->gmch_pfit.control = tmp; > pipe_config->gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS); > - if (INTEL_INFO(dev)->gen < 5) > - pipe_config->gmch_pfit.lvds_border_bits = > - I915_READ(LVDS) & LVDS_BORDER_ENABLE; > } > > static void vlv_crtc_clock_get(struct intel_crtc *crtc, > diff --git a/drivers/gpu/drm/i915/intel_lvds.c > b/drivers/gpu/drm/i915/intel_lvds.c > index 66e832beeb37..bc53c0dd34d0 100644 > --- a/drivers/gpu/drm/i915/intel_lvds.c > +++ b/drivers/gpu/drm/i915/intel_lvds.c > @@ -122,6 +122,10 @@ static void intel_lvds_get_config(struct intel_encoder > *encoder, > > pipe_config->base.adjusted_mode.flags |= flags; > > + if (INTEL_INFO(dev)->gen < 5) > + pipe_config->gmch_pfit.lvds_border_bits = > + tmp & LVDS_BORDER_ENABLE; > + > /* gen2/3 store dither state in pfit control, needs to match */ > if (INTEL_INFO(dev)->gen < 4) { > tmp = I915_READ(PFIT_CONTROL); > -- > 2.1.4 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/lvds: separate border enable readout from panel fitter
== Series Details == Series: series starting with [1/2] drm/i915/lvds: separate border enable readout from panel fitter URL : https://patchwork.freedesktop.org/series/6535/ State : success == Summary == Series 6535v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/6535/revisions/1/mbox/ bdw-nuci7-2 total:201 pass:189 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:201 pass:176 dwarn:0 dfail:0 fail:0 skip:25 bsw-nuc-2total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 byt-nuc total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 hsw-brixbox total:201 pass:175 dwarn:0 dfail:0 fail:0 skip:26 hsw-gt2 total:201 pass:179 dwarn:0 dfail:0 fail:1 skip:21 ilk-hp8440p total:201 pass:140 dwarn:0 dfail:0 fail:0 skip:61 ivb-t430stotal:201 pass:170 dwarn:0 dfail:0 fail:0 skip:31 skl-i7k-2total:201 pass:174 dwarn:0 dfail:0 fail:0 skip:27 skl-nuci5total:201 pass:190 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:201 pass:159 dwarn:0 dfail:0 fail:0 skip:42 snb-x220ttotal:201 pass:159 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/Patchwork_2114/ 1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 2016y-04m-29d-09h-21m-52s UTC integration manifest b1884d4 drm/i915: do not set border enable software state for VLV/CHV 7a750ca drm/i915/lvds: separate border enable readout from panel fitter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] autotools, assembler: Fix check target for tests in assembler.
assembler suffers from the same issue as lib/tests, adjust it so it allows us to do a check. Have to make autotools happy by having an empty Makefile.am. Signed-off-by: Marius Vlad--- assembler/Makefile.am | 108 - assembler/test/Makefile.am | 93 -- assembler/test/run-test.sh | 2 +- 3 files changed, 107 insertions(+), 96 deletions(-) diff --git a/assembler/Makefile.am b/assembler/Makefile.am index fb309ac..bed6c07 100644 --- a/assembler/Makefile.am +++ b/assembler/Makefile.am @@ -47,8 +47,112 @@ intel_gen4disasm_LDADD = libbrw.la pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = intel-gen4asm.pc -CLEANFILES = $(BUILT_SOURCES) +check_SCRIPTS = test/run-test.sh + +TESTS = \ + test/mov \ + test/frc \ + test/rndd \ + test/rndu \ + test/rnde \ + test/rnde-intsrc \ + test/rndz \ + test/lzd \ + test/not \ + test/immediate \ + $(NULL) + +# Tests that are expected to fail because they contain some inccorect code. +XFAIL_TESTS = + +# Those tests were already failing when the assembler was imported from +# the intel-gen4asm git repository: +# http://cgit.freedesktop.org/xorg/app/intel-gen4asm/ +# We disable them "for now" as a workaround to be able to release i-g-t +disabled_tests = \ + test/declare \ + test/jmpi \ + test/if \ + test/iff \ + test/while \ + test/else \ + test/break \ + test/cont \ + test/halt \ + test/wait \ + test/endif \ + $(NULL) + +disabled_xfail_tests = \ + test/rnde-intsrc \ + $(NULL) + +TESTDATA = \ + test/mov.expected \ + test/mov.g4a \ + test/frc.expected \ + test/frc.g4a \ + test/rndd.expected \ + test/rndd.g4a \ + test/rndu.expected \ + test/rndu.g4a \ + test/rnde.expected \ + test/rnde.g4a \ + test/rnde-intsrc.expected \ + test/rnde-intsrc.g4a \ + test/rndz.expected \ + test/rndz.g4a \ + test/lzd.expected \ + test/lzd.g4a \ + test/not.expected \ + test/not.g4a \ + test/jmpi.expected \ + test/jmpi.g4a \ + test/if.expected \ + test/if.g4a \ + test/iff.expected \ + test/iff.g4a \ + test/while.expected \ + test/while.g4a \ + test/else.expected \ + test/else.g4a \ + test/break.expected \ + test/break.g4a \ + test/cont.expected \ + test/cont.g4a \ + test/halt.expected \ + test/halt.g4a \ + test/wait.expected \ + test/wait.g4a \ + test/endif.expected \ + test/endif.g4a \ + test/declare.expected \ + test/declare.g4a \ + test/immediate.g4a \ + test/immediate.expected \ + $(NULL) + +test_EXTRA_DIST = \ + ${TESTDATA} \ + test/run-test.sh \ + $(NULL) + +$(TESTS): test/run-test.sh + sed "s|TEST|$@|g" ${srcdir}/test/run-test.sh > $@ + chmod +x $@ + +test_CLEANFILES = \ + test/*.out \ + ${TESTS} \ + $(NULL) + +CLEANFILES = $(BUILT_SOURCES) \ +$(test_CLEANFILES) \ +$(NULL) + EXTRA_DIST = \ README \ TODO \ - intel-gen4asm.pc.in + intel-gen4asm.pc.in \ + $(test_EXTRA_DIST) \ + $(NULL) diff --git a/assembler/test/Makefile.am b/assembler/test/Makefile.am index f113119..e69de29 100644 --- a/assembler/test/Makefile.am +++ b/assembler/test/Makefile.am @@ -1,93 +0,0 @@ -check_SCRIPTS = run-test.sh - -TESTS_ENVIRONMENT = top_builddir=${top_builddir} -TESTS = \ - mov \ - frc \ - rndd \ - rndu \ - rnde \ - rnde-intsrc \ - rndz \ - lzd \ - not \ - immediate - -# Tests that are expected to fail because they contain some inccorect code. -XFAIL_TESTS = - -# Those tests were already failing when the assembler was imported from -# the intel-gen4asm git repository: -# http://cgit.freedesktop.org/xorg/app/intel-gen4asm/ -# We disable them "for now" as a workaround to be able to release i-g-t -disabled_tests = \ - declare \ - jmpi \ - if \ - iff \ - while \ - else \ - break \ - cont \ - halt \ - wait \ - endif - -disabled_xfail_tests = \ - rnde-intsrc - -TESTDATA = \ - mov.expected \ - mov.g4a \ - frc.expected \ - frc.g4a \ - rndd.expected \ - rndd.g4a \ - rndu.expected \ - rndu.g4a \ - rnde.expected \ - rnde.g4a \ - rnde-intsrc.expected \ - rnde-intsrc.g4a \ - rndz.expected \ - rndz.g4a \ - lzd.expected \ - lzd.g4a \ - not.expected \ - not.g4a \ - jmpi.expected \ - jmpi.g4a \ - if.expected \ - if.g4a \ - iff.expected \ - iff.g4a \ - while.expected \ - while.g4a \ - else.expected \ -
[Intel-gfx] [PATCH i-g-t 1/2] autotools: Check target requires to a have the list of tests built.
We need to have the test list generated before running the check target. Migrated igt_command_line.sh to tests/ from lib/tests/, which allows to building the tests and execute the script. This would allow cleaning followed by a make check. Signed-off-by: Marius Vlad--- lib/tests/Makefile.am | 1 - lib/tests/Makefile.sources| 3 -- lib/tests/igt_command_line.sh | 76 --- tests/Makefile.am | 2 +- tests/Makefile.sources| 8 + tests/igt_command_line.sh | 74 + 6 files changed, 83 insertions(+), 81 deletions(-) delete mode 100755 lib/tests/igt_command_line.sh create mode 100755 tests/igt_command_line.sh diff --git a/lib/tests/Makefile.am b/lib/tests/Makefile.am index 582cc3e..99ab724 100644 --- a/lib/tests/Makefile.am +++ b/lib/tests/Makefile.am @@ -4,7 +4,6 @@ AM_TESTS_ENVIRONMENT = \ top_builddir=$(top_builddir) \ top_srcdir=$(top_srcdir) -EXTRA_DIST = $(check_SCRIPTS) AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS) \ -I$(srcdir)/../.. \ diff --git a/lib/tests/Makefile.sources b/lib/tests/Makefile.sources index 707c445..37126f1 100644 --- a/lib/tests/Makefile.sources +++ b/lib/tests/Makefile.sources @@ -15,9 +15,6 @@ check_PROGRAMS = \ igt_exit_handler \ $(NULL) -check_SCRIPTS = \ - igt_command_line.sh \ - $(NULL) TESTS = \ $(check_PROGRAMS) \ diff --git a/lib/tests/igt_command_line.sh b/lib/tests/igt_command_line.sh deleted file mode 100755 index e83a548..000 --- a/lib/tests/igt_command_line.sh +++ /dev/null @@ -1,76 +0,0 @@ -#!/bin/sh -# -# Copyright © 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. - -# -# Check that command line handling works consistently across all tests -# - -TESTLIST=`cat $top_builddir/tests/test-list.txt` -if [ $? -ne 0 ]; then - echo "Error: Could not read test lists" - exit 99 -fi - -for test in $TESTLIST; do - - if [ "$test" = "TESTLIST" -o "$test" = "END" ]; then - continue - fi - - if [ -x $top_builddir/tests/$test ]; then - test=$top_builddir/tests/$test - else - # if the test is a script, it will be in $srcdir - test=$top_srcdir/tests/$test - fi - - echo "$test:" - - # check invalid option handling - echo " Checking invalid option handling..." - ./$test --invalid-option 2> /dev/null && exit 1 - - # check valid options succeed - echo " Checking valid option handling..." - ./$test --help > /dev/null || exit 1 - - # check --list-subtests works correctly - echo " Checking subtest enumeration..." - LIST=`./$test --list-subtests` - RET=$? - if [ $RET -ne 0 -a $RET -ne 79 ]; then - exit 1 - fi - - if [ $RET -eq 79 -a -n "$LIST" ]; then - exit 1 - fi - - if [ $RET -eq 0 -a -z "$LIST" ]; then - exit 1 - fi - - # check invalid subtest handling - echo " Checking invalid subtest handling..." - ./$test --run-subtest invalid-subtest > /dev/null 2>&1 && exit 1 -done diff --git a/tests/Makefile.am b/tests/Makefile.am index 45e3359..79a7324 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -49,7 +49,7 @@ all-local: .gitignore pkgdata_DATA = test-list.txt test-list-full.txt EXTRA_PROGRAMS = $(HANG) -EXTRA_DIST = $(common_files) +EXTRA_DIST = $(common_files) $(check_SCRIPTS) CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt test-list-full.txt .gitignore diff --git a/tests/Makefile.sources b/tests/Makefile.sources index b73f48d..28e8695 100644 --- a/tests/Makefile.sources +++ b/tests/Makefile.sources @@ -287,6 +287,14 @@ testdisplay_SOURCES = \ TESTS_progs += testdisplay +check_SCRIPTS = \ +
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy
== Series Details == Series: series starting with [CI,1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy URL : https://patchwork.freedesktop.org/series/6534/ State : success == Summary == Series 6534v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/6534/revisions/1/mbox/ bdw-nuci7-2 total:201 pass:189 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:201 pass:176 dwarn:0 dfail:0 fail:0 skip:25 bsw-nuc-2total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 byt-nuc total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 hsw-brixbox total:201 pass:175 dwarn:0 dfail:0 fail:0 skip:26 hsw-gt2 total:201 pass:179 dwarn:0 dfail:0 fail:1 skip:21 ilk-hp8440p total:201 pass:140 dwarn:0 dfail:0 fail:0 skip:61 ivb-t430stotal:201 pass:170 dwarn:0 dfail:0 fail:0 skip:31 skl-i7k-2total:201 pass:174 dwarn:0 dfail:0 fail:0 skip:27 skl-nuci5total:201 pass:190 dwarn:0 dfail:0 fail:0 skip:11 snb-x220ttotal:201 pass:159 dwarn:0 dfail:0 fail:1 skip:41 snb-dellxps failed to collect. IGT log at Patchwork_2113/snb-dellxps/igt.log Results at /archive/results/CI_IGT_test/Patchwork_2113/ 1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 2016y-04m-29d-09h-21m-52s UTC integration manifest f2387cc drm/i915: Reload PD tables after semaphore wait on gen8 88d4855 drm/i915: Fix serialisation of pipecontrol write vs semaphore signal dd37b7e drm/i915: Fix gen8 semaphores id for legacy mode 5cdc2fe drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists 833e61b drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/19] drm/i915: Unify unpin_work and mmio_work into flip_work.
On Tue, Apr 19, 2016 at 09:52:25AM +0200, Maarten Lankhorst wrote: > Rename intel_unpin_work to intel_flip_work and use it for mmio flips > and unpinning. Use flip_queued_req to hold the wait request in the > mmio case, and the vblank counter from intel_crtc_get_vblank_counter. > > Signed-off-by: Maarten LankhorstReviewed-by: Patrik Jakobsson > --- > drivers/gpu/drm/i915/i915_debugfs.c | 6 +- > drivers/gpu/drm/i915/intel_display.c | 189 > +++ > drivers/gpu/drm/i915/intel_drv.h | 19 ++-- > drivers/gpu/drm/i915/intel_sprite.c | 8 +- > 4 files changed, 98 insertions(+), 124 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index def95532d421..aabd7a13cec7 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -604,10 +604,10 @@ static int i915_gem_pageflip_info(struct seq_file *m, > void *data) > for_each_intel_crtc(dev, crtc) { > const char pipe = pipe_name(crtc->pipe); > const char plane = plane_name(crtc->plane); > - struct intel_unpin_work *work; > + struct intel_flip_work *work; > > spin_lock_irq(>event_lock); > - work = crtc->unpin_work; > + work = crtc->flip_work; > if (work == NULL) { > seq_printf(m, "No flip due on pipe %c (plane %c)\n", > pipe, plane); > @@ -637,7 +637,7 @@ static int i915_gem_pageflip_info(struct seq_file *m, > void *data) > seq_printf(m, "Flip queued on frame %d, (was ready on > frame %d), now %d\n", > work->flip_queued_vblank, > work->flip_ready_vblank, > -drm_crtc_vblank_count(>base)); > +intel_crtc_get_vblank_counter(crtc)); > seq_printf(m, "%d prepares\n", > atomic_read(>pending)); > > if (INTEL_INFO(dev)->gen >= 4) > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 2086e8bd10da..1d7ef9fb526c 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -48,6 +48,11 @@ > #include > #include > > +static bool is_mmio_work(struct intel_flip_work *work) > +{ > + return work->mmio_work.func; > +} > + > /* Primary plane formats for gen <= 3 */ > static const uint32_t i8xx_primary_formats[] = { > DRM_FORMAT_C8, > @@ -3302,7 +3307,7 @@ static bool intel_crtc_has_pending_flip(struct drm_crtc > *crtc) > return false; > > spin_lock_irq(>event_lock); > - pending = to_intel_crtc(crtc)->unpin_work != NULL; > + pending = to_intel_crtc(crtc)->flip_work != NULL; > spin_unlock_irq(>event_lock); > > return pending; > @@ -3881,7 +3886,7 @@ bool intel_has_pending_fb_unpin(struct drm_device *dev) > if (atomic_read(>unpin_work_count) == 0) > continue; > > - if (crtc->unpin_work) > + if (crtc->flip_work) > intel_wait_for_vblank(dev, crtc->pipe); > > return true; > @@ -3893,9 +3898,9 @@ bool intel_has_pending_fb_unpin(struct drm_device *dev) > static void page_flip_completed(struct intel_crtc *intel_crtc) > { > struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev); > - struct intel_unpin_work *work = intel_crtc->unpin_work; > + struct intel_flip_work *work = intel_crtc->flip_work; > > - intel_crtc->unpin_work = NULL; > + intel_crtc->flip_work = NULL; > > if (work->event) > drm_crtc_send_vblank_event(_crtc->base, work->event); > @@ -3903,7 +3908,7 @@ static void page_flip_completed(struct intel_crtc > *intel_crtc) > drm_crtc_vblank_put(_crtc->base); > > wake_up_all(_priv->pending_flip_queue); > - queue_work(dev_priv->wq, >work); > + queue_work(dev_priv->wq, >unpin_work); > > trace_i915_flip_complete(intel_crtc->plane, >work->pending_flip_obj); > @@ -3927,9 +3932,11 @@ static int intel_crtc_wait_for_pending_flips(struct > drm_crtc *crtc) > > if (ret == 0) { > struct intel_crtc *intel_crtc = to_intel_crtc(crtc); > + struct intel_flip_work *work; > > spin_lock_irq(>event_lock); > - if (intel_crtc->unpin_work) { > + work = intel_crtc->flip_work; > + if (work && !is_mmio_work(work)) { > WARN_ONCE(1, "Removing stuck page flip\n"); > page_flip_completed(intel_crtc); > } > @@ -6328,7 +6335,7 @@ static void intel_crtc_disable_noatomic(struct drm_crtc > *crtc) > return; > > if
[Intel-gfx] [PATCH i-g-t] tools/intel_watermark: Dump linetime watermarks on hsw/bdw
From: Ville SyrjäläSigned-off-by: Ville Syrjälä --- tools/intel_watermark.c | 46 -- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/tools/intel_watermark.c b/tools/intel_watermark.c index 0b7c5e5193ef..133c058aee97 100644 --- a/tools/intel_watermark.c +++ b/tools/intel_watermark.c @@ -95,6 +95,9 @@ struct ilk_wm_level { struct ilk_wm { struct ilk_wm_level pipe[3]; + struct { + int linetime, ips; + } linetime[3]; struct ilk_wm_level lp[3]; }; @@ -133,6 +136,7 @@ static void ilk_wm_dump(void) uint32_t dspcntr[3]; uint32_t spcntr[3]; uint32_t wm_pipe[3]; + uint32_t wm_linetime[3]; uint32_t wm_lp[3]; uint32_t wm_lp_spr[3]; uint32_t arb_ctl, arb_ctl2, wm_misc = 0; @@ -153,6 +157,13 @@ static void ilk_wm_dump(void) wm_pipe[1] = read_reg(0x45104); if (num_pipes == 3) wm_pipe[2] = read_reg(0x45200); + + if (is_hsw_plus(devid)) { + wm_linetime[0] = read_reg(0x45270); + wm_linetime[1] = read_reg(0x45274); + wm_linetime[2] = read_reg(0x45278); + } + wm_lp[0] = read_reg(0x45108); wm_lp[1] = read_reg(0x4510c); wm_lp[2] = read_reg(0x45110); @@ -171,25 +182,34 @@ static void ilk_wm_dump(void) intel_register_access_fini(); for (i = 0; i < num_pipes; i++) - printf(" WM_PIPE_%c = 0x%08x\n", pipe_name(i), wm_pipe[i]); - printf(" WM_LP1 = 0x%08x\n", wm_lp[0]); - printf(" WM_LP2 = 0x%08x\n", wm_lp[1]); - printf(" WM_LP3 = 0x%08x\n", wm_lp[2]); - printf(" WM_LP1_SPR = 0x%08x\n", wm_lp_spr[0]); + printf("WM_PIPE_%c = 0x%08x\n", pipe_name(i), wm_pipe[i]); + if (is_hsw_plus(devid)) { + for (i = 0; i < num_pipes; i++) + printf("WM_LINETIME_%c = 0x%08x\n", pipe_name(i), wm_linetime[i]); + } + printf(" WM_LP1 = 0x%08x\n", wm_lp[0]); + printf(" WM_LP2 = 0x%08x\n", wm_lp[1]); + printf(" WM_LP3 = 0x%08x\n", wm_lp[2]); + printf(" WM_LP1_SPR = 0x%08x\n", wm_lp_spr[0]); if (is_gen7_plus(devid)) { - printf(" WM_LP2_SPR = 0x%08x\n", wm_lp_spr[1]); - printf(" WM_LP3_SPR = 0x%08x\n", wm_lp_spr[2]); + printf(" WM_LP2_SPR = 0x%08x\n", wm_lp_spr[1]); + printf(" WM_LP3_SPR = 0x%08x\n", wm_lp_spr[2]); } - printf("ARB_CTL = 0x%08x\n", arb_ctl); - printf(" ARB_CTL2 = 0x%08x\n", arb_ctl2); + printf(" ARB_CTL = 0x%08x\n", arb_ctl); + printf(" ARB_CTL2 = 0x%08x\n", arb_ctl2); if (is_hsw_plus(devid)) - printf("WM_MISC = 0x%08x\n", wm_misc); + printf(" WM_MISC = 0x%08x\n", wm_misc); for (i = 0 ; i < num_pipes; i++) { wm.pipe[i].primary = REG_DECODE1(wm_pipe[i], 16, 8); wm.pipe[i].sprite = REG_DECODE1(wm_pipe[i], 8, 8); wm.pipe[i].cursor = REG_DECODE1(wm_pipe[i], 0, 6); + if (is_hsw_plus(devid)) { + wm.linetime[i].linetime = REG_DECODE1(wm_linetime[i], 0, 9); + wm.linetime[i].ips = REG_DECODE1(wm_linetime[i], 16, 9); + } + wm.pipe[i].primary_trickle_feed_dis = REG_DECODE1(dspcntr[i], 14, 1); if (!IS_GEN5(devid)) @@ -218,6 +238,12 @@ static void ilk_wm_dump(void) printf("WM_PIPE_%c: primary=%d, cursor=%d, sprite=%d\n", pipe_name(i), wm.pipe[i].primary, wm.pipe[i].cursor, wm.pipe[i].sprite); } + if (is_hsw_plus(devid)) { + for (i = 0; i < num_pipes; i++) { + printf("WM_LINETIME_%c: line time=%d, ips line time=%d\n", + pipe_name(i), wm.linetime[i].linetime, wm.linetime[i].ips); + } + } if (is_gen7_plus(devid)) { for (i = 0; i < 3; i++) { printf("WM_LP%d: %s, latency=%d, fbc=%d, primary=%d, cursor=%d, sprite=%d\n", -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled
On Fri, 29 Apr 2016, Ville Syrjäläwrote: > On Fri, Apr 29, 2016 at 01:12:33PM +0300, Ville Syrjälä wrote: >> On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote: >> > We also don't read the border bits in i9xx_get_pfit_config() when the >> > panel fitter is not enabled, causing the state checker warning: >> > >> > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in >> > gmch_pfit.lvds_border_bits (expected 0x8000, found 0x) >> > >> > Cc: Ville Syrjälä >> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632 >> > Signed-off-by: Jani Nikula >> > --- >> > drivers/gpu/drm/i915/intel_panel.c | 1 + >> > 1 file changed, 1 insertion(+) >> > >> > diff --git a/drivers/gpu/drm/i915/intel_panel.c >> > b/drivers/gpu/drm/i915/intel_panel.c >> > index 828f0fcaaaf8..67cf2e22ba51 100644 >> > --- a/drivers/gpu/drm/i915/intel_panel.c >> > +++ b/drivers/gpu/drm/i915/intel_panel.c >> > @@ -363,6 +363,7 @@ out: >> >if ((pfit_control & PFIT_ENABLE) == 0) { >> >pfit_control = 0; >> >pfit_pgm_ratios = 0; >> > + border = 0; >> >> That doesn't seem right. We especially want the border for "center". Doh. > So after looking at this again, I think we should just move the border > bit readout to the lvds get_config() hook. Agreed. Patches sent [1]. > Or was there some magic reason for doing the readout in the wrong > place? Daniel? I tried to dig the history, didn't find anything. BR, Jani. [1] http://patchwork.freedesktop.org/patch/msgid/1461933243-2140-1-git-send-email-jani.nik...@intel.com -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/lvds: separate border enable readout from panel fitter
The LVDS border enable is independent from the panel fitter. Move the readout of the "border bits" from i9xx_get_pfit_config() to intel_lvds_get_config(), where it will be read if LVDS is enabled even if the panel fitter is not. This fixes the state checker warning: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 0x8000, found 0x) Cc: Ville SyrjäläBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632 Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_display.c | 3 --- drivers/gpu/drm/i915/intel_lvds.c| 4 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 5ffccf6e7f36..0fccebbd41a3 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8022,9 +8022,6 @@ static void i9xx_get_pfit_config(struct intel_crtc *crtc, pipe_config->gmch_pfit.control = tmp; pipe_config->gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS); - if (INTEL_INFO(dev)->gen < 5) - pipe_config->gmch_pfit.lvds_border_bits = - I915_READ(LVDS) & LVDS_BORDER_ENABLE; } static void vlv_crtc_clock_get(struct intel_crtc *crtc, diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index 66e832beeb37..bc53c0dd34d0 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -122,6 +122,10 @@ static void intel_lvds_get_config(struct intel_encoder *encoder, pipe_config->base.adjusted_mode.flags |= flags; + if (INTEL_INFO(dev)->gen < 5) + pipe_config->gmch_pfit.lvds_border_bits = + tmp & LVDS_BORDER_ENABLE; + /* gen2/3 store dither state in pfit control, needs to match */ if (INTEL_INFO(dev)->gen < 4) { tmp = I915_READ(PFIT_CONTROL); -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: do not set border enable software state for VLV/CHV
VLV/CHV use intel_gmch_panel_fitting() for eDP and DSI. They don't use the border enable software state for anything, so don't set it either. This should avoid a state checker warning on lvds_border_bits, although one hasn't been spotted in the wild. Signed-off-by: Jani Nikula--- drivers/gpu/drm/i915/intel_panel.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 828f0fcaaaf8..d0606b8714a4 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -371,7 +371,8 @@ out: pipe_config->gmch_pfit.control = pfit_control; pipe_config->gmch_pfit.pgm_ratios = pfit_pgm_ratios; - pipe_config->gmch_pfit.lvds_border_bits = border; + if (INTEL_INFO(dev)->gen < 5) + pipe_config->gmch_pfit.lvds_border_bits = border; } enum drm_connector_status -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/5] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists
The i915.enable_ppgtt option depends upon the state of i915.enable_execlists option - so we need to sanitize execlists first. Signed-off-by: Chris WilsonReviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_dma.c | 13 + drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_gem.c | 3 --- drivers/gpu/drm/i915/i915_gem_gtt.c | 16 +--- drivers/gpu/drm/i915/intel_lrc.c| 2 -- 5 files changed, 20 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index f69330cf0118..c91387f1aedd 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -968,6 +968,19 @@ static void intel_device_info_runtime_init(struct drm_device *dev) info->has_subslice_pg ? "y" : "n"); DRM_DEBUG_DRIVER("has EU power gating: %s\n", info->has_eu_pg ? "y" : "n"); + + i915.enable_execlists = + intel_sanitize_enable_execlists(dev, i915.enable_execlists); + + /* +* i915.enable_ppgtt is read-only, so do an early pass to validate the +* user's requested state against the hardware/driver capabilities. We +* do this now so that we can print out any log messages once rather +* than every time we check intel_enable_ppgtt(). +*/ + i915.enable_ppgtt = + intel_sanitize_enable_ppgtt(dev, i915.enable_ppgtt); + DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt); } static void intel_init_dpio(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 7d15930b69b1..02c619e7af05 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2753,6 +2753,8 @@ extern int i915_max_ioctl; extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state); extern int i915_resume_switcheroo(struct drm_device *dev); +int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt); + /* i915_dma.c */ void __printf(3, 4) __i915_printk(struct drm_i915_private *dev_priv, const char *level, diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 96fbc9ab4039..bd6061f177fe 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4901,9 +4901,6 @@ int i915_gem_init(struct drm_device *dev) struct drm_i915_private *dev_priv = dev->dev_private; int ret; - i915.enable_execlists = intel_sanitize_enable_execlists(dev, - i915.enable_execlists); - mutex_lock(>struct_mutex); if (!i915.enable_execlists) { diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 59a78f760b6b..364cf8236021 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -110,7 +110,7 @@ const struct i915_ggtt_view i915_ggtt_view_rotated = { .type = I915_GGTT_VIEW_ROTATED, }; -static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt) +int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt) { bool has_aliasing_ppgtt; bool has_full_ppgtt; @@ -123,12 +123,14 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt) if (intel_vgpu_active(dev)) has_full_ppgtt = false; /* emulation is too hard */ + if (!has_aliasing_ppgtt) + return 0; + /* * We don't allow disabling PPGTT for gen9+ as it's a requirement for * execlists, the sole mechanism available to submit work. */ - if (INTEL_INFO(dev)->gen < 9 && - (enable_ppgtt == 0 || !has_aliasing_ppgtt)) + if (enable_ppgtt == 0 && INTEL_INFO(dev)->gen < 9) return 0; if (enable_ppgtt == 1) @@ -3219,14 +3221,6 @@ int i915_ggtt_init_hw(struct drm_device *dev) if (intel_iommu_gfx_mapped) DRM_INFO("VT-d active for gfx access\n"); #endif - /* -* i915.enable_ppgtt is read-only, so do an early pass to validate the -* user's requested state against the hardware/driver capabilities. We -* do this now so that we can print out any log messages once rather -* than every time we check intel_enable_ppgtt(). -*/ - i915.enable_ppgtt = sanitize_enable_ppgtt(dev, i915.enable_ppgtt); - DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt); return 0; diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index b2a9072c5753..d8763524319d 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -248,8 +248,6 @@ static int intel_lr_context_pin(struct intel_context *ctx, */ int intel_sanitize_enable_execlists(struct drm_device *dev, int enable_execlists) { -
[Intel-gfx] [CI 5/5] drm/i915: Reload PD tables after semaphore wait on gen8
When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by: Chris WilsonCc: Ville Syrjälä Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 533ebbd384f6..70738a54ed0f 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1481,6 +1481,7 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req, { struct intel_engine_cs *waiter = waiter_req->engine; struct drm_i915_private *dev_priv = waiter->dev->dev_private; + struct i915_hw_ppgtt *ppgtt; int ret; ret = intel_ring_begin(waiter_req, 4); @@ -1496,6 +1497,15 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req, intel_ring_emit(waiter, upper_32_bits(GEN8_WAIT_OFFSET(waiter, signaller->id))); intel_ring_advance(waiter); + + /* When the !RCS engines idle waiting upon a semaphore, they lose their +* pagetables and we must reload them before executing the batch. +* We do this on the i915_switch_context() following the wait and +* before the dispatch. +*/ + ppgtt = waiter_req->ctx->ppgtt; + if (ppgtt && waiter_req->engine->id != RCS) + ppgtt->pd_dirty_rings |= intel_engine_flag(waiter_req->engine); return 0; } -- 2.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/5] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by: Chris WilsonReviewed-by: Ville Syrjälä Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index ef3468956fae..533ebbd384f6 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1307,7 +1307,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request *signaller_req, intel_ring_emit(signaller, GFX_OP_PIPE_CONTROL(6)); intel_ring_emit(signaller, PIPE_CONTROL_GLOBAL_GTT_IVB | PIPE_CONTROL_QW_WRITE | - PIPE_CONTROL_FLUSH_ENABLE); + PIPE_CONTROL_CS_STALL); intel_ring_emit(signaller, lower_32_bits(gtt_offset)); intel_ring_emit(signaller, upper_32_bits(gtt_offset)); intel_ring_emit(signaller, seqno); @@ -1489,7 +1489,6 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req, intel_ring_emit(waiter, MI_SEMAPHORE_WAIT | MI_SEMAPHORE_GLOBAL_GTT | - MI_SEMAPHORE_POLL | MI_SEMAPHORE_SAD_GTE_SDD); intel_ring_emit(waiter, seqno); intel_ring_emit(waiter, -- 2.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/5] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy
For legacy ringbuffer mode, we need the new ordered breadcrumb emission tried and tested on execlists in order to avoid the dreaded "missed interrupt" syndrome. A secondary advantage of the execlists method is that it writes to an arbitrary address, useful if one wants to write a breadcrumb elsewhere. This fix is taken from commit 7c17d377374dd (drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists). Signed-off-by: Chris WilsonCc: Mika Kuoppala Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_lrc.c| 10 +++--- drivers/gpu/drm/i915/intel_ringbuffer.c | 32 ++-- drivers/gpu/drm/i915/intel_ringbuffer.h | 5 + 3 files changed, 38 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index ec2522243b5e..b2a9072c5753 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1767,11 +1767,6 @@ static void bxt_a_set_seqno(struct intel_engine_cs *engine, u32 seqno) */ #define WA_TAIL_DWORDS 2 -static inline u32 hws_seqno_address(struct intel_engine_cs *engine) -{ - return engine->status_page.gfx_addr + I915_GEM_HWS_INDEX_ADDR; -} - static int gen8_emit_request(struct drm_i915_gem_request *request) { struct intel_ringbuffer *ringbuf = request->ringbuf; @@ -1787,7 +1782,7 @@ static int gen8_emit_request(struct drm_i915_gem_request *request) intel_logical_ring_emit(ringbuf, (MI_FLUSH_DW + 1) | MI_FLUSH_DW_OP_STOREDW); intel_logical_ring_emit(ringbuf, - hws_seqno_address(request->engine) | + intel_hws_seqno_address(request->engine) | MI_FLUSH_DW_USE_GTT); intel_logical_ring_emit(ringbuf, 0); intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request)); @@ -1817,7 +1812,8 @@ static int gen8_emit_request_render(struct drm_i915_gem_request *request) (PIPE_CONTROL_GLOBAL_GTT_IVB | PIPE_CONTROL_CS_STALL | PIPE_CONTROL_QW_WRITE)); - intel_logical_ring_emit(ringbuf, hws_seqno_address(request->engine)); + intel_logical_ring_emit(ringbuf, + intel_hws_seqno_address(request->engine)); intel_logical_ring_emit(ringbuf, 0); intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request)); /* We're thrashing one dword of HWS. */ diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index c7637ceec1f4..c1472d62b663 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1430,6 +1430,35 @@ gen6_add_request(struct drm_i915_gem_request *req) return 0; } +static int +gen8_render_add_request(struct drm_i915_gem_request *req) +{ + struct intel_engine_cs *engine = req->engine; + int ret; + + if (engine->semaphore.signal) + ret = engine->semaphore.signal(req, 8); + else + ret = intel_ring_begin(req, 8); + if (ret) + return ret; + + intel_ring_emit(engine, GFX_OP_PIPE_CONTROL(6)); + intel_ring_emit(engine, (PIPE_CONTROL_GLOBAL_GTT_IVB | +PIPE_CONTROL_CS_STALL | +PIPE_CONTROL_QW_WRITE)); + intel_ring_emit(engine, intel_hws_seqno_address(req->engine)); + intel_ring_emit(engine, 0); + intel_ring_emit(engine, i915_gem_request_get_seqno(req)); + /* We're thrashing one dword of HWS. */ + intel_ring_emit(engine, 0); + intel_ring_emit(engine, MI_USER_INTERRUPT); + intel_ring_emit(engine, MI_NOOP); + __intel_ring_advance(engine); + + return 0; +} + static inline bool i915_gem_has_seqno_wrapped(struct drm_device *dev, u32 seqno) { @@ -2751,12 +2780,11 @@ int intel_init_render_ring_buffer(struct drm_device *dev) } engine->init_context = intel_rcs_ctx_init; - engine->add_request = gen6_add_request; + engine->add_request = gen8_render_add_request; engine->flush = gen8_render_ring_flush; engine->irq_get = gen8_ring_get_irq; engine->irq_put = gen8_ring_put_irq; engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT; - engine->irq_seqno_barrier = gen6_seqno_barrier; engine->get_seqno = ring_get_seqno; engine->set_seqno = ring_set_seqno; if (i915_semaphore_is_enabled(dev)) { diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index d7082124eee3..55b0438b2fa1 100644 ---
[Intel-gfx] [CI 3/5] drm/i915: Fix gen8 semaphores id for legacy mode
With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add360522c876c25ef2ab1c94bdb509ab Signed-off-by: Chris WilsonCc: Tvrtko Ursulin Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +++-- drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index c1472d62b663..ef3468956fae 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1313,7 +1313,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request *signaller_req, intel_ring_emit(signaller, seqno); intel_ring_emit(signaller, 0); intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL | - MI_SEMAPHORE_TARGET(waiter->id)); + MI_SEMAPHORE_TARGET(waiter->hw_id)); intel_ring_emit(signaller, 0); } @@ -1353,7 +1353,7 @@ static int gen8_xcs_signal(struct drm_i915_gem_request *signaller_req, intel_ring_emit(signaller, upper_32_bits(gtt_offset)); intel_ring_emit(signaller, seqno); intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL | - MI_SEMAPHORE_TARGET(waiter->id)); + MI_SEMAPHORE_TARGET(waiter->hw_id)); intel_ring_emit(signaller, 0); } @@ -2759,6 +2759,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev) engine->name = "render ring"; engine->id = RCS; engine->exec_id = I915_EXEC_RENDER; + engine->hw_id = 0; engine->mmio_base = RENDER_RING_BASE; if (INTEL_INFO(dev)->gen >= 8) { @@ -2909,6 +2910,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev) engine->name = "bsd ring"; engine->id = VCS; engine->exec_id = I915_EXEC_BSD; + engine->hw_id = 1; engine->write_tail = ring_write_tail; if (INTEL_INFO(dev)->gen >= 6) { @@ -2987,6 +2989,7 @@ int intel_init_bsd2_ring_buffer(struct drm_device *dev) engine->name = "bsd2 ring"; engine->id = VCS2; engine->exec_id = I915_EXEC_BSD; + engine->hw_id = 4; engine->write_tail = ring_write_tail; engine->mmio_base = GEN8_BSD2_RING_BASE; @@ -3019,6 +3022,7 @@ int intel_init_blt_ring_buffer(struct drm_device *dev) engine->name = "blitter ring"; engine->id = BCS; engine->exec_id = I915_EXEC_BLT; + engine->hw_id = 2; engine->mmio_base = BLT_RING_BASE; engine->write_tail = ring_write_tail; @@ -3078,6 +3082,7 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev) engine->name = "video enhancement ring"; engine->id = VECS; engine->exec_id = I915_EXEC_VEBOX; + engine->hw_id = 3; engine->mmio_base = VEBOX_RING_BASE; engine->write_tail = ring_write_tail; diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index 55b0438b2fa1..723ff6160fbb 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h @@ -153,7 +153,8 @@ struct intel_engine_cs { #define I915_NUM_ENGINES 5 #define _VCS(n) (VCS + (n)) unsigned int exec_id; - unsigned int guc_id; + unsigned int hw_id; + unsigned int guc_id; /* XXX same as hw_id? */ u32 mmio_base; struct drm_device *dev; struct intel_ringbuffer *buffer; -- 2.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled
On Fri, Apr 29, 2016 at 01:12:33PM +0300, Ville Syrjälä wrote: > On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote: > > We also don't read the border bits in i9xx_get_pfit_config() when the > > panel fitter is not enabled, causing the state checker warning: > > > > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in > > gmch_pfit.lvds_border_bits (expected 0x8000, found 0x) > > > > Cc: Ville Syrjälä> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632 > > Signed-off-by: Jani Nikula > > --- > > drivers/gpu/drm/i915/intel_panel.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > > b/drivers/gpu/drm/i915/intel_panel.c > > index 828f0fcaaaf8..67cf2e22ba51 100644 > > --- a/drivers/gpu/drm/i915/intel_panel.c > > +++ b/drivers/gpu/drm/i915/intel_panel.c > > @@ -363,6 +363,7 @@ out: > > if ((pfit_control & PFIT_ENABLE) == 0) { > > pfit_control = 0; > > pfit_pgm_ratios = 0; > > + border = 0; > > That doesn't seem right. We especially want the border for "center". So after looking at this again, I think we should just move the border bit readout to the lvds get_config() hook. Or was there some magic reason for doing the readout in the wrong place? Daniel? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [CI,1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy
== Series Details == Series: series starting with [CI,1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy URL : https://patchwork.freedesktop.org/series/6532/ State : warning == Summary == Series 6532v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/6532/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (bsw-nuc-2) Test kms_force_connector_basic: Subgroup force-edid: pass -> SKIP (ivb-t430s) bdw-nuci7-2 total:201 pass:189 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:201 pass:176 dwarn:0 dfail:0 fail:0 skip:25 bsw-nuc-2total:200 pass:158 dwarn:1 dfail:0 fail:0 skip:41 byt-nuc total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 hsw-brixbox total:201 pass:175 dwarn:0 dfail:0 fail:0 skip:26 hsw-gt2 total:201 pass:179 dwarn:0 dfail:0 fail:1 skip:21 ilk-hp8440p total:201 pass:140 dwarn:0 dfail:0 fail:0 skip:61 ivb-t430stotal:201 pass:169 dwarn:0 dfail:0 fail:0 skip:32 skl-i7k-2total:201 pass:174 dwarn:0 dfail:0 fail:0 skip:27 skl-nuci5total:201 pass:190 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:201 pass:159 dwarn:0 dfail:0 fail:0 skip:42 snb-x220ttotal:201 pass:159 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/Patchwork_2112/ 1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 2016y-04m-29d-09h-21m-52s UTC integration manifest 3d3b8b2 drm/i915: Enable legacy/semaphores for CI 9a603b6 drm/i915: Enable semaphores for legacy submission on gen8 b208441 drm/i915: Reload PD tables after semaphore wait on gen8 f667059 drm/i915: Fix serialisation of pipecontrol write vs semaphore signal 95243ff drm/i915: Fix gen8 semaphores id for legacy mode 71cf798 drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists 006506f drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/gem: support BO freeing without dev->struct_mutex
On Fri, Apr 29, 2016 at 11:18:18AM -, Patchwork wrote: > == Series Details == > > Series: drm/gem: support BO freeing without dev->struct_mutex > URL : https://patchwork.freedesktop.org/series/6527/ > State : failure > > == Summary == > > Series 6527v1 drm/gem: support BO freeing without dev->struct_mutex > http://patchwork.freedesktop.org/api/1.0/series/6527/revisions/1/mbox/ > > Test drv_getparams_basic: > Subgroup basic-eu-total: > pass -> DMESG-WARN (bsw-nuc-2) Hmm, I guess that we call drm_gem_object_unreference on a unlocked path during init/fini. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 6/7] drm/i915: Enable semaphores for legacy submission on gen8
We have sufficient evidence from igt to support that semaphores are in a working state. Enabling semaphores now for legacy provides a better comparison of execlists against legacy ring submission. Signed-off-by: Chris WilsonAcked-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index d37c0a671eed..9fd221c97275 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -542,10 +542,6 @@ bool i915_semaphore_is_enabled(struct drm_device *dev) if (i915.enable_execlists) return false; - /* Until we get further testing... */ - if (IS_GEN8(dev)) - return false; - #ifdef CONFIG_INTEL_IOMMU /* Enable semaphores on SNB when IO remapping is off */ if (INTEL_INFO(dev)->gen == 6 && intel_iommu_gfx_mapped) -- 2.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 7/7] drm/i915: Enable legacy/semaphores for CI
--- drivers/gpu/drm/i915/intel_lrc.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index d8763524319d..0713acb52ce4 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -260,10 +260,6 @@ int intel_sanitize_enable_execlists(struct drm_device *dev, int enable_execlists if (enable_execlists == 0) return 0; - if (HAS_LOGICAL_RING_CONTEXTS(dev) && USES_PPGTT(dev) && - i915.use_mmio_flip >= 0) - return 1; - return 0; } -- 2.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/7] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists
The i915.enable_ppgtt option depends upon the state of i915.enable_execlists option - so we need to sanitize execlists first. Signed-off-by: Chris WilsonReviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_dma.c | 13 + drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_gem.c | 3 --- drivers/gpu/drm/i915/i915_gem_gtt.c | 16 +--- drivers/gpu/drm/i915/intel_lrc.c| 2 -- 5 files changed, 20 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index f69330cf0118..c91387f1aedd 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -968,6 +968,19 @@ static void intel_device_info_runtime_init(struct drm_device *dev) info->has_subslice_pg ? "y" : "n"); DRM_DEBUG_DRIVER("has EU power gating: %s\n", info->has_eu_pg ? "y" : "n"); + + i915.enable_execlists = + intel_sanitize_enable_execlists(dev, i915.enable_execlists); + + /* +* i915.enable_ppgtt is read-only, so do an early pass to validate the +* user's requested state against the hardware/driver capabilities. We +* do this now so that we can print out any log messages once rather +* than every time we check intel_enable_ppgtt(). +*/ + i915.enable_ppgtt = + intel_sanitize_enable_ppgtt(dev, i915.enable_ppgtt); + DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt); } static void intel_init_dpio(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 7d15930b69b1..02c619e7af05 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2753,6 +2753,8 @@ extern int i915_max_ioctl; extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t state); extern int i915_resume_switcheroo(struct drm_device *dev); +int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt); + /* i915_dma.c */ void __printf(3, 4) __i915_printk(struct drm_i915_private *dev_priv, const char *level, diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 96fbc9ab4039..bd6061f177fe 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4901,9 +4901,6 @@ int i915_gem_init(struct drm_device *dev) struct drm_i915_private *dev_priv = dev->dev_private; int ret; - i915.enable_execlists = intel_sanitize_enable_execlists(dev, - i915.enable_execlists); - mutex_lock(>struct_mutex); if (!i915.enable_execlists) { diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 59a78f760b6b..364cf8236021 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -110,7 +110,7 @@ const struct i915_ggtt_view i915_ggtt_view_rotated = { .type = I915_GGTT_VIEW_ROTATED, }; -static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt) +int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt) { bool has_aliasing_ppgtt; bool has_full_ppgtt; @@ -123,12 +123,14 @@ static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt) if (intel_vgpu_active(dev)) has_full_ppgtt = false; /* emulation is too hard */ + if (!has_aliasing_ppgtt) + return 0; + /* * We don't allow disabling PPGTT for gen9+ as it's a requirement for * execlists, the sole mechanism available to submit work. */ - if (INTEL_INFO(dev)->gen < 9 && - (enable_ppgtt == 0 || !has_aliasing_ppgtt)) + if (enable_ppgtt == 0 && INTEL_INFO(dev)->gen < 9) return 0; if (enable_ppgtt == 1) @@ -3219,14 +3221,6 @@ int i915_ggtt_init_hw(struct drm_device *dev) if (intel_iommu_gfx_mapped) DRM_INFO("VT-d active for gfx access\n"); #endif - /* -* i915.enable_ppgtt is read-only, so do an early pass to validate the -* user's requested state against the hardware/driver capabilities. We -* do this now so that we can print out any log messages once rather -* than every time we check intel_enable_ppgtt(). -*/ - i915.enable_ppgtt = sanitize_enable_ppgtt(dev, i915.enable_ppgtt); - DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt); return 0; diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index b2a9072c5753..d8763524319d 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -248,8 +248,6 @@ static int intel_lr_context_pin(struct intel_context *ctx, */ int intel_sanitize_enable_execlists(struct drm_device *dev, int enable_execlists) { -
[Intel-gfx] [CI 5/7] drm/i915: Reload PD tables after semaphore wait on gen8
When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by: Chris WilsonCc: Ville Syrjälä Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 533ebbd384f6..70738a54ed0f 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1481,6 +1481,7 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req, { struct intel_engine_cs *waiter = waiter_req->engine; struct drm_i915_private *dev_priv = waiter->dev->dev_private; + struct i915_hw_ppgtt *ppgtt; int ret; ret = intel_ring_begin(waiter_req, 4); @@ -1496,6 +1497,15 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req, intel_ring_emit(waiter, upper_32_bits(GEN8_WAIT_OFFSET(waiter, signaller->id))); intel_ring_advance(waiter); + + /* When the !RCS engines idle waiting upon a semaphore, they lose their +* pagetables and we must reload them before executing the batch. +* We do this on the i915_switch_context() following the wait and +* before the dispatch. +*/ + ppgtt = waiter_req->ctx->ppgtt; + if (ppgtt && waiter_req->engine->id != RCS) + ppgtt->pd_dirty_rings |= intel_engine_flag(waiter_req->engine); return 0; } -- 2.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/7] drm/i915: Fix serialisation of pipecontrol write vs semaphore signal
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by: Chris WilsonReviewed-by: Ville Syrjälä Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index ef3468956fae..533ebbd384f6 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1307,7 +1307,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request *signaller_req, intel_ring_emit(signaller, GFX_OP_PIPE_CONTROL(6)); intel_ring_emit(signaller, PIPE_CONTROL_GLOBAL_GTT_IVB | PIPE_CONTROL_QW_WRITE | - PIPE_CONTROL_FLUSH_ENABLE); + PIPE_CONTROL_CS_STALL); intel_ring_emit(signaller, lower_32_bits(gtt_offset)); intel_ring_emit(signaller, upper_32_bits(gtt_offset)); intel_ring_emit(signaller, seqno); @@ -1489,7 +1489,6 @@ gen8_ring_sync(struct drm_i915_gem_request *waiter_req, intel_ring_emit(waiter, MI_SEMAPHORE_WAIT | MI_SEMAPHORE_GLOBAL_GTT | - MI_SEMAPHORE_POLL | MI_SEMAPHORE_SAD_GTE_SDD); intel_ring_emit(waiter, seqno); intel_ring_emit(waiter, -- 2.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/7] drm/i915: Apply strongly ordered RCS breadcrumb to gen8/legacy
For legacy ringbuffer mode, we need the new ordered breadcrumb emission tried and tested on execlists in order to avoid the dreaded "missed interrupt" syndrome. A secondary advantage of the execlists method is that it writes to an arbitrary address, useful if one wants to write a breadcrumb elsewhere. This fix is taken from commit 7c17d377374dd (drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists). Signed-off-by: Chris WilsonCc: Mika Kuoppala Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_lrc.c| 10 +++--- drivers/gpu/drm/i915/intel_ringbuffer.c | 32 ++-- drivers/gpu/drm/i915/intel_ringbuffer.h | 5 + 3 files changed, 38 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index ec2522243b5e..b2a9072c5753 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1767,11 +1767,6 @@ static void bxt_a_set_seqno(struct intel_engine_cs *engine, u32 seqno) */ #define WA_TAIL_DWORDS 2 -static inline u32 hws_seqno_address(struct intel_engine_cs *engine) -{ - return engine->status_page.gfx_addr + I915_GEM_HWS_INDEX_ADDR; -} - static int gen8_emit_request(struct drm_i915_gem_request *request) { struct intel_ringbuffer *ringbuf = request->ringbuf; @@ -1787,7 +1782,7 @@ static int gen8_emit_request(struct drm_i915_gem_request *request) intel_logical_ring_emit(ringbuf, (MI_FLUSH_DW + 1) | MI_FLUSH_DW_OP_STOREDW); intel_logical_ring_emit(ringbuf, - hws_seqno_address(request->engine) | + intel_hws_seqno_address(request->engine) | MI_FLUSH_DW_USE_GTT); intel_logical_ring_emit(ringbuf, 0); intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request)); @@ -1817,7 +1812,8 @@ static int gen8_emit_request_render(struct drm_i915_gem_request *request) (PIPE_CONTROL_GLOBAL_GTT_IVB | PIPE_CONTROL_CS_STALL | PIPE_CONTROL_QW_WRITE)); - intel_logical_ring_emit(ringbuf, hws_seqno_address(request->engine)); + intel_logical_ring_emit(ringbuf, + intel_hws_seqno_address(request->engine)); intel_logical_ring_emit(ringbuf, 0); intel_logical_ring_emit(ringbuf, i915_gem_request_get_seqno(request)); /* We're thrashing one dword of HWS. */ diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index c7637ceec1f4..c1472d62b663 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1430,6 +1430,35 @@ gen6_add_request(struct drm_i915_gem_request *req) return 0; } +static int +gen8_render_add_request(struct drm_i915_gem_request *req) +{ + struct intel_engine_cs *engine = req->engine; + int ret; + + if (engine->semaphore.signal) + ret = engine->semaphore.signal(req, 8); + else + ret = intel_ring_begin(req, 8); + if (ret) + return ret; + + intel_ring_emit(engine, GFX_OP_PIPE_CONTROL(6)); + intel_ring_emit(engine, (PIPE_CONTROL_GLOBAL_GTT_IVB | +PIPE_CONTROL_CS_STALL | +PIPE_CONTROL_QW_WRITE)); + intel_ring_emit(engine, intel_hws_seqno_address(req->engine)); + intel_ring_emit(engine, 0); + intel_ring_emit(engine, i915_gem_request_get_seqno(req)); + /* We're thrashing one dword of HWS. */ + intel_ring_emit(engine, 0); + intel_ring_emit(engine, MI_USER_INTERRUPT); + intel_ring_emit(engine, MI_NOOP); + __intel_ring_advance(engine); + + return 0; +} + static inline bool i915_gem_has_seqno_wrapped(struct drm_device *dev, u32 seqno) { @@ -2751,12 +2780,11 @@ int intel_init_render_ring_buffer(struct drm_device *dev) } engine->init_context = intel_rcs_ctx_init; - engine->add_request = gen6_add_request; + engine->add_request = gen8_render_add_request; engine->flush = gen8_render_ring_flush; engine->irq_get = gen8_ring_get_irq; engine->irq_put = gen8_ring_put_irq; engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT; - engine->irq_seqno_barrier = gen6_seqno_barrier; engine->get_seqno = ring_get_seqno; engine->set_seqno = ring_set_seqno; if (i915_semaphore_is_enabled(dev)) { diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index d7082124eee3..55b0438b2fa1 100644 ---
[Intel-gfx] [CI 3/7] drm/i915: Fix gen8 semaphores id for legacy mode
With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add360522c876c25ef2ab1c94bdb509ab Signed-off-by: Chris WilsonCc: Tvrtko Ursulin Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 9 +++-- drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index c1472d62b663..ef3468956fae 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1313,7 +1313,7 @@ static int gen8_rcs_signal(struct drm_i915_gem_request *signaller_req, intel_ring_emit(signaller, seqno); intel_ring_emit(signaller, 0); intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL | - MI_SEMAPHORE_TARGET(waiter->id)); + MI_SEMAPHORE_TARGET(waiter->hw_id)); intel_ring_emit(signaller, 0); } @@ -1353,7 +1353,7 @@ static int gen8_xcs_signal(struct drm_i915_gem_request *signaller_req, intel_ring_emit(signaller, upper_32_bits(gtt_offset)); intel_ring_emit(signaller, seqno); intel_ring_emit(signaller, MI_SEMAPHORE_SIGNAL | - MI_SEMAPHORE_TARGET(waiter->id)); + MI_SEMAPHORE_TARGET(waiter->hw_id)); intel_ring_emit(signaller, 0); } @@ -2759,6 +2759,7 @@ int intel_init_render_ring_buffer(struct drm_device *dev) engine->name = "render ring"; engine->id = RCS; engine->exec_id = I915_EXEC_RENDER; + engine->hw_id = 0; engine->mmio_base = RENDER_RING_BASE; if (INTEL_INFO(dev)->gen >= 8) { @@ -2909,6 +2910,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev) engine->name = "bsd ring"; engine->id = VCS; engine->exec_id = I915_EXEC_BSD; + engine->hw_id = 1; engine->write_tail = ring_write_tail; if (INTEL_INFO(dev)->gen >= 6) { @@ -2987,6 +2989,7 @@ int intel_init_bsd2_ring_buffer(struct drm_device *dev) engine->name = "bsd2 ring"; engine->id = VCS2; engine->exec_id = I915_EXEC_BSD; + engine->hw_id = 4; engine->write_tail = ring_write_tail; engine->mmio_base = GEN8_BSD2_RING_BASE; @@ -3019,6 +3022,7 @@ int intel_init_blt_ring_buffer(struct drm_device *dev) engine->name = "blitter ring"; engine->id = BCS; engine->exec_id = I915_EXEC_BLT; + engine->hw_id = 2; engine->mmio_base = BLT_RING_BASE; engine->write_tail = ring_write_tail; @@ -3078,6 +3082,7 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev) engine->name = "video enhancement ring"; engine->id = VECS; engine->exec_id = I915_EXEC_VEBOX; + engine->hw_id = 3; engine->mmio_base = VEBOX_RING_BASE; engine->write_tail = ring_write_tail; diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index 55b0438b2fa1..723ff6160fbb 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h @@ -153,7 +153,8 @@ struct intel_engine_cs { #define I915_NUM_ENGINES 5 #define _VCS(n) (VCS + (n)) unsigned int exec_id; - unsigned int guc_id; + unsigned int hw_id; + unsigned int guc_id; /* XXX same as hw_id? */ u32 mmio_base; struct drm_device *dev; struct intel_ringbuffer *buffer; -- 2.8.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lvds: do not set border bits when panel fitter is not enabled
== Series Details == Series: drm/i915/lvds: do not set border bits when panel fitter is not enabled URL : https://patchwork.freedesktop.org/series/6530/ State : success == Summary == Series 6530v1 drm/i915/lvds: do not set border bits when panel fitter is not enabled http://patchwork.freedesktop.org/api/1.0/series/6530/revisions/1/mbox/ bdw-nuci7-2 total:201 pass:189 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:201 pass:176 dwarn:0 dfail:0 fail:0 skip:25 bsw-nuc-2total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 byt-nuc total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 hsw-brixbox total:201 pass:175 dwarn:0 dfail:0 fail:0 skip:26 hsw-gt2 total:201 pass:179 dwarn:0 dfail:0 fail:1 skip:21 ilk-hp8440p total:201 pass:140 dwarn:0 dfail:0 fail:0 skip:61 ivb-t430stotal:201 pass:170 dwarn:0 dfail:0 fail:0 skip:31 skl-i7k-2total:201 pass:174 dwarn:0 dfail:0 fail:0 skip:27 skl-nuci5total:201 pass:190 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:201 pass:159 dwarn:0 dfail:0 fail:0 skip:42 snb-x220ttotal:201 pass:159 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/Patchwork_2111/ 1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 2016y-04m-29d-09h-21m-52s UTC integration manifest 42aec19 drm/i915/lvds: do not set border bits when panel fitter is not enabled ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/gem: support BO freeing without dev->struct_mutex
== Series Details == Series: drm/gem: support BO freeing without dev->struct_mutex URL : https://patchwork.freedesktop.org/series/6527/ State : failure == Summary == Series 6527v1 drm/gem: support BO freeing without dev->struct_mutex http://patchwork.freedesktop.org/api/1.0/series/6527/revisions/1/mbox/ Test drv_getparams_basic: Subgroup basic-eu-total: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (skl-nuci5) pass -> DMESG-WARN (bdw-nuci7-2) pass -> DMESG-WARN (ivb-t430s) pass -> DMESG-WARN (bdw-ultra) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) pass -> DMESG-WARN (snb-x220t) pass -> DMESG-WARN (snb-dellxps) pass -> DMESG-WARN (hsw-brixbox) pass -> DMESG-WARN (ilk-hp8440p) Subgroup basic-subslice-total: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (skl-nuci5) pass -> DMESG-WARN (bdw-nuci7-2) pass -> DMESG-WARN (ivb-t430s) pass -> DMESG-WARN (bdw-ultra) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) pass -> DMESG-WARN (snb-x220t) pass -> DMESG-WARN (snb-dellxps) pass -> DMESG-WARN (hsw-brixbox) pass -> DMESG-WARN (ilk-hp8440p) Test drv_hangman: Subgroup error-state-basic: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (hsw-gt2) pass -> DMESG-WARN (bdw-nuci7-2) pass -> DMESG-WARN (ivb-t430s) pass -> DMESG-WARN (bdw-ultra) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) pass -> DMESG-WARN (snb-x220t) pass -> DMESG-WARN (snb-dellxps) pass -> DMESG-WARN (hsw-brixbox) pass -> DMESG-WARN (ilk-hp8440p) Test drv_module_reload_basic: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (bdw-nuci7-2) pass -> DMESG-WARN (ivb-t430s) pass -> DMESG-WARN (bdw-ultra) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) pass -> DMESG-WARN (snb-x220t) pass -> DMESG-WARN (snb-dellxps) pass -> DMESG-WARN (hsw-brixbox) pass -> DMESG-WARN (ilk-hp8440p) Test gem_basic: Subgroup bad-close: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (skl-nuci5) pass -> DMESG-WARN (bdw-nuci7-2) pass -> DMESG-WARN (ivb-t430s) pass -> DMESG-WARN (bdw-ultra) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) pass -> DMESG-WARN (snb-x220t) pass -> DMESG-WARN (snb-dellxps) pass -> DMESG-WARN (hsw-brixbox) pass -> DMESG-WARN (ilk-hp8440p) Subgroup create-close: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (bdw-nuci7-2) pass -> DMESG-WARN (ivb-t430s) pass -> DMESG-WARN (bdw-ultra) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) pass -> DMESG-WARN (snb-x220t) pass -> DMESG-WARN (snb-dellxps) pass -> DMESG-WARN (hsw-brixbox) pass -> DMESG-WARN (ilk-hp8440p) Subgroup create-fd-close: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (skl-nuci5) pass -> DMESG-WARN (bdw-nuci7-2) pass -> DMESG-WARN (ivb-t430s) pass -> DMESG-WARN (bdw-ultra) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) pass -> DMESG-WARN (snb-x220t) pass -> DMESG-WARN (snb-dellxps) pass -> DMESG-WARN (hsw-brixbox) pass -> DMESG-WARN (ilk-hp8440p) Test gem_busy: Subgroup basic-blt: pass -> DMESG-WARN (bsw-nuc-2) pass -> DMESG-WARN (skl-nuci5) pass -> DMESG-WARN (bdw-nuci7-2) pass -> DMESG-WARN (hsw-gt2) pass -> DMESG-WARN (bdw-ultra) pass -> DMESG-WARN (skl-i7k-2) pass
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space
On Fri, Apr 29, 2016 at 11:56:28AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 11:39, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote: > >> > >>On 29/04/16 11:18, Chris Wilson wrote: > >>>On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: > I don't get it - if we are adding something why not add it in a way > that makes it clear and self-contained - what is the downside of > what I propose to meet such resistance? > >>> > >>>You're suggesting to add a field I'm not going to use. Is any one? > >>>Until there is an actual use (which would afaict be if one of the > >>>existing values changed meaning, which itself would be an abi break) I'm > >>>not convinced we should be designing for the unknowable. If we did need > >>>to version would we not be better off with a new ioctl? > >> > >>I am suggesting if we are adding aper_total_size, or whatever it is > >>called, to make it usable in an self-contained matter. > >> > >>My impression was you want aper_total_size so I was simply objecting > >>to adding it without being able to directly tell if kernel actually > >>supports that extension. > > > >The two additions that I thought we have reduced it to: > > > > u64 mappable_aperture_size > > u64 stolen_size; > > > >Of which I agree that the first has some ambiguity over 0. But I don't > >think it makes a difference in practice. I for one would not bother with > >checking a version. I already have a cascade here to deal with not being > >able to use various probes, with an eventual fallback to a safe value. > > > >We know the mappable_aperture_size cannot be zero with the exception > >that the device is disabled - but we have opened the device already. > > Since you agree there is ambiguity lets just add a version. You > don't have to use it, but someone will. > > u32 version; // == 1 > u64 mappable_aperture_size; > > And then it is clear and self-contained. u64 version; or u32 version; u32 flags; uABI fields need to be naturally aligned. Hah, you didn't mention the trump card you pulled on IRC. In light of that issue ever being a problem (that we may be faced with 0 aperture), yes. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists
On to, 2016-04-28 at 17:24 +0100, Chris Wilson wrote: > The i915.enable_ppgtt option depends upon the state of > i915.enable_execlists option - so we need to sanitize execlists first. > Reviewed-by: Joonas Lahtinen> Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/i915_dma.c | 13 + > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/i915_gem.c | 3 --- > drivers/gpu/drm/i915/i915_gem_gtt.c | 16 +--- > drivers/gpu/drm/i915/intel_lrc.c| 2 -- > 5 files changed, 20 insertions(+), 16 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c > index f69330cf0118..c91387f1aedd 100644 > --- a/drivers/gpu/drm/i915/i915_dma.c > +++ b/drivers/gpu/drm/i915/i915_dma.c > @@ -968,6 +968,19 @@ static void intel_device_info_runtime_init(struct > drm_device *dev) > info->has_subslice_pg ? "y" : "n"); > DRM_DEBUG_DRIVER("has EU power gating: %s\n", > info->has_eu_pg ? "y" : "n"); > + > + i915.enable_execlists = > + intel_sanitize_enable_execlists(dev, i915.enable_execlists); > + > + /* > + * i915.enable_ppgtt is read-only, so do an early pass to validate the > + * user's requested state against the hardware/driver capabilities. We > + * do this now so that we can print out any log messages once rather > + * than every time we check intel_enable_ppgtt(). > + */ > + i915.enable_ppgtt = > + intel_sanitize_enable_ppgtt(dev, i915.enable_ppgtt); > + DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt); > } > > static void intel_init_dpio(struct drm_i915_private *dev_priv) > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index e2abbcc27f2c..17f22009f2b3 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -2753,6 +2753,8 @@ extern int i915_max_ioctl; > extern int i915_suspend_switcheroo(struct drm_device *dev, pm_message_t > state); > extern int i915_resume_switcheroo(struct drm_device *dev); > > +int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt); > + > /* i915_dma.c */ > void __printf(3, 4) > __i915_printk(struct drm_i915_private *dev_priv, const char *level, > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 96fbc9ab4039..bd6061f177fe 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -4901,9 +4901,6 @@ int i915_gem_init(struct drm_device *dev) > struct drm_i915_private *dev_priv = dev->dev_private; > int ret; > > - i915.enable_execlists = intel_sanitize_enable_execlists(dev, > - i915.enable_execlists); > - > mutex_lock(>struct_mutex); > > if (!i915.enable_execlists) { > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > b/drivers/gpu/drm/i915/i915_gem_gtt.c > index 59a78f760b6b..364cf8236021 100644 > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > @@ -110,7 +110,7 @@ const struct i915_ggtt_view i915_ggtt_view_rotated = { > .type = I915_GGTT_VIEW_ROTATED, > }; > > -static int sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt) > +int intel_sanitize_enable_ppgtt(struct drm_device *dev, int enable_ppgtt) > { > bool has_aliasing_ppgtt; > bool has_full_ppgtt; > @@ -123,12 +123,14 @@ static int sanitize_enable_ppgtt(struct drm_device > *dev, int enable_ppgtt) > if (intel_vgpu_active(dev)) > has_full_ppgtt = false; /* emulation is too hard */ > > + if (!has_aliasing_ppgtt) > + return 0; > + > /* > * We don't allow disabling PPGTT for gen9+ as it's a requirement for > * execlists, the sole mechanism available to submit work. > */ > - if (INTEL_INFO(dev)->gen < 9 && > - (enable_ppgtt == 0 || !has_aliasing_ppgtt)) > + if (enable_ppgtt == 0 && INTEL_INFO(dev)->gen < 9) > return 0; > > if (enable_ppgtt == 1) > @@ -3219,14 +3221,6 @@ int i915_ggtt_init_hw(struct drm_device *dev) > if (intel_iommu_gfx_mapped) > DRM_INFO("VT-d active for gfx access\n"); > #endif > - /* > - * i915.enable_ppgtt is read-only, so do an early pass to validate the > - * user's requested state against the hardware/driver capabilities. We > - * do this now so that we can print out any log messages once rather > - * than every time we check intel_enable_ppgtt(). > - */ > - i915.enable_ppgtt = sanitize_enable_ppgtt(dev, i915.enable_ppgtt); > - DRM_DEBUG_DRIVER("ppgtt mode: %i\n", i915.enable_ppgtt); > > return 0; > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index 874c2515f9d4..4c832f90fe49 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space
On 29/04/16 11:39, Chris Wilson wrote: On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote: On 29/04/16 11:18, Chris Wilson wrote: On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: I don't get it - if we are adding something why not add it in a way that makes it clear and self-contained - what is the downside of what I propose to meet such resistance? You're suggesting to add a field I'm not going to use. Is any one? Until there is an actual use (which would afaict be if one of the existing values changed meaning, which itself would be an abi break) I'm not convinced we should be designing for the unknowable. If we did need to version would we not be better off with a new ioctl? I am suggesting if we are adding aper_total_size, or whatever it is called, to make it usable in an self-contained matter. My impression was you want aper_total_size so I was simply objecting to adding it without being able to directly tell if kernel actually supports that extension. The two additions that I thought we have reduced it to: u64 mappable_aperture_size u64 stolen_size; Of which I agree that the first has some ambiguity over 0. But I don't think it makes a difference in practice. I for one would not bother with checking a version. I already have a cascade here to deal with not being able to use various probes, with an eventual fallback to a safe value. We know the mappable_aperture_size cannot be zero with the exception that the device is disabled - but we have opened the device already. Since you agree there is ambiguity lets just add a version. You don't have to use it, but someone will. u32 version; // == 1 u64 mappable_aperture_size; And then it is clear and self-contained. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space
On Fri, Apr 29, 2016 at 11:26:45AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 11:18, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: > >>I don't get it - if we are adding something why not add it in a way > >>that makes it clear and self-contained - what is the downside of > >>what I propose to meet such resistance? > > > >You're suggesting to add a field I'm not going to use. Is any one? > >Until there is an actual use (which would afaict be if one of the > >existing values changed meaning, which itself would be an abi break) I'm > >not convinced we should be designing for the unknowable. If we did need > >to version would we not be better off with a new ioctl? > > I am suggesting if we are adding aper_total_size, or whatever it is > called, to make it usable in an self-contained matter. > > My impression was you want aper_total_size so I was simply objecting > to adding it without being able to directly tell if kernel actually > supports that extension. The two additions that I thought we have reduced it to: u64 mappable_aperture_size u64 stolen_size; Of which I agree that the first has some ambiguity over 0. But I don't think it makes a difference in practice. I for one would not bother with checking a version. I already have a cascade here to deal with not being able to use various probes, with an eventual fallback to a safe value. We know the mappable_aperture_size cannot be zero with the exception that the device is disabled - but we have opened the device already. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 ERRORs and WARN_ON()s
On Fri, Apr 29, 2016 at 04:27:08AM +0200, Florian Zumbiehl wrote: > Hi, > > > The Bugzilla at https://bugs.freedesktop.org is our tool of choice for > > tracking bugs in drm/i915. It's your choice to not create an account > > there, but please, don't expect us to work as a proxy between you and > > bugzilla either. It's a much bigger and unscalable inconvenience for us > > than it is for you to create that account. > > Hu? I don't quite get it. Communicating via email is an unscalable > inconvenience? So, if I asked you to create an account with my todo tracker > instead, would that be more scalable and convenient? Using everyone's > software of choice instead of my own most certainly is neither scalable nor > convenient for me at all. I think you're missing the point here. First of all, your bug report isn't the only bug report. If all bug reports were posted here rather than reported in our bug tracker, it would definitely be more likely that some bugs would get lost. It works for small projects with a low influx of bug reports, but it's less convenient for larger projects. This is the scalability factor. Second of all, convenience. Your convenience, while of course a consideration, isn't the primary concern. The convenience of the developers is. You're reporting one bug, but the developers here have to keep track of, and fix, hundreds (and that's on top of new features, support for new platforms, test cases, and performance improvements). If we were asking for support for software you develop, you'd obviously be the one to set the rules (and yes, that includes your TODO tracker, closed forums or what not). Reporting bugs in a bug tracking system isn't exactly a novelty. Rather the opposite. Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space
On 29/04/16 11:18, Chris Wilson wrote: On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: I don't get it - if we are adding something why not add it in a way that makes it clear and self-contained - what is the downside of what I propose to meet such resistance? You're suggesting to add a field I'm not going to use. Is any one? Until there is an actual use (which would afaict be if one of the existing values changed meaning, which itself would be an abi break) I'm not convinced we should be designing for the unknowable. If we did need to version would we not be better off with a new ioctl? I am suggesting if we are adding aper_total_size, or whatever it is called, to make it usable in an self-contained matter. My impression was you want aper_total_size so I was simply objecting to adding it without being able to directly tell if kernel actually supports that extension. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup
On Fri, Apr 29, 2016 at 11:11:20AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 11:00, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote: > >> > >>On 29/04/16 10:39, Chris Wilson wrote: > >>>On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > On 29/04/16 10:15, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >b/drivers/gpu/drm/i915/intel_lrc.c > >index 2e0eaa9fa240..2c94072ab085 100644 > >--- a/drivers/gpu/drm/i915/intel_lrc.c > >+++ b/drivers/gpu/drm/i915/intel_lrc.c > >@@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum > >intel_engine_id id) > > struct intel_engine_cs *engine = _priv->engine[id]; > > enum forcewake_domains fw_domains; > > > >- engine->dev = dev; > >- > > engine->id = id; > > engine->name = info->name; > > engine->exec_id = info->exec_id; > > engine->guc_id = info->guc_id; > > engine->mmio_base = info->mmio_base; > > > >+ /* disable interrupts to this engine before we install > >ourselves*/ > >+ I915_WRITE_IMR(engine, ~0); > >+ > >+ engine->dev = dev; > >+ > > /* Intentionally left blank. */ > > engine->buffer = NULL; > > > >Make sense? > > Not the most elegant because all the hw access we have so far is in > engine->init_hw. Why can't we just make intel_engine_initialized > return false until the very last thing in engine constructors? > >>> > >>>In my defence sanitizing the hw before we are ready is common practice > >>>across the driver. The unfun part is that irq install is before gem_init > >>>(because modeset init wants irq enabled for GMBUS/dp-aux). gem init > >>>itself could be split up and moved around so that the setup and init_hw > >>>phases are separate (which would be next on the init ordering hitlist I > >>>hope). > >>> > >>>I want engine->dev/engine->i915 set early so we can use it during setup > >>>and init-hw and so that for_each_engine() works as expected in that > >>>time. > >> > >>Why wouldn't an explicit engine->initialized flag solve that? You > >>could keep setting engine->dev early (as it should be) and then set > >>engine->initialized at the end of per-engine constructors. > > > >Because it becomes irrelevant very shortly. The only interesting > >question remaining is whether or not we should be sanitizing the IMR > >first. It has been suggested elsewhere (in Ville's review of the GT > >interrupt handling) that doing the sanitization would be useful. > > How come it becomes irrelevant? Will there not be > intel_engine_initialized? Because as long as there is, imho it makes > sense not to use engine->dev for it. The only argument here is how to handle an interrupt left over from before the driver loads. At all other times engine->dev means precisely that. I do not agree that you need to duplicate the state. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Support blending modes of display planes (rev2)
== Series Details == Series: Support blending modes of display planes (rev2) URL : https://patchwork.freedesktop.org/series/2582/ State : failure == Summary == Series 2582v2 Support blending modes of display planes http://patchwork.freedesktop.org/api/1.0/series/2582/revisions/2/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> INCOMPLETE (hsw-gt2) bdw-nuci7-2 total:201 pass:189 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:201 pass:176 dwarn:0 dfail:0 fail:0 skip:25 bsw-nuc-2total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 byt-nuc total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 hsw-brixbox total:201 pass:175 dwarn:0 dfail:0 fail:0 skip:26 hsw-gt2 total:151 pass:132 dwarn:0 dfail:0 fail:0 skip:18 ilk-hp8440p total:201 pass:140 dwarn:0 dfail:0 fail:0 skip:61 ivb-t430stotal:201 pass:170 dwarn:0 dfail:0 fail:0 skip:31 skl-i7k-2total:201 pass:174 dwarn:0 dfail:0 fail:0 skip:27 snb-dellxps total:201 pass:159 dwarn:0 dfail:0 fail:0 skip:42 snb-x220ttotal:201 pass:159 dwarn:0 dfail:0 fail:1 skip:41 Results at /archive/results/CI_IGT_test/Patchwork_2109/ 1d56af10bdd6f4714e0892c05ff01d11e77f54fc drm-intel-nightly: 2016y-04m-29d-09h-21m-52s UTC integration manifest f078b1b drm/i915/skl: Add support for blending modes 0910f9d drm: Add an blend_color property ab2afbf drm: Introduce DRM_MODE_COLOR() 5f3d082 drm/i915/skl: Add blend_func to SKL/BXT sprite planes 2426e80 drm: Introduce the blend-func property ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space
On Fri, Apr 29, 2016 at 11:06:49AM +0100, Tvrtko Ursulin wrote: > I don't get it - if we are adding something why not add it in a way > that makes it clear and self-contained - what is the downside of > what I propose to meet such resistance? You're suggesting to add a field I'm not going to use. Is any one? Until there is an actual use (which would afaict be if one of the existing values changed meaning, which itself would be an abi break) I'm not convinced we should be designing for the unknowable. If we did need to version would we not be better off with a new ioctl? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled
On Fri, Apr 29, 2016 at 12:36:35PM +0300, Jani Nikula wrote: > We also don't read the border bits in i9xx_get_pfit_config() when the > panel fitter is not enabled, causing the state checker warning: > > [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in > gmch_pfit.lvds_border_bits (expected 0x8000, found 0x) > > Cc: Ville Syrjälä> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632 > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_panel.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/intel_panel.c > b/drivers/gpu/drm/i915/intel_panel.c > index 828f0fcaaaf8..67cf2e22ba51 100644 > --- a/drivers/gpu/drm/i915/intel_panel.c > +++ b/drivers/gpu/drm/i915/intel_panel.c > @@ -363,6 +363,7 @@ out: > if ((pfit_control & PFIT_ENABLE) == 0) { > pfit_control = 0; > pfit_pgm_ratios = 0; > + border = 0; That doesn't seem right. We especially want the border for "center". > } > > /* Make sure pre-965 set dither correctly for 18bpp panels. */ > -- > 2.1.4 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup
On 29/04/16 11:00, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote: On 29/04/16 10:39, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: On 29/04/16 10:15, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 2e0eaa9fa240..2c94072ab085 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum intel_engine_id id) struct intel_engine_cs *engine = _priv->engine[id]; enum forcewake_domains fw_domains; - engine->dev = dev; - engine->id = id; engine->name = info->name; engine->exec_id = info->exec_id; engine->guc_id = info->guc_id; engine->mmio_base = info->mmio_base; + /* disable interrupts to this engine before we install ourselves*/ + I915_WRITE_IMR(engine, ~0); + + engine->dev = dev; + /* Intentionally left blank. */ engine->buffer = NULL; Make sense? Not the most elegant because all the hw access we have so far is in engine->init_hw. Why can't we just make intel_engine_initialized return false until the very last thing in engine constructors? In my defence sanitizing the hw before we are ready is common practice across the driver. The unfun part is that irq install is before gem_init (because modeset init wants irq enabled for GMBUS/dp-aux). gem init itself could be split up and moved around so that the setup and init_hw phases are separate (which would be next on the init ordering hitlist I hope). I want engine->dev/engine->i915 set early so we can use it during setup and init-hw and so that for_each_engine() works as expected in that time. Why wouldn't an explicit engine->initialized flag solve that? You could keep setting engine->dev early (as it should be) and then set engine->initialized at the end of per-engine constructors. Because it becomes irrelevant very shortly. The only interesting question remaining is whether or not we should be sanitizing the IMR first. It has been suggested elsewhere (in Ville's review of the GT interrupt handling) that doing the sanitization would be useful. How come it becomes irrelevant? Will there not be intel_engine_initialized? Because as long as there is, imho it makes sense not to use engine->dev for it. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Extend GET_APERTURE ioctl to report available map space
On 28/04/16 11:24, Chris Wilson wrote: On Thu, Apr 28, 2016 at 10:30:32AM +0100, Tvrtko Ursulin wrote: On 26/04/16 10:44, Chris Wilson wrote: On Mon, Apr 25, 2016 at 03:51:09PM +0100, Tvrtko Ursulin wrote: On 25/04/16 11:35, Ankitprasad Sharma wrote: On Thu, 2016-04-21 at 15:59 +0100, Tvrtko Ursulin wrote: On 21/04/16 15:46, Chris Wilson wrote: On Thu, Apr 21, 2016 at 03:04:52PM +0100, Tvrtko Ursulin wrote: Hi, On 20/04/16 12:17, ankitprasad.r.sha...@intel.com wrote: + mutex_unlock(>struct_mutex); + + seq_printf(m, "Total size of the GTT: %llu bytes\n", + arg.aper_size); + seq_printf(m, "Available space in the GTT: %llu bytes\n", + arg.aper_available_size); + seq_printf(m, "Total space in the mappable aperture: %llu bytes\n", + arg.map_total_size); + seq_printf(m, "Available space in the mappable aperture: %llu bytes\n", + map_space); + seq_printf(m, "Single largest space in the mappable aperture: %llu bytes\n", + map_largest); + seq_printf(m, "Available space for fences: %llu bytes\n", + fence_space); + seq_printf(m, "Single largest fence available: %llu bytes\n", + fence_largest); + + return 0; +} + In general I find this a lot of code for a feature of questionable utility. As such I would prefer someone really stated the need for this and explained how it really is useful - even though whetever number they get from this may be completely irrelevant by the time it is acted upon. Yes, with the exception of the size of the mappable aperture, this is really is debug info. It will get automatically dumped by userspace when it sees an ENOSPC, and that may prove enough to solve the riddle of why it failed. However, this information is terrible outdated and now longer of such relevance. As for the mappable aperture size, there has been a request many years ago! could we provide it without resorting to a privilege operation. I guess by know that request has died out - but there is still the issue with libpciassess that make it unsuitable for use inside a library where one may want to avoid it and use a simple ioctl on the device you already have open. Yes, it is meh. Aperture size in the ioctl is fine I think, just that detection caveat what I asked in the other reply. Here I wanted to suggest dropping all the non-trivial debugfs stuff and just leave the info queried via i915_gem_get_aperture ioctl. So effectively dropping the list traversal and vma sorting bits. I think, debug info regarding the mappable space is good to have for debugging purpose as Chris mentioned. Also, the list traversal and the vma sorting stuff will only be called for debugging purposes, not slowing anything down or so. I am pretty indifferent on the topic of debugfs edition. But for the ioctl extension, how about adding a version field as the first one in the extended area? A version number only makes sense when you are changing the meaning of an existing field. Adding one implies that we are planning to do so, are we? In the scenarios, I've run through I haven't found one where a caller would behave any differently faced with "0 - ioctl version not supported" and "0 - no available space (mappable/stolen)". Adding a version doesn't help using the new fields afaict. The argument is the same as whether a flags field is forward thinking or unthinkingly forward. I was thinking that if 0 = no aperture or ioctl not supported userspace has to try one mmap_gtt to find out which is true, will it be ENODEV or ENOSPC (assuming, haven't checked). If we put a version in there then it can avoid doing that. Sounds like a better interface to me and I don't see any downsides to it. I was thinking either userspace already cares and has a method for finding the size of the PCI memory region or it doesn't. If it doesn't and the ioctl reports 0 and its older second method fails with EPERM/EACCESS then it is no worse off than before. I don't get it - if we are adding something why not add it in a way that makes it clear and self-contained - what is the downside of what I propose to meet such resistance? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv2 1/5] drm: Introduce the blend-func property
On Fri, Apr 29, 2016 at 02:59:13PM +0530, Vandita Kulkarni wrote: > From: Damien Lespiau> > We'd like to be able to program the blending modes of display planes. > Ville suggested to use something similar to the GL blend states, which > does seem like a good idea. > > For now, we only consider blend factors, but room is left for > extensions: blend equation, separate rgb/alpha blend factors, blend > color. > > V2: Added the belnd func property support in get property. > > Suggested-by: Ville Syrjälä > Signed-off-by: Damien Lespiau > Signed-off-by: Vandita Kulkarni > --- > Documentation/DocBook/gpu.tmpl | 11 +-- > drivers/gpu/drm/drm_atomic.c | 14 ++ > drivers/gpu/drm/drm_crtc.c | 5 + > include/drm/drm_crtc.h | 20 > 4 files changed, 48 insertions(+), 2 deletions(-) > > diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl > index 1464fb2..f673989 100644 > --- a/Documentation/DocBook/gpu.tmpl > +++ b/Documentation/DocBook/gpu.tmpl > @@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev) > Description/Restrictions > > > - DRM > + DRM > Generic > “rotation” > BITMASK > @@ -1868,7 +1868,7 @@ void intel_crt_init(struct drm_device *dev) > CRTC that connector is attached to (atomic) > > > - Plane > + Plane > “type” > ENUM | IMMUTABLE > { "Overlay", "Primary", "Cursor" } > @@ -1946,6 +1946,13 @@ void intel_crt_init(struct drm_device *dev) > CRTC that plane is attached to (atomic) > > > + “blend_func” > + None > + DRM_BLEND_FUNC() > + Plane > + Source and destination blending factors > + > + > DVI-I > “subconnector” > ENUM > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > index 8ee1db8..c2ead2d 100644 > --- a/drivers/gpu/drm/drm_atomic.c > +++ b/drivers/gpu/drm/drm_atomic.c > @@ -701,6 +701,18 @@ int drm_atomic_plane_set_property(struct drm_plane > *plane, > state->src_h = val; > } else if (property == config->rotation_property) { > state->rotation = val; > + } else if (property == config->prop_blend_func) { > + enum drm_blend_factor src_factor, dst_factor; > + > + src_factor = DRM_BLEND_FUNC_SRC_FACTOR(val); > + dst_factor = DRM_BLEND_FUNC_DST_FACTOR(val); > + > + if (src_factor != dst_factor && > + (src_factor == DRM_BLEND_FACTOR_AUTO || > + dst_factor == DRM_BLEND_FACTOR_AUTO)) > + return -EINVAL; > + > + state->blend_mode.func = val & GENMASK(31, 0); > } else if (plane->funcs->atomic_set_property) { > return plane->funcs->atomic_set_property(plane, state, > property, val); > @@ -757,6 +769,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane, > *val = state->src_h; > } else if (property == config->rotation_property) { > *val = state->rotation; > + } else if (property == config->prop_blend_func) { > + *val = state->blend_mode.func; > } else if (plane->funcs->atomic_get_property) { > return plane->funcs->atomic_get_property(plane, state, > property, val); > } else { > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index f7fe9e1..2cac5e1 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -1587,6 +1587,11 @@ static int drm_mode_create_standard_properties(struct > drm_device *dev) > return -ENOMEM; > dev->mode_config.gamma_lut_size_property = prop; > > + prop = drm_property_create_range(dev, 0, "blend_func", 0, U32_MAX); > + if (!prop) > + return -ENOMEM; > + dev->mode_config.prop_blend_func = prop; > + > return 0; > } > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > index 6d46842..269f660 100644 > --- a/include/drm/drm_crtc.h > +++ b/include/drm/drm_crtc.h > @@ -89,6 +89,23 @@ static inline uint64_t I642U64(int64_t val) > #define DRM_REFLECT_X4 > #define DRM_REFLECT_Y5 > > +enum drm_blend_factor { > + DRM_BLEND_FACTOR_AUTO, > + DRM_BLEND_FACTOR_ZERO, > + DRM_BLEND_FACTOR_ONE, > + DRM_BLEND_FACTOR_SRC_ALPHA, > + DRM_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA, Based on what I remember of the earlier discussion I don't think these are quite enough. We could want some way to deal with the constant alpha as well. Hmm. I think I need to refresh my brain a bit on this before I can say anything really. Also IIRC I was thinking that the premult vs. non-premult would be a separate thing outside the blend equation. That's how we have it some hw at least AFAIK, so be shoving it all
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup
On Fri, Apr 29, 2016 at 10:50:02AM +0100, Tvrtko Ursulin wrote: > > On 29/04/16 10:39, Chris Wilson wrote: > >On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > >>On 29/04/16 10:15, Chris Wilson wrote: > >>>diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >>>b/drivers/gpu/drm/i915/intel_lrc.c > >>>index 2e0eaa9fa240..2c94072ab085 100644 > >>>--- a/drivers/gpu/drm/i915/intel_lrc.c > >>>+++ b/drivers/gpu/drm/i915/intel_lrc.c > >>>@@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum > >>>intel_engine_id id) > >>> struct intel_engine_cs *engine = _priv->engine[id]; > >>> enum forcewake_domains fw_domains; > >>> > >>>- engine->dev = dev; > >>>- > >>> engine->id = id; > >>> engine->name = info->name; > >>> engine->exec_id = info->exec_id; > >>> engine->guc_id = info->guc_id; > >>> engine->mmio_base = info->mmio_base; > >>> > >>>+ /* disable interrupts to this engine before we install ourselves*/ > >>>+ I915_WRITE_IMR(engine, ~0); > >>>+ > >>>+ engine->dev = dev; > >>>+ > >>> /* Intentionally left blank. */ > >>> engine->buffer = NULL; > >>> > >>>Make sense? > >> > >>Not the most elegant because all the hw access we have so far is in > >>engine->init_hw. Why can't we just make intel_engine_initialized > >>return false until the very last thing in engine constructors? > > > >In my defence sanitizing the hw before we are ready is common practice > >across the driver. The unfun part is that irq install is before gem_init > >(because modeset init wants irq enabled for GMBUS/dp-aux). gem init > >itself could be split up and moved around so that the setup and init_hw > >phases are separate (which would be next on the init ordering hitlist I > >hope). > > > >I want engine->dev/engine->i915 set early so we can use it during setup > >and init-hw and so that for_each_engine() works as expected in that > >time. > > Why wouldn't an explicit engine->initialized flag solve that? You > could keep setting engine->dev early (as it should be) and then set > engine->initialized at the end of per-engine constructors. Because it becomes irrelevant very shortly. The only interesting question remaining is whether or not we should be sanitizing the IMR first. It has been suggested elsewhere (in Ville's review of the GT interrupt handling) that doing the sanitization would be useful. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup
On 29/04/16 10:39, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: On 29/04/16 10:15, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 2e0eaa9fa240..2c94072ab085 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum intel_engine_id id) struct intel_engine_cs *engine = _priv->engine[id]; enum forcewake_domains fw_domains; - engine->dev = dev; - engine->id = id; engine->name = info->name; engine->exec_id = info->exec_id; engine->guc_id = info->guc_id; engine->mmio_base = info->mmio_base; + /* disable interrupts to this engine before we install ourselves*/ + I915_WRITE_IMR(engine, ~0); + + engine->dev = dev; + /* Intentionally left blank. */ engine->buffer = NULL; Make sense? Not the most elegant because all the hw access we have so far is in engine->init_hw. Why can't we just make intel_engine_initialized return false until the very last thing in engine constructors? In my defence sanitizing the hw before we are ready is common practice across the driver. The unfun part is that irq install is before gem_init (because modeset init wants irq enabled for GMBUS/dp-aux). gem init itself could be split up and moved around so that the setup and init_hw phases are separate (which would be next on the init ordering hitlist I hope). I want engine->dev/engine->i915 set early so we can use it during setup and init-hw and so that for_each_engine() works as expected in that time. Why wouldn't an explicit engine->initialized flag solve that? You could keep setting engine->dev early (as it should be) and then set engine->initialized at the end of per-engine constructors. Engine setup would then work fine - I don't see it needed for_each_engine or intel_engine_initialized ? And problem of hw sanitation could then be left out of this patch/discussion, no? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup
On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > Not the most elegant because all the hw access we have so far is in > engine->init_hw. Why can't we just make intel_engine_initialized > return false until the very last thing in engine constructors? The other thing I've been mulling over is just making for_each_engine iterate over the ring_mask. Means the reinstatement of temporary variables (at least for the macros I've sketched) :( -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915 suspend/resume_noirq instead of suspend_late/resume_early
On Wed, Apr 27, 2016 at 11:46:22AM -0700, Todd Brandt wrote: > I'd like to propose that we push the i915 suspend_late/resume_early code > into suspend_noirq/resume_noirq in order to reduce the total suspend time > by ~15ms. According to the comments, when i915_pm_suspend_late was first > added to the kernel back in April 2014, it was done so to ensure that it > was called after the snd_hda_intel driver had finished its suspend. > > The comments in i915_drv.c are here: > > /* > * We have a suspedn ordering issue with the snd-hda driver also > * requiring our device to be power up. Due to the lack of a > * parent/child relationship we currently solve this with an late > * suspend hook. > * > * FIXME: This should be solved with a special hdmi sink device or > * similar so that power domains can be employed. > */ > > I believe we could achieve the same ordering by simply pushing it to > suspend/resume_noirq. Thus we can effectively eliminate the suspend_late > and resume_early phases altogether in most simple systems. Does anyone see > a problem with this? > > analyzesuspend outputs for freeze/suspend/hibernate (WITHOUT PATCH): > https://01org.github.io/suspendresume/i915/freeze-160422-155931-ivybridge-dev-late/ > https://01org.github.io/suspendresume/i915/suspend-160422-155735-ivybridge-dev-late/ > https://01org.github.io/suspendresume/i915/hibernate-160422-163915-ivybridge-dev-late/ > > analyzesuspend outputs for freeze/suspend/hibernate (WITH PATCH): > https://01org.github.io/suspendresume/i915/freeze-160422-162811-ivybridge-dev-noirq/ > https://01org.github.io/suspendresume/i915/suspend-160422-162700-ivybridge-dev-noirq/ > https://01org.github.io/suspendresume/i915/hibernate-160422-162952-ivybridge-dev-noirq/ BTW couple of unrelated observations from this data: - The boot clock power cycle delay thing *seems* to be working. The schedule_timeout() wasn't actually shown in the data, but there were cases where the late vs. noirq had a huge difference in resume time. I can only assume that's because it spent more time actually suspended in one of the cases, and that allowd the power cycle delay to be shorter. Would be nice to see these sorts of things (wait_remaining_ms_from_jiffies(), wait_panel_status()) explicitly in the data. - we really need to make the display ->detect() async at resume time. HDMI live status checks cost a ton of time. I think here too I might just suggest injecting a hpd for every connector and let the hpd machinery deal with it. Or we just toss out an uncoditional uevent and let userspace reprobe? But maybe this is still stuck behind MST explosions? - With async modesets coming perhaps, we should make the resume modeset async as well - We need to parallelize ->detect() for all connectors even from normal HPD. Again, HDMI live status checks do add up. The main snag here might be gmbus since we only have the one. It has a lock, but I'm not sure if it's a bit too low level to do this efficiently. Would need to measure it I suppose. I thought we had more gmbus instances on BXT, but now I can't find them anywhere, so maybe I was just confusing it with blc/pps or something. > > Signed-off-by: Todd Brandt> --- > drivers/gpu/drm/i915/i915_drv.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 30798cb..759d93c 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -1628,8 +1628,8 @@ static const struct dev_pm_ops i915_pm_ops = { >* PMSG_RESUME] >*/ > .suspend = i915_pm_suspend, > - .suspend_late = i915_pm_suspend_late, > - .resume_early = i915_pm_resume_early, > + .suspend_noirq = i915_pm_suspend_late, > + .resume_noirq = i915_pm_resume_early, > .resume = i915_pm_resume, > > /* > @@ -1648,12 +1648,12 @@ static const struct dev_pm_ops i915_pm_ops = { >*hibernation image [PMSG_RESTORE] >*/ > .freeze = i915_pm_suspend, > - .freeze_late = i915_pm_suspend_late, > - .thaw_early = i915_pm_resume_early, > + .freeze_noirq = i915_pm_suspend_late, > + .thaw_noirq = i915_pm_resume_early, > .thaw = i915_pm_resume, > .poweroff = i915_pm_suspend, > - .poweroff_late = i915_pm_poweroff_late, > - .restore_early = i915_pm_resume_early, > + .poweroff_noirq = i915_pm_poweroff_late, > + .restore_noirq = i915_pm_resume_early, > .restore = i915_pm_resume, > > /* S0ix (via runtime suspend) event handlers */ > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing
[Intel-gfx] [PATCH] drm/i915/lvds: do not set border bits when panel fitter is not enabled
We also don't read the border bits in i9xx_get_pfit_config() when the panel fitter is not enabled, causing the state checker warning: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 0x8000, found 0x) Cc: Ville SyrjäläBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632 Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_panel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 828f0fcaaaf8..67cf2e22ba51 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -363,6 +363,7 @@ out: if ((pfit_control & PFIT_ENABLE) == 0) { pfit_control = 0; pfit_pgm_ratios = 0; + border = 0; } /* Make sure pre-965 set dither correctly for 18bpp panels. */ -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup
On Fri, Apr 29, 2016 at 10:25:41AM +0100, Tvrtko Ursulin wrote: > On 29/04/16 10:15, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >b/drivers/gpu/drm/i915/intel_lrc.c > >index 2e0eaa9fa240..2c94072ab085 100644 > >--- a/drivers/gpu/drm/i915/intel_lrc.c > >+++ b/drivers/gpu/drm/i915/intel_lrc.c > >@@ -2016,14 +2016,17 @@ logical_ring_setup(struct drm_device *dev, enum > >intel_engine_id id) > > struct intel_engine_cs *engine = _priv->engine[id]; > > enum forcewake_domains fw_domains; > > > >- engine->dev = dev; > >- > > engine->id = id; > > engine->name = info->name; > > engine->exec_id = info->exec_id; > > engine->guc_id = info->guc_id; > > engine->mmio_base = info->mmio_base; > > > >+ /* disable interrupts to this engine before we install ourselves*/ > >+ I915_WRITE_IMR(engine, ~0); > >+ > >+ engine->dev = dev; > >+ > > /* Intentionally left blank. */ > > engine->buffer = NULL; > > > >Make sense? > > Not the most elegant because all the hw access we have so far is in > engine->init_hw. Why can't we just make intel_engine_initialized > return false until the very last thing in engine constructors? In my defence sanitizing the hw before we are ready is common practice across the driver. The unfun part is that irq install is before gem_init (because modeset init wants irq enabled for GMBUS/dp-aux). gem init itself could be split up and moved around so that the setup and init_hw phases are separate (which would be next on the init ordering hitlist I hope). I want engine->dev/engine->i915 set early so we can use it during setup and init-hw and so that for_each_engine() works as expected in that time. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/21] drm/i915/slpc: Fail intel_runtime_suspend if SLPC or RPS not active
On to, 2016-04-28 at 09:00 +0100, Chris Wilson wrote: > On Thu, Apr 28, 2016 at 10:57:20AM +0300, Imre Deak wrote: > > On to, 2016-04-28 at 07:56 +0100, Chris Wilson wrote: > > > On Wed, Apr 27, 2016 at 06:11:05PM -0700, tom.orou...@intel.com > > > wrote: > > > > From: Sagar Arun Kamble> > > > > > > > intel_runtime_suspend failed with warning if RPS was disabled. > > > > With SLPC enabled, RPS is disabled. With SLPC, warning is now > > > > changed > > > > to consider SLPC active status as well. This will ensure > > > > runtime suspend > > > > proceeds when SLPC enabled. > > > > > > > > v2: Commit message update. (Tom) > > > > > > > > Signed-off-by: Sagar Arun Kamble > > > > Signed-off-by: Tom O'Rourke > > > > --- > > > > drivers/gpu/drm/i915/i915_drv.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > > b/drivers/gpu/drm/i915/i915_drv.c > > > > index cc22fa0..00a2713 100644 > > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > > @@ -1474,7 +1474,8 @@ static int intel_runtime_suspend(struct > > > > device *device) > > > > struct drm_i915_private *dev_priv = dev->dev_private; > > > > int ret; > > > > > > > > - if (WARN_ON_ONCE(!(dev_priv->rps.enabled && > > > > intel_enable_rc6(dev > > > > + if (WARN_ON_ONCE(!((dev_priv->rps.enabled || > > > > intel_slpc_active(dev)) && > > > > + intel_enable_rc6(dev > > > > > > The real question here is why does runtime suspend depend on > > > either of > > > these being enabled (espcially rps!). > > > > We need RC6 enabled across a runtime suspend/resume since we depend > > on > > the RC6 context to be retained across these transitions. There is > > no > > separate knob for RPS and we enable RC6 and RPS together, that's > > why > > rps.enabled is checked. > > So, from the standpoint of this series, we should be separating the > two > and giving rc6 its own bit of bookkeeping. Yes, separating RC6 and RPS enabling would be the clean way for this and other purposes too. This patchset enables RC6 from intel_enable_gt_powersave() directly in case SLPC is enabled but schedules a work for enabling RC6 if SLPC is not enabled. So while the above works it could be done in a cleaner way. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/gem: support BO freeing without dev->struct_mutex
Finally all the core gem and a lot of drivers are entirely free of dev->struct_mutex depencies, and we can start to have an entirely lockless unref path. To make sure that no one who touches the core code accidentally breaks existing drivers which still require dev->struct_mutex I've made the might_lock check unconditional. While at it de-inline the ref/unref functions, they've become a bit too big. v2: Make it not leak like a sieve. v3: Review from Lucas: - drop != NULL in pointer checks. - fixup copypasted kerneldoc to actually match the functions. v4: Add __drm_gem_object_unreference as a fastpath helper for drivers who abolished dev->struct_mutex, requested by Chris. Cc: Chris WilsonCc: Alex Deucher Cc: Lucas Stach Reviewed-by: Lucas Stach Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_gem.c | 54 ++- include/drm/drmP.h| 15 ++--- include/drm/drm_gem.h | 48 + 3 files changed, 80 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 25dac31eef37..750d8975c318 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -806,12 +806,64 @@ drm_gem_object_free(struct kref *kref) WARN_ON(!mutex_is_locked(>struct_mutex)); - if (dev->driver->gem_free_object != NULL) + if (dev->driver->gem_free_object_unlocked) + dev->driver->gem_free_object_unlocked(obj); + else if (dev->driver->gem_free_object) dev->driver->gem_free_object(obj); } EXPORT_SYMBOL(drm_gem_object_free); /** + * drm_gem_object_unreference_unlocked - release a GEM BO reference + * @obj: GEM buffer object + * + * This releases a reference to @obj. Callers must not hold the + * dev->struct_mutex lock when calling this function. + * + * See also __drm_gem_object_unreference(). + */ +void +drm_gem_object_unreference_unlocked(struct drm_gem_object *obj) +{ + struct drm_device *dev; + + if (!obj) + return; + + dev = obj->dev; + might_lock(>struct_mutex); + + if (dev->driver->gem_free_object) + kref_put(>refcount, drm_gem_object_free); + else if (kref_put_mutex(>refcount, drm_gem_object_free, + >struct_mutex)) + mutex_unlock(>struct_mutex); +} +EXPORT_SYMBOL(drm_gem_object_unreference_unlocked); + +/** + * drm_gem_object_unreference - release a GEM BO reference + * @obj: GEM buffer object + * + * This releases a reference to @obj. Callers must hold the dev->struct_mutex + * lock when calling this function, even when the driver doesn't use + * dev->struct_mutex for anything. + * + * For drivers not encumbered with legacy locking use + * drm_gem_object_unreference_unlocked() instead. + */ +void +drm_gem_object_unreference(struct drm_gem_object *obj) +{ + if (obj) { + WARN_ON(!mutex_is_locked(>dev->struct_mutex)); + + kref_put(>refcount, drm_gem_object_free); + } +} +EXPORT_SYMBOL(drm_gem_object_unreference); + +/** * drm_gem_vm_open - vma->ops->open implementation for GEM * @vma: VM area structure * diff --git a/include/drm/drmP.h b/include/drm/drmP.h index c81dd2250fc6..bd7b262d7af0 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -580,12 +580,21 @@ struct drm_driver { void (*debugfs_cleanup)(struct drm_minor *minor); /** -* Driver-specific constructor for drm_gem_objects, to set up -* obj->driver_private. +* @gem_free_object: deconstructor for drm_gem_objects * -* Returns 0 on success. +* This is deprecated and should not be used by new drivers. Use +* @gem_free_object_unlocked instead. */ void (*gem_free_object) (struct drm_gem_object *obj); + + /** +* @gem_free_object_unlocked: deconstructor for drm_gem_objects +* +* This is for drivers which are not encumbered with dev->struct_mutex +* legacy locking schemes. Use this hook instead of @gem_free_object. +*/ + void (*gem_free_object_unlocked) (struct drm_gem_object *obj); + int (*gem_open_object) (struct drm_gem_object *, struct drm_file *); void (*gem_close_object) (struct drm_gem_object *, struct drm_file *); diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h index 0b3e11ab8757..408d6c47d98b 100644 --- a/include/drm/drm_gem.h +++ b/include/drm/drm_gem.h @@ -200,47 +200,29 @@ drm_gem_object_reference(struct drm_gem_object *obj) } /** - * drm_gem_object_unreference - release a GEM BO reference + * __drm_gem_object_unreference - raw function to release a GEM BO reference * @obj: GEM buffer object * - * This releases a reference to @obj. Callers
Re: [Intel-gfx] [PATCH] mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly
On Fri, Apr 22, 2016 at 9:38 PM,wrote: > From: Ville Syrjälä > > GPIO lookup tables are supposed to be zero terminated. Let's do that > and avoid accidentally walking off the end. > > Cc: Shobhit Kumar > Cc: Samuel Ortiz > Cc: Linus Walleij > Cc: Alexandre Courbot > Cc: Thierry Reding > Cc: Lee Jones > Cc: sta...@vger.kernel.org > Fixes: 61dd2ca2d44e ("mfd: intel_soc_pmic_core: Add lookup table for Panel > Control as GPIO signal") > Signed-off-by: Ville Syrjälä Acked-by: Linus Walleij Yours, Linus Walleij ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2 1/5] drm: Introduce the blend-func property
From: Damien LespiauWe'd like to be able to program the blending modes of display planes. Ville suggested to use something similar to the GL blend states, which does seem like a good idea. For now, we only consider blend factors, but room is left for extensions: blend equation, separate rgb/alpha blend factors, blend color. V2: Added the belnd func property support in get property. Suggested-by: Ville Syrjälä Signed-off-by: Damien Lespiau Signed-off-by: Vandita Kulkarni --- Documentation/DocBook/gpu.tmpl | 11 +-- drivers/gpu/drm/drm_atomic.c | 14 ++ drivers/gpu/drm/drm_crtc.c | 5 + include/drm/drm_crtc.h | 20 4 files changed, 48 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 1464fb2..f673989 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev) Description/Restrictions - DRM + DRM Generic “rotation” BITMASK @@ -1868,7 +1868,7 @@ void intel_crt_init(struct drm_device *dev) CRTC that connector is attached to (atomic) - Plane + Plane “type” ENUM | IMMUTABLE { "Overlay", "Primary", "Cursor" } @@ -1946,6 +1946,13 @@ void intel_crt_init(struct drm_device *dev) CRTC that plane is attached to (atomic) + “blend_func” + None + DRM_BLEND_FUNC() + Plane + Source and destination blending factors + + DVI-I “subconnector” ENUM diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 8ee1db8..c2ead2d 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -701,6 +701,18 @@ int drm_atomic_plane_set_property(struct drm_plane *plane, state->src_h = val; } else if (property == config->rotation_property) { state->rotation = val; + } else if (property == config->prop_blend_func) { + enum drm_blend_factor src_factor, dst_factor; + + src_factor = DRM_BLEND_FUNC_SRC_FACTOR(val); + dst_factor = DRM_BLEND_FUNC_DST_FACTOR(val); + + if (src_factor != dst_factor && + (src_factor == DRM_BLEND_FACTOR_AUTO || + dst_factor == DRM_BLEND_FACTOR_AUTO)) + return -EINVAL; + + state->blend_mode.func = val & GENMASK(31, 0); } else if (plane->funcs->atomic_set_property) { return plane->funcs->atomic_set_property(plane, state, property, val); @@ -757,6 +769,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->src_h; } else if (property == config->rotation_property) { *val = state->rotation; + } else if (property == config->prop_blend_func) { + *val = state->blend_mode.func; } else if (plane->funcs->atomic_get_property) { return plane->funcs->atomic_get_property(plane, state, property, val); } else { diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index f7fe9e1..2cac5e1 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1587,6 +1587,11 @@ static int drm_mode_create_standard_properties(struct drm_device *dev) return -ENOMEM; dev->mode_config.gamma_lut_size_property = prop; + prop = drm_property_create_range(dev, 0, "blend_func", 0, U32_MAX); + if (!prop) + return -ENOMEM; + dev->mode_config.prop_blend_func = prop; + return 0; } diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 6d46842..269f660 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -89,6 +89,23 @@ static inline uint64_t I642U64(int64_t val) #define DRM_REFLECT_X 4 #define DRM_REFLECT_Y 5 +enum drm_blend_factor { + DRM_BLEND_FACTOR_AUTO, + DRM_BLEND_FACTOR_ZERO, + DRM_BLEND_FACTOR_ONE, + DRM_BLEND_FACTOR_SRC_ALPHA, + DRM_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA, +}; + +#define DRM_BLEND_FUNC(src_factor, dst_factor) \ + (DRM_BLEND_FACTOR_##src_factor << 16 | DRM_BLEND_FACTOR_##dst_factor) +#define DRM_BLEND_FUNC_SRC_FACTOR(val) (((val) >> 16) & 0x) +#define DRM_BLEND_FUNC_DST_FACTOR(val) ((val) & 0x) + +struct drm_blend_mode { + uint64_t func; +}; + enum drm_connector_force { DRM_FORCE_UNSPECIFIED, DRM_FORCE_OFF, @@ -1273,6 +1290,8 @@ struct drm_plane_state { /* Plane rotation */ unsigned int rotation; + struct drm_blend_mode blend_mode; + struct drm_atomic_state *state; }; @@ -2125,6 +2144,7
[Intel-gfx] [PATCHv2 4/5] drm: Add an blend_color property
From: Damien LespiauAdd blend color property and update the documentation for the same V2: Add blend color support in get property. Signed-off-by: Damien Lespiau Signed-off-by: vandita kulkarni --- Documentation/DocBook/gpu.tmpl | 11 +-- drivers/gpu/drm/drm_atomic.c | 4 drivers/gpu/drm/drm_crtc.c | 5 + include/drm/drm_crtc.h | 6 ++ 4 files changed, 24 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index f673989..8572c9a 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev) Description/Restrictions - DRM + DRM Generic “rotation” BITMASK @@ -1868,7 +1868,7 @@ void intel_crt_init(struct drm_device *dev) CRTC that connector is attached to (atomic) - Plane + Plane “type” ENUM | IMMUTABLE { "Overlay", "Primary", "Cursor" } @@ -1953,6 +1953,13 @@ void intel_crt_init(struct drm_device *dev) Source and destination blending factors + “blend_color” + Color + DRM_MODE_COLOR() + Plane + Blend constant color + + DVI-I “subconnector” ENUM diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index c2ead2d..20340de 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -713,6 +713,8 @@ int drm_atomic_plane_set_property(struct drm_plane *plane, return -EINVAL; state->blend_mode.func = val & GENMASK(31, 0); + } else if (property == config->prop_blend_color) { + state->blend_mode.color = val; } else if (plane->funcs->atomic_set_property) { return plane->funcs->atomic_set_property(plane, state, property, val); @@ -771,6 +773,8 @@ drm_atomic_plane_get_property(struct drm_plane *plane, *val = state->rotation; } else if (property == config->prop_blend_func) { *val = state->blend_mode.func; + } else if (property == config->prop_blend_color) { + *val = state->blend_mode.color; } else if (plane->funcs->atomic_get_property) { return plane->funcs->atomic_get_property(plane, state, property, val); } else { diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 2cac5e1..65cbaea 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1592,6 +1592,11 @@ static int drm_mode_create_standard_properties(struct drm_device *dev) return -ENOMEM; dev->mode_config.prop_blend_func = prop; + prop = drm_property_create_range(dev, 0, "blend_color", 0, U64_MAX); + if (!prop) + return -ENOMEM; + dev->mode_config.prop_blend_color = prop; + return 0; } diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 269f660..33d5845 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -95,6 +95,10 @@ enum drm_blend_factor { DRM_BLEND_FACTOR_ONE, DRM_BLEND_FACTOR_SRC_ALPHA, DRM_BLEND_FACTOR_ONE_MINUS_SRC_ALPHA, + DRM_BLEND_FACTOR_CONSTANT_ALPHA, + DRM_BLEND_FACTOR_ONE_MINUS_CONSTANT_ALPHA, + DRM_BLEND_FACTOR_CONSTANT_ALPHA_TIMES_SRC_ALPHA, + DRM_BLEND_FACTOR_ONE_MINUS_CONSTANT_ALPHA_TIMES_SRC_ALPHA, }; #define DRM_BLEND_FUNC(src_factor, dst_factor) \ @@ -103,6 +107,7 @@ enum drm_blend_factor { #define DRM_BLEND_FUNC_DST_FACTOR(val) ((val) & 0x) struct drm_blend_mode { + uint64_t color; uint64_t func; }; @@ -2145,6 +2150,7 @@ struct drm_mode_config { struct drm_property *prop_active; struct drm_property *prop_mode_id; struct drm_property *prop_blend_func; + struct drm_property *prop_blend_color; /* DVI-I properties */ struct drm_property *dvi_i_subconnector_property; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2 5/5] drm/i915/skl: Add support for blending modes
From: Damien LespiauThis patch adds support for blending modes involving color. V2: Add support for primary plane. Separate out plane alpha disable functionality from per pixel drop_alpha blend function and add another blend function case for disabling plane alpha. Signed-off-by: Damien Lespiau Signed-off-by: vandita kulkarni --- drivers/gpu/drm/i915/i915_reg.h | 4 +++ drivers/gpu/drm/i915/intel_display.c | 47 drivers/gpu/drm/i915/intel_drv.h | 3 +++ drivers/gpu/drm/i915/intel_sprite.c | 9 +-- 4 files changed, 61 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 9464ba3..4d0c39d 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -5515,6 +5515,10 @@ enum skl_disp_power_wells { #define PLANE_KEYMAX(pipe, plane) \ _MMIO_PLANE(plane, _PLANE_KEYMAX_1(pipe), _PLANE_KEYMAX_2(pipe)) +#define PLANE_KEYMAX_ALPHA_MASK0x00ff +#define PLANE_KEY_MASK_ALPHA_EN31 +#define PLANE_KEY_MAX_ALPHA_SHIFT 24 + #define _PLANE_BUF_CFG_1_B 0x7127c #define _PLANE_BUF_CFG_2_B 0x7137c #define _PLANE_BUF_CFG_1(pipe) \ diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 037407f..31755f2 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3032,6 +3032,8 @@ static void skylake_update_primary_plane(struct drm_plane *plane, struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc); struct drm_framebuffer *fb = plane_state->base.fb; struct drm_i915_gem_object *obj = intel_fb_obj(fb); + const struct drm_intel_sprite_colorkey *key = + _intel_plane_state(plane->state)->ckey; int pipe = intel_crtc->pipe; u32 plane_ctl, stride_div, stride; u32 tile_height, plane_offset, plane_size; @@ -3064,6 +3066,15 @@ static void skylake_update_primary_plane(struct drm_plane *plane, WARN_ON(drm_rect_width(_state->src) == 0); + I915_WRITE(PLANE_KEYMAX(pipe, 0), (DRM_MODE_COLOR_ALPHA_8 + (plane_state->base.blend_mode.color) + << PLANE_KEY_MAX_ALPHA_SHIFT) | + (key->max_value & PLANE_KEYMAX_ALPHA_MASK)); + I915_WRITE(PLANE_KEYMSK(pipe, 0), + (plane_state->use_plane_alpha + << PLANE_KEY_MASK_ALPHA_EN) | + (key->channel_mask & GENMASK(0, 26))); + if (intel_rotation_90_or_270(rotation)) { int cpp = drm_format_plane_cpp(fb->pixel_format, 0); @@ -3146,6 +3157,7 @@ static int intel_plane_state_check_blend(struct drm_plane_state *plane_state) case DRM_BLEND_FUNC(AUTO, AUTO): if (has_per_pixel_blending) state->per_pixel_alpha = PRE_MULTIPLIED_ALPHA; + state->use_plane_alpha = false; break; /* fbs without an alpha channel, or dropping the alpha channel */ case DRM_BLEND_FUNC(ONE, ZERO): @@ -3158,6 +3170,7 @@ static int intel_plane_state_check_blend(struct drm_plane_state *plane_state) state->per_pixel_alpha = DROP_ALPHA; else state->per_pixel_alpha = PRE_MULTIPLIED_ALPHA; + state->use_plane_alpha = false; break; /* non pre-multiplied alpha */ case DRM_BLEND_FUNC(SRC_ALPHA, ONE_MINUS_SRC_ALPHA): @@ -3165,6 +3178,34 @@ static int intel_plane_state_check_blend(struct drm_plane_state *plane_state) state->per_pixel_alpha = DROP_ALPHA; else state->per_pixel_alpha = NON_PRE_MULTIPLIED_ALPHA; + state->use_plane_alpha = false; + break; + /* plane alpha */ + case DRM_BLEND_FUNC(CONSTANT_ALPHA, ONE_MINUS_CONSTANT_ALPHA): + state->use_plane_alpha = true; + break; + /* plane alpha, pre-multiplied fb */ + case DRM_BLEND_FUNC(CONSTANT_ALPHA, + ONE_MINUS_CONSTANT_ALPHA_TIMES_SRC_ALPHA): + if (!has_per_pixel_blending) + state->per_pixel_alpha = DROP_ALPHA; + else + state->per_pixel_alpha = PRE_MULTIPLIED_ALPHA; + /*TBD bspec check*/ + state->use_plane_alpha = true; + break; + /* plane alpha, non pre-multiplied fb */ + case DRM_BLEND_FUNC(CONSTANT_ALPHA_TIMES_SRC_ALPHA, + ONE_MINUS_CONSTANT_ALPHA_TIMES_SRC_ALPHA): + if (!has_per_pixel_blending) + state->per_pixel_alpha = DROP_ALPHA; + else
[Intel-gfx] [PATCHv2 0/5] Support blending modes of display planes
From: vandita kulkarniThe below patches support plane and pixel blending by adding two properties blend_func and blend_color. As per Damien's initial patches, this design based on OpenGL's blend equations is suggested by Ville. All the below patches are tested on BXT android platform. V2: Squashed all the blend color related patches to one single patch and blend func related pathces into one single patch. The initial kernel patches from damien can be found at https://github.com/dlespiau/linux/commits/20150708-alpha-blending Damien Lespiau (5): drm: Introduce the blend-func property drm/i915/skl: Add blend_func to SKL/BXT sprite planes drm: Introduce DRM_MODE_COLOR() drm: Add an blend_color property drm/i915/skl: Add support for blending modes The initial version of kms_blend, igt by Damien can be found at https://github.com/dlespiau/intel-gpu-tools/commits/20150613-blend Damien Lespiau (5): drm: Introduce the blend-func property drm/i915/skl: Add blend_func to SKL/BXT sprite planes drm: Introduce DRM_MODE_COLOR() drm: Add an blend_color property drm/i915/skl: Add support for blending modes Documentation/DocBook/gpu.tmpl | 18 +++- drivers/gpu/drm/drm_atomic.c | 18 drivers/gpu/drm/drm_crtc.c | 10 +++ drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_display.c | 168 +-- drivers/gpu/drm/i915/intel_drv.h | 17 +++- drivers/gpu/drm/i915/intel_sprite.c | 15 +++- include/drm/drm_crtc.h | 26 ++ include/uapi/drm/drm_mode.h | 34 +++ 9 files changed, 298 insertions(+), 12 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2 2/5] drm/i915/skl: Add blend_func to SKL/BXT sprite planes
From: Damien LespiauThis patch adds the blend functions, and as per the blend function, updates the plane control register values V2: Add blend support for all RGB formats Fix the reg writes on plane_ctl_alpha bits. V3: Add support support for primary and cursor planes. fix an issue where the previous value was not retained, change the logic to do so. Signed-off-by: Damien Lespiau Signed-off-by: vandita kulkarni --- drivers/gpu/drm/i915/intel_display.c | 121 +-- drivers/gpu/drm/i915/intel_drv.h | 14 +++- drivers/gpu/drm/i915/intel_sprite.c | 6 +- 3 files changed, 133 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c5b9687..037407f 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2921,8 +2921,29 @@ static void skl_detach_scalers(struct intel_crtc *intel_crtc) } } -u32 skl_plane_ctl_format(uint32_t pixel_format) +u32 skl_plane_ctl_format(uint32_t pixel_format, + enum per_pixel_alpha_state alpha) { + u32 plane_ctl_alpha = 0; + + if (pixel_format == DRM_FORMAT_ABGR || + pixel_format == DRM_FORMAT_ARGB) { + + switch (alpha) { + case DROP_ALPHA: + plane_ctl_alpha = PLANE_CTL_ALPHA_DISABLE; + break; + case PRE_MULTIPLIED_ALPHA: + plane_ctl_alpha = PLANE_CTL_ALPHA_SW_PREMULTIPLY; + break; + case NON_PRE_MULTIPLIED_ALPHA: + plane_ctl_alpha = PLANE_CTL_ALPHA_HW_PREMULTIPLY; + break; + default: + MISSING_CASE(alpha); + } + } + switch (pixel_format) { case DRM_FORMAT_C8: return PLANE_CTL_FORMAT_INDEXED; @@ -2938,11 +2959,11 @@ u32 skl_plane_ctl_format(uint32_t pixel_format) * DRM_FORMAT) for user-space to configure that. */ case DRM_FORMAT_ABGR: - return PLANE_CTL_FORMAT_XRGB_ | PLANE_CTL_ORDER_RGBX | - PLANE_CTL_ALPHA_SW_PREMULTIPLY; + return ((PLANE_CTL_FORMAT_XRGB_ | (PLANE_CTL_ORDER_RGBX + & (~PLANE_CTL_ALPHA_MASK))) | plane_ctl_alpha); case DRM_FORMAT_ARGB: - return PLANE_CTL_FORMAT_XRGB_ | - PLANE_CTL_ALPHA_SW_PREMULTIPLY; + return ((PLANE_CTL_FORMAT_XRGB_ & ~PLANE_CTL_ALPHA_MASK) + | plane_ctl_alpha); case DRM_FORMAT_XRGB2101010: return PLANE_CTL_FORMAT_XRGB_2101010; case DRM_FORMAT_XBGR2101010: @@ -3031,7 +3052,8 @@ static void skylake_update_primary_plane(struct drm_plane *plane, PLANE_CTL_PIPE_GAMMA_ENABLE | PLANE_CTL_PIPE_CSC_ENABLE; - plane_ctl |= skl_plane_ctl_format(fb->pixel_format); + plane_ctl |= skl_plane_ctl_format(fb->pixel_format, + plane_state->per_pixel_alpha); plane_ctl |= skl_plane_ctl_tiling(fb->modifier[0]); plane_ctl |= PLANE_CTL_PLANE_GAMMA_DISABLE; plane_ctl |= skl_plane_ctl_rotation(rotation); @@ -3087,6 +3109,69 @@ static void skylake_update_primary_plane(struct drm_plane *plane, POSTING_READ(PLANE_SURF(pipe, 0)); } +static int intel_plane_state_check_blend(struct drm_plane_state *plane_state) +{ + struct drm_device *dev = plane_state->state->dev; + struct intel_plane_state *state = to_intel_plane_state(plane_state); + const struct drm_framebuffer *fb = plane_state->fb; + const struct drm_blend_mode *mode = >base.blend_mode; + bool has_per_pixel_blending; + + /* +* We don't install the properties pre-SKL, so this is SKL+ specific +* code for now. +*/ + if (INTEL_INFO(dev)->gen < 9) + return 0; + + if (!fb) + return 0; + + has_per_pixel_blending = fb->pixel_format == DRM_FORMAT_ABGR || + fb->pixel_format == DRM_FORMAT_RGBA || + fb->pixel_format == DRM_FORMAT_ARGB || + fb->pixel_format == DRM_FORMAT_BGRA; + + /* drop alpha for all fbs without an alpha channel */ + if (!has_per_pixel_blending) + state->per_pixel_alpha = DROP_ALPHA; + + switch (mode->func) { + /* +* The 'AUTO' behaviour is the default and keeps compatibility with +* kernels before the introduction of the blend_func property: +* - pre-multiplied alpha if the fb has an alpha channel +* - usual DRM_BLEND_FUNC(ONE, ZERO) otherwise +*/ + case
[Intel-gfx] [PATCHv2 3/5] drm: Introduce DRM_MODE_COLOR()
From: Damien LespiauIn the hope of expressing colors in the KMS API in a consitant want, let's introduce a ARGB 16161616 color and a few convinience macros around it. Signed-off-by: Damien Lespiau --- include/uapi/drm/drm_mode.h | 34 ++ 1 file changed, 34 insertions(+) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 7a7856e..203c7ab0 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -295,6 +295,40 @@ struct drm_mode_get_connector { */ #define DRM_MODE_PROP_ATOMIC0x8000 +/* Color for the KMS API, ARGB (msb -> lsb) 16bits per component. */ +#define DRM_MODE_COLOR(a, r, b, g) \ + (((__u64)(a) << 48) | ((__u64)(r) << 32) | \ +((__u64)(g) << 16) | (__u64)(b)) + +/* Extract full precision, 8 bits, 10 bits and 12 bits components. */ +#define DRM_MODE_COLOR_ALPHA(color)(((color) >> 48) & 0x) +#define DRM_MODE_COLOR_RED(color) (((color) >> 32) & 0x) +#define DRM_MODE_COLOR_BLUE(color) (((color) >> 16) & 0x) +#define DRM_MODE_COLOR_GREEN(color)((color) & 0x) +#define DRM_MODE_COLOR_ALPHA_8(color) (((color) >> (48 + 8)) & 0xff) +#define DRM_MODE_COLOR_RED_8(color)(((color) >> (32 + 8)) & 0xff) +#define DRM_MODE_COLOR_BLUE_8(color) (((color) >> (16 + 8)) & 0xff) +#define DRM_MODE_COLOR_GREEN_8(color) (((color) >> 8) & 0xff) +#define DRM_MODE_COLOR_ALPHA_10(color) (((color) >> (48 + 6)) & 0x3ff) +#define DRM_MODE_COLOR_RED_10(color) (((color) >> (32 + 6)) & 0x3ff) +#define DRM_MODE_COLOR_BLUE_10(color) (((color) >> (16 + 6)) & 0x3ff) +#define DRM_MODE_COLOR_GREEN_10(color) (((color) >> 6) & 0x3ff) +#define DRM_MODE_COLOR_ALPHA_12(color) (((color) >> (48 + 4)) & 0xfff) +#define DRM_MODE_COLOR_RED_12(color) (((color) >> (32 + 4)) & 0xfff) +#define DRM_MODE_COLOR_BLUE_12(color) (((color) >> (16 + 4)) & 0xfff) +#define DRM_MODE_COLOR_GREEN_12(color) (((color) >> 4) & 0xfff) + +/* Handy macros to convert a DRM_MODE_COLOR() into common precisions */ +#define DRM_MODE_COLOR_TO_ARGB_(color) \ + ((DRM_MODE_COLOR_ALPHA_8(color) << 24) | \ +(DRM_MODE_COLOR_RED_8(color) << 16) | \ +(DRM_MODE_COLOR_GREEN_8(color) << 8) | \ +DRM_MODE_COLOR_BLUE_8(color)) +#define DRM_MODE_COLOR_TO_RGB_101010(color) \ +((DRM_MODE_COLOR_RED_10(color) << 20) | \ +(DRM_MODE_COLOR_GREEN_10(color) << 10) | \ +DRM_MODE_COLOR_BLUE_10(color)) + struct drm_mode_property_enum { __u64 value; char name[DRM_PROP_NAME_LEN]; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup
On 29/04/16 10:15, Chris Wilson wrote: On Fri, Apr 29, 2016 at 10:04:35AM +0100, Tvrtko Ursulin wrote: On 28/04/16 18:35, Chris Wilson wrote: Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set together. Signed-off-by: Chris WilsonCc: Tvrtko Ursulin Cc: Dave Gordon --- drivers/gpu/drm/i915/intel_lrc.c | 176 +-- 1 file changed, 93 insertions(+), 83 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 874c2515f9d4..2e0eaa9fa240 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1921,8 +1921,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs *engine) } static void -logical_ring_default_vfuncs(struct drm_device *dev, - struct intel_engine_cs *engine) +logical_ring_default_vfuncs(struct intel_engine_cs *engine) { /* Default vfuncs which can be overriden by each engine. */ engine->init_hw = gen8_init_common_ring; @@ -1933,7 +1932,7 @@ logical_ring_default_vfuncs(struct drm_device *dev, engine->emit_bb_start = gen8_emit_bb_start; engine->get_seqno = gen8_get_seqno; engine->set_seqno = gen8_set_seqno; - if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) { + if (IS_BXT_REVID(engine->dev, 0, BXT_REVID_A1)) { engine->irq_seqno_barrier = bxt_a_seqno_barrier; engine->set_seqno = bxt_a_set_seqno; } @@ -1944,6 +1943,7 @@ logical_ring_default_irqs(struct intel_engine_cs *engine, unsigned shift) { engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT << shift; engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift; + init_waitqueue_head(>irq_queue); } static int @@ -1964,31 +1964,68 @@ lrc_setup_hws(struct intel_engine_cs *engine, return 0; } -static int -logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine) +static const struct logical_ring_info { + const char *name; + unsigned exec_id; + unsigned guc_id; + u32 mmio_base; + unsigned irq_shift; +} logical_rings[] = { + [RCS] = { + .name = "render ring", + .exec_id = I915_EXEC_RENDER, + .guc_id = GUC_RENDER_ENGINE, + .mmio_base = RENDER_RING_BASE, + .irq_shift = GEN8_RCS_IRQ_SHIFT, + }, + [BCS] = { + .name = "blitter ring", + .exec_id = I915_EXEC_BLT, + .guc_id = GUC_BLITTER_ENGINE, + .mmio_base = BLT_RING_BASE, + .irq_shift = GEN8_BCS_IRQ_SHIFT, + }, + [VCS] = { + .name = "bsd ring", + .exec_id = I915_EXEC_BSD, + .guc_id = GUC_VIDEO_ENGINE, + .mmio_base = GEN6_BSD_RING_BASE, + .irq_shift = GEN8_VCS1_IRQ_SHIFT, + }, + [VCS2] = { + .name = "bsd2 ring", + .exec_id = I915_EXEC_BSD, + .guc_id = GUC_VIDEO_ENGINE2, + .mmio_base = GEN8_BSD2_RING_BASE, + .irq_shift = GEN8_VCS2_IRQ_SHIFT, + }, + [VECS] = { + .name = "video enhancement ring", + .exec_id = I915_EXEC_VEBOX, + .guc_id = GUC_VIDEOENHANCE_ENGINE, + .mmio_base = VEBOX_RING_BASE, + .irq_shift = GEN8_VECS_IRQ_SHIFT, + }, +}; + +static struct intel_engine_cs * +logical_ring_setup(struct drm_device *dev, enum intel_engine_id id) { Would dev_priv be better? Just to gradually move towards the correct state of things. I have a patch queued up to do engine->i915 (1 KiB in object code reduction) next. + const struct logical_ring_info *info = _rings[id]; struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_context *dctx = dev_priv->kernel_context; + struct intel_engine_cs *engine = _priv->engine[id]; enum forcewake_domains fw_domains; - int ret; - - /* Intentionally left blank. */ - engine->buffer = NULL; engine->dev = dev; Looking at usages of intel_engine_initialized... one potential danger scenario would be interrupt noise during driver load end in notify ring and explodes. Sounds very unlikely but theoretically it is a regression compared to where engine->dev initialization was before. We should really move away from engine->dev for this and just add an explicit flag. Hmm. not that but I think we really should be sanitizing the irq here and enabling them last. Like: diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 2e0eaa9fa240..2c94072ab085 100644 ---
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Bump reserved size for legacy gen8 semaphore emission
== Series Details == Series: series starting with [CI,1/3] drm/i915: Bump reserved size for legacy gen8 semaphore emission URL : https://patchwork.freedesktop.org/series/6523/ State : success == Summary == Series 6523v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/6523/revisions/1/mbox/ Test gem_exec_whisper: Subgroup basic: dmesg-warn -> PASS (ilk-hp8440p) Test gem_sync: Subgroup basic-render: dmesg-warn -> PASS (ilk-hp8440p) Test kms_force_connector_basic: Subgroup force-load-detect: skip -> PASS (hsw-gt2) bdw-nuci7-2 total:201 pass:189 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:201 pass:176 dwarn:0 dfail:0 fail:0 skip:25 bsw-nuc-2total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 byt-nuc total:200 pass:159 dwarn:0 dfail:0 fail:0 skip:41 hsw-brixbox total:201 pass:175 dwarn:0 dfail:0 fail:0 skip:26 hsw-gt2 total:201 pass:179 dwarn:0 dfail:0 fail:1 skip:21 ilk-hp8440p total:201 pass:140 dwarn:0 dfail:0 fail:0 skip:61 ivb-t430stotal:201 pass:170 dwarn:0 dfail:0 fail:0 skip:31 skl-i7k-2total:201 pass:174 dwarn:0 dfail:0 fail:0 skip:27 skl-nuci5total:201 pass:190 dwarn:0 dfail:0 fail:0 skip:11 snb-x220ttotal:201 pass:159 dwarn:0 dfail:0 fail:1 skip:41 snb-dellxps failed to collect. IGT log at Patchwork_2108/snb-dellxps/igt.log Results at /archive/results/CI_IGT_test/Patchwork_2108/ f739e448f0278feb6bfcbf2f0caf6fa9a6a2b0a1 drm-intel-nightly: 2016y-04m-29d-08h-04m-09s UTC integration manifest 1ad60b0 drm/i915: Trim the flush for the execlists request emission 5c6cb25 drm/i915: Trim the flush for the legacy request emission acee343 drm/i915: Bump reserved size for legacy gen8 semaphore emission ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup
On Fri, Apr 29, 2016 at 10:04:35AM +0100, Tvrtko Ursulin wrote: > > On 28/04/16 18:35, Chris Wilson wrote: > >Move all of the constant assignments up front and into a common > >function. This is primarily to ensure the backpointers are set as early > >as possible for later use during initialisation. > > > >v2: Use a constant struct so that all the similar values are set > >together. > > > >Signed-off-by: Chris Wilson> >Cc: Tvrtko Ursulin > >Cc: Dave Gordon > >--- > > drivers/gpu/drm/i915/intel_lrc.c | 176 > > +-- > > 1 file changed, 93 insertions(+), 83 deletions(-) > > > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >b/drivers/gpu/drm/i915/intel_lrc.c > >index 874c2515f9d4..2e0eaa9fa240 100644 > >--- a/drivers/gpu/drm/i915/intel_lrc.c > >+++ b/drivers/gpu/drm/i915/intel_lrc.c > >@@ -1921,8 +1921,7 @@ void intel_logical_ring_cleanup(struct intel_engine_cs > >*engine) > > } > > > > static void > >-logical_ring_default_vfuncs(struct drm_device *dev, > >-struct intel_engine_cs *engine) > >+logical_ring_default_vfuncs(struct intel_engine_cs *engine) > > { > > /* Default vfuncs which can be overriden by each engine. */ > > engine->init_hw = gen8_init_common_ring; > >@@ -1933,7 +1932,7 @@ logical_ring_default_vfuncs(struct drm_device *dev, > > engine->emit_bb_start = gen8_emit_bb_start; > > engine->get_seqno = gen8_get_seqno; > > engine->set_seqno = gen8_set_seqno; > >-if (IS_BXT_REVID(dev, 0, BXT_REVID_A1)) { > >+if (IS_BXT_REVID(engine->dev, 0, BXT_REVID_A1)) { > > engine->irq_seqno_barrier = bxt_a_seqno_barrier; > > engine->set_seqno = bxt_a_set_seqno; > > } > >@@ -1944,6 +1943,7 @@ logical_ring_default_irqs(struct intel_engine_cs > >*engine, unsigned shift) > > { > > engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT << shift; > > engine->irq_keep_mask = GT_CONTEXT_SWITCH_INTERRUPT << shift; > >+init_waitqueue_head(>irq_queue); > > } > > > > static int > >@@ -1964,31 +1964,68 @@ lrc_setup_hws(struct intel_engine_cs *engine, > > return 0; > > } > > > >-static int > >-logical_ring_init(struct drm_device *dev, struct intel_engine_cs *engine) > >+static const struct logical_ring_info { > >+const char *name; > >+unsigned exec_id; > >+unsigned guc_id; > >+u32 mmio_base; > >+unsigned irq_shift; > >+} logical_rings[] = { > >+[RCS] = { > >+.name = "render ring", > >+.exec_id = I915_EXEC_RENDER, > >+.guc_id = GUC_RENDER_ENGINE, > >+.mmio_base = RENDER_RING_BASE, > >+.irq_shift = GEN8_RCS_IRQ_SHIFT, > >+}, > >+[BCS] = { > >+.name = "blitter ring", > >+.exec_id = I915_EXEC_BLT, > >+.guc_id = GUC_BLITTER_ENGINE, > >+.mmio_base = BLT_RING_BASE, > >+.irq_shift = GEN8_BCS_IRQ_SHIFT, > >+}, > >+[VCS] = { > >+.name = "bsd ring", > >+.exec_id = I915_EXEC_BSD, > >+.guc_id = GUC_VIDEO_ENGINE, > >+.mmio_base = GEN6_BSD_RING_BASE, > >+.irq_shift = GEN8_VCS1_IRQ_SHIFT, > >+}, > >+[VCS2] = { > >+.name = "bsd2 ring", > >+.exec_id = I915_EXEC_BSD, > >+.guc_id = GUC_VIDEO_ENGINE2, > >+.mmio_base = GEN8_BSD2_RING_BASE, > >+.irq_shift = GEN8_VCS2_IRQ_SHIFT, > >+}, > >+[VECS] = { > >+.name = "video enhancement ring", > >+.exec_id = I915_EXEC_VEBOX, > >+.guc_id = GUC_VIDEOENHANCE_ENGINE, > >+.mmio_base = VEBOX_RING_BASE, > >+.irq_shift = GEN8_VECS_IRQ_SHIFT, > >+}, > >+}; > >+ > >+static struct intel_engine_cs * > >+logical_ring_setup(struct drm_device *dev, enum intel_engine_id id) > > { > > Would dev_priv be better? Just to gradually move towards the correct > state of things. I have a patch queued up to do engine->i915 (1 KiB in object code reduction) next. > >+const struct logical_ring_info *info = _rings[id]; > > struct drm_i915_private *dev_priv = to_i915(dev); > >-struct intel_context *dctx = dev_priv->kernel_context; > >+struct intel_engine_cs *engine = _priv->engine[id]; > > enum forcewake_domains fw_domains; > >-int ret; > >- > >-/* Intentionally left blank. */ > >-engine->buffer = NULL; > > > > engine->dev = dev; > > Looking at usages of intel_engine_initialized... one potential > danger scenario would be interrupt noise during driver load end in > notify ring and explodes. Sounds very unlikely but theoretically it > is a regression compared to where engine->dev initialization was > before. > > We should really move away from engine->dev for this and just add an > explicit flag. Hmm. not that but I think we really should be sanitizing the irq here and enabling them last. Like: diff --git
Re: [Intel-gfx] [PATCH 15/21] drm/i915/slpc: Notification of Refresh Rate change
On Wed, Apr 27, 2016 at 06:10:59PM -0700, tom.orou...@intel.com wrote: > From: Sagar Arun Kamble> > This patch will inform GuC SLPC about changes in the refresh rate > due to Seamless DRRS. Refresh rate changes due to Static DRRS will > be notified via commit path. > > v2: Rebased on previous changed patch and printed error message if > H2G action fails. > v2(torourke): Updates suggested by Paulo: replace HAS_SLPC with > intel_slpc_active. return void instead of ignored error code. > > Signed-off-by: Sagar Arun Kamble > Signed-off-by: Tom O'Rourke > --- > drivers/gpu/drm/i915/intel_dp.c | 2 ++ > drivers/gpu/drm/i915/intel_slpc.c | 23 +++ > drivers/gpu/drm/i915/intel_slpc.h | 1 + > 3 files changed, 26 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index c12c414..3d41f7b 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -5379,6 +5379,8 @@ static void intel_dp_set_drrs_state(struct drm_device > *dev, int refresh_rate) > dev_priv->drrs.refresh_rate_type = index; > > DRM_DEBUG_KMS("eDP Refresh Rate set to : %dHz\n", refresh_rate); > + > + intel_slpc_update_display_rr_info(dev, refresh_rate); > } > > /** > diff --git a/drivers/gpu/drm/i915/intel_slpc.c > b/drivers/gpu/drm/i915/intel_slpc.c > index 7f26284..9e0bc96 100644 > --- a/drivers/gpu/drm/i915/intel_slpc.c > +++ b/drivers/gpu/drm/i915/intel_slpc.c > @@ -364,3 +364,26 @@ void intel_slpc_update_atomic_commit_info(struct > drm_device *dev, > if (notify) > host2guc_slpc_display_mode_change(dev); > } > + > +void intel_slpc_update_display_rr_info(struct drm_device *dev, u32 > refresh_rate) > +{ > + struct drm_i915_private *dev_priv = dev->dev_private; > + struct drm_crtc *crtc; > + struct intel_display_pipe_info *per_pipe_info; > + struct intel_slpc_display_mode_event_params *display_params; > + > + if (!intel_slpc_active(dev)) > + return; > + > + if (!refresh_rate) > + return; > + > + display_params = _priv->guc.slpc.display_mode_params; > + crtc = dp_to_dig_port(dev_priv->drrs.dp)->base.base.crtc; > + > + per_pipe_info = > _params->per_pipe_info[to_intel_crtc(crtc)->pipe]; > + per_pipe_info->refresh_rate = refresh_rate; > + per_pipe_info->vsync_ft_usec = 100 / refresh_rate; > + > + host2guc_slpc_display_mode_change(dev); > +} Other people already commented, but I'll just add that this in any case looks rather bogus. Only updated for a single pipe when it has drrs enabled, non-drrs and all the other pipes left out. What's that about? > diff --git a/drivers/gpu/drm/i915/intel_slpc.h > b/drivers/gpu/drm/i915/intel_slpc.h > index 39b4657..0b251a1 100644 > --- a/drivers/gpu/drm/i915/intel_slpc.h > +++ b/drivers/gpu/drm/i915/intel_slpc.h > @@ -153,5 +153,6 @@ void intel_slpc_reset(struct drm_device *dev); > void intel_slpc_update_display_mode_info(struct drm_device *dev); > void intel_slpc_update_atomic_commit_info(struct drm_device *dev, > struct drm_atomic_state *state); > +void intel_slpc_update_display_rr_info(struct drm_device *dev, u32 > refresh_rate); > > #endif > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx