Re: [Intel-gfx] [PATCH] drm/i915: Bug fixes to ring 'head' updating
On Mon, Nov 03, 2014 at 01:29:04PM +, Dave Gordon wrote: Fixes to both the LRC and the legacy ringbuffer code to correctly calculate and update the available space in a ring. The logical ring code was updating the software ring 'head' value by reading the hardware 'HEAD' register. In LRC mode, this is not valid as the hardware is not necessarily executing the same context that is being processed by the software. Thus reading the h/w HEAD could put an unrelated (undefined, effectively random) value into the s/w 'head' -- A Bad Thing for the free space calculations. In addition, the old code could update a ringbuffer's 'head' value from the 'last_retired_head' even when the latter hadn't been recently updated and therefore had a value of -1; this would also confuse the freespace calculations. Now, we consume 'last_retired_head' in just one place, ensuring that this confusion does not arise. Change-Id: Id7ce9096ed100a2882c68a54206f30b6c87e92fa Signed-off-by: Dave Gordon david.s.gor...@intel.com Is there an igt testcase which readily reproduces this? Or can we have one? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Free resources correctly if we cannot map status page during ctx create
On Tue, Nov 18, 2014 at 07:44:40AM +, Chris Wilson wrote:
On Mon, Nov 17, 2014 at 08:04:09PM +0100, Daniel Vetter wrote:
On Mon, Nov 17, 2014 at 03:48:27PM +, Arun Siluvery wrote:
We are not freeing memory allocated for ringbuf and ctx if we fail
to map status page so release all resources correctly.
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c
b/drivers/gpu/drm/i915/intel_lrc.c
index f3efdbd..a84d24b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1777,8 +1777,10 @@ int intel_lr_context_deferred_create(struct
intel_context *ctx,
ring-status_page.gfx_addr = i915_gem_obj_ggtt_offset(ctx_obj);
ring-status_page.page_addr =
kmap(sg_page(ctx_obj-pages-sgl));
- if (ring-status_page.page_addr == NULL)
- return -ENOMEM;
+ if (ring-status_page.page_addr == NULL) {
+ ret = -ENOMEM;
+ goto error;
+ }
Since this popped up: Do we have an automated igt testcase to exercise
this corner-case?
How? kmap() never returns NULL.
Oh dear.
/me hangs head in shame
I'll do a patch to correct this.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Drop return value from lrc_setup_hardware_status_page
kmap never fails.
Spotted-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Arun Siluvery arun.siluv...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 15 +++
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index b7c4c9ab9012..3cf15c4da0e8 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1706,7 +1706,7 @@ static uint32_t get_lr_context_size(struct
intel_engine_cs *ring)
return ret;
}
-static int lrc_setup_hardware_status_page(struct intel_engine_cs *ring,
+static void lrc_setup_hardware_status_page(struct intel_engine_cs *ring,
struct drm_i915_gem_object *default_ctx_obj)
{
struct drm_i915_private *dev_priv = ring-dev-dev_private;
@@ -1716,15 +1716,11 @@ static int lrc_setup_hardware_status_page(struct
intel_engine_cs *ring,
ring-status_page.gfx_addr = i915_gem_obj_ggtt_offset(default_ctx_obj);
ring-status_page.page_addr =
kmap(sg_page(default_ctx_obj-pages-sgl));
- if (ring-status_page.page_addr == NULL)
- return -ENOMEM;
ring-status_page.obj = default_ctx_obj;
I915_WRITE(RING_HWS_PGA(ring-mmio_base),
(u32)ring-status_page.gfx_addr);
POSTING_READ(RING_HWS_PGA(ring-mmio_base));
-
- return 0;
}
/**
@@ -1811,13 +1807,8 @@ int intel_lr_context_deferred_create(struct
intel_context *ctx,
ctx-engine[ring-id].ringbuf = ringbuf;
ctx-engine[ring-id].state = ctx_obj;
- if (ctx == ring-default_context) {
- ret = lrc_setup_hardware_status_page(ring, ctx_obj);
- if (ret) {
- DRM_ERROR(Failed to setup hardware status page\n);
- goto error;
- }
- }
+ if (ctx == ring-default_context)
+ lrc_setup_hardware_status_page(ring, ctx_obj);
if (ring-id == RCS !ctx-rcs_initialized) {
if (ring-init_context) {
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0
-Original Message- From: Lespiau, Damien Sent: Saturday, November 15, 2014 6:55 PM To: He, Shuang Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0 Hi Shuang, You wanted suggestions, so how about: For both examples, to determine the size of the column, I'd take the length of the longest value of that column (including the title) and add 4 to account for spacing. Left alignment for text, right alignement for numbers (of course, all of that is debatable). [He, Shuang] Hello, Damien, Thanks for your great input, we'll check how those suggestion could be integrated, I've created one jira task to track it: https://jira01.devtools.intel.com/browse/VIZ-4672 On Fri, Nov 14, 2014 at 09:28:03PM -0800, shuang...@intel.com wrote: Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate BYT: pass/total=290/291-290/291 PNV: pass/total=352/356-356/356 ILK: pass/total=371/372-364/372 IVB: pass/total=545/546-545/546 SNB: pass/total=424/425-424/425 HSW: pass/total=579/579-579/579 BDW: pass/total=434/435-434/435 For this one: - a bit more spacing - some table-like alignment. That's assuming the mail client will use monospaced fonts for text emails, it really should. - add the delta so it's easier to parse the interesting information - sort by gens [He, Shuang] yes, this makes sense - baseline_drm_intel_nightly_pass_rate can really just be drm-intel-nightly [He, Shuang] yes, this makes sense - it's not just a single patch applied, so series applied? [He, Shuang] yes, it's series applied PlatformDeltadrm-intel-nightlySeries Applied PNV+4 352/356 356/356 ILK-7 371/372 364/372 SNB 0 424/425 424/425 IVB 0 545/546 545/546 BYT 0 290/291 290/291 HSW 0 579/579 579/579 BDW 0 434/435 434/435 -Detailed- test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...-result_with_patch_applied(count, machine_id)... PNV: Intel_gpu_tools, igt_gen3_mixed_blits, DMESG_WARN(1, M23) - PASS(4, M7) PNV: Intel_gpu_tools, igt_gen3_render_mixed_blits, CRASH(1, M23) - PASS(1, M7) PNV: Intel_gpu_tools, igt_gen3_render_tiledx_blits, CRASH(1, M23) - PASS(1, M7) PNV: Intel_gpu_tools, igt_gen3_render_tiledy_blits, CRASH(1, M23) - PASS(1, M7) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank, DMESG_WARN(1, M26)PASS(3, M37M26) - DMESG_WARN(2, M26)PASS(2, M26) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible, PASS(4, M37M26) - NSPT(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) - DMESG_WARN(2, M26)PASS(2, M26) ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-interruptible, PASS(4, M37M26) - DMESG_WARN(2, M26)PASS(2, M26) ILK: Intel_gpu_tools, igt_kms_flip_rcs-flip-vs-modeset-interruptible, PASS(4, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) And for this one: - it's not nessary to repeat the test suite name for every single row, if needed at all (I don't think it is when replying to kernel patches), it can be put beforehand. [He, Shuang] this makes sense - sorted by gen - The machine id isn't useful in this report [He, Shuang] Some time, test result diffs because of Machine have changed, machine id is put there to help understand the issue - It'd be nice to add a some explanations on how to decipher the result column (what is the count, what the various states mean). Maybe after the table as it only needs to be read a few times to get it. [He, Shuang] yes, it may help. I'm always be hesitating on how to put these things in the right position. I'll see if your way could help PlatformTest drm-intel-nightlySeries Applied --- ILK igt_kms_flip_flip-vs-absolute-wf_vblank DMESG_WARN(1) PASS(3)DMESG_WARN(2) PASS(2) ILK igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible DMESG_WARN(1) PASS(3)DMESG_WARN(1) PASS(3) .. HTH,
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ddi: set has_infoframe flag on DDI too
On Mon, Nov 17, 2014 at 01:08:46PM -0800, Jesse Barnes wrote:
Just like we do in the HDMI code, set the infoframe flag if we detect an
HDMI sink.
Reported-by: Paulo Zanoni przan...@gmail.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 86745da..78576e0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2062,6 +2062,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
switch (temp TRANS_DDI_MODE_SELECT_MASK) {
case TRANS_DDI_MODE_SELECT_HDMI:
pipe_config-has_hdmi_sink = true;
+ pipe_config-has_infoframe = true;
Infoframes aren't controlled by this bit here but set in
HSW_TVIDEO_DIP_CTL. Since the point of this is to detect mismatches
between the bios and what we'd like to have for fastboot I think we need
to check that register. Instead of blindly deriving state to appease the
cross checker.
-Daniel
case TRANS_DDI_MODE_SELECT_DVI:
case TRANS_DDI_MODE_SELECT_FDI:
break;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0
-Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Monday, November 17, 2014 11:03 PM To: Lespiau, Damien Cc: He, Shuang; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0 On Sat, Nov 15, 2014 at 10:54:47AM +, Damien Lespiau wrote: Hi Shuang, You wanted suggestions, so how about: For both examples, to determine the size of the column, I'd take the length of the longest value of that column (including the title) and add 4 to account for spacing. Left alignment for text, right alignement for numbers (of course, all of that is debatable). On Fri, Nov 14, 2014 at 09:28:03PM -0800, shuang...@intel.com wrote: Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate BYT: pass/total=290/291-290/291 PNV: pass/total=352/356-356/356 ILK: pass/total=371/372-364/372 IVB: pass/total=545/546-545/546 SNB: pass/total=424/425-424/425 HSW: pass/total=579/579-579/579 BDW: pass/total=434/435-434/435 For this one: - a bit more spacing - some table-like alignment. That's assuming the mail client will use monospaced fonts for text emails, it really should. - add the delta so it's easier to parse the interesting information I think the delta should mention both + and - counts separately so that it's easy to see when a patch regressed the same amount of tests as it fixed. Iirc there's been a few cases before where this was important. [He, Shuang] Agree with that, it's kind of like patch Thanks --Shuang Otherwise I agree with damien, the column aligment and headers make the results a lot easier to read. -Daniel - sort by gens - baseline_drm_intel_nightly_pass_rate can really just be drm-intel-nightly - it's not just a single patch applied, so series applied? PlatformDeltadrm-intel-nightlySeries Applied PNV+4 352/356 356/356 ILK-7 371/372 364/372 SNB 0 424/425 424/425 IVB 0 545/546 545/546 BYT 0 290/291 290/291 HSW 0 579/579 579/579 BDW 0 434/435 434/435 -Detailed- test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...-result_with_patch_applied(count, machine_id)... PNV: Intel_gpu_tools, igt_gen3_mixed_blits, DMESG_WARN(1, M23) - PASS(4, M7) PNV: Intel_gpu_tools, igt_gen3_render_mixed_blits, CRASH(1, M23) - PASS(1, M7) PNV: Intel_gpu_tools, igt_gen3_render_tiledx_blits, CRASH(1, M23) - PASS(1, M7) PNV: Intel_gpu_tools, igt_gen3_render_tiledy_blits, CRASH(1, M23) - PASS(1, M7) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank, DMESG_WARN(1, M26)PASS(3, M37M26) - DMESG_WARN(2, M26)PASS(2, M26) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible, PASS(4, M37M26) - NSPT(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(3, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) - DMESG_WARN(2, M26)PASS(2, M26) ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-interruptible, PASS(4, M37M26) - DMESG_WARN(2, M26)PASS(2, M26) ILK: Intel_gpu_tools, igt_kms_flip_rcs-flip-vs-modeset-interruptible, PASS(4, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) And for this one: - it's not nessary to repeat the test suite name for every single row, if needed at all (I don't think it is when replying to kernel patches), it can be put beforehand. - sorted by gen - The machine id isn't useful in this report - It'd be nice to add a some explanations on how to decipher the result column (what is the count, what the various states mean). Maybe after the table as it only needs to be read a few times to get it. PlatformTest drm-intel-nightlySeries Applied --- ILK igt_kms_flip_flip-vs-absolute-wf_vblank DMESG_WARN(1) PASS(3)DMESG_WARN(2) PASS(2) ILK igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible DMESG_WARN(1) PASS(3)DMESG_WARN(1) PASS(3) ..
Re: [Intel-gfx] [PATCH 2/2] drm/i915/ddi: add break in DDI mode select switch
On Mon, Nov 17, 2014 at 01:08:47PM -0800, Jesse Barnes wrote: The lack of a break here wasn't for falling through to some other important code, so made me do a double take. Add a break just to make things a little less confusing. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Confusing indeed. Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0
On Mon, Nov 17, 2014 at 07:28:28PM +0100, Daniel Vetter wrote: On Fri, Nov 14, 2014 at 05:24:35PM +, Damien Lespiau wrote: Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/intel_ddi.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index b5a279a..924f1ec 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -767,12 +767,20 @@ static void skl_ddi_clock_get(struct intel_encoder *encoder, pipe_config-port_clock = link_clock; + /* +* On SKL the eDP DPLL (DPLL0 as we don't use SSC) is not part of the +* shared DPLL framework and thus needs to be read out separately +*/ + if (encoder-type == INTEL_OUTPUT_EDP) Hw state readout shouldn't depend upon our sw state, and given the multiple personality nature of DDI ports I think this is the case here: We might have a different opinion than the bios guys about what's edp (it happened) or how consistently to apply this clock selection algo (also happened). So might be better to stuff this into the ddi clock readout code (the one where you patched away the WARN for DPLL0 I guess). And after a night of pondering I stand correct on our irc discussion about putting dpll0 into the shared dpll infrastructure - if the bios indeed does something we don't expect and we don't properly track the use count for dpll0 it'll blow up. So I guess we'll need indeed need that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: remove intel_pipe_set_base() (v3)
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate BYT: pass/total=290/291-291/291 PNV: pass/total=356/356-356/356 ILK: pass/total=371/372-371/372 IVB: pass/total=544/546-545/546 SNB: pass/total=424/425-424/425 HSW: pass/total=595/595-595/595 BDW: pass/total=432/435-433/435 -Detailed- test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...-result_with_patch_applied(count, machine_id)... BYT: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(1, M36)PASS(9, M31M36) - TIMEOUT(3, M31)PASS(1, M31) ILK: Intel_gpu_tools, igt_kms_flip_bcs-wf_vblank-vs-dpms, PASS(7, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(1, M37)PASS(9, M26M37) - FAIL(3, M26)PASS(1, M26) IVB: Intel_gpu_tools, igt_kms_3d, DMESG_WARN(3, M4)PASS(1, M21) - DMESG_WARN(1, M4)PASS(3, M4) IVB: Intel_gpu_tools, igt_kms_cursor_crc_cursor-256x256-random, DMESG_WARN(1, M21)PASS(9, M21M34M4) - PASS(4, M4) IVB: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(1, M21)PASS(9, M21M34M4) - TIMEOUT(3, M4)PASS(1, M4) SNB: Intel_gpu_tools, igt_kms_3d, DMESG_WARN(3, M22)PASS(1, M35) - DMESG_WARN(1, M22)PASS(3, M22) SNB: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(1, M35)PASS(9, M35M22) - TIMEOUT(3, M22)PASS(1, M22) BDW: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(1, M28)PASS(9, M30M28) - TIMEOUT(3, M30)PASS(1, M30) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm: add helper to get crtc timings (v2)
On Tue, 18 Nov 2014, Matt Roper matthew.d.ro...@intel.com wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
Cc: dri-de...@lists.freedesktop.org
Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/drm_crtc.c | 22 --
drivers/gpu/drm/i915/intel_display.c | 6 +++---
include/drm/drm_crtc.h | 2 ++
3 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 56737e7..64ec23b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2493,6 +2493,17 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
}
EXPORT_SYMBOL(drm_mode_set_config_internal);
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+ int *hdisplay, int *vdisplay)
+{
+ struct drm_display_mode adjusted = *mode;
I'd prefer using drm_mode_copy(). It doesn't matter here and now, but if
it starts to matter in the future the problems will be hard to track.
BR,
Jani.
+
+ drm_mode_stereo_double(adjusted);
+ *hdisplay = adjusted.crtc_hdisplay;
+ *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
/**
* drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
* CRTC viewport
@@ -2510,16 +2521,7 @@ int drm_crtc_check_viewport(const struct drm_crtc
*crtc,
{
int hdisplay, vdisplay;
- hdisplay = mode-hdisplay;
- vdisplay = mode-vdisplay;
-
- if (drm_mode_is_stereo(mode)) {
- struct drm_display_mode adjusted = *mode;
-
- drm_mode_set_crtcinfo(adjusted, CRTC_STEREO_DOUBLE);
- hdisplay = adjusted.crtc_hdisplay;
- vdisplay = adjusted.crtc_vdisplay;
- }
+ drm_crtc_get_hv_timing(mode, hdisplay, vdisplay);
if (crtc-invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 320bf4c..a967623 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
* computation to clearly distinguish it from the adjusted mode, which
* can be changed by the connectors in the below retry loop.
*/
- drm_mode_set_crtcinfo(pipe_config-requested_mode, CRTC_STEREO_DOUBLE);
- pipe_config-pipe_src_w = pipe_config-requested_mode.crtc_hdisplay;
- pipe_config-pipe_src_h = pipe_config-requested_mode.crtc_vdisplay;
+ drm_crtc_get_hv_timing(pipe_config-requested_mode,
+pipe_config-pipe_src_w,
+pipe_config-pipe_src_h);
encoder_retry:
/* Ensure the port clock defaults are reset when retrying. */
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7b28ab0..23236f6 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1138,6 +1138,8 @@ extern int drm_plane_init(struct drm_device *dev,
extern void drm_plane_cleanup(struct drm_plane *plane);
extern unsigned int drm_plane_index(struct drm_plane *plane);
extern void drm_plane_force_disable(struct drm_plane *plane);
+extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+int *hdisplay, int *vdisplay);
extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
int x, int y,
const struct drm_display_mode *mode,
--
1.8.5.1
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Monday, November 17, 2014 6:09 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
backing objects to GGTT on-demand
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 059330c..3c7299d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -655,6 +655,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ int unpin_count;
Pinning is already refcounted. Why this additional refcount?
The vma.pin_count is only allocated 4 bits of storage. If this restriction can
be lifted then I can use that.
And yes I've only realized this now that you've supplied the review
comments from Akash. I really rely upon the review discussions to spot such
low-level implementation details.
I know, and I explicitly asked the guys to post comments to the mailing list.
Cheers,
Thomas.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 11/28] drm/i915: Add IRQ friendly request deference facility
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of john.c.harri...@intel.com
Sent: Friday, November 14, 2014 12:19 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Subject: [Intel-gfx] [PATCH v2 11/28] drm/i915: Add IRQ friendly request
deference facility
From: John Harrison john.c.harri...@intel.com
The next patches in the series convert some display related seqno usage to
request structure usage. However, the request dereference introduced
must be done from interrupt context. As the dereference potentially
involves freeing the request structure and thus calling lots of non-interrupt
friendly code, this poses a problem.
The solution is to add an IRQ friendly version of the dereference function.
All
this does is to add the request structure to a 'delayed free' list and return.
The retire code, which is run periodically, then processes this list and does
the actual dereferencing of the request structures.
v2: Added a count to allow for multiple IRQ dereferences of the same
request at a time.
For: VIZ-4377
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |7 +++
drivers/gpu/drm/i915/i915_gem.c | 33
+++
drivers/gpu/drm/i915/intel_lrc.c|2 ++
drivers/gpu/drm/i915/intel_ringbuffer.c |3 +++
drivers/gpu/drm/i915/intel_ringbuffer.h |2 ++
5 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 180b674..87cb355 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2019,6 +2019,10 @@ struct drm_i915_gem_request {
struct drm_i915_file_private *file_priv;
/** file_priv list entry for this request */
struct list_head client_list;
+
+ /** deferred free list for dereferencing from IRQ context */
+ struct list_head delay_free_list;
+ uint32_t delay_free_count;
};
void i915_gem_request_free(struct kref *req_ref); @@ -2044,9 +2048,12
@@ i915_gem_request_reference(struct drm_i915_gem_request *req)
static inline void i915_gem_request_unreference(struct
drm_i915_gem_request *req) {
+ WARN_ON(!mutex_is_locked(req-ring-dev-struct_mutex));
kref_put(req-ref, i915_gem_request_free); }
+void i915_gem_request_unreference_irq(struct drm_i915_gem_request
+*req);
+
static inline void i915_gem_request_assign(struct drm_i915_gem_request
**pdst,
struct drm_i915_gem_request *src)
{ diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c index 60e5eec..8453bbd 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2722,6 +2722,19 @@ void i915_gem_reset(struct drm_device *dev)
i915_gem_restore_fences(dev);
}
+void i915_gem_request_unreference_irq(struct drm_i915_gem_request
*req)
+{
+ struct intel_engine_cs *ring = req-ring;
+ unsigned long flags;
+
+ /* Need to add the req to a deferred dereference list to be
processed
+ * outside of interrupt time */
+ spin_lock_irqsave(ring-reqlist_lock, flags);
+ if (req-delay_free_count++ == 0)
+ list_add_tail(req-delay_free_list, ring-
delayed_free_list);
+ spin_unlock_irqrestore(ring-reqlist_lock, flags); }
+
/**
* This function clears the request list as sequence numbers are passed.
*/
@@ -2796,6 +2809,25 @@ i915_gem_retire_requests_ring(struct
intel_engine_cs *ring)
ring-trace_irq_seqno = 0;
}
+ while (!list_empty(ring-delayed_free_list)) {
+ struct drm_i915_gem_request *request;
+ unsigned long flags;
+ uint32_t count;
+
+ request = list_first_entry(ring-delayed_free_list,
+struct drm_i915_gem_request,
+delay_free_list);
+
+ spin_lock_irqsave(request-ring-reqlist_lock, flags);
+ list_del(request-delay_free_list);
+ count = request-delay_free_count;
+ request-delay_free_count = 0;
+ spin_unlock_irqrestore(request-ring-reqlist_lock, flags);
+
+ while (count-- 0)
+ i915_gem_request_unreference(request);
+ }
+
WARN_ON(i915_verify_lists(ring-dev));
}
@@ -5055,6 +5087,7 @@ init_ring_lists(struct intel_engine_cs *ring) {
INIT_LIST_HEAD(ring-active_list);
INIT_LIST_HEAD(ring-request_list);
+ INIT_LIST_HEAD(ring-delayed_free_list);
Same comment as before - multiple init points for this list.
Thomas.
}
void i915_init_vm(struct drm_i915_private *dev_priv, diff --git
a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index eba0acd..db8efaa 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1287,7
Re: [Intel-gfx] [PATCH v2 25/28] drm/i915: Interrupt driven request completion
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of john.c.harri...@intel.com
Sent: Friday, November 14, 2014 12:19 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Subject: [Intel-gfx] [PATCH v2 25/28] drm/i915: Interrupt driven request
completion
From: John Harrison john.c.harri...@intel.com
Added a hook to the ring noftification code to process request completion.
This means that there is no longer a need to explicitly process request
completions every time a request object is tested. Instead, the test code
simply becomes 'return req-completed'. Obviously, this only works if ring
interrupts are enabled, however, this is already the case for the duration of
__wait_request() which is the point where the driver really needs to know.
To prevent stale requests floating around indefinitely, the retire work
handler also now performs a completion check periodically.
For: VIZ-4377
Signed-off-by: John Harrison john.c.harri...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |5 -
drivers/gpu/drm/i915/i915_gem.c | 10 ++
drivers/gpu/drm/i915/i915_irq.c |2 ++
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 8531e0f..66219b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2072,11 +2072,6 @@ static inline void i915_gem_request_assign(struct
drm_i915_gem_request **pdst, static inline bool
i915_gem_request_completed(struct drm_i915_gem_request *req,
bool lazy_coherency)
{
- if (req-complete)
- return true;
-
- i915_gem_complete_requests_ring(req-ring, lazy_coherency);
-
return req-complete;
}
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c index edf712b..039dbb8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1264,6 +1264,11 @@ int __i915_wait_request(struct
drm_i915_gem_request *req,
if (!irq_test_in_progress WARN_ON(!ring-irq_get(ring)))
return -ENODEV;
+ /* Completion status should be interrupt driven but it is possible
+ * the request popped out before the interrupt was enabled. So do
an
+ * explicit check now... */
+ i915_gem_complete_requests_ring(req-ring, false);
+
/* Record current time in case interrupted by signal, or wedged */
trace_i915_gem_request_wait_begin(req);
before = ktime_get_raw_ns();
@@ -2487,6 +2492,10 @@ int __i915_add_request(struct intel_engine_cs
*ring,
list_add_tail(request-list, ring-request_list);
request-file_priv = NULL;
+ /* Avoid race condition where the request completes before it has
+ * been added to the list. */
+ ring-last_read_seqno = 0;
+
if (file) {
struct drm_i915_file_private *file_priv = file-driver_priv;
@@ -2858,6 +2867,7 @@ i915_gem_retire_requests(struct drm_device
*dev)
int i;
for_each_ring(ring, dev_priv, i) {
+ i915_gem_complete_requests_ring(ring, false);
i915_gem_retire_requests_ring(ring);
idle = list_empty(ring-request_list);
}
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c index 198bbc6..4f63966 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -987,6 +987,8 @@ static void notify_ring(struct drm_device *dev,
trace_i915_gem_request_complete(ring);
+ i915_gem_complete_requests_ring(ring, false);
I915_gem_complete_requests_ring takes the request list lock and iterates over
the entire list. Are you sure this is safe to do during the interrupt handler?
Thomas.
+
wake_up_all(ring-irq_queue);
i915_queue_hangcheck(dev);
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] igt/gem_exec_big: Increase stress
We should be able to execute batches up to the full GTT size (give or
take fragmentation), so let's try!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
tests/gem_exec_big.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/tests/gem_exec_big.c b/tests/gem_exec_big.c
index b82774f..b5ec71c 100644
--- a/tests/gem_exec_big.c
+++ b/tests/gem_exec_big.c
@@ -46,10 +46,9 @@
#include drm.h
#include ioctl_wrappers.h
#include drmtest.h
+#include igt_aux.h
-#define BATCH_SIZE (1024*1024)
-
-static void exec(int fd, uint32_t handle, uint32_t reloc_ofs)
+static void exec(int fd, uint32_t handle, uint32_t reloc_ofs, unsigned flags)
{
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 gem_exec[1];
@@ -80,7 +79,7 @@ static void exec(int fd, uint32_t handle, uint32_t reloc_ofs)
execbuf.num_cliprects = 0;
execbuf.DR1 = 0;
execbuf.DR4 = 0;
- execbuf.flags = 0;
+ execbuf.flags = flags;
i915_execbuffer2_set_context_id(execbuf, 0);
execbuf.rsvd2 = 0;
@@ -100,27 +99,36 @@ static void exec(int fd, uint32_t handle, uint32_t
reloc_ofs)
igt_simple_main
{
uint32_t batch[2] = {MI_BATCH_BUFFER_END};
- uint32_t handle;
int fd;
uint32_t reloc_ofs;
unsigned batch_size;
+ int max;
igt_skip_on_simulation();
fd = drm_open_any();
+ max = 3 * gem_aperture_size(fd) / 4;
+
+ igt_require(intel_check_memory(1, max, CHECK_RAM));
- for (batch_size = BATCH_SIZE/4; batch_size = BATCH_SIZE; batch_size +=
4096) {
- handle = gem_create(fd, batch_size);
+ for (batch_size = 4096; batch_size = max; ) {
+ uint32_t handle = gem_create(fd, batch_size);
gem_write(fd, handle, 0, batch, sizeof(batch));
for (reloc_ofs = 4096; reloc_ofs batch_size; reloc_ofs +=
4096) {
igt_debug(batch_size %u, reloc_ofs %u\n,
batch_size, reloc_ofs);
- exec(fd, handle, reloc_ofs);
+ exec(fd, handle, reloc_ofs, 0);
+ exec(fd, handle, reloc_ofs, I915_EXEC_SECURE);
}
- }
- gem_close(fd, handle);
+ gem_madvise(fd, handle, I915_MADV_DONTNEED);
+
+ if (batch_size max 2*batch_size max)
+ batch_size = max;
+ else
+ batch_size *= 2;
+ }
close(fd);
}
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/audio: fix monitor presence indication after disable
Indicate the monitor has been disconnected on disable. The regression has been introduced in commit 5fad84a7530f8e7664cdc6f490cb90653fed1266 Author: Jani Nikula jani.nik...@intel.com Date: Tue Nov 4 10:30:23 2014 +0200 drm/i915: rewrite hsw/bdw audio codec enable/disable sequences Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86424 Cc: Rodrigo Vivi rodrigo.v...@gmail.com Signed-off-by: Jani Nikula jani.nik...@intel.com --- drivers/gpu/drm/i915/intel_audio.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_audio.c b/drivers/gpu/drm/i915/intel_audio.c index 87750ef018e6..2c7ed5cb29c0 100644 --- a/drivers/gpu/drm/i915/intel_audio.c +++ b/drivers/gpu/drm/i915/intel_audio.c @@ -194,6 +194,7 @@ static void hsw_audio_codec_disable(struct intel_encoder *encoder) /* Invalidate ELD */ tmp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD); tmp = ~AUDIO_ELD_VALID(pipe); + tmp = ~AUDIO_OUTPUT_ENABLE(pipe); I915_WRITE(HSW_AUD_PIN_ELD_CP_VLD, tmp); } -- 2.1.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: fix monitor presence indication after disable
On Tue, Nov 18, 2014 at 12:11:29PM +0200, Jani Nikula wrote: Indicate the monitor has been disconnected on disable. The regression has been introduced in commit 5fad84a7530f8e7664cdc6f490cb90653fed1266 Author: Jani Nikula jani.nik...@intel.com Date: Tue Nov 4 10:30:23 2014 +0200 drm/i915: rewrite hsw/bdw audio codec enable/disable sequences Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86424 Cc: Rodrigo Vivi rodrigo.v...@gmail.com Signed-off-by: Jani Nikula jani.nik...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] igt/gem_exec_big: Increase stress
On Tue, Nov 18, 2014 at 09:50:23AM +, Chris Wilson wrote:
We should be able to execute batches up to the full GTT size (give or
take fragmentation), so let's try!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
tests/gem_exec_big.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/tests/gem_exec_big.c b/tests/gem_exec_big.c
index b82774f..b5ec71c 100644
--- a/tests/gem_exec_big.c
+++ b/tests/gem_exec_big.c
@@ -46,10 +46,9 @@
#include drm.h
#include ioctl_wrappers.h
#include drmtest.h
+#include igt_aux.h
-#define BATCH_SIZE (1024*1024)
-
-static void exec(int fd, uint32_t handle, uint32_t reloc_ofs)
+static void exec(int fd, uint32_t handle, uint32_t reloc_ofs, unsigned flags)
{
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 gem_exec[1];
@@ -80,7 +79,7 @@ static void exec(int fd, uint32_t handle, uint32_t
reloc_ofs)
execbuf.num_cliprects = 0;
execbuf.DR1 = 0;
execbuf.DR4 = 0;
- execbuf.flags = 0;
+ execbuf.flags = flags;
i915_execbuffer2_set_context_id(execbuf, 0);
execbuf.rsvd2 = 0;
@@ -100,27 +99,36 @@ static void exec(int fd, uint32_t handle, uint32_t
reloc_ofs)
igt_simple_main
{
uint32_t batch[2] = {MI_BATCH_BUFFER_END};
- uint32_t handle;
int fd;
uint32_t reloc_ofs;
unsigned batch_size;
+ int max;
igt_skip_on_simulation();
fd = drm_open_any();
+ max = 3 * gem_aperture_size(fd) / 4;
+
+ igt_require(intel_check_memory(1, max, CHECK_RAM));
This might result in the testcase skipping and us loosing the coverage -
our QA tends to have puny machines. Better to have two subtests?
-Daniel
- for (batch_size = BATCH_SIZE/4; batch_size = BATCH_SIZE; batch_size +=
4096) {
- handle = gem_create(fd, batch_size);
+ for (batch_size = 4096; batch_size = max; ) {
+ uint32_t handle = gem_create(fd, batch_size);
gem_write(fd, handle, 0, batch, sizeof(batch));
for (reloc_ofs = 4096; reloc_ofs batch_size; reloc_ofs +=
4096) {
igt_debug(batch_size %u, reloc_ofs %u\n,
batch_size, reloc_ofs);
- exec(fd, handle, reloc_ofs);
+ exec(fd, handle, reloc_ofs, 0);
+ exec(fd, handle, reloc_ofs, I915_EXEC_SECURE);
}
- }
- gem_close(fd, handle);
+ gem_madvise(fd, handle, I915_MADV_DONTNEED);
+
+ if (batch_size max 2*batch_size max)
+ batch_size = max;
+ else
+ batch_size *= 2;
+ }
close(fd);
}
--
2.1.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] igt/gem_exec_big: Increase stress
On Tue, Nov 18, 2014 at 11:33:23AM +0100, Daniel Vetter wrote:
On Tue, Nov 18, 2014 at 09:50:23AM +, Chris Wilson wrote:
We should be able to execute batches up to the full GTT size (give or
take fragmentation), so let's try!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
tests/gem_exec_big.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/tests/gem_exec_big.c b/tests/gem_exec_big.c
index b82774f..b5ec71c 100644
--- a/tests/gem_exec_big.c
+++ b/tests/gem_exec_big.c
@@ -46,10 +46,9 @@
#include drm.h
#include ioctl_wrappers.h
#include drmtest.h
+#include igt_aux.h
-#define BATCH_SIZE (1024*1024)
-
-static void exec(int fd, uint32_t handle, uint32_t reloc_ofs)
+static void exec(int fd, uint32_t handle, uint32_t reloc_ofs, unsigned
flags)
{
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 gem_exec[1];
@@ -80,7 +79,7 @@ static void exec(int fd, uint32_t handle, uint32_t
reloc_ofs)
execbuf.num_cliprects = 0;
execbuf.DR1 = 0;
execbuf.DR4 = 0;
- execbuf.flags = 0;
+ execbuf.flags = flags;
i915_execbuffer2_set_context_id(execbuf, 0);
execbuf.rsvd2 = 0;
@@ -100,27 +99,36 @@ static void exec(int fd, uint32_t handle, uint32_t
reloc_ofs)
igt_simple_main
{
uint32_t batch[2] = {MI_BATCH_BUFFER_END};
- uint32_t handle;
int fd;
uint32_t reloc_ofs;
unsigned batch_size;
+ int max;
igt_skip_on_simulation();
fd = drm_open_any();
+ max = 3 * gem_aperture_size(fd) / 4;
+
+ igt_require(intel_check_memory(1, max, CHECK_RAM));
This might result in the testcase skipping and us loosing the coverage -
our QA tends to have puny machines. Better to have two subtests?
What I wanted to do was do the check inside the loop, but that would
have resulted in premature eviction of the leaked objects that I was
using to make the kernel work harder.
I really wanted to be lazy and not have to convert this over to a bunch
of subtests ;-)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Daniel, Thomas
Sent: Tuesday, November 18, 2014 9:28 AM
To: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
backing objects to GGTT on-demand
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, November 17, 2014 6:09 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
backing objects to GGTT on-demand
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 059330c..3c7299d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -655,6 +655,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ int unpin_count;
Pinning is already refcounted. Why this additional refcount?
The vma.pin_count is only allocated 4 bits of storage. If this restriction
can be
lifted then I can use that.
Actually I just tried to implement this, it causes a problem for patch 4 of
this set as the unpin_count is also used for the ringbuffer object which has an
ioremap as well as a ggtt pin.
Thomas.
And yes I've only realized this now that you've supplied the review
comments from Akash. I really rely upon the review discussions to spot
such low-level implementation details.
I know, and I explicitly asked the guys to post comments to the mailing list.
Cheers,
Thomas.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't print header in error state for non-existing CS
This goes back to
commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b
Author: Ben Widawsky benjamin.widaw...@intel.com
Date: Thu Jan 30 00:19:38 2014 -0800
drm/i915: Move per ring error state to ring_error
Spotted while reading error states.
Cc: Ben Widawsky benjamin.widaw...@intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/i915/i915_gpu_error.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 89a2f3dbf956..82111b8ad374 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -242,11 +242,15 @@ static const char *hangcheck_action_to_str(enum
intel_ring_hangcheck_action a)
static void i915_ring_error_state(struct drm_i915_error_state_buf *m,
struct drm_device *dev,
- struct drm_i915_error_ring *ring)
+ struct drm_i915_error_state *error,
+ int ring_idx)
{
+ struct drm_i915_error_ring *ring = error-ring[ring_idx];
+
if (!ring-valid)
return;
+ err_printf(m, %s command stream:\n, ring_str(ring_idx));
err_printf(m, HEAD: 0x%08x\n, ring-head);
err_printf(m, TAIL: 0x%08x\n, ring-tail);
err_printf(m, CTL: 0x%08x\n, ring-ctl);
@@ -388,10 +392,8 @@ int i915_error_state_to_str(struct
drm_i915_error_state_buf *m,
if (INTEL_INFO(dev)-gen == 7)
err_printf(m, ERR_INT: 0x%08x\n, error-err_int);
- for (i = 0; i ARRAY_SIZE(error-ring); i++) {
- err_printf(m, %s command stream:\n, ring_str(i));
- i915_ring_error_state(m, dev, error-ring[i]);
- }
+ for (i = 0; i ARRAY_SIZE(error-ring); i++)
+ i915_ring_error_state(m, dev, error, i);
for (i = 0; i error-vm_count; i++) {
err_printf(m, vm[%d]\n, i);
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/prime_self_import: Track leaked objects accurately
drm_open_any keeps a buffer handle around for the cleanup sync work,
so we can only grab the buffer count after the latst drm_open_any
call. Otherwise we'll detect a fake leak.
This broke in
commit 2f2c491cf3167befe7c79e4b17afb4f6284dfc84
Author: Mika Kuoppala mika.kuopp...@intel.com
Date: Fri Mar 28 10:52:46 2014 +0200
lib/drmtest: don't dup quiescent fd
since that additional open drm fd keeps a gem object for the default
context around. Hence why this also only blows up on gen6+ - earlier
platforms don't have hw context support.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79821
Cc: Mika Kuoppala mika.kuopp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
tests/prime_self_import.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/prime_self_import.c b/tests/prime_self_import.c
index 3e482b79b2ff..dd9c2933110e 100644
--- a/tests/prime_self_import.c
+++ b/tests/prime_self_import.c
@@ -341,8 +341,6 @@ static void test_export_close_race(void)
int obj_count;
void *status;
- obj_count = get_object_count();
-
num_threads = sysconf(_SC_NPROCESSORS_ONLN);
threads = calloc(num_threads, sizeof(pthread_t));
@@ -350,6 +348,8 @@ static void test_export_close_race(void)
fd = drm_open_any();
igt_assert(fd = 0);
+ obj_count = get_object_count();
+
for (i = 0; i num_threads; i++) {
r = pthread_create(threads[i], NULL,
thread_fn_export_vs_close,
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Pin tiled objects for L-shaped configs
Let's just throw in the towel on this one and take the cheap way out.
Based on a patch from Chris Wilson, but checking for a different bit.
Chris' patch checked for even bank layout, this one here for a magic
bit. Given the evidence we've gathered (not much) both work I think,
but checking for the magic bit might be more accurate.
Anyway, works on my gm45 here.
For paranoi restrict to gen4 (and mobile), since we've only ever seen
this on gm45 and i965gm.
Also add some debugfs output so that we can skip the tiled swapping
tests properly in these cases.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28813
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45092
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c| 6 ++
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/i915_gem.c| 14 ++
drivers/gpu/drm/i915/i915_gem_tiling.c | 18 ++
drivers/gpu/drm/i915/i915_reg.h| 2 ++
5 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0a6981399642..a43124e4a77b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1975,6 +1975,8 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
if (IS_GEN3(dev) || IS_GEN4(dev)) {
seq_printf(m, DDC = 0x%08x\n,
I915_READ(DCC));
+ seq_printf(m, DDC2 = 0x%08x\n,
+ I915_READ(DCC2));
seq_printf(m, C0DRB3 = 0x%04x\n,
I915_READ16(C0DRB3));
seq_printf(m, C1DRB3 = 0x%04x\n,
@@ -1997,6 +1999,10 @@ static int i915_swizzle_info(struct seq_file *m, void
*data)
seq_printf(m, DISP_ARB_CTL = 0x%08x\n,
I915_READ(DISP_ARB_CTL));
}
+
+ if (dev_priv-quirks QUIRK_PIN_SWIZZLED_PAGES)
+ seq_puts(m, L-shaped memory detected\n);
+
intel_runtime_pm_put(dev_priv);
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 54691bcf1822..d5accc481082 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -747,6 +747,7 @@ enum intel_sbi_destination {
#define QUIRK_INVERT_BRIGHTNESS (12)
#define QUIRK_BACKLIGHT_PRESENT (13)
#define QUIRK_PIPEB_FORCE (14)
+#define QUIRK_PIN_SWIZZLED_PAGES (15)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1de94cc63517..196ebd07d118 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2120,6 +2120,10 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj);
+ if (obj-tiling_mode != I915_TILING_NONE
+ dev_priv-quirks QUIRK_PIN_SWIZZLED_PAGES)
+ i915_gem_object_pin_pages(obj);
+
return 0;
err_pages:
@@ -4300,6 +4304,7 @@ int
i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
+ struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_madvise *args = data;
struct drm_i915_gem_object *obj;
int ret;
@@ -4327,6 +4332,15 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
*data,
goto out;
}
+ if (obj-pages
+ obj-tiling_mode != I915_TILING_NONE
+ dev_priv-quirks QUIRK_PIN_SWIZZLED_PAGES) {
+ if (obj-madv == I915_MADV_WILLNEED)
+ i915_gem_object_unpin_pages(obj);
+ if (args-madv == I915_MADV_WILLNEED)
+ i915_gem_object_pin_pages(obj);
+ }
+
if (obj-madv != __I915_MADV_PURGED)
obj-madv = args-madv;
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 749ab485569e..03c675a4476e 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -178,6 +178,15 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
}
break;
}
+
+ /* check for L-shaped memory aka modified enhanced addressing */
+ if (IS_GEN4(dev)) {
+ uint32_t ddc2 = I915_READ(DCC2);
+
+ if (!(ddc2 DCC2_MODIFIED_ENHANCED_DISABLE))
+ dev_priv-quirks |= QUIRK_PIN_SWIZZLED_PAGES;
+ }
+
if (dcc == 0x) {
DRM_ERROR(Couldn't read from MCHBAR.
Disabling tiling.\n);
@@ -393,6 +402,15 @@ i915_gem_set_tiling(struct drm_device *dev, void *data,
}
[Intel-gfx] [PATCH] tests/gem_tiled_swapping: Skip on L-shaped memory
The only thing the kernel can do is pin the buffers, which essentially
means no swapped tiled objects.
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
tests/gem_tiled_swapping.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/tests/gem_tiled_swapping.c b/tests/gem_tiled_swapping.c
index 69d1cfae94d2..0839df00151e 100644
--- a/tests/gem_tiled_swapping.c
+++ b/tests/gem_tiled_swapping.c
@@ -61,6 +61,7 @@
#include drmtest.h
#include intel_io.h
#include igt_aux.h
+#include igt_debugfs.h
#define WIDTH 512
#define HEIGHT 512
@@ -143,6 +144,25 @@ static void thread_fini(struct thread *t)
free(t-idx_arr);
}
+static void check_memory_layout(void)
+{
+ FILE *tiling_debugfs_file;
+ char *line = NULL;
+ size_t sz = 0;
+
+ tiling_debugfs_file = igt_debugfs_fopen(i915_swizzle_info, r);
+ igt_assert(tiling_debugfs_file);
+
+ while (getline(line, sz, tiling_debugfs_file) 0) {
+ if (strstr(line, L-shaped) != 0)
+ continue;
+
+ igt_skip(L-shaped memory configuration detected\n);
+ }
+
+ igt_debug(normal memory configuration detected, continuing\n);
+}
+
igt_simple_main
{
struct thread *threads;
@@ -162,6 +182,8 @@ igt_simple_main
threads = calloc(num_threads, sizeof(struct thread));
igt_assert(threads);
+ check_memory_layout();
+
igt_log(IGT_LOG_INFO,
Using %d 1MiB objects (available RAM: %ld/%ld, swap: %ld)\n,
count,
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Pin tiled objects for L-shaped configs
On Tue, Nov 18, 2014 at 02:41:22PM +0100, Daniel Vetter wrote: struct intel_fbdev; struct intel_fbc_work; diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 1de94cc63517..196ebd07d118 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2120,6 +2120,10 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj) if (i915_gem_object_needs_bit17_swizzle(obj)) i915_gem_object_do_bit_17_swizzle(obj); + if (obj-tiling_mode != I915_TILING_NONE + dev_priv-quirks QUIRK_PIN_SWIZZLED_PAGES) + i915_gem_object_pin_pages(obj); Note that we have a WARN_ON(obj-pages_pin_count) in i915_gem_free_object() now. if (dev_priv-quirks QUIRK_PIN_SWIZZLED_PAGES) obj-pages_pin_count = 0; or we could just throw away the WARN_ON(). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't print header in error state for non-existing CS
On Tue, Nov 18, 2014 at 01:28:38PM +0100, Daniel Vetter wrote: This goes back to commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b Author: Ben Widawsky benjamin.widaw...@intel.com Date: Thu Jan 30 00:19:38 2014 -0800 drm/i915: Move per ring error state to ring_error Spotted while reading error states. Cc: Ben Widawsky benjamin.widaw...@intel.com Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/i915/i915_gpu_error.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 89a2f3dbf956..82111b8ad374 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -242,11 +242,15 @@ static const char *hangcheck_action_to_str(enum intel_ring_hangcheck_action a) static void i915_ring_error_state(struct drm_i915_error_state_buf *m, struct drm_device *dev, - struct drm_i915_error_ring *ring) + struct drm_i915_error_state *error, + int ring_idx) Hmm, doesn't the drm_i915_error_ring already have ring-id set? It does in my kernel (and so saves having to pass in error + ring_idx). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_tiled_swapping: Skip on L-shaped memory
On Tue, Nov 18, 2014 at 02:40:28PM +0100, Daniel Vetter wrote:
The only thing the kernel can do is pin the buffers, which essentially
means no swapped tiled objects.
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
tests/gem_tiled_swapping.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/tests/gem_tiled_swapping.c b/tests/gem_tiled_swapping.c
index 69d1cfae94d2..0839df00151e 100644
--- a/tests/gem_tiled_swapping.c
+++ b/tests/gem_tiled_swapping.c
@@ -61,6 +61,7 @@
#include drmtest.h
#include intel_io.h
#include igt_aux.h
+#include igt_debugfs.h
#define WIDTH 512
#define HEIGHT 512
@@ -143,6 +144,25 @@ static void thread_fini(struct thread *t)
free(t-idx_arr);
}
+static void check_memory_layout(void)
+{
+ FILE *tiling_debugfs_file;
+ char *line = NULL;
+ size_t sz = 0;
+
+ tiling_debugfs_file = igt_debugfs_fopen(i915_swizzle_info, r);
+ igt_assert(tiling_debugfs_file);
+
+ while (getline(line, sz, tiling_debugfs_file) 0) {
+ if (strstr(line, L-shaped) != 0)
+ continue;
+
+ igt_skip(L-shaped memory configuration detected\n);
+ }
+
+ igt_debug(normal memory configuration detected, continuing\n);
+}
igt_check_memory():
if (flags CHECK_SWAP !check_memory_layout())
skip()
That should then cover us for all tests that want to use swap. (And if
not, we are missing some more igt_check_memory/igt_require_memory.)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand
On Tue, Nov 18, 2014 at 10:48:09AM +, Daniel, Thomas wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Daniel, Thomas
Sent: Tuesday, November 18, 2014 9:28 AM
To: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
backing objects to GGTT on-demand
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, November 17, 2014 6:09 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
backing objects to GGTT on-demand
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 059330c..3c7299d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -655,6 +655,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ int unpin_count;
Pinning is already refcounted. Why this additional refcount?
The vma.pin_count is only allocated 4 bits of storage. If this restriction
can be
lifted then I can use that.
Those 4 bits are good enough for legacy contexts, so I wonder a bit what's
so massively different for execlist contexts.
Actually I just tried to implement this, it causes a problem for patch 4
of this set as the unpin_count is also used for the ringbuffer object
which has an ioremap as well as a ggtt pin.
Yeah, ioremap needs to be redone every time we pin/unpin. But on sane
archs it's almost no overhead really. And if this does start to matter
(shudder for 32bit kernels on gen8) then we can fix it ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't print header in error state for non-existing CS
On Tue, Nov 18, 2014 at 02:04:23PM +, Chris Wilson wrote: On Tue, Nov 18, 2014 at 01:28:38PM +0100, Daniel Vetter wrote: This goes back to commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b Author: Ben Widawsky benjamin.widaw...@intel.com Date: Thu Jan 30 00:19:38 2014 -0800 drm/i915: Move per ring error state to ring_error Spotted while reading error states. Cc: Ben Widawsky benjamin.widaw...@intel.com Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/i915/i915_gpu_error.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 89a2f3dbf956..82111b8ad374 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -242,11 +242,15 @@ static const char *hangcheck_action_to_str(enum intel_ring_hangcheck_action a) static void i915_ring_error_state(struct drm_i915_error_state_buf *m, struct drm_device *dev, - struct drm_i915_error_ring *ring) + struct drm_i915_error_state *error, + int ring_idx) Hmm, doesn't the drm_i915_error_ring already have ring-id set? It does in my kernel (and so saves having to pass in error + ring_idx). Unfortunately not ... and I'm too lazily to rework things even more. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_tiled_swapping: Skip on L-shaped memory
On Tue, Nov 18, 2014 at 02:06:37PM +, Chris Wilson wrote:
On Tue, Nov 18, 2014 at 02:40:28PM +0100, Daniel Vetter wrote:
The only thing the kernel can do is pin the buffers, which essentially
means no swapped tiled objects.
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
tests/gem_tiled_swapping.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/tests/gem_tiled_swapping.c b/tests/gem_tiled_swapping.c
index 69d1cfae94d2..0839df00151e 100644
--- a/tests/gem_tiled_swapping.c
+++ b/tests/gem_tiled_swapping.c
@@ -61,6 +61,7 @@
#include drmtest.h
#include intel_io.h
#include igt_aux.h
+#include igt_debugfs.h
#define WIDTH 512
#define HEIGHT 512
@@ -143,6 +144,25 @@ static void thread_fini(struct thread *t)
free(t-idx_arr);
}
+static void check_memory_layout(void)
+{
+ FILE *tiling_debugfs_file;
+ char *line = NULL;
+ size_t sz = 0;
+
+ tiling_debugfs_file = igt_debugfs_fopen(i915_swizzle_info, r);
+ igt_assert(tiling_debugfs_file);
+
+ while (getline(line, sz, tiling_debugfs_file) 0) {
+ if (strstr(line, L-shaped) != 0)
+ continue;
+
+ igt_skip(L-shaped memory configuration detected\n);
+ }
+
+ igt_debug(normal memory configuration detected, continuing\n);
+}
igt_check_memory():
if (flags CHECK_SWAP !check_memory_layout())
skip()
That should then cover us for all tests that want to use swap. (And if
not, we are missing some more igt_check_memory/igt_require_memory.)
Lots of our memory thrashin tests use linear objects, and I don't really
want to disable all these tests. I know somewhat futile since the only big
things are tiled objects, still.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Pin tiled objects for L-shaped configs
On Tue, Nov 18, 2014 at 02:01:37PM +, Chris Wilson wrote: On Tue, Nov 18, 2014 at 02:41:22PM +0100, Daniel Vetter wrote: struct intel_fbdev; struct intel_fbc_work; diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 1de94cc63517..196ebd07d118 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2120,6 +2120,10 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj) if (i915_gem_object_needs_bit17_swizzle(obj)) i915_gem_object_do_bit_17_swizzle(obj); + if (obj-tiling_mode != I915_TILING_NONE + dev_priv-quirks QUIRK_PIN_SWIZZLED_PAGES) + i915_gem_object_pin_pages(obj); Note that we have a WARN_ON(obj-pages_pin_count) in i915_gem_free_object() now. if (dev_priv-quirks QUIRK_PIN_SWIZZLED_PAGES) obj-pages_pin_count = 0; or we could just throw away the WARN_ON(). Shame on me for not noticing that. I think I'll just drop the pinning for tiled objects manually, that way we can keep the WARN_ON. Given all the tricks being pulled with pin refcounts I think that check is useful. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/kms_render: gen2/3 can't do 10bpc
So skip those.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86236
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/kms_render.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/kms_render.c b/tests/kms_render.c
index d96ceea45149..a3487dd88fe9 100644
--- a/tests/kms_render.c
+++ b/tests/kms_render.c
@@ -179,10 +179,17 @@ static void test_connector(const char *test_name,
int i;
igt_get_all_formats(formats, format_count);
- for (i = 0; i format_count; i++)
+ for (i = 0; i format_count; i++) {
+ if (intel_gen(intel_get_drm_devid(drm_fd)) 4
+formats[i] == DRM_FORMAT_XRGB2101010) {
+ igt_info(gen2/3 don't support 10bpc, skipping\n);
+ continue;
+ }
+
test_format(test_name,
cconf, cconf-connector-modes[0],
formats[i], flags);
+ }
}
static int run_test(const char *test_name, enum test_flags flags)
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_tiled_swapping: Skip on L-shaped memory
On Tue, Nov 18, 2014 at 03:35:33PM +0100, Daniel Vetter wrote:
On Tue, Nov 18, 2014 at 02:06:37PM +, Chris Wilson wrote:
On Tue, Nov 18, 2014 at 02:40:28PM +0100, Daniel Vetter wrote:
The only thing the kernel can do is pin the buffers, which essentially
means no swapped tiled objects.
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
tests/gem_tiled_swapping.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/tests/gem_tiled_swapping.c b/tests/gem_tiled_swapping.c
index 69d1cfae94d2..0839df00151e 100644
--- a/tests/gem_tiled_swapping.c
+++ b/tests/gem_tiled_swapping.c
@@ -61,6 +61,7 @@
#include drmtest.h
#include intel_io.h
#include igt_aux.h
+#include igt_debugfs.h
#define WIDTH 512
#define HEIGHT 512
@@ -143,6 +144,25 @@ static void thread_fini(struct thread *t)
free(t-idx_arr);
}
+static void check_memory_layout(void)
+{
+ FILE *tiling_debugfs_file;
+ char *line = NULL;
+ size_t sz = 0;
+
+ tiling_debugfs_file = igt_debugfs_fopen(i915_swizzle_info, r);
+ igt_assert(tiling_debugfs_file);
+
+ while (getline(line, sz, tiling_debugfs_file) 0) {
+ if (strstr(line, L-shaped) != 0)
+ continue;
+
+ igt_skip(L-shaped memory configuration detected\n);
+ }
+
+ igt_debug(normal memory configuration detected, continuing\n);
+}
igt_check_memory():
if (flags CHECK_SWAP !check_memory_layout())
skip()
That should then cover us for all tests that want to use swap. (And if
not, we are missing some more igt_check_memory/igt_require_memory.)
Lots of our memory thrashin tests use linear objects, and I don't really
want to disable all these tests. I know somewhat futile since the only big
things are tiled objects, still.
I still like the idea of moving this check into the central location.
Perhaps intel_check_memory(CHECK_TILED) with semantics tbd?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't print header in error state for non-existing CS
On Tue, Nov 18, 2014 at 03:34:15PM +0100, Daniel Vetter wrote: On Tue, Nov 18, 2014 at 02:04:23PM +, Chris Wilson wrote: On Tue, Nov 18, 2014 at 01:28:38PM +0100, Daniel Vetter wrote: This goes back to commit 362b8af7ad1d91266aa4931e62be45c1e5cf753b Author: Ben Widawsky benjamin.widaw...@intel.com Date: Thu Jan 30 00:19:38 2014 -0800 drm/i915: Move per ring error state to ring_error Spotted while reading error states. Cc: Ben Widawsky benjamin.widaw...@intel.com Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@intel.com --- drivers/gpu/drm/i915/i915_gpu_error.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index 89a2f3dbf956..82111b8ad374 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -242,11 +242,15 @@ static const char *hangcheck_action_to_str(enum intel_ring_hangcheck_action a) static void i915_ring_error_state(struct drm_i915_error_state_buf *m, struct drm_device *dev, - struct drm_i915_error_ring *ring) + struct drm_i915_error_state *error, + int ring_idx) Hmm, doesn't the drm_i915_error_ring already have ring-id set? It does in my kernel (and so saves having to pass in error + ring_idx). Unfortunately not ... and I'm too lazily to rework things even more. Oh well, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Tuesday, November 18, 2014 2:33 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
backing objects to GGTT on-demand
On Tue, Nov 18, 2014 at 10:48:09AM +, Daniel, Thomas wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
Behalf Of Daniel, Thomas
Sent: Tuesday, November 18, 2014 9:28 AM
To: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the
context backing objects to GGTT on-demand
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, November 17, 2014 6:09 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the
context backing objects to GGTT on-demand
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 059330c..3c7299d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -655,6 +655,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ int unpin_count;
Pinning is already refcounted. Why this additional refcount?
The vma.pin_count is only allocated 4 bits of storage. If this
restriction can be lifted then I can use that.
Those 4 bits are good enough for legacy contexts, so I wonder a bit what's so
massively different for execlist contexts.
With execlists, in order to dynamically unpin the LRC backing object and ring
buffer object when not required we take a reference for each execlist request
that uses them (remember that the execlist request lifecycle is currently
different from the execbuffer request). This can be a lot, especially in some
of the less sane i-g-t tests.
Actually I just tried to implement this, it causes a problem for patch
4 of this set as the unpin_count is also used for the ringbuffer
object which has an ioremap as well as a ggtt pin.
Yeah, ioremap needs to be redone every time we pin/unpin. But on sane
archs it's almost no overhead really. And if this does start to matter
(shudder
for 32bit kernels on gen8) then we can fix it ...
Hm, so the CPU vaddr of the ring buffer will move around as more requests
reference it which I suppose is not a problem. We will use a lot of address
space (again, especially with the i-g-t stress tests which can submit tens of
thousands of requests in a very short space of time). What would the fix be?
An extra reference count for the ioremap? Looks familiar :)
I still think it's best to keep the context unpin_count for execlists mode.
Thomas.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/Android.mk: Add kms_pwrite_crc to cairo test list
From: Tim Gore tim.g...@intel.com kms_pwrite_crc was recently added and requires cairo, so add this to the list of tests to exclude if cairo is not avaiable Signed-off-by: Tim Gore tim.g...@intel.com --- tests/Android.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/Android.mk b/tests/Android.mk index f28b400..519852a 100644 --- a/tests/Android.mk +++ b/tests/Android.mk @@ -74,7 +74,8 @@ else kms_universal_plane \ kms_rotation_crc \ kms_force_connector \ -kms_flip_event_leak +kms_flip_event_leak \ +kms_pwrite_crc IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0 endif -- 2.1.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/Android.mk: add gem_fence_upload excluded tests
From: Tim Gore tim.g...@intel.com gem_fence_upload implements some performance measurements, but fails on both android and linux systems and does not generally seem to be a usefull test, so exclude it. Signed-off-by: Tim Gore tim.g...@intel.com --- tests/Android.mk | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/Android.mk b/tests/Android.mk index 519852a..230d709 100644 --- a/tests/Android.mk +++ b/tests/Android.mk @@ -31,6 +31,9 @@ skip_tests_list := skip_tests_list += testdisplay# needs glib.h skip_tests_list += pm_rpm +# some tests are rusty +skip_tests_list += gem_fence_upload + # set local compilation flags for IGT tests IGT_LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM -DANDROID -UNDEBUG IGT_LOCAL_CFLAGS += -include check-ndebug.h -std=c99 -- 2.1.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand
On Tue, Nov 18, 2014 at 02:51:52PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Tuesday, November 18, 2014 2:33 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
backing objects to GGTT on-demand
On Tue, Nov 18, 2014 at 10:48:09AM +, Daniel, Thomas wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
Behalf Of Daniel, Thomas
Sent: Tuesday, November 18, 2014 9:28 AM
To: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the
context backing objects to GGTT on-demand
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, November 17, 2014 6:09 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the
context backing objects to GGTT on-demand
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 059330c..3c7299d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -655,6 +655,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ int unpin_count;
Pinning is already refcounted. Why this additional refcount?
The vma.pin_count is only allocated 4 bits of storage. If this
restriction can be lifted then I can use that.
Those 4 bits are good enough for legacy contexts, so I wonder a bit what's
so
massively different for execlist contexts.
With execlists, in order to dynamically unpin the LRC backing object and
ring buffer object when not required we take a reference for each
execlist request that uses them (remember that the execlist request
lifecycle is currently different from the execbuffer request). This can
be a lot, especially in some of the less sane i-g-t tests.
Why?
Presuming the buffer objects is properly pushed onto the active list you
only need to pin while doing the command submission up to the point where
you've committed the buffer object to the active list.
I know documentation sucks for this stuff since I have this discussion
with roughly everyone ever touching anything related to active buffers :(
If you want some recent examples the cmd parser's shadow batch should
serve well (including the entire evolution from reinvented wheel to just
using the active list, although the latest patches are only 90% there and
still have 1-2 misplaced pieces).
Actually I just tried to implement this, it causes a problem for patch
4 of this set as the unpin_count is also used for the ringbuffer
object which has an ioremap as well as a ggtt pin.
Yeah, ioremap needs to be redone every time we pin/unpin. But on sane
archs it's almost no overhead really. And if this does start to matter
(shudder
for 32bit kernels on gen8) then we can fix it ...
Hm, so the CPU vaddr of the ring buffer will move around as more
requests reference it which I suppose is not a problem. We will use a
lot of address space (again, especially with the i-g-t stress tests
which can submit tens of thousands of requests in a very short space of
time). What would the fix be? An extra reference count for the
ioremap? Looks familiar :)
ioremap always gives you the same linear address on 64bit kernels. On
32bit it makes a new one, but if you ioremap for each request it'll fall
over anyway. The solution would be to ioremap just the required pages
using the atomic kmap stuff wrapped up into the io_mapping stuff.
I still think it's best to keep the context unpin_count for execlists mode.
Well just means the todo-list to fix up execlist grows longer.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/Android.mk: add gem_fence_upload excluded tests
On Tue, Nov 18, 2014 at 03:03:28PM +, tim.g...@intel.com wrote: From: Tim Gore tim.g...@intel.com gem_fence_upload implements some performance measurements, but fails on both android and linux systems and does not generally seem to be a usefull test, so exclude it. Signed-off-by: Tim Gore tim.g...@intel.com Nack. Just because the test tests something that doesn't yet work doesn't mean we should skip it by default. And if you need skip lists because of your validation process then that should be managed within your test environment, preferrably per-platform. -Daniel --- tests/Android.mk | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/Android.mk b/tests/Android.mk index 519852a..230d709 100644 --- a/tests/Android.mk +++ b/tests/Android.mk @@ -31,6 +31,9 @@ skip_tests_list := skip_tests_list += testdisplay# needs glib.h skip_tests_list += pm_rpm +# some tests are rusty +skip_tests_list += gem_fence_upload + # set local compilation flags for IGT tests IGT_LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM -DANDROID -UNDEBUG IGT_LOCAL_CFLAGS += -include check-ndebug.h -std=c99 -- 2.1.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop return value from
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate BYT: pass/total=290/290-290/290 PNV: pass/total=362/362-362/362 ILK: pass/total=381/381-374/381 IVB: pass/total=522/559-522/559 SNB: pass/total=444/444-444/444 HSW: pass/total=595/595-594/595 BDW: pass/total=436/436-436/436 -Detailed- test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...-result_with_patch_applied(count, machine_id)... ILK: Intel_gpu_tools, igt_kms_flip_bcs-wf_vblank-vs-modeset-interruptible, PASS(4, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-rmfb-interruptible, PASS(4, M37M26) - DMESG_WARN(2, M26)PASS(2, M26) ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_rcs-wf_vblank-vs-dpms-interruptible, PASS(4, M37M26) - DMESG_WARN(3, M26)PASS(1, M26) ILK: Intel_gpu_tools, igt_kms_flip_vblank-vs-hang-interruptible, PASS(4, M37M26) - DMESG_WARN(3, M26)PASS(1, M26) ILK: Intel_gpu_tools, igt_kms_flip_wf_vblank-ts-check, PASS(4, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_wf_vblank-vs-dpms, DMESG_WARN(1, M26)PASS(3, M6M26) - DMESG_WARN(2, M26)PASS(2, M26) HSW: Intel_gpu_tools, igt_gem_reset_stats_close-pending-render, PASS(3, M19M40) - NO_RESULT(1, M40)PASS(3, M40) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context backing objects to GGTT on-demand
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
Vetter
Sent: Tuesday, November 18, 2014 3:11 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
backing objects to GGTT on-demand
On Tue, Nov 18, 2014 at 02:51:52PM +, Daniel, Thomas wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Tuesday, November 18, 2014 2:33 PM
To: Daniel, Thomas
Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the
context backing objects to GGTT on-demand
On Tue, Nov 18, 2014 at 10:48:09AM +, Daniel, Thomas wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org]
On Behalf Of Daniel, Thomas
Sent: Tuesday, November 18, 2014 9:28 AM
To: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the
context backing objects to GGTT on-demand
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf
Of Daniel Vetter
Sent: Monday, November 17, 2014 6:09 PM
To: Daniel, Thomas
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the
context backing objects to GGTT on-demand
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h index 059330c..3c7299d
100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -655,6 +655,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ int unpin_count;
Pinning is already refcounted. Why this additional refcount?
The vma.pin_count is only allocated 4 bits of storage. If this
restriction can be lifted then I can use that.
Those 4 bits are good enough for legacy contexts, so I wonder a bit
what's so massively different for execlist contexts.
With execlists, in order to dynamically unpin the LRC backing object
and ring buffer object when not required we take a reference for each
execlist request that uses them (remember that the execlist request
lifecycle is currently different from the execbuffer request). This
can be a lot, especially in some of the less sane i-g-t tests.
Why?
Presuming the buffer objects is properly pushed onto the active list you only
need to pin while doing the command submission up to the point where
you've committed the buffer object to the active list.
This is not currently the case. Using the active list for context object
management is one of the refactoring tasks, as we agreed.
I know documentation sucks for this stuff since I have this discussion with
roughly everyone ever touching anything related to active buffers :( If you
want some recent examples the cmd parser's shadow batch should serve
well (including the entire evolution from reinvented wheel to just using the
active list, although the latest patches are only 90% there and still have 1-2
misplaced pieces).
Actually I just tried to implement this, it causes a problem for
patch
4 of this set as the unpin_count is also used for the ringbuffer
object which has an ioremap as well as a ggtt pin.
Yeah, ioremap needs to be redone every time we pin/unpin. But on
sane archs it's almost no overhead really. And if this does start to
matter (shudder for 32bit kernels on gen8) then we can fix it ...
Hm, so the CPU vaddr of the ring buffer will move around as more
requests reference it which I suppose is not a problem. We will use a
lot of address space (again, especially with the i-g-t stress tests
which can submit tens of thousands of requests in a very short space
of time). What would the fix be? An extra reference count for the
ioremap? Looks familiar :)
ioremap always gives you the same linear address on 64bit kernels. On 32bit
it makes a new one, but if you ioremap for each request it'll fall over
anyway.
Ah, I didn't know that ioremap behaved like that.
The solution would be to ioremap just the required pages using the atomic
kmap stuff wrapped up into the io_mapping stuff.
I still think it's best to keep the context unpin_count for execlists mode.
Well just means the todo-list to fix up execlist grows longer.
That's OK from my point of view, this may go away anyway with some of the
refactoring. The (strong) direction I'm getting from the management is that
they want these merged ASAP.
Cheers,
Thomas.
-Daniel
--
Daniel Vetter
Software Engineer, Intel
Re: [Intel-gfx] [PATCH 0/8] sanitize RPS interrupt enabling/disabling
2014-11-05 16:48 GMT-02:00 Imre Deak imre.d...@intel.com: While fixing [1] I noticed that we can simplify a couple of things in the RPS enabling/disabling code. So I did that and also fixed one WARN that we can hit with some of the pm_rpm subtests. Hopefully these changes also makes it clearer how we avoid the race during RPS interrupt disabling and makes it less fragile (see the comment in patch 7/8). [1] https://bugs.freedesktop.org/show_bug.cgi?id=82939 Imre Deak (8): drm/i915: unify gen6/gen8 pm irq helpers drm/i915: unify gen6/gen8 rps irq handler drm/i915: unify gen6/gen8 rps irq enable/disable drm/i915: move rps irq enable/disable to i915_irq.c drm/i915: move rps irq disable one level up drm/i915: sanitize rps irq enabling drm/i915: sanitize rps irq disabling drm/i915: disable rps irqs earlier during suspend/unload With or without my bikesheds, feel free to add Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com to: - new versions of patches 5, 6, and 7 - patch 8 Although it would be nice to see those gen != 9 replaced with gen 9, but maybe Daniel can do this. drivers/gpu/drm/i915/i915_drv.c | 9 +-- drivers/gpu/drm/i915/i915_drv.h | 6 +- drivers/gpu/drm/i915/i915_irq.c | 122 +++ drivers/gpu/drm/i915/intel_display.c | 6 +- drivers/gpu/drm/i915/intel_drv.h | 5 +- drivers/gpu/drm/i915/intel_pm.c | 90 +++--- 6 files changed, 90 insertions(+), 148 deletions(-) -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/8] sanitize RPS interrupt enabling/disabling
On Tue, 2014-11-18 at 14:04 -0200, Paulo Zanoni wrote: 2014-11-05 16:48 GMT-02:00 Imre Deak imre.d...@intel.com: While fixing [1] I noticed that we can simplify a couple of things in the RPS enabling/disabling code. So I did that and also fixed one WARN that we can hit with some of the pm_rpm subtests. Hopefully these changes also makes it clearer how we avoid the race during RPS interrupt disabling and makes it less fragile (see the comment in patch 7/8). [1] https://bugs.freedesktop.org/show_bug.cgi?id=82939 Imre Deak (8): drm/i915: unify gen6/gen8 pm irq helpers drm/i915: unify gen6/gen8 rps irq handler drm/i915: unify gen6/gen8 rps irq enable/disable drm/i915: move rps irq enable/disable to i915_irq.c drm/i915: move rps irq disable one level up drm/i915: sanitize rps irq enabling drm/i915: sanitize rps irq disabling drm/i915: disable rps irqs earlier during suspend/unload With or without my bikesheds, feel free to add Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com to: - new versions of patches 5, 6, and 7 - patch 8 Thanks! Although it would be nice to see those gen != 9 replaced with gen 9, but maybe Daniel can do this. Ok, will resend with those changes. drivers/gpu/drm/i915/i915_drv.c | 9 +-- drivers/gpu/drm/i915/i915_drv.h | 6 +- drivers/gpu/drm/i915/i915_irq.c | 122 +++ drivers/gpu/drm/i915/intel_display.c | 6 +- drivers/gpu/drm/i915/intel_drv.h | 5 +- drivers/gpu/drm/i915/intel_pm.c | 90 +++--- 6 files changed, 90 insertions(+), 148 deletions(-) -- 1.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: fix monitor presence indication
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate BYT: pass/total=290/290-290/290 PNV: pass/total=362/362-362/362 ILK: pass/total=381/381-380/381 IVB: pass/total=522/559-521/559 SNB: pass/total=444/444-444/444 HSW: pass/total=595/595-595/595 BDW: pass/total=436/436-436/436 -Detailed- test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...-result_with_patch_applied(count, machine_id)... ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible, DMESG_WARN(2, M26M37)PASS(5, M37M26) - DMESG_WARN(1, M37)PASS(3, M37) IVB: Intel_gpu_tools, igt_kms_cursor_crc_cursor-64x64-offscreen, PASS(4, M21) - DMESG_WARN(1, M21)PASS(3, M21) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ddi: set has_infoframe flag on DDI too
On Tue, 18 Nov 2014 09:14:05 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Nov 17, 2014 at 01:08:46PM -0800, Jesse Barnes wrote:
Just like we do in the HDMI code, set the infoframe flag if we detect an
HDMI sink.
Reported-by: Paulo Zanoni przan...@gmail.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 86745da..78576e0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2062,6 +2062,7 @@ void intel_ddi_get_config(struct intel_encoder
*encoder,
switch (temp TRANS_DDI_MODE_SELECT_MASK) {
case TRANS_DDI_MODE_SELECT_HDMI:
pipe_config-has_hdmi_sink = true;
+ pipe_config-has_infoframe = true;
Infoframes aren't controlled by this bit here but set in
HSW_TVIDEO_DIP_CTL. Since the point of this is to detect mismatches
between the bios and what we'd like to have for fastboot I think we need
to check that register. Instead of blindly deriving state to appease the
cross checker.
Oh you're right; I was thinking of compute_config. I'll send a follow
up.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm: add helper to get crtc timings (v3)
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
v3 (by Matt):
- Add missing kerneldoc (Daniel)
- Use drm_mode_copy() (Jani)
Cc: dri-de...@lists.freedesktop.org
Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/drm_crtc.c | 32 ++--
drivers/gpu/drm/i915/intel_display.c | 6 +++---
include/drm/drm_crtc.h | 2 ++
3 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 56737e7..be1a485 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2494,6 +2494,27 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
EXPORT_SYMBOL(drm_mode_set_config_internal);
/**
+ * drm_crtc_get_hv_timing - Fetches hdisplay/vdisplay for given mode
+ * @mode: mode to query
+ * @hdisplay: hdisplay value to fill in
+ * @vdisplay: vdisplay value to fill in
+ *
+ * The vdisplay value will be doubled if the specified mode is a stereo mode of
+ * the appropriate layout.
+ */
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+ int *hdisplay, int *vdisplay)
+{
+ struct drm_display_mode adjusted;
+
+ drm_mode_copy(adjusted, mode);
+ drm_mode_stereo_double(adjusted);
+ *hdisplay = adjusted.crtc_hdisplay;
+ *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
+/**
* drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
* CRTC viewport
* @crtc: CRTC that framebuffer will be displayed on
@@ -2510,16 +2531,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
{
int hdisplay, vdisplay;
- hdisplay = mode-hdisplay;
- vdisplay = mode-vdisplay;
-
- if (drm_mode_is_stereo(mode)) {
- struct drm_display_mode adjusted = *mode;
-
- drm_mode_set_crtcinfo(adjusted, CRTC_STEREO_DOUBLE);
- hdisplay = adjusted.crtc_hdisplay;
- vdisplay = adjusted.crtc_vdisplay;
- }
+ drm_crtc_get_hv_timing(mode, hdisplay, vdisplay);
if (crtc-invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 320bf4c..a967623 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
* computation to clearly distinguish it from the adjusted mode, which
* can be changed by the connectors in the below retry loop.
*/
- drm_mode_set_crtcinfo(pipe_config-requested_mode, CRTC_STEREO_DOUBLE);
- pipe_config-pipe_src_w = pipe_config-requested_mode.crtc_hdisplay;
- pipe_config-pipe_src_h = pipe_config-requested_mode.crtc_vdisplay;
+ drm_crtc_get_hv_timing(pipe_config-requested_mode,
+ pipe_config-pipe_src_w,
+ pipe_config-pipe_src_h);
encoder_retry:
/* Ensure the port clock defaults are reset when retrying. */
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7b28ab0..23236f6 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1138,6 +1138,8 @@ extern int drm_plane_init(struct drm_device *dev,
extern void drm_plane_cleanup(struct drm_plane *plane);
extern unsigned int drm_plane_index(struct drm_plane *plane);
extern void drm_plane_force_disable(struct drm_plane *plane);
+extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+ int *hdisplay, int *vdisplay);
extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
int x, int y,
const struct drm_display_mode *mode,
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace
Jani/Jesse, Does this patch look reasonable to you for merging? -- U. Artie -Original Message- From: Eoff, Ullysses A Sent: Tuesday, November 11, 2014 12:31 PM To: intel-gfx@lists.freedesktop.org Cc: Eoff, Ullysses A Subject: [PATCH] drm/i915: expose a fixed brightness range to userspace A userspace brightness range that is larger than the hardware brightness range does not have a 1:1 mapping and can result in brightness != actual_brightness for some values. Expose a fixed brightness range of [0..1000] to userspace so that all values can map 1:1 into the hardware brightness range. This would assume that the hardware range is always greater than 1000, otherwise we're right back to the original issue. This patch is based on Jani Nikula's proposed change in the referenced ML thread, except use the range [0..1000] instead; which was recommended by Jesse Barnes for smoother backlight transitions. Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-November/055221.html Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com --- drivers/gpu/drm/i915/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 4d63839..f74f5f2 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1057,7 +1057,7 @@ static int intel_backlight_device_register(struct intel_connector *connector) * Note: Everything should work even if the backlight device max * presented to the userspace is arbitrarily chosen. */ - props.max_brightness = panel-backlight.max; + props.max_brightness = 1000; props.brightness = scale_hw_to_user(connector, panel-backlight.level, props.max_brightness); -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace
On Tue, 11 Nov 2014 12:30:38 -0800 U. Artie Eoff ullysses.a.e...@intel.com wrote: A userspace brightness range that is larger than the hardware brightness range does not have a 1:1 mapping and can result in brightness != actual_brightness for some values. Expose a fixed brightness range of [0..1000] to userspace so that all values can map 1:1 into the hardware brightness range. This would assume that the hardware range is always greater than 1000, otherwise we're right back to the original issue. This patch is based on Jani Nikula's proposed change in the referenced ML thread, except use the range [0..1000] instead; which was recommended by Jesse Barnes for smoother backlight transitions. Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-November/055221.html Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com --- drivers/gpu/drm/i915/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 4d63839..f74f5f2 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1057,7 +1057,7 @@ static int intel_backlight_device_register(struct intel_connector *connector) * Note: Everything should work even if the backlight device max * presented to the userspace is arbitrarily chosen. */ - props.max_brightness = panel-backlight.max; + props.max_brightness = 1000; props.brightness = scale_hw_to_user(connector, panel-backlight.level, props.max_brightness); Yeah looks ok to me. I guess Jani has to ack it too. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/ddi: set has_infoframe flag on DDI too v2
Just like we do in the HDMI code, set the infoframe flag if we detect
that infoframes are enabled.
v2: check for actual infoframe status as in hdmi code (Daniel)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 07c5625..24110c9 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2075,6 +2075,14 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
break;
}
+ if (encoder-type == INTEL_OUTPUT_HDMI) {
+ struct intel_hdmi *intel_hdmi =
+ enc_to_intel_hdmi(encoder-base);
+
+ if (intel_hdmi-infoframe_enabled(encoder-base))
+ pipe_config-has_infoframe = true;
+ }
+
if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
if (temp AUDIO_OUTPUT_ENABLE(intel_crtc-pipe))
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/15] drm/i915: Introduce intel_psr.c
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:22 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 02/15] drm/i915: Introduce intel_psr.c
No functional changes. Just cleaning and reorganizing it.
v2: Rebase it puting it to begin of psr rework. This helps to blame easily
at least latest changes.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_dp.c | 381 +
drivers/gpu/drm/i915/intel_drv.h | 21 +-
drivers/gpu/drm/i915/intel_frontbuffer.c | 4 +-
drivers/gpu/drm/i915/intel_psr.c | 408 +++
7 files changed, 428 insertions(+), 393 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_psr.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 891e584..e4083e4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -51,6 +51,7 @@ i915-y += intel_audio.o \
intel_frontbuffer.o \
intel_modes.o \
intel_overlay.o \
+intel_psr.o \
intel_sideband.o \
intel_sprite.o
i915-$(CONFIG_ACPI) += intel_acpi.o intel_opregion.o
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 68703ce..a5a8acd 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1228,7 +1228,7 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder)
intel_dp_stop_link_train(intel_dp);
intel_edp_backlight_on(intel_dp);
- intel_edp_psr_enable(intel_dp);
+ intel_psr_enable(intel_dp);
}
if (intel_crtc-config.has_audio) {
@@ -1254,7 +1254,7 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder)
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
- intel_edp_psr_disable(intel_dp);
+ intel_psr_disable(intel_dp);
intel_edp_backlight_off(intel_dp);
}
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4706856..2ca6939 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12310,7 +12310,7 @@ static void intel_setup_outputs(struct drm_device *dev)
if (SUPPORTS_TV(dev))
intel_tv_init(dev);
- intel_edp_psr_init(dev);
+ intel_psr_init(dev);
for_each_intel_encoder(dev, encoder) {
encoder-base.possible_crtcs = encoder-crtc_mask;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 01834cd..98f7ecd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2066,385 +2066,6 @@ static void intel_dp_get_config(struct intel_encoder
*encoder,
}
}
-static bool is_edp_psr(struct intel_dp *intel_dp)
-{
- return intel_dp-psr_dpcd[0] DP_PSR_IS_SUPPORTED;
-}
-
-static bool intel_edp_is_psr_enabled(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = dev-dev_private;
-
- if (!HAS_PSR(dev))
- return false;
-
- return I915_READ(EDP_PSR_CTL(dev)) EDP_PSR_ENABLE;
-}
-
-static void intel_edp_psr_write_vsc(struct intel_dp *intel_dp,
- struct edp_vsc_psr *vsc_psr)
-{
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- struct drm_device *dev = dig_port-base.base.dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *crtc = to_intel_crtc(dig_port-base.base.crtc);
- u32 ctl_reg = HSW_TVIDEO_DIP_CTL(crtc-config.cpu_transcoder);
- u32 data_reg = HSW_TVIDEO_DIP_VSC_DATA(crtc-config.cpu_transcoder);
- uint32_t *data = (uint32_t *) vsc_psr;
- unsigned int i;
-
- /* As per BSPec (Pipe Video Data Island Packet), we need to disable
- the video DIP being updated before program video DIP data buffer
- registers for DIP being updated. */
- I915_WRITE(ctl_reg, 0);
- POSTING_READ(ctl_reg);
-
- for (i = 0; i VIDEO_DIP_VSC_DATA_SIZE; i += 4) {
- if (i sizeof(struct edp_vsc_psr))
- I915_WRITE(data_reg + i, *data++);
- else
- I915_WRITE(data_reg + i, 0);
- }
-
- I915_WRITE(ctl_reg, VIDEO_DIP_ENABLE_VSC_HSW);
- POSTING_READ(ctl_reg);
-}
-
-static void intel_edp_psr_setup_vsc(struct intel_dp *intel_dp)
-{
- struct edp_vsc_psr psr_vsc;
-
- /* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
- memset(psr_vsc, 0, sizeof(psr_vsc));
- psr_vsc.sdp_header.HB0 = 0;
- psr_vsc.sdp_header.HB1 =
Re: [Intel-gfx] [PATCH 03/15] drm/i915: Add PSR docbook
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:22 PM
To: intel-gfx@lists.freedesktop.org
Cc: Daniel Vetter; Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 03/15] drm/i915: Add PSR docbook
Let's document PSR a bit. No functional changes.
v2: Add actual DocBook entry and accept Daniel's improvements.
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
Documentation/DocBook/drm.tmpl | 5 +++
drivers/gpu/drm/i915/intel_psr.c | 73
2 files changed, 78 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 9449cd6..a1168a8 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3893,6 +3893,11 @@ int num_ioctls;/synopsis
!Idrivers/gpu/drm/i915/intel_audio.c
/sect2
sect2
+ titlePanel Self Refresh PSR (PSR/SRD)/title
+!Pdrivers/gpu/drm/i915/intel_psr.c Panel Self Refresh (PSR/SRD)
+!Idrivers/gpu/drm/i915/intel_psr.c
+ /sect2
+ sect2
titleDPIO/title
!Pdrivers/gpu/drm/i915/i915_reg.h DPIO
table id=dpiox2
diff --git a/drivers/gpu/drm/i915/intel_psr.c
b/drivers/gpu/drm/i915/intel_psr.c
index 7b3ed91..716b8a9 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -21,6 +21,36 @@
* DEALINGS IN THE SOFTWARE.
*/
+/**
+ * DOC: Panel Self Refresh (PSR/SRD)
+ *
+ * Since Haswell Display controller supports Panel Self-Refresh on display
+ * panels witch have a remote frame buffer (RFB) implemented according to PSR
s/witch/which ;)
oh, I see that this is already merged, anyway..
Thanks,
Durga
+ * spec in eDP1.3. PSR feature allows the display to go to lower standby
states
+ * when system is idle but display is on as it eliminates display refresh
+ * request to DDR memory completely as long as the frame buffer for that
+ * display is unchanged.
+ *
+ * Panel Self Refresh must be supported by both Hardware (source) and
+ * Panel (sink).
+ *
+ * PSR saves power by caching the framebuffer in the panel RFB, which allows
us
+ * to power down the link and memory controller. For DSI panels the same idea
+ * is called manual mode.
+ *
+ * The implementation uses the hardware-based PSR support which automatically
+ * enters/exits self-refresh mode. The hardware takes care of sending the
+ * required DP aux message and could even retrain the link (that part isn't
+ * enabled yet though). The hardware also keeps track of any frontbuffer
+ * changes to know when to exit self-refresh mode again. Unfortunately that
+ * part doesn't work too well, hence why the i915 PSR support uses the
+ * software frontbuffer tracking to make sure it doesn't miss a screen
+ * update. For this integration intel_psr_invalidate() and intel_psr_flush()
+ * get called by the frontbuffer tracking code. Note that because of locking
+ * issues the self-refresh re-enable code is done from a work queue, which
+ * must be correctly synchronized/cancelled when shutting down the pipe.
+ */
+
#include drm/drmP.h
#include intel_drv.h
@@ -217,6 +247,12 @@ static void intel_psr_do_enable(struct intel_dp *intel_dp)
dev_priv-psr.active = true;
}
+/**
+ * intel_psr_enable - Enable PSR
+ * @intel_dp: Intel DP
+ *
+ * This function can only be called after the pipe is fully trained and
enabled.
+ */
void intel_psr_enable(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -258,6 +294,12 @@ unlock:
mutex_unlock(dev_priv-psr.lock);
}
+/**
+ * intel_psr_disable - Disable PSR
+ * @intel_dp: Intel DP
+ *
+ * This function needs to be called before disabling pipe.
+ */
void intel_psr_disable(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -342,6 +384,18 @@ static void intel_psr_exit(struct drm_device *dev)
}
+/**
+ * intel_psr_invalidate - Invalidade PSR
+ * @dev: DRM device
+ * @frontbuffer_bits: frontbuffer plane tracking bits
+ *
+ * Since the hardware frontbuffer tracking has gaps we need to integrate
+ * with the software frontbuffer tracking. This function gets called every
+ * time frontbuffer rendering starts and a buffer gets dirtied. PSR must be
+ * disabled if the frontbuffer mask contains a buffer relevant to PSR.
+ *
+ * Dirty frontbuffers relevant to PSR are tracked in busy_frontbuffer_bits.
+ */
void intel_psr_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits)
{
@@ -366,6 +420,18 @@ void intel_psr_invalidate(struct drm_device *dev,
mutex_unlock(dev_priv-psr.lock);
}
+/**
+ * intel_psr_flush - Flush PSR
+ * @dev: DRM device
+ * @frontbuffer_bits: frontbuffer plane tracking bits
+ *
+ * Since the hardware frontbuffer tracking has gaps we need to integrate
+ * with the software frontbuffer tracking. This function gets called
Re: [Intel-gfx] [PATCH 06/15] drm/i915: PSR get full link off x standby from VBT
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 06/15] drm/i915: PSR get full link off x standby
from VBT
OEMs can specify if full_link might be always enabled, i.e. only_standby
over VBT.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
I have not looked at/tried these VBT bits myself. If that's ok then,
For patches 4,5,6:
Reviewed-by: Durgadoss R durgados...@intel.com
Thanks,
Durga
---
drivers/gpu/drm/i915/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c
b/drivers/gpu/drm/i915/intel_psr.c
index 576568e..e706c9d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -120,7 +120,7 @@ static void intel_psr_enable_sink(struct intel_dp
*intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t aux_clock_divider;
int precharge = 0x3;
- bool only_standby = false;
+ bool only_standby = dev_priv-vbt.psr.full_link;
static const uint8_t aux_msg[] = {
[0] = DP_AUX_NATIVE_WRITE 4,
[1] = DP_SET_POWER 8,
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/15] drm/i915: remove PSR BDW single frame update.
-Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Rodrigo Vivi Sent: Friday, November 14, 2014 10:23 PM To: intel-gfx@lists.freedesktop.org Cc: Vivi, Rodrigo Subject: [Intel-gfx] [PATCH 08/15] drm/i915: remove PSR BDW single frame update. Single frame update is a feature available on BDW for PSR that allows Source to send Sink only one frame and get it updated. Usually useful when page fliping. However with our frontbuffer tracking where we force flipping psr exit on flips we don't need this feature. Also after it got added here many workaround was added to documentation to mask some bits when using single frame update. So the safest thing is to just stop using it. Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com Again, I have not looked at the BDW spec. But the commit message sounds reasonable. So, Reviewed-by: Durgadoss R durgados...@intel.com Thanks, Durga --- drivers/gpu/drm/i915/intel_psr.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 4cfe7a4..66d24c2 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -180,7 +180,6 @@ static void intel_psr_enable_source(struct intel_dp *intel_dp) val |= EDP_PSR_LINK_STANDBY; val |= EDP_PSR_TP2_TP3_TIME_0us; val |= EDP_PSR_TP1_TIME_0us; - val |= IS_BROADWELL(dev) ? BDW_PSR_SINGLE_FRAME : 0; } else val |= EDP_PSR_LINK_DISABLE; -- 1.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/15] drm/i915: Fix intel_psr_is_enabled function and document it.
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 09/15] drm/i915: Fix intel_psr_is_enabled function
and document it.
This function can be used to check if psr feature got enabled.
However on HSW and BDW we currently force psr exit by disabling
EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually
returning the active/inactive state that is different from the enable/disable
meaning and had the risk of false negative.
So let's just return the presence of intel_dp at dev_priv-psr.enabled.
It would be more easy to just check this presence directly but let's keep
it more organized.
Agreed, but shouldn't we protect it using psr.lock ?
Thanks,
Durga
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_psr.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c
b/drivers/gpu/drm/i915/intel_psr.c
index 66d24c2..c296a89 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -61,6 +61,16 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
return intel_dp-psr_dpcd[0] DP_PSR_IS_SUPPORTED;
}
+/**
+ * intel_psr_is_enabled - Is PSR enabled?
+ * @dev: DRM Device
+ *
+ * This function can be used to verify if PSR feature is enabled.
+ * Since on Haswell+ we force the exit by disabling
+ * EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev)
+ * the most reliable way to export if psr feature is enabled is to
+ * check the presence of intel_dp at dev_priv-psr.enabled.
+ */
bool intel_psr_is_enabled(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -68,7 +78,7 @@ bool intel_psr_is_enabled(struct drm_device *dev)
if (!HAS_PSR(dev))
return false;
- return I915_READ(EDP_PSR_CTL(dev)) EDP_PSR_ENABLE;
+ return (bool)dev_priv-psr.enabled;
}
static void intel_psr_write_vsc(struct intel_dp *intel_dp,
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/15] drm/i915: Add PSR registers for PSR VLV/CHV.
-Original Message-
From: Vivi, Rodrigo
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH 10/15] drm/i915: Add PSR registers for PSR VLV/CHV.
Baytrail (Valleyview) and Braswell (Cherryview) uses a complete different
implementation of PSR that we currently have supported for
Haswell and Broadwell. So let's start by adding registers definitions.
I usually don't like commit that adds just registers without using,
but after I put all in one commit I realized that no one would want
to take the AR to review it so I decided to split in order to make
reviewer's life easier. Only last commit in this series will actually
enable the PSR on intel enable panel path.
But as it happens currently with HSW/BDW the plan is to let it
disabled by default (protected by kernel parameter)
while we are able to fully validate it.
v2: Remove a unused bit definition that isn't used on vlv and
reserved on chv as pointed out by Durgadoss.
Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
Reviewed-by: Durgadoss R durgados...@intel.com
Thanks,
Durga
---
drivers/gpu/drm/i915/i915_reg.h | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 35cfc16..667a923 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2511,6 +2511,42 @@ enum punit_power_well {
#define PIPESRC(trans) _TRANSCODER2(trans, _PIPEASRC)
#define PIPE_MULT(trans) _TRANSCODER2(trans, _PIPE_MULT_A)
+/* VLV eDP PSR registers */
+#define _PSRCTLA (VLV_DISPLAY_BASE + 0x60090)
+#define _PSRCTLB (VLV_DISPLAY_BASE + 0x61090)
+#define VLV_EDP_PSR_ENABLE (10)
+#define VLV_EDP_PSR_RESET(11)
+#define VLV_EDP_PSR_MODE_MASK(72)
+#define VLV_EDP_PSR_MODE_HW_TIMER(13)
+#define VLV_EDP_PSR_MODE_SW_TIMER(12)
+#define VLV_EDP_PSR_SINGLE_FRAME_UPDATE (17)
+#define VLV_EDP_PSR_ACTIVE_ENTRY (18)
+#define VLV_EDP_PSR_SRC_TRANSMITTER_STATE(19)
+#define VLV_EDP_PSR_DBL_FRAME(110)
+#define VLV_EDP_PSR_FRAME_COUNT_MASK (0xff16)
+#define VLV_EDP_PSR_IDLE_FRAME_SHIFT 16
+#define VLV_PSRCTL(pipe) _PIPE(pipe, _PSRCTLA, _PSRCTLB)
+
+#define _VSCSDPA (VLV_DISPLAY_BASE + 0x600a0)
+#define _VSCSDPB (VLV_DISPLAY_BASE + 0x610a0)
+#define VLV_EDP_PSR_SDP_FREQ_MASK(330)
+#define VLV_EDP_PSR_SDP_FREQ_ONCE(131)
+#define VLV_EDP_PSR_SDP_FREQ_EVFRAME (130)
+#define VLV_VSCSDP(pipe) _PIPE(pipe, _VSCSDPA, _VSCSDPB)
+
+#define _PSRSTATA (VLV_DISPLAY_BASE + 0x60094)
+#define _PSRSTATB (VLV_DISPLAY_BASE + 0x61094)
+#define VLV_EDP_PSR_LAST_STATE_MASK (73)
+#define VLV_EDP_PSR_CURR_STATE_MASK 7
+#define VLV_EDP_PSR_DISABLED (00)
+#define VLV_EDP_PSR_INACTIVE (10)
+#define VLV_EDP_PSR_IN_TRANS_TO_ACTIVE (20)
+#define VLV_EDP_PSR_ACTIVE_NORFB_UP (30)
+#define VLV_EDP_PSR_ACTIVE_SF_UPDATE (40)
+#define VLV_EDP_PSR_EXIT (50)
+#define VLV_EDP_PSR_IN_TRANS (17)
+#define VLV_PSRSTAT(pipe) _PIPE(pipe, _PSRSTATA, _PSRSTATB)
+
/* HSW+ eDP PSR registers */
#define EDP_PSR_BASE(dev) (IS_HASWELL(dev) ? 0x64800 :
0x6f800)
#define EDP_PSR_CTL(dev) (EDP_PSR_BASE(dev) + 0)
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915: PSR VLV/CHV: Introduce setup, enable and disable functions
-Original Message-
From: Vivi, Rodrigo
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH 11/15] drm/i915: PSR VLV/CHV: Introduce setup, enable and
disable functions
The biggest difference from HSW/BDW PSR here is that VLV enable_source
function enables PSR but let it in Inactive state. So it might be called
on early stage along with setup and enable_sink ones.
v2: Rebase over intel_psr.c;
Remove docs from static functions;
Merge vlv_psr_active_on_pipe;
Timeout for psr transition is 250us;
Remove SRC_TRASMITTER_STATE;
With SRC_TRANSMITTER_STATE not set to 1
explicitly, if entry/exit works, I would like to know what DPCD
register 71h is reading in your panel ?
I would expect bit 0 of 71h to be 1.
Is it the case ? Can we check once ?
Thanks,
Durga
Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_psr.c | 154 ---
1 file changed, 129 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c
b/drivers/gpu/drm/i915/intel_psr.c
index c296a89..bdb28f2 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -81,6 +81,17 @@ bool intel_psr_is_enabled(struct drm_device *dev)
return (bool)dev_priv-psr.enabled;
}
+static bool vlv_is_psr_active_on_pipe(struct drm_device *dev, int pipe)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t val;
+
+ val = I915_READ(VLV_PSRSTAT(pipe))
+VLV_EDP_PSR_CURR_STATE_MASK;
+ return (val == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+ (val == VLV_EDP_PSR_ACTIVE_SF_UPDATE);
+}
+
static void intel_psr_write_vsc(struct intel_dp *intel_dp,
struct edp_vsc_psr *vsc_psr)
{
@@ -110,7 +121,23 @@ static void intel_psr_write_vsc(struct intel_dp *intel_dp,
POSTING_READ(ctl_reg);
}
-static void intel_psr_setup_vsc(struct intel_dp *intel_dp)
+static void vlv_psr_setup_vsc(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc = intel_dig_port-base.base.crtc;
+ enum pipe pipe = to_intel_crtc(crtc)-pipe;
+ uint32_t val;
+
+ /* VLV auto-generate VSC package as per EDP 1.3 spec, Table 3.10 */
+ val = I915_READ(VLV_VSCSDP(pipe));
+ val = ~VLV_EDP_PSR_SDP_FREQ_MASK;
+ val |= VLV_EDP_PSR_SDP_FREQ_EVFRAME;
+ I915_WRITE(VLV_VSCSDP(pipe), val);
+}
+
+static void hsw_psr_setup_vsc(struct intel_dp *intel_dp)
{
struct edp_vsc_psr psr_vsc;
@@ -123,7 +150,13 @@ static void intel_psr_setup_vsc(struct intel_dp *intel_dp)
intel_psr_write_vsc(intel_dp, psr_vsc);
}
-static void intel_psr_enable_sink(struct intel_dp *intel_dp)
+static void vlv_psr_enable_sink(struct intel_dp *intel_dp)
+{
+ drm_dp_dpcd_writeb(intel_dp-aux, DP_PSR_EN_CFG,
+ DP_PSR_ENABLE);
+}
+
+static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port-base.base.dev;
@@ -167,7 +200,21 @@ static void intel_psr_enable_sink(struct intel_dp
*intel_dp)
(aux_clock_divider DP_AUX_CH_CTL_BIT_CLOCK_2X_SHIFT));
}
-static void intel_psr_enable_source(struct intel_dp *intel_dp)
+static void vlv_psr_enable_source(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc = dig_port-base.base.crtc;
+ enum pipe pipe = to_intel_crtc(crtc)-pipe;
+
+ /* Transition from PSR_state 0 to PSR_state 1, i.e. PSR Inactive */
+ I915_WRITE(VLV_PSRCTL(pipe),
+ VLV_EDP_PSR_MODE_SW_TIMER |
+ VLV_EDP_PSR_ENABLE);
+}
+
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port-base.base.dev;
@@ -247,7 +294,7 @@ static bool intel_psr_match_conditions(struct intel_dp
*intel_dp)
return true;
}
-static void intel_psr_do_enable(struct intel_dp *intel_dp)
+static void intel_psr_activate(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port-base.base.dev;
@@ -257,9 +304,12 @@ static void intel_psr_do_enable(struct intel_dp *intel_dp)
WARN_ON(dev_priv-psr.active);
lockdep_assert_held(dev_priv-psr.lock);
- /* Enable/Re-enable PSR on the host */
- intel_psr_enable_source(intel_dp);
-
+ /* Enable/Re-enable PSR on the host
+ *
Re: [Intel-gfx] [PATCH 12/15] drm/i915: VLV/CHV PSR Software timer mode
-Original Message-
From: Vivi, Rodrigo
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH 12/15] drm/i915: VLV/CHV PSR Software timer mode
This patch introduces exit/activate functions for PSR
on VLV+. Since on VLV+ HW cannot track frame updates and force PSR
exit let's use fully SW tracking available.
v2: Rebase over intel_psr.c;
Remove Single Frame update transitioning from state 3 to 5 directly;
Fake a software invalidation for sprites and cursor so we don't miss
any screen update;
Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_psr.c | 96 ++--
1 file changed, 83 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c
b/drivers/gpu/drm/i915/intel_psr.c
index bdb28f2..b2a4ee7 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -214,6 +214,23 @@ static void vlv_psr_enable_source(struct intel_dp
*intel_dp)
VLV_EDP_PSR_ENABLE);
}
+static void vlv_psr_activate(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc = dig_port-base.base.crtc;
+ enum pipe pipe = to_intel_crtc(crtc)-pipe;
+
+ /* Let's do the transition from PSR_state 1 to PSR_state 2
+ * that is PSR transition to active - static frame transmission.
+ * Then Hardware is responsible for the transition to PSR_state 3
+ * that is PSR active - no Remote Frame Buffer (RFB) update.
+ */
+ I915_WRITE(VLV_PSRCTL(pipe), I915_READ(VLV_PSRCTL(pipe)) |
+ VLV_EDP_PSR_ACTIVE_ENTRY);
+}
+
static void hsw_psr_enable_source(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -304,12 +321,16 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
WARN_ON(dev_priv-psr.active);
lockdep_assert_held(dev_priv-psr.lock);
- /* Enable/Re-enable PSR on the host
- * On HSW+ after we enable PSR on source it will activate it
- * as soon as it match configure idle_frame count. So
- * we just actually enable it here on activation time.
- */
- hsw_psr_enable_source(intel_dp);
+ /* Enable/Re-enable PSR on the host */
+ if (HAS_DDI(dev))
+ /* On HSW+ after we enable PSR on source it will activate it
+ * as soon as it match configure idle_frame count. So
+ * we just actually enable it here on activation time.
+ */
+ hsw_psr_enable_source(intel_dp);
+ else
+ vlv_psr_activate(intel_dp);
+
dev_priv-psr.active = true;
}
@@ -457,18 +478,27 @@ static void intel_psr_work(struct work_struct *work)
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), psr.work.work);
struct intel_dp *intel_dp = dev_priv-psr.enabled;
+ struct drm_crtc *crtc = dp_to_dig_port(intel_dp)-base.base.crtc;
+ enum pipe pipe = to_intel_crtc(crtc)-pipe;
/* We have to make sure PSR is ready for re-enable
* otherwise it keeps disabled until next full enable/disable cycle.
* PSR might take some time to get fully disabled
* and be ready for re-enable.
*/
- if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev_priv-dev))
-EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
- DRM_ERROR(Timed out waiting for PSR Idle for re-enable\n);
- return;
+ if (HAS_DDI(dev_priv-dev)) {
+ if (wait_for((I915_READ(EDP_PSR_STATUS_CTL(dev_priv-dev))
+EDP_PSR_STATUS_STATE_MASK) == 0, 50)) {
+ DRM_ERROR(Timed out waiting for PSR Idle for
re-enable\n);
+ return;
+ }
+ } else {
+ if (wait_for((I915_READ(VLV_PSRSTAT(pipe))
+VLV_EDP_PSR_IN_TRANS) == 0, 0.250)) {
I didn't know wait_for takes floats ;)
+ DRM_ERROR(Timed out waiting for PSR Idle for
re-enable\n);
+ return;
+ }
}
-
mutex_lock(dev_priv-psr.lock);
intel_dp = dev_priv-psr.enabled;
@@ -491,17 +521,47 @@ unlock:
static void intel_psr_exit(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_dp *intel_dp = dev_priv-psr.enabled;
+ struct drm_crtc *crtc = dp_to_dig_port(intel_dp)-base.base.crtc;
+ enum pipe pipe = to_intel_crtc(crtc)-pipe;
+ u32 val;
- if (dev_priv-psr.active) {
- u32 val = I915_READ(EDP_PSR_CTL(dev));
+ if (!dev_priv-psr.active)
+ return;
+
+ if (HAS_DDI(dev)) {
+
Re: [Intel-gfx] [PATCH 13/15] drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.
-Original Message-
From: Vivi, Rodrigo
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; R, Durgadoss
Subject: [PATCH 13/15] drm/i915: VLV/CHV PSR: Increase wait delay time before
active PSR.
Since active function on VLV immediately activate PSR let's give more
time for idleness.
v2: Rebase over intel_psr.c and fix typo.
Cc: Durgadoss R durgados...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/intel_psr.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_psr.c
b/drivers/gpu/drm/i915/intel_psr.c
index b2a4ee7..fe7b0f6 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -618,6 +618,11 @@ void intel_psr_flush(struct drm_device *dev,
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_crtc *crtc;
enum pipe pipe;
+ /* On HSW/BDW Hardware controls idle_frames to go to PSR entry state
+ * However on VLV we go to PSR active state with psr work. So let's
s/psr/PSR
Reviewed-by: Durgadoss R durgados...@intel.com
Thanks,
Durga
+ * wait more time and let the user experience smooth enough.
+ */
+ int delay = msecs_to_jiffies(HAS_DDI(dev) ? 100 : 5000);
mutex_lock(dev_priv-psr.lock);
if (!dev_priv-psr.enabled) {
@@ -651,7 +656,7 @@ void intel_psr_flush(struct drm_device *dev,
if (!dev_priv-psr.active !dev_priv-psr.busy_frontbuffer_bits)
schedule_delayed_work(dev_priv-psr.work,
-msecs_to_jiffies(100));
+msecs_to_jiffies(delay));
mutex_unlock(dev_priv-psr.lock);
}
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/15] drm/i915: VLV/CHV PSR debugfs.
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Rodrigo Vivi
Sent: Friday, November 14, 2014 10:23 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo
Subject: [Intel-gfx] [PATCH 14/15] drm/i915: VLV/CHV PSR debugfs.
Add debugfs support for Valleyview and Cherryview considering that
we have PSR per pipe and we don't have any kind of
performance counter as we have on other platforms that support PSR.
Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 319da61..d9b27f8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2126,6 +2126,8 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
struct drm_device *dev = node-minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
u32 psrperf = 0;
+ u32 stat[3];
+ enum pipe pipe;
bool enabled = false;
intel_runtime_pm_get(dev_priv);
@@ -2140,14 +2142,36 @@ static int i915_edp_psr_status(struct seq_file *m,
void *data)
seq_printf(m, Re-enable work scheduled: %s\n,
yesno(work_busy(dev_priv-psr.work.work)));
- enabled = HAS_PSR(dev)
- I915_READ(EDP_PSR_CTL(dev)) EDP_PSR_ENABLE;
- seq_printf(m, HW Enabled Active bit: %s\n, yesno(enabled));
+ if (HAS_PSR(dev)) {
+ if (HAS_DDI(dev))
+ enabled = I915_READ(EDP_PSR_CTL(dev)) EDP_PSR_ENABLE;
+ else {
+ for_each_pipe(dev_priv, pipe) {
+ stat[pipe] = I915_READ(VLV_PSRSTAT(pipe))
+ VLV_EDP_PSR_CURR_STATE_MASK;
+ if ((stat[pipe] == VLV_EDP_PSR_ACTIVE_NORFB_UP)
||
+ (stat[pipe] ==
VLV_EDP_PSR_ACTIVE_SF_UPDATE))
+ enabled = true;
+ }
+ }
+ }
Reviewed-by: Durgadoss R durgados...@intel.com
Thanks,
Durga
+ seq_printf(m, HW Enabled Active bit: %s, yesno(enabled));
- if (HAS_PSR(dev))
+ if (!HAS_DDI(dev))
+ for_each_pipe(dev_priv, pipe) {
+ if ((stat[pipe] == VLV_EDP_PSR_ACTIVE_NORFB_UP) ||
+ (stat[pipe] == VLV_EDP_PSR_ACTIVE_SF_UPDATE))
+ seq_printf(m, pipe %c, pipe_name(pipe));
+ }
+ seq_puts(m, \n);
+
+ /* CHV PSR has no kind of performance counter */
+ if (HAS_PSR(dev) HAS_DDI(dev)) {
psrperf = I915_READ(EDP_PSR_PERF_CNT(dev))
EDP_PSR_PERF_CNT_MASK;
- seq_printf(m, Performance_Counter: %u\n, psrperf);
+
+ seq_printf(m, Performance_Counter: %u\n, psrperf);
+ }
mutex_unlock(dev_priv-psr.lock);
intel_runtime_pm_put(dev_priv);
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't print header in error state for
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate BYT: pass/total=290/290-290/290 PNV: pass/total=362/362-362/362 ILK: pass/total=381/381-376/381 IVB: pass/total=522/559-522/559 SNB: pass/total=444/444-444/444 HSW: pass/total=525/525-523/525 BDW: pass/total=436/436-436/436 -Detailed- test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...-result_with_patch_applied(count, machine_id)... ILK: Intel_gpu_tools, igt_kms_flip_absolute-wf_vblank, DMESG_WARN(1, M26)PASS(3, M37M26) - DMESG_WARN(4, M26) ILK: Intel_gpu_tools, igt_kms_flip_blocking-absolute-wf_vblank-interruptible, DMESG_WARN(2, M26)PASS(2, M6M26) - DMESG_WARN(2, M26)PASS(2, M26) ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang, DMESG_WARN(2, M26)PASS(2, M37M26) - DMESG_WARN(2, M26)PASS(2, M26) ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, DMESG_WARN(1, M26)PASS(6, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_wf_vblank-ts-check, DMESG_WARN(1, M26)PASS(6, M37M26) - DMESG_WARN(2, M26)PASS(2, M26) HSW: Intel_gpu_tools, igt_gem_reset_stats_close-pending-fork-reverse-render, PASS(4, M19M20) - NO_RESULT(1, M20)PASS(3, M20) HSW: Intel_gpu_tools, igt_gem_reset_stats_reset-count-vebox, PASS(4, M19M20) - NO_RESULT(1, M20)PASS(3, M20) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Extend pcode mailbox interface
On Thu, Nov 13, 2014 at 06:50:10PM -0800, Tom.O'rou...@intel.com wrote:
From: Tom O'Rourke Tom.O'rou...@intel.com
In sandybridge_pcode_read and sandybridge_pcode_write,
extend the mbox parameter from u8 to u32.
On Haswell and Sandybridge, bits 7:0 encode the mailbox
command and bits 28:8 are used for address control for
specific commands.
Based on suggestion from Ville Syrjälä.
Signed-off-by: Tom O'Rourke Tom.O'rou...@intel.com
Not sure what we're going to do with this, but the spec does allow
passing some stuff in the high bits, so
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h |4 ++--
drivers/gpu/drm/i915/intel_pm.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3f3035c..4dea835 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2954,8 +2954,8 @@ void gen6_gt_force_wake_get(struct drm_i915_private
*dev_priv, int fw_engine);
void gen6_gt_force_wake_put(struct drm_i915_private *dev_priv, int
fw_engine);
void assert_force_wake_inactive(struct drm_i915_private *dev_priv);
-int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u8 mbox, u32
*val);
-int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u8 mbox, u32
val);
+int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
*val);
+int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32
val);
/* intel_sideband.c */
u32 vlv_punit_read(struct drm_i915_private *dev_priv, u8 addr);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9e87265..21faa92 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7154,7 +7154,7 @@ void intel_init_pm(struct drm_device *dev)
}
}
-int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u8 mbox, u32
*val)
+int sandybridge_pcode_read(struct drm_i915_private *dev_priv, u32 mbox, u32
*val)
{
WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
@@ -7180,7 +7180,7 @@ int sandybridge_pcode_read(struct drm_i915_private
*dev_priv, u8 mbox, u32 *val)
return 0;
}
-int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u8 mbox, u32
val)
+int sandybridge_pcode_write(struct drm_i915_private *dev_priv, u32 mbox, u32
val)
{
WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Bug fixes to ring 'head' updating
On 18/11/14 15:00, Deepak S wrote:
On Monday 03 November 2014 06:59 PM, Dave Gordon wrote:
Fixes to both the LRC and the legacy ringbuffer code to correctly
calculate and update the available space in a ring.
The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode, this is not
valid as the hardware is not necessarily executing the same context
that is being processed by the software. Thus reading the h/w HEAD
could put an unrelated (undefined, effectively random) value into
the s/w 'head' -- A Bad Thing for the free space calculations.
In addition, the old code could update a ringbuffer's 'head' value
from the 'last_retired_head' even when the latter hadn't been recently
updated and therefore had a value of -1; this would also confuse the
freespace calculations. Now, we consume 'last_retired_head' in just
one place, ensuring that this confusion does not arise.
Change-Id: Id7ce9096ed100a2882c68a54206f30b6c87e92fa
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c |5 ++-
drivers/gpu/drm/i915/intel_lrc.c| 36 ++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 53
---
drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
4 files changed, 48 insertions(+), 47 deletions(-)
[snip]
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index a8f72e8..1150862 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -52,16 +52,27 @@ intel_ring_initialized(struct intel_engine_cs *ring)
int __intel_ring_space(int head, int tail, int size)
{
-int space = head - (tail + I915_RING_FREE_SPACE);
-if (space 0)
+int space = head - tail;
+if (space = 0)
space += size;
-return space;
+return space - I915_RING_FREE_SPACE;
+}
+
+void intel_ring_update_space(struct intel_ringbuffer *ringbuf)
+{
+if (ringbuf-last_retired_head != -1) {
+ringbuf-head = ringbuf-last_retired_head;
+ringbuf-last_retired_head = -1;
+}
+
+ringbuf-space = __intel_ring_space(ringbuf-head HEAD_ADDR,
+ringbuf-tail, ringbuf-size);
}
int intel_ring_space(struct intel_ringbuffer *ringbuf)
{
-return __intel_ring_space(ringbuf-head HEAD_ADDR,
- ringbuf-tail, ringbuf-size);
+intel_ring_update_space(ringbuf);
+return ringbuf-space;
}
bool intel_ring_stopped(struct intel_engine_cs *ring)
@@ -73,7 +84,7 @@ bool intel_ring_stopped(struct intel_engine_cs *ring)
void __intel_ring_advance(struct intel_engine_cs *ring)
{
struct intel_ringbuffer *ringbuf = ring-buffer;
-ringbuf-tail = ringbuf-size - 1;
+intel_ring_advance(ring);
Should this be in another patch?
Other than this other changes looks fine to me.\
Also, are you planning to add WARN_ON if there is a mismatch with
ring_begin add_request?
Yes, that's another patch that I'll be sending out soon; it also checks
for various other mistakes in ring management.
Meanwhile I've decided to move the line above into that patch rather
than this one; also, I've refactored this patch to break out the two
sections that fix specific bugs in the LRC code, so I shall send out a
new version shortly.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Don't store panning coordinates as 16.16 fixed point
On Mon, Nov 17, 2014 at 06:10:38PM -0800, Matt Roper wrote:
When using the universal plane interface, the source rectangle
coordinates define the panning offset for the primary plane, which needs
to be stored in crtc-{x,y}. The original universal plane code
negelected to set these panning offset fields, which was partially
remedied in:
commit ccc759dc2a0214fd8b65ed4ebe78050874a67f94
Author: Gustavo Padovan gustavo.pado...@collabora.co.uk
Date: Wed Sep 24 14:20:22 2014 -0300
drm/i915: Merge of visible and !visible paths for primary planes
However the plane source coordinates are provided in 16.16 fixed point
format and the above commit forgot to convert back to integer
coordinates before saving the values. When we replace
intel_pipe_set_base() with plane-funcs-update_plane() in a future
patch, this bug becomes visible via the set_config entrypoint as well as
update_plane.
Cc: Gustavo Padovan gustavo.pado...@collabora.co.uk
Testcase: igt/kms_plane
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8dbc0e9..1c1886e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11668,8 +11668,8 @@ intel_commit_primary_plane(struct drm_plane *plane,
struct drm_rect *src = state-src;
crtc-primary-fb = fb;
- crtc-x = src-x1;
- crtc-y = src-y1;
+ crtc-x = src-x1 16;
+ crtc-y = src-y1 16;
Oh I had the notion that we shift these down during the check phase.
But I see we only do that for sprites. We should pick one approach
and use it for all planes. I suppose keeping to the 16.16 format is
the better option in anticipation of the day when we have planes
which can do sub-pixel panning.
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
intel_plane-crtc_x = state-orig_dst.x1;
intel_plane-crtc_y = state-orig_dst.y1;
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/3] drm/i915: Bug fixes to ring 'head' updating
Fixes to both the LRC and the legacy ringbuffer code to correctly calculate and update the available space in a ring. The logical ring code was updating the software ring 'head' value by reading the hardware 'HEAD' register. In LRC mode, this is not valid as the hardware is not necessarily executing the same context that is being processed by the software. Thus reading the h/w HEAD could put an unrelated (undefined, effectively random) value into the s/w 'head' -- A Bad Thing for the free space calculations. In addition, the old code could update a ringbuffer's 'head' value from the 'last_retired_head' even when the latter hadn't been recently updated and therefore had a value of -1; this would also confuse the freespace calculations. Now, we consume 'last_retired_head' in just one place, ensuring that this confusion does not arise. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915: Check for matching ringbuffer in logical_ring_wait_request()
The request queue is per-engine, and may therefore contain requests
from several different contexts/ringbuffers. In determining which
request to wait for, this function should only consider requests
from the ringbuffer that it's checking for space, and ignore any
that it finds that belong to other contexts.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2a1a719..1003b3a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -835,6 +835,16 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
}
list_for_each_entry(request, ring-request_list, list) {
+ /*
+* The request queue is per-engine, so can contain requests
+* from multiple ringbuffers. Here, we must ignore any that
+* aren't from the ringbuffer we're considering.
+*/
+ struct intel_context *ctx = request-ctx;
+ if (ctx-engine[ring-id].ringbuf != ringbuf)
+ continue;
+
+ /* Would completion of this request free enough space? */
if (__intel_ring_space(request-tail, ringbuf-tail,
ringbuf-size) = bytes) {
seqno = request-seqno;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/3] drm/i915: Consolidate ring freespace calculations
There are numerous places in the code where the driver's idea of
how much space is left in a ring is updated using the driver's
latest notions of the positions of 'head' and 'tail' for the ring.
Among them are some that update one or both of these values before
(re)doing the calculation. In particular, there are four different
places in the code where 'last_retired_head' is copied to 'head'
and then set to -1; and two of these do not have a guard to check
that it has actually been updated since last time it was consumed,
leaving the possibility that the dummy -1 can be transferred from
'last_retired_head' to 'head', causing the space calculation to
produce 'impossible' results (previously seen on Android/VLV).
This code therefore consolidates all the calculation and updating of
these values, such that there is only one place where the ring space
is updated, and it ALWAYS uses (and consumes) 'last_retired_head' if
(and ONLY if) it has been updated since the last call.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c |5 ++-
drivers/gpu/drm/i915/intel_lrc.c| 25 +--
drivers/gpu/drm/i915/intel_ringbuffer.c | 51 ---
drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
4 files changed, 37 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5dc37f0..4a98399 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -154,11 +154,10 @@ void i915_kernel_lost_context(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_MODESET))
return;
+ ringbuf-last_retired_head = -1;
ringbuf-head = I915_READ_HEAD(ring) HEAD_ADDR;
ringbuf-tail = I915_READ_TAIL(ring) TAIL_ADDR;
- ringbuf-space = ringbuf-head - (ringbuf-tail + I915_RING_FREE_SPACE);
- if (ringbuf-space 0)
- ringbuf-space += ringbuf-size;
+ intel_ring_update_space(ringbuf);
if (!dev-primary-master)
return;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index ad31373..c9a5227 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -825,14 +825,8 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
u32 seqno = 0;
int ret;
- if (ringbuf-last_retired_head != -1) {
- ringbuf-head = ringbuf-last_retired_head;
- ringbuf-last_retired_head = -1;
-
- ringbuf-space = intel_ring_space(ringbuf);
- if (ringbuf-space = bytes)
- return 0;
- }
+ if (intel_ring_space(ringbuf) = bytes)
+ return 0;
list_for_each_entry(request, ring-request_list, list) {
/*
@@ -860,11 +854,8 @@ static int logical_ring_wait_request(struct
intel_ringbuffer *ringbuf,
return ret;
i915_gem_retire_requests_ring(ring);
- ringbuf-head = ringbuf-last_retired_head;
- ringbuf-last_retired_head = -1;
- ringbuf-space = intel_ring_space(ringbuf);
- return 0;
+ return intel_ring_space(ringbuf) = bytes ? 0 : -ENOSPC;
}
static int logical_ring_wait_for_space(struct intel_ringbuffer *ringbuf,
@@ -890,12 +881,10 @@ static int logical_ring_wait_for_space(struct
intel_ringbuffer *ringbuf,
* case by choosing an insanely large timeout. */
end = jiffies + 60 * HZ;
+ ret = 0;
do {
- ringbuf-space = intel_ring_space(ringbuf);
- if (ringbuf-space = bytes) {
- ret = 0;
+ if (intel_ring_space(ringbuf) = bytes)
break;
- }
msleep(1);
@@ -936,7 +925,7 @@ static int logical_ring_wrap_buffer(struct intel_ringbuffer
*ringbuf)
iowrite32(MI_NOOP, virt++);
ringbuf-tail = 0;
- ringbuf-space = intel_ring_space(ringbuf);
+ intel_ring_update_space(ringbuf);
return 0;
}
@@ -1777,8 +1766,8 @@ int intel_lr_context_deferred_create(struct intel_context
*ctx,
ringbuf-effective_size = ringbuf-size;
ringbuf-head = 0;
ringbuf-tail = 0;
- ringbuf-space = ringbuf-size;
ringbuf-last_retired_head = -1;
+ intel_ring_update_space(ringbuf);
/* TODO: For now we put this in the mappable region so that we can reuse
* the existing ringbuffer code which ioremaps it. When we start
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ae09258..a08ae65 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -52,16 +52,27 @@ intel_ring_initialized(struct intel_engine_cs *ring)
int __intel_ring_space(int head, int tail, int size)
{
- int space = head - (tail + I915_RING_FREE_SPACE);
- if
[Intel-gfx] [PATCH v2 2/3] drm/i915: Don't read 'HEAD' MMIO register in LRC mode
The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode, this is not
valid as the hardware is not necessarily executing the same context
that is being processed by the software. Thus reading the h/w HEAD
could put an unrelated (undefined, effectively random) value into
the s/w 'head' -- A Bad Thing for the free space calculations.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 1003b3a..ad31373 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -891,7 +891,6 @@ static int logical_ring_wait_for_space(struct
intel_ringbuffer *ringbuf,
end = jiffies + 60 * HZ;
do {
- ringbuf-head = I915_READ_HEAD(ring);
ringbuf-space = intel_ring_space(ringbuf);
if (ringbuf-space = bytes) {
ret = 0;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm: add helper to get crtc timings (v3)
On Tue, Nov 18, 2014 at 09:12:49AM -0800, Matt Roper wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
v3 (by Matt):
- Add missing kerneldoc (Daniel)
- Use drm_mode_copy() (Jani)
Cc: dri-de...@lists.freedesktop.org
Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/drm_crtc.c | 32 ++--
drivers/gpu/drm/i915/intel_display.c | 6 +++---
include/drm/drm_crtc.h | 2 ++
3 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 56737e7..be1a485 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2494,6 +2494,27 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
EXPORT_SYMBOL(drm_mode_set_config_internal);
/**
+ * drm_crtc_get_hv_timing - Fetches hdisplay/vdisplay for given mode
+ * @mode: mode to query
+ * @hdisplay: hdisplay value to fill in
+ * @vdisplay: vdisplay value to fill in
+ *
+ * The vdisplay value will be doubled if the specified mode is a stereo mode
of
+ * the appropriate layout.
+ */
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+ int *hdisplay, int *vdisplay)
+{
+ struct drm_display_mode adjusted;
+
+ drm_mode_copy(adjusted, mode);
+ drm_mode_stereo_double(adjusted);
Hmm. The mode may not have the crtc_ timings populated at all here, so
drm_mode_stereo_double() might just double some zeroes/garbage.
I don't recall anymore if I had some clever idea how to do this. I was
hoping we can avoid duplicating the stereo doubling logic in more than
once place, but maybe it's just easier to admit defeat?
I guess the options are:
1) duplciate some stereo doubling logic
2) populate the required crtc_ timings here as well
3) keep using drm_mode_set_crtcinfo() but remove the offending stuff
from the copied mode so that it doesn't interfere with the results
4) add more flags to drm_mode_set_crtcinfo() that prevent the offending
stuff from affecting the results
+ *hdisplay = adjusted.crtc_hdisplay;
+ *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
+/**
* drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
* CRTC viewport
* @crtc: CRTC that framebuffer will be displayed on
@@ -2510,16 +2531,7 @@ int drm_crtc_check_viewport(const struct drm_crtc
*crtc,
{
int hdisplay, vdisplay;
- hdisplay = mode-hdisplay;
- vdisplay = mode-vdisplay;
-
- if (drm_mode_is_stereo(mode)) {
- struct drm_display_mode adjusted = *mode;
-
- drm_mode_set_crtcinfo(adjusted, CRTC_STEREO_DOUBLE);
- hdisplay = adjusted.crtc_hdisplay;
- vdisplay = adjusted.crtc_vdisplay;
- }
+ drm_crtc_get_hv_timing(mode, hdisplay, vdisplay);
if (crtc-invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 320bf4c..a967623 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
* computation to clearly distinguish it from the adjusted mode, which
* can be changed by the connectors in the below retry loop.
*/
- drm_mode_set_crtcinfo(pipe_config-requested_mode, CRTC_STEREO_DOUBLE);
- pipe_config-pipe_src_w = pipe_config-requested_mode.crtc_hdisplay;
- pipe_config-pipe_src_h = pipe_config-requested_mode.crtc_vdisplay;
+ drm_crtc_get_hv_timing(pipe_config-requested_mode,
+pipe_config-pipe_src_w,
+pipe_config-pipe_src_h);
encoder_retry:
/* Ensure the port clock defaults are reset when retrying. */
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 7b28ab0..23236f6 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1138,6 +1138,8 @@ extern int drm_plane_init(struct drm_device *dev,
extern void drm_plane_cleanup(struct drm_plane *plane);
extern unsigned int drm_plane_index(struct drm_plane *plane);
extern void drm_plane_force_disable(struct drm_plane *plane);
+extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+int *hdisplay, int *vdisplay);
extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
int x, int y,
const struct drm_display_mode *mode,
--
1.8.5.1
Re: [Intel-gfx] [PATCH 5/5] drm/i915: remove intel_pipe_set_base() (v3)
On Mon, Nov 17, 2014 at 06:10:39PM -0800, Matt Roper wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
After some refactor intel_primary_plane_setplane() does the same
as intel_pipe_set_base() so we can get rid of it and replace the calls
with intel_primary_plane_setplane().
v2: take Ville's comments:
- get the right arguments for update_plane()
- use drm_crtc_get_hv_timing()
v3 (by Matt):
- Rebase to latest di-nightly codebase
- Use primary-funcs-update_plane() in __intel_set_mode()
- Use primary-funcs-disable_plane() in intel_crtc_disable()
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 124
---
1 file changed, 27 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1c1886e..968ef0b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2890,71 +2890,6 @@ static void intel_update_pipe_size(struct intel_crtc
*crtc)
crtc-config.pipe_src_h = adjusted_mode-crtc_vdisplay;
}
-static int
-intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *fb)
-{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc-pipe;
- struct drm_framebuffer *old_fb = crtc-primary-fb;
- struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
- int ret;
-
- if (intel_crtc_has_pending_flip(crtc)) {
- DRM_ERROR(pipe is still busy with an old pageflip\n);
- return -EBUSY;
- }
-
- /* no fb bound */
- if (!fb) {
- DRM_ERROR(No FB bound\n);
- return 0;
- }
-
- if (intel_crtc-plane INTEL_INFO(dev)-num_pipes) {
- DRM_ERROR(no plane for crtc: plane %c, num_pipes %d\n,
- plane_name(intel_crtc-plane),
- INTEL_INFO(dev)-num_pipes);
- return -EINVAL;
- }
-
- mutex_lock(dev-struct_mutex);
- ret = intel_pin_and_fence_fb_obj(crtc-primary, fb, NULL);
- if (ret == 0)
- i915_gem_track_fb(old_obj, intel_fb_obj(fb),
- INTEL_FRONTBUFFER_PRIMARY(pipe));
- mutex_unlock(dev-struct_mutex);
- if (ret != 0) {
- DRM_ERROR(pin fence failed\n);
- return ret;
- }
-
- dev_priv-display.update_primary_plane(crtc, fb, x, y);
-
- if (intel_crtc-active)
- intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
-
- crtc-primary-fb = fb;
- crtc-x = x;
- crtc-y = y;
-
- if (old_fb) {
- if (intel_crtc-active old_fb != fb)
- intel_wait_for_vblank(dev, intel_crtc-pipe);
- mutex_lock(dev-struct_mutex);
- intel_unpin_fb_obj(old_obj);
- mutex_unlock(dev-struct_mutex);
- }
-
- mutex_lock(dev-struct_mutex);
- intel_update_fbc(dev);
- mutex_unlock(dev-struct_mutex);
-
- return 0;
-}
-
static void intel_fdi_normal_train(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
@@ -5267,8 +5202,6 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
struct drm_device *dev = crtc-dev;
struct drm_connector *connector;
struct drm_i915_private *dev_priv = dev-dev_private;
- struct drm_i915_gem_object *old_obj = intel_fb_obj(crtc-primary-fb);
- enum pipe pipe = to_intel_crtc(crtc)-pipe;
/* crtc should still be enabled when we disable it. */
WARN_ON(!crtc-enabled);
@@ -5277,14 +5210,7 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
intel_crtc_update_sarea(crtc, false);
dev_priv-display.off(crtc);
- if (crtc-primary-fb) {
- mutex_lock(dev-struct_mutex);
- intel_unpin_fb_obj(old_obj);
- i915_gem_track_fb(old_obj, NULL,
- INTEL_FRONTBUFFER_PRIMARY(pipe));
- mutex_unlock(dev-struct_mutex);
- crtc-primary-fb = NULL;
- }
+ crtc-primary-funcs-disable_plane(crtc-primary);
/* Update computed state. */
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
@@ -9578,6 +9504,8 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *old_fb = crtc-primary-fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_plane *primary = crtc-primary;
+ struct intel_plane *intel_plane = to_intel_plane(primary);
enum pipe pipe = intel_crtc-pipe;
struct intel_unpin_work *work;
struct intel_engine_cs
Re: [Intel-gfx] Macbook Air 6, 2: i915-related interrupt storm after Yosemite update
On 2014-11-03 16:25, Daniel Vetter wrote:
On Sat, Nov 01, 2014 at 06:08:00PM +0100, Christian Kastner wrote:
[after upgrading dual-booted OSX to Yosemite, wich included firmware updates]
Here's what I see [in Linux 3.16, 3.17]:
$ GPE=/sys/firmware/acpi/interrupts/gpe66
$ while true; do cat $GPE; sleep 1; done
727268 enabled
757981 enabled
788576 enabled
807337 enabled
828426 enabled
...
When I boot with modprobe.blacklist=i915, the issue disappears.
Does anyone have an idea what could be going on?
The only acpi interrupt we're handling is asle afaik, so sounds like
something we do in there doesn't please the new firmware and sends it into
a tailspin. So I'd sprinkle printks all over the place there until you
know what exactly goes on in i915, starting with the asle functions.
In the meantime, I noticed that there a kernel bugzilla bug entry for
this issue.
https://bugzilla.kernel.org/show_bug.cgi?id=85881
It has been closed in the meantime, although AFAIUI it the solution
merely forces disabling gpe66.
I'd still like try resolving this by determining the cause. Before I
embark on an unguided printk spree: does this analysis from the bugzilla
bug perhaps somewhat narrow the issue down so that I can focus on a
specific part?
Comment #31 from Lv Zheng lv.zh...@intel.com
The decompiled GPE 0x66 handler is as follows:
Method (_L66, 0, NotSerialized) // _Lxx: Level-Triggered GPE
{
If (LAnd (\_SB.PCI0.IGPU.GSSE, LNot (GSMI)))
{
\_SB.PCI0.IGPU.GSCI ()
}
Else
{
Store (0x00, \_SB.PCI0.IGPU.GEFC)
Store (0x01, SCIS) /* \SCIS */
Store (0x00, \_SB.PCI0.IGPU.GSSE)
Store (0x00, \_SB.PCI0.IGPU.SCIE)
}
}
It's completely GPU related. So I have no idea what has happened.
The GSMI seems to be some configuration option in the BIOS:
OperationRegion (GNVS, SystemMemory, 0x8CD3EA90, 0x026D)
Field (GNVS, AnyAcc, Lock, Preserve)
{
GSMI, 8,
}
It sounds like something was originally handled by SMI and now is reported
through GPE. So I guess there might be chances you could revert back to the
original behavior using some BIOS configuration.
[note: TTBOMK no such low-level configuration is possible]
Christian
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: add turbo boost trace point
Might be helpful for debugging places where userspace ends up boosting
or waiting where it doesn't intend to.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
drivers/gpu/drm/i915/i915_trace.h | 15 +++
drivers/gpu/drm/i915/intel_pm.c | 9 +++--
3 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 86cf428..b03cb07 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4209,8 +4209,10 @@ i915_gem_object_ggtt_unpin(struct drm_i915_gem_object
*obj)
struct i915_vma *vma = i915_gem_obj_to_ggtt(obj);
BUG_ON(!vma);
- BUG_ON(vma-pin_count == 0);
- BUG_ON(!i915_gem_obj_ggtt_bound(obj));
+ if (WARN(vma-pin_count == 0, bad pin count\n))
+ return;
+ if (WARN(!i915_gem_obj_ggtt_bound(obj), obj not bound\n))
+ return;
if (--vma-pin_count == 0)
obj-pin_mappable = false;
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 751d4ad..d710fe1 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -691,6 +691,21 @@ TRACE_EVENT(switch_mm,
__entry-dev, __entry-ring, __entry-to, __entry-vm)
);
+TRACE_EVENT(turbo_boost,
+ TP_PROTO(u32 freq),
+ TP_ARGS(freq),
+
+ TP_STRUCT__entry(
+ __field(u32, freq)
+ ),
+
+ TP_fast_assign(
+ __entry-freq = freq;
+ ),
+
+ TP_printk(turbo boost to %d MHz, __entry-freq)
+);
+
#endif /* _I915_TRACE_H_ */
/* This part must be outside protection */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7558ba2..2944593 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4483,10 +4483,15 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv)
mutex_lock(dev_priv-rps.hw_lock);
if (dev_priv-rps.enabled) {
- if (IS_VALLEYVIEW(dev))
+ if (IS_VALLEYVIEW(dev)) {
valleyview_set_rps(dev_priv-dev,
dev_priv-rps.max_freq_softlimit);
- else
+ trace_turbo_boost(vlv_gpu_freq(dev_priv,
+
dev_priv-rps.max_freq_softlimit));
+ } else {
gen6_set_rps(dev_priv-dev,
dev_priv-rps.max_freq_softlimit);
+ trace_turbo_boost(dev_priv-rps.max_freq_softlimit *
50);
+ }
+
dev_priv-rps.last_adj = 0;
}
mutex_unlock(dev_priv-rps.hw_lock);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: remove intel_pipe_set_base() (v3)
On Mon, 17 Nov 2014 18:10:39 -0800
Matt Roper matthew.d.ro...@intel.com wrote:
-static int
-intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *fb)
-{
I'm gonna miss this old function... But on the plus side I won't
confuse pipe_set_base and set_pipe_base anymore, always got that wrong
when searching.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace
Thanks Jesse for the ack. Unfortunately I just learned from Stéphane that there are certain devices which only support 256 levels, so this patch would do us no good at solving the real issue for such devices. Why can't we just use a dynamic 1:1 mapping as was suggested before? I would vote for that instead. U. Artie -Original Message- From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] Sent: Tuesday, November 18, 2014 9:23 AM To: Eoff, Ullysses A Cc: intel-gfx@lists.freedesktop.org; Jani Nikula Subject: Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace On Tue, 11 Nov 2014 12:30:38 -0800 U. Artie Eoff ullysses.a.e...@intel.com wrote: A userspace brightness range that is larger than the hardware brightness range does not have a 1:1 mapping and can result in brightness != actual_brightness for some values. Expose a fixed brightness range of [0..1000] to userspace so that all values can map 1:1 into the hardware brightness range. This would assume that the hardware range is always greater than 1000, otherwise we're right back to the original issue. This patch is based on Jani Nikula's proposed change in the referenced ML thread, except use the range [0..1000] instead; which was recommended by Jesse Barnes for smoother backlight transitions. Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-November/055221.html Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com --- drivers/gpu/drm/i915/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 4d63839..f74f5f2 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1057,7 +1057,7 @@ static int intel_backlight_device_register(struct intel_connector *connector) * Note: Everything should work even if the backlight device max * presented to the userspace is arbitrarily chosen. */ - props.max_brightness = panel-backlight.max; + props.max_brightness = 1000; props.brightness = scale_hw_to_user(connector, panel-backlight.level, props.max_brightness); Yeah looks ok to me. I guess Jani has to ack it too. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace
-Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Eoff, Ullysses A Sent: Tuesday, November 18, 2014 3:19 PM To: Jani Nikula; Jesse Barnes Cc: stephane.marche...@gmail.com; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace Thanks Jesse for the ack. Unfortunately I just learned from Stéphane that there are certain devices which only support 256 levels, so this patch would do us no good at solving the real issue for such devices. Why can't we just use a dynamic 1:1 mapping as was suggested before? I would vote for that instead. U. Artie In all fairness, I guess Jesse did elude to the fact that there would be such devices in the previous thread: http://lists.freedesktop.org/archives/intel-gfx/2014-November/055221.html I don't see why we shouldn't just expose the full 1:1 range to userspace. And let userspace decide what level stepping makes sense for providing smooth backlight level transitions to the end-user if necessary. --U. Artie -Original Message- From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] Sent: Tuesday, November 18, 2014 9:23 AM To: Eoff, Ullysses A Cc: intel-gfx@lists.freedesktop.org; Jani Nikula Subject: Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace On Tue, 11 Nov 2014 12:30:38 -0800 U. Artie Eoff ullysses.a.e...@intel.com wrote: A userspace brightness range that is larger than the hardware brightness range does not have a 1:1 mapping and can result in brightness != actual_brightness for some values. Expose a fixed brightness range of [0..1000] to userspace so that all values can map 1:1 into the hardware brightness range. This would assume that the hardware range is always greater than 1000, otherwise we're right back to the original issue. This patch is based on Jani Nikula's proposed change in the referenced ML thread, except use the range [0..1000] instead; which was recommended by Jesse Barnes for smoother backlight transitions. Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-November/055221.html Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com --- drivers/gpu/drm/i915/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 4d63839..f74f5f2 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1057,7 +1057,7 @@ static int intel_backlight_device_register(struct intel_connector *connector) * Note: Everything should work even if the backlight device max * presented to the userspace is arbitrarily chosen. */ - props.max_brightness = panel-backlight.max; + props.max_brightness = 1000; props.brightness = scale_hw_to_user(connector, panel-backlight.level, props.max_brightness); Yeah looks ok to me. I guess Jani has to ack it too. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace
On Tue, Nov 18, 2014 at 3:18 PM, Eoff, Ullysses A ullysses.a.e...@intel.com wrote: Thanks Jesse for the ack. Unfortunately I just learned from Stéphane that there are certain devices which only support 256 levels, so this patch would do us no good at solving the real issue for such devices. Why can't we just use a dynamic 1:1 mapping as was suggested before? I would vote for that instead. Right, from my (consumer's) perspective, a 1:1 mapping is simpler. But the confusing part for me is that (as far as I can see) the current mapping should be 1:1 (because the user and hw ranges are the same), even though it goes through the scale logic. Is the scale() function maybe not the identity? If it isn't, maybe we just need to make it so... Stéphane U. Artie -Original Message- From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] Sent: Tuesday, November 18, 2014 9:23 AM To: Eoff, Ullysses A Cc: intel-gfx@lists.freedesktop.org; Jani Nikula Subject: Re: [Intel-gfx] [PATCH] drm/i915: expose a fixed brightness range to userspace On Tue, 11 Nov 2014 12:30:38 -0800 U. Artie Eoff ullysses.a.e...@intel.com wrote: A userspace brightness range that is larger than the hardware brightness range does not have a 1:1 mapping and can result in brightness != actual_brightness for some values. Expose a fixed brightness range of [0..1000] to userspace so that all values can map 1:1 into the hardware brightness range. This would assume that the hardware range is always greater than 1000, otherwise we're right back to the original issue. This patch is based on Jani Nikula's proposed change in the referenced ML thread, except use the range [0..1000] instead; which was recommended by Jesse Barnes for smoother backlight transitions. Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-November/055221.html Signed-off-by: U. Artie Eoff ullysses.a.e...@intel.com --- drivers/gpu/drm/i915/intel_panel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 4d63839..f74f5f2 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1057,7 +1057,7 @@ static int intel_backlight_device_register(struct intel_connector *connector) * Note: Everything should work even if the backlight device max * presented to the userspace is arbitrarily chosen. */ - props.max_brightness = panel-backlight.max; + props.max_brightness = 1000; props.brightness = scale_hw_to_user(connector, panel-backlight.level, props.max_brightness); Yeah looks ok to me. I guess Jani has to ack it too. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/ddi: set has_infoframe flag on DDI too
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate BYT: pass/total=290/290-290/290 PNV: pass/total=362/362-362/362 ILK: pass/total=381/381-381/381 IVB: pass/total=522/559-522/559 SNB: pass/total=444/444-444/444 HSW: pass/total=595/595-595/595 BDW: pass/total=436/436-435/436 -Detailed- test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...-result_with_patch_applied(count, machine_id)... BDW: Intel_gpu_tools, igt_gem_reset_stats_close-pending-ctx-render, PASS(4, M28) - FAIL(1, M28)PASS(3, M28) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm: add helper to get crtc timings (v4)
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
v3 (by Matt):
- Add missing kerneldoc (Daniel)
- Use drm_mode_copy() (Jani)
v4 (by Matt):
- Drop stereo doubling function again; add 'stereo only' flag
to drm_mode_set_crtcinfo() instead (Ville)
Cc: dri-de...@lists.freedesktop.org
Suggested-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/drm_crtc.c | 32 ++--
drivers/gpu/drm/drm_modes.c | 24 ++--
drivers/gpu/drm/i915/intel_display.c | 6 +++---
include/drm/drm_crtc.h | 2 ++
include/drm/drm_modes.h | 3 +++
5 files changed, 44 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 56737e7..6202611 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2494,6 +2494,27 @@ int drm_mode_set_config_internal(struct drm_mode_set
*set)
EXPORT_SYMBOL(drm_mode_set_config_internal);
/**
+ * drm_crtc_get_hv_timing - Fetches hdisplay/vdisplay for given mode
+ * @mode: mode to query
+ * @hdisplay: hdisplay value to fill in
+ * @vdisplay: vdisplay value to fill in
+ *
+ * The vdisplay value will be doubled if the specified mode is a stereo mode of
+ * the appropriate layout.
+ */
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+ int *hdisplay, int *vdisplay)
+{
+ struct drm_display_mode adjusted;
+
+ drm_mode_copy(adjusted, mode);
+ drm_mode_set_crtcinfo(adjusted, CRTC_STEREO_DOUBLE_ONLY);
+ *hdisplay = adjusted.crtc_hdisplay;
+ *vdisplay = adjusted.crtc_vdisplay;
+}
+EXPORT_SYMBOL(drm_crtc_get_hv_timing);
+
+/**
* drm_crtc_check_viewport - Checks that a framebuffer is big enough for the
* CRTC viewport
* @crtc: CRTC that framebuffer will be displayed on
@@ -2510,16 +2531,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
{
int hdisplay, vdisplay;
- hdisplay = mode-hdisplay;
- vdisplay = mode-vdisplay;
-
- if (drm_mode_is_stereo(mode)) {
- struct drm_display_mode adjusted = *mode;
-
- drm_mode_set_crtcinfo(adjusted, CRTC_STEREO_DOUBLE);
- hdisplay = adjusted.crtc_hdisplay;
- vdisplay = adjusted.crtc_vdisplay;
- }
+ drm_crtc_get_hv_timing(mode, hdisplay, vdisplay);
if (crtc-invert_dimensions)
swap(hdisplay, vdisplay);
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 6d8b941..fd5479b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -765,18 +765,22 @@ void drm_mode_set_crtcinfo(struct drm_display_mode *p,
int adjust_flags)
}
}
- if (p-flags DRM_MODE_FLAG_DBLSCAN) {
- p-crtc_vdisplay *= 2;
- p-crtc_vsync_start *= 2;
- p-crtc_vsync_end *= 2;
- p-crtc_vtotal *= 2;
+ if (!(adjust_flags CRTC_NO_DBLSCAN)) {
+ if (p-flags DRM_MODE_FLAG_DBLSCAN) {
+ p-crtc_vdisplay *= 2;
+ p-crtc_vsync_start *= 2;
+ p-crtc_vsync_end *= 2;
+ p-crtc_vtotal *= 2;
+ }
}
- if (p-vscan 1) {
- p-crtc_vdisplay *= p-vscan;
- p-crtc_vsync_start *= p-vscan;
- p-crtc_vsync_end *= p-vscan;
- p-crtc_vtotal *= p-vscan;
+ if (!(adjust_flags CRTC_NO_VSCAN)) {
+ if (p-vscan 1) {
+ p-crtc_vdisplay *= p-vscan;
+ p-crtc_vsync_start *= p-vscan;
+ p-crtc_vsync_end *= p-vscan;
+ p-crtc_vtotal *= p-vscan;
+ }
}
if (adjust_flags CRTC_STEREO_DOUBLE) {
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 320bf4c..a967623 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10158,9 +10158,9 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
* computation to clearly distinguish it from the adjusted mode, which
* can be changed by the connectors in the below retry loop.
*/
- drm_mode_set_crtcinfo(pipe_config-requested_mode, CRTC_STEREO_DOUBLE);
- pipe_config-pipe_src_w = pipe_config-requested_mode.crtc_hdisplay;
- pipe_config-pipe_src_h = pipe_config-requested_mode.crtc_vdisplay;
+ drm_crtc_get_hv_timing(pipe_config-requested_mode,
+ pipe_config-pipe_src_w,
+ pipe_config-pipe_src_h);
encoder_retry:
/*
[Intel-gfx] [PATCH 5/5] drm/i915: Introduce intel_prepare_cursor_plane()
Primary and sprite planes have already been refactored to include a
'prepare' step which handles all the commit-time operations that could
fail (i.e., pinning buffers and such). Refactor the cursor commit in a
similar manner.
For simplicity and consistency with other plane types, we also switch to
using intel_pin_and_fence_fb_obj() to perform our pinning for
non-physical cursors. This will allow us to more easily migrate the
code into the atomic 'begin' handler in a plane-agnostic manner in a
future patchset.
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 114 ++-
1 file changed, 44 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3482946..a0247e7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11850,19 +11850,51 @@ intel_check_cursor_plane(struct drm_plane *plane,
}
static int
+intel_prepare_cursor_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+ struct drm_device *dev = plane-dev;
+ struct drm_framebuffer *fb = state-fb;
+ struct intel_crtc *intel_crtc = to_intel_crtc(state-crtc);
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct drm_i915_gem_object *old_obj = intel_fb_obj(plane-fb);
+ enum pipe pipe = intel_crtc-pipe;
+ int ret = 0;
+
+ if (old_obj != obj) {
+ /* we only need to pin inside GTT if cursor is non-phy */
+ mutex_lock(dev-struct_mutex);
+ if (!INTEL_INFO(dev)-cursor_needs_physical) {
+ if (obj)
+ ret = intel_pin_and_fence_fb_obj(plane, fb,
NULL);
+ if (ret == 0)
+ i915_gem_track_fb(intel_crtc-cursor_bo, obj,
+
INTEL_FRONTBUFFER_CURSOR(pipe));
+ } else {
+ int align = IS_I830(dev) ? 16 * 1024 : 256;
+ if (obj)
+ ret = i915_gem_object_attach_phys(obj, align);
+ if (ret)
+ DRM_DEBUG_KMS(failed to attach phys object\n);
+ }
+ mutex_unlock(dev-struct_mutex);
+ }
+
+ return ret;
+}
+
+static void
intel_commit_cursor_plane(struct drm_plane *plane,
struct intel_plane_state *state)
{
struct drm_crtc *crtc = state-crtc;
struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_i915_gem_object *obj = intel_fb_obj(state-fb);
enum pipe pipe = intel_crtc-pipe;
unsigned old_width;
uint32_t addr;
- int ret;
crtc-cursor_x = state-orig_dst.x1;
crtc-cursor_y = state-orig_dst.y1;
@@ -11880,75 +11912,18 @@ intel_commit_cursor_plane(struct drm_plane *plane,
if (intel_crtc-cursor_bo == obj)
goto update;
- /* if we want to turn off the cursor ignore width and height */
- if (!obj) {
- DRM_DEBUG_KMS(cursor off\n);
+ if (!obj)
addr = 0;
- mutex_lock(dev-struct_mutex);
- goto finish;
- }
-
- /* we only need to pin inside GTT if cursor is non-phy */
- mutex_lock(dev-struct_mutex);
- if (!INTEL_INFO(dev)-cursor_needs_physical) {
- unsigned alignment;
-
- /*
-* Global gtt pte registers are special registers which actually
-* forward writes to a chunk of system memory. Which means that
-* there is no risk that the register values disappear as soon
-* as we call intel_runtime_pm_put(), so it is correct to wrap
-* only the pin/unpin/fence and not more.
-*/
- intel_runtime_pm_get(dev_priv);
-
- /* Note that the w/a also requires 2 PTE of padding following
-* the bo. We currently fill all unused PTE with the shadow
-* page and so we should always have valid PTE following the
-* cursor preventing the VT-d warning.
-*/
- alignment = 0;
- if (need_vtd_wa(dev))
- alignment = 64*1024;
-
- ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
- if (ret) {
- DRM_DEBUG_KMS(failed to move cursor bo into the
GTT\n);
- intel_runtime_pm_put(dev_priv);
- goto fail_locked;
- }
-
- ret = i915_gem_object_put_fence(obj);
- if (ret) {
-
[Intel-gfx] [PATCH 2/5] drm/i915: remove intel_crtc_cursor_set_obj() (v5)
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Merge it into the plane update_plane() callback and make other
users use the update_plane() functions instead.
The fb != crtc-cursor-fb was already inside intel_crtc_cursor_set_obj()
so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both paths into one.
v5 (by Matt):
- Rebase onto latest di-nightly codebase
- Drop extra unreference call when we fail to pin (Ville)
Reviewed-by(v4): Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 215 ---
1 file changed, 99 insertions(+), 116 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a967623..8dbc0e9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8364,109 +8364,6 @@ static bool cursor_size_ok(struct drm_device *dev,
return true;
}
-static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
-struct drm_i915_gem_object *obj,
-uint32_t width, uint32_t height)
-{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc-pipe;
- unsigned old_width;
- uint32_t addr;
- int ret;
-
- /* if we want to turn off the cursor ignore width and height */
- if (!obj) {
- DRM_DEBUG_KMS(cursor off\n);
- addr = 0;
- mutex_lock(dev-struct_mutex);
- goto finish;
- }
-
- /* we only need to pin inside GTT if cursor is non-phy */
- mutex_lock(dev-struct_mutex);
- if (!INTEL_INFO(dev)-cursor_needs_physical) {
- unsigned alignment;
-
- /*
-* Global gtt pte registers are special registers which actually
-* forward writes to a chunk of system memory. Which means that
-* there is no risk that the register values disappear as soon
-* as we call intel_runtime_pm_put(), so it is correct to wrap
-* only the pin/unpin/fence and not more.
-*/
- intel_runtime_pm_get(dev_priv);
-
- /* Note that the w/a also requires 2 PTE of padding following
-* the bo. We currently fill all unused PTE with the shadow
-* page and so we should always have valid PTE following the
-* cursor preventing the VT-d warning.
-*/
- alignment = 0;
- if (need_vtd_wa(dev))
- alignment = 64*1024;
-
- ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
- if (ret) {
- DRM_DEBUG_KMS(failed to move cursor bo into the
GTT\n);
- intel_runtime_pm_put(dev_priv);
- goto fail_locked;
- }
-
- ret = i915_gem_object_put_fence(obj);
- if (ret) {
- DRM_DEBUG_KMS(failed to release fence for cursor);
- intel_runtime_pm_put(dev_priv);
- goto fail_unpin;
- }
-
- addr = i915_gem_obj_ggtt_offset(obj);
-
- intel_runtime_pm_put(dev_priv);
- } else {
- int align = IS_I830(dev) ? 16 * 1024 : 256;
- ret = i915_gem_object_attach_phys(obj, align);
- if (ret) {
- DRM_DEBUG_KMS(failed to attach phys object\n);
- goto fail_locked;
- }
- addr = obj-phys_handle-busaddr;
- }
-
- finish:
- if (intel_crtc-cursor_bo) {
- if (!INTEL_INFO(dev)-cursor_needs_physical)
-
i915_gem_object_unpin_from_display_plane(intel_crtc-cursor_bo);
- }
-
- i915_gem_track_fb(intel_crtc-cursor_bo, obj,
- INTEL_FRONTBUFFER_CURSOR(pipe));
- mutex_unlock(dev-struct_mutex);
-
- old_width = intel_crtc-cursor_width;
-
- intel_crtc-cursor_addr = addr;
- intel_crtc-cursor_bo = obj;
- intel_crtc-cursor_width = width;
- intel_crtc-cursor_height = height;
-
- if (intel_crtc-active) {
- if (old_width != width)
- intel_update_watermarks(crtc);
- intel_crtc_update_cursor(crtc, intel_crtc-cursor_bo != NULL);
-
- intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
- }
-
- return 0;
-fail_unpin:
- i915_gem_object_unpin_from_display_plane(obj);
-fail_locked:
- mutex_unlock(dev-struct_mutex);
- return ret;
-}
-
static void
[Intel-gfx] [PATCH 0/5] i915 display refactoring (v2)
Another iteration of the i915 display refactoring work in preparation for atomic. The last patchset was posted here: http://lists.freedesktop.org/archives/intel-gfx/2014-November/055702.html This set incorporates the feedback from the last review and also adds an additional patch at the end to split the cursor commit code into separate prepare/commit steps (anything that can fail goes into commit). That split will help simplify the future patchset to convert i915 over to using the atomic plane helpers. Gustavo Padovan (3): drm: add helper to get crtc timings (v4) drm/i915: remove intel_crtc_cursor_set_obj() (v5) drm/i915: remove intel_pipe_set_base() (v4) Matt Roper (2): drm/i915: Don't store panning coordinates as 16.16 fixed point drm/i915: Introduce intel_prepare_cursor_plane() drivers/gpu/drm/drm_crtc.c | 32 ++-- drivers/gpu/drm/drm_modes.c | 24 +-- drivers/gpu/drm/i915/intel_display.c | 330 --- include/drm/drm_crtc.h | 2 + include/drm/drm_modes.h | 3 + 5 files changed, 148 insertions(+), 243 deletions(-) -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: remove intel_pipe_set_base() (v4)
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
After some refactor intel_primary_plane_setplane() does the same
as intel_pipe_set_base() so we can get rid of it and replace the calls
with intel_primary_plane_setplane().
v2: take Ville's comments:
- get the right arguments for update_plane()
- use drm_crtc_get_hv_timing()
v3 (by Matt):
- Rebase to latest di-nightly codebase
- Use primary-funcs-update_plane() in __intel_set_mode()
- Use primary-funcs-disable_plane() in intel_crtc_disable()
v4 (by Matt):
- Drop redundant calls to intel_crtc_wait_for_pending_flips() before
calling update_plane() (Ville)
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 129 ---
1 file changed, 28 insertions(+), 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1c1886e..3482946 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2890,71 +2890,6 @@ static void intel_update_pipe_size(struct intel_crtc
*crtc)
crtc-config.pipe_src_h = adjusted_mode-crtc_vdisplay;
}
-static int
-intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *fb)
-{
- struct drm_device *dev = crtc-dev;
- struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc-pipe;
- struct drm_framebuffer *old_fb = crtc-primary-fb;
- struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
- int ret;
-
- if (intel_crtc_has_pending_flip(crtc)) {
- DRM_ERROR(pipe is still busy with an old pageflip\n);
- return -EBUSY;
- }
-
- /* no fb bound */
- if (!fb) {
- DRM_ERROR(No FB bound\n);
- return 0;
- }
-
- if (intel_crtc-plane INTEL_INFO(dev)-num_pipes) {
- DRM_ERROR(no plane for crtc: plane %c, num_pipes %d\n,
- plane_name(intel_crtc-plane),
- INTEL_INFO(dev)-num_pipes);
- return -EINVAL;
- }
-
- mutex_lock(dev-struct_mutex);
- ret = intel_pin_and_fence_fb_obj(crtc-primary, fb, NULL);
- if (ret == 0)
- i915_gem_track_fb(old_obj, intel_fb_obj(fb),
- INTEL_FRONTBUFFER_PRIMARY(pipe));
- mutex_unlock(dev-struct_mutex);
- if (ret != 0) {
- DRM_ERROR(pin fence failed\n);
- return ret;
- }
-
- dev_priv-display.update_primary_plane(crtc, fb, x, y);
-
- if (intel_crtc-active)
- intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
-
- crtc-primary-fb = fb;
- crtc-x = x;
- crtc-y = y;
-
- if (old_fb) {
- if (intel_crtc-active old_fb != fb)
- intel_wait_for_vblank(dev, intel_crtc-pipe);
- mutex_lock(dev-struct_mutex);
- intel_unpin_fb_obj(old_obj);
- mutex_unlock(dev-struct_mutex);
- }
-
- mutex_lock(dev-struct_mutex);
- intel_update_fbc(dev);
- mutex_unlock(dev-struct_mutex);
-
- return 0;
-}
-
static void intel_fdi_normal_train(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
@@ -5267,8 +5202,6 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
struct drm_device *dev = crtc-dev;
struct drm_connector *connector;
struct drm_i915_private *dev_priv = dev-dev_private;
- struct drm_i915_gem_object *old_obj = intel_fb_obj(crtc-primary-fb);
- enum pipe pipe = to_intel_crtc(crtc)-pipe;
/* crtc should still be enabled when we disable it. */
WARN_ON(!crtc-enabled);
@@ -5277,14 +5210,7 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
intel_crtc_update_sarea(crtc, false);
dev_priv-display.off(crtc);
- if (crtc-primary-fb) {
- mutex_lock(dev-struct_mutex);
- intel_unpin_fb_obj(old_obj);
- i915_gem_track_fb(old_obj, NULL,
- INTEL_FRONTBUFFER_PRIMARY(pipe));
- mutex_unlock(dev-struct_mutex);
- crtc-primary-fb = NULL;
- }
+ crtc-primary-funcs-disable_plane(crtc-primary);
/* Update computed state. */
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
@@ -9578,6 +9504,8 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *old_fb = crtc-primary-fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_plane *primary = crtc-primary;
+ struct intel_plane *intel_plane = to_intel_plane(primary);
enum pipe pipe
Re: [Intel-gfx] [PATCH] drm/i915: add turbo boost trace point
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) -Summary- Platform: baseline_drm_intel_nightly_pass_rate-patch_applied_pass_rate BYT: pass/total=290/290-290/290 PNV: pass/total=362/362-362/362 ILK: pass/total=381/381-379/381 IVB: pass/total=522/559-522/559 SNB: pass/total=444/444-444/444 HSW: pass/total=595/595-595/595 BDW: pass/total=436/436-436/436 -Detailed- test_platform: test_suite, test_case, result_with_drm_intel_nightly(count, machine_id...)...-result_with_patch_applied(count, machine_id)... ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, DMESG_WARN(2, M26)PASS(2, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ILK: Intel_gpu_tools, igt_kms_flip_single-buffer-flip-vs-dpms-off-vs-modeset, DMESG_WARN(1, M26)PASS(3, M37M26) - DMESG_WARN(1, M26)PASS(3, M26) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
