[PATCH] drm/i915: Delete outdated comment in byt_pte_encode

[PATCH] drm/i915: Delete outdated comment in byt_pte_encode

[Daniel Vetter]

This has been invalidated in

commit 24f3a8cf7766e52a087904b4346794c7b410f957
Author: Akash Goel <akash.goel@intel.com>
Date:   Tue Jun 17 10:59:42 2014 +0530

    drm/i915: Added write-enable pte bit supportt

But despite that it's in the diff context no one noticed :(

Cc: Akash Goel <akash.goel@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4498a068a5a7..68a27b2d3654 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -164,9 +164,6 @@ static gen6_gtt_pte_t byt_pte_encode(dma_addr_t addr,
 	gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
 	pte |= GEN6_PTE_ADDR_ENCODE(addr);
 
-	/* Mark the page as writeable.  Other platforms don't have a
-	 * setting for read-only/writable, so this matches that behavior.
-	 */
 	if (!(flags & PTE_READ_ONLY))
 		pte |= BYT_PTE_WRITEABLE;
 
-- 
2.1.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Delete outdated comment in

[shuang.he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
-------------------------------------Summary-------------------------------------
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=291/291->290/291
PNV: pass/total=356/356->356/356
ILK: pass/total=372/372->365/372
IVB: pass/total=545/546->545/546
SNB: pass/total=380/380->379/380
HSW: pass/total=579/579->579/579
BDW: pass/total=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)...
BYT: Intel_gpu_tools, igt_gem_userptr_blits_forked-sync-swapping-multifd-mempressure-interruptible, PASS(4, M31M38) -> NO_RESULT(1, M38)PASS(3, M38)
ILK: Intel_gpu_tools, igt_kms_flip_bcs-wf_vblank-vs-dpms-interruptible, DMESG_WARN(3, M26)PASS(4, M26) -> DMESG_WARN(1, M26)PASS(3, M26)
ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-dpms-off-vs-modeset, DMESG_WARN(2, M26)PASS(2, M26) -> DMESG_WARN(2, M26)PASS(2, M26)
ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang, NSPT(1, M26)DMESG_WARN(1, M26)PASS(2, M26) -> DMESG_WARN(1, M26)PASS(3, M26)
ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(6, M26) -> DMESG_WARN(1, M26)PASS(3, M26)
ILK: Intel_gpu_tools, igt_kms_flip_nonexisting-fb-interruptible, DMESG_WARN(1, M26)PASS(3, M26) -> DMESG_WARN(2, M26)PASS(2, M26)
ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-ts-check-interruptible, DMESG_WARN(1, M26)PASS(3, M26) -> DMESG_WARN(2, M26)PASS(2, M26)
ILK: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, FAIL(3, M26)DMESG_FAIL(1, M26)TIMEOUT(17, M37M6M26)PASS(1, M26) -> TIMEOUT(1, M26)PASS(3, M26)
IVB: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(7, M21M34M4)PASS(12, M34M21M4) -> NSPT(1, M34)PASS(3, M34)
IVB: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(18, M34M21M4)PASS(1, M21) -> TIMEOUT(1, M34)PASS(3, M34)
SNB: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(18, M35M22)PASS(1, M35) -> TIMEOUT(1, M22)PASS(3, M22)
BDW: Intel_gpu_tools, igt_gem_reset_stats_ban-bsd, DMESG_WARN(1, M28)PASS(18, M42M30M28) -> PASS(4, M28)
BDW: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(18, M42M30M28)PASS(1, M28) -> TIMEOUT(1, M28)PASS(3, M28)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Delete outdated comment in

[Damien Lespiau]

Hi,

This is a great example that shows that either some tests or the testing
methodology are not quite right and need a few more iterations.

This patch just removes a comment, so the ideal case is no delta in the
test results. Two things that may help improving the situation.

  1/ Some tests may be unreliable. It's be great to have a way to mark
  them as such and display that state in the results so we don't worry
  too much if an unreliable test fails. I think the test itself is a
  great place to store that information.

  2/ The reference against which this delta is taken seems not
  completely up to date, otherwise we would have fewer failing cases?

Some other remarks:

- I don't actually understand some of the delta shown:

  IVB: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(7, M21M34M4)PASS(12, M34M21M4) -> NSPT(1, M34)PASS(3, M34)

  going from NPST to NSPT, which is that line shown? IVB shows
  pass/total=545/546->545/546 and yet we have two IVB lines in the
  details

- What does 'count' means in the results below?

- The results are somewhat hard to read and would benefit from a bit
  more formatting, even if just alignment of columns.

- You're missing the In-reply-to header in your answers which breaks
  mail threading

- It'd be great to have public links with logs to inspect the failure
  cases.

Thanks!

-- 
Damien

On Wed, Nov 12, 2014 at 11:21:35PM -0800, shuang.he@intel.com wrote:
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
> -------------------------------------Summary-------------------------------------
> Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
> BYT: pass/total=291/291->290/291
> PNV: pass/total=356/356->356/356
> ILK: pass/total=372/372->365/372
> IVB: pass/total=545/546->545/546
> SNB: pass/total=380/380->379/380
> HSW: pass/total=579/579->579/579
> BDW: pass/total=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)...
> BYT: Intel_gpu_tools, igt_gem_userptr_blits_forked-sync-swapping-multifd-mempressure-interruptible, PASS(4, M31M38) -> NO_RESULT(1, M38)PASS(3, M38)
> ILK: Intel_gpu_tools, igt_kms_flip_bcs-wf_vblank-vs-dpms-interruptible, DMESG_WARN(3, M26)PASS(4, M26) -> DMESG_WARN(1, M26)PASS(3, M26)
> ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-dpms-off-vs-modeset, DMESG_WARN(2, M26)PASS(2, M26) -> DMESG_WARN(2, M26)PASS(2, M26)
> ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang, NSPT(1, M26)DMESG_WARN(1, M26)PASS(2, M26) -> DMESG_WARN(1, M26)PASS(3, M26)
> ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible, DMESG_WARN(1, M26)PASS(6, M26) -> DMESG_WARN(1, M26)PASS(3, M26)
> ILK: Intel_gpu_tools, igt_kms_flip_nonexisting-fb-interruptible, DMESG_WARN(1, M26)PASS(3, M26) -> DMESG_WARN(2, M26)PASS(2, M26)
> ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-ts-check-interruptible, DMESG_WARN(1, M26)PASS(3, M26) -> DMESG_WARN(2, M26)PASS(2, M26)
> ILK: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, FAIL(3, M26)DMESG_FAIL(1, M26)TIMEOUT(17, M37M6M26)PASS(1, M26) -> TIMEOUT(1, M26)PASS(3, M26)
> IVB: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(7, M21M34M4)PASS(12, M34M21M4) -> NSPT(1, M34)PASS(3, M34)
> IVB: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(18, M34M21M4)PASS(1, M21) -> TIMEOUT(1, M34)PASS(3, M34)
> SNB: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(18, M35M22)PASS(1, M35) -> TIMEOUT(1, M22)PASS(3, M22)
> BDW: Intel_gpu_tools, igt_gem_reset_stats_ban-bsd, DMESG_WARN(1, M28)PASS(18, M42M30M28) -> PASS(4, M28)
> BDW: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, TIMEOUT(18, M42M30M28)PASS(1, M28) -> TIMEOUT(1, M28)PASS(3, M28)
> _______________________________________________
> 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: [PATCH] drm/i915: Delete outdated comment in

[He, Shuang]

> -----Original Message-----
> From: Lespiau, Damien
> Sent: Thursday, November 13, 2014 8:28 PM
> To: He, Shuang
> Cc: intel-gfx@lists.freedesktop.org; daniel.vetter@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Delete outdated comment in
> 
> Hi,
> 
> This is a great example that shows that either some tests or the testing
> methodology are not quite right and need a few more iterations.
[He, Shuang] Thanks for your great feedback. Actually I'm also curious why no one is asking how the result is formatted (I thought engineers are concentrating on codes only:)). It definitely need improvement.

> 
> This patch just removes a comment, so the ideal case is no delta in the
> test results. Two things that may help improving the situation.
> 
>   1/ Some tests may be unreliable. It's be great to have a way to mark
>   them as such and display that state in the results so we don't worry
>   too much if an unreliable test fails. I think the test itself is a
>   great place to store that information.
[He, Shuang] We have already tried our best to remove as many unreliable tests as possible. Actually my query will only select pass many times in the recent testing, and no fail result in recent testing. But still no luck, we still have kind of noise there. Yi and one of our GB has spent great effort recently to have known unstable tests blacklisted, while combine those works together there is still unreliable test case show randomly. And actually these unreliable tests greatly impact bisection efficiency. That's one of major reason that PRTS is now using that blacklist as nightly does (PRTS used to run all test cases).

> 
>   2/ The reference against which this delta is taken seems not
>   completely up to date, otherwise we would have fewer failing cases?
[He, Shuang] The only thing I can guarantee is baseline results are based on the same kernel commit, while it might run on a different hardware. In our design, our script will re-run diff results (patched result compared with baseline result) on same test machine (the machine your patch is tested).

> 
> Some other remarks:
> 
> - I don't actually understand some of the delta shown:
> 
>   IVB: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(7,
> M21M34M4)PASS(12, M34M21M4) -> NSPT(1, M34)PASS(3, M34)
> 
>   going from NPST to NSPT, which is that line shown? IVB shows
>   pass/total=545/546->545/546 and yet we have two IVB lines in the
>   details
[He, Shuang] 545/546->546/546 simply means the pass rate doesn't change, while in some cases that result changed while keep the passrate unchanged. For example, 1 case change from PASS to NSPT, while another case changed from NSPT to PASS, you will see the passrate doesn't change. But the truth is there is some change happened, and we have to let you know about it. And for NSPT->NSPT as you noticed, is actually have sometime passed and sometime NSPT with baseline kernel, and it also sometime get NSPT and sometime get PASS with patched kernel. Before we have one solid way to tell if one test case is really unreliable in an automatically, telling you the truth we have is the best we can do right now.

> 
> - What does 'count' means in the results below?
[He, Shuang] The count means how many times the test case get that result

> 
> - The results are somewhat hard to read and would benefit from a bit
>   more formatting, even if just alignment of columns.
[He, Shuang] Yes, it absolutely need more refinement. I would be very happen to apply them if you have any suggestion

> 
> - You're missing the In-reply-to header in your answers which breaks
>   mail threading
[He, Shuang] It is in the header. You could check archieve of intel-gfx mailing list http://lists.freedesktop.org/archives/intel-gfx/2014-November/thread.html. It's correctly threaded by intel-gfx mailing

> 
> - It'd be great to have public links with logs to inspect the failure
>   cases.
[He, Shuang] that is one exactly same concern I had also, since we can't send internal link to external mailing list. While we need one way to hold logs

Thanks
	--Shuang

> 
> Thanks!
> 
> --
> Damien
> 
> On Wed, Nov 12, 2014 at 11:21:35PM -0800, shuang.he@intel.com wrote:
> > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang.he@intel.com)
> > -------------------------------------Summary-------------------------------------
> > Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
> > BYT: pass/total=291/291->290/291
> > PNV: pass/total=356/356->356/356
> > ILK: pass/total=372/372->365/372
> > IVB: pass/total=545/546->545/546
> > SNB: pass/total=380/380->379/380
> > HSW: pass/total=579/579->579/579
> > BDW: pass/total=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)...
> > BYT: Intel_gpu_tools,
> igt_gem_userptr_blits_forked-sync-swapping-multifd-mempressure-interruptib
> le, PASS(4, M31M38) -> NO_RESULT(1, M38)PASS(3, M38)
> > ILK: Intel_gpu_tools, igt_kms_flip_bcs-wf_vblank-vs-dpms-interruptible,
> DMESG_WARN(3, M26)PASS(4, M26) -> DMESG_WARN(1, M26)PASS(3, M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-dpms-off-vs-modeset,
> DMESG_WARN(2, M26)PASS(2, M26) -> DMESG_WARN(2, M26)PASS(2, M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang, NSPT(1,
> M26)DMESG_WARN(1, M26)PASS(2, M26) -> DMESG_WARN(1, M26)PASS(3,
> M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible,
> DMESG_WARN(1, M26)PASS(6, M26) -> DMESG_WARN(1, M26)PASS(3, M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_nonexisting-fb-interruptible,
> DMESG_WARN(1, M26)PASS(3, M26) -> DMESG_WARN(2, M26)PASS(2, M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-ts-check-interruptible,
> DMESG_WARN(1, M26)PASS(3, M26) -> DMESG_WARN(2, M26)PASS(2, M26)
> > ILK: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc, FAIL(3,
> M26)DMESG_FAIL(1, M26)TIMEOUT(17, M37M6M26)PASS(1, M26) ->
> TIMEOUT(1, M26)PASS(3, M26)
> > IVB: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(7,
> M21M34M4)PASS(12, M34M21M4) -> NSPT(1, M34)PASS(3, M34)
> > IVB: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc,
> TIMEOUT(18, M34M21M4)PASS(1, M21) -> TIMEOUT(1, M34)PASS(3, M34)
> > SNB: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc,
> TIMEOUT(18, M35M22)PASS(1, M35) -> TIMEOUT(1, M22)PASS(3, M22)
> > BDW: Intel_gpu_tools, igt_gem_reset_stats_ban-bsd, DMESG_WARN(1,
> M28)PASS(18, M42M30M28) -> PASS(4, M28)
> > BDW: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc,
> TIMEOUT(18, M42M30M28)PASS(1, M28) -> TIMEOUT(1, M28)PASS(3, M28)
> > _______________________________________________
> > 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