From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 6/7] drm/i915/perf: add interrupt enabling parameter
Date: Tue, 03 Mar 2020 21:47:56 -0800 [thread overview]
Message-ID: <87wo80u0vn.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20200303221905.25866-7-umesh.nerlige.ramappa@intel.com>
On Tue, 03 Mar 2020 14:19:04 -0800, Umesh Nerlige Ramappa wrote:
>
> From: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
>
> This let's the application choose to be driven by the interrupt
> mechanism of the HW. In conjuction with long periods for checks for
> the availability of data on the CPU, this can reduce the CPU load when
> doing capture of OA data.
>
> v2: Version the new parameter (Joonas)
> v3: Rebase (Umesh)
>
> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
[snip]
> + /**
> + * Specifying this property sets up the interrupt mechanism for the OA
> + * buffer in i915. This option in conjuction with a long polling delay
> + * for avaibility of OA data can reduce CPU load significantly if you
> + * do not care about OA data being read as soon as it's available.
> + *
> + * This property is available in perf revision 5.
> + */
> + DRM_I915_PERF_PROP_OA_ENABLE_INTERRUPT,
What if we do not expose this parameter in the uapi at all and internally
decide in i915 whether to leave the interrupt either always enabled or
always disabled (and in that case always use the hrtimer)? This way we
retain flexibility in i915 if hardware evolves in the future e.g. to use
watermarks for the interrupt, without yielding control to userspace.
Overall I feel we should avoid exposing unnecessary details of the internal
implemenation to userspace, they would be neither interested in knowing
internal details nor know how to properly use these parameters. Shouldn't
the driver be able to make these kinds of decisions internally?
At this point the only parameter which implicitly exposed to userspace is
the hrtimer poll period, so perhaps all we need to do is to expose that in
the uapi? Thoughts?
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-03-04 5:48 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 22:18 [Intel-gfx] [PATCH 0/7] drm/i915/perf: add OA interrupt support Umesh Nerlige Ramappa
2020-03-03 22:18 ` [Intel-gfx] [PATCH 1/7] drm/i915/perf: rework aging tail workaround Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 2/7] drm/i915/perf: move pollin setup to non hw specific code Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 3/7] drm/i915/perf: only append status when data is available Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 4/7] drm/i915/perf: add new open param to configure polling of OA buffer Umesh Nerlige Ramappa
2020-03-12 19:27 ` Dixit, Ashutosh
2020-03-12 20:37 ` Lionel Landwerlin
2020-03-12 22:20 ` Dixit, Ashutosh
2020-03-12 23:10 ` Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 5/7] drm/i915: handle interrupts from the OA unit Umesh Nerlige Ramappa
2020-03-03 22:19 ` [Intel-gfx] [PATCH 6/7] drm/i915/perf: add interrupt enabling parameter Umesh Nerlige Ramappa
2020-03-04 5:47 ` Dixit, Ashutosh [this message]
2020-03-04 8:55 ` Lionel Landwerlin
2020-03-10 20:08 ` Umesh Nerlige Ramappa
2020-03-10 20:57 ` Lionel Landwerlin
2020-03-03 22:19 ` [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl Umesh Nerlige Ramappa
2020-03-04 5:48 ` Dixit, Ashutosh
2020-03-04 8:52 ` Lionel Landwerlin
2020-03-05 5:56 ` Dixit, Ashutosh
2020-03-09 19:51 ` Umesh Nerlige Ramappa
2020-03-10 20:44 ` Lionel Landwerlin
2020-03-11 3:05 ` Dixit, Ashutosh
2020-03-09 21:15 ` Umesh Nerlige Ramappa
2020-03-04 2:53 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: add OA interrupt support (rev5) Patchwork
2020-03-04 2:58 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-03-04 3:13 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2020-03-04 3:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-03-04 19:31 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
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=87wo80u0vn.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=umesh.nerlige.ramappa@intel.com \
/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.