[Intel-gfx] [PATCH v2] drm/i915/cmdparser: Remove stray intel_engine_cs *ring
Joonas Lahtinen
joonas.lahtinen at linux.intel.com
Mon Jul 25 11:01:05 UTC 2016
On ma, 2016-07-25 at 10:06 +0100, Chris Wilson wrote:
> When we refer to intel_engine_cs, we want to use engine so as not to
> confuse ourselves about ringbuffers.
>
> v2: Rename all the functions as well, as well as a few more stray comments.
>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Link: http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-6-git-send-email-chris@chris-wilson.co.uk
> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 72 +++++++++++++++---------------
> drivers/gpu/drm/i915/i915_drv.h | 23 +++++-----
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 +++---
> drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
> drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
> drivers/gpu/drm/i915/intel_ringbuffer.h | 10 ++---
> 7 files changed, 64 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index b0fd6a7..8db144b 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -62,23 +62,23 @@
> * The parser always rejects such commands.
> *
> * The majority of the problematic commands fall in the MI_* range, with only a
> - * few specific commands on each ring (e.g. PIPE_CONTROL and MI_FLUSH_DW).
> + * few specific commands on each engine (e.g. PIPE_CONTROL and MI_FLUSH_DW).
> *
> * Implementation:
> - * Each ring maintains tables of commands and registers which the parser uses in
> - * scanning batch buffers submitted to that ring.
> + * Each engine maintains tables of commands and registers which the parser
> + * uses in scanning batch buffers submitted to that engine.
> *
> * Since the set of commands that the parser must check for is significantly
> * smaller than the number of commands supported, the parser tables contain only
> * those commands required by the parser. This generally works because command
> * opcode ranges have standard command length encodings. So for commands that
> * the parser does not need to check, it can easily skip them. This is
> - * implemented via a per-ring length decoding vfunc.
> + * implemented via a per-engine length decoding vfunc.
> *
> * Unfortunately, there are a number of commands that do not follow the standard
> * length encoding for their opcode range, primarily amongst the MI_* commands.
> * To handle this, the parser provides a way to define explicit "skip" entries
> - * in the per-ring command tables.
> + * in the per-engine command tables.
> *
> * Other command table entries map fairly directly to high level categories
> * mentioned above: rejected, master-only, register whitelist. The parser
> @@ -603,7 +603,7 @@ static u32 gen7_blt_get_cmd_length_mask(u32 cmd_header)
> return 0;
> }
>
> -static bool validate_cmds_sorted(struct intel_engine_cs *engine,
> +static bool validate_cmds_sorted(const struct intel_engine_cs *engine,
This otherwise unrelated change is a dependency from a signature change
below.
> const struct drm_i915_cmd_table *cmd_tables,
> int cmd_table_count)
> {
> @@ -624,8 +624,9 @@ static bool validate_cmds_sorted(struct intel_engine_cs *engine,
> u32 curr = desc->cmd.value & desc->cmd.mask;
>
> if (curr < previous) {
> - DRM_ERROR("CMD: table not sorted ring=%d table=%d entry=%d cmd=0x%08X prev=0x%08X\n",
> - engine->id, i, j, curr, previous);
> + DRM_ERROR("CMD: %s [%d] command table not sorted: table=%d entry=%d cmd=0x%08X prev=0x%08X\n",
Cut this line here like;
DRM_ERROR("CMD: %s [%d] command table not sorted: "
"table=%d entry=%d cmd=0x%08X prev=0x%08X\n"
> + engine->name, engine->id,
> + i, j, curr, previous);
Then this cut makes more sense, too.
Apart from that, looks fairly mechanical;
Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
More information about the Intel-gfx
mailing list