On Tue, Feb 12, 2019 at 3:57 PM Manasi Navare wrote:
>
> On Mon, Jan 28, 2019 at 02:00:12PM -0800, Aditya Swarup wrote:
> > Macros to be organized semantically by dword, lane and
> > port(in this order).
> >
> > Cc: Clint Taylor
> > Cc: Imre Deak
> > Cc: Jani Nikula
> > Signed-off-by: Aditya Sw
Hi David,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.0-rc4 next-20190213]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
From: Michel Thierry
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.
The recommended default watchdog threshold for vide
From: Michel Thierry
Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.
v2: Support watchdog threshold per context engine, merge lri commands,
and move watchdog commands emission to emit_bb_
From: Michel Thierry
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to su
From: Michel Thierry
XXX: What to do when the watchdog irq fired twice but our hangcheck
logic thinks the engine is not hung? For example, what if the
active-head moved since the irq handler?
One option is to just ignore the watchdog, if the engine is really hung,
then the driver will detect the
This is a rebased on the original patch series from Michel Thierry
that can be found here:
https://patchwork.freedesktop.org/series/21868
Note that this series is only limited to the GPU Watchdog timeout
for execlists as it leaves out support
for GuC based submission for a later time.
PATCH v3 o
From: Michel Thierry
Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
and unaffected.
To start the discussion, include just a total en
From: Michel Thierry
Save the watchdog threshold (in us) as part of the engine state.
v2: Only do it for gen8+ (and prevent a missing-case warn).
v3: use ctx->__engine.
v4: Rebase.
v5: Rebase.
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
The support for PSR2 was polished, IGT tests for PSR2 was added and
it was tested performing regular user workloads like browsing,
editing documents and compiling Linux, so it is time to enable it by
default and enjoy even more power-savings.
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Signed-off-b
As stated in CRC_CTL spec, after PSR entry state CRC will not be
calculated anymore what is not a problem as IGT tests do some screen
change and then request the pipe CRC right after the change so PSR
will go to idle state and only will entry again after at least 6
idles frames.
But for PSR2 it is
Now we are checking sink capabilities when probing PSR DPCD register
and then dynamically checking in if new state is compatible with PSR
in, so this FIXME can be dropped.
Reviewed-by: Dhinakaran Pandiyan
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/int
Forcing a specific CRTC to the eDP connector was causing the
intel_psr_fastset_force() to mark mode_chaged in the wrong and
disabled CRTC causing no update in the PSR state.
Looks like our internal state track do not clear output_types and
has_psr in the disabled CRTCs, not sure if this is the exp
Maarten Lankhorst wrote:
> Op 13-02-2019 om 16:53 schreef Ville Syrjälä:
> > On Fri, Feb 08, 2019 at 01:49:40PM -0800, Kevin Strasser wrote:
> >> This series defines new formats and adds implementation to the i915 driver.
> >> Since posting v1 I have removed the pixel normalize property, as it's no
On Thu, 2019-02-07 at 14:24 -0800, José Roberto de Souza wrote:
> Now we are checking sink capabilities when probing PSR DPCD register
> and then dynamically checking in if new state is compatible with PSR
> in, so this FIXME can be dropped.
Right, this was fixed a while ago.
Reviewed-by: Dhinaka
Currently we try to stop the engine by programming the ring registers to
be disabled before we perform the reset. Sometimes, we see the context
image also have invalid ring registers, which one presumes may be
actually caused by us doing so. Lets risk not doing programming the
ring to zero on the f
Currently, we only try to reset a live engine for checking the whitelist
retention across a per-engine reset. For safety, it appears we need to
prime the system with a hanging spinner before performing a full-device
reset. (Figuring out the root cause behind the instability with handling
a reset du
Quoting Takashi Iwai (2019-02-13 21:48:50)
> On Wed, 13 Feb 2019 16:21:09 +0100,
> Chris Wilson wrote:
> >
> > drm/i915 is tracking all wakeref owners with a cookie in order to
> > identify leaks. To that end, each rpm acquisition ops->get_power is
> > assigned a cookie which should be passed to o
On Wed, 13 Feb 2019 16:21:09 +0100,
Chris Wilson wrote:
>
> drm/i915 is tracking all wakeref owners with a cookie in order to
> identify leaks. To that end, each rpm acquisition ops->get_power is
> assigned a cookie which should be passed to ops->put_power to signify
> its release (and removal fro
Tested with dual CRTC configuration shows many FIFO underruns even with
this code. Single CRTC has not produced a FIFO underrun yet.
[ 7037.510737] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU
pipe A FIFO underrun
[ 7040.769741] [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU
pi
On Wed, Feb 13, 2019 at 11:44:44AM -0800, Clinton Taylor wrote:
>
> On 2/13/19 8:54 AM, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We'll need to poke at the "ignore lines" bit in the skl+
> > watermark registers for a w/a. Include that bit in the wm
> > state.
> >
> > Signed-off-by: Vil
On Wed, Feb 13, 2019 at 09:45:36AM -0500, David Francis wrote:
> The function drm_dsc_pps_infoframe_pack only
> packed the payload portion of the infoframe.
> Change the input struct to the PPS payload
> to clarify the function's purpose and allow
> for drivers with their own handling of sdp.
> (e.
Reviewed-by: Clint Taylor
-Clint
On 2/13/19 8:54 AM, Ville Syrjala wrote:
From: Ville Syrjälä
The new workaround from the hw team involves programming the
leaving WM1 still disabled but programming the blocks value
identically to WM0, and we also need to set the "ignore
lines watermark" bit
On 2/13/19 8:54 AM, Ville Syrjala wrote:
From: Ville Syrjälä
We'll need to poke at the "ignore lines" bit in the skl+
watermark registers for a w/a. Include that bit in the wm
state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h |
Reviewed-by: Clint Taylor
-Clint
On 2/13/19 8:54 AM, Ville Syrjala wrote:
From: Ville Syrjälä
This reverts commit bf002c100740f4ae01d0d86b44f65a712ee14031.
The hw team has come up with a better workaround. So
let's get rid of this one.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i
On Wed, Feb 13, 2019 at 09:45:35AM -0500, David Francis wrote:
> Native 420 and 422 transfer modes are new in DSC1.2
>
> In these modes, each two pixels of a slice are treated as one
> pixel, so the slice width is half as large (round down) for
> the purposes of calucating the groups per line and
On Wed, Feb 13, 2019 at 09:45:34AM -0500, David Francis wrote:
> The function intel_compute_rc_parameters is part of the dsc spec
> and is not driver-specific. Other drm drivers might like to use
> it. The function is not changed; just moved and renamed.
>
Yes this sounds fair since its DSC spec
As we currently do not check on submission whether the context is banned
in a timely manner it is possible for some requests to escape
cancellation after their parent context is banned. By moving the ban
into the request submission under the engine->timeline.lock, we
serialise it with the reset and
As we currently do not check on submission whether the context is banned
in a timely manner it is possible for some requests to escape
cancellation after their parent context is banned. By moving the ban
into the request submission under the engine->timeline.lock, we
serialise it with the reset and
== Series Details ==
Series: snd/hda, drm/i915: Track the display_power_status using a cookie
URL : https://patchwork.freedesktop.org/series/56615/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5598_full -> Patchwork_12213_full
=
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v4.20.7, v4.19.20, v4.14.98, v4.9.155,
v4.4.173, v3.18.134.
v4.20.7: Build OK!
v4.
On Wed, Feb 06, 2019 at 10:49:10PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Wrap the .update_plane()/.update_slave()/.disable_plane() vfunc
> calls into helpers which also take care to emit the appropriate
> tracepoint.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
On Wed, Feb 06, 2019 at 10:49:09PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_crtc_disable_planes() disables the planes so it should
> trigger the appropriate tracepoint.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_display.c
On Wed, Feb 06, 2019 at 10:49:07PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a tracepoint for pipe crc. Makes life much simpler when staring at
> traces when hunting for fifo underruns and other issues which cause
> corrupted frames. We'll add the tracepoint before filtering out a
On Wed, Feb 06, 2019 at 10:49:08PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add tracepoints for pipe enable/disable. We'll include the
> frame/scanline counters for all pipes in these tracepoints to
> help in diagnosing underruns and whatnot when enabling/disabling
> pipes in paralle
From: Ville Syrjälä
This reverts commit bf002c100740f4ae01d0d86b44f65a712ee14031.
The hw team has come up with a better workaround. So
let's get rid of this one.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 -
drivers/gpu/drm/i915/intel_display.c | 6 --
2 fil
From: Ville Syrjälä
The new workaround from the hw team involves programming the
leaving WM1 still disabled but programming the blocks value
identically to WM0, and we also need to set the "ignore
lines watermark" bit for WM1.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c |
From: Ville Syrjälä
We'll need to poke at the "ignore lines" bit in the skl+
watermark registers for a w/a. Include that bit in the wm
state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 44 ++
Quoting Ville Syrjälä (2019-02-13 16:30:10)
> On Wed, Feb 13, 2019 at 04:21:42PM +, Chris Wilson wrote:
> > Each set of registers we need to rewrite during a pageflip/modeset
> > increases the required evasion window. Modesets with PSR enabled
> > empirically take up to 350us to complete the re
On Wed, Feb 13, 2019 at 04:21:42PM +, Chris Wilson wrote:
> Each set of registers we need to rewrite during a pageflip/modeset
> increases the required evasion window. Modesets with PSR enabled
> empirically take up to 350us to complete the register programming, so
> provide a corresponding boo
Each set of registers we need to rewrite during a pageflip/modeset
increases the required evasion window. Modesets with PSR enabled
empirically take up to 350us to complete the register programming, so
provide a corresponding boost to the evasion window.
Bugzilla: https://bugs.freedesktop.org/show
== Series Details ==
Series: snd/hda, drm/i915: Track the display_power_status using a cookie
URL : https://patchwork.freedesktop.org/series/56615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5598 -> Patchwork_12213
Summa
== Series Details ==
Series: snd/hda, drm/i915: Track the display_power_status using a cookie
URL : https://patchwork.freedesktop.org/series/56615/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3b218178e779 snd/hda, drm/i915: Track the display_power_status using a cookie
-:107:
Op 13-02-2019 om 16:53 schreef Ville Syrjälä:
> On Fri, Feb 08, 2019 at 01:49:40PM -0800, Kevin Strasser wrote:
>> This series defines new formats and adds implementation to the i915 driver.
>> Since posting v1 I have removed the pixel normalize property, as it's not
>> needed
>> for basic functio
On Fri, Feb 08, 2019 at 01:49:40PM -0800, Kevin Strasser wrote:
> This series defines new formats and adds implementation to the i915 driver.
> Since posting v1 I have removed the pixel normalize property, as it's not
> needed
> for basic functionality. Also, I have been working on adding support
== Series Details ==
Series: Make DRM DSC helpers more generally usable
URL : https://patchwork.freedesktop.org/series/56608/
State : failure
== Summary ==
Applying: drm/i915: Move dsc rate params compute into drm
Applying: drm/dsc: Add native 420 and 422 support to compute_rc_params
error: sh
On 2019-02-13 9:45 a.m., David Francis wrote:
> The function drm_dsc_pps_infoframe_pack only
> packed the payload portion of the infoframe.
> Change the input struct to the PPS payload
> to clarify the function's purpose and allow
> for drivers with their own handling of sdp.
> (e.g. drivers with t
On 2019-02-13 9:45 a.m., David Francis wrote:
> Native 420 and 422 transfer modes are new in DSC1.2
>
> In these modes, each two pixels of a slice are treated as one
> pixel, so the slice width is half as large (round down) for
> the purposes of calucating the groups per line and chunk size
> in b
On 2019-02-13 9:45 a.m., David Francis wrote:
> The function intel_compute_rc_parameters is part of the dsc spec
> and is not driver-specific. Other drm drivers might like to use
> it. The function is not changed; just moved and renamed.
>
> Signed-off-by: David Francis
Reviewed-by: Harry Wentl
drm/i915 is tracking all wakeref owners with a cookie in order to
identify leaks. To that end, each rpm acquisition ops->get_power is
assigned a cookie which should be passed to ops->put_power to signify
its release (and removal from the list of wakeref owners). As snd/hda is
already using a bool t
On Thu, Nov 29, 2018 at 07:55:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> As there are no upstream drivers for VED or ISP let's just
> assert that they are power gated. Otherwise they would
> prevent s0ix entry.
>
> For ISP this is only relevant when it is not exposed as a
> PCI d
The function drm_dsc_pps_infoframe_pack only
packed the payload portion of the infoframe.
Change the input struct to the PPS payload
to clarify the function's purpose and allow
for drivers with their own handling of sdp.
(e.g. drivers with their own struct for
all SDP transactions)
Signed-off-by:
The function intel_compute_rc_parameters is part of the dsc spec
and is not driver-specific. Other drm drivers might like to use
it. The function is not changed; just moved and renamed.
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dsc.c | 133 ++
driv
Native 420 and 422 transfer modes are new in DSC1.2
In these modes, each two pixels of a slice are treated as one
pixel, so the slice width is half as large (round down) for
the purposes of calucating the groups per line and chunk size
in bytes
In native 422 mode, each pixel has four components,
drm_dsc could use some work so that drm drivers other than
i915 can make use of it their own DSC implementations
Move rc compute, a function that forms part of the DSC spec,
into drm. Update it to DSC 1.2. Also change the packing function
to operate only on the packing struct, to allow for drivers
On Thu, Nov 29, 2018 at 07:55:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rename the punit display power register to match the spec.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> drivers/gpu/drm/i915/intel_c
Quoting Chris Wilson (2019-02-13 14:08:02)
> Quoting Guillaume Tucker (2019-02-13 09:31:37)
> > This fixes a compiler warning treated as an error when building for
> > 32-bit architectures since their pointer size does not match the size
> > of drm_i915_gem_context_param.value which is 64 bits:
> >
Quoting Guillaume Tucker (2019-02-13 09:31:37)
> This fixes a compiler warning treated as an error when building for
> 32-bit architectures since their pointer size does not match the size
> of drm_i915_gem_context_param.value which is 64 bits:
>
> CC i915/gem_ctx_sseu.o
> i915/gem_ctx_s
== Series Details ==
Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats
URL : https://patchwork.freedesktop.org/series/56606/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add P010, P012, P016 plane control definitions
Okay!
Com
== Series Details ==
Series: Enable P0xx (planar), Y2xx/Y4xx (packed) pixel formats
URL : https://patchwork.freedesktop.org/series/56606/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cb165e09561e drm/i915: Add P010, P012, P016 plane control definitions
faf842adb452 drm/i915: P
From: Juha-Pekka Heikkila
Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Signed-off-by: Swati Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_sprite.c | 28 ++--
1
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 30 ++
drivers/gpu/drm/i915/intel_sprite.c | 60 +++-
2 files changed, 89 insert
From: Juha-Pekka Heikkila
Add needed plane control flag definitions for P010, P012 and
P016 formats.
Signed-off-by: Juha-Pekka Heikkila
Signed-off-by: Swati Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/driver
From: Juha-Pekka Heikkila
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
Signed-off-by: Juha-Pekka Heikkila
Signed-off-by: Swati Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 2 +-
drivers/
Added needed plane control flag definitions for Y2xx and Y4xx (10, 12 and
16 bits)
Signed-off-by: Swati Sharma
Signed-off-by: Vidya Srinivas
Reviewed-by: Juha-Pekka Heikkila
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
1 file changed, 6 insertions(+)
diff --
This patch series is for enabling P0xx, Y2xx and Y4xx pixel formats for
intel's i915 driver.
In this patch series, Juha Pekka's patch series Gen10+ P0xx formats
https://patchwork.freedesktop.org/series/56053/ is combined with Swati's
https://patchwork.freedesktop.org/series/55035/ for Gen11+ pixel
The following pixel formats are packed format that follows 4:2:2
chroma sampling. For memory represenation each component is
allocated 16 bits each. Thus each pixel occupies 32bit.
Y210: For each component, valid data occupies MSB 10 bits.
LSB 6 bits are filled with zeroes.
Y212: For e
Quoting Daniel Vetter (2019-02-13 13:08:32)
> On Wed, Feb 13, 2019 at 2:05 PM Chris Wilson wrote:
> >
> > Quoting Daniel Vetter (2019-02-13 13:02:29)
> > > On Wed, Feb 13, 2019 at 11:15 AM Chris Wilson
> > > wrote:
> > > > Quoting Daniel Vetter (2019-02-13 10:11:27)
> > > > > On Tue, Feb 12, 201
On Wed, Feb 13, 2019 at 2:05 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-02-13 13:02:29)
> > On Wed, Feb 13, 2019 at 11:15 AM Chris Wilson
> > wrote:
> > > Quoting Daniel Vetter (2019-02-13 10:11:27)
> > > > On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> > > > > CI co
Quoting Daniel Vetter (2019-02-13 13:02:29)
> On Wed, Feb 13, 2019 at 11:15 AM Chris Wilson
> wrote:
> > Quoting Daniel Vetter (2019-02-13 10:11:27)
> > > On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> > > > CI complains that the exhaustive test of trying every size up to the
> >
On Wed, Feb 13, 2019 at 11:15 AM Chris Wilson wrote:
> Quoting Daniel Vetter (2019-02-13 10:11:27)
> > On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> > > CI complains that the exhaustive test of trying every size up to the
> > > limit is too slow, so add a simple test that tries t
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson
---
Continue the
== Series Details ==
Series: i915/gem_exec_big: Add a single shot test
URL : https://patchwork.freedesktop.org/series/56595/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5596_full -> IGTPW_2390_full
Summary
---
**SU
Hi Dave and Daniel, perhaps slightly more than I'd like at this stage,
but didn't really want to drop anything either...
BR,
Jani.
The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9:
Linux 5.0-rc6 (2019-02-10 14:42:20 -0800)
are available in the Git repository at:
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Wednesday, February 13, 2019 4:34 PM
>To: Shankar, Uma
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Syrjala,
>Ville
>; emil.l.veli...@gmail.com; Lankhorst, Maarten
>
>Subject
On Tue, Feb 12, 2019 at 09:30:50PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, February 12, 2019 10:35 PM
> >To: Shankar, Uma
> >Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
Op 11-02-2019 om 14:50 schreef Uma Shankar:
> Add the degamma and gamma lut sizes to gen11 capability
> structure.
>
> Note: Currently this doesn't account for the extended range gamma
> entries and this will be addressed with new segmented gamma ABI
> in a future patch.
>
> v2: Reorder the patch a
Stop accessing the HWSP to read the global seqno, and stop tracking the
mirror in the engine's execution timeline -- it is unused.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gpu_error.c | 4 --
drivers/gpu/drm/i915/i915_gpu_error.h |
As we no longer have a precise indication of requests queued to an
engine, make no presumptions and just sample the ring registers to see
if the engine is busy.
v2: Report busy while the ring is idling on a semaphore/event.
v3: Give the struct a name!
v4: Always 0 outside the powerwell; trusting t
Having weaned the interrupt handling off using a single global execution
queue, we no longer need to emit a global_seqno. Note that we still have
a few assumptions about execution order along engine timelines, but this
removes the most obvious artefact!
Signed-off-by: Chris Wilson
---
drivers/gp
To determine whether an engine has 'stuck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests w
Quoting Daniel Vetter (2019-02-13 10:11:27)
> On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> > CI complains that the exhaustive test of trying every size up to the
> > limit is too slow, so add a simple test that tries to submit one
> > extreme batch buffer and check all the reloca
On Tue, Feb 12, 2019 at 10:43:41PM +, Chris Wilson wrote:
> CI complains that the exhaustive test of trying every size up to the
> limit is too slow, so add a simple test that tries to submit one
> extreme batch buffer and check all the relocations land.
>
> Bugzilla: https://bugs.freedesktop.
Hi Dave, Daniel,
Just a single fix to a license inconsistency in vkms. :)
drm-misc-fixes-2019-02-13:
drm-misc-fixes for v5.0:
- Fix license inconsistency in vkms.
The following changes since commit 6297388e1eddd2f1345cea5892156223995bcf2d:
drm/omap: dsi: Hack-fix DSI bus flags (2019-02-06 13:3
== Series Details ==
Series: drm/i915: Apply rps waitboosting for dma_fence_wait_timeout()
URL : https://patchwork.freedesktop.org/series/56597/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5596 -> Patchwork_12209
Summary
== Series Details ==
Series: drm/i915: Apply rps waitboosting for dma_fence_wait_timeout()
URL : https://patchwork.freedesktop.org/series/56597/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Apply rps waitboosting for dma_fence_wait_timeout(
This fixes a compiler warning treated as an error when building for
32-bit architectures since their pointer size does not match the size
of drm_i915_gem_context_param.value which is 64 bits:
CC i915/gem_ctx_sseu.o
i915/gem_ctx_sseu.c: In function ‘test_ggtt_args’:
i915/gem_ctx_sseu.c:
== Series Details ==
Series: i915/gem_exec_big: Add a single shot test
URL : https://patchwork.freedesktop.org/series/56595/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5596 -> IGTPW_2390
Summary
---
**SUCCESS**
As time goes by, usage of generic ioctls such as drm_syncobj and
sync_file are on the increase bypassing i915-specific ioctls like
GEM_WAIT. Currently, we only apply waitboosting to our driver ioctls as
we track the file/client and account the waitboosting to them. However,
since commit 7b92c1bd054
CI complains that the exhaustive test of trying every size up to the
limit is too slow, so add a simple test that tries to submit one
extreme batch buffer and check all the relocations land.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=10
Signed-off-by: Chris Wilson
---
tests/i915/
Quoting Rodrigo Vivi (2019-02-12 01:51:18)
> On Mon, Feb 11, 2019 at 06:15:20PM +0100, Daniel Vetter wrote:
> > Hi all,
> >
> > Here's the typed component topic branch.
> >
> > drm-intel maintainers: Please pull, I need this for the mei hdcp work from
> > Ram.
>
> I'm about to handle dinq to Jo
== Series Details ==
Series: Add Colorspace connector property interface (rev15)
URL : https://patchwork.freedesktop.org/series/47132/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5596_full -> Patchwork_12208_full
Summary
92 matches
Mail list logo
