== Series Details ==
Series: drm/edid: overhaul displayid iterator
URL : https://patchwork.freedesktop.org/series/87802/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3dfb9f5009ca drm/edid: make a number of functions, parameters and variables
const
02e11a7ac9cc drm/displayid:
== Series Details ==
Series: drm/edid: overhaul displayid iterator
URL : https://patchwork.freedesktop.org/series/87802/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amd
== Series Details ==
Series: drm/edid: overhaul displayid iterator
URL : https://patchwork.freedesktop.org/series/87802/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9844 -> Patchwork_19770
Summary
---
**FAILURE**
== Series Details ==
Series: drm/edid: overhaul displayid iterator (rev2)
URL : https://patchwork.freedesktop.org/series/87802/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4c9b64816221 drm/edid: make a number of functions, parameters and variables
const
6e714eb67565 drm/disp
== Series Details ==
Series: drm/edid: overhaul displayid iterator (rev2)
URL : https://patchwork.freedesktop.org/series/87802/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/
== Series Details ==
Series: drm/edid: overhaul displayid iterator (rev2)
URL : https://patchwork.freedesktop.org/series/87802/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9844 -> Patchwork_19771
Summary
---
**SUCC
Hi,
On 08/03/2021 17:32, Chiou, Cooper wrote:
I've tested on GLK, KBL, CFL Intel NUC devices and got the following
performance results, there is no performance regression per my testing.
Patch: [v5] drm/i915: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads for
Gen9
Test suite:
phoroni
Quoting Tvrtko Ursulin (2021-03-10 10:19:12)
>
> Hi,
>
> On 08/03/2021 17:32, Chiou, Cooper wrote:
> > I've tested on GLK, KBL, CFL Intel NUC devices and got the following
> > performance results, there is no performance regression per my testing.
> >
> > Patch: [v5] drm/i915: Enable WaProgramM
eb_copy_relocations() only do unsafe_put_user(), it only
requires write access to user.
Use user_write_access_begin() instead of user_access_begin().
Signed-off-by: Christophe Leroy
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
d
== Series Details ==
Series: drm/i915/gem: Use user_write_access_begin() instead of
user_access_begin()
URL : https://patchwork.freedesktop.org/series/87834/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9844 -> Patchwork_19772
On Tue, Mar 09, 2021 at 10:09:13AM +0530, Ankit Nautiyal wrote:
> Currently the FRL training mode (Concurrent, Sequential) and
> training type (Normal, Extended) are not defined properly and
> are passed as bool values in drm_helpers for pcon
> configuration for FRL training.
>
> This patch:
> -Ad
On Tue, Mar 09, 2021 at 03:54:09PM +0200, Jani Nikula wrote:
> If there's no need to change it, it should be const. There's more to be
> done, but start off with changes that make follow-up work easier. No
> functional changes.
>
> Signed-off-by: Jani Nikula
const is good.
Reviewed-by: Ville Sy
On Tue, Mar 09, 2021 at 03:54:10PM +0200, Jani Nikula wrote:
> We'll be adding more DisplayID specific functions going forward, so
> start off by splitting out a few functions to a separate file.
>
> We don't bother with exporting the functions; at least for now they
> should be needed solely with
On Tue, Mar 09, 2021 at 03:54:11PM +0200, Jani Nikula wrote:
> Iterating DisplayID blocks across sections (in EDID extensions) is
> unnecessarily complicated for the caller. Implement DisplayID iterators
> to go through all blocks in all sections.
>
> Usage example:
>
> const struct display
On Tue, Mar 09, 2021 at 03:54:12PM +0200, Jani Nikula wrote:
> Neatly reduce displayid boilerplate in code. No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 23 ++-
> 1 file changed, 6 insertions(+), 17 d
On Tue, Mar 09, 2021 at 03:54:13PM +0200, Jani Nikula wrote:
> Neatly reduce displayid boilerplate in code. No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 25 +
> 1 file changed, 9 insertions(+), 16
On Tue, Mar 09, 2021 at 03:54:14PM +0200, Jani Nikula wrote:
> Neatly reduce displayid boilerplate in code. Remove excessive debug
> logging while at it, no other functional changes.
>
> The old displayid iterator becomes unused; remove it as well as make
> drm_find_displayid_extension() static.
>
From: Ville Syrjälä
Let's check that we actually found the PLL before doing the
port_clock readout, just in case the hardware is severly
misprogramming by the previous guy. Not sure the hw would
even survive such misprogramming without hanging but no
real harm in checking anyway.
Cc: Karthik B S
libdrm has supported the newer execbuffer2 ioctl and using it by default
when it exists since libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22
which landed Mar 2, 2010. The i915 and i965 drivers in Mesa at the time
both used libdrm and so did the Intel X11 back-end. The SNA back-end
for X11
== Series Details ==
Series: drm/i915: Tolerate bogus DPLL selection
URL : https://patchwork.freedesktop.org/series/87852/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9845 -> Patchwork_19773
Summary
---
**SUCCESS**
== Series Details ==
Series: i915: Drop legacy execbuffer support
URL : https://patchwork.freedesktop.org/series/87854/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1d49bdae0f72 i915: Drop legacy execbuffer support
-:7: ERROR:GIT_COMMIT_ID: Please use git commit description st
The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations. The older i965
driver in Mesa
== Series Details ==
Series: i915: Drop legacy execbuffer support
URL : https://patchwork.freedesktop.org/series/87854/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9845 -> Patchwork_19774
Summary
---
**SUCCESS**
On Fri, Jan 22, 2021 at 4:40 PM Ashutosh Dixit wrote:
>
> The guidance for i915 at this time is to start phasing out pread/pwrite
> ioctl's, the rationale being (a) the functionality can be done entirely in
> userspace with a combination of mmap + memcpy, and (b) no existing user
> mode clients ac
== Series Details ==
Series: RFC: i915: Drop relocation support on Gen12+ (rev2)
URL : https://patchwork.freedesktop.org/series/77048/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
35a435752bf5 i915: Drop relocation support on all new hardware
-:49: WARNING:AVOID_BUG: Avoid cra
From: Sean Paul
This patch adds some newlines which are missing from debug messages.
This will prevent logs from being stacked up in dmesg.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
From: Sean Paul
One instance of DRM_DEBUG_KMS was leftover in dp_link_training, convert
it to the new shiny.
Signed-off-by: Sean Paul
---
.../gpu/drm/i915/display/intel_dp_link_training.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/d
The Vulkan driver in Mesa for Intel hardware never uses relocations if
it's running on a version of i915 that supports at least softpin which
all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is
only supported by iris which never uses relocations. The older i965
driver in Mesa
== Series Details ==
Series: RFC: i915: Drop relocation support on Gen12+ (rev2)
URL : https://patchwork.freedesktop.org/series/77048/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9845 -> Patchwork_19775
Summary
---
An upcoming platform requires the stride of tiled display surfaces to be
power-of-two aligned. This patch adds support for this using the FB
remapping logic.
Until the functionality is fully enabled we keep testing it via the
vma selftests and by the last patch which forces the padding on for all
The expected/found values were swapped in a debug message, fix this up.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
b/drivers/gpu/drm/i915/selftests/i915_vma.
The HW plane state is cleared and inited after we store the rotation to
it, so store it instead to the uapi state to match what we do with all
other plane state until intel_plane_copy_uapi_to_hw_state() is called.
Rotation for initial FBs is not supported atm, but let's still fix the
plane state s
This probably doesn't cause an issue, since the code checks the view
type dependent size of the views before comparing them, but let's follow
the practice to bzero the whole struct when initializing it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 2 ++
1 file chan
An inner scope version of err shadows the variable in the outer scope,
and err doesn't get set after a failure, fix these.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/i91
Start collecting all the FB plane related functions into a new intel_fb.c
file.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 1 +
.../drm/i915/display/intel_display_types.h| 19 -
drivers/gpu/d
Remove the duplicate function declaration from the header file.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 216047
This probably doesn't cause an issue, since the code checks the view
type dependent size of the views before comparing them, but let's follow
the practice to bzero the whole struct when initializing it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +-
1 file changed
Move the FB plane specific function from intel_sprite.c to intel_fb.c
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_fb.c | 32 +
drivers/gpu/drm/i915/display/intel_fb.h | 4 +++
drivers/gpu/drm/i915/display/intel_sprite.c | 32 -
Move the FB plane related functions from skl_universal_plane.c to
intel_fb.c.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_fb.c | 32 +
drivers/gpu/drm/i915/display/intel_fb.h | 4 +++
.../drm/i915/display/skl_universal_plane.c| 34
Move is_surface_linear() to intel_fb.c and export it from here, also
removing the duplicate definitions of it.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 6 --
drivers/gpu/drm/i915/display/intel_fb.c| 6 ++
drivers/gpu/drm/i915/display/i
After the previous patch we can unexport intel_fb_check_stride(), which
isn't needed by intel_display.c.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_fb.c | 2 +-
drivers/gpu/drm/i915/display/intel_fb.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/driv
Factor out to a new function the logic to convert the FB plane offset to
x/y and check the validity of x/y, with the goal to make
intel_fill_fb_info() more readable.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_fb.c | 70 +++--
1 file changed, 42 insertions
Factor out to a new function the logic to convert the FB plane x/y
values to a tile size based offset and new x/y relative to this offset.
This makes intel_fill_fb_info() and intel_plane_remap_gtt() somewhat
more readable.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_fb.c | 26
Move the FB plane specific functions from intel_display.c to intel_fb.c.
There's more functions like this, but I leave moving those as well for a
follow up, and for now moving only the ones needed by the end of this
patchset (adding support for padding tile-rows in an FB GGTT view).
Signed-off-by:
Rename dev_priv to i915 in the intel_fb.[ch] files.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_fb.c | 66 -
drivers/gpu/drm/i915/display/intel_fb.h | 6 +--
2 files changed, 36 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/display
Factor out to a new function the logic to calculate the FB remapping
parameters both during creating the FB and when flipping to it.
Add a new intel_fb_plane_remap_info() that can be used by a new remapped
view set up when creating the FB in a follow up patch.
Signed-off-by: Imre Deak
---
.../d
An upcoming patch adds a new dst_stride field to the
intel_remapped_plane_info struct, so for clarity rename the current
stride field to src_stride.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_fb.c | 12 ++---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 +-
drivers/gpu/d
Factor out to a new function the logic to calculate an FB plane's
normal-view size.
Instead of using intel_remapped_plane_info, which is related only to
remapping, add a helper to get the tile pitch and rows for an FB plane,
so these helpers can be used both by the normal size calculation and the
Save some place in the GTT VMAs by using a u16 instead of unsigned int
to store the view dimensions. The maximum FB stride is 256kB which is
4096 tiles in the worst case (yf-tiles), the maximum FB height is 16k
pixels, which is 2048 tiles in the worst case (x-tiles).
Signed-off-by: Imre Deak
---
An upcoming platform has a restriction that the FB stride must be
power-of-two aligned. To support framebuffer layouts that are not in
this layout add a logic that pads the tile rows to the POT aligned size.
The HW won't read the padding PTEs, so these don't have to point to an
allocated address,
To test the POT stride padding functionality until it's taken into use
by the actual platform needing it, enable the padding whenever the FB
remapping is possible. An exception is to pad linear FBs when this would
be otherwise possible (stride is page size aligned), because this won't
be anyway nee
Always use the modified copy of the intel_remapped_plane_info variables.
An upcoming patch updates the dst_stride field in these copies after
which we can't use the original versions.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/selftests/i915_vma.c | 61 ---
1 file chan
Add selftests to test the POT stride padding functionality added in the
previous patch.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/selftests/i915_vma.c | 93 +--
1 file changed, 86 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
b
== Series Details ==
Series: series starting with [1/2] drm/i915/dp_link_training: Add newlines to
debug messages
URL : https://patchwork.freedesktop.org/series/87858/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9845 -> Patchwork_19776
==
== Series Details ==
Series: drm/i915: Tolerate bogus DPLL selection
URL : https://patchwork.freedesktop.org/series/87852/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9845_full -> Patchwork_19773_full
Summary
---
*
+Zbigniew for review
On Wed, Mar 10, 2021 at 3:50 PM Jason Ekstrand wrote:
>
> The Vulkan driver in Mesa for Intel hardware never uses relocations if
> it's running on a version of i915 that supports at least softpin which
> all versions of i915 supporting Gen12 do. On the OpenGL side, Gen12+ is
== Series Details ==
Series: RFC: i915: Drop relocation support on Gen12+ (rev3)
URL : https://patchwork.freedesktop.org/series/77048/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9846 -> Patchwork_19777
Summary
---
== Series Details ==
Series: i915: Drop legacy execbuffer support
URL : https://patchwork.freedesktop.org/series/87854/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9845_full -> Patchwork_19774_full
Summary
---
**FA
== Series Details ==
Series: drm/i915: Add support for FBs requiring a POT stride padding
URL : https://patchwork.freedesktop.org/series/87859/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5ddacca7a473 drm/i915: Fix rotation setup during plane HW readout
40363381f9ec drm/i915/
== Series Details ==
Series: drm/i915: Add support for FBs requiring a POT stride padding
URL : https://patchwork.freedesktop.org/series/87859/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+dr
== Series Details ==
Series: drm/i915: Add support for FBs requiring a POT stride padding
URL : https://patchwork.freedesktop.org/series/87859/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9846 -> Patchwork_19778
Summary
-
== Series Details ==
Series: series starting with [1/2] drm/i915/dp_link_training: Add newlines to
debug messages
URL : https://patchwork.freedesktop.org/series/87858/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9845_full -> Patchwork_19776_full
> From: Tvrtko Ursulin
> Hi,
>
> On 08/03/2021 17:32, Chiou, Cooper wrote:
> > I've tested on GLK, KBL, CFL Intel NUC devices and got the following
> performance results, there is no performance regression per my testing.
> >
> > Patch: [v5] drm/i915: Enable
> > WaProgramMgsrForCorrectSliceSpecif
Jason Ekstrand writes:
> libdrm has supported the newer execbuffer2 ioctl and using it by default
> when it exists since libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22
> which landed Mar 2, 2010. The i915 and i965 drivers in Mesa at the time
> both used libdrm and so did the Intel X11 ba
== Series Details ==
Series: RFC: i915: Drop relocation support on Gen12+ (rev3)
URL : https://patchwork.freedesktop.org/series/77048/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9846_full -> Patchwork_19777_full
Summary
> The issue is that if the regression is reproducible it means that the
> broadcast
> mask is no longer correct (or never was, one or the other ;) And another w/a
> is going astray because it depends on the previous undefined value of the
> mcr.
[Chiou, Cooper] I think we might focus on this w/a
On 3/11/2021 1:13 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Let's check that we actually found the PLL before doing the
port_clock readout, just in case the hardware is severly
misprogramming by the previous guy. Not sure the hw would
even survive such misprogramming without hanging but no
r
67 matches
Mail list logo
