All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Andi Shyti <andi.shyti@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Matt Roper <matthew.d.roper@intel.com>
Cc: Andi Shyti <andi.shyti@kernel.org>
Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915: Sanitycheck MMIO access early in driver load
Date: Tue, 21 Mar 2023 13:37:44 +0200	[thread overview]
Message-ID: <877cva8hdj.fsf@intel.com> (raw)
In-Reply-To: <20230320202326.296498-2-andi.shyti@linux.intel.com>

On Mon, 20 Mar 2023, Andi Shyti <andi.shyti@linux.intel.com> wrote:
> From: Matt Roper <matthew.d.roper@intel.com>
>
> We occasionally see the PCI device in a non-accessible state at the
> point the driver is loaded.  When this happens, all BAR accesses will
> read back as 0xFFFFFFFF.  Rather than reading registers and
> misinterpreting their (invalid) values, let's specifically check for
> 0xFFFFFFFF in a register that cannot have that value to see if the
> device is accessible.
>
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 34 +++++++++++++++++++++++++++++
>  1 file changed, 34 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index e1e1f34490c8e..14ec45e6facfa 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -2602,11 +2602,45 @@ static int uncore_forcewake_init(struct intel_uncore *uncore)
>  	return 0;
>  }
>  
> +static int sanity_check_mmio_access(struct intel_uncore *uncore)
> +{
> +	struct drm_i915_private *i915 = uncore->i915;
> +
> +	if (GRAPHICS_VER(i915) < 8)
> +		return 0;
> +
> +	/*
> +	 * Sanitycheck that MMIO access to the device is working properly.  If
> +	 * the CPU is unable to communcate with a PCI device, BAR reads will
> +	 * return 0xFFFFFFFF.  Let's make sure the device isn't in this state
> +	 * before we start trying to access registers.
> +	 *
> +	 * We use the primary GT's forcewake register as our guinea pig since
> +	 * it's been around since HSW and it's a masked register so the upper
> +	 * 16 bits can never read back as 1's if device access is operating
> +	 * properly.
> +	 *
> +	 * If MMIO isn't working, we'll wait up to 2 seconds to see if it
> +	 * recovers, then give up.
> +	 */
> +#define COND (__raw_uncore_read32(uncore, FORCEWAKE_MT) != ~0)
> +	if (wait_for(COND, 2000) == -ETIMEDOUT) {

I guess this somewhat reimplements intel_wait_for_register_fw()?

> +		drm_err(&i915->drm, "Device is non-operational; MMIO access returns 0xFFFFFFFF!\n");
> +		return -EIO;
> +	}
> +
> +	return 0;
> +}
> +
>  int intel_uncore_init_mmio(struct intel_uncore *uncore)
>  {
>  	struct drm_i915_private *i915 = uncore->i915;
>  	int ret;
>  
> +	ret = sanity_check_mmio_access(uncore);
> +	if (ret)
> +		return ret;
> +
>  	/*
>  	 * The boot firmware initializes local memory and assesses its health.
>  	 * If memory training fails, the punit will have been instructed to

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2023-03-21 11:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20 20:23 [Intel-gfx] [PATCH 0/2] Report MMIO communication problems more clearly Andi Shyti
2023-03-20 20:23 ` Andi Shyti
2023-03-20 20:23 ` [Intel-gfx] [PATCH 1/2] drm/i915: Sanitycheck MMIO access early in driver load Andi Shyti
2023-03-20 20:23   ` Andi Shyti
2023-03-21 11:37   ` Jani Nikula [this message]
2023-03-21 16:38     ` [Intel-gfx] " Andi Shyti
2023-03-21 16:38       ` Andi Shyti
2023-03-20 20:23 ` [Intel-gfx] [PATCH 2/2] drm/i915: Check for unreliable MMIO during forcewake Andi Shyti
2023-03-20 20:23   ` Andi Shyti
2023-03-21 12:06 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning for Report MMIO communication problems more clearly Patchwork
2023-03-21 12:06 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-03-21 12:32 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " 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=877cva8hdj.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=andi.shyti@kernel.org \
    --cc=andi.shyti@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.d.roper@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.