== Series Details ==
Series: series starting with [1/6] drm/i915/gt: Protect signaler walk with RCU
URL : https://patchwork.freedesktop.org/series/73691/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7970 -> Patchwork_16642
> -Original Message-
> From: Intel-gfx On Behalf Of Manasi
> Navare
> Sent: Friday, February 14, 2020 5:11 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [CI v3 1/3] drm/i915: Introduce
> encoder->compute_config_late()
>
> From: Ville Syrjälä
>
> Add an optional seco
On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
On 2/18/20 10:01 PM, Daniel Vetter wrote:
On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
wrote:
On 2/17/20 6:55 PM, Daniel Vetter wrote:
On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
Implement the importer sid
If the blitter is not available, we cannot use it as a source for dirty
rectangles. We shall have to rely on the other engines to create GPU
dirty instead.
v2: Try using lots of subgroup+fixtures
Signed-off-by: Chris Wilson
---
tests/kms_frontbuffer_tracking.c | 57 +
We use the GPU to convert between tiling formats, indirectly via the
call to igt_create_pattern_fb. So before we try and execute commands on
the GPU, we should check that the GPU is available.
Signed-off-by: Chris Wilson
---
tests/kms_flip_tiling.c | 1 +
1 file changed, 1 insertion(+)
diff --g
The draw-method-blt subtests require a working GPU, so create a subtest
group for the draw-methods, and skip the BLT group using
igt_require_gem() in its fixture.
Signed-off-by: Chris Wilson
---
tests/kms_draw_crc.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(
> -Original Message-
> From: Intel-gfx On Behalf Of Manasi
> Navare
> Sent: Friday, February 14, 2020 5:11 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [CI v3 3/3] drm/i915/dp: Add all tiled and port sync
> conns to
> modeset
>
> If one of the synced crtcs needs a fu
I see I missed some commits in the actual tag, but I fixed this below.
drm-misc-fixes-2020-02-20:
drm-misc-fixes for v5.6-rc3:
- Fix dt binding for sunxi.
- Allow only 1 rotation argument, and allow 0 rotation in video cmdline.
- Small compiler warning fix for panfrost.
- Fix when using performan
On Wed, 19 Feb 2020, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable initialization feature, thi
On Wed, 19 Feb 2020, Andi Shyti wrote:
> The GT has its own properties and in sysfs they should be grouped
> in the 'gt/' directory.
>
> Create the 'gt/' directory in sysfs and move the power management
> related files.
>
> The new interfaces are:
>
> gt/gt_act_freq_mhz
> gt/gt_boost_freq_mhz
> gt
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Let's just calculate the hsync rate on demand. No point in wasting
> space storing it and risking the cached value getting out of sync
> with reality.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_mode
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Signed-off-by: Ville Syrjälä
Reviewed-by: Emil Velikov
-
The real one can be found in i915_scheduler.c.
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 6daf18dbb3d4..dbd88
Quoting Matthew Auld (2020-02-20 10:57:07)
> The real one can be found in i915_scheduler.c.
>
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
You're not a fan of redundancy, I see :)
Oops,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The drrs code dereferences mode->vrefresh via some really long chain
> of structures/pointers. Couldn't get coccinelle to see through all
> that so let's add some local variables to help it.
>
There's a limit to the ma
Hi Dave & Daniel -
Due to issues in s2idle in v5.6-rc2, I've gotten CI results on these
with two hack reverts on top, and I threw them out just before making
the pull request. I had to revert:
fdde0ff8590b ("ACPI: PM: s2idle: Prevent spurious SCIs from waking up the
system")
e3728b50cd9b ("ACP
On Thu, 7 Nov 2019 at 15:17, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> We have a nice little helper to compute a single LUT entry
> for everything except the 8bpc legacy gamma mode. Let's
> complete the set.
>
At a later stage one could rename this & the 10bit one, moving them to
include/d
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> The driver never sets mode->private_flags so copying
> it back and forth is entirely pointless. Stop doing it.
>
> Also drop private_flags from the tracepoint.
>
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: linux-arm-...@vg
== Series Details ==
Series: series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14
URL : https://patchwork.freedesktop.org/series/73586/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16603_full
=
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Get rid of mode->vrefresh and just calculate it on demand. Saves
> a bit of space and avoids the cached value getting out of sync
> with reality.
>
> Mostly done with cocci, with the following manual fixups:
> - Remove
== Series Details ==
Series: drm/i915: remove the other slab_dependencies
URL : https://patchwork.freedesktop.org/series/73701/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7972 -> Patchwork_16643
Summary
---
**FAIL
We need a new PCode request commands and reply codes
to be added as a prepartion patch for QGV points
restricting for new SAGV support.
v2: - Extracted those changes into separate patch
(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/i915_reg.h | 4
Currently intel_can_enable_sagv function contains
a mix of workarounds for different platforms
some of them are not valid for gens >= 11 already,
so lets split it into separate functions.
v2:
- Rework watermark calculation algorithm to
attempt to calculate Level 0 watermark
with ad
For future Gen12 SAGV implementation we need to
seemlessly alter wm levels calculated, depending
on whether we are allowed to enable SAGV or not.
So this accessor will give additional flexibility
to do that.
Currently this accessor is still simply working
as "pass-through" function. This will be
We might be willing to call intel_atomic_get_old_global_obj_state
and intel_atomic_get_new_global_obj_state right away, however
those are not initializing global obj state as
intel_atomic_get_global_obj_state does.
Extracted initializing part to separate function and now using this
also in intel_at
According to BSpec 53998, we should try to
restrict qgv points, which can't provide
enough bandwidth for desired display configuration.
Currently we are just comparing against all of
those and take minimum(worst case).
v2: Fixed wrong PCode reply mask, removed hardcoded
values.
v3: Forbid si
Flip the switch and enable SAGV support
for Gen12 also.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2aafd2b07e4a..6d4240f260a9 100644
--- a/dr
For Gen11+ platforms BSpec suggests disabling specific
QGV points separately, depending on bandwidth limitations
and current display configuration. Thus it required adding
a new PCode request for disabling QGV points and some
refactoring of already existing SAGV code.
Also had to refactor intel_can
We need to start passing memory latency as a
parameter when calculating plane wm levels,
as latency can get changed in different
circumstances(for example with or without SAGV).
So we need to be more flexible on that matter.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/intel_pm.c
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
Signed-off-by: Chris Wilson
---
d
Hi Chris,
On Tuesday, February 11, 2020 5:44:59 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2020-02-11 14:30:48)
> > @@ -2009,8 +2016,31 @@ igt_main_args("c:", NULL, help_str, opt_handler,
NULL)
> > igt_subtest("invalid-null-pointer")
> > test_
We need to be extremely careful inside i915_request_await_start() as it
needs to walk the list of requests in the foreign timeline with very
little protection. As we hold our own timeline mutex, we can not nest
inside the signaler's timeline mutex, so all that remains is our RCU
protection. However
On Tue, 2020-02-18 at 12:39 -0800, José Roberto de Souza wrote:
> Commit 60c6a14b489b ("drm/i915/display: Force the state compute phase
> once to enable PSR") was forcing the state compute too earlier
> causing errors because not everything was initialized, so here
> moving to i915_driver_register(
On Thu, 20 Feb 2020, Stanislav Lisovskiy wrote:
> We might be willing to call intel_atomic_get_old_global_obj_state
> and intel_atomic_get_new_global_obj_state right away, however
> those are not initializing global obj state as
> intel_atomic_get_global_obj_state does.
> Extracted initializing pa
As DP shim's config_stream_type returns size of message
to be written in case of success therefore on
config_stream_type success return a zero success
value in order to succeed the HDCP auth.
CC: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 +++-
HDCP Repeater initializes seq_num_V to 0 at the beginning of
hdcp Session i.e. after AKE_init received, refer
HDCP 2.2 Spec HDMI PAGE 19, DP PAGE 20.
HDCP 2.2 Comp specs 1B-06 test verifies that whether DUT
considers failure of authentication if the repeater provides a
non-zero value in seq_num_V
Adding ram's RB on patch1 and a new patch to fix DP HDCP Auth.
Anshuman Gupta (2):
drm/i915/hdcp: Mandate (seq_num_V==0) at first RecvId msg
drm/i915/hdcp: Return 0 on config_stream_type() +ve return
drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +-
1 file changed, 9 insertions(+),
On 20/02/2020 07:50, Chris Wilson wrote:
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect the
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Instead of supporting ~2000km wide displayes let's limit ourselves
> to ~65m. That seems plenty big enough to me.
>
> Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
> 10*0xfff which fits into the 16 bi
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: ee5e5e7a5e0f ("drm/i915: Add HDCP framework + base
implementation").
The bot has tested the following trees: v5.5.4, v5.4.20, v4.19.104.
v5.5.4: Failed to apply! Possible dependen
Quoting Matthew Auld (2020-02-20 12:47:28)
> On 20/02/2020 07:50, Chris Wilson wrote:
> > While we know that the waiters cannot disappear as we walk our list
> > (only that they might be added), the same cannot be said for our
> > signalers as they may be completed by the HW and retired as we proce
On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Reorganize drm_display_mode to eliminate all the holes.
> We'll put all the actual timings to the start of the
> struct and all the extra junk to the end.
>
> Gets the size down to 136 bytes on 64bit and 120 bytes on
>
On 20/02/2020 12:36, Chris Wilson wrote:
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
ba
On 07.02.2020 16:39, Alexey Budankov wrote:
>
> On 07.02.2020 14:38, Thomas Gleixner wrote:
>> Alexey Budankov writes:
>>> On 22.01.2020 17:25, Alexey Budankov wrote:
On 22.01.2020 17:07, Stephen Smalley wrote:
>> It keeps the implementation simple and readable. The implementation is
>
On Thu, 2020-02-20 at 14:40 +0200, Jani Nikula wrote:
> On Thu, 20 Feb 2020, Stanislav Lisovskiy <
> stanislav.lisovs...@intel.com> wrote:
> > We might be willing to call intel_atomic_get_old_global_obj_state
> > and intel_atomic_get_new_global_obj_state right away, however
> > those are not initia
On 20/02/2020 12:52, Chris Wilson wrote:
Quoting Matthew Auld (2020-02-20 12:47:28)
On 20/02/2020 07:50, Chris Wilson wrote:
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by
On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> struct drm_display_mode is extremely fat. Put it on diet.
>
> Some stats for the whole series:
>
> 64bit sizeof(struct drm_display_mode):
> 200 -> 136 bytes (-32%)
>
> 64bit bloat-o-meter -c drm.ko:
> add/remove: 1/0 g
On Thu, 2020-02-20 at 15:11 +0200, stanislav.lisovs...@intel.com wrote:
> On Thu, 2020-02-20 at 14:40 +0200, Jani Nikula wrote:
> > On Thu, 20 Feb 2020, Stanislav Lisovskiy <
> > stanislav.lisovs...@intel.com> wrote:
> > > We might be willing to call intel_atomic_get_old_global_obj_state
> > > and
== Series Details ==
Series: drm/i915: make i915_debugfs_register return void.
URL : https://patchwork.freedesktop.org/series/73587/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16604_full
Summary
--
On Wed, Feb 19, 2020 at 10:22:58PM -0800, Kees Cook wrote:
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable initial
On Thu, Feb 20, 2020 at 11:20:05AM +, Emil Velikov wrote:
> On Thu, 7 Nov 2019 at 15:17, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > We have a nice little helper to compute a single LUT entry
> > for everything except the 8bpc legacy gamma mode. Let's
> > complete the set.
> >
Hi Daniel,
On 2/19/20 11:21 AM, Daniel Vetter wrote:
> It's right above the drm_dev_put().
>
> Aside: Another driver with a bit much devm_kzalloc, which should
> probably use drmm_kzalloc instead ...
>
> Signed-off-by: Daniel Vetter
> Cc: Yannick Fertre
> Cc: Philippe Cornu
> Cc: Benjamin Gai
On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > struct drm_display_mode is extremely fat. Put it on diet.
> >
> > Some stats for the whole series:
> >
> > 64bit sizeof(struct drm_display_mode)
== Series Details ==
Series: drm/i915/psr: Force PSR probe only after full initialization (rev5)
URL : https://patchwork.freedesktop.org/series/73436/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16607_full
==
Hi Greg,
On Wed, Feb 19, 2020 at 07:19:32PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> >> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> >>> On Wed,
== Series Details ==
Series: series starting with [1/1] drm/i915: MCHBAR memory info registers are
moved since GEN 12. (rev3)
URL : https://patchwork.freedesktop.org/series/73332/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16609_full
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be stil
On Thu, Feb 20, 2020 at 11:24:20AM +, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely pointless. Stop doing it.
> >
> > Also drop private_flags
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
> >
On Thu, Feb 20, 2020 at 05:23:47PM +0200, Stanislav Lisovskiy wrote:
> There seems to be a bit of confusing redundancy in a way, how
> plane data rate/min cdclk are calculated.
> In fact both min cdclk, pixel rate and plane data rate are all
> part of the same formula as per BSpec.
>
> However cur
On Thu, 2020-02-20 at 17:43 +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 05:23:47PM +0200, Stanislav Lisovskiy wrote:
> > There seems to be a bit of confusing redundancy in a way, how
> > plane data rate/min cdclk are calculated.
> > In fact both min cdclk, pixel rate and plane data rate a
Hi Chris,
On Monday, December 2, 2019 3:59:19 PM CET Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-12-02 14:42:58)
> > Hi Chris,
> >
> > I have a few questions rather than comments. I hope they are worth
> > spending
> > your time.
> >
> > On Wednesday, November 13, 2019 1:52:40 PM C
Quoting Janusz Krzysztofik (2020-02-20 15:57:24)
> Hi Chris,
>
> On Monday, December 2, 2019 3:59:19 PM CET Chris Wilson wrote:
> > Quoting Janusz Krzysztofik (2019-12-02 14:42:58)
> > > Hi Chris,
> > >
> > > I have a few questions rather than comments. I hope they are worth
> > > spending
> >
Quoting Janusz Krzysztofik (2020-02-20 15:32:03)
> Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> introduced a macro that makes it easy to repeat a test body within a
> loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
> API. However, when run on an older vers
Quoting Chris Wilson (2020-02-20 16:09:14)
> Quoting Janusz Krzysztofik (2020-02-20 15:32:03)
> > Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> > introduced a macro that makes it easy to repeat a test body within a
> > loop for each mmap-offset mapping type supported by v4 of i915
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate
On Thu, Feb 20, 2020 at 3:19 PM Philippe CORNU wrote:
>
> Hi Daniel,
>
> On 2/19/20 11:21 AM, Daniel Vetter wrote:
> > It's right above the drm_dev_put().
> >
> > Aside: Another driver with a bit much devm_kzalloc, which should
> > probably use drmm_kzalloc instead ...
> >
> > Signed-off-by: Danie
== Series Details ==
Series: drm/i915: Add support for HDCP 1.4 over MST connectors (rev4)
URL : https://patchwork.freedesktop.org/series/70393/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16610_full
Den 19.02.2020 11.20, skrev Daniel Vetter:
> They all share mipi_dbi_release so we need to switch them all
> together. With this we can drop the final kfree from the release
> function.
>
> Aside, I think we could perhaps have a tiny additional helper for
> these mipi_dbi drivers, the first few
Den 19.02.2020 11.20, skrev Daniel Vetter:
> With this we can drop the final kfree from the release function.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Reviewed-by: Noralf Trønnes
___
Intel-gfx mailing list
Intel-gfx@lists.freed
Den 19.02.2020 11.21, skrev Daniel Vetter:
> Allows us to drop the drm_driver.release callback.
>
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
> ---
Reviewed-by: Noralf Trønnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
htt
Den 19.02.2020 11.21, skrev Daniel Vetter:
> 7/7 drivers agree that's the right choice, let's do this.
>
> This avoids duplicating the same old error checking code over all 7
> drivers, which is the motivation here.
>
> Signed-off-by: Daniel Vetter
> ---
Reviewed-by: Noralf Trønnes
__
Den 19.02.2020 11.21, skrev Daniel Vetter:
> Allows us to drop the drm_driver.release callback from all
> drivers, and remove the mipi_dbi_release() function.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5d070083c766 drm/i915: Start passing latency as parameter
0ada6eb4565d drm/i915: Introduce skl_plane_wm_level accessor.
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Start passing latency as parameter
Okay!
Commit: drm/i915: Introduce skl_plane_wm_
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> Patchwork_16644
Summary
---
**FAILURE**
Serious
== Series Details ==
Series: series starting with [1/2] drm/i915: Double check bumping after the
spinlock
URL : https://patchwork.freedesktop.org/series/73707/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
00c160893898 drm/i915: Double check bumping after the spinlock
-:10: WA
We don't need to try reset-stress on every engine with the display, just
once is enough to stress any interlinkage.
This should reduce the runtime to 10s.
Signed-off-by: Chris Wilson
Cc: Martin Peres
---
tests/i915/gem_eio.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
dif
Convert from using a fixed number of iterations (1 million), to using a
fixed runtime so that we have predictable (and shorter!) run times across
a wide variety of machines.
Signed-off-by: Chris Wilson
Cc: Martin Peres
---
tests/sw_sync.c | 17 +++--
1 file changed, 7 insertions(+),
On Thu, 20 Feb 2020 at 14:28, Ville Syrjälä
wrote:
>
> On Thu, Feb 20, 2020 at 01:21:03PM +, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
> > > Some s
Device specific dev_WARN and dev_WARN_ONCE macros available in kernel
include device information in the backtrace, so we know what device
the warnings originate from.
Similar to this, add new struct drm_device based drm_WARN* macros. These
macros include device information in the backtrace, so we
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automati
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automati
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done automatica
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be stil
Please ignore this submission, the code is broken. Sorry for that.
Janusz
On Thursday, February 20, 2020 6:08:19 PM CET Janusz Krzysztofik wrote:
> Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
> introduced a macro that makes it easy to repeat a test body within a
> loop for each
On Tue, Feb 11, 2020 at 10:55:27PM +0530, Anshuman Gupta wrote:
> we can't have (pipe == crtc->index) assumption in
> driver in order to support 3 non-contiguous
> display pipe system.
>
> FIXME: Remove the WARN_ON(drm_crtc_index(&crtc->base) != crtc->pipe)
> when we will fix all such assumption.
On Tue, Feb 11, 2020 at 10:55:28PM +0530, Anshuman Gupta wrote:
> Skip the transcoder whose pipe is disabled while
> initializing transcoder error state in 3 non-contiguous
> display pipe system.
>
> v2:
> - Don't skip EDP_TRANSCODER error state. [Ville]
> - Use a helper has_transcoder(). [Ville]
== Series Details ==
Series: series starting with [1/2] drm/i915: Double check bumping after the
spinlock
URL : https://patchwork.freedesktop.org/series/73707/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> Patchwork_16645
==
On Tue, Feb 11, 2020 at 10:55:29PM +0530, Anshuman Gupta wrote:
> As a disabled pipe in pipe_mask is not having a valid intel crtc,
> driver wrongly populates the possible_crtcs mask while initializing
> the plane for a CRTC. Fixing up the plane possible_crtcs mask.
>
> changes since RFC:
> - Simp
On Tue, Feb 11, 2020 at 10:55:32PM +0530, Anshuman Gupta wrote:
> skl_ddb_allocation_overlaps() num_entries hass been passed as
> INTEL_NUM_PIPES, it should be I915_MAX_PIPES.
>
> Cc: Ville Syrjälä
> Signed-off-by: Anshuman Gupta
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/displa
On Tue, Feb 18, 2020 at 05:42:30PM -0800, José Roberto de Souza wrote:
> dGFX have local memory so it do not have aperture and do not support
> CPU fences but even for iGFX it have a small number of fences.
>
> As replacement for fences to track frontbuffer modifications by CPU
> we have a softwar
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be stil
Since we check before and then after each debugfs entry, we do not need
to check before each time as well. We will error out as soon as it does
fail, at all other times we know the system to be idle.
No impact on runtime for glk (which apparently is one of the better
behaving systems).
Signed-off
1 - 100 of 154 matches
Mail list logo
