== Series Details ==
Series: Improve crc-core driver interface (rev12)
URL : https://patchwork.freedesktop.org/series/45246/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4664 -> Patchwork_9932 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9932
This patch implements "verify_crc_source" callback function for
Virtual KMS drm driver.
Changes Since V1:
- update values_cnt in verify_crc_source
Cc: Haneen Mohammed
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/vkms/vkms_crc.c | 38 ++
The following crash was observed with xserver 1.20.1 on exiting xserver
after enabling a PRIME output source with the Intel driver:
Old value = (WindowPtr) 0x612000159dc0
New value = (WindowPtr) 0x0 // pWin->drawable.pScreen->root = NULL;
DeleteWindow (value=0x612000159dc0, wid=) at
Since xorg-server 1.20, an external monitor would remain blank when used
in a PRIME output slave setup. Only a cursor was visible. The cause is
"Make PixmapDirtyUpdateRec::src a DrawablePtr" in xserver, the "src"
pointer might point to the root window (created by the server) instead
of a pixmap
On Fri, 2018-07-27 at 13:04 -0700, Paulo Zanoni wrote:
> From: Manasi Navare
>
> PLLs are the source clocks for the DDIs so in order to determine the
> ddi clock we need to check the PLL configuration.
>
> For MG PHy Ports (C - F), depending on whether it is a TBT PLL or MG
> PLL the link lock
On Fri, 2018-07-27 at 13:04 -0700, Paulo Zanoni wrote:
> From: Manasi Navare
>
> The register value of Divider Ratio for high speed divider
> (hsdiv_ratio) in MG_CLKTOP2_HSCLKCTL_PORT register is not same as the
> actual numerical value of the divider. So this patch implements
> separate divider
On Mon, Aug 13, 2018 at 12:38:00PM -0700, Souza, Jose wrote:
> On Tue, 2018-07-31 at 17:30 -0700, Manasi Navare wrote:
> > In case of Legacy DP connector on TypeC port (C, D, E or F), the
>
> Legacy DP connector(DisplayPort Alternative Mode)
Ok will reword this as DisplayPort Alternative Mode
>
On Tue, 2018-07-31 at 17:30 -0700, Manasi Navare wrote:
> In case of Legacy DP connector on TypeC port (C, D, E or F), the
Legacy DP connector(DisplayPort Alternative Mode)
> flex IO DPMLE register is set to maximum number of lanes since
> there is no muxing with other controllers in this case.
On Mon, 2018-08-13 at 11:17 -0700, Tarun Vyas wrote:
> On Mon, Aug 13, 2018 at 11:10:00AM -0700, Pandiyan, Dhinakaran wrote:
> > On Mon, 2018-08-13 at 09:57 -0700, Rodrigo Vivi wrote:
> > > On Thu, Aug 09, 2018 at 05:41:35PM -0700, Dhinakaran Pandiyan
> > > wrote:
> > > > CI runs show PSR2 does
On Mon, Aug 13, 2018 at 11:10:00AM -0700, Pandiyan, Dhinakaran wrote:
> On Mon, 2018-08-13 at 09:57 -0700, Rodrigo Vivi wrote:
> > On Thu, Aug 09, 2018 at 05:41:35PM -0700, Dhinakaran Pandiyan wrote:
> > > CI runs show PSR2 does not go to IDLE with selective update enabled
> > > on
> > > all PSR
On Mon, 2018-08-13 at 09:47 -0700, Rodrigo Vivi wrote:
> On Mon, Aug 13, 2018 at 03:47:20PM +0200, Maarten Lankhorst wrote:
> > Op 11-08-18 om 02:50 schreef Dhinakaran Pandiyan:
> > > We print the last attempted entry and last exit timestamps only
> > > when
> > > IRQ debug is requested. This
On Mon, 2018-08-13 at 09:57 -0700, Rodrigo Vivi wrote:
> On Thu, Aug 09, 2018 at 05:41:35PM -0700, Dhinakaran Pandiyan wrote:
> > CI runs show PSR2 does not go to IDLE with selective update enabled
> > on
> > all PSR exit triggers. Specifically, logs indicate the hardware
> > enters
> > "SLEEP
On Thu, Aug 09, 2018 at 05:41:35PM -0700, Dhinakaran Pandiyan wrote:
> CI runs show PSR2 does not go to IDLE with selective update enabled on
> all PSR exit triggers. Specifically, logs indicate the hardware enters
> "SLEEP Selective Update" and not "IDLE Reset state' like the kernel
> expects.
On Mon, Aug 13, 2018 at 03:47:20PM +0200, Maarten Lankhorst wrote:
> Op 11-08-18 om 02:50 schreef Dhinakaran Pandiyan:
> > We print the last attempted entry and last exit timestamps only when
> > IRQ debug is requested. This check was missed when new debug flags were
> > added in 'commit
On Wed, 2018-08-08 at 10:53 +0200, Jan-Marek Glogowski wrote:
> This re-applies the workaround for "some DP sinks, [which] are a
> little nuts" from commit 1a36147bb939 ("drm/i915: Perform link
> quality check unconditionally during long pulse").
> It makes the secondary AOC E2460P monitor
So that this test can be run in drivers other than i915.
Remove devid and only check it if the driver is i915.
Signed-off-by: Haneen Mohammed
---
tests/kms_cursor_crc.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/tests/kms_cursor_crc.c
== Series Details ==
Series: drm/i915: Wait for vblank between disabling planes and disabling crtc
URL : https://patchwork.freedesktop.org/series/48113/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4662_full -> Patchwork_9930_full =
== Summary - WARNING ==
Minor
Chris Wilson writes:
> Do not call gen6_reset_rps_interrupts() when we know the registers do not
> exist.
>
> Signed-off-by: Chris Wilson
This makes me wonder about adding some known gen6+ debug
register range assertions to I915_WRITE when gen < 6.
i915.mmio_debug for all (gens) :)
Chris Wilson writes:
> Since the gt powerstate is allocated by i915_gem_init, clean it from
> i915_gem_fini for symmetry and to correct the imbalance on error.
>
Was first confused about the allocation as it is embedded.
But vlv really does allocate an underlying power context object.
And the
== Series Details ==
Series: Improve crc-core driver interface (rev11)
URL : https://patchwork.freedesktop.org/series/45246/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4663 -> Patchwork_9931 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9931
== Series Details ==
Series: series starting with [1/2] drm/i915: Expose retry count to per gen
reset logic (rev4)
URL : https://patchwork.freedesktop.org/series/48019/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4662_full -> Patchwork_9929_full =
== Summary - SUCCESS
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
during open. If application want to wait after read call, it can use
poll/read blocking read() call.
Suggested-by: Ville Syrjälä
Signed-off-by: Mahesh Kumar
Cc:
This patch implements "verify_crc_source" callback function for
Virtual KMS drm driver.
Cc: dri-de...@lists.freedesktop.org
Cc: Haneen Mohammed
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/vkms/vkms_crc.c | 36
drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.
This series improves crc-core <-> driver interface.
This series adds following functionality in the crc-core
- Now control node will print all the available sources if
implemented by driver along with current source.
- Setting of sorce will fail if provided source is not supported
- cleanup
On 13-Aug-18 7:46 PM, Sharma, Swati2 wrote:
Hi Stanlis,
Won't we defining XYUV PF in skl_update_scaler_plane? Else scaler
won't be updated for XYUV PF.
On 10-Aug-18 6:50 PM, StanLis wrote:
From: Stanislav Lisovskiy
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
== Series Details ==
Series: drm/i915: Wait for vblank between disabling planes and disabling crtc
URL : https://patchwork.freedesktop.org/series/48113/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4662 -> Patchwork_9930 =
== Summary - SUCCESS ==
No regressions found.
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-10 15:00:35)
>> There is a possibility for per gen reset logic to
>> be more nasty if the softer approach on resetting does
>> not bear fruit.
>>
>> Expose retry count to per gen reset logic if it
>> wants to take such tough measures.
>>
>>
== Series Details ==
Series: drm/i915: Wait for vblank between disabling planes and disabling crtc
URL : https://patchwork.freedesktop.org/series/48113/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a46c5d644c7f drm/i915: Wait for vblank between disabling planes and disabling
== Series Details ==
Series: series starting with [1/2] drm/i915: Expose retry count to per gen
reset logic (rev4)
URL : https://patchwork.freedesktop.org/series/48019/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4662 -> Patchwork_9929 =
== Summary - SUCCESS ==
No
Op 11-08-18 om 02:50 schreef Dhinakaran Pandiyan:
> We print the last attempted entry and last exit timestamps only when
> IRQ debug is requested. This check was missed when new debug flags were
> added in 'commit c44301fce614 ("drm/i915: Allow control of PSR at
> runtime through debugfs, v6")
>
>
Disabling cursor does not take effect until the next vblank, but if the
pipe is shut down too quickly after a cursor disable, we will see
random corruption from where the mouse cursor used to be when the pipe
is enabled again.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106478
Joonas, sorry for interfering; could you please explain more regarding the
options for tracing scheduling events better than tracepoints?
After scheduling moves to GuC tools will have to switch to something like
GuC-logging; but while kmd does scheduling isn't kernel-tracing the best
solution?
If engine reports that it is not ready for reset, we
give up. Evidence shows that forcing a per engine reset
on an engine which is not reporting to be ready for reset,
can bring it back into a working order. There is risk that
we corrupt the context image currently executing on that
engine. But
Quoting Mika Kuoppala (2018-08-13 13:49:43)
> Chris Wilson writes:
>
> > Quoting Chris Wilson (2018-07-12 12:57:29)
> >> We require that we keep the list of outstanding work short so that we do
> >> not "leak" memory while pageflipping under stress. However that system
> >> stress may delay
== Series Details ==
Series: series starting with [1/2] drm/i915: Expose retry count to per gen
reset logic (rev3)
URL : https://patchwork.freedesktop.org/series/48019/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4660_full -> Patchwork_9928_full =
== Summary - SUCCESS
Chris Wilson writes:
> Quoting Chris Wilson (2018-07-12 12:57:29)
>> We require that we keep the list of outstanding work short so that we do
>> not "leak" memory while pageflipping under stress. However that system
>> stress may delay kernel workers virtually indefinitely, which incurs the
>>
Hey,
Op 08-08-18 om 17:26 schreef Mahesh Kumar:
> This patch implements get_crc_sources callback, which returns list of
> all the crc sources supported by driver in current platform.
>
> Changes Since V1:
> - move sources list per-crtc
> - init sources-list only for gen3
> Changes Since V2:
>
On Fri, 2018-08-10 at 19:01 +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi Stanislav,
>
> FYI, we are trying to add same format under a slightly different
> name.
> See https://lists.freedesktop.org/archives/dri-devel/2018-
> July/184598.html
So we probably just need to decide, if this should be
== Series Details ==
Series: series starting with [1/2] drm/i915: Expose retry count to per gen
reset logic (rev3)
URL : https://patchwork.freedesktop.org/series/48019/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4660 -> Patchwork_9928 =
== Summary - SUCCESS ==
No
Quoting Mika Kuoppala (2018-08-13 12:02:51)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-08-13 11:42:42)
> >> If engine reports that it is not ready for reset, we
> >> give up. Evidence shows that forcing a per engine reset
> >> on an engine which is not reporting to be ready for
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-13 11:42:42)
>> If engine reports that it is not ready for reset, we
>> give up. Evidence shows that forcing a per engine reset
>> on an engine which is not reporting to be ready for reset,
>> can bring it back into a working order. There is
On Fri, 2018-08-10 at 13:02 +, Lisovskiy, Stanislav wrote:
> On Thu, 2018-08-09 at 14:13 +0300, Gwan-gyeong Mun wrote:
> >
> > The hotplug detection routine of i915 uses
> > drm_helper_hpd_irq_event(). This
> > helper can detect changing of status of connector, but it can not
> > detect
> >
Quoting Mika Kuoppala (2018-08-13 11:42:42)
> If engine reports that it is not ready for reset, we
> give up. Evidence shows that forcing a per engine reset
> on an engine which is not reporting to be ready for reset,
> can bring it back into a working order. There is risk that
> we corrupt the
Quoting Chris Wilson (2018-07-12 12:57:29)
> We require that we keep the list of outstanding work short so that we do
> not "leak" memory while pageflipping under stress. However that system
> stress may delay kernel workers virtually indefinitely, which incurs the
> pageflips stall and eventually
If engine reports that it is not ready for reset, we
give up. Evidence shows that forcing a per engine reset
on an engine which is not reporting to be ready for reset,
can bring it back into a working order. There is risk that
we corrupt the context image currently executing on that
engine. But
== Series Details ==
Series: drm/i915: Bump priority of clean up work
URL : https://patchwork.freedesktop.org/series/46390/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4660_full -> Patchwork_9927_full =
== Summary - SUCCESS ==
No regressions found.
== Known
Quoting Mika Kuoppala (2018-08-13 10:58:10)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-08-13 09:18:07)
> >> Chris Wilson writes:
> >>
> >> > Quoting Mika Kuoppala (2018-08-10 15:00:36)
> >> >> If engine reports that it is not ready for reset, we
> >> >> give up. Evidence shows
== Series Details ==
Series: Reviewed perf cleanups
URL : https://patchwork.freedesktop.org/series/48100/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4660_full -> Patchwork_9926_full =
== Summary - SUCCESS ==
No regressions found.
== Known issues ==
Here are
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-13 09:18:07)
>> Chris Wilson writes:
>>
>> > Quoting Mika Kuoppala (2018-08-10 15:00:36)
>> >> If engine reports that it is not ready for reset, we
>> >> give up. Evidence shows that forcing a per engine reset
>> >> on an engine which is
Quoting Tvrtko Ursulin (2018-08-08 15:56:01)
> On 08/08/2018 13:42, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-08-08 13:13:08)
> This is true, no disagreement. My point simply was that we can provide
> this info easily to anyone. There is a little bit of analogy with perf
> scheduler
On 10/08/2018 14:25, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-09 12:54:41)
On 08/08/2018 15:59, Chris Wilson wrote:
Our observation is that the systematic error is proportional to the
number of iterations we perform; the suspicion is that it directly
correlates with the number of
== Series Details ==
Series: drm/i915: Bump priority of clean up work
URL : https://patchwork.freedesktop.org/series/46390/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4660 -> Patchwork_9927 =
== Summary - SUCCESS ==
No regressions found.
External URL:
Quoting Tvrtko Ursulin (2018-08-13 10:11:44)
>
> On 13/08/2018 09:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
> >> From: Lionel Landwerlin
> >>
> >> Abstract the context image access a bit.
> >>
> >> Signed-off-by: Lionel Landwerlin
> >> Reviewed-by: Tvrtko Ursulin
On 13/08/2018 09:16, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
From: Lionel Landwerlin
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
== Series Details ==
Series: Reviewed perf cleanups
URL : https://patchwork.freedesktop.org/series/48100/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4660 -> Patchwork_9926 =
== Summary - SUCCESS ==
No regressions found.
External URL:
Quoting Mika Kuoppala (2018-08-13 09:18:07)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2018-08-10 15:00:36)
> >> If engine reports that it is not ready for reset, we
> >> give up. Evidence shows that forcing a per engine reset
> >> on an engine which is not reporting to be ready for
Chris Wilson writes:
> Quoting Mika Kuoppala (2018-08-10 15:00:36)
>> If engine reports that it is not ready for reset, we
>> give up. Evidence shows that forcing a per engine reset
>> on an engine which is not reporting to be ready for reset,
>> can bring it back into a working order. There is
Quoting Tvrtko Ursulin (2018-08-13 09:02:18)
> From: Lionel Landwerlin
>
> Abstract the context image access a bit.
>
> Signed-off-by: Lionel Landwerlin
> Reviewed-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_perf.c | 34 +++-
> 1 file changed, 16
From: Lionel Landwerlin
We don't need any special treatment on error so just return as soon as
possible.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git
From: Tvrtko Ursulin
Two reviewed simple cleanup patches, extracted from dynamic SSEU series.
Lionel Landwerlin (2):
drm/i915/perf: simplify configure all context function
drm/i915/perf: reuse intel_lrc ctx regs macro
drivers/gpu/drm/i915/i915_perf.c | 45 ++--
From: Lionel Landwerlin
Abstract the context image access a bit.
Signed-off-by: Lionel Landwerlin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_perf.c | 34 +++-
1 file changed, 16 insertions(+), 18 deletions(-)
diff --git
62 matches
Mail list logo
