All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 04/15] drm/i915: Add GuC-related header files
Date: Wed, 24 Jun 2015 08:41:02 +0100	[thread overview]
Message-ID: <558A5F0E.9070508@intel.com> (raw)
In-Reply-To: <20150615202037.GF28462@nuc-i3427.alporthouse.com>

On 15/06/15 21:20, Chris Wilson wrote:
> On Mon, Jun 15, 2015 at 07:36:22PM +0100, Dave Gordon wrote:
>> From: Alex Dai <yu.dai@intel.com>
>>
>> intel_guc_api.h contains the subset of the GuC interface that we
>> will need for submission of commands through the GuC. These MUST
>> be kept in sync with the definitions used by the GuC firmware.
> 
> intel_guc_hw.h or intel_guc_abi.h then. Calling it API doesn't make it
> clear whose API you are talking about.
>  
>> intel_guc.h defines structures and parameters relevant to loading
>> the GuC firmware and setting it running. Some of these also need
>> to be kept in sync with the firmware.
> 
> intel_guc.h should be developed organically as features are added in the
> series so that it is possible to track against implementation. Certainly
> not in a patch that adds the entirety of the firmware ABI.

Done.

>> +struct i915_guc_client {
>> +	spinlock_t wq_lock;
>> +	struct drm_i915_gem_object *client_obj;
>> +	u32 priority;
>> +	off_t doorbell_offset;
>> +	off_t proc_desc_offset;
>> +	off_t wq_offset;
>> +	uint16_t doorbell_id;
>> +	uint32_t ctx_index;
>> +	uint32_t wq_size;
>> +	uint32_t wq_tail;
>> +	uint32_t cookie;
>> +
>> +	/* GuC submission statistics & status */
>> +	uint64_t submissions;
>> +	uint32_t q_fail;
>> +	uint32_t b_fail;
>> +	int retcode;
> 
> Mixture of classic kernel types and stdint types. And off_t! What size
> exactly do you mean there?

All converted to stdint now.

>> +};
>> +
>> +#define I915_MAX_DOORBELLS	256
>> +#define INVALID_DOORBELL_ID	I915_MAX_DOORBELLS
>> +
>> +#define INVALID_CTX_ID		(MAX_GUC_GPU_CONTEXTS+1)
>> +
>> +struct intel_guc {
>> +	/* Generic uC firmware management */
>> +	struct intel_uc_fw guc_fw;
> 
> Haven't checked for size, but I guess this is going to be an init only
> structure that we could discard.

No, we need it for reloading. It's not very big anyway.

>> +	/* GuC-specific additions */
>> +	uint32_t fw_ver_major;
>> +	uint32_t fw_ver_minor;
> 
> I have no idea why you would want to keep these around.

Firstly, they're used to pass the designation for the version of the f/w
interface that this revision of the driver can work with.

Secondly we want to print them in messages, so I've split these into
(major,minor) that we wanted and (major,minor) that we found. These were
already printed in a NOTICE, but not in the debugfs output.

>> +	spinlock_t host2guc_lock;
> 
> Seems overly specific, no comment as to what it locks and lack of
> implementation to be able to confirm.

Now reorganised so it's adjacent to the protected data :)

>> +	struct drm_i915_gem_object *ctx_pool_obj;
>> +	struct drm_i915_gem_object *log_obj;
>> +	struct i915_guc_client *execbuf_client;
> 
> I expect these will want modification based on patches to be reviewed.

Now added in separate patches.

>> +	struct ida ctx_ids;
>> +	uint32_t log_flags;
>> +	int db_cacheline;
>> +	DECLARE_BITMAP(doorbell_bitmap, I915_MAX_DOORBELLS);
>> +
>> +	/* Action status & statistics */
>> +	uint64_t action_count;		/* Total commands issued	*/
>> +	uint32_t action_cmd;		/* Last command word		*/
>> +	uint32_t action_status;		/* Last return status		*/
>> +	uint32_t action_fail;		/* Total number of failures	*/
>> +	int32_t action_err;		/* Last error code		*/
> 
> Any group of prefix_ immediately raises the question of "why isn't this
> a struct?"
> -Chris

Not really worth making and naming a struct. There's only one instance
of this whole thing; the code that updates these touches them
individually, and the debugfs code that prints them can't really make
use of them collectively either.

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

  parent reply	other threads:[~2015-06-24  7:41 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-15 18:36 [PATCH 00/15] Batch submission via GuC Dave Gordon
2015-06-15 18:36 ` [PATCH 01/15] drm/i915: Add i915_gem_object_write() to i915_gem.c Dave Gordon
2015-06-15 20:09   ` Chris Wilson
2015-06-17  7:23     ` Dave Gordon
2015-06-17 12:02       ` Daniel Vetter
2015-06-18 11:49         ` Dave Gordon
2015-06-18 12:10           ` Chris Wilson
2015-06-18 18:07             ` Dave Gordon
2015-06-19  8:44               ` Chris Wilson
2015-06-22 11:59                 ` Dave Gordon
2015-06-22 12:37                   ` Chris Wilson
2015-06-23 16:54                     ` Dave Gordon
2015-06-18 14:31           ` Daniel Vetter
2015-06-18 18:28             ` Dave Gordon
2015-06-24  9:32               ` Daniel Vetter
2015-06-25 12:28                 ` Dave Gordon
2015-06-24  9:40               ` Chris Wilson
2015-06-15 18:36 ` [PATCH 02/15] drm/i915: Embedded microcontroller (uC) firmware loading support Dave Gordon
2015-06-17 12:05   ` Daniel Vetter
2015-06-18 12:11     ` Dave Gordon
2015-06-18 14:49       ` Daniel Vetter
2015-06-18 15:27         ` Chris Wilson
2015-06-18 15:35           ` Daniel Vetter
2015-06-18 15:49             ` Chris Wilson
2015-06-19  8:43         ` Dave Gordon
2015-06-24 10:29           ` Daniel Vetter
2015-07-06 12:44             ` Dave Gordon
2015-07-06 13:24               ` Daniel Vetter
2015-06-15 18:36 ` [PATCH 03/15] drm/i915: Add GuC-related module parameters Dave Gordon
2015-06-15 18:36 ` [PATCH 04/15] drm/i915: Add GuC-related header files Dave Gordon
2015-06-15 20:20   ` Chris Wilson
2015-06-17 15:01     ` Dave Gordon
2015-06-23 18:10       ` Dave Gordon
2015-06-24  7:41     ` Dave Gordon [this message]
2015-06-24  9:37       ` Daniel Vetter
2015-06-15 18:36 ` [PATCH 05/15] drm/i915: GuC-specific firmware loader Dave Gordon
2015-06-15 20:30   ` Chris Wilson
2015-06-18 17:53     ` Yu Dai
2015-06-18 20:12       ` Chris Wilson
2015-06-19 14:34         ` Dave Gordon
2015-06-18 18:54     ` Dave Gordon
2015-06-15 18:36 ` [PATCH 06/15] drm/i915: Debugfs interface to read GuC load status Dave Gordon
2015-06-16  9:40   ` Chris Wilson
2015-06-19  7:49     ` Dave Gordon
2015-06-15 18:36 ` [PATCH 07/15] drm/i915: Defer default hardware context initialisation until first open Dave Gordon
2015-06-16  9:35   ` Chris Wilson
2015-06-19  9:42     ` Dave Gordon
2015-06-17 12:18   ` Daniel Vetter
2015-06-19  9:19     ` Dave Gordon
2015-06-24 10:15       ` Daniel Vetter
2015-06-15 18:36 ` [PATCH 08/15] drm/i915: Move execlists defines from .c to .h Dave Gordon
2015-06-16  9:37   ` Chris Wilson
2015-06-17  7:31     ` Dave Gordon
2015-06-17  7:54       ` Chris Wilson
2015-06-17  7:59       ` Chris Wilson
2015-06-22 13:05         ` Dave Gordon
2015-06-15 18:36 ` [PATCH 09/15] drm/i915: GuC submission setup, phase 1 Dave Gordon
2015-06-15 21:32   ` Chris Wilson
2015-06-19 17:02     ` Dave Gordon
2015-06-19 17:22       ` Dave Gordon
2015-06-16 11:44   ` Chris Wilson
2015-06-15 18:36 ` [PATCH 10/15] drm/i915: Enable GuC firmware log Dave Gordon
2015-06-15 21:40   ` Chris Wilson
2015-06-16  9:26   ` Tvrtko Ursulin
2015-06-16 11:40     ` Chris Wilson
2015-06-16 12:29       ` Tvrtko Ursulin
2015-06-15 18:36 ` [PATCH 11/15] drm/i915: Implementation of GuC client Dave Gordon
2015-06-15 21:55   ` Chris Wilson
2015-06-19 17:55     ` Dave Gordon
2015-06-15 18:36 ` [PATCH 12/15] drm/i915: Interrupt routing for GuC submission Dave Gordon
2015-06-16  9:24   ` Chris Wilson
2015-06-17  8:20     ` Dave Gordon
2015-06-17 12:22       ` Daniel Vetter
2015-06-17 12:41         ` Daniel Vetter
2015-06-23 11:33           ` Dave Gordon
2015-06-23 23:48             ` Yu Dai
2015-06-24 10:02               ` Daniel Vetter
2015-06-15 18:36 ` [PATCH 13/15] drm/i915: Integrate GuC-based command submission Dave Gordon
2015-06-16  9:22   ` Chris Wilson
2015-06-19 18:18     ` Dave Gordon
2015-06-15 18:36 ` [PATCH 14/15] drm/i915: Debugfs interface for GuC submission statistics Dave Gordon
2015-06-16  9:28   ` Chris Wilson
2015-06-24  8:27     ` Dave Gordon
2015-06-15 18:36 ` [PATCH 15/15] Documentation/drm: kerneldoc for GuC Dave Gordon
2015-06-15 18:36 ` [PATCH 16/15] drm/i915: Enable GuC submission, where supported Dave Gordon
2015-06-17 12:43 ` [PATCH 00/15] Batch submission via GuC Daniel Vetter
2015-06-25  7:23   ` Dave Gordon
2015-06-25  8:05     ` Chris Wilson
2015-06-24 12:16 ` Daniel Vetter
2015-06-24 12:57   ` Chris Wilson
  -- strict thread matches above, loose matches on Subject: below --
2015-07-03 12:30 [PATCH 00/15 v3] " Dave Gordon
2015-07-03 12:30 ` [PATCH 04/15] drm/i915: Add GuC-related header files Dave Gordon

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=558A5F0E.9070508@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --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.