== Series Details ==
Series: drm/i915/dsb: Pre allocate and late cleanup of cmd buffer
URL : https://patchwork.freedesktop.org/series/73036/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7871_full -> Patchwork_16437_full
Su
== Series Details ==
Series: drm/i915/selftests: Relax timeout for error-interrupt reset processing
URL : https://patchwork.freedesktop.org/series/73032/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7870_full -> Patchwork_16436_full
===
== Series Details ==
Series: drm/hdcp: optimizing the srm handling (rev4)
URL : https://patchwork.freedesktop.org/series/72312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7890 -> Patchwork_16493
Summary
---
**SUCC
As we are not using the sysfs infrastructure anymore, link to it is
removed. And global srm data and mutex to protect it are removed,
with required handling at revocation check function.
v2:
srm_data is dropped and few more comments are addressed.
v3:
ptr passing around is fixed with functiona
== Series Details ==
Series: drm/i915: Mark i915.reset as unsigned
URL : https://patchwork.freedesktop.org/series/73024/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7869_full -> Patchwork_16435_full
Summary
---
**S
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next linus/master v5.5 next-20200207]
[cannot apply to drm/drm-next]
[if
== Series Details ==
Series: drm/i915: align dumb buffer stride to page_sz of the region
URL : https://patchwork.freedesktop.org/series/73021/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7869_full -> Patchwork_16433_full
== Series Details ==
Series: drm/i915: Don't use uninitialized 'ret' (rev2)
URL : https://patchwork.freedesktop.org/series/73157/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7889 -> Patchwork_16490
Summary
---
**SU
== Series Details ==
Series: drm/i915/execlists: Always force a context reload when rewinding
RING_TAIL (rev3)
URL : https://patchwork.freedesktop.org/series/73175/
State : failure
== Summary ==
Applying: drm/i915/execlists: Always force a context reload when rewinding
RING_TAIL
Using index
== Series Details ==
Series: series starting with [1/2] drm/i915: Flush execution tasklets before
checking request status
URL : https://patchwork.freedesktop.org/series/73013/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7869_full -> Patchwork_16430_full
Each set of relocations track the content of their particular portion of
the batch, the presumed offset they use encode matches their own view.
It is legal for the object to be moved, and the execbuf will have to
relocation -- we can't just assert that the relocations were not
required as that is b
== Series Details ==
Series: drm/i915: Disable use of hwsp_cacheline for kernel_context (rev2)
URL : https://patchwork.freedesktop.org/series/72992/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7869_full -> Patchwork_16429_full
On Fri, Jan 31, 2020 at 03:17:05PM -0800, Anusha Srivatsa wrote:
> Disable Early Read and Src Swap (bit 14) by setting the chicken
> register.
>
> BSpec: 46045,52890
>
> v2: Follow the Bspec implementation for the WA.
> v3: Have 2 separate defines for bit 14 and 15.
> - Rename register definition
== Series Details ==
Series: drm/i915/execlists: Always force a context reload when rewinding
RING_TAIL
URL : https://patchwork.freedesktop.org/series/73175/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7887 -> Patchwork_16489
If we rewind the RING_TAIL on a context, due to a preemption event, we
must force the context restore for the RING_TAIL update to be properly
handled. Rather than note which preemption events may cause us to rewind
the tail, compare the new request's tail with the previously submitted
RING_TAIL, as
== Series Details ==
Series: drm/i915/execlists: Always force a context reload when rewinding
RING_TAIL
URL : https://patchwork.freedesktop.org/series/73175/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6e0bc47b73d9 drm/i915/execlists: Always force a context reload when rewin
== Series Details ==
Series: drm/i915/gt: Only ignore already reset requests
URL : https://patchwork.freedesktop.org/series/73162/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7887 -> Patchwork_16488
Summary
---
**S
If we rewind the RING_TAIL on a context, due to a preemption event, we
must force the context restore for the RING_TAIL update to be properly
handled. Rather than note which preemption events may cause us to rewind
the tail, compare the new request's tail with the previously submitted
RING_TAIL, as
If we rewind the RING_TAIL on a context, due to a preemption event, we
must force the context restore for the RING_TAIL update to be properly
handled. Rather than note which preemption events may cause us to rewind
the tail, compare the new request's tail with the previously submitted
RING_TAIL, as
On 02/05, Jerry (Fangzhi) Zuo wrote:
> Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
> real CRC value of the last edid data block, and write it back.
> Current edid CRC calculates routine adds the last CRC byte,
> and check if non-zero.
>
> This behavior is not accurate; actuall
== Series Details ==
Series: Per client engine busyness (rev4)
URL : https://patchwork.freedesktop.org/series/70977/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7887 -> Patchwork_16487
Summary
---
**SUCCESS**
No
== Series Details ==
Series: Per client engine busyness (rev4)
URL : https://patchwork.freedesktop.org/series/70977/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Expose list of clients in sysfs
Okay!
Commit: drm/i915: Update client name on
== Series Details ==
Series: series starting with [1/2] drm/i915: Disable tesselation clock gating
on tgl A0
URL : https://patchwork.freedesktop.org/series/73160/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7887 -> Patchwork_16486
===
== Series Details ==
Series: Per client engine busyness (rev4)
URL : https://patchwork.freedesktop.org/series/70977/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f50257412ea0 drm/i915: Expose list of clients in sysfs
-:65: WARNING:FILE_PATH_CHANGES: added, moved or deleted fil
== Series Details ==
Series: drm/i915: Don't use uninitialized 'ret'
URL : https://patchwork.freedesktop.org/series/73157/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7887 -> Patchwork_16485
Summary
---
**FAILURE**
== Series Details ==
Series: drm/mm: Break long searches in fragmented address spaces
URL : https://patchwork.freedesktop.org/series/73154/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7887 -> Patchwork_16484
Summary
-
== Series Details ==
Series: drm/i915: HDCP support on above PORT_E
URL : https://patchwork.freedesktop.org/series/73153/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7887 -> Patchwork_16483
Summary
---
**SUCCESS**
== Series Details ==
Series: drm: Try to fix encoder possible_clones/crtc (rev2)
URL : https://patchwork.freedesktop.org/series/63399/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7886 -> Patchwork_16482
Summary
---
Chris Wilson writes:
> If a request is being re-run after an innocent reset, it is marked as
> -EAGAIN. So only skip an engine reset if the request is marked as -EIO.
>
> Testcase: igt/gem_ctx_exec/basic-nohangcheck
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu
On 07/02/2020 17:02, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-07 16:49:17)
On 07/02/2020 16:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-07 16:13:30)
static inline void
-__intel_context_stats_start(struct intel_context *ce, ktime_t now)
+__intel_context_stats_start(
Quoting Tvrtko Ursulin (2020-02-07 16:49:17)
>
> On 07/02/2020 16:33, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-02-07 16:13:30)
> >> static inline void
> >> -__intel_context_stats_start(struct intel_context *ce, ktime_t now)
> >> +__intel_context_stats_start(struct intel_context *ce,
That's my build many times test boot result.
https://github.com/youling257/android-4.9/commits/drm-intel
the "drm/i915/gt: Track engine round-trip times" is bad commit for my
Androidx86.
2020-02-08 0:34 GMT+08:00, Chris Wilson :
> Quoting youling257 (2020-02-07 16:31:25)
>> This patch cause GPU ha
2020-02-08 0:34 GMT+08:00, Chris Wilson :
> Quoting youling257 (2020-02-07 16:31:25)
>> This patch cause GPU hang on my Bay trail z3735f.
>> https://gitlab.freedesktop.org/drm/intel/issues/1144
>
> No it didn't. The cause for that is unfortunately well known.
> -Chris
>
“drm/i915/gt: Track engine r
This patch cause GPU hang on my Bay trail z3735f.
https://gitlab.freedesktop.org/drm/intel/issues/1144
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Tvrtko Ursulin (2020-02-07 16:46:55)
>
> If you want quick&dirty feedback read below, if you want something
> smarter wait some more. :)
>
> On 07/02/2020 11:11, Chris Wilson wrote:
> > +static void kill_stale_engines(struct i915_gem_context *ctx)
> > +{
> > + struct i915_gem_engines
== Series Details ==
Series: drm/i915: Fix force-probe failure message
URL : https://patchwork.freedesktop.org/series/73149/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7886 -> Patchwork_16481
Summary
---
**SUCCESS
On 07/02/2020 16:33, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-07 16:13:30)
static inline void
-__intel_context_stats_start(struct intel_context *ce, ktime_t now)
+__intel_context_stats_start(struct intel_context *ce,
+ struct intel_engine_cs *engine,
+
On Fri, Feb 07, 2020 at 05:39:26PM +0100, Daniel Vetter wrote:
> On Fri, Feb 07, 2020 at 03:59:50PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > WARN if the encoder possible_crtcs is effectively empty or contains
> > bits for non-existing crtcs.
> >
> > TODO: Or should we perhapst
If you want quick&dirty feedback read below, if you want something
smarter wait some more. :)
On 07/02/2020 11:11, Chris Wilson wrote:
If we have a set of active engines marked as being non-persistent, we
lose track of those if the user replaces those engines with
I915_CONTEXT_PARAM_ENGINES.
On Fri, Feb 07, 2020 at 06:34:47PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 07, 2020 at 05:27:51PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 07, 2020 at 04:50:01PM +0200, Ville Syrjälä wrote:
> > > On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote:
> > > > Hi
> > > >
> > > > Am
On Fri, Feb 07, 2020 at 03:59:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> WARN if the encoder possible_crtcs is effectively empty or contains
> bits for non-existing crtcs.
>
> TODO: Or should we perhapst just filter out any bit for a
> non-exisiting crtc?
>
> Cc: Thomas Zimmerma
On Fri, Feb 07, 2020 at 03:59:45PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The docs say possible_clones should always include the encoder itself.
> Since most drivers don't want to deal with the complexities of cloning
> let's allow them to set possible_clones=0 and instead we'll fi
Quoting youling257 (2020-02-07 16:31:25)
> This patch cause GPU hang on my Bay trail z3735f.
> https://gitlab.freedesktop.org/drm/intel/issues/1144
No it didn't. The cause for that is unfortunately well known.
-Chris
___
Intel-gfx mailing list
Intel-gfx@
On Fri, Feb 07, 2020 at 05:27:51PM +0100, Daniel Vetter wrote:
> On Fri, Feb 07, 2020 at 04:50:01PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> > > > From: Ville Syrjälä
> > >
Quoting Tvrtko Ursulin (2020-02-07 16:13:30)
> static inline void
> -__intel_context_stats_start(struct intel_context *ce, ktime_t now)
> +__intel_context_stats_start(struct intel_context *ce,
> + struct intel_engine_cs *engine,
> + ktime_t now)
== Series Details ==
Series: drm/i915/guc: Make sure to sanitize CT status
URL : https://patchwork.freedesktop.org/series/73146/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7886 -> Patchwork_16480
Summary
---
**SUC
On Fri, Feb 07, 2020 at 03:20:44PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > It's not at all clear what cloning options this driver supports.
> > So let's just clear possible_clones instead of setting it to some
> > bogus
On Fri, Feb 07, 2020 at 03:59:46PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
> i915 at least doesn't do those. Truthfully there could be some very
> specific circumstances where some of them would do doable, but
> genereal
On Fri, Feb 07, 2020 at 04:50:01PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> > > From: Ville Syrjälä
> > >
> > > The docs say possible_clones should always include the encoder itse
If a request is being re-run after an innocent reset, it is marked as
-EAGAIN. So only skip an engine reset if the request is marked as -EIO.
Testcase: igt/gem_ctx_exec/basic-nohangcheck
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/i
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For in
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 23 +
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing o
From: Tvrtko Ursulin
Some customers want to know how much of the GPU time are their clients
using in order to make dynamic load balancing decisions.
With the hooks already in place which track the overall engine busyness,
we can extend that slightly to split that time between contexts.
v2: Fix
From: Tvrtko Ursulin
Another re-spin of the per-client engine busyness series. Highlights from this
version:
* Refactor of the i915_drm_client concept based on feedback from Chris.
* Tracking contexts belonging to a client had a flaw where reaped contexts
would stop contributing to the busy
From: Tvrtko Ursulin
Add per client, per engine class tracking of on GPU runtime on top of the
previously added per context tracking.
This data will then be exported via sysfs in a following patch in order to
implement per DRM client view of GPU utilization.
To implement this we add a stats str
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
To enable lockless access to client name and pid data from the following
pat
On Fri, Feb 07, 2020 at 05:10:40PM +0100, Daniel Vetter wrote:
> On Wed, Jan 29, 2020 at 07:54:52PM +, Chris Wilson wrote:
> > On Braswell and Broxton (also known as Valleyview and Apollolake), we
> > need to serialise updates of the GGTT using the big stop_machine()
> > hammer. This has the si
On Wed, Jan 29, 2020 at 07:54:52PM +, Chris Wilson wrote:
> On Braswell and Broxton (also known as Valleyview and Apollolake), we
> need to serialise updates of the GGTT using the big stop_machine()
> hammer. This has the side effect of appearing to lockdep as a possible
> reclaim (since it use
Quoting Mika Kuoppala (2020-02-07 15:51:37)
> Disable TEDOP clock gating flow by programming 0x20A0[19] = 1
>
> References: HSDES#1407928979
> Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.free
Quoting Mika Kuoppala (2020-02-07 15:51:38)
> SIMD16 with Src0 scalar might conflict between Src1/Src2 and cause
> GRF read issue. Workaround this issue by setting bit 14 in 0xe4f4
> which will disable early read/src swap of Src0.
>
> Signed-off-by: Mika Kuoppala
Found!
Reviewed-by: Chris Wilson
== Series Details ==
Series: drm/i915/gt: Use the kernel_context to measure the breadcrumb size
URL : https://patchwork.freedesktop.org/series/73143/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7886 -> Patchwork_16479
Sum
SIMD16 with Src0 scalar might conflict between Src1/Src2 and cause
GRF read issue. Workaround this issue by setting bit 14 in 0xe4f4
which will disable early read/src swap of Src0.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
drivers/gpu/drm/i915/i915_reg
Disable TEDOP clock gating flow by programming 0x20A0[19] = 1
References: HSDES#1407928979
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i91
== Series Details ==
Series: series starting with [1/3] drm/i915/gem: Don't leak non-persistent
requests on changing engines
URL : https://patchwork.freedesktop.org/series/73134/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7886 -> Patchwork_16478
===
Quoting Ville Syrjala (2020-02-07 15:22:28)
> From: Ville Syrjälä
>
> Accidentally removed the 'ret=0' initialization, and thus
> we're potentially looking at some stack garbage here.
>
> The whole 'ret = do_stuff; if (!ret) do_other_stuff;' pattern
> confuses my brain so let's replace it with t
From: Ville Syrjälä
Accidentally removed the 'ret=0' initialization, and thus
we're potentially looking at some stack garbage here.
The whole 'ret = do_stuff; if (!ret) do_other_stuff;' pattern
confuses my brain so let's replace it with the standard
immediate return thing.
Reported-by: Chris Wi
We try hard to select a suitable hole in the drm_mm first time. But if
that is unsuccessful, we then have to look at neighbouring nodes, and
this requires traversing the rbtree. Walking the rbtree can be slow
(much slower than a linear list for deep trees), and if the drm_mm has
been purposefully f
== Series Details ==
Series: series starting with [1/3] drm/i915/gem: Don't leak non-persistent
requests on changing engines
URL : https://patchwork.freedesktop.org/series/73134/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9e3619244308 drm/i915/gem: Don't leak non-persistent
As Gen12 onwards there are HDCP instances for each transcoder
instead of port, remove the (port < PORT_E) hdcp support
limitation for platform >= Gen12.
v2:
- Nuke the comment and cosmetic changes. [Jani]
Cc: Jani Nikula
Cc: Ramalingam C
Reviewed-by: Ramalingam C
Signed-off-by: Anshuman Gupta
On Fri, Feb 07, 2020 at 03:28:35PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> > From: Ville Syrjälä
> >
> > The docs say possible_clones should always include the encoder itself.
> > Since most drivers don't want to deal with the complexities of clonin
On Fri, 07 Feb 2020, Chris Wilson wrote:
> Do not try and deference the i915 private before it has been allocated
> and attached to the drvdata!
>
> Fixes: 7daac72e9a3f ("drm/i915/pci: conversion to drm_device based logging
> macros.")
> Signed-off-by: Chris Wilson
> Cc: Wambui Karuga
> Cc: Jan
Hi
Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> The docs say possible_clones should always include the encoder itself.
> Since most drivers don't want to deal with the complexities of cloning
> let's allow them to set possible_clones=0 and instead we'll fix that
> up in
Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> Many drivers are populating encoder->possible_clones wrong. Let's
> persuade them to get it right by adding some loud WARNs.
>
> We'll cross check the bits between any two encoders. So either
> both encoders can clone with t
Hi
Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> It's not at all clear what cloning options this driver supports.
> So let's just clear possible_clones instead of setting it to some
> bogus value.
>
> Cc: Philipp Zabel
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gp
Am 07.02.20 um 14:59 schrieb Ville Syrjala:
> From: Ville Syrjälä
>
> Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Signed-off-by: Ville Syrjälä
Acked-by: Thomas Zimmermann
> ---
>
On 2020-01-28 at 19:24:25 +0530, Anshuman Gupta wrote:
> Few CI panel claims to support HDCP 2.2 but at CI
> HDCP IGT test execution these panels are not detecting
> as HDCP 2.2 supported panels. Adding HDCP 2.2 version
> print will be useful in such cases.
>
> CC: Ramalingam C
> Signed-off-by: A
On 2020-01-28 at 19:24:24 +0530, Anshuman Gupta wrote:
> If HDCP shim is not initialized, i915_display_info
> connector info returns EINVAL without providing any debug
> information. Adding a print for that will be useful for debugging.
>
> CC: Ramalingam C
> Signed-off-by: Anshuman Gupta
> ---
== Series Details ==
Series: drm/i915: Check require bandwidth did not exceed LSPCON limitation
(rev6)
URL : https://patchwork.freedesktop.org/series/72157/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7867_full -> Patchwork_16426_full
===
On 2020-01-29 at 18:56:19 +0530, Anshuman Gupta wrote:
> As Gen12 onwards there are HDCP instances for each transcoder
> instead of port, remove the (port < PORT_E) hdcp support
> limitation for platform >= Gen12.
>
> v2:
> - Nuke the comment and cosmetic changes. [Jani]
>
> Cc: Jani Nikula
> C
From: Ville Syrjälä
WARN if the encoder possible_crtcs is effectively empty or contains
bits for non-existing crtcs.
TODO: Or should we perhapst just filter out any bit for a
non-exisiting crtc?
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_enc
From: Ville Syrjälä
It's not at all clear what cloning options this driver supports.
So let's just clear possible_clones instead of setting it to some
bogus value.
Cc: Philipp Zabel
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
1 file changed, 1 insertion(+), 1 d
From: Ville Syrjälä
I doubt the DP+DP and SDVO+SDVO cloning works for this driver.
i915 at least doesn't do those. Truthfully there could be some very
specific circumstances where some of them would do doable, but
genereally it's too much pain to deal with so we've chose not to
bother. Let's use
From: Ville Syrjälä
Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
From: Ville Syrjälä
Remainder of my possible_clones/crtcs cleanup. All the i915 bits and a
few other driver bits got merged already.
Ville Syrjälä (6):
drm: Include the encoder itself in possible_clones
drm/gma500: Sanitize possible_clones
drm/exynos: Use drm_encoder_mask()
drm/imx: Remo
From: Ville Syrjälä
The docs say possible_clones should always include the encoder itself.
Since most drivers don't want to deal with the complexities of cloning
let's allow them to set possible_clones=0 and instead we'll fix that
up in the core.
We can't put this special case into drm_encoder_i
From: Ville Syrjälä
Many drivers are populating encoder->possible_clones wrong. Let's
persuade them to get it right by adding some loud WARNs.
We'll cross check the bits between any two encoders. So either
both encoders can clone with the other, or neither can.
We'll also complain about effecti
Do not try and deference the i915 private before it has been allocated
and attached to the drvdata!
Fixes: 7daac72e9a3f ("drm/i915/pci: conversion to drm_device based logging
macros.")
Signed-off-by: Chris Wilson
Cc: Wambui Karuga
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1
On 07.02.2020 14:38, Thomas Gleixner wrote:
> Alexey Budankov writes:
>> On 22.01.2020 17:25, Alexey Budankov wrote:
>>> On 22.01.2020 17:07, Stephen Smalley wrote:
> It keeps the implementation simple and readable. The implementation is
> more
> performant in the sense of calling th
Hi,
On patches 2 to 5:
Acked-by: Thomas Zimmermann
I'm not overly knowledgeable on DRM locking semantics, but the patches
appear to be correct in general.
Best regards
Thomas
Am 04.02.20 um 16:01 schrieb Daniel Vetter:
> CI didn't like my test-with tag :-/
>
> Test-with: 20200128112549.1721
== Series Details ==
Series: drm/i915/gt: Protect execlists_hold/unhold from new waiters
URL : https://patchwork.freedesktop.org/series/73133/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7885 -> Patchwork_16477
Summary
--
From: Michal Wajdeczko
We are sanitizing firmware status and old mmio message, but
we forget to sanitize CT status.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
drivers/gpu/drm/i915
Chris Wilson writes:
> We set up a dummy ring in order to measure the size we require for our
> breadcrumb emission, so that we don't have to manually count dwords! We
> can pass in the kernel_context to use for this so that if required it is
> known for the breadcrumb emitter, and we can reuse s
On Fri, Feb 07, 2020 at 12:55:41AM +, Souza, Jose wrote:
> On Thu, 2020-02-06 at 15:46 +0200, Ville Syrjälä wrote:
> > On Wed, Feb 05, 2020 at 06:08:49PM -0800, José Roberto de Souza
> > wrote:
> > > dGFX have local memory so it do not have aperture and do not
> > > support
> > > CPU fences but
We set up a dummy ring in order to measure the size we require for our
breadcrumb emission, so that we don't have to manually count dwords! We
can pass in the kernel_context to use for this so that if required it is
known for the breadcrumb emitter, and we can reuse some details from the
kernel_con
Alexey Budankov writes:
> On 22.01.2020 17:25, Alexey Budankov wrote:
>> On 22.01.2020 17:07, Stephen Smalley wrote:
It keeps the implementation simple and readable. The implementation is more
performant in the sense of calling the API - one capable() call for
CAP_PERFMON
priv
On 06/02/2020 20:49, Chris Wilson wrote:
Virtual engines are fleeting. They carry a reference count and may be freed
when their last request is retired. This makes them unsuitable for the
task of housing engine->retire.work so assert that it is not used.
Tvrtko tracked down an instance where w
We can not require that the system process a tasklet in reasonable time
(thanks be to ksoftirqd), but we can insist that having waited
sufficiently for the error interrupt to have been raised and having
kicked the tasklet, the reset has begun and the request will be marked
as in error (if not alrea
If we have a set of active engines marked as being non-persistent, we
lose track of those if the user replaces those engines with
I915_CONTEXT_PARAM_ENGINES. As part of our uABI contract is that
non-persistent requests are terminated if they are no longer being
tracked by the user's context (in ord
Currently on execlists, we use a local hwsp for the kernel_context,
rather than the engine's HWSP, as this is the default for execlists.
However, seqno rollover requires allocating a new HWSP cachline, and may
require pinning a new HWSP page in the GTT. This operation requiring
pinning in the GGTT
1 - 100 of 120 matches
Mail list logo
