Re: [Intel-gfx] [PATCH 2/7] drm: Add drm_memcpy_from_wc() variant which accepts destination address

2022-02-28 Thread Lucas De Marchi
On Mon, Feb 28, 2022 at 11:48:58PM -0800, Lucas De Marchi wrote: On Tue, Feb 22, 2022 at 08:22:01PM +0530, Balasubramani Vivekanandan wrote: Fast copy using non-temporal instructions for x86 currently exists at two locations. One is implemented in i915 driver at i915/i915_memcpy.c and another

Re: [Intel-gfx] [PATCH 3/7] drm/i915: use the memcpy_from_wc call from the drm

2022-02-28 Thread Lucas De Marchi
On Tue, Feb 22, 2022 at 08:22:02PM +0530, Balasubramani Vivekanandan wrote: memcpy_from_wc functions in i915_memcpy.c will be removed and replaced by the implementation in drm_cache.c. Updated to use the functions provided by drm_cache.c. Signed-off-by: Balasubramani Vivekanandan ---

Re: [Intel-gfx] [PATCH 2/7] drm: Add drm_memcpy_from_wc() variant which accepts destination address

2022-02-28 Thread Lucas De Marchi
On Tue, Feb 22, 2022 at 08:22:01PM +0530, Balasubramani Vivekanandan wrote: Fast copy using non-temporal instructions for x86 currently exists at two locations. One is implemented in i915 driver at i915/i915_memcpy.c and another copy at drm_cache.c. The plan is to remove the duplicate

[Intel-gfx] ✗ Fi.CI.IGT: failure for Kbuild: move to -std=gnu11

2022-02-28 Thread Patchwork
== Series Details == Series: Kbuild: move to -std=gnu11 URL : https://patchwork.freedesktop.org/series/100824/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11300_full -> Patchwork_22435_full Summary --- **FAILURE**

Re: [Intel-gfx] [PATCH 1/7] drm: Relax alignment constraint for destination address

2022-02-28 Thread Lucas De Marchi
On Tue, Feb 22, 2022 at 08:22:00PM +0530, Balasubramani Vivekanandan wrote: There is no need for the destination address to be aligned to 16 byte boundary to be able to use the non-temporal instructions while copying. Non-temporal instructions are used only for loading from the source address

Re: [Intel-gfx] [PATCH v2 06/13] drm/i915: Move context descriptor fields to intel_lrc.h

2022-02-28 Thread Lucas De Marchi
On Mon, Feb 28, 2022 at 09:42:38AM -0800, Matt Roper wrote: This is a more appropriate header for these definitions. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 34 ---

Re: [Intel-gfx] [PATCH v2 04/13] drm/i915/xehp: compute engine pipe_control

2022-02-28 Thread Lucas De Marchi
On Mon, Feb 28, 2022 at 09:42:36AM -0800, Matt Roper wrote: From: Daniele Ceraolo Spurio CCS will reuse the RCS functions for breadcrumb and flush emission. However, CCS pipe_control has additional programming restrictions: - Command Streamer Stall Enable must be always set - Post Sync

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/xehp: Drop aux table invalidation on FlatCCS platforms

2022-02-28 Thread Patchwork
== Series Details == Series: drm/i915/xehp: Drop aux table invalidation on FlatCCS platforms URL : https://patchwork.freedesktop.org/series/100867/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22445

[Intel-gfx] ✓ Fi.CI.IGT: success for Kbuild: remove -std=gnu89 from compiler arguments

2022-02-28 Thread Patchwork
== Series Details == Series: Kbuild: remove -std=gnu89 from compiler arguments URL : https://patchwork.freedesktop.org/series/100823/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300_full -> Patchwork_22434_full Summary

Re: [Intel-gfx] [PATCH 1/6] drivers: usb: remove usage of list iterator past the loop body

2022-02-28 Thread Dan Carpenter
On Mon, Feb 28, 2022 at 10:20:28AM -0800, Joe Perches wrote: > On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote: > > > a multi-line indent gets curly braces for readability even though > > it's not required by C. And then both sides would get curly braces. > > That's more your personal

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: add more TMDS clock rate supported by HDMI driver

2022-02-28 Thread Patchwork
== Series Details == Series: drm/i915: add more TMDS clock rate supported by HDMI driver URL : https://patchwork.freedesktop.org/series/100866/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22444 Summary

[Intel-gfx] [PATCH] drm/i915/xehp: Drop aux table invalidation on FlatCCS platforms

2022-02-28 Thread Matt Roper
Platforms with FlatCCS do not use auxiliary planes for compression control data and thus do not need traditional aux table invalidation (and the registers no longer even exist). Original-author: CQ Tang Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 28

[Intel-gfx] [PATCH] drm/i915: add more TMDS clock rate supported by HDMI driver

2022-02-28 Thread Lee Shawn C
VBT 249 update to support more TMDS clock rate 3.00G, 3.40G and 5.94G. Refer to this new definition to configure max TMDS clock rate for HDMI driver. BSpec: 20124 Cc: Jani Nikula Cc: Ville Syrjala Cc: Ankit Nautiyal Signed-off-by: Lee Shawn C --- drivers/gpu/drm/i915/display/intel_bios.c

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/4] drm/i915/ttm: make eviction mappable aware

2022-02-28 Thread Patchwork
== Series Details == Series: series starting with [CI,1/4] drm/i915/ttm: make eviction mappable aware URL : https://patchwork.freedesktop.org/series/100818/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11299_full -> Patchwork_22433_full

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread David Laight
From: Matthew Wilcox > Sent: 28 February 2022 20:16 > > On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote: > > We can do > > > > typeof(pos) pos > > > > in the 'for ()' loop, and never use __iter at all. > > > > That means that inside the for-loop, we use a _different_ 'pos'

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Remove usage of list iterator past the loop body (rev3)

2022-02-28 Thread Patchwork
== Series Details == Series: Remove usage of list iterator past the loop body (rev3) URL : https://patchwork.freedesktop.org/series/100822/ State : failure == Summary == fatal: empty ident name (for <>) not allowed Applying: drivers: usb: remove usage of list iterator past the loop body

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread David Laight
From: Linus Torvalds > Sent: 28 February 2022 19:56 > On Mon, Feb 28, 2022 at 4:19 AM Christian König > wrote: > > > > I don't think that using the extra variable makes the code in any way > > more reliable or easier to read. > > So I think the next step is to do the attached patch (which

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Clear compress metadata for Xe_HP platforms

2022-02-28 Thread Patchwork
== Series Details == Series: drm/i915/gt: Clear compress metadata for Xe_HP platforms URL : https://patchwork.freedesktop.org/series/100856/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22442 Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities

2022-02-28 Thread Patchwork
== Series Details == Series: drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities URL : https://patchwork.freedesktop.org/series/100851/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22441

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 4:45 PM Linus Torvalds wrote: > > Yeah, except that's ugly beyond belief, plus it's literally not what > we do in the kernel. (Of course, I probably shouldn't have used 'min()' as an example, because that is actually one of the few places where we do exactly that, using

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 4:38 PM Segher Boessenkool wrote: > > In C its scope is the rest of the declaration and the entire loop, not > anything after it. This was the same in C++98 already, btw (but in > pre-standard versions of C++ things were like you remember, yes, and it > was painful).

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 3:26 PM Matthew Wilcox wrote: > > #define ___PASTE(a, b) a##b > #define __PASTE(a, b) ___PASTE(a, b) > #define _min(a, b, u) ({ \ Yeah, except that's ugly beyond belief, plus it's literally not what we do in the kernel. Really. The "-Wshadow doesn't work on the

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 1:47 PM Jakob Koschel wrote: > > The goal of this is to get compiler warnings right? This would indeed be > great. Yes, so I don't mind having a one-time patch that has been gathered using some automated checker tool, but I don't think that works from a long-term

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix flag query helper function to not modify state

2022-02-28 Thread Ceraolo Spurio, Daniele
On 2/17/2022 1:29 PM, john.c.harri...@intel.com wrote: From: John Harrison A flag query helper was actually writing to the flags word rather than just reading. Fix that. Also update the function's comment as it was out of date. NB: No need for a 'Fixes' tag. The test was only ever used

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities

2022-02-28 Thread Patchwork
== Series Details == Series: drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities URL : https://patchwork.freedesktop.org/series/100851/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7ba5645d82fa drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities -:35:

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation

2022-02-28 Thread Patchwork
== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation URL : https://patchwork.freedesktop.org/series/100847/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22439

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Remove usage of list iterator past the loop body (rev2)

2022-02-28 Thread Patchwork
== Series Details == Series: Remove usage of list iterator past the loop body (rev2) URL : https://patchwork.freedesktop.org/series/100822/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation

2022-02-28 Thread Patchwork
== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation URL : https://patchwork.freedesktop.org/series/100847/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/mm: Add an iterator to optimally walk over holes suitable for an allocation

2022-02-28 Thread Patchwork
== Series Details == Series: drm/mm: Add an iterator to optimally walk over holes suitable for an allocation URL : https://patchwork.freedesktop.org/series/100847/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0ae83c35ff14 drm/mm: Add an iterator to optimally walk over holes

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2)

2022-02-28 Thread Patchwork
== Series Details == Series: series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2) URL : https://patchwork.freedesktop.org/series/100771/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22438

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Matthew Wilcox
On Mon, Feb 28, 2022 at 12:37:15PM -0800, Linus Torvalds wrote: > On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote: > > > > Then we can never use -Wshadow ;-( I'd love to be able to turn it on; > > it catches real bugs. > > Oh, we already can never use -Wshadow regardless of things like

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2)

2022-02-28 Thread Patchwork
== Series Details == Series: series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2) URL : https://patchwork.freedesktop.org/series/100771/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2)

2022-02-28 Thread Patchwork
== Series Details == Series: series starting with [CI,1/4] drm/i915: Use str_yes_no() (rev2) URL : https://patchwork.freedesktop.org/series/100771/ State : warning == Summary == $ dim checkpatch origin/drm-tip e9d80367b6a2 drm/i915: Use str_yes_no() -:333: WARNING:LONG_LINE: line length of

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Prepare for Xe_HP compute engines

2022-02-28 Thread Patchwork
== Series Details == Series: i915: Prepare for Xe_HP compute engines URL : https://patchwork.freedesktop.org/series/100833/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22437 Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for HAX: drm/i915: Disable GuC submission on DG1

2022-02-28 Thread Patchwork
== Series Details == Series: HAX: drm/i915: Disable GuC submission on DG1 URL : https://patchwork.freedesktop.org/series/100826/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22436 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: Prepare for Xe_HP compute engines

2022-02-28 Thread Patchwork
== Series Details == Series: i915: Prepare for Xe_HP compute engines URL : https://patchwork.freedesktop.org/series/100833/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Prepare for Xe_HP compute engines

2022-02-28 Thread Patchwork
== Series Details == Series: i915: Prepare for Xe_HP compute engines URL : https://patchwork.freedesktop.org/series/100833/ State : warning == Summary == $ dim checkpatch origin/drm-tip aeab2e429058 drm/i915/xehp: Define compute class and engine 794deed65cd5 drm/i915/xehp: CCS shares the

Re: [Intel-gfx] [PATCH] drm/i915/guc: Fix flag query helper function to not modify state

2022-02-28 Thread Ceraolo Spurio, Daniele
On 2/17/2022 1:29 PM, john.c.harri...@intel.com wrote: From: John Harrison A flag query helper was actually writing to the flags word rather than just reading. Fix that. Also update the function's comment as it was out of date. NB: No need for a 'Fixes' tag. The test was only ever used

Re: [Intel-gfx] [PATCH v7 09/13] drm/i915/guc: Check sizing of guc_capture output

2022-02-28 Thread kernel test robot
Hi Alan, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] [cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next drm/drm-next tegra-drm/drm/tegra/for-next airlied/drm-next v5.17-rc6 next-20220228] [If your patch is applied to the wrong

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread James Bottomley
On Mon, 2022-02-28 at 23:59 +0200, Mike Rapoport wrote: > > On February 28, 2022 10:42:53 PM GMT+02:00, James Bottomley < > james.bottom...@hansenpartnership.com> wrote: > > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote: [...] > > > > I do wish we could actually poison the 'pos' value

[Intel-gfx] ✓ Fi.CI.BAT: success for Kbuild: move to -std=gnu11

2022-02-28 Thread Patchwork
== Series Details == Series: Kbuild: move to -std=gnu11 URL : https://patchwork.freedesktop.org/series/100824/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22435 Summary --- **SUCCESS** No

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Kbuild: move to -std=gnu11

2022-02-28 Thread Patchwork
== Series Details == Series: Kbuild: move to -std=gnu11 URL : https://patchwork.freedesktop.org/series/100824/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✓ Fi.CI.BAT: success for Kbuild: remove -std=gnu89 from compiler arguments

2022-02-28 Thread Patchwork
== Series Details == Series: Kbuild: remove -std=gnu89 from compiler arguments URL : https://patchwork.freedesktop.org/series/100823/ State : success == Summary == CI Bug Log - changes from CI_DRM_11300 -> Patchwork_22434 Summary ---

Re: [Intel-gfx] [PATCH] drm/i915/gt: Clear compress metadata for Xe_HP platforms

2022-02-28 Thread Ramalingam C
Matt, This is the continuation of review happened at https://patchwork.freedesktop.org/patch/475177/?series=100419=1 On 2022-03-01 at 02:51:39 +0530, Ramalingam C wrote: > From: Ayaz A Siddiqui > > Xe-HP and latest devices support Flat CCS which reserved a portion of > the device memory to

[Intel-gfx] [PATCH] drm/i915/gt: Clear compress metadata for Xe_HP platforms

2022-02-28 Thread Ramalingam C
From: Ayaz A Siddiqui Xe-HP and latest devices support Flat CCS which reserved a portion of the device memory to store compression metadata, during the clearing of device memory buffer object we also need to clear the associated CCS buffer. Flat CCS memory can not be directly accessed by S/W.

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread James Bottomley
On Mon, 2022-02-28 at 21:56 +0100, Christian König wrote: > > Am 28.02.22 um 21:42 schrieb James Bottomley: > > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote: > > > Am 28.02.22 um 20:56 schrieb Linus Torvalds: > > > > On Mon, Feb 28, 2022 at 4:19 AM Christian König > > > > wrote: > >

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Kbuild: remove -std=gnu89 from compiler arguments

2022-02-28 Thread Patchwork
== Series Details == Series: Kbuild: remove -std=gnu89 from compiler arguments URL : https://patchwork.freedesktop.org/series/100823/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread James Bottomley
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote: > Am 28.02.22 um 20:56 schrieb Linus Torvalds: > > On Mon, Feb 28, 2022 at 4:19 AM Christian König > > wrote: > > > I don't think that using the extra variable makes the code in any > > > way > > > more reliable or easier to read. > > So I

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 12:29 PM Johannes Berg wrote: > > If we're willing to change the API for the macro, we could do > > list_for_each_entry(type, pos, head, member) > > and then actually take advantage of -Wshadow? See my reply to Willy. There is no way -Wshadow will ever happen. I

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote: > > Then we can never use -Wshadow ;-( I'd love to be able to turn it on; > it catches real bugs. Oh, we already can never use -Wshadow regardless of things like this. That bridge hasn't just been burned, it never existed in the first

Re: [Intel-gfx] [PATCH v5 7/7] drm/i915/gt: Adding new sysfs frequency attributes

2022-02-28 Thread Michal Wajdeczko
On 17.02.2022 15:41, Andi Shyti wrote: > From: Sujaritha Sundaresan > > This patch adds the following new sysfs frequency attributes; > - punit_req_freq_mhz > - throttle_reason_status > - throttle_reason_pl1 > - throttle_reason_pl2 > - throttle_reason_pl4 >

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Johannes Berg
On Mon, 2022-02-28 at 20:16 +, Matthew Wilcox wrote: > On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote: > > We can do > > > > typeof(pos) pos > > > > in the 'for ()' loop, and never use __iter at all. > > > > That means that inside the for-loop, we use a _different_

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Matthew Wilcox
On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote: > We can do > > typeof(pos) pos > > in the 'for ()' loop, and never use __iter at all. > > That means that inside the for-loop, we use a _different_ 'pos' than outside. Then we can never use -Wshadow ;-( I'd love to be

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds wrote: > > We can do > > typeof(pos) pos > > in the 'for ()' loop, and never use __iter at all. > > That means that inside the for-loop, we use a _different_ 'pos' than outside. The thing that makes me throw up in my mouth a bit is that in

[Intel-gfx] [PATCH] drm/i915: Add a DP1.2 compatible way to read LTTPR capabilities

2022-02-28 Thread Imre Deak
At least some DELL monitors (P2715Q) with DPCD_REV 1.2 return corrupted DPCD register values when reading from the 0xF- LTTPR range with an AUX transaction block size bigger than 1. The DP standard requires 0 to be returned - as for any other reserved/invalid addresses - but these monitors

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 12:03 PM Linus Torvalds wrote: > > Side note: we do need *some* way to do it. Ooh. This patch is a work of art. And I mean that in the worst possible way. We can do typeof(pos) pos in the 'for ()' loop, and never use __iter at all. That means that inside the

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 11:56 AM Linus Torvalds wrote: > > I do wish we could actually poison the 'pos' value after the loop > somehow - but clearly the "might be uninitialized" I was hoping for > isn't the way to do it. Side note: we do need *some* way to do it. Because if we make that change,

Re: [Intel-gfx] [PATCH v5 3/7] drm/i915/gt: add gt_is_root() helper

2022-02-28 Thread Michal Wajdeczko
On 17.02.2022 15:41, Andi Shyti wrote: > The "gt_is_root(struct intel_gt *gt)" helper return true if the > gt is the root gt, which means that its id is 0. Return false > otherwise. > > Suggested-by: Michal Wajdeczko > Signed-off-by: Andi Shyti > --- > drivers/gpu/drm/i915/gt/intel_gt.h | 5

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915/ttm: make eviction mappable aware

2022-02-28 Thread Patchwork
== Series Details == Series: series starting with [CI,1/4] drm/i915/ttm: make eviction mappable aware URL : https://patchwork.freedesktop.org/series/100818/ State : success == Summary == CI Bug Log - changes from CI_DRM_11299 -> Patchwork_22433

Re: [Intel-gfx] [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 4:19 AM Christian König wrote: > > I don't think that using the extra variable makes the code in any way > more reliable or easier to read. So I think the next step is to do the attached patch (which requires that "-std=gnu11" that was discussed in the original thread).

Re: [Intel-gfx] [PATCH v5 1/7] drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0

2022-02-28 Thread Michal Wajdeczko
On 17.02.2022 15:41, Andi Shyti wrote: > With the upcoming multitile support each tile will have its own > local memory. Mark the current LMEM with the suffix '0' to > emphasise that it belongs to the root tile. > > Suggested-by: Michal Wajdeczko > Signed-off-by: Andi Shyti > --- >

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Prep work for next GuC release (rev3)

2022-02-28 Thread John Harrison
On 2/24/2022 20:43, Patchwork wrote: Project List - Patchwork *Patch Details* *Series:* Prep work for next GuC release (rev3) *URL:* https://patchwork.freedesktop.org/series/99805/ *State:*success *Details:* https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22404/index.html

[Intel-gfx] [CI 0/2] drm/mm: Add an iterator to optimally walk over holes suitable for an allocation

2022-02-28 Thread Vivek Kasireddy
The first patch is a drm core patch that replaces the for loop in drm_mm_insert_node_in_range() with the iterator and would not cause any functional changes. The second patch is a i915 driver specific patch that also uses the iterator but solves a different problem. v2: - Added a new patch to

[Intel-gfx] [CI 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)

2022-02-28 Thread Vivek Kasireddy
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or more framebuffers/scanout buffers results in only one that is mappable/ fenceable. Therefore, pageflipping between these 2 FBs where only one is mappable/fenceable creates latencies large enough to miss alternate vblanks thereby

[Intel-gfx] [CI 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v5)

2022-02-28 Thread Vivek Kasireddy
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole() functions to identify suitable holes for an allocation of a given size by efficiently traversing the rbtree associated with the given allocator. It replaces the for loop in drm_mm_insert_node_in_range() and can also be used by drm

Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads

2022-02-28 Thread John Harrison
On 2/28/2022 07:32, Tvrtko Ursulin wrote: On 25/02/2022 19:03, John Harrison wrote: On 2/25/2022 10:29, Tvrtko Ursulin wrote: On 25/02/2022 18:01, John Harrison wrote: On 2/25/2022 09:39, Tvrtko Ursulin wrote: On 25/02/2022 17:11, John Harrison wrote: On 2/25/2022 08:36, Tvrtko Ursulin

Re: [Intel-gfx] [CI 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v4)

2022-02-28 Thread Kasireddy, Vivek
Hi Tvrtko, > > Hi Vivek, > > On 27/02/2022 17:29, Vivek Kasireddy wrote: > > This iterator relies on drm_mm_first_hole() and drm_mm_next_hole() > > functions to identify suitable holes for an allocation of a given > > size by efficiently traversing the rbtree associated with the given > >

Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts

2022-02-28 Thread John Harrison
On 2/28/2022 09:12, Tvrtko Ursulin wrote: On 25/02/2022 18:48, John Harrison wrote: On 2/25/2022 10:14, Tvrtko Ursulin wrote: I'll try to simplify the discussion here: On 24/02/2022 19:45, John Harrison wrote: On 2/24/2022 03:41, Tvrtko Ursulin wrote: On 23/02/2022 20:00, John Harrison

Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11

2022-02-28 Thread Linus Torvalds
On Mon, Feb 28, 2022 at 3:37 AM Arnd Bergmann wrote: > > I think the KBUILD_USERCFLAGS portion and the modpost.c fix for it > make sense regardless of the -std=gnu11 change I do think they make sense, but I want to note again that people doing cross builds obviously use different tools for user

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Limit scheduling properties to avoid overflow

2022-02-28 Thread John Harrison
On 2/28/2022 08:11, Tvrtko Ursulin wrote: On 25/02/2022 17:39, John Harrison wrote: On 2/25/2022 09:06, Tvrtko Ursulin wrote: On 24/02/2022 19:19, John Harrison wrote: [snip] ./gt/uc/intel_guc_fwif.h: u32 execution_quantum; ./gt/uc/intel_guc_submission.c: desc->execution_quantum =

Re: [Intel-gfx] [PATCH 1/6] drivers: usb: remove usage of list iterator past the loop body

2022-02-28 Thread Joe Perches
On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote: > a multi-line indent gets curly braces for readability even though > it's not required by C. And then both sides would get curly braces. That's more your personal preference than a coding style guideline.

[Intel-gfx] ✗ Fi.CI.IGT: failure for Fix prime_mmap to work when using LMEM (rev2)

2022-02-28 Thread Patchwork
== Series Details == Series: Fix prime_mmap to work when using LMEM (rev2) URL : https://patchwork.freedesktop.org/series/100737/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11297_full -> Patchwork_22432_full Summary

[Intel-gfx] [PATCH v2 08/13] drm/i915/xehp/guc: enable compute engine inside GuC

2022-02-28 Thread Matt Roper
From: Daniele Ceraolo Spurio Tell GuC that CCS is enabled by setting a bit in its ADS. Cc: Vinay Belgaumkar Original-author: Michel Thierry Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt_regs.h| 3 +++

[Intel-gfx] [PATCH v2 11/13] drm/i915/xehp: handle fused off CCS engines

2022-02-28 Thread Matt Roper
From: Daniele Ceraolo Spurio HW resources are divided across the active CCS engines at the compute slice level, with each CCS having priority on one of the cslices. If a compute slice has no enabled DSS, its paired compute engine is not usable in full parallel execution because the other ones

[Intel-gfx] [PATCH v2 09/13] drm/i915/xehp: Enable ccs/dual-ctx in RCU_MODE

2022-02-28 Thread Matt Roper
We have to specify in the Render Control Unit Mode register when CCS is enabled. v2: - Move RCU_MODE programming to a helper function. (Tvrtko) - Clean up and clarify comments. (Tvrtko) - Add RCU_MODE to the GuC save/restore list. (Daniele) Bspec: 46034 Original-author: Michel Thierry Cc:

[Intel-gfx] [PATCH v2 13/13] drm/i915/xehpsdv: Move render/compute engine reset domains related workarounds

2022-02-28 Thread Matt Roper
From: Srinivasan Shanmugam Registers that exist in the shared render/compute reset domain need to be placed on an engine workaround list to ensure that they are properly re-applied whenever an RCS or CCS engine is reset. We have a number of workarounds (updating registers MLTICTXCTL,

[Intel-gfx] [PATCH v2 10/13] drm/i915/xehp: Don't support parallel submission on compute / render

2022-02-28 Thread Matt Roper
From: Matthew Brost A different emit breadcrumbs ring programming is required for compute / render and we don't have UMD user so just reject parallel submission for these engine classes. Signed-off-by: Matthew Brost Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gem/i915_gem_context.c

[Intel-gfx] [PATCH v2 04/13] drm/i915/xehp: compute engine pipe_control

2022-02-28 Thread Matt Roper
From: Daniele Ceraolo Spurio CCS will reuse the RCS functions for breadcrumb and flush emission. However, CCS pipe_control has additional programming restrictions: - Command Streamer Stall Enable must be always set - Post Sync Operations must not be set to Write PS Depth Count - 3D-related

[Intel-gfx] [PATCH v2 12/13] drm/i915/xehp: Add compute workarounds

2022-02-28 Thread Matt Roper
Additional workarounds are required once we start exposing CCS engines. Note that we have a number of workarounds that update registers in the shared render/compute reset domain. Historically we've just added such registers to the RCS engine's workaround list. But going forward we should be

[Intel-gfx] [PATCH v2 06/13] drm/i915: Move context descriptor fields to intel_lrc.h

2022-02-28 Thread Matt Roper
This is a more appropriate header for these definitions. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 34 --- drivers/gpu/drm/i915/gt/intel_lrc.h | 34 +++ 3 files

[Intel-gfx] [PATCH v2 07/13] drm/i915/xehp: Define context scheduling attributes in lrc descriptor

2022-02-28 Thread Matt Roper
In Dual Context mode the EUs are shared between render and compute command streamers. The hardware provides a field in the lrc descriptor to indicate the prioritization of the thread dispatch associated to the corresponding context. The context priority is set to 'low' at creation time and relies

[Intel-gfx] [PATCH v2 02/13] drm/i915/xehp: CCS shares the render reset domain

2022-02-28 Thread Matt Roper
The reset domain is shared between render and all compute engines, so resetting one will affect the others. Note: Before performing a reset on an RCS or CCS engine, the GuC will attempt to preempt-to-idle the other non-hung RCS/CCS engines to avoid impacting other clients (since some shared

[Intel-gfx] [PATCH v2 01/13] drm/i915/xehp: Define compute class and engine

2022-02-28 Thread Matt Roper
Introduce a Compute Command Streamer (CCS), which has access to the media and GPGPU pipelines (but not the 3D pipeline). To begin with, define the compute class/engine common functions, based on the existing render ones. v2: - Add kerneldoc for drm_i915_gem_engine_class since we're adding a new

[Intel-gfx] [PATCH v2 05/13] drm/i915/xehp: CCS should use RCS setup functions

2022-02-28 Thread Matt Roper
The compute engine handles the same commands the render engine can (except 3D pipeline), so it makes sense that CCS is more similar to RCS than non-render engines. The CCS context state (lrc) is also similar to the render one, so reuse it. Note that the compute engine has its own

[Intel-gfx] [PATCH v2 03/13] drm/i915/xehp: Add Compute CS IRQ handlers

2022-02-28 Thread Matt Roper
Add execlists and GuC interrupts for compute CS into existing IRQ handlers. All compute command streamers belong to the same compute class, so the only change needed to enable their interrupts is to program their GT engine interrupt mask registers. CCS0 shares the register with CCS1, while CCS2

[Intel-gfx] [PATCH v2 00/13] i915: Prepare for Xe_HP compute engines

2022-02-28 Thread Matt Roper
The Xe_HP architecture introduces compute engines as a new engine class. These compute command streamers (CCS) are similar to the render engine, except that they're intended for GPGPU usage and lack support for the 3D pipeline. For now we're just sending some initial "under the hood" preparation

[Intel-gfx] [PATCH v8 00/13] Add GuC Error Capture Support

2022-02-28 Thread Alan Previn
This series: 1. Enables support of GuC to report error-state-capture using a list of MMIO registers the driver registers and GuC will dump, log and notify right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register said lists of global,

Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Make the heartbeat play nice with long pre-emption timeouts

2022-02-28 Thread Tvrtko Ursulin
On 25/02/2022 18:48, John Harrison wrote: On 2/25/2022 10:14, Tvrtko Ursulin wrote: I'll try to simplify the discussion here: On 24/02/2022 19:45, John Harrison wrote: On 2/24/2022 03:41, Tvrtko Ursulin wrote: On 23/02/2022 20:00, John Harrison wrote: On 2/23/2022 05:58, Tvrtko Ursulin

[Intel-gfx] [PATCH v8 00/13] Add GuC Error Capture Support

2022-02-28 Thread Alan Previn
This series: 1. Enables support of GuC to report error-state-capture using a list of MMIO registers the driver registers and GuC will dump, log and notify right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register said lists of global,

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Limit scheduling properties to avoid overflow

2022-02-28 Thread Tvrtko Ursulin
On 25/02/2022 17:39, John Harrison wrote: On 2/25/2022 09:06, Tvrtko Ursulin wrote: On 24/02/2022 19:19, John Harrison wrote: [snip] ./gt/uc/intel_guc_fwif.h: u32 execution_quantum; ./gt/uc/intel_guc_submission.c: desc->execution_quantum = engine->props.timeslice_duration_ms * 1000;

[Intel-gfx] [PATCH] HAX: drm/i915: Disable GuC submission on DG1

2022-02-28 Thread Thomas Hellström
This is just to try to repro the execlist selftest failure I'm seeing on my local DG1 with GuC submission disabled. Signed-off-by: Thomas Hellström --- drivers/gpu/drm/i915/gt/uc/intel_uc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c

Re: [Intel-gfx] [PATCH 0/3] Improve anti-pre-emption w/a for compute workloads

2022-02-28 Thread Tvrtko Ursulin
On 25/02/2022 19:03, John Harrison wrote: On 2/25/2022 10:29, Tvrtko Ursulin wrote: On 25/02/2022 18:01, John Harrison wrote: On 2/25/2022 09:39, Tvrtko Ursulin wrote: On 25/02/2022 17:11, John Harrison wrote: On 2/25/2022 08:36, Tvrtko Ursulin wrote: On 24/02/2022 20:02, John Harrison

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dmabuf: Update dma_buf_ops.unmap_dma_buf callback to use drm_gem_unmap_dma_buf()

2022-02-28 Thread Das, Nirmoy
Reviewed-by: Nirmoy Das On 25/02/2022 14:13, Gwan-gyeong Mun wrote: The dma_buf_ops.unmap_dma_buf callback used in i915, i915_gem_unmap_dma_buf(), has the same code as drm_gem_unmap_dma_buf(). In order to eliminate defining and using duplicate function, it updates the dma_buf_ops.unmap_dma_buf

[Intel-gfx] ✓ Fi.CI.BAT: success for Fix prime_mmap to work when using LMEM (rev2)

2022-02-28 Thread Patchwork
== Series Details == Series: Fix prime_mmap to work when using LMEM (rev2) URL : https://patchwork.freedesktop.org/series/100737/ State : success == Summary == CI Bug Log - changes from CI_DRM_11297 -> Patchwork_22432 Summary ---

Re: [Intel-gfx] [PATCH] Kbuild: remove -std=gnu89 from compiler arguments

2022-02-28 Thread John Stoffel
On Sun, Feb 27, 2022 at 10:52:43PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > During a patch discussion, Linus brought up the option of changing > the C standard version from gnu89 to gnu99, which allows using variable > declaration inside of a for() loop. While the C99, C11 and later

Re: [Intel-gfx] [greybus-dev] [PATCH] Kbuild: remove -std=gnu89 from compiler arguments

2022-02-28 Thread Alex Elder
On 2/27/22 5:11 PM, Linus Torvalds wrote: On Sun, Feb 27, 2022 at 3:04 PM Alex Elder wrote: Glancing at the Greybus code, I don't believe there's any reason it needs to shift a negative value. Such warnings could be fixed by making certain variables unsigned, for example. As mentioned in

[Intel-gfx] [PATCH 0/6] Remove usage of list iterator past the loop body

2022-02-28 Thread Jakob Koschel
This is the first patch removing several categories of use cases of the list iterator variable past the loop. This is follow up to the discussion in: https://lore.kernel.org/all/20220217184829.1991035-1-jakobkosc...@gmail.com/ As concluded in:

Re: [Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11

2022-02-28 Thread Arnd Bergmann
On Mon, Feb 28, 2022 at 12:47 PM Marco Elver wrote: > On Mon, 28 Feb 2022 at 11:32, Arnd Bergmann wrote: > > > Nathan Chancellor reported an additional -Wdeclaration-after-statement > > warning that appears in a system header on arm, this still needs a > > workaround. > > On the topic of

Re: [Intel-gfx] [PATCH] Kbuild: remove -std=gnu89 from compiler arguments

2022-02-28 Thread Arnd Bergmann
On Mon, Feb 28, 2022 at 1:14 AM John Stoffel wrote: > > On Sun, Feb 27, 2022 at 10:52:43PM +0100, Arnd Bergmann wrote: > > From: Arnd Bergmann > > > > During a patch discussion, Linus brought up the option of changing > > the C standard version from gnu89 to gnu99, which allows using variable >

[Intel-gfx] [PATCH] [v2] Kbuild: move to -std=gnu11

2022-02-28 Thread Arnd Bergmann
From: Arnd Bergmann During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already

  1   2   >