On 28/01/2020 01:05, Navare, Manasi D wrote:
> On Sat, Jan 25, 2020 at 01:31:06AM -0800, Saarinen, Jani wrote:
>> + Martin to re-report.
>
> Could you re-report this so we get the full CI IGT results?
Sorry, I had done the work but I re-reported the wrong run...
Anyway, I queued the re-reporting
== Series Details ==
Series: drm/i915/dp: Modeset only the tiled connectors with CRTC
URL : https://patchwork.freedesktop.org/series/72559/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7811 -> Patchwork_16267
Summary
-
== Series Details ==
Series: drm/i915/gt conversion to new drm logging macros.
URL : https://patchwork.freedesktop.org/series/72643/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16290
Summary
---
*
== Series Details ==
Series: Introduce CAP_PERFMON to secure system performance monitoring and
observability (rev2)
URL : https://patchwork.freedesktop.org/series/72273/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16289
Manual conversion of the printk based logging macros to the new struct
drm_based logging macros in drm/i915/gt/intel_ggtt.c.
Also includes extracting the struct drm_i915_private device from various
intel types to use in the new macros.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/gt/int
Convert various instances of the printk based drm logging macros to the
new struct drm_device based logging macros in i915/gt/intel_rps.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/gt/intel_rps.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/dri
This converts most instances of the printk based drm logging macros in
i915/gt/intel_resect.c to the new struct drm_based logging macros.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/gt/intel_reset.c | 48 +++
1 file changed, 26 insertions(+), 22 deletions(-)
di
Convert remaining instances of the printk based logging macros in
i915/gt/intel_gt to the struct drm_device based logging macros.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/gt/intel_gt.c | 43 +++---
1 file changed, 21 insertions(+), 22 deletions(-)
diff --git
Manually convert the remaining instance of the printk based drm logging
macros to the struct drm_device based logging macros in
i915/gt/intel_ring_submission.c
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Conversion of the remaining printk based drm logging macros to the new
struct drm_device based logging macros in i915/gt/intel_engine_cs.c.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/d
Converts most instances of the printk based drm logging macros in
i915/gt/intel_lrc.c to the new struct drm_device based logging macros.
In some instances, extracts the struct drm_i915_private device for use
in the logging macros.
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/i915/gt/intel_lr
This series continues the conversion to the new drm logging macros
focused on the drm/i915/gt folder. This was done both manually and using
coccinelle.
Wambui Karuga (8):
drm/i915/gt: conversion to struct drm_device macros when struct
drm_i915_private is available.
drm/i915/ggtt: use new d
This patch is the conversion of printk based logging macros to the new
struct drm_device based logging macros in the drm/i915/gt folder by
running the following coccinelle script that matches when the struct
drm_i915_private device is present:
@rule1@
identifier fn, T;
@@
fn(...,struct drm_i915_pr
== Series Details ==
Series: Introduce CAP_PERFMON to secure system performance monitoring and
observability (rev2)
URL : https://patchwork.freedesktop.org/series/72273/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
00180af79ca9 capabilities: introduce CAP_PERFMON to kernel an
Open access to monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without the
rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
credentials and makes operation more secure.
CAP_PERFMON implements the principal of least privile
Open access to monitoring for CAP_PERFMON privileged process. Providing
the access under CAP_PERFMON capability singly, without the rest of
CAP_SYS_ADMIN credentials, excludes chances to misuse the credentials and
makes operation more secure.
CAP_PERFMON implements the principal of least privile
Open access to monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without the
rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
credentials and makes operation more secure.
CAP_PERFMON implements the principal of least privile
Open access to monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without the
rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
credentials and makes operation more secure.
CAP_PERFMON implements the principal of least privile
Open access to bpf_trace monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without the
rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
credentials and makes operation more secure.
CAP_PERFMON implements the principal of lea
Open access to i915_perf monitoring for CAP_PERFMON privileged process.
Providing the access under CAP_PERFMON capability singly, without the
rest of CAP_SYS_ADMIN credentials, excludes chances to misuse the
credentials and makes operation more secure.
CAP_PERFMON implements the principal of lea
Extend error messages to mention CAP_PERFMON capability as an option
to substitute CAP_SYS_ADMIN capability for secure system performance
monitoring and observability operations. Make perf_event_paranoid_check()
and __cmd_ftrace() to be aware of CAP_PERFMON capability.
CAP_PERFMON implements the
Open access to monitoring via kprobes and uprobes and eBPF tracing for
CAP_PERFMON privileged process. Providing the access under CAP_PERFMON
capability singly, without the rest of CAP_SYS_ADMIN credentials, excludes
chances to misuse the credentials and makes operation more secure.
perf kprobes
Open access to monitoring of kernel code, cpus, tracepoints and namespaces
data for a CAP_PERFMON privileged process. Providing the access under
CAP_PERFMON capability singly, without the rest of CAP_SYS_ADMIN credentials,
excludes chances to misuse the credentials and makes operation more secure
Introduce CAP_PERFMON capability designed to secure system performance
monitoring and observability operations so that CAP_PERFMON would assist
CAP_SYS_ADMIN capability in its governing role for performance monitoring
and observability subsystems.
CAP_PERFMON hardens system security and integrit
Currently access to perf_events, i915_perf and other performance monitoring and
observability subsystems of the kernel is open only for a privileged process [1]
with CAP_SYS_ADMIN capability enabled in the process effective set [2].
This patch set introduces CAP_PERFMON capability designed to se
On 2020-01-27 at 16:10:32 -0500, Sean Paul wrote:
> On Mon, Jan 27, 2020 at 11:42:31PM +0530, Ramalingam C wrote:
> > 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 ch
== Series Details ==
Series: series starting with [1/6] drm/i915: Skip capturing errors from
internal contexts
URL : https://patchwork.freedesktop.org/series/72639/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/gener
== Series Details ==
Series: series starting with [1/6] drm/i915: Skip capturing errors from
internal contexts
URL : https://patchwork.freedesktop.org/series/72639/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16288
=
== Series Details ==
Series: series starting with [1/8] drm/i915/gt: Expose engine properties via
sysfs
URL : https://patchwork.freedesktop.org/series/72638/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16287
== Series Details ==
Series: series starting with [1/6] drm/i915: Skip capturing errors from
internal contexts
URL : https://patchwork.freedesktop.org/series/72639/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5176f847f2a0 drm/i915: Skip capturing errors from internal context
== Series Details ==
Series: series starting with [1/8] drm/i915/gt: Expose engine properties via
sysfs
URL : https://patchwork.freedesktop.org/series/72638/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/gt: Expose engine properties via sysf
== Series Details ==
Series: series starting with [1/8] drm/i915/gt: Expose engine properties via
sysfs
URL : https://patchwork.freedesktop.org/series/72638/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
988fe3ead6d1 drm/i915/gt: Expose engine properties via sysfs
-:91: WARNIN
== Series Details ==
Series: drm/i915: Check current i915_vma.pin_count status first on unbind (rev3)
URL : https://patchwork.freedesktop.org/series/72529/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16286
===
== Series Details ==
Series: drm/i915/tgl: Suppress DC5/DC6 around DSB usage (rev3)
URL : https://patchwork.freedesktop.org/series/72549/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16285
Summary
---
On Fri, Jan 24, 2020 at 4:11 PM Guenter Roeck wrote:
>
> On Fri, Dec 20, 2019 at 12:03:53PM -0800, Rajat Jain wrote:
> > Certain laptops now come with panels that have integrated privacy
> > screens on them. This patch adds support for such panels by adding
> > a privacy-screen property to the int
== Series Details ==
Series: drm/i915: Adding YUV444 packed format support for skl+ (rev3)
URL : https://patchwork.freedesktop.org/series/66770/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16284
Summary
== Series Details ==
Series: drm/i915/display: mass conversion to intel_de_*() register accessors
(rev2)
URL : https://patchwork.freedesktop.org/series/72533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16283
===
== Series Details ==
Series: drm/i915: Adding YUV444 packed format support for skl+ (rev3)
URL : https://patchwork.freedesktop.org/series/66770/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a705c01c469e drm/i915: Adding YUV444 packed format support for skl+ (V13)
-:9: WARNING:
On 22/01/20 08:26, Janusz Krzysztofik wrote:
Working with a userptr GEM object backed by any type of mapping to
another GEM object, not only GTT mapping currently examined bu the
test, may cause a currently unavoidable lockdep splat inside the i915
driver. Then, such operations are expected t
== Series Details ==
Series: drm/i915/display: mass conversion to intel_de_*() register accessors
(rev2)
URL : https://patchwork.freedesktop.org/series/72533/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/icl_dsi: use intel_de_*() functions
== Series Details ==
Series: drm/i915/display: mass conversion to intel_de_*() register accessors
(rev2)
URL : https://patchwork.freedesktop.org/series/72533/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e3fe468e8ec9 drm/i915/icl_dsi: use intel_de_*() functions for register a
== Series Details ==
Series: drm/hdcp: optimizing the srm handling (rev2)
URL : https://patchwork.freedesktop.org/series/72312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16282
Summary
---
**SUCC
== Series Details ==
Series: drm/i915/dp: Modeset only the tiled connectors with CRTC (rev2)
URL : https://patchwork.freedesktop.org/series/72559/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16281
Summar
On 1/14/20 5:31 PM, Daniele Ceraolo Spurio wrote:
> Now that we can differentiate wants vs uses GuC/HuC, intel_uc_init is
> restricted to running only if we have successfully fetched the required
> blob(s) and are committed to using the microcontroller(s).
> The only remaining thing that can go w
On 1/14/20 5:31 PM, Daniele Ceraolo Spurio wrote:
> To be able to setup GuC submission functions during engine init we need
> to commit to using GuC as soon as possible.
> Currently, the only thing that can stop us from using the
> microcontrollers once we've fetched the blobs is a fundamental
>
== Series Details ==
Series: drm/i915/dp: Modeset only the tiled connectors with CRTC (rev2)
URL : https://patchwork.freedesktop.org/series/72559/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
37497c9a2541 drm/i915/dp: Modeset only the tiled connectors with CRTC
-:11: WARNING:C
== Series Details ==
Series: drm/i915/gt: Lift set-wedged engine dumping out of user paths (rev2)
URL : https://patchwork.freedesktop.org/series/72611/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16279
S
== Series Details ==
Series: drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
URL : https://patchwork.freedesktop.org/series/72626/
State : failure
== Summary ==
Applying: drm/i915/gt: Acquire ce->active before ce->pin_count/ce->pin_mutex
Using index info to reconstruct a bas
== Series Details ==
Series: drm/i915/selftests/perf: measure memcpy bw between regions
URL : https://patchwork.freedesktop.org/series/72621/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16278
Summary
---
Now that we have offline error capture and can reset an engine from
inside an atomic context while also preserving the GPU state for
post-mortem analysis, it is time to handle error interrupts thrown by
the command parser.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/
We always use a deferred bottom-half (either tasklet or irq_work) for
processing the response to an interrupt which means we can recombine the
GT irq ack+handler into one. This simplicity is important in later
patches as we will need to handle and then ack multiple interrupt levels
before acking th
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
The user (e.g. gem_eio) can manipulate the driver into wedging itself,
allowing the user to trigger voluminous logging of inconsequential
details. If we lift the dump to direct calls to intel_gt_set_wedged(),
out of the intel_reset failure handling, we keep the detail logging for
what we expect are
We use the same interrupt mask for each engine, so define it once in a
local and reuse.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/dri
We don't want to report errors on the internal contexts to userspace,
suppressing their own, so treat them as simulated errors. These mostly
arise inside selftests and so are simulated anyway. For the rest, we can
rely on the normal debug channels in CI.
Signed-off-by: Chris Wilson
---
drivers/g
Hi all,
On Wed, 8 Jan 2020 17:08:03 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the generic-ioremap tree got a conflict in:
>
> drivers/gpu/drm/i915/i915_gem_gtt.c
>
> between commit:
>
> 2c86e55d2ab5 ("drm/i915/gtt: split up i915_gem_gtt")
>
> from the drm-intel tree a
On Sat, Jan 25, 2020 at 01:31:06AM -0800, Saarinen, Jani wrote:
> + Martin to re-report.
Could you re-report this so we get the full CI IGT results?
Manasi
>
> > -Original Message-
> > From: Navare, Manasi D
> > Sent: lauantai 25. tammikuuta 2020 4.19
> > To: intel-gfx@lists.freedeskt
== Series Details ==
Series: drm/i915/selftests/perf: measure memcpy bw between regions
URL : https://patchwork.freedesktop.org/series/72621/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/selftests/perf: measure memcpy bw between regions
+dri
== Series Details ==
Series: drm/i915/selftests/perf: measure memcpy bw between regions
URL : https://patchwork.freedesktop.org/series/72621/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a5ec4dca083a drm/i915/selftests/perf: measure memcpy bw between regions
-:175: WARNING:DEE
== Series Details ==
Series: drm/i915/dsi: Enable dsi as part of encoder->enable
URL : https://patchwork.freedesktop.org/series/72619/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7827 -> Patchwork_16277
Summary
---
On Fri, Jan 17, 2020 at 04:16:28AM -0500, Matt Atwood wrote:
> On Tiger Lake we do not support source keying in the pixel formats P010,
> P012, P016.
>
> Bspec: 52890
> Cc: Matt Roper
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/display/intel_sprite.c | 13 +
> 1 file c
On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> CEA-861 says :
> "d = offset for the byte following the reserved data block.
> If no data is provided in the reserved data block, then d=4.
> If no DTDs are provided, then d=0."
>
> So let's not look for DTDs when
On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> I'm curious if there are any bogus 18 byte descriptors around.
> Let's dump them out if we encounter them.
>
> Not sure we'd actually want this, but at least I get to see
> if our CI has anything that hits this :)
>
On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Let's try to make a lot more stuff const in the edid parser.
>
> The "downside" is that we can no longer mangle the EDID in the
> middle of the parsing to apply quirks (drm_mode_detailed()).
> I don't really think ma
On Fri, Jan 24, 2020 at 3:02 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Let's introduce is_detailed_timing_descritor() as the opposite
> counterpart of is_display_descriptor().
>
> Cc: Allen Chen
> Signed-off-by: Ville Syrjälä
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_edid
On Fri, Jan 24, 2020 at 3:02 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Currently we assume any 18 byte descriptor to be a display descritor
> if only the tag byte matches the expected value. But for detailed
> timing descriptors that same byte is just the lower 8 bits of
> hblank, and a
== Series Details ==
Series: drm/i915/dsi: Enable dsi as part of encoder->enable
URL : https://patchwork.freedesktop.org/series/72619/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
90cfe8a7b2cb drm/i915/dsi: Enable dsi as part of encoder->enable
-:31: CHECK:PARENTHESIS_ALIGNMEN
On Fri, Jan 24, 2020 at 3:02 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> I don't understand what the DispID CEA data block revision
> means. The spec doesn't say. I guess some DispID must have
> a value of >= 3 in there or else we generally wouldn't
> even parse the CEA data blocks. Or do
On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> After much head scratching I managed to convince myself that
> for_each_displayid_db() has already done the bounds checks for
> the DispID CEA data block. Which is why we don't need to repeat
> them in cea_db_offsets
Title should be s/i915/edid/ , with that fixed:
Reviewed-by: Alex Deucher
On Fri, Jan 24, 2020 at 3:03 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Nuke some whitespace that shouldn't be there.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 6 +++---
> 1 file ch
== Series Details ==
Series: drm/i915: Remove 'prefault_disable' modparam (rev2)
URL : https://patchwork.freedesktop.org/series/72557/
State : failure
== Summary ==
Applying: drm/i915: Remove 'prefault_disable' modparam
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i91
== Series Details ==
Series: drm/i915: Add missing HDMI audio pixel clocks for gen12
URL : https://patchwork.freedesktop.org/series/72617/
State : failure
== Summary ==
Applying: drm/i915: Add missing HDMI audio pixel clocks for gen12
Using index info to reconstruct a base tree...
M driv
Allow the sysadmin to specify whether we should prevent the CPU from
entering higher C-states while waiting for the CPU, in order to reduce
the latency of request completions and so speed up client continuations.
The target dma latency can be adjusted per-engine using,
/sys/class/drm/card
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure. Later
We busywait on an inflight request (one that is currently executing on
HW, and so might complete quickly) prior to setting up an interrupt and
sleeping. The trade off is that we keep an expensive CPU core busy in
order to avoid wake up latency: where that trade off should lie is best
left to the sy
When we allow ourselves to sleep before a GPU reset after disabling
submission, even for a few milliseconds, gives an innocent context the
opportunity to clear the GPU before the reset occurs. However, how long
to sleep depends on the typical non-preemptible duration (a similar
problem to determini
We monitor the health of the system via periodic heartbeat pulses. The
pulses also provide the opportunity to perform garbage collection.
However, we interpret an incomplete pulse (a missed heartbeat) as an
indication that the system is no longer responsive, i.e. hung, and
perform an engine or full
Execlists uses a scheduling quantum (a timeslice) to alternate execution
between ready-to-run contexts of equal priority. This ensures that all
users (though only if they of equal importance) have the opportunity to
run and prevents livelocks where contexts may have implicit ordering due
to userspa
Use the per-engine sysfs directory to let userspace discover the
mmio_base of each engine. Prior to recent generations, the user
accessible registers on each engine are at a fixed offset relative to
each engine -- but require absolute addressing. As the absolute address
depends on the actual physic
After initialising a preemption request, we give the current resident a
small amount of time to vacate the GPU. The preemption request is for a
higher priority context and should be immediate to maintain high
quality of service (and avoid priority inversion). However, the
preemption granularity of
== Series Details ==
Series: drm/auth: Drop master_create/destroy hooks
URL : https://patchwork.freedesktop.org/series/72609/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7826 -> Patchwork_16274
Summary
---
**SUCCES
Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is
currently pinned, without waiting to see if the inflight operations may
unpin it. We see this problem with the shrinker trying to unbind the
active vma from inside its bind worker:
<6> [472.618968] Workqueue: events_unbound fe
On Mon, Jan 27, 2020 at 11:42:31PM +0530, Ramalingam C wrote:
> 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 mor
== Series Details ==
Series: drm/i915: Restore the kernel context after verifying the w/a (rev2)
URL : https://patchwork.freedesktop.org/series/72588/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7826 -> Patchwork_16271
Su
== Series Details ==
Series: drm/auth: Drop master_create/destroy hooks
URL : https://patchwork.freedesktop.org/series/72609/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
502e4c060823 drm/auth: Drop master_create/destroy hooks
-:78: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-o
== Series Details ==
Series: drm: Introduce struct drm_device based WARN* and use them in i915 (rev4)
URL : https://patchwork.freedesktop.org/series/72035/
State : failure
== Summary ==
Applying: drm/i915/display: Make WARN* drm specific where drm_device ptr is
available
Using index info to r
== Series Details ==
Series: drm/i915/display: Squelch kerneldoc complaints (rev2)
URL : https://patchwork.freedesktop.org/series/72182/
State : failure
== Summary ==
Applying: drm/i915/display: Squelch kerneldoc complaints
Using index info to reconstruct a base tree...
M drivers/gpu/drm
There are reports of unexpected DSB busy/timeout happening after IGT
tests finish running that apparently go away when the DMC firmware isn't
loaded. The bspec doesn't say anything specific about DSB needing us to
exit DC5/DC6, but let's try adding DSB usage to the "DC off" list and
see if that ch
Add XYUV to the list of DRM Formats to test.
Also fix the byte order for the format.
Signed-off-by: Bob Paauwe
Reviewed-by: Uma Shankar
---
lib/igt_color_encoding.c | 1 +
lib/igt_fb.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/igt_color_enco
From: Stanislav Lisovskiy
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
On 26/01/2020 10:23, Chris Wilson wrote:
Do an early rejection of a i915_vma_unbind() attempt if the i915_vma is
currently pinned, without waiting to see if the inflight operations may
unpin it. We see this problem with the shrinker trying to unbind the
active vma from inside its bind worker:
On Fri, 24 Jan 2020, Matt Roper wrote:
> There's a lot of display (watermark) code in intel_pm.c as well, even
> though it doesn't live in the display/ directory. We should probably
> pull the watermark stuff out into a separate display/intel_wm.c or
> something soon, but in the meantime we'll pr
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
Switch from simple iteration over all potential engines to using
macro __for_each_physical_engine which only returns engines that are
actually present.
For each context (as it is created) call gem_context_set_all_engines
so that execbuf will interpret the engine specification in the new way.
Sign
On Fri, 24 Jan 2020, Matt Roper wrote:
> On Fri, Jan 24, 2020 at 03:25:26PM +0200, Jani Nikula wrote:
>> @@ -151,20 +151,20 @@ static void cnl_combo_phys_init(struct
>> drm_i915_private *dev_priv)
>> {
>> u32 val;
>>
>> -val = I915_READ(CHICKEN_MISC_2);
>> +val = intel_de_read(dev
On Sat, 25 Jan 2020, Jani Nikula wrote:
> On Fri, 24 Jan 2020, Rodrigo Vivi wrote:
>> On Fri, Jan 24, 2020 at 01:54:58PM +, Chris Wilson wrote:
>>> Quoting Jani Nikula (2020-01-24 13:25:21)
>>> > Hey all,
>>> >
>>> > So I sent [1] to convert some forcewake register accessors... but what if
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(),
1 - 100 of 189 matches
Mail list logo
