== Series Details ==
Series: Assorted fixes/tweaks to GuC support (rev3)
URL : https://patchwork.freedesktop.org/series/97514/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10963 -> Patchwork_21757
Summary
---
**FAIL
On Fri, 03 Dec 2021 07:54:56 -0800, Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin
>
> Use the i915 exported data in /proc//fdinfo to show GPU utilization
> per DRM client.
Didn't we just remove it? Adding it back now? Sorry for the probably dumb
question :/
== Series Details ==
Series: Assorted fixes/tweaks to GuC support (rev3)
URL : https://patchwork.freedesktop.org/series/97514/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Assorted fixes/tweaks to GuC support (rev3)
URL : https://patchwork.freedesktop.org/series/97514/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
251e5012b67c drm/i915/uc: Allow platforms to have GuC but not HuC
-:36: ERROR:COMPLEX_MACRO: Macros with
== Series Details ==
Series: Per client GPU stats (rev5)
URL : https://patchwork.freedesktop.org/series/92574/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10961_full -> Patchwork_21748_full
Summary
---
**FAILURE**
From: Clint Taylor
Remove force probe protection from ADL_P platform. Did not obsevre
warnings, errors, flickering or any visual defects while doing ordinary
tasks like browsing and editing documents in a two monitor setup.
For more info drm-tip idle run results :
https://intel-gfx-ci.01.org/tre
Hi Matthew,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.16-rc3 next-20211203]
[cannot apply to airlied/drm-next]
[If your
== Series Details ==
Series: drm/i915: Rollback seqno when request creation fails (rev2)
URL : https://patchwork.freedesktop.org/series/97562/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10963 -> Patchwork_21756
Summary
-
== Series Details ==
Series: drm/i915/selftests: Follow up on increase timeout in i915_gem_contexts
selftests
URL : https://patchwork.freedesktop.org/series/97577/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10963 -> Patchwork_21755
=
On Fri, Dec 03, 2021 at 04:28:56PM +0100, Thierry Reding wrote:
> On Fri, Dec 03, 2021 at 01:25:17AM -0800, Kees Cook wrote:
> > The link_status array was not large enough to read the Adjust Request
> > Post Cursor2 register. Adjust the size to include it. Found with a
> > -Warray-bounds build:
> >
Assuming the whitespace cleanup requested below is completed:
Acked-by: Jon Bloomfield
> -Original Message-
> From: Intel-gfx On Behalf Of
> Rodrigo Vivi
> Sent: Tuesday, November 16, 2021 2:33 PM
> To: Taylor, Clinton A
> Cc: Intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx]
== Series Details ==
Series: drm/i915: Rollback seqno when request creation fails (rev2)
URL : https://patchwork.freedesktop.org/series/97562/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Fri, Dec 03, 2021 at 03:53:56PM -0800, Matthew Brost wrote:
> On Fri, Dec 03, 2021 at 03:30:57PM -0800, Bruce Chang wrote:
> > Follow up on patch https://patchwork.freedesktop.org/patch/446832/
> >
> > Different platforms will take a bit longer while GuC is enabled, so
> > increase the timeout
On Fri, Dec 03, 2021 at 11:28:00PM +0100, Michal Wajdeczko wrote:
>
>
> On 03.12.2021 19:33, john.c.harri...@intel.com wrote:
> > From: John Harrison
> >
> > Update to the latest GuC release.
> >
> > The latest GuC firmware introduces a number of interface changes:
>
> Why can't we review all
On Fri, Dec 03, 2021 at 03:30:57PM -0800, Bruce Chang wrote:
> Follow up on patch https://patchwork.freedesktop.org/patch/446832/
>
> Different platforms will take a bit longer while GuC is enabled, so
> increase the timeout and also add some margin in i915_gem_context
> selftest.
>
> Signed-off-
gem_ctx_create.basic-files can slam on kernel contexts to the extent
where request creation fails because the ring is full. When this happens
seqno numbers are skipped which can result the below GEM_BUG_ON blowing
in gt/intel_engine_pm.c:__engine_unpark:
GEM_BUG_ON(ce->timeline->seqno !=
== Series Details ==
Series: drm/i915/selftests: Follow up on increase timeout in i915_gem_contexts
selftests
URL : https://patchwork.freedesktop.org/series/97577/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
06b07fd47af5 drm/i915/selftests: Follow up on increase timeout in
== Series Details ==
Series: drm/i915/gem: Use local pointer ttm for __i915_ttm_move
URL : https://patchwork.freedesktop.org/series/97572/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10963 -> Patchwork_21754
Summary
-
Follow up on patch https://patchwork.freedesktop.org/patch/446832/
Different platforms will take a bit longer while GuC is enabled, so
increase the timeout and also add some margin in i915_gem_context
selftest.
Signed-off-by: Bruce Chang
Cc: Matthew Brost
Cc: John Harrison
---
drivers/gpu/drm
== Series Details ==
Series: drm/i915/gem: Use local pointer for __i915_ttm_move
URL : https://patchwork.freedesktop.org/series/97571/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10963 -> Patchwork_21753
Summary
---
== Series Details ==
Series: drm/i915/gem: Use local pointer ttm for __i915_ttm_move
URL : https://patchwork.freedesktop.org/series/97572/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4f37b82c97ec drm/i915/gem: Use local pointer ttm for __i915_ttm_move
-:22: ERROR:MISSING_SIGN
== Series Details ==
Series: drm/i915/gem: Use local pointer for __i915_ttm_move
URL : https://patchwork.freedesktop.org/series/97571/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c48a10e7ad67 drm/i915/gem: Use local pointer for __i915_ttm_move
-:21: ERROR:MISSING_SIGN_OFF: Mi
== Series Details ==
Series: Update to GuC version 69.0.0
URL : https://patchwork.freedesktop.org/series/97564/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10963 -> Patchwork_21752
Summary
---
**SUCCESS**
No reg
== Series Details ==
Series: drm/i915/gen11: Moving WAs to icl_gt_workarounds_init() (rev4)
URL : https://patchwork.freedesktop.org/series/97208/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10961_full -> Patchwork_21747_full
==
On 03.12.2021 19:33, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Update to the latest GuC release.
>
> The latest GuC firmware introduces a number of interface changes:
Why can't we review all these changes in smaller patches and squash them
in separate CI series *after* colle
== Series Details ==
Series: Update to GuC version 69.0.0
URL : https://patchwork.freedesktop.org/series/97564/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
/home/cidrm/kernel/Documentation/gpu/i915:542:
./drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h:44: WARNING
== Series Details ==
Series: Introduce new i915 macros for checking PTEs (rev5)
URL : https://patchwork.freedesktop.org/series/96679/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10963 -> Patchwork_21750
Summary
---
== Series Details ==
Series: Update to GuC version 69.0.0
URL : https://patchwork.freedesktop.org/series/97564/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Update to GuC version 69.0.0
URL : https://patchwork.freedesktop.org/series/97564/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1ba090939f4f drm/i915/uc: Allow platforms to have GuC but not HuC
-:37: ERROR:COMPLEX_MACRO: Macros with complex values
== Series Details ==
Series: drm/i915: Rollback seqno when request creation fails
URL : https://patchwork.freedesktop.org/series/97562/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile
To avoid confusion with deferencing possible null pointer bo->ttm,
replace pointer bo->ttm with local pointer ttm in i915_ttm_move
as ttm has checks for null before getting passed to __i915_ttm_move
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
== Series Details ==
Series: Introduce new i915 macros for checking PTEs (rev5)
URL : https://patchwork.freedesktop.org/series/96679/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: series starting with [v5,1/1] drm/i915: Introduce new macros for i915
PTE
URL : https://patchwork.freedesktop.org/series/97559/
State : failure
== Summary ==
Patch is empty.
When you have resolved this problem, run "git am --continue".
If you prefer to skip this p
== Series Details ==
Series: drm/i915/ddi: add use_edp_hobl() and use_edp_low_vswing() helpers
URL : https://patchwork.freedesktop.org/series/97547/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10961_full -> Patchwork_21745_full
===
== Series Details ==
Series: drm/i915/gt: Use hw_engine_masks as reset_domains
URL : https://patchwork.freedesktop.org/series/97543/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10961_full -> Patchwork_21743_full
Summary
-
On Fri, Dec 03, 2021 at 12:47:53PM -0800, Jasmine Newsome wrote:
> Replace pointer bo->ttm with ttm in i915_ttm_move
> when passed as argument to __i915_ttm_move
Hi Jasmine,
Can you please resend this patch with the commit description updated to
describe why this patch is needed?
Thanks,
Sudeep
Replace pointer bo->ttm with ttm in i915_ttm_move
when passed as argument to __i915_ttm_move
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_mo
Hello:
This patch was applied to bpf/bpf.git (master)
by Alexei Starovoitov :
On Thu, 2 Dec 2021 12:34:00 -0800 you wrote:
> cgroup.h (therefore swap.h, therefore half of the universe)
> includes bpf.h which in turn includes module.h and slab.h.
> Since we're about to get rid of that dependency
On Fri, Dec 03, 2021 at 10:33:36AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Lots of testing is done with the DEBUG_GEM config option enabled but
> not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
> which are not hugely useful. Enabling full DEBUG_GUC a
On Fri, Dec 03, 2021 at 10:33:39AM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> If the GuC fails to load, it is useful to know what firmware file /
> version was attempted. So move the version info report to before the
> load attempt rather than only after a successful load.
On 12/2/2021 4:33 PM, Lucas De Marchi wrote:
On Thu, Dec 02, 2021 at 04:06:23PM -0800, john.c.harri...@intel.com
wrote:
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't le
== Series Details ==
Series: series starting with [1/3] drm/i915: Nuke {pipe,
plane}_to_crtc_mapping[]
URL : https://patchwork.freedesktop.org/series/97541/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10961_full -> Patchwork_21742_full
==
On Wed, Dec 01, 2021 at 08:48:31PM -0800, Matthew Brost wrote:
> From: Dan Carpenter
>
> Originally "out_fence" was set using out_fence = sync_file_create() but
> which returns NULL, but now it is set with out_fence = eb_requests_create()
> which returns error pointers. The error path needs to b
On Thu, Dec 2, 2021 at 11:11 PM Greg KH wrote:
>
> On Thu, Dec 02, 2021 at 12:34:00PM -0800, Jakub Kicinski wrote:
> > cgroup.h (therefore swap.h, therefore half of the universe)
> > includes bpf.h which in turn includes module.h and slab.h.
> > Since we're about to get rid of that dependency we n
On Fri, Dec 03, 2021 at 10:33:35AM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separate
From: John Harrison
If the GuC fails to load, it is useful to know what firmware file /
version was attempted. So move the version info report to before the
load attempt rather than only after a successful load.
If the GuC does fail to load, then make the error messages visible
rather than being
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log_debu
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_uc_f
From: John Harrison
Update to the latest GuC release.
The latest GuC firmware introduces a number of interface changes:
GuC may return NO_RESPONSE_RETRY message for requests sent over CTB.
Add support for this reply and try resending the request again as a
new CTB message.
A KLV (key-length-va
From: John Harrison
Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
bigge
From: John Harrison
Update to the latest GuC version. This includes a suite of interface
changes and new features with corresponding i915 side changes.
Also, fix/improve a bunch of other things while at it.
Signed-off-by: John Harrison
John Harrison (5):
drm/i915/uc: Allow platforms to ha
gem_ctx_create.basic-files can slam on kernel contexts to the extent
where request creation fails because the ring is full. When this happens
seqno numbers are skipped which can result the below GEM_BUG_ON blowing
in gt/intel_engine_pm.c:__engine_unpark:
GEM_BUG_ON(ce->timeline->seqno !=
Certain functions within i915 uses macros that are defined for
specific architectures by the mmu, such as _PAGE_RW and _PAGE_PRESENT
(Some architectures don't even have these macros defined, like ARM64).
Instead of re-using bits defined for the CPU, we should use bits
defined for i915. This patch
This series is to introduce new macros generic to i915 for checking 0 and 1
bits, instead on relying on whats defined by the mmu, since it could
be different or non-exisitent between different platforms.
v2: Corrected sender's email.
v3: Corrected spelling error.
v4: Clean up a few other macro
Certain functions within i915 uses macros that are defined for
specific architectures by the mmu, such as _PAGE_RW and _PAGE_PRESENT
(Some architectures don't even have these macros defined, like ARM64).
Instead of re-using bits defined for the CPU, we should use bits
defined for i915. This patch
On 2021-12-03 at 17:31:11 +, Matthew Auld wrote:
> On 03/12/2021 16:59, Ramalingam C wrote:
> > On 2021-12-03 at 12:24:20 +, Matthew Auld wrote:
> > > If this is LMEM then we get a 32 entry PT, with each PTE pointing to
> > > some 64K block of memory, otherwise it's just the usual 512 entry
This series is to introduce new macros generic to i915 for checking 0 and 1
bits, instead on relying on whats defined by the mmu, since it could
be different or non-exisitent between different platforms.
v2: Corrected sender's email.
v3: Corrected spelling error.
v4: Clean up a few other macro
On 03/12/2021 17:30, Ramalingam C wrote:
On 2021-12-03 at 12:24:22 +, Matthew Auld wrote:
Ensure we add the engine base only after we calculate the qword offset
into the PTE window.
So we didn't hit this issue because we were always using the
engine->instance 0!?
Yes, AFAIK.
Looks goo
On 03/12/2021 17:25, Ramalingam C wrote:
On 2021-12-03 at 12:24:21 +, Matthew Auld wrote:
With object clearing/copying we need to be able to modify the PTEs on
the fly via some batch buffer, which means we need to be able to map the
paging structures(or at the very least the PT, but being ab
On 2021-12-03 at 12:24:24 +, Matthew Auld wrote:
> Ensure we account for any object rounding due to min_page_size
> restrictions.
>
> Signed-off-by: Matthew Auld
Reviewed-by: Ramalingam C
> Cc: Thomas Hellström
> Cc: Ramalingam C
> ---
> drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 +
On 2021-12-03 at 12:24:23 +, Matthew Auld wrote:
> No need to insert PTEs for the PTE window itself, also foreach expects a
> length not an end offset, which could be gigantic here with a second
> engine.
>
Looks good to me
Reviewed-by: Ramalingam C
> Signed-off-by: Matthew Auld
> Cc: Thom
On 03/12/2021 16:59, Ramalingam C wrote:
On 2021-12-03 at 12:24:20 +, Matthew Auld wrote:
If this is LMEM then we get a 32 entry PT, with each PTE pointing to
some 64K block of memory, otherwise it's just the usual 512 entry PT.
This very much assumes the caller knows what they are doing.
S
On 2021-12-03 at 12:24:22 +, Matthew Auld wrote:
> Ensure we add the engine base only after we calculate the qword offset
> into the PTE window.
So we didn't hit this issue because we were always using the
engine->instance 0!?
Looks good to me
Reviewed-by: Ramalingam C
>
> Signed-off-by:
== Series Details ==
Series: Per client GPU stats (rev5)
URL : https://patchwork.freedesktop.org/series/92574/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10961 -> Patchwork_21748
Summary
---
**SUCCESS**
No regr
On 2021-12-03 at 12:24:21 +, Matthew Auld wrote:
> With object clearing/copying we need to be able to modify the PTEs on
> the fly via some batch buffer, which means we need to be able to map the
> paging structures(or at the very least the PT, but being able to also
> map the PD might also be
== Series Details ==
Series: Per client GPU stats (rev5)
URL : https://patchwork.freedesktop.org/series/92574/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_context_types.h:417: warning: Function
parameter or member 'client_link
== Series Details ==
Series: Per client GPU stats (rev5)
URL : https://patchwork.freedesktop.org/series/92574/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: Per client GPU stats (rev5)
URL : https://patchwork.freedesktop.org/series/92574/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5b365ef06833 drm/i915: Explicitly track DRM clients
-:129: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), do
On 2021-12-03 at 12:24:20 +, Matthew Auld wrote:
> If this is LMEM then we get a 32 entry PT, with each PTE pointing to
> some 64K block of memory, otherwise it's just the usual 512 entry PT.
> This very much assumes the caller knows what they are doing.
>
> Signed-off-by: Matthew Auld
> Cc:
We have a bug https://gitlab.freedesktop.org/drm/intel/-/issues/4384 for the
regression failure.
Re-reported.
Thanks,
Lakshmi.
-Original Message-
From: Gupta, Anshuman
Sent: Friday, December 3, 2021 12:40 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
Cc: Dixit, Ashut
On 2021-12-03 at 12:24:19 +, Matthew Auld wrote:
> The scratch page might not be allocated in LMEM(like on DG2), so instead
> of using that as the deciding factor for where the paging structures
> live, let's just query the pt before mapping it.
>
Looks good to me.
Reviewed-by: Ramalingam C
== Series Details ==
Series: drm/i915/selftest: Disable IRQ for timestamp calculation (rev3)
URL : https://patchwork.freedesktop.org/series/96853/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10943_full -> Patchwork_21701_full
=
== Series Details ==
Series: drm/dp: Actually read Adjust Request Post Cursor2 register
URL : https://patchwork.freedesktop.org/series/97533/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10959_full -> Patchwork_21740_full
On Fri, 03 Dec 2021, Ville Syrjälä wrote:
> On Wed, Nov 24, 2021 at 01:36:52PM +0200, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> Now that each plane tracks its own no_fbc_reason we can print that
>> out in debugfs, and we can also show which plane is currently
>> selected for FBC duty.
>>
From: Tvrtko Ursulin
Use the i915 exported data in /proc//fdinfo to show GPU utilization
per DRM client.
Example of the output:
intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz
70% RC6; 0.62/ 7.08 W; 760 irqs/s
ENGINES BUSY
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM.
i91
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamse
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver:
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not g
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram)
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multi
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs proposing
the common specification which should enable nice common userspace tools to be
written.
For the moment I only have intel_gpu_top converted to use this and that seems to
work okay.
v2:
* Added prot
== Series Details ==
Series: drm/i915/gen11: Moving WAs to icl_gt_workarounds_init() (rev4)
URL : https://patchwork.freedesktop.org/series/97208/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10961 -> Patchwork_21747
Summar
== Series Details ==
Series: drm/i915/adl_p: Fix ddc pin mapping
URL : https://patchwork.freedesktop.org/series/97527/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10959_full -> Patchwork_21739_full
Summary
---
**SU
== Series Details ==
Series: drm/i915/ddi: add use_edp_hobl() and use_edp_low_vswing() helpers
URL : https://patchwork.freedesktop.org/series/97547/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10961 -> Patchwork_21745
Sum
On 12/3/21 16:00, Christian König wrote:
Am 03.12.21 um 15:50 schrieb Thomas Hellström:
On 12/3/21 15:26, Christian König wrote:
[Adding Daniel here as well]
Am 03.12.21 um 15:18 schrieb Thomas Hellström:
[SNIP]
Well that's ok as well. My question is why does this single dma_fence
then sh
== Series Details ==
Series: treewide: add missing includes masked by cgroup -> bpf dependency (rev2)
URL : https://patchwork.freedesktop.org/series/97159/
State : failure
== Summary ==
Applying: treewide: add missing includes masked by cgroup -> bpf dependency
error: sha1 information is lacki
== Series Details ==
Series: drm/i915/gt: Use hw_engine_masks as reset_domains
URL : https://patchwork.freedesktop.org/series/97543/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10961 -> Patchwork_21743
Summary
---
From: Raviteja Goud Talla
Bspec page says "Reset: BUS", Accordingly moving w/a's:
Wa_1407352427,Wa_1406680159 to proper function icl_gt_workarounds_init()
Which will resolve guc enabling error
v2:
- Previous patch rev2 was created by email client which caused the
Build failure, This v2 is
On 12/3/21 15:26, Christian König wrote:
[Adding Daniel here as well]
Am 03.12.21 um 15:18 schrieb Thomas Hellström:
[SNIP]
Well that's ok as well. My question is why does this single dma_fence
then shows up in the dma_fence_chain representing the whole
migration?
What we'd like to happen d
== Series Details ==
Series: DG2 accelerated migration/clearing support
URL : https://patchwork.freedesktop.org/series/97544/
State : failure
== Summary ==
Applying: drm/i915/migrate: don't check the scratch page
Applying: drm/i915/gtt: add xehpsdv_ppgtt_insert_entry
Applying: drm/i915/gtt: ad
== Series Details ==
Series: drm/i915/gt: Use hw_engine_masks as reset_domains
URL : https://patchwork.freedesktop.org/series/97543/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Fri, 2021-12-03 at 14:08 +0100, Christian König wrote:
> Am 01.12.21 um 13:16 schrieb Thomas Hellström (Intel):
> >
> > On 12/1/21 12:25, Christian König wrote:
> > > Am 01.12.21 um 12:04 schrieb Thomas Hellström (Intel):
> > > >
> > > > On 12/1/21 11:32, Christian König wrote:
> > > > > Am 01
== Series Details ==
Series: series starting with [1/3] drm/i915: Nuke {pipe,
plane}_to_crtc_mapping[]
URL : https://patchwork.freedesktop.org/series/97541/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10961 -> Patchwork_21742
cgroup.h (therefore swap.h, therefore half of the universe)
includes bpf.h which in turn includes module.h and slab.h.
Since we're about to get rid of that dependency we need
to clean things up.
v2: drop the cpu.h include from cacheinfo.h, it's not necessary
and it makes riscv sensitive to orderin
Quoting Janusz Krzysztofik (2021-12-03 13:21:06)
> diff --git a/0001-drm-i915-gt-Cleanup-partial-engine-discovery-failure.patch
> b/0001-drm-i915-gt-Cleanup-partial-engine-discovery-failure.patch
> index efadd30d8cad..62b0a41d4aa4 100644
> --- a/0001-drm-i915-gt-Cleanup-partial-engine-discovery-fa
== Series Details ==
Series: series starting with [1/3] drm/i915: Nuke {pipe,
plane}_to_crtc_mapping[]
URL : https://patchwork.freedesktop.org/series/97541/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked sep
On Thu, 2021-12-02 at 13:56 +0200, Ville Syrjälä wrote:
> On Wed, Dec 01, 2021 at 05:18:54PM +, Souza, Jose wrote:
> > On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Replace the "sizes are 0 based" stuff with just straight
> > > up -1 where neede
== Series Details ==
Series: series starting with [1/4] drm/i915: Pass plane id to watermark
calculation functions
URL : https://patchwork.freedesktop.org/series/97536/
State : failure
== Summary ==
Applying: drm/i915: Pass plane id to watermark calculation functions
Applying: drm/i915: Intro
1 - 100 of 151 matches
Mail list logo
