== Series Details ==
Series: HDCP 2.2 DP MST Support (rev2)
URL : https://patchwork.freedesktop.org/series/81538/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9137 -> Patchwork_18696
Summary
---
**SUCCESS**
No re
== Series Details ==
Series: HDCP 2.2 DP MST Support (rev2)
URL : https://patchwork.freedesktop.org/series/81538/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+./drivers/gpu/drm/amd/amdgpu/../
== Series Details ==
Series: HDCP 2.2 DP MST Support (rev2)
URL : https://patchwork.freedesktop.org/series/81538/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
51e1dc4c0c75 drm/i915/hdcp: Update CP property in update_pipe
46a92a431c4f drm/i915/hotplug: Handle CP_IRQ for DP-MST
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used
Add HDCP 2.2 DP MST HDCP2_STREAM_STATUS
and HDCP2_AUTH_STREAM register in i915_reg header.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/dri
When crtc state need_modeset is true it is not necessary
it is going to be a real modeset, it can turns to be a
update_pipe instead of modeset.
This turns content protection property to be DESIRED and hdcp
update_pipe left with property to be in DESIRED state but
actually hdcp->value was ENABLED.
T
Handle CP_IRQ in DEVICE_SERVICE_IRQ_VECTOR_ESI0
It requires to call intel_hdcp_handle_cp_irq() in case
of CP_IRQ is triggered by a sink in DP-MST topology.
Cc: "Ville Syrjälä"
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 +-
1 file
Enable HDCP 2.2 over DP MST.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 46 ++-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_
This requires for HDCP 2.2 MST check link.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
drivers/gpu/drm/i915/d
Add support for HDCP 2.2 DP MST shim callback.
This adds existing DP HDCP shim callback for Link Authentication
and Encryption and HDCP 2.2 stream encryption
callback.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types.h| 4 +
drivers/gpu/drm/i915/d
Add support for multiple mst stream in hdcp port data
which will be used by RepeaterAuthStreamManage msg and
HDCP 2.2 security f/w for m' validation.
security f/w enforce a policy to do RepeaterAuthStreamManage
management only once with established HDCP session with
all available streams in DP MST
This series has been tested with IGT changes to do
a single commit to enable HDCP on all DP-MST connector.
HDCP 2.2 support over DP MST actually starts
from patch [PATCH 07/13] Pass dig_port to intel_hdcp_init
Other patches of this series has already floated for
Gen12 HDCP 1.4 DP MST support
(http
Pass dig_port as an argument to intel_hdcp_init()
and intel_hdcp2_init().
This will be required for HDCP 2.2 stream encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_hdcp.c| 12 +++---
hdcp_port_data is specific to a port on which HDCP
encryption is getting enabled, so encapsulate it to
intel_digital_port.
This will be required to enable HDCP 2.2 stream encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_types.h| 5 +-
driver
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving th
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and
Enable HDCP 1.4 over DP MST for Gen12.
This also enable the stream encryption support for
older generations, which was missing earlier.
v2:
- Added debug print for stream encryption.
- Disable the hdcp on port after disabling last stream
encryption.
Cc: Ramalingam C
Signed-off-by: Anshuman Gup
== Series Details ==
Series: drm/i915: Make the GEM reclaim workqueue high priority
URL : https://patchwork.freedesktop.org/series/82616/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9135_full -> Patchwork_18685_full
Summa
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/82647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9137 -> Patchwork_18695
Summary
---
**SUCCESS**
No r
On Mon, 2020-10-12 at 17:18 +0300, Gwan-gyeong Mun wrote:
> As per b.spec 49274, the IO buffer Wake lines and Fast Wake lines can be
> calculated based on the following formula.
>
> IO buffer wake lines = ROUNDUP(50us / total line time in us)
> Fast wake lines = ROUNDUP(32us / total line time in
On Fri, 9 Oct 2020, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
Acked-by: Nicolas Pitre
> fs
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/82647/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_r
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/82647/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bd08bb57be3c drm/i915/guc: Update to use firmware v49.0.1
-:231: WARNING:LONG_LINE: line length of 103 exceeds 100 co
== Series Details ==
Series: series starting with [1/6] drm/i915/display/psr: Calculate selective
fetch plane registers
URL : https://patchwork.freedesktop.org/series/82646/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9137 -> Patchwork_18694
== Series Details ==
Series: drm/i915/gem: Poison stolen pages before use (rev2)
URL : https://patchwork.freedesktop.org/series/82463/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9135_full -> Patchwork_18684_full
Summary
i915_gem_free_object() is called by multiple threads/processes, they all add
objects onto the same free_list. The free_list processing worker thread becomes
bottle-neck. I see that the worker is mostly a single thread (with particular
thread ID), but sometimes multiple threads are launched to pr
== Series Details ==
Series: series starting with [1/6] drm/i915/display/psr: Calculate selective
fetch plane registers
URL : https://patchwork.freedesktop.org/series/82646/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won
== Series Details ==
Series: series starting with [1/6] drm/i915/display/psr: Calculate selective
fetch plane registers
URL : https://patchwork.freedesktop.org/series/82646/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2b304de51d75 drm/i915/display/psr: Calculate selective fe
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the instance in bits [3..6].
NOTE: this patch breaks pointer dere
From: John Harrison
Clear out some pointers when objects have been de-allocated. This
makes it much easier to track down use-after-free type issues.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 1 +
2 files chan
From: John Harrison
Update to the latest GuC firmware
v2: Rebase to newer tree, updated a commit message (review feedback
from Daniele) and dropped the patch to enable GuC/HuC loading by
default as apparently this is not allowed.
Signed-off-by: John Harrison
John Harrison (3):
drm/i915/guc
From: John Harrison
Rather than just saying 'GuC failed to load: -110', actually print out
the GuC status register and break it down into the individual fields.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 31 ---
1 file changed, 22 insertion
Do the calculation of x and y offsets using
skl_calc_main_surface_offset().
RFC/WIP: This causes the value of the calculated x to be different than
plane_state->color_plane[color_plane].x, not sure if that is expected.
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
Just for feature development, not needed in production.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display
Add the calculations to set plane selective fetch registers depending
in the value of the area damaged.
It is still using the whole plane area as damaged but that will change
in next patches.
BSpec: 55229
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
.../drm/i9
The calculation the offsets of the main surface will be needed by PSR2
selective fetch code so here splitting and exporting it.
No functional changes were done here.
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 95
Planes can individually have transparent, move or have visibility
changed if any of those happens, planes bellow it will be visible or
have more pixels of it visible than before.
This patch is taking care of this case for selective fetch by adding
to each plane damaged area all the intersections o
Now using plane damage clips property to calcualte the damaged area.
Selective fetch only supports one region to be fetched so software
needs to calculate a bounding box around all damage clips.
Cc: Ville Syrjälä
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915
On Wed, Oct 14, 2020 at 12:59:48AM +0530, Tejas Upadhyay wrote:
> Recently we came across requirement to identify EHL and JSL
> platform to program them differently. Thus Split the basic
> platform definition, macros, and PCI IDs to differentiate
> between EHL and JSL platforms. Also, IS_ELKHARTLAK
On Tue, Oct 13, 2020 at 12:25:44PM +0100, Christoph Hellwig wrote:
> > - kaddr = kmap(pp);
> > + kaddr = kmap_thread(pp);
> > memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE);
> > - kunmap(pp);
> > + kunmap_thread(pp);
>
> You only Cced me on this particular patch, which mean
On Tue, Oct 13, 2020 at 09:01:49PM +0100, Al Viro wrote:
> On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
>
> > static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> > int size)
> > {
> > char *vto = kmap_atomic(to);
> >
> > memcpy(vto, vfrom, size
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over
On Tue, Oct 13, 2020 at 08:36:43PM +0100, Matthew Wilcox wrote:
> static inline void copy_to_highpage(struct page *to, void *vfrom, unsigned
> int size)
> {
> char *vto = kmap_atomic(to);
>
> memcpy(vto, vfrom, size);
> kunmap_atomic(vto);
> }
>
> in linux/highmem.h ?
You mea
== Series Details ==
Series: drm/i915/jsl: Split EHL/JSL platform info and PCI ids (rev2)
URL : https://patchwork.freedesktop.org/series/82437/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9136 -> Patchwork_18693
Summary
-
== Series Details ==
Series: drm/i915/jsl: Split EHL/JSL platform info and PCI ids (rev2)
URL : https://patchwork.freedesktop.org/series/82437/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7c82a7cc787d drm/i915/jsl: Split EHL/JSL platform info and PCI ids
-:218: CHECK:UNNECESS
== Series Details ==
Series: series starting with [v10,01/11] HAX to make DSC work on the icelake
test system (rev2)
URL : https://patchwork.freedesktop.org/series/82483/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9136 -> Patchwork_18692
===
On Tue, Oct 13, 2020 at 12:37 PM Matthew Wilcox wrote:
>
> On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> > On Fri, Oct 9, 2020 at 12:52 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > The kmap() calls in this FS are localized to a single thread. To avoid
> > > the over head
Recently we came across requirement to identify EHL and JSL
platform to program them differently. Thus Split the basic
platform definition, macros, and PCI IDs to differentiate
between EHL and JSL platforms. Also, IS_ELKHARTLAKE is replaced
with IS_JSL_EHL everywhere.
Changes since V1 :
-
On Tue, Oct 13, 2020 at 11:44:29AM -0700, Dan Williams wrote:
> On Fri, Oct 9, 2020 at 12:52 PM wrote:
> >
> > From: Ira Weiny
> >
> > The kmap() calls in this FS are localized to a single thread. To avoid
> > the over head of global PKRS updates use the new kmap_thread() call.
> >
> > Cc: Nicol
== Series Details ==
Series: series starting with [v10,01/11] HAX to make DSC work on the icelake
test system (rev2)
URL : https://patchwork.freedesktop.org/series/82483/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't
== Series Details ==
Series: series starting with [v10,01/11] HAX to make DSC work on the icelake
test system (rev2)
URL : https://patchwork.freedesktop.org/series/82483/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
98c263260e2e HAX to make DSC work on the icelake test system
== Series Details ==
Series: series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on
eLLC machines to avoid rcu lockup during fbdev init (rev2)
URL : https://patchwork.freedesktop.org/series/82438/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9136 -> Patchwork_18
== Series Details ==
Series: series starting with [v3,1/3] drm/i915: Reorder hpd init vs. display
resume (rev4)
URL : https://patchwork.freedesktop.org/series/82417/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9136 -> Patchwork_18690
On Fri, Oct 9, 2020 at 12:52 PM wrote:
>
> From: Ira Weiny
>
> The kmap() calls in this FS are localized to a single thread. To avoid
> the over head of global PKRS updates use the new kmap_thread() call.
>
> Cc: Nicolas Pitre
> Signed-off-by: Ira Weiny
> ---
> fs/cramfs/inode.c | 10 +---
== Series Details ==
Series: series starting with [v3,1/3] drm/i915: Reorder hpd init vs. display
resume (rev4)
URL : https://patchwork.freedesktop.org/series/82417/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
706cef4f9041 drm/i915: Reorder hpd init vs. display resume
-:26:
From: Ville Syrjälä
Currently we call .hpd_irq_setup() directly just before display
resume, and follow it with another call via intel_hpd_init()
just afterwards. Assuming the hpd pins are marked as enabled
during the open-coded call these two things do exactly the
same thing (ie. enable HPD inter
While CI is unreliable in terms of detecting performance deltas, it
should still be able to detect when we are orders of magnitude off
expectations. In this case, latency/throughput when submitting to a load
balancer should be on par with a native engine.
Signed-off-by: Chris Wilson
---
tests/i9
> -Original Message-
> From: Chris Wilson
> Sent: Tuesday, October 13, 2020 9:25 AM
> To: Tang, CQ ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Make the GEM reclaim workqueue
> high priority
>
> Quoting Tang, CQ (2020-10-13 17:19:27)
> > Chris,
> >
Quoting Tang, CQ (2020-10-13 17:19:27)
> Chris,
> I tested this patch. It is still not enough, I keep catch running out of
> lmem. Every worker invocation takes larger and larger freeing object count.
>
Was that with the immediate call (not via call_rcu) to
__i915_gem_free_object_rcu?
If t
== Series Details ==
Series: drm/i915/gt: Confirm the context survives execution
URL : https://patchwork.freedesktop.org/series/82633/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9136 -> Patchwork_18689
Summary
---
Chris,
I tested this patch. It is still not enough, I keep catch running out of
lmem. Every worker invocation takes larger and larger freeing object count.
Here is my debugging code:
+static int obj_count = 0;
+
..
+ if (llist_add(&obj->freed, &i915->mm.free_list)) {
+
On Tue, Oct 13, 2020 at 04:47:49PM +0100, Chris Wilson wrote:
> See subject, s/ininitial/iniital/
>
> Quoting Ville Syrjala (2020-10-07 13:03:27)
> > From: Ville Syrjälä
> >
> > Currently we leave the cache_level of the initial fb obj
> > set to NONE. This means on eLLC machines the first pin_to
On Tue, Oct 13, 2020 at 04:51:00PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-10-07 13:03:28)
> > From: Ville Syrjälä
> >
> > Fix up the MOCS PTE setting to really get the LLC cacheability
> > from the PTE rather than hardocoding it to LLC or LLC+eLLC.
> >
> > Signed-off-by: Ville
Quoting Ville Syrjala (2020-10-07 13:03:28)
> From: Ville Syrjälä
>
> Fix up the MOCS PTE setting to really get the LLC cacheability
> from the PTE rather than hardocoding it to LLC or LLC+eLLC.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++--
> 1 file ch
See subject, s/ininitial/iniital/
Quoting Ville Syrjala (2020-10-07 13:03:27)
> From: Ville Syrjälä
>
> Currently we leave the cache_level of the initial fb obj
> set to NONE. This means on eLLC machines the first pin_to_display()
> will try to switch it to WT which requires a vma unbind+bind.
>
Repeat our sanitychecks from before execution to after execution. One
expects that if we were to see these, the gpu would already be on fire,
but the timing may be informative.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 10 +++---
1 file changed, 7 insertions(+), 3
Quoting Chris Wilson (2020-10-13 13:21:55)
> > +
> > + /*
> > + * batch_len seems like it can have different interaction depending
> > on
> > + * the engine and HW.
> > + */
> > + for_each_engine(e, fd) {
> > + execbuf.flags = eb_ring(e);
> > +
On Monday, October 12, 2020 8:41 PM, Pankaj Bharadiya
wrote:
> Now, Sameer has implemented Integer scaling in Kodi Retro gaming
> framework which demonstrate how Integer scaling gives distinctive
> look to pixel art games when played on higher resolution monitors.
>
> Kodi patches are reviewed a
Include the implicit eb.batch_len=0 into the mix of various offsets and
lengths.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
tests/i915/gen9_exec_parse.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/i915/gen9_exec_parse.c b/tests/i915/gen9_exec_parse.c
index 7ddb5bf2b..08
Quoting Matthew Auld (2020-10-13 15:07:46)
> On 13/10/2020 12:58, Chris Wilson wrote:
> > Quoting Matthew Auld (2020-10-13 12:18:39)
> >> As per the ABI batch_len is u32, however if the batch_len is left unset,
> >> then the kernel will just assume batch_len is the size of the whole
> >> batch obje
On 13/10/2020 12:58, Chris Wilson wrote:
Quoting Matthew Auld (2020-10-13 12:18:39)
As per the ABI batch_len is u32, however if the batch_len is left unset,
then the kernel will just assume batch_len is the size of the whole
batch object, however since the vma->size is u64, while the batch_len i
== Series Details ==
Series: drm/i915/execbuf: don't allow zero batch_len
URL : https://patchwork.freedesktop.org/series/82620/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9135 -> Patchwork_18687
Summary
---
**SUCC
== Series Details ==
Series: tests/gem_exec_params: test overly large batch
URL : https://patchwork.freedesktop.org/series/82626/
State : failure
== Summary ==
Applying: tests/gem_exec_params: test overly large batch
error: sha1 information is lacking or useless (tests/i915/gem_exec_params.c).
> - kaddr = kmap(pp);
> + kaddr = kmap_thread(pp);
> memcpy(kaddr, vip->vii_immed.vi_immed + offset, PAGE_SIZE);
> - kunmap(pp);
> + kunmap_thread(pp);
You only Cced me on this particular patch, which means I have absolutely
no idea what kmap_thread and kunmap_thread actually
Le lun. 12 oct. 2020 à 16:10, Daniel Vetter a écrit
:
On Mon, Oct 12, 2020 at 12:25:09PM +0200, Paul Cercueil wrote:
Fix a badly reverted commit. The revert commit was cherry-picked
from
drm-misc-next to drm-misc-next-fixes, and in the process some
unrelated
code was added.
Fixes: a3
Hi Stephen,
Le lun. 12 oct. 2020 à 15:24, Stephen Rothwell
a écrit :
Hi all,
On Thu, 8 Oct 2020 15:42:02 +1100 Stephen Rothwell
wrote:
On Thu, 8 Oct 2020 14:09:03 +1100 Stephen Rothwell
wrote:
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) fai
As reported by Sphinx:
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1147:
WARNING: Duplicate C declaration, also defined in 'gpu/i915'.
Declaration is 'i915_oa_wait_unlocked'.
./Documentation/gpu/i915:646: ./drivers/gpu/drm/i915/i915_perf.c:1169:
WARNI
On Mon, Oct 12, 2020 at 10:36:45PM +0300, Imre Deak wrote:
> On Wed, Oct 07, 2020 at 10:22:41PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently we call .hpd_irq_setup() directly just before display
> > resume, and follow it with another call via intel_hpd_init()
> > just aft
== Series Details ==
Series: drm/i915/gt: Cleanup kasan warning for on-stack (unsigned long) casting
URL : https://patchwork.freedesktop.org/series/82619/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9135 -> Patchwork_18686
== Series Details ==
Series: drm/i915/gt: Cleanup kasan warning for on-stack (unsigned long) casting
URL : https://patchwork.freedesktop.org/series/82619/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6ccdb007c7e9 drm/i915/gt: Cleanup kasan warning for on-stack (unsigned long)
On 13/10/2020 12:08, Chris Wilson wrote:
Kasan is gving a warning for passing a u32 parameter into find_first_bit
(casting to a unsigned long *, with appropriate length restrictions):
[ 44.678262] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x2e/0x50
[ 44.678295] Read of size 8 at ad
== Series Details ==
Series: drm/i915: Make the GEM reclaim workqueue high priority
URL : https://patchwork.freedesktop.org/series/82616/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9135 -> Patchwork_18685
Summary
---
Hi,
> -Original Message-
> From: Kai-Heng Feng
> Sent: tiistai 13. lokakuuta 2020 15.18
> To: Saarinen, Jani
> Cc: Ville Syrjälä ; intel-gfx g...@lists.freedesktop.org>; Runyan, Arthur J
> Subject: Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143"
> breaks HDMI on A
== Series Details ==
Series: HDCP over DP-MST misc (rev2)
URL : https://patchwork.freedesktop.org/series/82605/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9134_full -> Patchwork_18683_full
Summary
---
**SUCCESS**
Quoting Matthew Auld (2020-10-13 13:11:39)
> See if can make something explode with too large batch (1ULL << 32),
> while also making the batch_len implicit. We should also try each engine
> since batch_len seems to have different interactions related to that.
>
> Signed-off-by: Matthew Auld
> --
> On Oct 13, 2020, at 19:50, Saarinen, Jani wrote:
>
> Hi,
>> -Original Message-
>> From: Intel-gfx On Behalf Of Ville
>> Syrjälä
>> Sent: tiistai 13. lokakuuta 2020 14.16
>> To: Kai-Heng Feng
>> Cc: intel-gfx ; Runyan, Arthur J
>>
>> Subject: Re: [Intel-gfx] [Regression] "drm/i915:
See if can make something explode with too large batch (1ULL << 32),
while also making the batch_len implicit. We should also try each engine
since batch_len seems to have different interactions related to that.
Signed-off-by: Matthew Auld
---
tests/i915/gem_exec_params.c | 31 ++
On Monday, October 12, 2020 8:41 PM, Pankaj Bharadiya
wrote:
> +/**
> + * DOC: CRTC scaling filter property
> + *
> + * SCALING_FILTER:
> + *
> + * Indicates scaling filter to be used for CRTC scaler
> + *
> + * The value of this property can be one of the following:
> + * Default:
> + *
Quoting Chris Wilson (2020-10-13 12:58:31)
> Quoting Matthew Auld (2020-10-13 12:18:39)
> > As per the ABI batch_len is u32, however if the batch_len is left unset,
> > then the kernel will just assume batch_len is the size of the whole
> > batch object, however since the vma->size is u64, while th
> +/**
> + * DOC: Plane scaling filter property
> + *
> + * SCALING_FILTER:
> + *
> + * Indicates scaling filter to be used for plane scaler
> + *
> + * The value of this property can be one of the following:
> + * Default:
> + * Driver's default scaling filter
> + * Nearest Neigh
Quoting Matthew Auld (2020-10-13 12:18:39)
> As per the ABI batch_len is u32, however if the batch_len is left unset,
> then the kernel will just assume batch_len is the size of the whole
> batch object, however since the vma->size is u64, while the batch_len is
> just u32 we can end up with batch_
Hi,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjälä
> Sent: tiistai 13. lokakuuta 2020 14.16
> To: Kai-Heng Feng
> Cc: intel-gfx ; Runyan, Arthur J
>
> Subject: Re: [Intel-gfx] [Regression] "drm/i915: Implement display w/a #1143"
> breaks HDMI on ASUS GL552VW
>
> On
== Series Details ==
Series: drm/i915/gem: Poison stolen pages before use (rev2)
URL : https://patchwork.freedesktop.org/series/82463/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9135 -> Patchwork_18684
Summary
---
As per the ABI batch_len is u32, however if the batch_len is left unset,
then the kernel will just assume batch_len is the size of the whole
batch object, however since the vma->size is u64, while the batch_len is
just u32 we can end up with batch_len = 0 if we are given too large batch
object(e.g
On Tue, Oct 13, 2020 at 01:20:35PM +0800, Kai-Heng Feng wrote:
>
>
> > On Sep 3, 2020, at 14:26, Kai-Heng Feng wrote:
> >
> >
> >
> >> On Aug 26, 2020, at 21:05, Ville Syrjälä
> >> wrote:
> >>
> >> On Wed, Aug 26, 2020 at 12:40:15PM +0800, Kai-Heng Feng wrote:
> >>> Hi,
> >>>
> On Au
Kasan is gving a warning for passing a u32 parameter into find_first_bit
(casting to a unsigned long *, with appropriate length restrictions):
[ 44.678262] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x2e/0x50
[ 44.678295] Read of size 8 at addr 888233f4fc30 by task
core_hotunplug/4
== Series Details ==
Series: drm/i915/gem: Poison stolen pages before use (rev2)
URL : https://patchwork.freedesktop.org/series/82463/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
63280c845634 drm/i915/gem: Poison stolen pages before use
-:38: WARNING:MEMORY_BARRIER: memory ba
On Tue, 13 Oct 2020, "Lee, Shawn C" wrote:
> On Mon, Oct 12, 2020 at 5:09 PM, Jani Nikula wrote:
>>On Mon, 12 Oct 2020, "Lee, Shawn C" wrote:
>>> On Fri, Aug 28, 2020 at 06:19AM, Shankar Uma wrote:
> -Original Message-
> From: Jani Nikula
> Sent: Friday, August 28, 2020 11:50
Removal of igt_fork_hang_detector() from local_i915_healthcheck() by
commit 1fbd127bd4e1 ("core_hotplug: Teach the healthcheck how to check
execution status") resulted in unintentional removal of an important
though implicit test feature of detecting, reporting as failures and
recovering from poten
Quoting Lucas De Marchi (2020-10-12 17:55:03)
> On Fri, Jul 31, 2020 at 12:23:57AM -0700, Siddiqui, Ayaz A wrote:
> >
> >
> >> -Original Message-
> >> From: Siddiqui, Ayaz A
> >> Sent: Wednesday, July 29, 2020 3:56 PM
> >> To: intel-gfx@lists.freedesktop.org
> >> Cc: Siddiqui, Ayaz A ; Chr
1 - 100 of 114 matches
Mail list logo
