On Tue, 22 Nov 2022 at 20:34, Jason Gunthorpe wrote:
> On Tue, Nov 22, 2022 at 08:29:05PM +0100, Daniel Vetter wrote:
> > You nuke all the ptes. Drivers that move have slightly more than a
> > bare struct file, they also have a struct address_space so that
> > invalidate_mapping_range() works.
>
>
== Series Details ==
Series: dma-buf: Require VM_PFNMAP vma for mmap
URL : https://patchwork.freedesktop.org/series/111210/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111210v1
Summary
---
**SUCC
From: John Harrison
Start using the 'submission API version' for deciding which GuC API to
use in the submission code.
Correct version number manipulation code to support full 32bit
major/minor/patch components, except for GuC which is guaranteed to be
8bit safe.
Other minor code clean ups arou
From: John Harrison
The GuC firmware includes an extra version number to specify the
submission API level. So use that rather than the main firmware
version number for submission related checks.
Also, while it is guaranteed that GuC version number components are
only 8-bits in size, other firmwa
From: John Harrison
The way delimieters (underscores and dots) were added to the UC
filenames was different for different types of delimter. Rationalise
them to all be done the same way - implicitly in the concatenation
macro rather than explicitly in the file name prefix.
Signed-off-by: John Ha
From: John Harrison
As a precursor to a coming change (for adding a GuC submission API
version), abstract the UC version number into its own private
structure separate to the firmware filename.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc.c| 6 +-
drivers/gpu/drm/i
After a more comprehensive offline discussion with Daniele and Rodrigo, design
direction was made to go with Option2
where we elevate pxp to a global subsystem and within it it establish a pointer
to the correct gt for pxp-controls. This
also reflects the current HW architectures where the PXP fe
Not everything of course, but intel_feature_action(param1, ...) enforcing
param1 to always be struct intel_feature_t i
assumed was what Rodrigo meant. And my intention wasn't to verify that rule but
rather look for surrounding precedence
for any exceptions to it (i felt PXP was a candidate for an
On Tue, 22 Nov 2022, "Ceraolo Spurio, Daniele"
wrote:
> On 11/22/2022 1:03 AM, Jani Nikula wrote:
>> On Mon, 21 Nov 2022, Daniele Ceraolo Spurio
>> wrote:
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
>>> b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
>>> index a8f38c2c60e2..5d0f1bcc381e 100
== Series Details ==
Series: drm/i915/gvt: use sysfs_streq() instead of strncmp()
URL : https://patchwork.freedesktop.org/series/111212/
State : warning
== Summary ==
Error: dim checkpatch failed
78ecf723a966 drm/i915/gvt: use sysfs_streq() instead of strncmp()
-:22: CHECK:PARENTHESIS_ALIGNMEN
Starting with MTL, the driver needs to not only protect the steering
control register from simultaneous software accesses, but also protect
against races with hardware/firmware agents. The hardware provides a
dedicated locking mechanism to support this via the STEER_SEMAPHORE
register. Reading th
We've been overloading uncore->lock to protect access to the MCR
steering register. That's not really what uncore->lock is intended for,
and it would be better if we didn't need to hold such a high-traffic
spinlock for the whole sequence of (apply steering, access MCR register,
restore steering).
The kerneldoc function name was not updated when this function was
converted to a non-fw form.
Fixes: 192bb40f030a ("drm/i915/gt: Manage uncore->lock while waiting on MCR
register")
Reported-by: kernel test robot
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 2 +-
1 fi
Passing the GT rather than uncore to the lowest level MCR read and write
functions will make it easier to introduce dedicated MCR locking in a
folling patch.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 18 ++
1 file changed, 10 insertions(+), 8 deletion
We've been overloading uncore->lock to protect access to the MCR
steering register. That's not really what uncore->lock is intended for,
and it would be better if we didn't need to hold such a high-traffic
spinlock for the whole sequence of (apply steering, access MCR register,
restore steering).
Thanks Stan for the explanation,
With that
Reviewed-by: Manasi Navare
Manasi
-Original Message-
From: Lisovskiy, Stanislav
Sent: Tuesday, November 22, 2022 2:40 AM
To: Navare, Manasi D
Cc: intel-gfx@lists.freedesktop.org; Saarinen, Jani ;
Nikula, Jani ; dri-de...@lists.freedesktop.
On Mon, Nov 21, 2022 at 03:16:15PM -0800, Daniele Ceraolo Spurio wrote:
> If the GSC was loaded, the only way to stop it during the driver unload
> flow is to do a driver-FLR.
> The driver-FLR is not the same as PCI config space FLR in that
> it doesn't reset the SGUnit and doesn't modify the PCI c
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/dg2: Introduce Wa_18018764978
URL : https://patchwork.freedesktop.org/series/111213/
State : warning
== Summary ==
Error: dim checkpatch failed
334ba5339553 drm/i915/dg2: Introduce Wa_18018764978
-:34: WARNING:SUSPECT_CODE_IND
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/dg2: Introduce Wa_18018764978
URL : https://patchwork.freedesktop.org/series/111213/
State : warning
== Summary ==
Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/gt/intel_gt_mcr.c:739: warning: expecting prototy
On Mon, Nov 21, 2022 at 03:16:16PM -0800, Daniele Ceraolo Spurio wrote:
> From: Jonathan Cavitt
>
> The GSC CS is only used for communicating with the GSC FW, so no need to
> initialize it if we're not going to use the FW. If we're not using
> neither the engine nor the microcontoller, then we ca
On Mon, Nov 21, 2022 at 03:16:17PM -0800, Daniele Ceraolo Spurio wrote:
> Now that we have the GSC FW support code as a user to the GSC CS, we
> can add the relevant flag to the engine mask. Note that the engine will
> still be disabled until we define the GSC FW binary file.
>
> Signed-off-by: Da
On Tue, Nov 22, 2022 at 11:39:31AM -0800, Ceraolo Spurio, Daniele wrote:
>
>
> On 11/22/2022 11:01 AM, Rodrigo Vivi wrote:
> > On Mon, Nov 21, 2022 at 03:16:14PM -0800, Daniele Ceraolo Spurio wrote:
> > > GSC FW is loaded by submitting a dedicated command via the GSC engine.
> > > The memory area
On Mon, Nov 21, 2022 at 06:18:15PM -0300, Gustavo Sousa wrote:
> Release notes:
>
> 1. Fixes for Register noclaims and few restore.
>
> Signed-off-by: Gustavo Sousa
Now that we've removed force_probe from DG2, in general we're past the
point where we can just directly update firmware versions l
I replied on v1 of this patch before realizing there was a v2 here. See
https://lists.freedesktop.org/archives/intel-gfx/2022-November/313046.html
for my feedback.
Matt
On Tue, Nov 22, 2022 at 06:17:15PM +, Srivatsa, Anusha wrote:
> Thanks, looked at the rest of the platforms in the file an
On Tue, Nov 22, 2022 at 06:50:14PM +, Teres Alexis, Alan Previn wrote:
>
>
> On Tue, 2022-11-22 at 12:57 -0500, Vivi, Rodrigo wrote:
> >
> >
> [Alan:snip]
>
> > As I had told I don't have a strong preference, as long as it keep clean
> > and without these many helpers of something "on_gt".
== Series Details ==
Series: add guard padding around i915_vma (rev2)
URL : https://patchwork.freedesktop.org/series/110720/
State : warning
== Summary ==
Error: dim checkpatch failed
c3b7961dfa97 drm/i915: Wrap all access to i915_vma.node.start|size
-:263: WARNING:AVOID_BUG: Do not crash the
On Tue, Nov 22, 2022 at 12:59:36PM -0800, Matt Roper wrote:
> On Mon, Nov 21, 2022 at 06:18:15PM -0300, Gustavo Sousa wrote:
> > Release notes:
> >
> > 1. Fixes for Register noclaims and few restore.
> >
> > Signed-off-by: Gustavo Sousa
>
> Now that we've removed force_probe from DG2, in genera
== Series Details ==
Series: add guard padding around i915_vma (rev2)
URL : https://patchwork.freedesktop.org/series/110720/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Tue, Nov 22, 2022 at 10:33:05AM -0800, Matt Atwood wrote:
> Wa_18018764978 applies to specific steppings of DG2 (G10 C0+,
> G11 and G12 A0+). Clean up style in function at the same time.
>
> Bspec: 66622
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +
On Wed, Nov 09, 2022 at 04:11:39PM +, Tvrtko Ursulin wrote:
> +DRM scheduling soft limits
> +~~
> +
> +Because of the heterogenous hardware and driver DRM capabilities, soft limits
> +are implemented as a loose co-operative (bi-directional) interface between
> the
> +co
On 11/22/2022 06:12, Jani Nikula wrote:
On Tue, 06 Sep 2022, Daniele Ceraolo Spurio
wrote:
From: John Harrison
There was a misunderstanding in how firmware file compatibility should
be managed within i915. This has been clarified as:
i915 must support all existing firmware releases foreve
== Series Details ==
Series: drm/i915/gvt: use sysfs_streq() instead of strncmp()
URL : https://patchwork.freedesktop.org/series/111212/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111212v1
Summary
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/dg2: Introduce Wa_18018764978
URL : https://patchwork.freedesktop.org/series/111213/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111213v1
==
== Series Details ==
Series: add guard padding around i915_vma (rev2)
URL : https://patchwork.freedesktop.org/series/110720/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12418 -> Patchwork_110720v2
Summary
---
**SUC
== Series Details ==
Series: More GuC firmware version improvements
URL : https://patchwork.freedesktop.org/series/111218/
State : warning
== Summary ==
Error: dim checkpatch failed
f3a008949a16 drm/i915/uc: Rationalise delimiters in filename macros
460dbd43f21f drm/i915/uc: More refactoring o
== Series Details ==
Series: More GuC firmware version improvements
URL : https://patchwork.freedesktop.org/series/111218/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Tue, Nov 22, 2022 at 03:17:14PM +0200, Jani Nikula wrote:
Introduce stricter rules for topic/core-for-CI management. Way too many
commits have been added over the years, with insufficient rationale
recorded in the commit message, and insufficient follow-up with removing
the commits from the to
== Series Details ==
Series: More GuC firmware version improvements
URL : https://patchwork.freedesktop.org/series/111218/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111218v1
Summary
---
**SUCCE
== Series Details ==
Series: i915: dedicated MCR locking and hardware semaphore
URL : https://patchwork.freedesktop.org/series/111220/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: i915: dedicated MCR locking and hardware semaphore
URL : https://patchwork.freedesktop.org/series/111220/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111220v1
Summary
--
On 11/22/2022 12:46 PM, Rodrigo Vivi wrote:
On Mon, Nov 21, 2022 at 03:16:15PM -0800, Daniele Ceraolo Spurio wrote:
If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-FLR is not the same as PCI config space FLR in that
it doesn't res
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active r
On 11/22/2022 12:52 PM, Rodrigo Vivi wrote:
On Mon, Nov 21, 2022 at 03:16:16PM -0800, Daniele Ceraolo Spurio wrote:
From: Jonathan Cavitt
The GSC CS is only used for communicating with the GSC FW, so no need to
initialize it if we're not going to use the FW. If we're not using
neither the e
On 11/10/2022 16:56, Daniele Ceraolo Spurio wrote:
The fence is always initialized in huc_init_early, but the cleanup in
huc_fini is only being run if HuC is enabled. This causes a leaking of
the debug object when HuC is disabled/not supported, which can in turn
trigger a warning if we try to reg
On 11/22/2022 12:09 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The way delimieters (underscores and dots) were added to the UC
filenames was different for different types of delimter. Rationalise
delimiter misspelled twice. Apart from this, it's a simple cleanup, so:
Reviewe
On 11/22/2022 12:09 PM, john.c.harri...@intel.com wrote:
From: John Harrison
As a precursor to a coming change (for adding a GuC submission API
version), abstract the UC version number into its own private
structure separate to the firmware filename.
Signed-off-by: John Harrison
Reviewed
From: John Harrison
It was noticed that the table order verification step was only being
run once rather than once per firmware type. Fix that.
Note that the long term plan is to convert this code to be a mock
selftest. It is already only compiled in when selftests are enabled.
And the work invo
On 11/22/2022 12:09 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The GuC firmware includes an extra version number to specify the
submission API level. So use that rather than the main firmware
version number for submission related checks.
Also, while it is guaranteed that GuC v
An earlier commit introduced a mechanism to parse the context image to
find the OA context control offset. This resulted in an NPD on haswell
when gem_context was passed into i915_perf_open_ioctl params. Haswell
does not support logical ring contexts, so ensure that the context image
is parsed only
== Series Details ==
Series: drm/i915: Allow error capture without a request
URL : https://patchwork.freedesktop.org/series/111224/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12418 -> Patchwork_111224v1
Summary
---
On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
> On XE_LPM+ platforms the media engines are carved out into a separate
> GT but have a common GGTMMADR address range which essentially makes
> the GGTT address space to be shared between media and render GT. As a
> result any upda
== Series Details ==
Series: drm/i915/dvo: Further DVO fixes/cleanups
URL : https://patchwork.freedesktop.org/series/91/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12417_full -> Patchwork_91v1_full
Summary
--
On 11/22/2022 09:42, Michal Wajdeczko wrote:
On 18.11.2022 02:58, john.c.harri...@intel.com wrote:
From: John Harrison
Create a set of GuC printers and start using them.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 32 --
drivers/gpu/drm/i915/gt
== Series Details ==
Series: drm/i915/uc: Fix table order verification to check all FW types
URL : https://patchwork.freedesktop.org/series/111228/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12419 -> Patchwork_111228v1
S
== Series Details ==
Series: drm/i915/perf: Do not parse context image for HSW
URL : https://patchwork.freedesktop.org/series/111231/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
CC [M] drivers/gpu/drm/i915/i915_perf.o
drivers/gpu/drm
On 11/22/2022 09:54, Michal Wajdeczko wrote:
On 18.11.2022 02:58, john.c.harri...@intel.com wrote:
From: John Harrison
Re-work the existing GuC CT printers and extend as required to match
the new wrapping scheme.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |
An earlier commit introduced a mechanism to parse the context image to
find the OA context control offset. This resulted in an NPD on haswell
when gem_context was passed into i915_perf_open_ioctl params. Haswell
does not support logical ring contexts, so ensure that the context image
is parsed only
On 11/22/2022 3:33 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that the table order verification step was only being
run once rather than once per firmware type. Fix that.
Note that the long term plan is to convert this code to be a mock
selftest. It is already o
== Series Details ==
Series: drm/i915/perf: Do not parse context image for HSW (rev2)
URL : https://patchwork.freedesktop.org/series/111231/
State : warning
== Summary ==
Error: dim checkpatch failed
bdbecc07a5b3 drm/i915/perf: Do not parse context image for HSW
-:27: CHECK:COMPARISON_TO_NULL:
== Series Details ==
Series: drm/i915/perf: Do not parse context image for HSW (rev2)
URL : https://patchwork.freedesktop.org/series/111231/
State : warning
== Summary ==
Error: make htmldocs had i915 warnings
./drivers/gpu/drm/i915/gt/intel_gt_mcr.c:739: warning: expecting prototype for
inte
== Series Details ==
Series: drm/i915/perf: Do not parse context image for HSW (rev2)
URL : https://patchwork.freedesktop.org/series/111231/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12419 -> Patchwork_111231v2
Summary
On Tue, 22 Nov 2022 18:07:00 -0800, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
> An earlier commit introduced a mechanism to parse the context image to
> find the OA context control offset. This resulted in an NPD on haswell
> when gem_context was passed into i915_perf_open_ioctl params. Haswell
>
The WaFbcTurnOffFbcWhenHyperVisorIsUsed is applicable for SKL, BXT and
KBL.
Bspec: 0852
v2: Updated commit msg and corrected Bspec format(Jani N)
v3: Updated the stepping information
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_fbc.c | 5 +++--
1 file changed, 3 insertio
== Series Details ==
Series: drm/i915/fbc: Disable FBC when VT-d is enabled
URL : https://patchwork.freedesktop.org/series/111239/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12419 -> Patchwork_111239v1
Summary
---
On 23-11-2022 05:29, Matt Roper wrote:
> On Tue, Nov 22, 2022 at 12:31:26PM +0530, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared betw
== Series Details ==
Series: drm/i915/hti: avoid theoretically possible negative shift
URL : https://patchwork.freedesktop.org/series/92/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12418_full -> Patchwork_92v1_full
===
> -Original Message-
> From: Gupta, Anshuman
> Sent: 21 November 2022 16:59
> To: Ghimiray, Himal Prasad ; intel-
> g...@lists.freedesktop.org
> Cc: Auld, Matthew
> Subject: RE: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> bandwidth via sysfs
>
>
>
> > -Original Me
> -Original Message-
> From: Tvrtko Ursulin
> Sent: 21 November 2022 17:17
> To: Ghimiray, Himal Prasad ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> bandwidth via sysfs
>
>
> On 21/11/2022 10:01, Himal Prasad Ghimiray w
On Tue, Nov 22, 2022 at 02:09:48PM +0200, Jani Nikula wrote:
> If phy is PHY_NONE, the shift to register bits becomes negative. Check
> and warn about this.
>
> Reported-by: coverity-bot
> References: https://lore.kernel.org/r/202211180848.D39006C@keescook
> Signed-off-by: Jani Nikula
Reviewed-
Hi all,
On Thu, 17 Nov 2022 18:32:14 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> ld: drivers/video/fbdev/core/fbmon.o: in function `fb_modesetting_disabled':
> fbmon.c:(.text+0x1e4): multiple defi
On Wed, Nov 23, 2022 at 3:21 PM Stephen Rothwell wrote:
>
> Hi all,
>
> On Thu, 17 Nov 2022 18:32:14 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > ld: drivers/video/fbdev/core/fbmon.o: in
== Series Details ==
Series: drm/i915/dmc: Update DG2 DMC version to v2.08 (rev2)
URL : https://patchwork.freedesktop.org/series/64/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12418_full -> Patchwork_64v2_full
Su
On Tue, 22 Nov 2022 21:10:01 -0800, Ghimiray, Himal Prasad wrote:
>
> > -Original Message-
> > From: Tvrtko Ursulin
> > Sent: 21 November 2022 17:17
> > To: Ghimiray, Himal Prasad ; intel-
> > g...@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max mem
Thanks Ashutosh for the clarification.
BR
Himal Ghimiray
> -Original Message-
> From: Dixit, Ashutosh
> Sent: 23 November 2022 11:29
> To: Ghimiray, Himal Prasad
> Cc: Tvrtko Ursulin ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max m
On Wed, Nov 23, 2022 at 09:03:08AM +0530, Arun R Murthy wrote:
> The WaFbcTurnOffFbcWhenHyperVisorIsUsed is applicable for SKL, BXT and
> KBL.
>
> Bspec: 0852
>
> v2: Updated commit msg and corrected Bspec format(Jani N)
> v3: Updated the stepping information
>
> Signed-off-by: Arun R Murthy
>
Hi Dave,
On Wed, 23 Nov 2022 15:35:50 +1000 David Airlie wrote:
>
> Nothing gone wrong as such, just the drm-misc-next pull request was
> sent on a regular weekly cadence, then I merged it a few days later.
> The fix for this is still in the drm-misc-next queue for the next PR
> which I will get
On Tue, Nov 22, 2022 at 12:23:43PM +0200, Luca Coelho wrote:
> In newer hardware versions (i.e. display version >= 14), the second
> scaler doesn't support vertical scaling.
>
> The current implementation of the scaling limits is simplified and
> only occurs when the planes are created, so we don'
== Series Details ==
Series: drm/i915/guc: make default_lists const data
URL : https://patchwork.freedesktop.org/series/111201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12418_full -> Patchwork_111201v1_full
Summary
---
Making sure that the mode-clock is not greater than the
max_dot_clock freq.This patch will prevent attempts from
userspace to modeset with mode->clock greater than
max_dot_clock freq.
Signed-off-by: Nischal Varide
---
drivers/gpu/drm/i915/display/intel_dp.c | 10 ++
drivers/gpu/drm/i9
On Wed, Nov 23, 2022 at 01:13:56PM +0530, Nischal Varide wrote:
> Making sure that the mode-clock is not greater than the
> max_dot_clock freq.This patch will prevent attempts from
> userspace to modeset with mode->clock greater than
> max_dot_clock freq.
Already handled elsewhere.
>
> Signed-o
101 - 180 of 180 matches
Mail list logo
