Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Poosa, Karthik" <karthik.poosa@intel.com>
To: Raag Jadav <raag.jadav@intel.com>, <lucas.demarchi@intel.com>,
	<rodrigo.vivi@intel.com>, <jani.nikula@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <riana.tauro@intel.com>,
	<matthew.brost@intel.com>, <michal.wajdeczko@intel.com>,
	<badal.nilawar@intel.com>, <ville.syrjala@linux.intel.com>
Subject: Re: [PATCH v3] drm/xe/pcode: Allow checking for mailbox command support during driver probe
Date: Thu, 13 Nov 2025 11:07:44 +0530	[thread overview]
Message-ID: <d3a3c573-307a-430a-8279-ef04ceb8a114@intel.com> (raw)
In-Reply-To: <20251113044620.537345-1-raag.jadav@intel.com>


On 13-11-2025 10:14, Raag Jadav wrote:
> If the device is running older pcode firmware, it is possible that newer
> mailbox commands are not supported by it. The respective functionality
> isn't useful in that case but nor is error logging, since it doesn't
> particularly signify anything wrong with pcode firmware or device as a
> whole. Log such failures as debug messages during driver probe which allows
> the caller to check for mailbox command support without it being reported
> as an error. This is useful in cases where we want to make a decision on
> driver functionality based on pcode return codes and a relatively simpler
> design choice compared to other solutions like checking pcode firmware
> version, which comes with additional complexity of binding every single
> command to a specific version and deems pcode commands useless in case the
> driver fails to obtain it for reasons unrelated to pcode.
>
> This only silences command related failures and still reports other
> failures as errors, so we don't end up hiding the genuine ones.
>
> v2: Split unsupported command cases
> v3: Add device bound check
>
> Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> ---
>
> I've not followed the documented device_lock() rule here because
>
> 1. It'll deadlock in ->probe() path.
> 2. I don't know the code well enough to tell if it's really needed for
>     our case.
>
> So feel free to weigh in.
>
>   drivers/gpu/drm/xe/xe_device.h | 7 +++++++
>   drivers/gpu/drm/xe/xe_pcode.c  | 8 ++++++--
>   2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_device.h b/drivers/gpu/drm/xe/xe_device.h
> index 32cc6323b7f6..e8f997546ae1 100644
> --- a/drivers/gpu/drm/xe/xe_device.h
> +++ b/drivers/gpu/drm/xe/xe_device.h
> @@ -12,6 +12,13 @@
>   #include "xe_gt_types.h"
>   #include "xe_sriov.h"
>   
> +static inline bool xe_is_bound(struct xe_device *xe)
> +{
> +	struct device *dev = xe->drm.dev;
> +
> +	return device_is_bound(dev);
> +}
> +
>   static inline struct xe_device *to_xe_device(const struct drm_device *dev)
>   {
>   	return container_of(dev, struct xe_device, drm);
> diff --git a/drivers/gpu/drm/xe/xe_pcode.c b/drivers/gpu/drm/xe/xe_pcode.c
> index 0d33c14ea0cf..0f1edf5155c4 100644
> --- a/drivers/gpu/drm/xe/xe_pcode.c
> +++ b/drivers/gpu/drm/xe/xe_pcode.c
> @@ -57,8 +57,12 @@ static int pcode_mailbox_status(struct xe_tile *tile)
>   	}
>   
>   	if (err) {
> -		drm_err(&tile_to_xe(tile)->drm, "PCODE Mailbox failed: %d %s",
> -			err_decode, err_str);
> +		if (err_decode == -ENXIO && !xe_is_bound(tile_to_xe(tile)))
> +			drm_dbg(&tile_to_xe(tile)->drm, "PCODE Mailbox unsupported: %d %s",
> +				err_decode, err_str);
> +		else
> +			drm_err(&tile_to_xe(tile)->drm, "PCODE Mailbox failed: %d %s",
> +				err_decode, err_str);
>   
>   		return err_decode;
>   	}

This looks fine, as the commands to verify pcode supports for it would 
be there in device probe flow

and we need not log them as errors then, it can be drm_dbg.


  reply	other threads:[~2025-11-13  5:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-13  4:44 [PATCH v3] drm/xe/pcode: Allow checking for mailbox command support during driver probe Raag Jadav
2025-11-13  5:37 ` Poosa, Karthik [this message]
2025-11-13  5:43   ` Poosa, Karthik
2025-11-13  5:43 ` ✓ CI.KUnit: success for " Patchwork
2025-11-13  6:24 ` ✓ Xe.CI.BAT: " Patchwork
2025-11-13  8:11 ` [PATCH v3] " Nilawar, Badal
2025-11-20  6:09   ` Poosa, Karthik
2025-11-13 13:50 ` ✗ Xe.CI.Full: failure for " 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=d3a3c573-307a-430a-8279-ef04ceb8a114@intel.com \
    --to=karthik.poosa@intel.com \
    --cc=badal.nilawar@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=raag.jadav@intel.com \
    --cc=riana.tauro@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=ville.syrjala@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox