Re: [Intel-gfx] [PATCH v3] drm/i915/pxp: limit drm-errors or warning on firmware API failures

From: "Teres Alexis, Alan Previn" <alan.previn.teres.alexis@intel.com>
To: "Tamminen, Eero T" <eero.t.tamminen@intel.com>,
	"tvrtko.ursulin@linux.intel.com" <tvrtko.ursulin@linux.intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v3] drm/i915/pxp: limit drm-errors or warning on firmware API failures
Date: Thu, 23 Mar 2023 18:33:23 +0000	[thread overview]
Message-ID: <ed774e36f7130f6801d10325c65b40a5f443f48f.camel@intel.com> (raw)
In-Reply-To: <416a0d13-0013-ecbe-716e-f3bda59c9d30@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2028 bytes --]

On Thu, 2023-03-23 at 08:35 +0000, Tvrtko Ursulin wrote:

On 23/03/2023 00:27, Teres Alexis, Alan Previn wrote:

On Fri, 2023-03-17 at 13:37 +0200, Tamminen, Eero T wrote:

Hi,

On 16.3.2023 10.50, Tvrtko Ursulin wrote:

[   11.674183] i915 0000:00:02.0: PXP init-arb-session-15 failed due

to BIOS/SOC:0x0000101a:ERR_PLATFORM_CONFIG

...

Alan - is this expected during normal operation on some parts, or it's

something truly unexpected/unexplained? If the former then I think it

would be good to downgrade away from drm_WARN so it is less scary.

Commit message talks about "HW/platform gaps" - if it is like a missing

BIOS support or so then I think WARN_ON is too much.

Note that this was on pre-production TGL-H HW with BIOS from April 2021.

(I don't know where to get update, nor interested to update it.)

        - Eero

Alan: Hi Tvrtko, thanks for the feedback -i shall change from WARN_ONCE to drm_info_once.

Maybe it deserves to be a warning? Or a notice? I was just thinking it

does not need a call trace and all since it is not a driver issue. Your

call on the level and whether or not there is any chance for it to

happen in the field to make the discussion relevant or not.

I agree we don't need a call trace. I can't say how often this can happen in the field as it would depend on
when the platform was purchased, whether the owner had been updating the firwmware releases and whether
the bios settings were configured correctly. I'm okay with the drm_info_once - it could be ignored which is fine.

If customers seeing protected rendering/decoding fail when they actually DO need it, I am expecting they  will
provide the dmesg that shows above new message at compositor startup (mesa attempting to establish caps)
along with more serious complaints such as their application getting a failure when attempting to create a
protected context via I915 ioctl (which aligns with existing PXP UAPI behavior).

Any chance for an r-b? :)

[-- Attachment #2: Type: text/html, Size: 3357 bytes --]