== Series Details ==
Series: drm/i915/dp: Do not switch aux to TBT mode for non-TC ports (rev2)
URL : https://patchwork.freedesktop.org/series/68691/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7221_full -> Patchwork_15062_full
== Series Details ==
Series: series starting with [1/2] drm/i915/tgl: Add SFC instdone to error state
URL : https://patchwork.freedesktop.org/series/68732/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7220_full -> Patchwork_15060_full
== Series Details ==
Series: series starting with [1/2] drm/i915: drop lrc header page
URL : https://patchwork.freedesktop.org/series/68800/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7228 -> Patchwork_15080
Summary
On 2019/10/31 上午5:23, Christoph Hellwig wrote:
On Wed, Oct 30, 2019 at 02:44:44PM +0800, Jason Wang wrote:
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to
Recent GuC binaries (including all the ones we're currently using)
don't require this shared area anymore, having moved the relevant
entries into the stage pool instead. i915 itself doesn't write
anything into it either, so we can safely drop it.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Chris
Recent GuC doesn't require the shared area. We still have one user in
i915 (engine reset via guc) because we haven't updated the command to
match the current guc submission flow [1]. Since the flow in guc is
about to change again, just disable the command for now and add a note
that we'll
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
between commit:
59cd826fb5e7 ("drm/i915: Fix PCH reference clock for FDI on HSW/BDW")
from the drm-intel-fixes tree and commit:
7d423af9bfb1 ("drm/i915: Implement a better i945gm vblank
And initialise fence to -1 to avoid closing stdin (fd:0)!
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_persistence.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/tests/i915/gem_ctx_persistence.c b/tests/i915/gem_ctx_persistence.c
index
Hi Chris,
On Wed, Oct 30, 2019 at 10:38:27AM +, Chris Wilson wrote:
> Currently we shutdown rc6 during i915_gem_resume() but this is called
> during the preparation phase (i915_drm_prepare) for all suspend paths,
> but we only want to shutdown rc6 for S3+. Move the actual shutdown to
>
== Series Details ==
Series: drm/i915/tgl: add support to one DP-MST stream (rev3)
URL : https://patchwork.freedesktop.org/series/68671/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7219_full -> Patchwork_15059_full
On 10/26/19 3:44 AM, Michal Wajdeczko wrote:
On Sat, 26 Oct 2019 02:35:06 +0200, Daniele Ceraolo Spurio
wrote:
GuC 35.2.0 and HuC 7.0.3 are the first production releases for TGL.
GuC 35.2 for gen12 is interface-compatible with 33.0 on older gens,
because the differences are related to
On Tue, 29 Oct 2019 at 16:51, Matthew Auld wrote:
>
> Intended for upstream testing so that we can still exercise the LMEM
> plumbing and !i915_ggtt_has_aperture paths. Smoke tested on Skull Canyon
> device. This works by allocating an intel_memory_region for a reserved
> portion of system
== Series Details ==
Series: drm/i915/guc: Skip suspend/resume GuC action on platforms w/o GuC
submission (rev3)
URL : https://patchwork.freedesktop.org/series/68685/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7227 -> Patchwork_15079
On Wed, Oct 30, 2019 at 02:44:44PM +0800, Jason Wang wrote:
> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented through vringh
> and workqueue. A device specific dma ops is to make sure HVA is used
> directly as the IOVA.
From: Don Hiatt
On some platforms (e.g. KBL) that do not support GuC submission, but
the user enabled the GuC communication (e.g for HuC authentication)
calling the GuC EXIT_S_STATE action results in lose of ability to
enter RC6. We can remove the GuC suspend/resume entirely as we do
not need to
On Wed, Oct 30, 2019 at 06:15:35PM +0100, Janusz Krzysztofik wrote:
Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
addresses for !ppgtt") introduced filtering of addresses possibly
occupied by other users of shared GTT. Unfortunately, that filtering
doesn't distinguish
== Series Details ==
Series: series starting with [01/11] drm/i915: Split detaching and removing the
vma
URL : https://patchwork.freedesktop.org/series/68788/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7226 -> Patchwork_15078
== Series Details ==
Series: drm/i915: Split detaching and removing the vma
URL : https://patchwork.freedesktop.org/series/68787/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7226 -> Patchwork_15077
Summary
---
== Series Details ==
Series: drm/i915: Preload LUTs if the hw isn't currently using them
URL : https://patchwork.freedesktop.org/series/68785/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7226 -> Patchwork_15076
Summary
== Series Details ==
Series: drm/i915/display: only include intel_dp_link_training.h where needed
(rev2)
URL : https://patchwork.freedesktop.org/series/68711/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7218_full -> Patchwork_15057_full
While I'm generally a fan of this change, we've been talking on IRC a bit
today and, apparently, the X server hasn't actually had a release where
modifiers have been enabled by default so this is causing problems. Adam &
Daniel, is there something that's preventing us from enabling it by
default?
Our timelines are currently contained within an intel_gt, and we only
need to perform list/spinlock initialisation, so we can pull the
intel_timelines_init() into our intel_gt_init_early().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt.c | 2 ++
Only add the engine to the available set of uabi engines once it has
been fully initialised and we know we want it in the public set.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Michał Wajdeczko
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 ++-
1 file changed, 2
Instead of rummaging through the intel_context to peek at the GEM
context in the middle of request submission to decide whether to use
semaphores, store that information on the intel_context itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 52
Currently we shutdown rc6 during i915_gem_resume() but this is called
during the preparation phase (i915_drm_prepare) for all suspend paths,
but we only want to shutdown rc6 for S3+. Move the actual shutdown to
i915_gem_suspend_late().
We then need to differentiate between suspend targets, to
Assume all responsibility for operating on the HW to sanitize the GT
state upon load/resume in intel_gt_sanitize() itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 5 ---
drivers/gpu/drm/i915/gt/intel_gt.c| 6 ++-
We already track the debugfs user_forcewake on the GT, so it is natural
to pull the suspend/resume handling under gt/ as well.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 22 --
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 22 ++
As we already do reload the kernel context in intel_gt_resume, repeating
that action inside i915_gem_resume() as well is redundant.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 30 --
1 file changed, 30 deletions(-)
diff --git
Allocate only an internal intel_context for the kernel_context, forgoing
a global GEM context for internal use as we only require a separate
address space (for our own protection).
Now having weaned GT from requiring ce->gem_context, we can stop
referencing it entirely. This also means we no
Keep the intel_context as being the primary state for i915_request, with
the GEM context a backpointer from the low level state for the rarer
cases we need client information. Our goal is to remove such references
to clients from the backend, and leave the HW submission agnostic to
client
As the GEM global context setup is now independent of the GT state
(although GT does currently still depending upon the global
i915->kernel_context), we can move its init earlier, leaving the gt init
ready to extracted.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c
In order to keep the assert_bind_count() valid, we need to hold the vma
page reference until after we drop the bind count. However, we must also
keep the drm_mm_remove_node() as the last action of i915_vma_unbind() so
that it serialises with the unlocked check inside i915_vma_destroy(). So
we need
On Mon, Oct 28, 2019 at 02:24:59PM -0700, Bob Paauwe wrote:
> Add XYUV to the list of DRM Formats to test.
>
> Also fix the byte order for the format.
>
> Signed-off-by: Bob Paauwe
Looks like CI got confused by this. You'll want to
Cc: igt-...@lists.freedesktop.org
and also set your
In order to keep the assert_bind_count() valid, we need to hold the vma
page reference until after we drop the bind count. However, we must also
keep the drm_mm_remove_node() as the last action of i915_vma_unbind() so
that it serialises with the unlocked check inside i915_vma_destroy(). So
we need
From: Ville Syrjälä
The LUTs are single buffered so in order to program them without
tearing we'd have to do it during vblank (actually to be 100%
effective it has to happen between start of vblank and frame start).
We have no proper mechanism for that at the moment so we just
defer loading them
Hi Daniel, Dave,
Here is this week's round of fixes for drm-misc.
Thanks!
Maxime
drm-misc-fixes-2019-10-30-1:
- three fixes for panfrost, one to silence a warning, one to fix
runtime_pm and one to prevent bogus pointer dereferences
- one fix for a memleak in v3d
The following changes since
On Wed, Oct 30, 2019 at 7:23 PM Lyude Paul wrote:
>
> On Wed, 2019-10-30 at 10:21 +0100, Daniel Vetter wrote:
> > On Tue, Oct 29, 2019 at 11:06 PM Lyude Paul wrote:
> > > topic/mst-suspend-resume-reprobe-2019-10-29-2:
> > > UAPI Changes:
> > >
> > > Cross-subsystem Changes:
> > >
> > > Core
== Series Details ==
Series: series starting with [1/4] drm/i915/bios: use a flag for vbt hdmi level
shift presence
URL : https://patchwork.freedesktop.org/series/68729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7218_full -> Patchwork_15056_full
On Wed, 2019-10-30 at 10:21 +0100, Daniel Vetter wrote:
> On Tue, Oct 29, 2019 at 11:06 PM Lyude Paul wrote:
> > topic/mst-suspend-resume-reprobe-2019-10-29-2:
> > UAPI Changes:
> >
> > Cross-subsystem Changes:
> >
> > Core Changes:
> > * Handle UP requests asynchronously in the DP MST helpers,
== Series Details ==
Series: drm/i915/lmem: add the fake lmem region (rev2)
URL : https://patchwork.freedesktop.org/series/68733/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7226 -> Patchwork_15075
Summary
---
Quoting Matthew Auld (2019-10-30 17:33:20)
> Intended for upstream testing so that we can still exercise the LMEM
> plumbing and !i915_ggtt_has_aperture paths. Smoke tested on Skull Canyon
> device. This works by allocating an intel_memory_region for a reserved
> portion of system memory, which we
Op 30-10-2019 om 18:03 schreef Ville Syrjälä:
> On Wed, Oct 30, 2019 at 03:26:48PM +0100, Maarten Lankhorst wrote:
>> intel_get_load_detect_pipe() needs to set uapi active,
>> uapi enable is set by the call to drm_atomic_set_mode_for_crtc(),
>> so we can remove it.
>>
>>
== Series Details ==
Series: drm/i915/lmem: add the fake lmem region (rev2)
URL : https://patchwork.freedesktop.org/series/68733/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bfc4292da998 drm/i915/lmem: add the fake lmem region
-:109: CHECK:PARENTHESIS_ALIGNMENT: Alignment
On Mon, Oct 28, 2019 at 07:58:51PM +0100, Hans de Goede wrote:
> Since commit 051a6d8d3ca0 ("drm/i915: Move LUT programming to happen after
> vblank waits"), I am seeing an ugly colored flash of the first few display
> lines on 2 Cherry Trail devices when the gamma table gets set for the first
>
Intended for upstream testing so that we can still exercise the LMEM
plumbing and !i915_ggtt_has_aperture paths. Smoke tested on Skull Canyon
device. This works by allocating an intel_memory_region for a reserved
portion of system memory, which we treat like LMEM. For the LMEMBAR we
steal the
Commit a355b2d6eb42 ("igt/gem_exec_reloc: Filter out unavailable
addresses for !ppgtt") introduced filtering of addresses possibly
occupied by other users of shared GTT. Unfortunately, that filtering
doesn't distinguish actually occupied addresses from otherwise invalid
softpin offsets. For
On Wed, Oct 30, 2019 at 03:26:56PM +0100, Maarten Lankhorst wrote:
> Splitting plane state is easier than splitting crtc_state,
> before plane check we copy the drm properties to hw so we can
> do the same in bigjoiner later on.
>
> We copy the state after we did all the modeset handling, but
On Wed, Oct 30, 2019 at 03:26:48PM +0100, Maarten Lankhorst wrote:
> intel_get_load_detect_pipe() needs to set uapi active,
> uapi enable is set by the call to drm_atomic_set_mode_for_crtc(),
> so we can remove it.
>
> intel_pipe_config_compare() needs to look at hw state, but I didn't
> change
On Wed, Oct 30, 2019 at 03:26:57PM +0100, Maarten Lankhorst wrote:
> Now that we split plane_state which I didn't want to do yet, we can
> program the slave plane without requiring the master plane.
>
> This is useful for programming bigjoiner slave planes as well. We
> will no longer need the
On Wed, Oct 30, 2019 at 03:26:51PM +0100, Maarten Lankhorst wrote:
> Now that we separated everything into uapi and hw, it's
> time to make the split definitive. Remove the union and
> make a copy of the hw state on modeset and fastset.
>
> Color blobs are copied in crtc atomic_check(), right
>
On Wed, Oct 30, 2019 at 03:26:55PM +0100, Maarten Lankhorst wrote:
> Split up plane_state->base to uapi. This is done using the following patch,
> ran after the previous commit that splits out any hw references:
>
> @@
> struct intel_plane_state *T;
> identifier x;
> @@
> -T->base.x
> +T->uapi.x
On Wed, Oct 30, 2019 at 03:26:53PM +0100, Maarten Lankhorst wrote:
> get_crtc_from_states() is called before plane_state is copied to uapi,
> so use the uapi state there.
>
> intel_legacy_cursor_update() could probably get away with looking at
> the hw state, but for clarity always look at the
== Series Details ==
Series: series starting with [1/5] drm/i915: Use drm_rect to simplify plane
{crtc, src}_{x, y, w, h} printing
URL : https://patchwork.freedesktop.org/series/68728/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7216_full -> Patchwork_15055_full
>> >>-Original Message-
>> >>From: Intel-gfx On Behalf
>> >>Of Ville Syrjala
>> >>Sent: Tuesday, October 8, 2019 9:45 PM
>> >>To: intel-gfx@lists.freedesktop.org
>> >>Subject: [Intel-gfx] [PATCH 7/9] drm/i915: Reject ckey+fp16 on skl+
>> >>
>> >>From: Ville Syrjälä
>> >>
>> >>According
== Series Details ==
Series: series starting with [CI,01/12] drm/i915: Handle a few more cases for
crtc hw/uapi split, v3.
URL : https://patchwork.freedesktop.org/series/68775/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7224 -> Patchwork_15074
Op 29-10-2019 om 15:55 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> The core no longer uses drm_crtc_state::mode with atomic drivers,
> so let's stop frobbing it in the driver. For the user mode readout
> we'll just use an on stack mode.
>
> Signed-off-by: Ville Syrjälä
> ---
>
== Series Details ==
Series: series starting with [CI,01/12] drm/i915: Handle a few more cases for
crtc hw/uapi split, v3.
URL : https://patchwork.freedesktop.org/series/68775/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Handle a few
On Tue, 29 Oct 2019, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We always pass mode==NULL to intel_get_load_detect_pipe(). Remove
> the pointless function argument.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 2 +-
>
On Wed, Oct 30, 2019 at 12:06:53AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Avoid HPD poll detect triggering a new detect cycle (rev2)
> URL : https://patchwork.freedesktop.org/series/68644/
> State : success
Thanks for the review, pushed to -dinq.
>
> == Summary
== Series Details ==
Series: series starting with [CI,01/12] drm/i915: Handle a few more cases for
crtc hw/uapi split, v3.
URL : https://patchwork.freedesktop.org/series/68775/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
82ecaad3eafe drm/i915: Handle a few more cases for
On Wed, 30 Oct 2019 14:50:09 +0100,
Ville Syrjälä wrote:
>
> On Tue, Oct 29, 2019 at 09:52:57PM +0100, Takashi Iwai wrote:
> > On Tue, 29 Oct 2019 20:10:50 +0100,
> > From: Takashi Iwai
> > Subject: [PATCH] ALSA: hda - Fix mutex deadlock in HDMI codec driver
> >
> > The commit ade49db337a9
Split up plane_state->base to hw. This is done using the following patch:
@@
struct intel_plane_state *T;
identifier x =~
"^(crtc|fb|alpha|pixel_blend_mode|rotation|color_encoding|color_range)$";
@@
-T->base.x
+T->hw.x
Signed-off-by: Maarten Lankhorst
Reviewed-by: Ville Syrjälä
---
intel_get_load_detect_pipe() needs to set uapi active,
uapi enable is set by the call to drm_atomic_set_mode_for_crtc(),
so we can remove it.
intel_pipe_config_compare() needs to look at hw state, but I didn't
change spatch to look at it. It's easy enough to do manually.
intel_atomic_check()
Prepare to split up hw and uapi machinally, by adding a uapi and
hw alias. We will remove the base in a bit. This is a split from the
original uapi/hw patch, which did it all in one go.
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/display/intel_atomic_plane.c| 16
Now that we split plane_state which I didn't want to do yet, we can
program the slave plane without requiring the master plane.
This is useful for programming bigjoiner slave planes as well. We
will no longer need the master's plane_state.
Changes since v1:
- set src/dst rectangles after
Now that we separated everything into uapi and hw, it's
time to make the split definitive. Remove the union and
make a copy of the hw state on modeset and fastset.
Color blobs are copied in crtc atomic_check(), right
before color management is checked.
Changes since v1:
- Copy all blobs
get_crtc_from_states() is called before plane_state is copied to uapi,
so use the uapi state there.
intel_legacy_cursor_update() could probably get away with looking at
the hw state, but for clarity always look at the uapi state.
Changes since v1:
- Convert entirety of intel_legacy_cursor_update
Splitting plane state is easier than splitting crtc_state,
before plane check we copy the drm properties to hw so we can
do the same in bigjoiner later on.
We copy the state after we did all the modeset handling, but fortunately
i915 seems to be split correctly and nothing during modeset looks
at
Split up plane_state->base to uapi. This is done using the following patch,
ran after the previous commit that splits out any hw references:
@@
struct intel_plane_state *T;
identifier x;
@@
-T->base.x
+T->uapi.x
@@
struct intel_plane_state *T;
@@
-T->base
+T->uapi
Signed-off-by: Maarten
Split up crtc_state->base to hw where appropriate. This is done using the
following patch:
@@
struct intel_crtc_state *T;
identifier x =~
"^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$";
@@
-T->base.x
+T->hw.x
@@
struct drm_crtc_state *T;
identifier x =~
Prepare to split up hw and uapi machinally, by adding a uapi and
hw alias. We will remove the base in a bit. This is a split from the
original uapi/hw patch, which did it all in one go.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 8 --
We are still looking at drm_crtc_state in a few places, convert those
to use intel_crtc_state instead.
Changes since v1:
- Move to before uapi/hw split.
- Add hunks for intel_pm.c as well.
Changes since v2:
- Incorporate Ville's feedback.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matt Roper
On Mon, Oct 28, 2019 at 08:15:17PM +0200, Imre Deak wrote:
> For the HPD interrupt functionality the HW depends on power wells in the
> display core domain to be on. Accordingly when enabling these power
> wells the HPD polling logic will force an HPD detection cycle to account
> for hotplug
On Tue, Oct 29, 2019 at 09:52:57PM +0100, Takashi Iwai wrote:
> On Tue, 29 Oct 2019 20:10:50 +0100,
> From: Takashi Iwai
> Subject: [PATCH] ALSA: hda - Fix mutex deadlock in HDMI codec driver
>
> The commit ade49db337a9 ("ALSA: hda/hdmi - Allow audio component for
> AMD/ATI and Nvidia HDMI")
== Series Details ==
Series: drm/i915: Stop frobbing crtc->base.mode
URL : https://patchwork.freedesktop.org/series/68725/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7215_full -> Patchwork_15054_full
Summary
---
On Wed, Oct 30, 2019 at 10:17:52AM +0100, Maarten Lankhorst wrote:
> Op 29-10-2019 om 19:35 schreef Ville Syrjälä:
> > On Tue, Oct 29, 2019 at 08:22:18AM +0100, Maarten Lankhorst wrote:
> >> Use this in all the places where we try to acquire planes after the planes
> >> atomic_check().
> >>
> >>
Op 29-10-2019 om 16:43 schreef Ville Syrjälä:
> On Tue, Oct 29, 2019 at 08:22:28AM +0100, Maarten Lankhorst wrote:
>> Split up plane_state->base to uapi. This is done using the following patch,
>> ran after the previous commit that splits out any hw references:
>>
>> @@
>> struct intel_plane_state
On Wed, 30 Oct 2019, Chris Chiu wrote:
> Hi guys,
> We have 2 laptops, ASUS Z406MA and Acer TravelMate B118, both
> powered by the same Intel N5000 GemniLake CPU. On the Acer laptop, the
> panel will blink once during boot which never happens on the ASUS
> laptop. It caught my attention and I
Quoting Mika Kuoppala (2019-10-30 12:30:47)
> Chris Wilson writes:
>
> > For this test, we need a laptop running on battery power so that we can
> > read the battery charge level before and after suspend. And then wait
> > long enough for a reliable measure.
> >
> > References:
Some time ago amdgpu changed their ABI to reject unknown compute rings,
so we should query the available set prior to execution.
Signed-off-by: Chris Wilson
---
tests/amdgpu/amd_basic.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/tests/amdgpu/amd_basic.c
== Series Details ==
Series: series starting with [1/3] drm/i915: Drop GEM context as a direct link
from i915_request (rev2)
URL : https://patchwork.freedesktop.org/series/68769/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7223 -> Patchwork_15073
Hi Chris,
On Wed, Oct 30, 2019 at 10:38:23AM +, Chris Wilson wrote:
> During startup, we may find ourselves in an interesting position where
> we haven't fully enabled RPS before the display starts trying to use it.
> This may lead to an imbalance in our "interactive" counter:
yes, makes
Chris Wilson writes:
> For this test, we need a laptop running on battery power so that we can
> read the battery charge level before and after suspend. And then wait
> long enough for a reliable measure.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=111909
> Signed-off-by: Chris
Allocate only an internal intel_context for the kernel_context, forgoing
a global GEM context for internal use as we only require a separate
address space (for our own protection).
Now having weaned GT from requiring ce->gem_context, we can stop
referencing it entirely. This also means we no
== Series Details ==
Series: series starting with [1/5] drm/i915/gt: Always track callers to
intel_rps_mark_interactive()
URL : https://patchwork.freedesktop.org/series/68770/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7223 -> Patchwork_15072
== Series Details ==
Series: series starting with [1/5] drm/i915/gt: Always track callers to
intel_rps_mark_interactive()
URL : https://patchwork.freedesktop.org/series/68770/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
62347effd8e0 drm/i915/gt: Always track callers to
== Series Details ==
Series: drm/i915/gt: Always track callers to intel_rps_mark_interactive() (rev2)
URL : https://patchwork.freedesktop.org/series/68764/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7223 -> Patchwork_15071
== Series Details ==
Series: drm/i915/perf: ensure selftests select valid format
URL : https://patchwork.freedesktop.org/series/68723/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7213_full -> Patchwork_15052_full
Summary
== Series Details ==
Series: drm/i915/gt: Always track callers to intel_rps_mark_interactive() (rev2)
URL : https://patchwork.freedesktop.org/series/68764/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0802e1c1452f drm/i915/gt: Always track callers to
Currently we shutdown rc6 during i915_gem_resume() but this is called
during the preparation phase (i915_drm_prepare) for all suspend paths,
but we only want to shutdown rc6 for S3+. Move the actual shutdown to
i915_gem_suspend_late().
We then need to differentiate between suspend targets, to
Assume all responsibility for operating on the HW to sanitize the GT
state upon load/resume in intel_gt_sanitize() itself.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 5 ---
drivers/gpu/drm/i915/gt/intel_gt.c| 6 ++-
During startup, we may find ourselves in an interesting position where
we haven't fully enabled RPS before the display starts trying to use it.
This may lead to an imbalance in our "interactive" counter:
<3>[4.813326] intel_rps_mark_interactive:652
GEM_BUG_ON(!rps->power.interactive)
<4>[
We already track the debugfs user_forcewake on the GT, so it is natural
to pull the suspend/resume handling under gt/ as well.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 22 --
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 22 ++
As we already do reload the kernel context in intel_gt_resume, repeating
that action inside i915_gem_resume() as well is redundant.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 30 --
1 file changed, 30 deletions(-)
diff --git
== Series Details ==
Series: series starting with [1/3] drm/i915: Drop GEM context as a direct link
from i915_request
URL : https://patchwork.freedesktop.org/series/68769/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7223 -> Patchwork_15070
On Wed, Oct 30, 2019 at 6:25 PM Chris Chiu wrote:
>
> Hi guys,
> We have 2 laptops, ASUS Z406MA and Acer TravelMate B118, both
> powered by the same Intel N5000 GemniLake CPU. On the Acer laptop, the
> panel will blink once during boot which never happens on the ASUS
> laptop. It caught my
Hi guys,
We have 2 laptops, ASUS Z406MA and Acer TravelMate B118, both
powered by the same Intel N5000 GemniLake CPU. On the Acer laptop, the
panel will blink once during boot which never happens on the ASUS
laptop. It caught my attention and I find the difference between them
but I need help
During startup, we may find ourselves in an interesting position where
we haven't fully enabled RPS before the display starts trying to use it.
This may lead to an imbalance in our "interactive" counter:
<3>[4.813326] intel_rps_mark_interactive:652
GEM_BUG_ON(!rps->power.interactive)
<4>[
Op 29-10-2019 om 14:23 schreef Ville Syrjälä:
> On Tue, Oct 29, 2019 at 08:22:21AM +0100, Maarten Lankhorst wrote:
>> intel_get_load_detect_pipe() needs to set uapi active,
>> uapi enable is set by the call to drm_atomic_set_mode_for_crtc(),
>> so we can remove it.
>>
>>
Keep the intel_context as being the primary state for i915_request, with
the GEM context a backpointer from the low level state for the rarer
cases we need client information. Our goal is to remove such references
to clients from the backend, and leave the HW submission agnostic to
client
1 - 100 of 125 matches
Mail list logo
