On Fri, 23 Nov 2018, Radhakrishna Sripada
wrote:
> For gen10+ the offsets for Slice PG cntl/ EU PG cntl donot scale well for
> higher slices.
Maybe it's time to realize using calculations like this isn't viable
anymore. For a seemingly simple change like this, I think it just takes
too long to
If the engine's seqno is already at our target seqno (most likely it
hasn't been used since the last reset), we can skip serialising the
engine and leave it as is.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_request.c | 3 +++
1 file changed, 3 insertions(+)
dif
== Series Details ==
Series: series starting with [1/2] drm/i915: Hook into the reboot notifier to
cancel outstanding GPU operations
URL : https://patchwork.freedesktop.org/series/52984/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5199 -> Patchwork_10901 =
== Summary - S
== Series Details ==
Series: drm/i915/gvt: fix spelling mistake "Interupts" -> "Interrupts"
URL : https://patchwork.freedesktop.org/series/52987/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5199 -> Patchwork_10902 =
== Summary - SUCCESS ==
No regressions found.
Exte
Pulled this now.
Regards, Joonas
Quoting Zhenyu Wang (2018-11-26 04:18:20)
>
> Hi,
>
> Here's regular gvt fixes for 4.20-rc5. One to correct MOCS registers
> load on engine list, one for rpm lock warning fix, and another for
> use-after-free fix for partial ggtt list destroy. Details below.
>
On Mon, Nov 26, 2018 at 09:33:13AM +0200, Jani Nikula wrote:
> On Fri, 23 Nov 2018, Imre Deak wrote:
> > On Fri, Nov 23, 2018 at 02:03:18PM +0200, Jani Nikula wrote:
> >> On Mon, 19 Nov 2018, Imre Deak wrote:
> >> > Depending on the transcoder enum values to translate from transcoder to
> >> > t
Quoting Chris Wilson (2018-11-02 18:12:13)
> When we first introduced the reset to sanitize the GPU on taking over
> from the BIOS and before returning control to third parties (the BIOS!),
> we restricted it to only systems utilizing HW contexts as we were
> uncertain of how stable our reset mecha
On 02/11/2018 16:12, Chris Wilson wrote:
The information presented here is not relevant to current development.
We can either use the context information, but more often we want to
inspect the active gpu state.
The ulterior motive is to eradicate dev->filelist.
Signed-off-by: Chris Wilson
---
On 02/11/2018 16:12, Chris Wilson wrote:
We have two classes of VM, global GTT and per-process GTT. In order to
allow ourselves the freedom to mix both along call chains, distinguish
the two classes with regards to their mutex and lockdep maps.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm
On Fri, Nov 23, 2018 at 1:13 PM Koenig, Christian
wrote:
> Am 23.11.18 um 18:36 schrieb Eric Anholt:
> > Christian König writes:
> >> Am 20.11.18 um 21:57 schrieb Eric Anholt:
> >>> Kenny Ho writes:
> Account for the number of command submitted to amdgpu by type on a per
> cgroup basi
On 2018-10-22 1:23 p.m., Arun KS wrote:
> Remove managed_page_count_lock spinlock and instead use atomic
> variables.
>
> Suggested-by: Michal Hocko
> Suggested-by: Vlastimil Babka
> Signed-off-by: Arun KS
Acked-by: Felix Kuehling
Regards,
Felix
>
> ---
> As discussed here,
> https://patch
== Series Details ==
Series: series starting with [1/2] drm/i915: Hook into the reboot notifier to
cancel outstanding GPU operations
URL : https://patchwork.freedesktop.org/series/52984/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5199_full -> Patchwork_10901_full =
== S
== Series Details ==
Series: drm/i915/gvt: fix spelling mistake "Interupts" -> "Interrupts"
URL : https://patchwork.freedesktop.org/series/52987/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5199_full -> Patchwork_10902_full =
== Summary - SUCCESS ==
No regressions foun
We may be simply restarting too fast for the culmudgeonly gen3/gen4 as
we still see missing interrupts following a reset. So let's try
restarting a little slower, first wake up the ring empty and then tell
it about the work it has to perform.
References: https://bugs.freedesktop.org/show_bug.cgi?i
== Series Details ==
Series: drm/i915: Skip engine serialisation for no-op seqno reset
URL : https://patchwork.freedesktop.org/series/53005/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5200 -> Patchwork_10904 =
== Summary - SUCCESS ==
No regressions found.
External
On Sun, 25 Nov 2018, Chris Wilson wrote:
> Certain monitors, e.g. Dell, do not like it when we reboot with an
> active link, leaving them in a confused state where they refuse to
> renegotiate the link after the reboot. If we hook into the reboot
> notifier, we can switch off any active link befor
== Series Details ==
Series: drm/i915/ringbuffer: 2-step restart
URL : https://patchwork.freedesktop.org/series/53009/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5200 -> Patchwork_10905 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwor
On 02/11/2018 16:12, Chris Wilson wrote:
Include the total size of closed vma when reporting the per_ctx_stats of
debugfs/i915_gem_objects.
Whilst adjusting the context tracking, note that we can simply use our
list of contexts in i915->contexts rather than circumlocute via
dev->filelist and th
Quoting Chris Wilson (2018-11-26 14:28:21)
> We may be simply restarting too fast for the culmudgeonly gen3/gen4 as
> we still see missing interrupts following a reset. So let's try
> restarting a little slower, first wake up the ring empty and then tell
> it about the work it has to perform.
>
>
Quoting Joonas Lahtinen (2018-11-26 14:19:30)
> Quoting Chris Wilson (2018-11-26 14:28:21)
> > We may be simply restarting too fast for the culmudgeonly gen3/gen4 as
> > we still see missing interrupts following a reset. So let's try
> > restarting a little slower, first wake up the ring empty and
On Wed, 17 Oct 2018 00:46:47 +0200, Daniele Ceraolo Spurio
wrote:
/snip/
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 8382d591c784..1a853cc627e3 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.
== Series Details ==
Series: drm/i915: Skip engine serialisation for no-op seqno reset
URL : https://patchwork.freedesktop.org/series/53005/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5200_full -> Patchwork_10904_full =
== Summary - FAILURE ==
Serious unknown changes
== Series Details ==
Series: drm/i915/ringbuffer: 2-step restart
URL : https://patchwork.freedesktop.org/series/53009/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5200_full -> Patchwork_10905_full =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_10
On Thu, Nov 22, 2018 at 08:54:30AM +, Tvrtko Ursulin wrote:
>
>
> On 21/11/2018 22:19, Rodrigo Vivi wrote:
> > On Mon, Nov 19, 2018 at 02:20:55PM -0800, Lucas De Marchi wrote:
> > > On Thu, Nov 08, 2018 at 11:23:46AM +, Tvrtko Ursulin wrote:
> > > >
> > > > On 08/11/2018 00:57, Lucas De
On Fri, Nov 23, 2018 at 02:42:59PM +0200, Jani Nikula wrote:
> On Wed, 21 Nov 2018, Rodrigo Vivi wrote:
> > On Tue, Nov 06, 2018 at 01:51:19PM -0800, Lucas De Marchi wrote:
> >> Define GT_GEN() similarly to our GT_GEN_RANGE() and convert users of
> >> IS_GEN to pss the gen as parameter. This prepa
On Thu, Nov 15, 2018 at 07:50:03PM -0500, Lyude Paul wrote:
> Signed-off-by: Lyude Paul
> Reviewed-by: Daniel Vetter
> ---
> include/drm/drm_dp_mst_helper.h | 77 +
> 1 file changed, 77 insertions(+)
>
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/
Petri Latvala writes:
> On Wed, Nov 14, 2018 at 02:28:32PM -0800, Eric Anholt wrote:
>> These are basic non-rendering tests of the UABI.
>>
>> Signed-off-by: Eric Anholt
>> ---
>> lib/igt_v3d.c | 4 --
>> tests/Makefile.am | 2 +
>> tests/Makefile.sources| 6 +++
>>
Thanks Tejun,Eric and Christian for your replies.
We want GPUs resource management to work seamlessly with containers and
container orchestration. With the Intel / bpf based approach this is not
possible.
From your response we gather the following. GPU resources need to be
abstracted. We will
On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote:
> There has been a TODO waiting for quite a long time in
> drm_dp_mst_topology.c:
>
> /* We cannot rely on port->vcpi.num_slots to update
>* topology_state->avail_slots as the port may not exist if the parent
>* bran
On Mon, Nov 26, 2018 at 10:04:21PM +0100, Daniel Vetter wrote:
> On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote:
> > There has been a TODO waiting for quite a long time in
> > drm_dp_mst_topology.c:
> >
> > /* We cannot rely on port->vcpi.num_slots to update
> > * topology_sta
On Mon, 2018-11-26 at 22:04 +0100, Daniel Vetter wrote:
> On Thu, Nov 15, 2018 at 07:50:05PM -0500, Lyude Paul wrote:
> > There has been a TODO waiting for quite a long time in
> > drm_dp_mst_topology.c:
> >
> > /* We cannot rely on port->vcpi.num_slots to update
> > * topology_state->ava
Sorry for the late reply, email got caught in a bad filter =/
I haven't been looking into it lately but we are still interested in
getting this fixed so I can start looking into this again.
In your last email you mentioned a sysfs hotplug could be the way to
go?
Thanks
Juston
On Thu, 2018-11-08
On Mon, 2018-11-26 at 21:53 +, Li, Juston wrote:
> Sorry for the late reply, email got caught in a bad filter =/
>
> I haven't been looking into it lately but we are still interested in
> getting this fixed so I can start looking into this again.
>
> In your last email you mentioned a sysfs h
On Wed, Nov 14, 2018 at 11:07:27PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> skl+ can go belly up if there are overlapping ddb allocations between
> planes. If we could absolutely guarantee that we can perform the atomic
> update within a single frame we shouldn't have to worry about
On Wed, Nov 14, 2018 at 11:07:28PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> A variable whose name is 'plane_id' is expected to be of the
> enum plane_id type. In this case we have a raw int, which turns
> out to refer to the plane of the framebuffer. Rename the variable
> to 'color_p
On Wed, Nov 14, 2018 at 11:07:29PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On icl+ the plane state that gets passed to update_slave() is not
> the plane state of the plane we're programming. With NV12 the
> plane state would be coming from the master (UV) plane whereas
> the plane w
This helps separate what capabilities are display capabilities.
Cc: Jani Nikula
Cc: Lucas De Marchi
Suggested-by: Jani Nikula
Suggested-by: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 22 ++---
drivers/gpu/drm/i915/i915_pci.c
Right now it is decided if GEN has display by checking the num_pipes,
so lets make it explicit and use a macro.
Cc: Jani Nikula
Reviewed-by: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Add HAS_DISPLAY() and use it
URL : https://patchwork.freedesktop.org/series/53042/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b5fb5ced1ab0 drm/i915: Add HAS_DISPLAY() and use it
65436500af52 drm/i915: Move
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Add HAS_DISPLAY() and use it
URL : https://patchwork.freedesktop.org/series/53042/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add HAS_DISPLAY() and use it
-drivers/gpu/d
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Add HAS_DISPLAY() and use it
URL : https://patchwork.freedesktop.org/series/53042/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5207 -> Patchwork_10906 =
== Summary - SUCCESS ==
No regressions found.
Noralf Trønnes writes:
> +static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
> +{
> + struct drm_gem_object *obj = vma->vm_private_data;
> + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> +
> + drm_gem_shmem_put_pages(shmem);
> + drm_gem_vm_close(vma)
For PSR2 there is no register to tell HW to keep main link enabled
while PSR2 is active, so don't configure sink DPCD with a
misleading value.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 10 ++
1 file changed, 6 i
eDP spec states 2 different bits to enable sink to trigger a
interruption when there is a CRC mismatch.
DP_PSR_CRC_VERIFICATION is for PSR only and
DP_PSR_IRQ_HPD_WITH_CRC_ERRORS is for PSR2 only.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm
According to eDP spec, sink can required specific selective update
granularity that source must comply.
Here caching the value if required and checking source supports it.
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP() was being set with the number of
frames that it should wait to enter PSR, what is wrong.
Here it is setting this field with the highest value to avoid PSR2
exits frequently, as when HW exit deep sleep it needs to go to idle
state causing a PSR exit for then wait
Source is required to comply to sink SU granularity when
DP_PSR2_SU_GRANULARITY_REQUIRED is set in DP_PSR_CAPS,
so adding the register here.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
include/drm/drm_dp_helper.h | 3 +++
1 file changed, 3 insertions(+)
d
i915 yet don't support PSR in Apple panels, so lets keep it disabled
while we work on that.
Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on gen-9+ HW)
Cc: Rodrigo Vivi
Cc: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
drivers/gpu/drm/i9
For ICL the bit 12 of CHICKEN_TRANS is reserved so we should not
touch it and as by default VSC_DATA_SEL_SOFTWARE_CONTROL is already
unset in gen10 + GLK we can just drop it and fix for both gens.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm
Our frontbuffer tracking improved over the years + the WA #0884
helped us keep PSR2 enabled while triggering screen updates when
necessary so this FIXME is not valid anymore.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_psr.c | 3
The first 8 bits of PSR2_CTL have 2 fields to set frames count, the
first one is to set how many idle frames PSR2 HW needs to wait before
enter in deep sleep and the second one it is how many frames(it don't
need to be idle frames) PSR2 HW will wait before start the PSR
activation sequence.
The pre
== Series Details ==
Series: series starting with [1/9] drm/i915: Disable PSR in Apple panels
URL : https://patchwork.freedesktop.org/series/53043/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ccc567f41e7e drm/i915: Disable PSR in Apple panels
-:26: WARNING:LONG_LINE: line ove
== Series Details ==
Series: series starting with [1/9] drm/i915: Disable PSR in Apple panels
URL : https://patchwork.freedesktop.org/series/53043/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Disable PSR in Apple panels
Okay!
Commit: drm/
== Series Details ==
Series: series starting with [1/9] drm/i915: Disable PSR in Apple panels
URL : https://patchwork.freedesktop.org/series/53043/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5207 -> Patchwork_10907 =
== Summary - FAILURE ==
Serious unknown changes com
The preliminary support protection flag exists mainly to protect
users with brand new Hardware from having bad experience when
using Linux distribution images containing old kernel versions from
preliminary development times. Distro's ISO images don't get frequent
updates.
This tag was previously
== Series Details ==
Series: drm/i915: rename alpha_support to preliminary_support.
URL : https://patchwork.freedesktop.org/series/53046/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
587ae1ba13b1 drm/i915: rename alpha_support to preliminary_support.
-:96: CHECK:PARENTHESIS_AL
== Series Details ==
Series: drm/i915: rename alpha_support to preliminary_support.
URL : https://patchwork.freedesktop.org/series/53046/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: rename alpha_support to preliminary_support.
+
+Error in
== Series Details ==
Series: drm/i915: rename alpha_support to preliminary_support.
URL : https://patchwork.freedesktop.org/series/53046/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_5207 -> Patchwork_10908 =
== Summary - FAILURE ==
Serious unknown changes coming with P
OK, so I enabled CONFIG_DMA_API_DEBUG: and now I get:
[ 178.789451] [ cut here ]
[ 178.789558] DMA-API: exceeded 7 overlapping mappings of cacheline
0x1a161a80
[ 178.789578] WARNING: CPU: 7 PID: 1223 at kernel/dma/debug.c:523
add_dma_entry+0x1f6/0x200
[ 178.78
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Add HAS_DISPLAY() and use it
URL : https://patchwork.freedesktop.org/series/53042/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5207_full -> Patchwork_10906_full =
== Summary - WARNING ==
Minor unknown
== Series Details ==
Series: DMA-API: exceeded 7 overlapping mappings of cacheline
URL : https://patchwork.freedesktop.org/series/53048/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5207 -> Patchwork_10909 =
== Summary - SUCCESS ==
No regressions found.
External URL:
== Series Details ==
Series: DMA-API: exceeded 7 overlapping mappings of cacheline
URL : https://patchwork.freedesktop.org/series/53048/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_5207_full -> Patchwork_10909_full =
== Summary - WARNING ==
Minor unknown changes coming
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Patchwork
> Sent: tiistai 27. marraskuuta 2018 3.16
> To: Souza, Jose
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/9
On Thu, Nov 22, 2018 at 05:51:06PM +0100, Daniel Vetter wrote:
> This is a similar idea to the fs_reclaim fake lockdep lock. It's
> fairly easy to provoke a specific notifier to be run on a specific
> range: Just prep it, and then munmap() it.
>
> A bit harder, but still doable, is to provoke the
64 matches
Mail list logo
