All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org
Cc: akash.goel@intel.com
Subject: Re: [PATCH 4/4] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation
Date: Thu, 3 Dec 2015 12:14:26 +0000	[thread overview]
Message-ID: <56603222.3020300@linux.intel.com> (raw)
In-Reply-To: <1449048293-4335-5-git-send-email-ankitprasad.r.sharma@intel.com>


Hi,

On 02/12/15 09:24, ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>
> This patch verifies if the contents of the stolen backed object were
> preserved across hibernation. This is to validate kernel changes related
> to moving stolen-backed objects to shmem on hibernation.
>
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>

Please Cc me if it is expected I keep reviewing this.

> ---
>   tests/gem_stolen.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 86 insertions(+)
>
> diff --git a/tests/gem_stolen.c b/tests/gem_stolen.c
> index 3374716..1f13fb0 100644
> --- a/tests/gem_stolen.c
> +++ b/tests/gem_stolen.c
> @@ -290,6 +290,89 @@ static void stolen_fill_purge_test(int fd)
>   		gem_close(fd, handle[i]);
>   }
>
> +static void stolen_hibernate(int fd)
> +{
> +	drm_intel_bo *bo;
> +	drm_intel_bo *src, *dest;
> +	int obj_count = 0, i = 0;
> +	int _ret = 0, j = 0;

Don't need to init _ret and j.

> +	uint32_t handle[MAX_OBJECTS], src_handle;
> +	uint32_t *virt;
> +
> +	gem_require_stolen_support(fd);
> +
> +	src_handle = gem_create(fd, SIZE);
> +	igt_assert(!src_handle);

gem_create already asserts this, but isn't it also reversed? Does it run 
and work?

> +	src = gem_handle_to_libdrm_bo(bufmgr, fd,
> +				     "bo", src_handle);
> +	igt_assert(src != NULL);
> +
> +	_ret = drm_intel_gem_bo_map_gtt(src);
> +	igt_assert(!_ret);

I think igt_assert_eq(ret, 0) is a preferred way nowadays.

Also a question, what is the special significance of _ret vs just normal 
ret in this test?

> +
> +	virt = src->virtual;
> +	for (j = 0; j < SIZE/DWORD_SIZE; j++)
> +		virt[j] = DATA;

memset?

> +
> +	drm_intel_bo_unmap(src);
> +	/* Exhaust Stolen space */
> +	do {
> +		handle[i] = __gem_create_stolen(fd, SIZE);
> +		if (handle[i] != 0) {

Maybe it would be more readable and with less indentation:

for (i = 0; i < MAX_OBJECTS; i++) {
	handle[i] = __gem_create_stolen(...);
	if (!handle[i])
		break;

	...

	obj_count++;
}

> +			bo = gem_handle_to_libdrm_bo(bufmgr, fd,
> +						     "verify_bo", handle[i]);
> +			igt_assert(bo != NULL);
> +			_ret = drm_intel_gem_bo_map_gtt(bo);
> +			igt_assert(!_ret);
> +
> +			virt = bo->virtual;
> +			for (j = 0; j < SIZE/DWORD_SIZE; j++)
> +				igt_assert(!virt[j]);

Again, people will probably want igt_assert_eq.

> +
> +			drm_intel_bo_unmap(bo);
> +			drm_intel_bo_unreference(bo);
> +
> +			obj_count++;
> +		}
> +
> +		i++;
> +	} while (handle[i-1] && i < MAX_OBJECTS);
> +
> +	igt_assert(obj_count > 0);
> +
> +	for (i = 0; i < obj_count; i++) {
> +		dest = gem_handle_to_libdrm_bo(bufmgr, fd,
> +					       "dst_bo", handle[i]);
> +		igt_assert(dest != NULL);
> +		intel_copy_bo(batch, dest, src, SIZE);
> +		drm_intel_bo_unreference(dest);
> +	}

Probably worth doing a verification step after each blit. So after 
resume is not the first time you are checking it.

> +	drm_intel_bo_unreference(src);
> +
> +	igt_system_hibernate_autoresume();
> +	/* Check if the object's memory contents are intact
> +	 * across hibernation.
> +	 */
> +	for (i = 0; i < obj_count; i++) {
> +		bo = gem_handle_to_libdrm_bo(bufmgr, fd,
> +					     "verify_bo", handle[i]);
> +		igt_assert(bo != NULL);
> +		_ret = drm_intel_gem_bo_map_gtt(bo);
> +		igt_assert(!_ret);
> +		virt = bo->virtual;
> +		for (j = 0; j < SIZE/DWORD_SIZE; j++)
> +			igt_assert_eq(virt[j], DATA);
> +
> +		drm_intel_bo_unmap(bo);
> +		drm_intel_bo_unreference(bo);
> +	}

Would it be interesting to fill the bos with some more elaborate pattern 
to potentially catch more potential corruption types?

Perhaps incrementing dwords would simply do?

> +	gem_close(fd, src_handle);
> +	for (i = 0; i < obj_count; i++)
> +		gem_close(fd, handle[i]);
> +}
> +
>   static void
>   stolen_no_mmap(int fd)
>   {
> @@ -353,6 +436,9 @@ igt_main
>   	igt_subtest("stolen-fill-purge")
>   		stolen_fill_purge_test(fd);
>
> +	igt_subtest("stolen-hibernate")
> +		stolen_hibernate(fd);
> +
>   	igt_fixture {
>   		intel_batchbuffer_free(batch);
>   		drm_intel_bufmgr_destroy(bufmgr);
>

Regards,

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

  reply	other threads:[~2015-12-03 12:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-02  9:24 [PATCH v4 0/3] Tests for verifying the old and extended GEM_CREATE ioctl ankitprasad.r.sharma
2015-12-02  9:24 ` [PATCH 1/4] igt/gem_stolen: Verifying extended gem_create ioctl ankitprasad.r.sharma
2015-12-02  9:24 ` [PATCH 2/4] igt/gem_pread: Support to verify pread/pwrite for non-shmem backed obj ankitprasad.r.sharma
2015-12-02  9:24 ` [PATCH 3/4] igt/gem_create: Test to validate parameters for GEM_CREATE ioctl ankitprasad.r.sharma
2015-12-02  9:24 ` [PATCH 4/4] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation ankitprasad.r.sharma
2015-12-03 12:14   ` Tvrtko Ursulin [this message]
2015-12-04 10:04   ` Tvrtko Ursulin
  -- strict thread matches above, loose matches on Subject: below --
2015-12-22 10:07 [PATCH v6 0/4] Tests for verifying the old and extended GEM_CREATE ioctl ankitprasad.r.sharma
2015-12-22 10:07 ` [PATCH 4/4] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation ankitprasad.r.sharma
2015-12-22 16:00   ` Tvrtko Ursulin
2015-12-22 16:17     ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56603222.3020300@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=akash.goel@intel.com \
    --cc=ankitprasad.r.sharma@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.