On 2021-10-05 21:16:17 [+0200], Peter Zijlstra wrote:
> > -static inline void intel_context_mark_active(struct intel_context *ce)
> > +static inline void intel_context_mark_active(struct intel_context *ce,
> > +bool timeline_mutex_needed)
> > {
> > - lockd
== Series Details ==
Series: drm/i915/display: Wait PSR2 get out of deep sleep to update pipe (rev3)
URL : https://patchwork.freedesktop.org/series/95309/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10685_full -> Patchwork_21259_full
=
== Series Details ==
Series: drm: Add privacy-screen class and connector properties (rev6)
URL : https://patchwork.freedesktop.org/series/79259/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10685_full -> Patchwork_21258_full
===
== Series Details ==
Series: series starting with [v6,1/8] drm/i915/gem: Break out some shmem
backend utils
URL : https://patchwork.freedesktop.org/series/95476/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10685_full -> Patchwork_21257_full
=
== Series Details ==
Series: drm/i915/irq: don't use gt ptr for no reason.
URL : https://patchwork.freedesktop.org/series/95492/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10686 -> Patchwork_21261
Summary
---
**FA
== Series Details ==
Series: drm/i915/bios: gracefully disable dual eDP for now
URL : https://patchwork.freedesktop.org/series/95475/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10685_full -> Patchwork_21255_full
Summary
From: Dave Airlie
Neither of these functions want the gt at all, just pass regs
and i915.
Just noticed in passing.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_irq.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i91
== Series Details ==
Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
(rev4)
URL : https://patchwork.freedesktop.org/series/95127/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10686 -> Patchwork_21260
=
== Series Details ==
Series: drm/dp, drm/i915: Finish basic PWM support for VESA backlight helpers
(rev4)
URL : https://patchwork.freedesktop.org/series/95127/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixe
Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
w
As it turns out, apparently some machines will actually leave additional
backlight functionality like dynamic backlight control on before the OS
loads. Currently we don't take care to disable unsupported features when
writing back the backlight mode, which can lead to some rather strange
looking be
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 5 -
1 file changed,
This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that
When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us d
== Series Details ==
Series: drm/i915/display: Wait PSR2 get out of deep sleep to update pipe (rev3)
URL : https://patchwork.freedesktop.org/series/95309/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21259
===
== Series Details ==
Series: drm: Add privacy-screen class and connector properties (rev6)
URL : https://patchwork.freedesktop.org/series/79259/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21258
Summary
== Series Details ==
Series: drm: Add privacy-screen class and connector properties (rev6)
URL : https://patchwork.freedesktop.org/series/79259/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+
== Series Details ==
Series: drm: Add privacy-screen class and connector properties (rev6)
URL : https://patchwork.freedesktop.org/series/79259/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
81c0ef8541bc drm/connector: Add support for privacy-screen properties (v4)
-:151: CHECK
== Series Details ==
Series: series starting with [v6,1/8] drm/i915/gem: Break out some shmem
backend utils
URL : https://patchwork.freedesktop.org/series/95476/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21257
===
== Series Details ==
Series: series starting with [v6,1/8] drm/i915/gem: Break out some shmem
backend utils
URL : https://patchwork.freedesktop.org/series/95476/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checke
== Series Details ==
Series: series starting with [v6,1/8] drm/i915/gem: Break out some shmem
backend utils
URL : https://patchwork.freedesktop.org/series/95476/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
605eef61ebf9 drm/i915/gem: Break out some shmem backend utils
b116a99
== Series Details ==
Series: drm/i915/bios: gracefully disable dual eDP for now
URL : https://patchwork.freedesktop.org/series/95475/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21255
Summary
---
== Series Details ==
Series: CPU + GPU synchronised priority scheduling (rev4)
URL : https://patchwork.freedesktop.org/series/95294/
State : failure
== Summary ==
Applying: effective and consolidated user experience. In other words why user
would not be
error: drivers/gpu/drm/i915/i915_drm_cl
On Tue, Oct 05, 2021 at 10:47:11AM -0700, Umesh Nerlige Ramappa wrote:
> With GuC handling scheduling, i915 is not aware of the time that a
> context is scheduled in and out of the engine. Since i915 pmu relies on
> this info to provide engine busyness to the user, GuC shares this info
> with i915
== Series Details ==
Series: drm/i915: remove IS_ACTIVE (rev3)
URL : https://patchwork.freedesktop.org/series/95312/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21253_full
Summary
---
**FAIL
Alderlake-P was getting 'max time under evasion' messages when PSR2
is enabled, this is due PIPE_SCANLINE/PIPEDSL returning 0 over a
period of time longer than VBLANK_EVASION_TIME_US.
For PSR1 we had the same issue so intel_psr_wait_for_idle() was
implemented to wait for PSR1 to get into idle stat
== Series Details ==
Series: drm/i915/pmu: Connect engine busyness stats from GuC to pmu (rev2)
URL : https://patchwork.freedesktop.org/series/95043/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10685 -> Patchwork_21254
Su
== Series Details ==
Series: drm/i915/pmu: Connect engine busyness stats from GuC to pmu (rev2)
URL : https://patchwork.freedesktop.org/series/95043/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gt/uc/intel_guc.h:167: warning: Function param
== Series Details ==
Series: drm/i915/pmu: Connect engine busyness stats from GuC to pmu (rev2)
URL : https://patchwork.freedesktop.org/series/95043/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6044dafc24be drm/i915/pmu: Connect engine busyness stats from GuC to pmu
-:577: CH
== Series Details ==
Series: series starting with [1/1] drm/i915/adlp: Keep hardware default dbox B
credits (rev2)
URL : https://patchwork.freedesktop.org/series/94702/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21252_full
==
On Mon, Feb 15, 2021 at 04:21:35PM +0200, Andy Shevchenko wrote:
We have already few similar implementation and a lot of code that can benefit
of the yesno() helper. Consolidate yesno() helpers under string.h hood.
I was taking a look on i915_utils.h to reduce it and move some of it
elsewhere
On Tue, 2021-10-05 at 23:38 +0300, Jani Nikula wrote:
> On Tue, 05 Oct 2021, "Souza, Jose" wrote:
> > On Tue, 2021-10-05 at 20:56 +0300, Jani Nikula wrote:
> > > For the time being, neither the power sequencer nor the backlight code
> > > properly support two eDP panels simultaneously. While the s
On Tue, 05 Oct 2021, "Souza, Jose" wrote:
> On Tue, 2021-10-05 at 20:56 +0300, Jani Nikula wrote:
>> For the time being, neither the power sequencer nor the backlight code
>> properly support two eDP panels simultaneously. While the software
>> states will be independent, the same sets of register
On Sat, 2021-10-02 at 11:14 +0200, Hans de Goede wrote:
> Hi Lyude,
>
> On 10/2/21 12:53 AM, Lyude Paul wrote:
> > When I originally moved all of the VESA backlight code in i915 into DRM
> > helpers, one of the things I didn't have the hardware or time for
> > testing was machines that used a comb
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
Changes in v3:
- Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector()
Changes in v2:
- Call drm_connector_update_privacy_screen() from
intel_enable_ddi_dp() / intel_ddi_update_pipe_d
The upcoming privacy-screen support adds another check for
deferring probe till some other drivers have bound first.
Factor out the current vga_switcheroo_client_probe_defer() check
into an intel_modeset_probe_defer() helper, so that further
probe-deferral checks can be added there.
Reviewed-by:
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.
Registering a privacy-screen device with the new privacy-screen class
code will also
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Reviewed-by: Emil Velikov
Reviewed-by: Lyude Paul
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 18 --
1 file changed, 8 insertions
Factor the extended hotkey handling out of hotkey_notify_hotkey() and
into a new hotkey_notify_extended_hotkey() helper.
This is a preparation patch for adding support the privacy-screen hotkey
toggle (which needs some special handling, it should NOT send an evdev
key-event to userspace...).
Revi
Add 2 drm_connector privacy-screen helper functions:
1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.
Changes in v2:
- Drop WARN_ON(mutex_is_locked(&priv->lock)) check in
drm_privacy_screen_call_notifier_chain() it may be locked by
another thr
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.
This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.
Reviewed-by: Emil Vel
On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.
This commit adds a privacy-screen class allowing the dr
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
"privacy-screen hw-state", to deal with devices where the OS might be
lo
Hi all,
Here is a new version of my privacy-screen series, addressing the
review-remark from Ville on patch 10/10 from the version posted on
October 2nd. This new version contains the following changes:
- drm/i915: Add privacy-screen support (v3)
- Move drm_privacy_screen_get() call to intel_ddi
On Tue, 2021-10-05 at 20:56 +0300, Jani Nikula wrote:
> For the time being, neither the power sequencer nor the backlight code
> properly support two eDP panels simultaneously. While the software
> states will be independent, the same sets of registers will be used for
> both eDP panels, clobbering
== Series Details ==
Series: drm/i915: remove IS_ACTIVE (rev3)
URL : https://patchwork.freedesktop.org/series/95312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21253
Summary
---
**SUCCESS**
N
On Tue, 05 Oct 2021, Ville Syrjälä wrote:
> On Tue, Oct 05, 2021 at 08:56:36PM +0300, Jani Nikula wrote:
>> For the time being, neither the power sequencer nor the backlight code
>> properly support two eDP panels simultaneously. While the software
>> states will be independent, the same sets of r
On Mon, Oct 04, 2021 at 01:37:37PM +0300, Dan Carpenter wrote:
> The "digi_port" pointer can't be NULL and we have already dereferenced
> it so checking for NULL is not necessary. Delete the check.
>
> Signed-off-by: Dan Carpenter
Thanks. Applied to drm-intel-next.
> ---
> drivers/gpu/drm/i91
On Tue, Oct 05, 2021 at 05:00:46PM +0200, Sebastian Andrzej Siewior wrote:
> This is a revert of commits
>d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
> irqsafe")
>6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by
> timeline->mutex")
>
== Series Details ==
Series: series starting with [1/1] drm/i915/adlp: Keep hardware default dbox B
credits (rev2)
URL : https://patchwork.freedesktop.org/series/94702/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21252
Thanks for explanation. This patch is Acked-by: Oak Zeng
Regards,
Oak
> -Original Message-
> From: Auld, Matthew
> Sent: October 5, 2021 1:07 PM
> To: Zeng, Oak ; Thomas Hellström
> ; intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Christian König
>
> Subject: Re
== Series Details ==
Series: drm/i915: Improve DP link training further (rev5)
URL : https://patchwork.freedesktop.org/series/95405/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21250_full
Summary
-
We currently just evict lmem objects to system memory when under memory
pressure. For this case we might lack the usual object mm.pages, which
effectively hides the pages from the i915-gem shrinker, until we
actually "attach" the TT to the object, or in the case of lmem-only
objects it just gets mi
We already do this when mapping the pages.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 1 -
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/g
Attempt to document shrink_pin and the other relevant interfaces that
interact with it, before we start messing with it.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 24 +-
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 31 +++
Turn on the shmem tt backend, and enable shrinking.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/driver
This should let us do an accelerated copy directly to the shmem pages
when temporarily moving lmem-only objects, where the i915-gem shrinker
can later kick in to swap out the pages, if needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i9
From: Thomas Hellström
Break out some shmem backend utils for future reuse by the TTM backend:
shmem_alloc_st(), shmem_free_st() and __shmem_writeback() which we can
use to provide a shmem-backed TTM page pool for cached-only TTM
buffer objects.
Main functional change here is that we now compute
For cached objects we can allocate our pages directly in shmem. This
should make it possible(in a later patch) to utilise the existing
i915-gem shrinker code for such objects. For now this is still disabled.
v2(Thomas):
- Add optional try_to_writeback hook for objects. Importantly we need
to
The comment here is no longer accurate, since the current shrinker code
requires a full ref before touching any objects. Also unset_pages()
should already do the required make_unshrinkable() for us, if needed,
which is also nicely balanced with set_pages().
Signed-off-by: Matthew Auld
Cc: Thomas
On Tue, Oct 05, 2021 at 08:56:36PM +0300, Jani Nikula wrote:
> For the time being, neither the power sequencer nor the backlight code
> properly support two eDP panels simultaneously. While the software
> states will be independent, the same sets of registers will be used for
> both eDP panels, clo
On Mon, Oct 04, 2021 at 04:21:44PM +0100, Tvrtko Ursulin wrote:
On 24/09/2021 23:34, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to th
For the time being, neither the power sequencer nor the backlight code
properly support two eDP panels simultaneously. While the software
states will be independent, the same sets of registers will be used for
both eDP panels, clobbering the hardware state and leading to errors.
Gracefully disable
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for all engines using shared memory. For each engine, this
info contains:
- to
== Series Details ==
Series: drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup (rev3)
URL : https://patchwork.freedesktop.org/series/94105/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21248_full
===
When trying to bring IS_ACTIVE to linux/kconfig.h I thought it wouldn't
provide much value just encapsulating it in a boolean context. So I also
added the support for handling undefined macros as the IS_ENABLED()
counterpart. However the feedback received from Masahiro Yamada was that
it is too ugl
On Mon, Oct 04, 2021 at 03:06:32PM -0700, Matthew Brost wrote:
> Allow multiple batch buffers to be submitted in a single execbuf IOCTL
> after a context has been configured with the 'set_parallel' extension.
> The number batches is implicit based on the contexts configuration.
>
> This is impleme
On 05/10/2021 15:23, Zeng, Oak wrote:
Regards,
Oak
-Original Message-
From: Thomas Hellström
Sent: October 5, 2021 9:48 AM
To: Zeng, Oak ; Auld, Matthew
; intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Christian König
Subject: Re: [Intel-gfx] [PATCH v5 09/13] d
== Series Details ==
Series: drm/i915: PREEMPT_RT related fixups.
URL : https://patchwork.freedesktop.org/series/95463/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21251
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915: PREEMPT_RT related fixups.
URL : https://patchwork.freedesktop.org/series/95463/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4bae9e7a5800 drm/i915: Use preempt_disable/enable_rt() where recommended
-:7: WARNING:COMMIT_LOG_LONG_LINE: Poss
== Series Details ==
Series: series starting with [1/2] drm/dp: add drm_dp_phy_name() for getting DP
PHY name
URL : https://patchwork.freedesktop.org/series/95447/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21245_full
===
On Tue, Oct 05, 2021 at 01:34:21PM +0300, Jani Nikula wrote:
>
> Cc: Imre, I think you were involved in adding the checks.
About ADL-S the spec says:
Bspec 53597:
Combo Port Maximum Speed:
OEM must use VBT to specify a maximum that is tolerated by the board design.
Combo Port HBR3 support:
May
== Series Details ==
Series: drm/i915/display: Remove check for low voltage sku for max dp source
rate
URL : https://patchwork.freedesktop.org/series/95444/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683_full -> Patchwork_21244_full
==
Disabling interrupts and invoking the irq_work function directly breaks
on PREEMPT_RT.
PREEMPT_RT does not invoke all irq_work from hardirq context because
some of the user have spinlock_t locking in the callback function.
These locks are then turned into a sleeping locks which can not be
acquired
This is a revert of commits
d67739268cf0e ("drm/i915/gt: Mark up the nested engine-pm timeline lock as
irqsafe")
6c69a45445af9 ("drm/i915/gt: Mark context->active_count as protected by
timeline->mutex")
The existing code leads to a different behaviour depending on wheather
lockdep is enabl
The !irqs_disabled() check triggers on PREEMPT_RT even with
i915_sched_engine::lock acquired. The reason is the lock is transformed
into a sleeping lock on PREEMPT_RT and does not disable interrupts.
There is no need to check for disabled interrupts. The lockdep
annotation below already check if t
execlists_dequeue() is invoked from a function which uses
local_irq_disable() to disable interrupts so the spin_lock() behaves
like spin_lock_irq().
This breaks PREEMPT_RT because local_irq_disable() + spin_lock() is not
the same as spin_lock_irq().
execlists_dequeue_irq() and execlists_dequeue()
Hi,
the following patches are from the PREEMPT_RT queue. It is mostly about
disabling interrupts/preemption which leads to problems.
Unfortunately DRM_I915_LOW_LEVEL_TRACEPOINTS had to be disabled because
it acquires locks from within trace points.
I tested it on a SandyBridge with built-in i915 b
From: Mike Galbraith
Commit
8d7849db3eab7 ("drm/i915: Make sprite updates atomic")
started disabling interrupts across atomic updates. This breaks on PREEMPT_RT
because within this section the code attempt to acquire spinlock_t locks which
are sleeping locks on PREEMPT_RT.
According to the c
From: Mike Galbraith
Mario Kleiner suggest in commit
ad3543ede630f ("drm/intel: Push get_scanout_position() timestamping into kms
driver.")
a spots where preemption should be disabled on PREEMPT_RT. The
difference is that on PREEMPT_RT the intel_uncore::lock disables neither
preemption nor in
The order of the header files is important. If this header file is
included after tracepoint.h was included then the NOTRACE here becomes a
nop. Currently this happens for two .c files which use the tracepoitns
behind DRM_I915_LOW_LEVEL_TRACEPOINTS.
Cc: Steven Rostedt
Signed-off-by: Sebastian And
Luca Abeni reported this:
| BUG: scheduling while atomic: kworker/u8:2/15203/0x0003
| CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10
| Call Trace:
| rt_spin_lock+0x3f/0x50
| gen6_read32+0x45/0x1d0 [i915]
| g4x_get_vblank_counter+0x36/0x40 [i915]
| trace_event_raw_event_i915
On 05/10/2021 14:05, Thomas Hellström wrote:
Hi, Tvrtko,
On 10/5/21 13:31, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout/composition on Intel
igfx.
Before this patch the dr
On Wed, Sep 22, 2021 at 11:54:32AM +0300, Kai Vehmanen wrote:
> In current code, the devres group for aggregate master is left open
> after call to component_master_add_*(). This leads to problems when the
> master does further managed allocations on its own. When any
> participating driver calls c
== Series Details ==
Series: drm/i915: Improve DP link training further (rev5)
URL : https://patchwork.freedesktop.org/series/95405/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21250
Summary
---
Regards,
Oak
> -Original Message-
> From: Thomas Hellström
> Sent: October 5, 2021 9:48 AM
> To: Zeng, Oak ; Auld, Matthew
> ; intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Christian König
>
> Subject: Re: [Intel-gfx] [PATCH v5 09/13] drm/i915/ttm: add tt shmem
On Tue, Oct 05, 2021 at 12:49:53PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Improve DP link training further (rev4)
> URL : https://patchwork.freedesktop.org/series/95405/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21
On 10/5/21 04:05, Zeng, Oak wrote:
Hi Matthew/Thomas,
See one question inline
Regards,
Oak
-Original Message-
From: Intel-gfx On Behalf Of Matthew
Auld
Sent: September 27, 2021 7:41 AM
To: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Thomas Hellström
; Chri
== Series Details ==
Series: drm/i915: Improve DP link training further (rev5)
URL : https://patchwork.freedesktop.org/series/95405/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dee501a3511e drm/i915: Tweak the DP "max vswing reached?" condition
94bb4313c0df drm/i915: Show LTT
== Series Details ==
Series: series starting with [01/28] dma-buf: add
dma_resv_for_each_fence_unlocked v8
URL : https://patchwork.freedesktop.org/series/95456/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21249
== Series Details ==
Series: series starting with [01/28] dma-buf: add
dma_resv_for_each_fence_unlocked v8
URL : https://patchwork.freedesktop.org/series/95456/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: series starting with [01/28] dma-buf: add
dma_resv_for_each_fence_unlocked v8
URL : https://patchwork.freedesktop.org/series/95456/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4d20a8353f25 dma-buf: add dma_resv_for_each_fence_unlocked v8
-:23: WA
== Series Details ==
Series: drm/i915: Handle Intel igfx + Intel dgfx hybrid graphics setup (rev3)
URL : https://patchwork.freedesktop.org/series/94105/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21248
Hi, Tvrtko,
On 10/5/21 13:31, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In short this makes i915 work for hybrid setups (DRI_PRIME=1 with Mesa)
when rendering is done on Intel dgfx and scanout/composition on Intel
igfx.
Before this patch the driver was not quite ready for that setup, mainly
== Series Details ==
Series: drm/i915: Improve DP link training further (rev4)
URL : https://patchwork.freedesktop.org/series/95405/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10683 -> Patchwork_21247
Summary
---
Am 05.10.21 um 14:40 schrieb Tvrtko Ursulin:
On 05/10/2021 12:37, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
Reviewed-by: Tvrtko Ursulin
Reminder - r-b was retracted until at least more
On 05/10/2021 12:37, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
Reviewed-by: Tvrtko Ursulin
Reminder - r-b was retracted until at least more text is added to commit
message about pros
There was an issue with fd.o expired root cert, and that caused some issues
during the weekend and yesterday, mostly with git fetches. I wonder if this
is related. Can you re-test the patchset and see if the issue persists?
Other patchsets nearby timewise seem to be unaffected by spurious sparses.
1 - 100 of 172 matches
Mail list logo
