On 27/02/2019 23:09, Chris Wilson wrote:
We currently use a worker queued from an rcu callback to determine when
a how grace period has elapsed while we remained idle. We use this idle
delay to infer that we will be idle for a while and this is a suitable
point at which we can trim our global me
On 27/02/2019 23:09, Chris Wilson wrote:
As our allocations are not device specific, we can move our slab caches
to a global scope.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 6 ---
drivers/gpu/drm
On 27/02/2019 23:09, Chris Wilson wrote:
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity life
On 26/02/2019 10:24, Chris Wilson wrote:
Do a pass over all the engines upon starting to determine the global
scheduler capability flags (those that are agreed upon by all).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_engine_cs
On 26/02/2019 10:23, Chris Wilson wrote:
A simple mutex used for guarding the flow of requests in and out of the
timeline. In the short-term, it will be used only to guard the addition
of requests into the timeline, taken on alloc and released on commit so
that only one caller can construct a re
On 26/02/2019 10:24, Chris Wilson wrote:
Gcc has a slight preference if we use __ffs() to subtract one from the
index once rather than each use:
__execlists_submission_tasklet 28672847 -20
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_scheduler.h | 6 --
== Series Details ==
Series: series starting with [v3,1/6] drm/i915/psr: Remove PSR2 FIXME
URL : https://patchwork.freedesktop.org/series/57324/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5668_full -> Patchwork_12324_full
Hi Jani,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190227]
[cannot apply to v5.0-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
== Series Details ==
Series: series starting with [1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57319/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5668_full -> Patchwork_12323_full
==
== Series Details ==
Series: series starting with [v3,1/6] drm/i915/psr: Remove PSR2 FIXME
URL : https://patchwork.freedesktop.org/series/57324/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5668 -> Patchwork_12324
Summary
Other features like PSR2 also needs to be disabled while getting CRC
so lets rename ips_force_disable to crc_enabled, drop all this checks
for pipe A and HSW and BDW and make it generic and
hsw_compute_ips_config() will take care of all the checks removed
from here.
Cc: Dhinakaran Pandiyan
Cc: Vi
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
When PSR2 is active aka after the number of frames programmed in
PSR2_CTL 'Frames Before SU Entry' hardware stops to generate CRC
interruptions causing IGT tests to fail due timeout.
Oddly that don't happen when PSR1 active, so here it switches from
PSR2 to PSR1 while user is requesting pipe CRC.
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
In any commit, intel_modeset_pipe_config() will initialilly clear
and then recalculate most of the pipe states but it leave intel
specific color features states in reset state.
If after intel_pipe_config_compare() is detected that a fastset is
possible it will mark update_pipe as true and unsed mo
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
== Series Details ==
Series: series starting with [1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57319/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5668 -> Patchwork_12323
On Thu, 2019-02-28 at 00:19 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915: Fix atomic state leak
> when resetting HDMI link
> URL : https://patchwork.freedesktop.org/series/57318/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from
On Tue, 2019-02-26 at 16:08 +0200, Imre Deak wrote:
> On Fri, Feb 22, 2019 at 01:08:34PM -0800, José Roberto de Souza
> wrote:
> > Unpowered type-c dongles can take some time to boot and be
> > responsible, causing the probe to fail and sink never be detected
> > without further actions from usersp
== Series Details ==
Series: series starting with [1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57319/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Make request allocation caches globa
== Series Details ==
Series: series starting with [1/3] drm/i915: Make request allocation caches
global
URL : https://patchwork.freedesktop.org/series/57319/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
158b026641f1 drm/i915: Make request allocation caches global
-:162: WARNI
== Series Details ==
Series: series starting with [1/2] drm/i915: Fix atomic state leak when
resetting HDMI link
URL : https://patchwork.freedesktop.org/series/57318/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5668 -> Patchwork_12322
===
On Wed, 27 Feb 2019 18:02:38 +0100, Jani Nikula
wrote:
@@ -108,9 +108,9 @@
* #define FOO(pipe) _MMIO_PIPE(pipe, _FOO_A, _FOO_B)
* #define FOO_ENABLEREG_BIT(31)
* #define FOO_MODE_MASK REG_GENMASK(19, 16)
- * #define FOO_MODE_BAR
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle" (rev2)
URL : https://patchwork.freedesktop.org/series/57311/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666_full -> Patchwork_12321_full
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmentation behaviour (one can argue that
different devices would have different activity lifetimes, but you can
also argue that activity
As our allocations are not device specific, we can move our slab caches
to a global scope.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 6 ---
drivers/gpu/drm/i915/i915_gem.c | 47 ++-
We currently use a worker queued from an rcu callback to determine when
a how grace period has elapsed while we remained idle. We use this idle
delay to infer that we will be idle for a while and this is a suitable
point at which we can trim our global memory caches.
Since we wrote that, this mech
On Wed, 27 Feb 2019 18:02:36 +0100, Jani Nikula
wrote:
@@ -116,6 +116,34 @@
* #define GEN8_BAR_MMIO(0xb888)
*/
+/**
+ * REG_BIT() - Prepare a u32 bit value
+ * @__n: 0-based bit number
+ *
+ * Local wrapper for BIT() to force u32, with compile time checks.
+ *
+ * @re
Atomic state needs to be put even if the commit was successful.
Fixes: dba14b27dd3c ("drm/i915: Reinitialize sink scrambling/TMDS clock ratio
on HPD")
Cc: Ville Syrjälä
Cc: Lyude Paul
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_ddi.c | 7 +--
1 file changed, 1 inse
drm_atomic_commit() call chain already takes care of adding
connectors and planes, so lets no add then manually if not changing
their states.
Cc: Ville Syrjälä
Cc: Lyude Paul
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_ddi.c | 8
1 file changed, 8 deletions(-)
Tested both the patches with drm-tip kernel. Fixes multiple gpu hangs
in vulkan cts and piglit. I will do more thorough testing with updated
version of these patches based on review.
On Wed, Feb 27, 2019 at 7:52 AM Michał Winiarski
wrote:
>
> We assumed that the default preemption granularity i
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle" (rev2)
URL : https://patchwork.freedesktop.org/series/57311/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12321
==
Quoting Chris Wilson (2019-02-27 10:17:15)
> Quoting Daniel Vetter (2017-08-07 10:28:58)
> > On Fri, Aug 04, 2017 at 09:23:28AM +0100, Chris Wilson wrote:
> > > After an event is sent, we try to copy it into the user buffer of the
> > > first waiter in drm_read() and if the user buffer doesn't have
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle" (rev2)
URL : https://patchwork.freedesktop.org/series/57311/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
35705bcdfb67 Revert "drm/i915: Avoid wa
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle"
URL : https://patchwork.freedesktop.org/series/57311/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12320
=
If we have parked, then we must have passed an idleness test and still
be idle. We chose not to use this shortcut in the past so that we could
use the idleness test at any time and inspect HW. However, some HW like
Sandybridge, doesn't like being woken up frivolously, so avoid doing so.
References
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Avoid waking the engines
just to check if they are idle"
URL : https://patchwork.freedesktop.org/series/57311/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
74f5ddaa45e2 Revert "drm/i915: Avoid waking th
Quoting Caz Yokoyama (2019-02-27 17:34:57)
> inline.
>
> v2 patches fixes
> - address calculation bug
> - not killed
> However, the test does not runs faster.
Fair enough, I expected some improvement from the incremental and
avoiding the second mlock + populate of a large region, but if it's not
On Wed, Feb 27, 2019 at 08:50:31PM +, Chris Wilson wrote:
> Quoting Jani Nikula (2019-02-27 17:02:36)
> > #define PP_REFERENCE_DIVIDER_SHIFT8
> > -#define PANEL_POWER_CYCLE_DELAY_MASK 0x1f
> > +#define PANEL_POWER_CYCLE_DELAY_MASK REG_GENMASK(4, 0)
>
> Ok.
>
> I'll get used to the
On Wed, Feb 27, 2019 at 07:02:38PM +0200, Jani Nikula wrote:
> Slightly verbose, but does away with hand rolled shifts. Ties the field
> values with the mask defining the field.
>
> Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
> to a integer constant expression. But with
Quoting Jani Nikula (2019-02-27 17:02:38)
> Slightly verbose, but does away with hand rolled shifts. Ties the field
> values with the mask defining the field.
>
> Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
> to a integer constant expression. But with this, we can ensure
This reverts commit 0b702dca26580e3bbfbbaf22dfc29280b6263414.
CI reports that this is not as reliable as it first appears, with
failures starting to sporadically occur in selftests.
Fixes: 0b702dca2658 ("drm/i915: Avoid waking the engines just to check if they
are idle")
Signed-off-by: Chris Wil
On Wed, Feb 27, 2019 at 03:23:01PM -0500, Adam Jackson wrote:
> On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Some monitors apparently forget to mark any mode as preferred in the
> > EDID. In this particular case we have a very generic looking ID
> > "PNP
Quoting Jani Nikula (2019-02-27 17:02:37)
> bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access
> bitfields using the mask alone, with no need for separate shift. Indeed,
> the shift is redundant.
>
> We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above,
> in part to
Quoting Jani Nikula (2019-02-27 17:02:36)
> Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to
> define register bitfield masks.
>
> We define the above as wrappers to BIT() and GENMASK() respectively to
> force u32 type to go with our register size, and to add compile time
> ch
If we have parked, then we must have passed an idleness test and still
be idle. We chose not to use this shortcut in the past so that we could
use the idleness test at any time and inspect HW, however some HW like
Sandybridge doesn't like being woken up frivolously so avoid doing so.
References: 0
On Wed, 2019-02-27 at 19:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Some monitors apparently forget to mark any mode as preferred in the
> EDID. In this particular case we have a very generic looking ID
> "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
> doesn't s
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev3)
URL : https://patchwork.freedesktop.org/series/50513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666_full -> Patchwork_12317_full
Hi Masahiro.
On Thu, Jan 31, 2019 at 12:56:39PM +0900, Masahiro Yamada wrote:
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already
== Series Details ==
Series: drm/i915: Add a security blanket to ring_is_idle()
URL : https://patchwork.freedesktop.org/series/57308/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12319
Summary
---
== Series Details ==
Series: series starting with [1/2] drm/i915/icl: Default to Thread Group
preemption for compute workloads
URL : https://patchwork.freedesktop.org/series/57300/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5666_full -> Patchwork_12315_full
===
== Series Details ==
Series: series starting with [1/2] drm/edid: If no preferred mode is found
assume the first mode is preferred
URL : https://patchwork.freedesktop.org/series/57306/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12318
=
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev3)
URL : https://patchwork.freedesktop.org/series/50513/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12317
Summary
On Tue, Feb 26, 2019 at 11:02:58AM -0800, Lucas De Marchi wrote:
> On Tue, Feb 26, 2019 at 04:48:23PM +0200, Ville Syrjälä wrote:
> >> >This seems a rather roundabout way of doing things when we already have
> >> >the vfuncs.
> >> >
> >> >How about just:
> >> >
> >> >mg_pll_enable()
> >> >{
> >> >
On Tue, Feb 26, 2019 at 11:15:44AM -0800, Lucas De Marchi wrote:
> On Tue, Feb 26, 2019 at 04:21:01PM +0200, Ville Syrjälä wrote:
> >On Mon, Feb 25, 2019 at 04:03:05PM -0800, Lucas De Marchi wrote:
> >> On Mon, Feb 25, 2019 at 10:42:12PM +0200, Ville Syrjälä wrote:
> >> >On Fri, Feb 22, 2019 at 03:
So CI is reporting a few flips on Skylake for intel_engines_are_idle(),
so apply a double check that the ring is valid before inspecting the
registers. However, we keep the forcewake omission in play to avoid the
Sandybridge failure.
Fixes: 0b702dca2658 ("drm/i915: Avoid waking the engines just to
Quoting Patchwork (2019-02-27 17:41:59)
> Possible regressions
>
> * igt@i915_selftest@live_active:
> - fi-apl-guc: PASS -> DMESG-WARN
Second flip due to "drm/i915: Avoid waking the engines just to check if
they are idle", both skl.
Suggests that its passing earlier was f
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev3)
URL : https://patchwork.freedesktop.org/series/50513/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: introduce REG_BIT() and REG_GENMASK() to define re
== Series Details ==
Series: drm/i915: introduce macros to define register contents (rev3)
URL : https://patchwork.freedesktop.org/series/50513/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
918ed22b15ea drm/i915: introduce REG_BIT() and REG_GENMASK() to define register
conten
== Series Details ==
Series: series starting with [1/3] drm/i915: Use intel_engine_stop_cs when
stopping ringbuffer
URL : https://patchwork.freedesktop.org/series/57304/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12316
inline.
v2 patches fixes
- address calculation bug
- not killed
However, the test does not runs faster.
-caz
On Wed, 2019-02-27 at 16:29 +, Chris Wilson wrote:
> As we already have the previous portion of the mmap mlocked, we only
> need to mlock() the fresh portion for testing available memo
Quoting Mika Kuoppala (2019-02-27 16:58:50)
> Hardware cannot be in a middle of idle flow messaging
> when we pull the plug from ringbuffer. Disable idle
> messaging before we do so to avoid potential deadlock
> on engine initialization and reset.
>
> v2: INVALID_MMIO_REG, unconditional enable (Ch
Quoting Mika Kuoppala (2019-02-27 17:03:38)
> Mika Kuoppala writes:
>
> > We have an exported function for stopping the engine before
> > disabling a ringbuffer. Take it into use.
> >
> > Cc: Chris Wilson
> > Signed-off-by: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/intel_engine_cs.c | 3
From: Ville Syrjälä
Some monitors apparently forget to mark any mode as preferred in the
EDID. In this particular case we have a very generic looking ID
"PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk
doesn't seem particularly wise. Also the quirk we have
(EDID_QUIRK_FIRST_DETA
From: Ville Syrjälä
Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.
Assuming that another preferred mode didn't sneak in somehow
(is that even po
Quoting Mika Kuoppala (2019-02-27 16:58:49)
> We use identical sequence of stopping ringbuffer on reset
> handing and on ring initialization. Make a function
> to handle both cases.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reset.c | 18 +---
Quoting Mika Kuoppala (2019-02-27 16:58:48)
> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
> drivers/gpu/drm/i915/intel_ringbu
== Series Details ==
Series: series starting with [1/2] drm/i915/icl: Default to Thread Group
preemption for compute workloads
URL : https://patchwork.freedesktop.org/series/57300/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5666 -> Patchwork_12315
=
Mika Kuoppala writes:
> We have an exported function for stopping the engine before
> disabling a ringbuffer. Take it into use.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
> drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +
Den 27.02.2019 15.27, skrev Gerd Hoffmann:
> On Mon, Feb 25, 2019 at 03:42:30PM +0100, Noralf Trønnes wrote:
>> Use devm_drm_dev_init() and drop using tinydrm_device.
>>
>> v2: devm_drm_dev_register() was dropped so add driver release callbacks.
>>
>> Signed-off-by: Noralf Trønnes
>> ---
>> dri
v3 of [1] with naming hopefully settled (fingers crossed), and some more
compile time checks, documentation and other polish added.
The naming scheme of the local wrappers/copies of bit fiddling macros is
to just use REG_ prefix for the regular kernel ones, with hopefully
minimal confusion. So we
bitfield.h defines FIELD_GET() and FIELD_PREP() macros to access
bitfields using the mask alone, with no need for separate shift. Indeed,
the shift is redundant.
We define REG_FIELD_GET() and REG_FIELD_PREP() wrappers for the above,
in part to force u32 and for consistency with REG_BIT() and
REG_G
Slightly verbose, but does away with hand rolled shifts. Ties the field
values with the mask defining the field.
Unfortunately we have to make a local copy of FIELD_PREP() to evaluate
to a integer constant expression. But with this, we can ensure the mask
is non-zero, power of 2, fits u32, and the
Introduce REG_BIT(n) to define register bits and REG_GENMASK(h, l) to
define register bitfield masks.
We define the above as wrappers to BIT() and GENMASK() respectively to
force u32 type to go with our register size, and to add compile time
checks on the bit numbers.
The intention is that these
We use identical sequence of stopping ringbuffer on reset
handing and on ring initialization. Make a function
to handle both cases.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 18 +---
drivers/gpu/drm/i915/intel_engine_cs.c | 28 +
Hardware cannot be in a middle of idle flow messaging
when we pull the plug from ringbuffer. Disable idle
messaging before we do so to avoid potential deadlock
on engine initialization and reset.
v2: INVALID_MMIO_REG, unconditional enable (Chris)
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
--
We have an exported function for stopping the engine before
disabling a ringbuffer. Take it into use.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++
drivers/gpu/drm/i915/intel_ringbuffer.c | 31 +++--
2 files changed, 16 i
As we already have the previous portion of the mmap mlocked, we only
need to mlock() the fresh portion for testing available memory.
v2: Fixup the uint64_t pointer arithmetric and only use a single mmap to
avoid subsequent mlock fail (for reasons unknown, but bet on mm/).
Signed-off-by: Chris Wil
Quoting Michał Winiarski (2019-02-27 15:51:09)
> There are still some cases where userspace needs to change the
> preemption granularity for compute workloads. Let's whitelist the
> per-ctx granularity control register to allow it.
>
> Signed-off-by: Michał Winiarski
> Cc: Anuj Phogat
> Cc: Joon
Quoting Michał Winiarski (2019-02-27 15:51:09)
> There are still some cases where userspace needs to change the
> preemption granularity for compute workloads. Let's whitelist the
> per-ctx granularity control register to allow it.
Just wondering aloud if this should a single patch; change the def
We assumed that the default preemption granularity is fine for ICL.
Unfortunately, it turns out that some drivers don't support mid-thread
preemption for compute workloads.
If a workload that doesn't support mid-thread preemption gets mid-thread
preempted, we're going to observe a GPU hang.
While I
There are still some cases where userspace needs to change the
preemption granularity for compute workloads. Let's whitelist the
per-ctx granularity control register to allow it.
Signed-off-by: Michał Winiarski
Cc: Anuj Phogat
Cc: Joonas Lahtinen
Cc: Matt Roper
Cc: Rafael Antognolli
---
driv
Hi,
On 27-02-19 10:44, Heikki Krogerus wrote:
On Mon, Feb 25, 2019 at 02:20:37PM +0100, Hans de Goede wrote:
Use the new drm_kms_call_oob_hotplug_notifier_chain() function to load
drm/kms drivers know about DisplayPort over Type-C hotplug events.
Signed-off-by: Hans de Goede
I'm OK with thi
Hi,
On 27-02-19 12:16, Jani Nikula wrote:
On Wed, 27 Feb 2019, Heikki Krogerus wrote:
One thing that this series does not consider is the DP lane count
problem. The GPU drivers (i915 in this case) does not know is four,
two or one DP lanes in use.
Also, orientation.
The orientation should
Quoting Patchwork (2019-02-27 15:07:07)
> Possible fixes
>
> * igt@drm_read@short-buffer-nonblock:
> - shard-snb: INCOMPLETE [fdo#105411] -> PASS
That's the one, that's been 100% since the last IGT reorder.
-Chris
___
Intel-gfx
== Series Details ==
Series: drm/i915: Avoid waking the engines just to check if they are idle
URL : https://patchwork.freedesktop.org/series/57292/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5665_full -> Patchwork_12314_full
Quoting Tvrtko Ursulin (2019-02-27 14:17:25)
>
> On 27/02/2019 10:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-27 10:29:43)
> >>
> >> On 26/02/2019 10:23, Chris Wilson wrote:
> >>> As kmem_caches share the same properties (size, allocation/free behaviour)
> >>> for all potential dev
Quoting Christian König (2019-02-27 04:17:01)
> Am 27.02.19 um 00:04 schrieb Dave Airlie:
> >>> At the end of the day, I don't really care that much. I get it, we
> >>> all have large projects with scarce resources. I just think a few
> >>> years down the road we'll all regret it as a community.
On Mon, Feb 25, 2019 at 03:42:32PM +0100, Noralf Trønnes wrote:
> This protects device resources from use after device removal.
>
> There are 3 ways for driver-device unbinding to happen:
> - The driver module is unloaded causing the driver to be unregistered.
> This can't happen as long as ther
On Mon, Feb 25, 2019 at 03:42:30PM +0100, Noralf Trønnes wrote:
> Use devm_drm_dev_init() and drop using tinydrm_device.
>
> v2: devm_drm_dev_register() was dropped so add driver release callbacks.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/tinydrm/hx8357d.c | 40 +--
>
On 27/02/2019 11:15, Chris Wilson wrote:
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until its use across entire system has completed,
as any other timeline active on the GPU may still refer back to the
already retired timeline. We both have to delay
On Mon, Feb 25, 2019 at 03:42:28PM +0100, Noralf Trønnes wrote:
> Add driver example that shows how devm_drm_dev_init() can be used.
>
> v2: Expand docs (Sam, Daniel)
Acked-by: Gerd Hoffmann
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
h
On 27/02/2019 10:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-02-27 10:29:43)
On 26/02/2019 10:23, Chris Wilson wrote:
As kmem_caches share the same properties (size, allocation/free behaviour)
for all potential devices, we can use global caches. While this
potential has worse fragmen
On Mon, Feb 25, 2019 at 03:42:27PM +0100, Noralf Trønnes wrote:
> This adds a resource managed (devres) version of drm_dev_init().
>
> v2: Remove devm_drm_dev_register() since we can't touch hw in devm
> release functions and drivers want to disable hw on driver module
> unload (Daniel Vet
On Mon, Feb 25, 2019 at 03:42:26PM +0100, Noralf Trønnes wrote:
> This makes it safe to access drm_device->dev after the parent device has
> been removed/unplugged.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Gerd Hoffmann
___
Intel-gfx mailing li
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev3)
URL : https://patchwork.freedesktop.org/series/57244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5665_full -> Patchwork_12313_full
Chris Wilson writes:
> Exploit that reads of the ring registers return 0 from the engine when
> it is idle and we do not apply forcewake to know that if the engine is
> idle then both reads will be identical (and so we interpret the ring as
> idle).
>
> The ulterior motive is to try and reduce th
== Series Details ==
Series: drm/i915: Avoid waking the engines just to check if they are idle
URL : https://patchwork.freedesktop.org/series/57292/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5665 -> Patchwork_12314
Summ
Am 27.02.19 um 00:04 schrieb Dave Airlie:
At the end of the day, I don't really care that much. I get it, we
all have large projects with scarce resources. I just think a few
years down the road we'll all regret it as a community.
AMD and others have also spent years tuning TTM for both UMA an
== Series Details ==
Series: series starting with [01/11] drm/i915: Skip scanning for signalers if
we are already inflight (rev3)
URL : https://patchwork.freedesktop.org/series/57244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5665 -> Patchwork_12313
==
1 - 100 of 118 matches
Mail list logo
