All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 1/2] drm/i915/guc: Limit number of scratch registers used for H2G
Date: Thu, 18 Oct 2018 11:51:22 -0700	[thread overview]
Message-ID: <3af93bcd-da23-f82b-640c-b7bff22d8ead@intel.com> (raw)
In-Reply-To: <20181018183024.31156-1-michal.wajdeczko@intel.com>



On 18/10/18 11:30, Michal Wajdeczko wrote:
> We wrongly assumed that GuC is only using last scratch register
> for G2H messages, but in fact it is also using register [14] to
> report sleep state status. Remove that register from our H2G
> send registers pool.
> 
> v2: No message from host to GuC uses more than 8 registers and
> the GuC FW itself uses an 8-element array to store the H2G message,
> so we may reduce our send array to just 8 registers (Daniele)
> v3: use explicit define
> 
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/intel_guc.c      | 3 ++-
>   drivers/gpu/drm/i915/intel_guc_fwif.h | 5 ++++-
>   2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
> index 4c61eb9..9b00cdf 100644
> --- a/drivers/gpu/drm/i915/intel_guc.c
> +++ b/drivers/gpu/drm/i915/intel_guc.c
> @@ -50,7 +50,8 @@ void intel_guc_init_send_regs(struct intel_guc *guc)
>   	unsigned int i;
>   
>   	guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0));
> -	guc->send_regs.count = SOFT_SCRATCH_COUNT - 1;
> +	guc->send_regs.count = GUC_MMIO_MSG_LEN;
> +	BUILD_BUG_ON(GUC_MMIO_MSG_LEN > SOFT_SCRATCH_COUNT);
>   
>   	for (i = 0; i < guc->send_regs.count; i++) {
>   		fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h
> index d1bbaba..cc997ef 100644
> --- a/drivers/gpu/drm/i915/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
> @@ -601,7 +601,8 @@ struct guc_shared_ctx_data {
>    * registers, where first register holds data treated as message header,
>    * and other registers are used to hold message payload.
>    *
> - * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8
> + * For Gen9+, GuC uses software scratch registers 0xC180-0xC1B8, but
> + * the GuC FW itself uses an 8-element array to store the H2G message.

I think our justification here should be that no commands takes more 
than 8 dwords more than what GuC FW does internally (which can reinforce 
the point but not make it IMO).

>    *
>    *      +-----------+---------+---------+---------+
>    *      |  MMIO[0]  | MMIO[1] |   ...   | MMIO[n] |
> @@ -633,6 +634,8 @@ struct guc_shared_ctx_data {
>    *   field.
>    */
>   
> +#define GUC_MMIO_MSG_LEN		8
> +

I'd prefer GUC_MAX_MMIO_MSG_LEN, but I can live with this.

With the improved comment:

Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>

Daniele

>   #define INTEL_GUC_MSG_TYPE_SHIFT	28
>   #define INTEL_GUC_MSG_TYPE_MASK		(0xF << INTEL_GUC_MSG_TYPE_SHIFT)
>   #define INTEL_GUC_MSG_DATA_SHIFT	16
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-10-18 18:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-18 18:30 [PATCH v3 1/2] drm/i915/guc: Limit number of scratch registers used for H2G Michal Wajdeczko
2018-10-18 18:30 ` [PATCH v3 2/2] HAX: Enable GuC for CI Michal Wajdeczko
2018-10-18 18:51 ` Daniele Ceraolo Spurio [this message]
2018-10-18 19:06 ` ✗ Fi.CI.BAT: failure for series starting with [v3,1/2] drm/i915/guc: Limit number of scratch registers used for H2G 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=3af93bcd-da23-f82b-640c-b7bff22d8ead@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michal.wajdeczko@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.