[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."
== Series Details == Series: Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available." URL : https://patchwork.freedesktop.org/series/43239/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4202 -> Patchwork_9041 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/43239/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9041 that come from known issues: === IGT changes === Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-cfl-s3: FAIL (fdo#100368, fdo#103928) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: DMESG-FAIL (fdo#102614, fdo#106103) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cnl-y3: DMESG-WARN (fdo#104951) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (42 -> 39) == Missing(3): fi-ilk-m540 fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4202 -> Patchwork_9041 CI_DRM_4202: ba797356237d1b7beb14f0399e7d2df686134ae1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9041: 3c25073b7b29c2954f176b246f3b39d47fb99c43 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Linux commits == 3c25073b7b29 Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available." == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9041/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Flush the RING stop bit after clearing RING_HEAD in reset
Quoting Chris Wilson (2018-05-17 16:47:26) > Inside the live_hangcheck (reset) selftests, we occasionally see > failures like > > <7>[ 239.094840] i915_gem_set_wedged rcs0 > <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, > hangcheck 0 [5158 ms] > <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) > <7>[ 239.094848] i915_gem_set_wedged Requests: > <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] > prio=1024 @ 5159ms: (null) > <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] > prio=139 @ 5159ms: igt/rcs0[5977]/1 > <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] > prio=1024 @ 5159ms: (null) > <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280, > tail 02a8, batch 0x_] > <7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000 > <7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8 > <7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8 > <7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8 > <7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10 > <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 > <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 > <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 > <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 > <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle] > <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe > <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c > <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d > <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260 > <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x > <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 > <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 0002 > <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write > 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled) > <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, > ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) > <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, > ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 > <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 > <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @ > 5164ms: (null) > <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139 @ > 5164ms: igt/rcs0[5977]/1 > <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139 > <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @ > 5164ms: igt/rcs0[5977]/8 > <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @ > 5165ms: igt/rcs0[5977]/2 > <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @ > 5165ms: igt/rcs0[5977]/3 > <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @ > 5164ms: igt/rcs0[5977]/2 > <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @ > 5165ms: igt/rcs0[5977]/4 > <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for 19a99 > > where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET! > The RING_MODE indicates that is idle and has the STOP_RING bit set, so > try clearing it. > > v2: Only clear the bit on restarting the ring, as we want to be sure the > STOP_RING bit is kept if reset fails on wedging. > > Signed-off-by: Chris Wilson 2/2 passes, it might not just be a coincidence! Please kindly review, -Chris > --- > drivers/gpu/drm/i915/intel_lrc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index 646ecf267411..211585187d2f 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -1773,6 +1773,9 @@ static void enable_execlists(struct intel_engine_cs > *engine) > I915_WRITE(RING_MODE_GEN7(engine), >_MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE)); > > + I915_WRITE(RING_MI_MODE(engine->mmio_base), > + _MASKED_BIT_DISABLE(STOP_RING)); > + > I915_WRITE(RING_HWS_PGA(engine->mmio_base), >engine->status_page.ggtt_offset); > POSTING_READ(RING_HWS_PGA(engine->mmio_base)); > -- > 2.17.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Store a pointer to intel_context in i915_request
On 18/05/2018 04:21, Zhenyu Wang wrote:
On 2018.05.17 22:26:32 +0100, Chris Wilson wrote:
To ease the frequent and ugly pointer dance of
&request->gem_context->engine[request->engine->id] during request
submission, store that pointer as request->hw_context. One major
advantage that we will exploit later is that this decouples the logical
context state from the engine itself.
v2: Set mock_context->ops so we don't crash and burn in selftests.
Cleanups from Tvrtko.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gvt/mmio_context.c | 6 +-
drivers/gpu/drm/i915/gvt/mmio_context.h | 2 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 141 +++---
drivers/gpu/drm/i915/gvt/scheduler.h | 1 -
gvt change looks fine to me.
Acked-by: Zhenyu Wang
Excellent, thanks!
And I think I already have my r-b earlier for non-GVT parts. So let me
repeat it:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 12 +-
drivers/gpu/drm/i915/i915_gem_context.c | 17 ++-
drivers/gpu/drm/i915/i915_gem_context.h | 21 ++-
drivers/gpu/drm/i915/i915_gpu_error.c | 3 +-
drivers/gpu/drm/i915/i915_perf.c | 25 ++--
drivers/gpu/drm/i915/i915_request.c | 34 ++---
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/intel_engine_cs.c| 54 ---
drivers/gpu/drm/i915/intel_guc_submission.c | 10 +-
drivers/gpu/drm/i915/intel_lrc.c | 125 +---
drivers/gpu/drm/i915/intel_lrc.h | 7 -
drivers/gpu/drm/i915/intel_ringbuffer.c | 100 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +-
drivers/gpu/drm/i915/selftests/mock_context.c | 7 +
drivers/gpu/drm/i915/selftests/mock_engine.c | 41 +++--
20 files changed, 321 insertions(+), 296 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c
b/drivers/gpu/drm/i915/gvt/mmio_context.c
index 0f949554d118..708170e61625 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.c
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
@@ -446,9 +446,9 @@ static void switch_mocs(struct intel_vgpu *pre, struct
intel_vgpu *next,
#define CTX_CONTEXT_CONTROL_VAL 0x03
-bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id)
+bool is_inhibit_context(struct intel_context *ce)
{
- u32 *reg_state = ctx->__engine[ring_id].lrc_reg_state;
+ const u32 *reg_state = ce->lrc_reg_state;
u32 inhibit_mask =
_MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT);
@@ -501,7 +501,7 @@ static void switch_mmio(struct intel_vgpu *pre,
* itself.
*/
if (mmio->in_context &&
- !is_inhibit_context(s->shadow_ctx, ring_id))
+
!is_inhibit_context(&s->shadow_ctx->__engine[ring_id]))
continue;
if (mmio->mask)
diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.h
b/drivers/gpu/drm/i915/gvt/mmio_context.h
index 0439eb8057a8..5c3b9ff9f96a 100644
--- a/drivers/gpu/drm/i915/gvt/mmio_context.h
+++ b/drivers/gpu/drm/i915/gvt/mmio_context.h
@@ -49,7 +49,7 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre,
void intel_gvt_init_engine_mmio_context(struct intel_gvt *gvt);
-bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id);
+bool is_inhibit_context(struct intel_context *ce);
int intel_vgpu_restore_inhibit_context(struct intel_vgpu *vgpu,
struct i915_request *req);
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 17f9f8d7e148..e1760030dda1 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -54,11 +54,8 @@ static void set_context_pdp_root_pointer(
static void update_shadow_pdps(struct intel_vgpu_workload *workload)
{
- struct intel_vgpu *vgpu = workload->vgpu;
- int ring_id = workload->ring_id;
- struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
- shadow_ctx->__engine[ring_id].state->obj;
+ workload->req->hw_context->state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
@@ -128,9 +125,8 @@ static int populate_shadow_context(struct intel_vgpu_workload *workload)
struct intel_vgpu *vgpu = workload->vgpu;
struct intel_gvt *gvt = vgpu->gvt;
int ring_id = workload->ring_id;
- struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
- shadow_ctx->__engine[ring_id].state->obj;
+ workload->req->hw_context->state->obj;
struct execlist_ring_context
[Intel-gfx] [PATCH] drm/i915/lvds: Move acpi lid notification registration to registration phase
Delay registering ourselves with the acpi lid notification mechansim
until we are registering the connectors after initialisation is
complete. This prevents a possibilty of trying to handle the lid
notification before we are ready with the danger of chasing
uninitialised function pointers.
BUG: unable to handle kernel NULL pointer dereference at
IP: (null)
PGD 0 P4D 0
Oops: 0010 [#1] PREEMPT SMP PTI
Modules linked in: arc4(+) iwldvm(+) i915(+) mac80211 i2c_algo_bit coretemp
mei_wdt iwlwifi drm_kms_helper kvm_intel wmi_bmof iTCO_wdt iTCO_vendor_support
kvm snd_hda_codec_conexant snd_hda_codec_generic drm psmouse cfg80211 irqbypass
input_leds pcspkr i2c_i801 snd_hda_intel snd_hda_codec thinkpad_acpi
snd_hda_core mei_me lpc_ich snd_hwdep e1000e wmi nvram snd_pcm mei snd_timer
shpchp ptp pps_core rfkill syscopyarea snd intel_agp sysfillrect intel_gtt
soundcore sysimgblt battery led_class fb_sys_fops ac rtc_cmos agpgart evdev
mac_hid acpi_cpufreq ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2
fscrypto crypto_simd glue_helper cryptd aes_x86_64 xts algif_skcipher af_alg
dm_crypt dm_mod sd_mod uas usb_storage serio_raw atkbd libps2 ahci libahci
uhci_hcd libata scsi_mod ehci_pci
ehci_hcd usbcore usb_common i8042 serio
CPU: 1 PID: 378 Comm: systemd-logind Not tainted 4.16.8-1-ARCH #1
Hardware name: LENOVO 7454CTO/7454CTO, BIOS 6DET72WW (3.22 ) 10/25/2012
RIP: 0010: (null)
RSP: 0018:af4580c33a18 EFLAGS: 00010287
RAX: RBX: 947533558000 RCX: 003e
RDX: c0aa80c0 RSI: af4580c33a3c RDI: 947534e4c000
RBP: 947533558338 R08: 947534598930 R09: c0a928b1
R10: d8f181d5fd40 R11: R12: c0a928b1
R13: 947533558368 R14: c0a928a9 R15: 947534e4c000
FS: 7f3dc4ddb940() GS:94753928() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: CR3: 6e214000 CR4: 000406e0
Call Trace:
? intel_modeset_setup_hw_state+0x385/0xf60 [i915]
? __intel_display_resume+0x1e/0xc0 [i915]
? intel_display_resume+0xcc/0x120 [i915]
? intel_lid_notify+0xbc/0xc0 [i915]
? notifier_call_chain+0x47/0x70
? blocking_notifier_call_chain+0x3e/0x60
? acpi_lid_notify_state+0x8f/0x1d0
? acpi_lid_update_state+0x49/0x70
? acpi_lid_input_open+0x60/0x90
? input_open_device+0x5d/0xa0
? evdev_open+0x1ba/0x1e0 [evdev]
? chrdev_open+0xa3/0x1b0
? cdev_put.part.0+0x20/0x20
? do_dentry_open+0x14c/0x300
? path_openat+0x30c/0x1240
? current_time+0x16/0x60
? do_filp_open+0x93/0x100
? __check_object_size+0xfb/0x180
? do_sys_open+0x186/0x210
? do_syscall_64+0x74/0x190
? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
Code: Bad RIP value.
RIP: (null) RSP: af4580c33a18
CR2:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106559
Signed-off-by: Chris Wilson
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_lvds.c | 43 +++
1 file changed, 32 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 8691c86f579c..a844d48e6731 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -574,6 +574,36 @@ static int intel_lid_notify(struct notifier_block *nb,
unsigned long val,
return NOTIFY_OK;
}
+static int
+intel_lvds_connector_register(struct drm_connector *connector)
+{
+ struct intel_lvds_connector *lvds = to_lvds_connector(connector);
+ int ret;
+
+ ret = intel_connector_register(connector);
+ if (ret)
+ return ret;
+
+ lvds->lid_notifier.notifier_call = intel_lid_notify;
+ if (acpi_lid_notifier_register(&lvds->lid_notifier)) {
+ DRM_DEBUG_KMS("lid notifier registration failed\n");
+ lvds->lid_notifier.notifier_call = NULL;
+ }
+
+ return 0;
+}
+
+static void
+intel_lvds_connector_unregister(struct drm_connector *connector)
+{
+ struct intel_lvds_connector *lvds = to_lvds_connector(connector);
+
+ if (lvds->lid_notifier.notifier_call)
+ acpi_lid_notifier_unregister(&lvds->lid_notifier);
+
+ intel_connector_unregister(connector);
+}
+
/**
* intel_lvds_destroy - unregister and free LVDS structures
* @connector: connector to free
@@ -586,9 +616,6 @@ static void intel_lvds_destroy(struct drm_connector
*connector)
struct intel_lvds_connector *lvds_connector =
to_lvds_connector(connector);
- if (lvds_connector->lid_notifier.notifier_call)
- acpi_lid_notifier_unregister(&lvds_connector->lid_notifier);
-
if (!IS_ERR_OR_NULL(lvds_connector->base.edid))
kfree(lvds_connector->base.edid);
@@ -609,8 +636,8 @@ static const struct drm_connector_funcs
intel_lvds_connector_funcs = {
.fill
Re: [Intel-gfx] [PATCH 18/19] drm/i915/execlists: Direct submission (avoid tasklet/ksoftirqd)
On 17/05/2018 18:07, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-17 14:13:00)
On 17/05/2018 08:40, Chris Wilson wrote:
Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
bottom half"), we came to the conclusion that running our CSB processing
and ELSP submission from inside the irq handler was a bad idea. A really
bad idea as we could impose nearly 1s latency on other users of the
system, on average! Deferring our work to a tasklet allowed us to do the
processing with irqs enabled, reducing the impact to an average of about
50us.
We have since eradicated the use of forcewaked mmio from inside the CSB
processing and ELSP submission, bringing the impact down to around 5us
(on Kabylake); an order of magnitude better than our measurements 2
years ago on Broadwell and only about 2x worse on average than the
gem_syslatency on an unladen system.
Comparing the impact on the maximum latency observed over a 120s interval,
repeated several times (using gem_syslatency, similar to RT's cyclictest)
while the system is fully laden with i915 nops, we see that direct
submission definitely worsens the response but not to the same outlandish
degree as before.
x Unladen baseline
+ Using tasklet
* Direct submission
++
|xx x +++++ + * * * ** *** * *|
||A| |__AM__| |_A_M___| |
++
What are these headers? This one and below, I cannot decipher them at all.
Ministat histogram. The headers being the label for the charts; it's a
bit flat so hard to tell it's a histogram.
N Min MaxMedian AvgStddev
x 10 51810 9.3 3.6530049
+ 1072 120 108 102.9 15.758243
* 10 255 348 316 305.7 28.74814
In micro-seconds? so tasklet is 108us median? Direct submission 316us
median?
Yup, more runs required so you have prettier graphs and units.
Biggest problem for me is that in these tests it is only showing as
significantly worse than the current tasklet. So it is kind of difficult
the sell the series. :)
If it only solves issues when submitting from a RT task then it is not
so interesting. RT tasks are rare and which deal with 3d/media/ocl
probably even rarer. Or you know of any?
Or perhaps you need to add data from gem_latency as well if that shows
some wins purely on the i915 side?
Regards,
Tvrtko
And with a background load
This is IO background load?
Yes, background writeout.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available."
== Series Details == Series: Revert "drm/i915/edp: Allow alternate fixed mode for eDP if available." URL : https://patchwork.freedesktop.org/series/43239/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4202_full -> Patchwork_9041_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9041_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9041_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43239/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9041_full: === IGT changes === Possible regressions igt@drv_hangman@error-state-capture-vebox: shard-kbl: PASS -> FAIL Warnings igt@gem_exec_schedule@deep-render: shard-kbl: SKIP -> PASS igt@kms_plane_lowres@pipe-c-tiling-x: shard-apl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9041_full that come from known issues: === IGT changes === Issues hit igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_flip@dpms-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +2 igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) Possible fixes igt@drv_selftest@live_hangcheck: shard-kbl: DMESG-FAIL (fdo#106560) -> PASS igt@gem_exec_schedule@deep-bsd1: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS igt@kms_cursor_legacy@flip-vs-cursor-legacy: shard-hsw: FAIL (fdo#102670) -> PASS igt@kms_flip@2x-wf_vblank-ts-check-interruptible: shard-glk: FAIL (fdo#103928) -> PASS igt@kms_flip@flip-vs-absolute-wf_vblank: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-hsw: FAIL (fdo#105707) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-apl: FAIL (fdo#105363, fdo#102887) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: shard-apl: DMESG-FAIL (fdo#103558, fdo#105602) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-shrfb-fliptrack: shard-glk: FAIL (fdo#103167, fdo#104724) -> PASS igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: shard-apl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +15 igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4202 -> Patchwork_9041 CI_DRM_4202: ba797356237d1b7beb14f0399e7d2df686134ae1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9041: 3c25073b7b29c2954f176b246f3b39d47fb99c43 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9041/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/19] drm/i915/execlists: Direct submission (avoid tasklet/ksoftirqd)
Quoting Tvrtko Ursulin (2018-05-18 09:06:03)
>
> On 17/05/2018 18:07, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-17 14:13:00)
> >>
> >> On 17/05/2018 08:40, Chris Wilson wrote:
> >>> Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a
> >>> bottom half"), we came to the conclusion that running our CSB processing
> >>> and ELSP submission from inside the irq handler was a bad idea. A really
> >>> bad idea as we could impose nearly 1s latency on other users of the
> >>> system, on average! Deferring our work to a tasklet allowed us to do the
> >>> processing with irqs enabled, reducing the impact to an average of about
> >>> 50us.
> >>>
> >>> We have since eradicated the use of forcewaked mmio from inside the CSB
> >>> processing and ELSP submission, bringing the impact down to around 5us
> >>> (on Kabylake); an order of magnitude better than our measurements 2
> >>> years ago on Broadwell and only about 2x worse on average than the
> >>> gem_syslatency on an unladen system.
> >>>
> >>> Comparing the impact on the maximum latency observed over a 120s interval,
> >>> repeated several times (using gem_syslatency, similar to RT's cyclictest)
> >>> while the system is fully laden with i915 nops, we see that direct
> >>> submission definitely worsens the response but not to the same outlandish
> >>> degree as before.
> >>>
> >>> x Unladen baseline
> >>> + Using tasklet
> >>> * Direct submission
> >>>
> >>> ++
> >>> |xx x +++++ + * * * ** *** * *|
> >>> ||A| |__AM__| |_A_M___| |
> >>> ++
> >>
> >> What are these headers? This one and below, I cannot decipher them at all.
> >
> > Ministat histogram. The headers being the label for the charts; it's a
> > bit flat so hard to tell it's a histogram.
> >
> >>> N Min MaxMedian Avg
> >>> Stddev
> >>> x 10 51810 9.3
> >>> 3.6530049
> >>> + 1072 120 108 102.9
> >>> 15.758243
> >>> * 10 255 348 316 305.7
> >>> 28.74814
> >>
> >> In micro-seconds? so tasklet is 108us median? Direct submission 316us
> >> median?
> >
> > Yup, more runs required so you have prettier graphs and units.
>
> Biggest problem for me is that in these tests it is only showing as
> significantly worse than the current tasklet. So it is kind of difficult
> the sell the series. :)
Ba! Compared to the previous best state 2 years ago, we're an order
magnitude better. (Unbelievable!)
I think it's simply a lack of a reference point, we're about 100% faster
in some microbenchmark stress igts, about 10% faster in regular stress
igts, and will not suffer some of the 200ms timeout -> wedged!
Any latency is bad, but at what point do we worry about the trade-off
between our latency and the rest of the system?
> If it only solves issues when submitting from a RT task then it is not
> so interesting. RT tasks are rare and which deal with 3d/media/ocl
> probably even rarer. Or you know of any?
No, it's not just an issue from RT. We see examples of the driver being
so starved we declare the system is wedged, to much more mundane
artifacts of our throughput being diminished due to the latency in
submitting work.
> Or perhaps you need to add data from gem_latency as well if that shows
> some wins purely on the i915 side?
The patch before (process CSB from interrupt handler) is justifiable
just by the bugs it solves. This patch, I think is justifiable by our
perf gains and the impact it has for low latency requirements. Or we can
wait until the next patch is mature, that tries to reduce the lock
contention by splitting the data structures.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lvds: Move acpi lid notification registration to registration phase
== Series Details == Series: drm/i915/lvds: Move acpi lid notification registration to registration phase URL : https://patchwork.freedesktop.org/series/43390/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4203 -> Patchwork_9042 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9042 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9042, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43390/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9042: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9042 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cnl-psr: PASS -> DMESG-WARN (fdo#104951) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104951 https://bugs.freedesktop.org/show_bug.cgi?id=104951 == Participating hosts (41 -> 39) == Additional (1): fi-kbl-7560u Missing(3): fi-ilk-m540 fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4203 -> Patchwork_9042 CI_DRM_4203: 76b6f2aaa6103e0c09fd87c3979aeb256a701615 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9042: 62b28ba957be6064cc05db5a50fc5f722713c7e0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Linux commits == 62b28ba957be drm/i915/lvds: Move acpi lid notification registration to registration phase == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9042/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Store a pointer to intel_context in i915_request
Quoting Tvrtko Ursulin (2018-05-18 08:43:33) > > On 18/05/2018 04:21, Zhenyu Wang wrote: > > On 2018.05.17 22:26:32 +0100, Chris Wilson wrote: > >> To ease the frequent and ugly pointer dance of > >> &request->gem_context->engine[request->engine->id] during request > >> submission, store that pointer as request->hw_context. One major > >> advantage that we will exploit later is that this decouples the logical > >> context state from the engine itself. > >> > >> v2: Set mock_context->ops so we don't crash and burn in selftests. > >> Cleanups from Tvrtko. > >> > >> Signed-off-by: Chris Wilson > >> Cc: Tvrtko Ursulin > >> --- > >> drivers/gpu/drm/i915/gvt/mmio_context.c | 6 +- > >> drivers/gpu/drm/i915/gvt/mmio_context.h | 2 +- > >> drivers/gpu/drm/i915/gvt/scheduler.c | 141 +++--- > >> drivers/gpu/drm/i915/gvt/scheduler.h | 1 - > > > > gvt change looks fine to me. > > > > Acked-by: Zhenyu Wang > > Excellent, thanks! > > And I think I already have my r-b earlier for non-GVT parts. So let me > repeat it: > > Reviewed-by: Tvrtko Ursulin Thanks. Applied, please yell if I broke anything, or better yet donate some machines to testing intel-gfx@ :) There will be a few more changes to make struct intel_context a first class citizen for i915_request if Tvrtko manages to whip me or the api into shape. So expect a little more upheaval in the coming months. I'm thinking an api like: ce = intel_context_get_and_lock(context, engine); rq = i915_request_get(ce); ... i915_request_add(rq); intel_context_put_and_unlock(ce); (get_and_lock() is a helper around _get() and _lock()) In the gvt case, I expect you will want to manage your intel_contexts explicitly as the ref/pin/locked phases is slightly longer for you than the typical construct-a-request used elsewhere. Note also that the goal is to replace the struct_mutex with fine grained locks. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915: Make intel_engine_dump irqsafe
To be useful later, enable intel_engine_dump() to be called from irq
context (i.e. using saving and restoring irq start rather than assuming
we enter with irqs enabled).
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 26f9f8aab949..2ce18bed6a7b 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1358,6 +1358,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
const struct intel_engine_execlists * const execlists =
&engine->execlists;
struct i915_gpu_error * const error = &engine->i915->gpu_error;
struct i915_request *rq, *last;
+ unsigned long flags;
struct rb_node *rb;
int count;
@@ -1424,7 +1425,8 @@ void intel_engine_dump(struct intel_engine_cs *engine,
drm_printf(m, "\tDevice is asleep; skipping register dump\n");
}
- spin_lock_irq(&engine->timeline.lock);
+ local_irq_save(flags);
+ spin_lock(&engine->timeline.lock);
last = NULL;
count = 0;
@@ -1466,16 +1468,17 @@ void intel_engine_dump(struct intel_engine_cs *engine,
print_request(m, last, "\t\tQ ");
}
- spin_unlock_irq(&engine->timeline.lock);
+ spin_unlock(&engine->timeline.lock);
- spin_lock_irq(&b->rb_lock);
+ spin_lock(&b->rb_lock);
for (rb = rb_first(&b->waiters); rb; rb = rb_next(rb)) {
struct intel_wait *w = rb_entry(rb, typeof(*w), node);
drm_printf(m, "\t%s [%d] waiting for %x\n",
w->tsk->comm, w->tsk->pid, w->seqno);
}
- spin_unlock_irq(&b->rb_lock);
+ spin_unlock(&b->rb_lock);
+ local_irq_restore(flags);
drm_printf(m, "IRQ? 0x%lx (breadcrumbs? %s) (execlists? %s)\n",
engine->irq_posted,
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915/execlists: Handle copying default context state for atomic reset
We want to be able to reset the GPU from inside a timer callback
(hardirq context). One step requires us to copy the default context
state over to the guilty context, which means we need to plan in advance
to have that object accessible from within an atomic context. The atomic
context prevents us from pinning the object or from peeking into the
shmemfs backing store (all may sleep), so we choose to pin the
default_state into memory when the engine becomes active. This
compromise allows us to swap out the default state when idle, when
required.
References: 5692251c254a ("drm/i915/lrc: Scrub the GPU state of the guilty
hanging request")
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 15 +++
drivers/gpu/drm/i915/intel_lrc.c| 15 ---
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
3 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 2ce18bed6a7b..8c795f854c9b 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1082,6 +1082,11 @@ void intel_engines_park(struct drm_i915_private *i915)
if (engine->park)
engine->park(engine);
+ if (engine->pinned_default_state) {
+ i915_gem_object_unpin_map(engine->default_state);
+ engine->pinned_default_state = NULL;
+ }
+
i915_gem_batch_pool_fini(&engine->batch_pool);
engine->execlists.no_priolist = false;
}
@@ -1099,6 +1104,16 @@ void intel_engines_unpark(struct drm_i915_private *i915)
enum intel_engine_id id;
for_each_engine(engine, i915, id) {
+ void *map;
+
+ /* Pin the default state for fast resets from atomic context. */
+ map = NULL;
+ if (engine->default_state)
+ map = i915_gem_object_pin_map(engine->default_state,
+ I915_MAP_WB);
+ if (!IS_ERR_OR_NULL(map))
+ engine->pinned_default_state = map;
+
if (engine->unpark)
engine->unpark(engine);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3744f5750624..857ab04452f0 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1964,17 +1964,10 @@ static void execlists_reset(struct intel_engine_cs
*engine,
* to recreate its own state.
*/
regs = request->hw_context->lrc_reg_state;
- if (engine->default_state) {
- void *defaults;
-
- defaults = i915_gem_object_pin_map(engine->default_state,
- I915_MAP_WB);
- if (!IS_ERR(defaults)) {
- memcpy(regs, /* skip restoring the vanilla PPHWSP */
- defaults + LRC_STATE_PN * PAGE_SIZE,
- engine->context_size - PAGE_SIZE);
- i915_gem_object_unpin_map(engine->default_state);
- }
+ if (engine->pinned_default_state) {
+ memcpy(regs, /* skip restoring the vanilla PPHWSP */
+ engine->pinned_default_state + LRC_STATE_PN * PAGE_SIZE,
+ engine->context_size - PAGE_SIZE);
}
execlists_init_reg_state(regs,
request->gem_context, engine, request->ring);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 20c4e13efc0d..acef385c4c80 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -342,6 +342,7 @@ struct intel_engine_cs {
struct i915_timeline timeline;
struct drm_i915_gem_object *default_state;
+ void *pinned_default_state;
atomic_t irq_count;
unsigned long irq_posted;
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] drm/i915: Allow init_breadcrumbs to be used from irq context
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 18e643df523e..86a987b8ac66 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -846,8 +846,9 @@ static void cancel_fake_irq(struct intel_engine_cs *engine)
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine)
{
struct intel_breadcrumbs *b = &engine->breadcrumbs;
+ unsigned long flags;
- spin_lock_irq(&b->irq_lock);
+ spin_lock_irqsave(&b->irq_lock, flags);
/*
* Leave the fake_irq timer enabled (if it is running), but clear the
@@ -871,7 +872,7 @@ void intel_engine_reset_breadcrumbs(struct intel_engine_cs
*engine)
*/
clear_bit(ENGINE_IRQ_BREADCRUMB, &engine->irq_posted);
- spin_unlock_irq(&b->irq_lock);
+ spin_unlock_irqrestore(&b->irq_lock, flags);
}
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine)
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr
From: Vathsala Nagaraju
For psr block #9, the vbt description has moved to options [0-3] for
TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
structure. Since spec does not mention from which VBT version this
change was added to vbt.bsf file, we cannot depend on bdb->version check
to change for all the platforms.
There is RCR inplace for GOP team to provide the version number
to make generic change. Since Kabylake with bdb version 209 is having this
change, limiting this change to gen9_bc and version 209+ to unblock google.
Tested on skl(bdb version 203,without options) and
kabylake(bdb version 209,212) having new options.
bspec 20131
v2: (Jani and Rodrigo)
move the 165 version check to intel_bios.c
v3: Jani
Move the abstraction to intel_bios.
v4: Jani
Rename tp*_wakeup_time to have "us" suffix.
For values outside range[0-3],default to max 2500us.
Old decimal value was wake up time in multiples of 100us.
v5: Jani and Rodrigo
Handle option 2 in default condition.
Print oustide range value.
For negetive values default to 2500us.
v6: Jani
Handle default first and then fall through for case 2.
v7: Rodrigo
Apply this change for IS_GEN9_BC and vbt version > 209.
v8: Puthik
add new function vbt_psr_to_us.
Cc: Rodrigo Vivi
Cc: Puthikorn Voravootivat
Cc: Dhinakaran Pandiyan
Cc: José Roberto de Souza
Cc: Jani Nikula
Signed-off-by: Maulik V Vaghela
Signed-off-by: Vathsala Nagaraju
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 8
drivers/gpu/drm/i915/intel_bios.c | 38 --
drivers/gpu/drm/i915/intel_psr.c | 39 ---
4 files changed, 62 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e33c380..dcfa791 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1078,8 +1078,8 @@ struct intel_vbt_data {
bool require_aux_wakeup;
int idle_frames;
enum psr_lines_to_wait lines_to_wait;
- int tp1_wakeup_time;
- int tp2_tp3_wakeup_time;
+ int tp1_wakeup_time_us;
+ int tp2_tp3_wakeup_time_us;
} psr;
struct {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 196a0eb..513b4a4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4088,10 +4088,10 @@ enum {
#define EDP_Y_COORDINATE_ENABLE (1<<25) /* GLK and CNL+ */
#define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
-#define EDP_PSR2_TP2_TIME_500(0<<8)
-#define EDP_PSR2_TP2_TIME_100(1<<8)
-#define EDP_PSR2_TP2_TIME_2500 (2<<8)
-#define EDP_PSR2_TP2_TIME_50 (3<<8)
+#define EDP_PSR2_TP2_TIME_500us (0<<8)
+#define EDP_PSR2_TP2_TIME_100us (1<<8)
+#define EDP_PSR2_TP2_TIME_2500us (2<<8)
+#define EDP_PSR2_TP2_TIME_50us (3<<8)
#define EDP_PSR2_TP2_TIME_MASK (3<<8)
#define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
#define EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 54270bd..5d8c29f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -647,12 +647,26 @@ static int intel_bios_ssc_frequency(struct
drm_i915_private *dev_priv,
}
}
+static int vbt_psr_to_us(bool is_waketime_options, int vbt_value)
+{
+ if (is_waketime_options) {
+ int waketime_map[] = {500, 100, 2500, 0};
+ /* Reset to value 2 = 2500us for outside range [0-3] */
+ if (vbt_value < 0 || vbt_value > 3)
+ vbt_value = 2;
+ return waketime_map[vbt_value];
+ } else {
+ return vbt_value * 100;
+ }
+}
+
static void
parse_psr(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
{
const struct bdb_psr *psr;
const struct psr_table *psr_table;
int panel_type = dev_priv->vbt.panel_type;
+ bool is_waketime_options = false;
psr = find_section(bdb, BDB_PSR);
if (!psr) {
@@ -688,8 +702,28 @@ static int intel_bios_ssc_frequency(struct
drm_i915_private *dev_priv,
break;
}
- dev_priv->vbt.psr.tp1_wakeup_time = psr_table->tp1_wakeup_time;
- dev_priv->vbt.psr.tp2_tp3_wakeup_time = psr_table->tp2_tp3_wakeup_time;
+ /*
+* New psr wake options 0=500us, 1=100us, 2=2500us, 3=0us
+* Old decimal value is wake up time in multiples of 100 us.
+* TODO: add other platforms having new psr options.
+*/
+ is_waketime_options = ((bdb->version >= 209) && IS_GEN9_BC(dev_priv));
+ if (is_waketime_options) {
+ /* Reset to value 2 = 2500us fo
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,1/3] drm/i915: Make intel_engine_dump irqsafe
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make intel_engine_dump irqsafe
URL : https://patchwork.freedesktop.org/series/43396/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0bb804040e08 drm/i915: Make intel_engine_dump irqsafe
55bb946fc4b5 drm/i915/execlists: Handle copying default context state for
atomic reset
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#17:
References: 5692251c254a ("drm/i915/lrc: Scrub the GPU state of the guilty
hanging request")
-:17: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 5692251c254a ("drm/i915/lrc:
Scrub the GPU state of the guilty hanging request")'
#17:
References: 5692251c254a ("drm/i915/lrc: Scrub the GPU state of the guilty
hanging request")
total: 1 errors, 1 warnings, 0 checks, 55 lines checked
2f68093ce8d2 drm/i915: Allow init_breadcrumbs to be used from irq context
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Wait longer for the old active request
On 17/05/2018 15:24, Chris Wilson wrote:
When testing reset, we wait for 1s on the main thread for the hang to
start. Meanwhile, we continue submitting requests on all the background
threads, and we may have more threads than cores and so potentially
starve the waiter from being woken within the timeout. As the hang
timeout and the active timeouts are the same, it is hard to distinguish
which caused the timeout. Bump the active thread timeouts to 5s,
compared to the 1s timeout for the hang, so that we preferentially
report the hang timing out, while hopefully ensuring that we do at least
wake up the hang thread first before declaring the background active
timeout.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/intel_hangcheck.c | 48 +--
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 438e0b045a2c..f1dc42a171c8 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -560,6 +560,30 @@ struct active_engine {
#define TEST_SELF BIT(2)
#define TEST_PRIORITY BIT(3)
+static int active_request_put(struct i915_request *rq)
+{
+ int err = 0;
+
+ if (!rq)
+ return 0;
+
+ if (i915_request_wait(rq, 0, 5 * HZ) < 0) {
+ GEM_TRACE("%s timed out waiting for completion of fence %llx:%d,
seqno %d.\n",
+ rq->engine->name,
+ rq->fence.context,
+ rq->fence.seqno,
+ i915_request_global_seqno(rq));
+ GEM_TRACE_DUMP();
+
+ i915_gem_set_wedged(rq->i915);
+ err = -EIO;
+ }
+
+ i915_request_put(rq);
+
+ return err;
+}
+
static int active_engine(void *data)
{
I915_RND_STATE(prng);
@@ -608,24 +632,20 @@ static int active_engine(void *data)
i915_request_add(new);
mutex_unlock(&engine->i915->drm.struct_mutex);
- if (old) {
- if (i915_request_wait(old, 0, HZ) < 0) {
- GEM_TRACE("%s timed out.\n", engine->name);
- GEM_TRACE_DUMP();
-
- i915_gem_set_wedged(engine->i915);
- i915_request_put(old);
- err = -EIO;
- break;
- }
- i915_request_put(old);
- }
+ err = active_request_put(old);
+ if (err)
+ break;
cond_resched();
}
- for (count = 0; count < ARRAY_SIZE(rq); count++)
- i915_request_put(rq[count]);
+ for (count = 0; count < ARRAY_SIZE(rq); count++) {
+ int err__ = active_request_put(rq[count]);
+
+ /* Keep the first error */
+ if (!err)
+ err = err__;
+ }
err_file:
mock_file_free(engine->i915, file);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr
On Fri, 18 May 2018, vathsala nagaraju wrote:
> From: Vathsala Nagaraju
>
> For psr block #9, the vbt description has moved to options [0-3] for
> TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt
> structure. Since spec does not mention from which VBT version this
> change was added to vbt.bsf file, we cannot depend on bdb->version check
> to change for all the platforms.
>
> There is RCR inplace for GOP team to provide the version number
> to make generic change. Since Kabylake with bdb version 209 is having this
> change, limiting this change to gen9_bc and version 209+ to unblock google.
>
> Tested on skl(bdb version 203,without options) and
> kabylake(bdb version 209,212) having new options.
>
> bspec 20131
>
> v2: (Jani and Rodrigo)
> move the 165 version check to intel_bios.c
> v3: Jani
> Move the abstraction to intel_bios.
> v4: Jani
> Rename tp*_wakeup_time to have "us" suffix.
> For values outside range[0-3],default to max 2500us.
> Old decimal value was wake up time in multiples of 100us.
> v5: Jani and Rodrigo
> Handle option 2 in default condition.
> Print oustide range value.
> For negetive values default to 2500us.
> v6: Jani
> Handle default first and then fall through for case 2.
> v7: Rodrigo
> Apply this change for IS_GEN9_BC and vbt version > 209.
> v8: Puthik
> add new function vbt_psr_to_us.
>
> Cc: Rodrigo Vivi
> Cc: Puthikorn Voravootivat
> Cc: Dhinakaran Pandiyan
> Cc: José Roberto de Souza
> Cc: Jani Nikula
>
> Signed-off-by: Maulik V Vaghela
> Signed-off-by: Vathsala Nagaraju
> ---
> drivers/gpu/drm/i915/i915_drv.h | 4 ++--
> drivers/gpu/drm/i915/i915_reg.h | 8
> drivers/gpu/drm/i915/intel_bios.c | 38 --
> drivers/gpu/drm/i915/intel_psr.c | 39
> ---
> 4 files changed, 62 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e33c380..dcfa791 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1078,8 +1078,8 @@ struct intel_vbt_data {
> bool require_aux_wakeup;
> int idle_frames;
> enum psr_lines_to_wait lines_to_wait;
> - int tp1_wakeup_time;
> - int tp2_tp3_wakeup_time;
> + int tp1_wakeup_time_us;
> + int tp2_tp3_wakeup_time_us;
> } psr;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 196a0eb..513b4a4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4088,10 +4088,10 @@ enum {
> #define EDP_Y_COORDINATE_ENABLE(1<<25) /* GLK and CNL+ */
> #define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
> #define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
> -#define EDP_PSR2_TP2_TIME_500 (0<<8)
> -#define EDP_PSR2_TP2_TIME_100 (1<<8)
> -#define EDP_PSR2_TP2_TIME_2500 (2<<8)
> -#define EDP_PSR2_TP2_TIME_50 (3<<8)
> +#define EDP_PSR2_TP2_TIME_500us(0<<8)
> +#define EDP_PSR2_TP2_TIME_100us(1<<8)
> +#define EDP_PSR2_TP2_TIME_2500us (2<<8)
> +#define EDP_PSR2_TP2_TIME_50us (3<<8)
> #define EDP_PSR2_TP2_TIME_MASK (3<<8)
> #define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
> #define EDP_PSR2_FRAME_BEFORE_SU_MASK (0xf<<4)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 54270bd..5d8c29f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -647,12 +647,26 @@ static int intel_bios_ssc_frequency(struct
> drm_i915_private *dev_priv,
> }
> }
>
> +static int vbt_psr_to_us(bool is_waketime_options, int vbt_value)
> +{
> + if (is_waketime_options) {
> + int waketime_map[] = {500, 100, 2500, 0};
> + /* Reset to value 2 = 2500us for outside range [0-3] */
> + if (vbt_value < 0 || vbt_value > 3)
> + vbt_value = 2;
> + return waketime_map[vbt_value];
> + } else {
> + return vbt_value * 100;
> + }
> +}
> +
> static void
> parse_psr(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
> {
> const struct bdb_psr *psr;
> const struct psr_table *psr_table;
> int panel_type = dev_priv->vbt.panel_type;
> + bool is_waketime_options = false;
>
> psr = find_section(bdb, BDB_PSR);
> if (!psr) {
> @@ -688,8 +702,28 @@ static int intel_bios_ssc_frequency(struct
> drm_i915_private *dev_priv,
> break;
> }
>
> - dev_priv->vbt.psr.tp1_wakeup_time = psr_table->tp1_wakeup_time;
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time = psr_table->tp2_tp3_wakeup_time;
> + /*
> + * New psr wake options 0=500us, 1=100us, 2=2500us, 3=0us
> + * Old decimal value is wake up time in multiples of 100 us.
> + *
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Make intel_engine_dump irqsafe
== Series Details == Series: series starting with [CI,1/3] drm/i915: Make intel_engine_dump irqsafe URL : https://patchwork.freedesktop.org/series/43396/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4204 -> Patchwork_9043 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/43396/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9043 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cnl-y3: PASS -> DMESG-FAIL (fdo#104724, fdo#103191) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (42 -> 39) == Additional (1): fi-byt-j1900 Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4204 -> Patchwork_9043 CI_DRM_4204: 1bffedaef627748248914f5a043e379fee0b121d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9043: 2f68093ce8d2ebf7c52166136c6e3e1ba948e561 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Linux commits == 2f68093ce8d2 drm/i915: Allow init_breadcrumbs to be used from irq context 55bb946fc4b5 drm/i915/execlists: Handle copying default context state for atomic reset 0bb804040e08 drm/i915: Make intel_engine_dump irqsafe == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9043/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/2] drm/i915/gmbus: Enable burst read
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
v3:
Macro is added for detecting the BURST_READ Support [Jani]
Runtime detection of the need for burst_read [Jani]
Calculation enhancement.
v4:
GMBUS0 reg val is passed from caller [ville]
Removed a extra var [ville]
Extra brackets are removed [ville]
Implemented the handling of 512Bytes Burst Read.
v5:
Burst read max length is fixed at 767Bytes [Ville]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 62 +---
3 files changed, 56 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 028691108125..14293fc1a142 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2552,6 +2552,9 @@ intel_info(const struct drm_i915_private *dev_priv)
*/
#define HAS_AUX_IRQ(dev_priv) true
#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
+#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
+ IS_GEMINILAKE(dev_priv) || \
+ IS_KABYLAKE(dev_priv))
/* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
* rows, which changed the alignment requirements and fence programming.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ebdf7c9d816e..575d9495f3e2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2996,6 +2996,7 @@ enum i915_power_well_id {
#define GMBUS_RATE_400KHZ(2<<8) /* reserved on Pineview */
#define GMBUS_RATE_1MHZ (3<<8) /* reserved on Pineview */
#define GMBUS_HOLD_EXT (1<<7) /* 300ns hold time, rsvd on Pineview */
+#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
#define GMBUS_PIN_DISABLED 0
#define GMBUS_PIN_SSC1
#define GMBUS_PIN_VGADDC 2
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 1c0f6b56b209..9e1142a2f81b 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -371,12 +371,30 @@ unsigned int gmbus_max_xfer_size(struct drm_i915_private
*dev_priv)
static int
gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
unsigned short addr, u8 *buf, unsigned int len,
- u32 gmbus1_index)
+ u32 gmbus0_reg, u32 gmbus1_index)
{
+ unsigned int size = len;
+ bool burst_read = len > gmbus_max_xfer_size(dev_priv);
+ bool extra_byte_added = false;
+
+ if (burst_read) {
+
+ /*
+* As per HW Spec, for 512Bytes need to read extra Byte and
+* Ignore the extra byte read.
+*/
+ if (len == 512) {
+ extra_byte_added = true;
+ len++;
+ }
+ size = len % 256 + 256;
+ I915_WRITE_FW(GMBUS0, gmbus0_reg | GMBUS_BYTE_CNT_OVERRIDE);
+ }
+
I915_WRITE_FW(GMBUS1,
gmbus1_index |
GMBUS_CYCLE_WAIT |
- (len << GMBUS_BYTE_COUNT_SHIFT) |
+ (size << GMBUS_BYTE_COUNT_SHIFT) |
(addr << GMBUS_SLAVE_ADDR_SHIFT) |
GMBUS_SLAVE_READ | GMBUS_SW_RDY);
while (len) {
@@ -389,17 +407,34 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
val = I915_READ_FW(GMBUS3);
do {
+ if (extra_byte_added && len == 1)
+ break;
+
*buf++ = val & 0xff;
val >>= 8;
} while (--len && ++loop < 4);
+
+ if (burst_read && len == size - 4)
+ /* Reset the override bit */
+ I915_WRITE_FW(GMBUS0, gmbus0_reg);
}
return 0;
}
+/*
+ * HW spec says that 512Bytes in Burst read need special treatment.
+ * But it doesn't talk about other multiple of 256Bytes. And couldn't locate
+ * an I2C slave, which supports such a lengthy burst read too for experiments.
+ *
+ * So until things get clarified on HW support, to avoid the burst read length
+ * in fold of 256Bytes except 512, max burst read length is fixed at 767Bytes.
+ */
+#define INTEL_GMBUS_BURST_READ_MAX_LEN 767U
+
static int
gmbus_xfer_read(struct drm_i915_private *dev_priv, struct i2c_msg *msg,
- u32 gmbus1_index)
+ u32 gmbus0_reg, u32 gmbus1_index)
{
u8 *buf = msg->buf;
unsigned int rx_size = msg->len;
@@ -407,10 +442,13 @@ gmbus_xfer_read(struct drm_i915_private *dev_priv, struct
i2c_msg *msg,
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Flush the RING stop bit after clearing RING_HEAD in reset
On 17/05/2018 15:24, Chris Wilson wrote:
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1)
<7>[ 239.094848] i915_gem_set_wedged Requests:
<7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f]
prio=1024 @ 5159ms: (null)
<7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a]
prio=139 @ 5159ms: igt/rcs0[5977]/1
<7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f]
prio=1024 @ 5159ms: (null)
<7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280,
tail 02a8, batch 0x_]
<7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000
<7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8
<7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8
<7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8
<7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10
<7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000
<7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260
<7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8
<7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001
<7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle]
<7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe
<7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c
<7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d
<7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260
<7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x
<7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280
<7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 0002
<7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write
5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled)
<7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1,
ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null)
<7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1,
ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1
<7>[ 239.100135] i915_gem_set_wedged HW active? 0x5
<7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @
5164ms: (null)
<7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139 @
5164ms: igt/rcs0[5977]/1
<7>[ 239.100340] i915_gem_set_wedged Queue priority: 139
<7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @
5164ms: igt/rcs0[5977]/8
<7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @
5165ms: igt/rcs0[5977]/2
<7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @
5165ms: igt/rcs0[5977]/3
<7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @
5164ms: igt/rcs0[5977]/2
<7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @
5165ms: igt/rcs0[5977]/4
<7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for 19a99
where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET!
The RING_MODE indicates that is idle and has the STOP_RING bit set, so
try clearing it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index b36a3b5736a0..082b0045ac8c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1720,6 +1720,8 @@ static void gen3_stop_engine(struct intel_engine_cs
*engine)
if (I915_READ_FW(RING_HEAD(base)) != 0)
DRM_DEBUG_DRIVER("%s: ring head not parked\n",
engine->name);
+
+ I915_WRITE_FW(RING_MI_MODE(base), _MASKED_BIT_DISABLE(STOP_RING));
}
static void i915_stop_engines(struct drm_i915_private *dev_priv,
Right, so expectation is after reset STOP_RING will not be set, but it
sometimes is?
Should we also add a notice or info if it is set in intel_gpu_reset,
after the reset is called? Could add i915_check_engine_running(..)
helper or something.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/psr: vbt change for psr (rev8)
== Series Details ==
Series: drm/i915/psr: vbt change for psr (rev8)
URL : https://patchwork.freedesktop.org/series/41289/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
46adf06c3a05 drm/i915/psr: vbt change for psr
-:79: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#79: FILE: drivers/gpu/drm/i915/i915_reg.h:4091:
+#define EDP_PSR2_TP2_TIME_500us (0<<8)
^
-:80: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#80: FILE: drivers/gpu/drm/i915/i915_reg.h:4092:
+#define EDP_PSR2_TP2_TIME_100us (1<<8)
^
-:81: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#81: FILE: drivers/gpu/drm/i915/i915_reg.h:4093:
+#define EDP_PSR2_TP2_TIME_2500us (2<<8)
^
-:82: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#82: FILE: drivers/gpu/drm/i915/i915_reg.h:4094:
+#define EDP_PSR2_TP2_TIME_50us (3<<8)
^
-:132: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#132: FILE: drivers/gpu/drm/i915/intel_bios.c:714:
+ if (psr_table->tp1_wakeup_time < 0 ||
+ psr_table->tp1_wakeup_time > 3) {
-:134: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#134: FILE: drivers/gpu/drm/i915/intel_bios.c:716:
+ DRM_DEBUG_KMS("VBT tp1 wakeup time value %d is outside
range[0-3], defaulting to max value 2500us\n",
+ psr_table->tp1_wakeup_time);
-:137: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#137: FILE: drivers/gpu/drm/i915/intel_bios.c:719:
+ if (psr_table->tp2_tp3_wakeup_time < 0 ||
+ psr_table->tp2_tp3_wakeup_time > 3) {
-:139: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#139: FILE: drivers/gpu/drm/i915/intel_bios.c:721:
+ DRM_DEBUG_KMS("VBT tp2_tp3 wakeup time value %d is
outside range[0-3], defaulting to max value 2500us\n",
+ psr_table->tp2_tp3_wakeup_time);
-:143: WARNING:LONG_LINE: line over 100 characters
#143: FILE: drivers/gpu/drm/i915/intel_bios.c:725:
+ dev_priv->vbt.psr.tp1_wakeup_time_us =
vbt_psr_to_us(is_waketime_options, psr_table->tp1_wakeup_time);
-:144: WARNING:LONG_LINE: line over 100 characters
#144: FILE: drivers/gpu/drm/i915/intel_bios.c:726:
+ dev_priv->vbt.psr.tp2_tp3_wakeup_time_us =
vbt_psr_to_us(is_waketime_options, psr_table->tp2_tp3_wakeup_time);
total: 0 errors, 2 warnings, 8 checks, 137 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/gmbus: Enable burst read
As per the discussion at #intel-gfx IRC, I have submitted v5 with the
max burst read length fixed to 767Bytes. Gist of the discussion: As per
HW spec HW supports burst for all the msg length above 511Bytes. But for
512 there is a special handling. Reasoning for this special handling is
not clear. because of this we are not sure whether other msg lengths in
multiples of 256 also will have problem or not. As of now, In real world
we couldn't have an I2C slave on DDC Bus whoc an provide msgs of
>511Bytes. Except 534Byte HDCP2.2 Cert Msg. So it is not possible to
test and confirm the HW capability for n*256Bytes where as n is >= 3. so
until we get further clarity, we are limiting the burst read support to
the msgs of length 512Bytes to 767Bytes. --Ram
On Wednesday 09 May 2018 07:15 PM, Ramalingam C wrote:
Support for Burst read in HW is added for HDCP2.2 compliance
requirement.
This patch enables the burst read for all the gmbus read of more than
511Bytes, on capable platforms.
v2:
Extra line is removed.
v3:
Macro is added for detecting the BURST_READ Support [Jani]
Runtime detection of the need for burst_read [Jani]
Calculation enhancement.
v4:
GMBUS0 reg val is passed from caller [ville]
Removed a extra var [ville]
Extra brackets are removed [ville]
Implemented the handling of 512Bytes Burst Read.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_i2c.c | 52
3 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 028691108125..14293fc1a142 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2552,6 +2552,9 @@ intel_info(const struct drm_i915_private *dev_priv)
*/
#define HAS_AUX_IRQ(dev_priv) true
#define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
+#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
+ IS_GEMINILAKE(dev_priv) || \
+ IS_KABYLAKE(dev_priv))
/* With the 945 and later, Y tiling got adjusted so that it was 32 128-byte
* rows, which changed the alignment requirements and fence programming.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index df998c10c48e..1166a24aff48 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2996,6 +2996,7 @@ enum i915_power_well_id {
#define GMBUS_RATE_400KHZ (2<<8) /* reserved on Pineview */
#define GMBUS_RATE_1MHZ (3<<8) /* reserved on Pineview */
#define GMBUS_HOLD_EXT (1<<7) /* 300ns hold time, rsvd on Pineview */
+#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
#define GMBUS_PIN_DISABLED 0
#define GMBUS_PIN_SSC 1
#define GMBUS_PIN_VGADDC2
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 1c0f6b56b209..2b59f8db42f2 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -371,12 +371,30 @@ unsigned int gmbus_max_xfer_size(struct drm_i915_private
*dev_priv)
static int
gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
unsigned short addr, u8 *buf, unsigned int len,
- u32 gmbus1_index)
+ u32 gmbus0_reg, u32 gmbus1_index)
{
+ unsigned int size = len;
+ bool burst_read = len > gmbus_max_xfer_size(dev_priv);
+ bool extra_byte_added = false;
+
+ if (burst_read) {
+
+ /*
+* As per HW Spec, for 512Bytes need to read extra Byte and
+* Ignore the extra byte read.
+*/
+ if (len == 512) {
+ extra_byte_added = true;
+ len++;
+ }
+ size = len % 256 + 256;
+ I915_WRITE_FW(GMBUS0, gmbus0_reg | GMBUS_BYTE_CNT_OVERRIDE);
+ }
+
I915_WRITE_FW(GMBUS1,
gmbus1_index |
GMBUS_CYCLE_WAIT |
- (len << GMBUS_BYTE_COUNT_SHIFT) |
+ (size << GMBUS_BYTE_COUNT_SHIFT) |
(addr << GMBUS_SLAVE_ADDR_SHIFT) |
GMBUS_SLAVE_READ | GMBUS_SW_RDY);
while (len) {
@@ -389,9 +407,16 @@ gmbus_xfer_read_chunk(struct drm_i915_private *dev_priv,
val = I915_READ_FW(GMBUS3);
do {
+ if (extra_byte_added && len == 1)
+ break;
+
*buf++ = val & 0xff;
val >>= 8;
} while (--len && ++loop < 4);
+
+ if (burst_read && len == size - 4)
+ /* Reset the override bit */
+ I915_WRITE_FW(GMBUS0, gmbus0_reg);
}
return 0;
@@ -399,7 +424,7
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Flush the RING stop bit after clearing RING_HEAD in reset
Quoting Tvrtko Ursulin (2018-05-18 10:33:44)
>
> On 17/05/2018 15:24, Chris Wilson wrote:
> > Inside the live_hangcheck (reset) selftests, we occasionally see
> > failures like
> >
> > <7>[ 239.094840] i915_gem_set_wedged rcs0
> > <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last
> > 19a9a, hangcheck 0 [5158 ms]
> > <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1)
> > <7>[ 239.094848] i915_gem_set_wedged Requests:
> > <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f]
> > prio=1024 @ 5159ms: (null)
> > <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a]
> > prio=139 @ 5159ms: igt/rcs0[5977]/1
> > <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f]
> > prio=1024 @ 5159ms: (null)
> > <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix
> > 0280, tail 02a8, batch 0x_]
> > <7>[ 239.100050] i915_gem_set_wedged ring->start:
> > 0x00283000
> > <7>[ 239.100053] i915_gem_set_wedged ring->head:
> > 0x01f8
> > <7>[ 239.100055] i915_gem_set_wedged ring->tail:
> > 0x02a8
> > <7>[ 239.100057] i915_gem_set_wedged ring->emit:
> > 0x02a8
> > <7>[ 239.100059] i915_gem_set_wedged ring->space:
> > 0x0f10
> > <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000
> > <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260
> > <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8
> > <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001
> > <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle]
> > <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe
> > <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c
> > <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d
> > <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260
> > <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x
> > <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280
> > <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052
> > 0002
> > <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5
> > cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no
> > (enabled)
> > <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1,
> > ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null)
> > <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1,
> > ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1
> > <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5
> > <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f]
> > prio=1024 @ 5164ms: (null)
> > <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a]
> > prio=139 @ 5164ms: igt/rcs0[5977]/1
> > <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139
> > <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132
> > @ 5164ms: igt/rcs0[5977]/8
> > <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121
> > @ 5165ms: igt/rcs0[5977]/2
> > <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82
> > @ 5165ms: igt/rcs0[5977]/3
> > <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44
> > @ 5164ms: igt/rcs0[5977]/2
> > <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20
> > @ 5165ms: igt/rcs0[5977]/4
> > <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting
> > for 19a99
> >
> > where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET!
> > The RING_MODE indicates that is idle and has the STOP_RING bit set, so
> > try clearing it.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_uncore.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > b/drivers/gpu/drm/i915/intel_uncore.c
> > index b36a3b5736a0..082b0045ac8c 100644
> > --- a/drivers/gpu/drm/i915/intel_uncore.c
> > +++ b/drivers/gpu/drm/i915/intel_uncore.c
> > @@ -1720,6 +1720,8 @@ static void gen3_stop_engine(struct intel_engine_cs
> > *engine)
> > if (I915_READ_FW(RING_HEAD(base)) != 0)
> > DRM_DEBUG_DRIVER("%s: ring head not parked\n",
> >engine->name);
> > +
> > + I915_WRITE_FW(RING_MI_MODE(base), _MASKED_BIT_DISABLE(STOP_RING));
> > }
> >
> > static void i915_stop_engines(struct drm_i915_private *dev_priv,
> >
>
> Right, so expectation is after reset STOP_RING will not be set, but it
> sometimes is?
Yes.
> Should we also add a notice or info if it is set in intel_gpu_reset,
> after the reset is called? Could add i915_check_engine
Re: [Intel-gfx] DRM Inquiry
On Thu, 17 May 2018, John Sledge wrote: > I’ve been doing some PTN3460 programming under Linux using C/C++ and I > have some questions regarding on setting the brightness level to my > display device. > > The display device with PTN3460 is connected in DP (display port) to > my computer. Only needs a DisplayPort native AUX command to access > DPCD address from PTN3460. I’m currently looking into the DRM (Direct > Rendering Manager) a subsystem of the Linux kernel. It has a methods > drm_dp_dpcd_readb, drm_dp_dpcd_read and drm_dp_dpcd_write. > > Do you have any suggestions or advice how to use the kernel driver in > DRM in regards to how to implement the method drm_dp_dpcd_readb for > example? I couldn't not find any test tool examples that implement > it. Biggest concern is I don't have sufficient knowledge where to > start what to code using the DRM module. Let me double check, you're talking about doing DPCD access from userspace? The *only* interface that can be recommended for that is the DRM DP AUX interface. If you have kernel config DRM_DP_AUX_CHARDEV=y, you'll get /dev/drm_dp_auxN node(s) that allows you to read and write arbitrary DPCD offsets. It's a chardev; you can use e.g. dd to debug read DPCD. Of course, it would be better to have a generic backlight interface for DPCD based backlight in kernel. We have the basics for that for Intel GPU in i915/intel_dp_aux_backlight.c. Granted, it should be moved to common DRM code, but it also doesn't work for you if you have the chip connected to regular DP. It expects eDP, and somewhat spec compliant eDP DPCD backlight support. HTH, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: vbt change for psr (rev8)
== Series Details == Series: drm/i915/psr: vbt change for psr (rev8) URL : https://patchwork.freedesktop.org/series/41289/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4204 -> Patchwork_9044 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41289/revisions/8/mbox/ == Known issues == Here are the changes found in Patchwork_9044 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) igt@kms_psr_sink_crc@basic: fi-elk-e7500: SKIP -> INCOMPLETE (fdo#103989) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (42 -> 39) == Additional (1): fi-byt-j1900 Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4204 -> Patchwork_9044 CI_DRM_4204: 1bffedaef627748248914f5a043e379fee0b121d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9044: 46adf06c3a05a9975ff258f3e786bd31c79173e1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Linux commits == 46adf06c3a05 drm/i915/psr: vbt change for psr == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9044/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Flush the RING stop bit after clearing RING_HEAD in reset
On 18/05/2018 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 10:33:44)
On 17/05/2018 15:24, Chris Wilson wrote:
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1)
<7>[ 239.094848] i915_gem_set_wedged Requests:
<7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f]
prio=1024 @ 5159ms: (null)
<7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a]
prio=139 @ 5159ms: igt/rcs0[5977]/1
<7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f]
prio=1024 @ 5159ms: (null)
<7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280,
tail 02a8, batch 0x_]
<7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000
<7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8
<7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8
<7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8
<7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10
<7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000
<7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260
<7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8
<7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001
<7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle]
<7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe
<7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c
<7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d
<7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260
<7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x
<7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280
<7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052
0002
<7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached],
write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled)
<7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1,
ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null)
<7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1,
ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1
<7>[ 239.100135] i915_gem_set_wedged HW active? 0x5
<7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f]
prio=1024 @ 5164ms: (null)
<7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139
@ 5164ms: igt/rcs0[5977]/1
<7>[ 239.100340] i915_gem_set_wedged Queue priority: 139
<7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @
5164ms: igt/rcs0[5977]/8
<7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @
5165ms: igt/rcs0[5977]/2
<7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @
5165ms: igt/rcs0[5977]/3
<7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @
5164ms: igt/rcs0[5977]/2
<7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @
5165ms: igt/rcs0[5977]/4
<7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for
19a99
where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET!
The RING_MODE indicates that is idle and has the STOP_RING bit set, so
try clearing it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index b36a3b5736a0..082b0045ac8c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1720,6 +1720,8 @@ static void gen3_stop_engine(struct intel_engine_cs
*engine)
if (I915_READ_FW(RING_HEAD(base)) != 0)
DRM_DEBUG_DRIVER("%s: ring head not parked\n",
engine->name);
+
+ I915_WRITE_FW(RING_MI_MODE(base), _MASKED_BIT_DISABLE(STOP_RING));
}
static void i915_stop_engines(struct drm_i915_private *dev_priv,
Right, so expectation is after reset STOP_RING will not be set, but it
sometimes is?
Yes.
Should we also add a notice or info if it is set in intel_gpu_reset,
after the reset is called? Could add i915_check_engine_running(..)
helper or something.
Could do, will be any more useful than the dump we give above? ;)
I think so - it would immediately and clearly say reset did not go to
plan and bad things could follow. (While the hangcheck dump above makes
requires one to think and analyse.)
Also, is stuck STOP_RING bit the only
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GMBUS changes (rev5)
== Series Details ==
Series: GMBUS changes (rev5)
URL : https://patchwork.freedesktop.org/series/41632/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cc8aaf86e7e8 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
f91237f2fdac drm/i915/gmbus: Enable burst read
-:36: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible
side-effects?
#36: FILE: drivers/gpu/drm/i915/i915_drv.h:2573:
+#define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
+ IS_GEMINILAKE(dev_priv) || \
+ IS_KABYLAKE(dev_priv))
-:50: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV)
#50: FILE: drivers/gpu/drm/i915/i915_reg.h:2999:
+#define GMBUS_BYTE_CNT_OVERRIDE (1<<6)
^
-:70: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#70: FILE: drivers/gpu/drm/i915/intel_i2c.c:381:
+ if (burst_read) {
+
total: 0 errors, 0 warnings, 3 checks, 131 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/lvds: Move acpi lid notification registration to registration phase
On Fri, 18 May 2018, Chris Wilson wrote:
> Delay registering ourselves with the acpi lid notification mechansim
> until we are registering the connectors after initialisation is
> complete. This prevents a possibilty of trying to handle the lid
> notification before we are ready with the danger of chasing
> uninitialised function pointers.
>
> BUG: unable to handle kernel NULL pointer dereference at
> IP: (null)
> PGD 0 P4D 0
> Oops: 0010 [#1] PREEMPT SMP PTI
> Modules linked in: arc4(+) iwldvm(+) i915(+) mac80211 i2c_algo_bit coretemp
> mei_wdt iwlwifi drm_kms_helper kvm_intel wmi_bmof iTCO_wdt
> iTCO_vendor_support kvm snd_hda_codec_conexant snd_hda_codec_generic drm
> psmouse cfg80211 irqbypass input_leds pcspkr i2c_i801 snd_hda_intel
> snd_hda_codec thinkpad_acpi snd_hda_core mei_me lpc_ich snd_hwdep e1000e wmi
> nvram snd_pcm mei snd_timer shpchp ptp pps_core rfkill syscopyarea snd
> intel_agp sysfillrect intel_gtt soundcore sysimgblt battery led_class
> fb_sys_fops ac rtc_cmos agpgart evdev mac_hid acpi_cpufreq ip_tables x_tables
> ext4 crc32c_generic crc16 mbcache jbd2 fscrypto crypto_simd glue_helper
> cryptd aes_x86_64 xts algif_skcipher af_alg dm_crypt dm_mod sd_mod uas
> usb_storage serio_raw atkbd libps2 ahci libahci uhci_hcd libata scsi_mod
> ehci_pci
> ehci_hcd usbcore usb_common i8042 serio
> CPU: 1 PID: 378 Comm: systemd-logind Not tainted 4.16.8-1-ARCH #1
> Hardware name: LENOVO 7454CTO/7454CTO, BIOS 6DET72WW (3.22 ) 10/25/2012
> RIP: 0010: (null)
> RSP: 0018:af4580c33a18 EFLAGS: 00010287
> RAX: RBX: 947533558000 RCX: 003e
> RDX: c0aa80c0 RSI: af4580c33a3c RDI: 947534e4c000
> RBP: 947533558338 R08: 947534598930 R09: c0a928b1
> R10: d8f181d5fd40 R11: R12: c0a928b1
> R13: 947533558368 R14: c0a928a9 R15: 947534e4c000
> FS: 7f3dc4ddb940() GS:94753928() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: CR3: 6e214000 CR4: 000406e0
> Call Trace:
> ? intel_modeset_setup_hw_state+0x385/0xf60 [i915]
> ? __intel_display_resume+0x1e/0xc0 [i915]
> ? intel_display_resume+0xcc/0x120 [i915]
> ? intel_lid_notify+0xbc/0xc0 [i915]
> ? notifier_call_chain+0x47/0x70
> ? blocking_notifier_call_chain+0x3e/0x60
> ? acpi_lid_notify_state+0x8f/0x1d0
> ? acpi_lid_update_state+0x49/0x70
> ? acpi_lid_input_open+0x60/0x90
> ? input_open_device+0x5d/0xa0
> ? evdev_open+0x1ba/0x1e0 [evdev]
> ? chrdev_open+0xa3/0x1b0
> ? cdev_put.part.0+0x20/0x20
> ? do_dentry_open+0x14c/0x300
> ? path_openat+0x30c/0x1240
> ? current_time+0x16/0x60
> ? do_filp_open+0x93/0x100
> ? __check_object_size+0xfb/0x180
> ? do_sys_open+0x186/0x210
> ? do_syscall_64+0x74/0x190
> ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> Code: Bad RIP value.
> RIP: (null) RSP: af4580c33a18
> CR2:
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106559
> Signed-off-by: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
Cc: sta...@vger.kernel.org ?
Fixes: ?
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_lvds.c | 43 +++
> 1 file changed, 32 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index 8691c86f579c..a844d48e6731 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -574,6 +574,36 @@ static int intel_lid_notify(struct notifier_block *nb,
> unsigned long val,
> return NOTIFY_OK;
> }
>
> +static int
> +intel_lvds_connector_register(struct drm_connector *connector)
> +{
> + struct intel_lvds_connector *lvds = to_lvds_connector(connector);
> + int ret;
> +
> + ret = intel_connector_register(connector);
> + if (ret)
> + return ret;
> +
> + lvds->lid_notifier.notifier_call = intel_lid_notify;
> + if (acpi_lid_notifier_register(&lvds->lid_notifier)) {
> + DRM_DEBUG_KMS("lid notifier registration failed\n");
> + lvds->lid_notifier.notifier_call = NULL;
> + }
> +
> + return 0;
> +}
> +
> +static void
> +intel_lvds_connector_unregister(struct drm_connector *connector)
> +{
> + struct intel_lvds_connector *lvds = to_lvds_connector(connector);
> +
> + if (lvds->lid_notifier.notifier_call)
> + acpi_lid_notifier_unregister(&lvds->lid_notifier);
> +
> + intel_connector_unregister(connector);
> +}
> +
> /**
> * intel_lvds_destroy - unregister and free LVDS structures
> * @connector: connector to free
> @@ -586,9 +616,6 @@ static void intel_lvds_destroy(struct drm_connector
> *connector)
> struct intel_lvds_connector *lvds_connector =
> to_lvds_connector(connector);
>
> - if (lvds_connector->lid_notifier.n
Re: [Intel-gfx] [PATCH 1/4] drm/mm: Reject over-sized allocation requests early
Quoting Chris Wilson (2018-05-13 10:50:07) > As we keep an rbtree of available holes sorted by their size, we can > very easily determine if there is any hole large enough that might > satisfy the allocation request. This helps when dealing with a highly > fragmented address space and a request for a search by address. > > To cache the largest size, we convert into the cached rbtree variant > which tracks the leftmost node for us. However, currently we sorted into > ascending size order so the leftmost node is the smallest, and so to > make it the largest hole we need to invert our sorting. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for GMBUS changes (rev5)
== Series Details == Series: GMBUS changes (rev5) URL : https://patchwork.freedesktop.org/series/41632/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/gmbus: Increase the Bytes per Rd/Wr Op -O:drivers/gpu/drm/i915/intel_i2c.c:403:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_i2c.c:465:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:472:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:472:23: warning: expression using sizeof(void) Commit: drm/i915/gmbus: Enable burst read -O:drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_i2c.c:410:23: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:446:31: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:448:31: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_i2c.c:448:31: warning: expression using sizeof(void) -drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3667:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Reject NV12 planes with odd width/start position
Planes with an odd width will appear to have an incorrect
stride. When the start position is odd the controller
can lock up.
Signed-off-by: Fritz Koenig
---
Hi,
This appears to be a limitation of the hardware that is not being
checked. Is this supported and am I not enabling it correctly?
drivers/gpu/drm/i915/intel_atomic_plane.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 7481ce85746b..ca4553592ab9 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -188,6 +188,21 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
else
crtc_state->active_planes &= ~BIT(intel_plane->id);
+ /*
+* NV12 plane is not allowed to start from an odd position or
+* end on an odd position.
+*/
+ if (state->fb && (DRM_FORMAT_NV12 == state->fb->format->format)) {
+ if ((intel_state->base.src_w >> 16) & 1) {
+ DRM_DEBUG_KMS("Invalid Source: Yuv format does not
support odd width\n");
+ return -EINVAL;
+ }
+ if ((intel_state->base.src_x >> 16) & 1) {
+ DRM_DEBUG_KMS("Invalid Source: Yuv format does not
support odd x pos\n");
+ return -EINVAL;
+ }
+ }
+
return intel_plane_atomic_calc_changes(old_crtc_state,
&crtc_state->base,
old_plane_state,
--
2.17.0.441.gb46fe60e1d-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Flush the RING stop bit after clearing RING_HEAD in reset
On 18/05/2018 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-05-18 10:33:44)
On 17/05/2018 15:24, Chris Wilson wrote:
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1)
<7>[ 239.094848] i915_gem_set_wedged Requests:
<7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f]
prio=1024 @ 5159ms: (null)
<7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a]
prio=139 @ 5159ms: igt/rcs0[5977]/1
<7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f]
prio=1024 @ 5159ms: (null)
<7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280,
tail 02a8, batch 0x_]
<7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000
<7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8
<7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8
<7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8
<7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10
<7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000
<7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260
<7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8
<7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001
<7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle]
<7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe
<7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c
<7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d
<7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260
<7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x
<7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280
<7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052
0002
<7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached],
write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled)
<7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1,
ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null)
<7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1,
ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1
<7>[ 239.100135] i915_gem_set_wedged HW active? 0x5
<7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f]
prio=1024 @ 5164ms: (null)
<7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139
@ 5164ms: igt/rcs0[5977]/1
<7>[ 239.100340] i915_gem_set_wedged Queue priority: 139
<7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @
5164ms: igt/rcs0[5977]/8
<7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @
5165ms: igt/rcs0[5977]/2
<7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @
5165ms: igt/rcs0[5977]/3
<7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @
5164ms: igt/rcs0[5977]/2
<7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @
5165ms: igt/rcs0[5977]/4
<7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for
19a99
where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET!
The RING_MODE indicates that is idle and has the STOP_RING bit set, so
try clearing it.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_uncore.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index b36a3b5736a0..082b0045ac8c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1720,6 +1720,8 @@ static void gen3_stop_engine(struct intel_engine_cs
*engine)
if (I915_READ_FW(RING_HEAD(base)) != 0)
DRM_DEBUG_DRIVER("%s: ring head not parked\n",
engine->name);
+
+ I915_WRITE_FW(RING_MI_MODE(base), _MASKED_BIT_DISABLE(STOP_RING));
}
static void i915_stop_engines(struct drm_i915_private *dev_priv,
Right, so expectation is after reset STOP_RING will not be set, but it
sometimes is?
Yes.
Also there is a comment in there which says engine must be stopped
before reset on some platforms. So shouldn't the manual attempt to
unstuck it go after the reset and not in gen3_stop_engine?
Like the suggested i915_check_engine_running:
if (stopped) {
DRM_NOTICE(Manually starting engine after reset);
clear_stop_ring;
}
?
Should we also add a notice or info if it is set in intel_gpu_reset,
after the reset is called? C
Re: [Intel-gfx] [PATCH 2/4] drm/mm: Add a search-by-address variant to only inspect a single hole
Quoting Chris Wilson (2018-05-13 10:50:08)
> Searching for an available hole by address is slow, as there no
> guarantee that a hole will be available and so we must walk over all
> nodes in the rbtree before we determine the search was futile. In many
> cases, the caller doesn't strictly care for the highest available hole
> and was just opportunistically laying out the address space in a
> preferred order. In such cases, the caller can accept any address and
> would rather do so then do a slow walk.
>
> To be able to mix search strategies, the caller wants to tell the drm_mm
> how long to spend on the search. Without a good guide for what should be
> the best split, start with a request to try once at most. That is return
> the top-most (or lowest) hole if it fulfils the alignment and size
> requirements.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> +++ b/include/drm/drm_mm.h
> @@ -109,6 +109,10 @@ enum drm_mm_insert_mode {
> * Allocates the node from the bottom of the found hole.
> */
> DRM_MM_INSERT_EVICT,
> +
Could definitely use a comment here.
Reviewed-by: Joonas Lahtinen
Regards, Joonas
> + DRM_MM_INSERT_END = BIT(31),
> + DRM_MM_INSERT_HIGHEST = DRM_MM_INSERT_HIGH | DRM_MM_INSERT_END,
> + DRM_MM_INSERT_LOWEST = DRM_MM_INSERT_LOW | DRM_MM_INSERT_END,
> };
>
> /**
> --
> 2.17.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH
Quoting Chris Wilson (2018-05-13 10:50:09)
> To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
> times), doing a search by address over a pathologically fragmented
> address space is exceeding slow. To protect ourselves from nearly
> unbounded latency (think searching a million holes while under
> struct_mutex), limit the search for the highest available hole and
> fallback to best-fit if it fails.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
Some testcase or measurement to quote before merging?
Code itself is;
Reviewed-by: Joonas Lahtinen
Regards, Joonas
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index c01d6dbe269a..cc9eb5956c44 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3967,7 +3967,7 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
>
> mode = DRM_MM_INSERT_BEST;
> if (flags & PIN_HIGH)
> - mode = DRM_MM_INSERT_HIGH;
> + mode = DRM_MM_INSERT_HIGHEST;
> if (flags & PIN_MAPPABLE)
> mode = DRM_MM_INSERT_LOW;
>
> @@ -3987,6 +3987,15 @@ int i915_gem_gtt_insert(struct i915_address_space *vm,
> if (err != -ENOSPC)
> return err;
>
> + if (mode & DRM_MM_INSERT_END) {
> + err = drm_mm_insert_node_in_range(&vm->mm, node,
> + size, alignment, color,
> + start, end,
> + DRM_MM_INSERT_BEST);
> + if (err != -ENOSPC)
> + return err;
> + }
> +
> if (flags & PIN_NOEVICT)
> return -ENOSPC;
>
> --
> 2.17.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Pin the ring high
Quoting Chris Wilson (2018-05-13 10:50:10) > If we can use an unmappable ring, try to pin it out of the mappable > aperture. This simple layout preference is to try and keep the mappable > aperture reserved and available to handle GGTT mmapping requests from > userspace without causing evictions and GPU stalls. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH
Quoting Joonas Lahtinen (2018-05-18 11:05:36) > Quoting Chris Wilson (2018-05-13 10:50:09) > > To no surprise (since we've flip-flopped over the use of PIN_HIGH a few > > times), doing a search by address over a pathologically fragmented > > address space is exceeding slow. To protect ourselves from nearly > > unbounded latency (think searching a million holes while under > > struct_mutex), limit the search for the highest available hole and > > fallback to best-fit if it fails. > > > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Some testcase or measurement to quote before merging? igt/gem_ctx_thrash goes from hours to seconds. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
Inside the live_hangcheck (reset) selftests, we occasionally see
failures like
<7>[ 239.094840] i915_gem_set_wedged rcs0
<7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a,
hangcheck 0 [5158 ms]
<7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1)
<7>[ 239.094848] i915_gem_set_wedged Requests:
<7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] prio=1024
@ 5159ms: (null)
<7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] prio=139
@ 5159ms: igt/rcs0[5977]/1
<7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] prio=1024
@ 5159ms: (null)
<7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280, tail
02a8, batch 0x_]
<7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000
<7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8
<7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8
<7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8
<7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10
<7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000
<7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260
<7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8
<7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001
<7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle]
<7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe
<7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c
<7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d
<7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260
<7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x
<7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280
<7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 0002
<7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write 5
[5 from hws], interrupt posted? no, tasklet queued? no (enabled)
<7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1,
ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null)
<7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1,
ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1
<7>[ 239.100135] i915_gem_set_wedged HW active? 0x5
<7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @
5164ms: (null)
<7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139 @
5164ms: igt/rcs0[5977]/1
<7>[ 239.100340] i915_gem_set_wedged Queue priority: 139
<7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @ 5164ms:
igt/rcs0[5977]/8
<7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @ 5165ms:
igt/rcs0[5977]/2
<7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @ 5165ms:
igt/rcs0[5977]/3
<7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @ 5164ms:
igt/rcs0[5977]/2
<7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @ 5165ms:
igt/rcs0[5977]/4
<7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for 19a99
where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET!
The RING_MODE indicates that is idle and has the STOP_RING bit set, so
try clearing it.
v2: Only clear the bit on restarting the ring, as we want to be sure the
STOP_RING bit is kept if reset fails on wedging.
v3: Spot when the ring state doesn't make sense when re-initialising the
engine and dump it to the logs so that we don't have to wait for an
error later and try to guess what happened earlier.
v4: Prepare to print all the unexpected state, not just the first.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3744f5750624..ba8411ba4abf 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1781,6 +1781,9 @@ static void enable_execlists(struct intel_engine_cs
*engine)
I915_WRITE(RING_MODE_GEN7(engine),
_MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+ I915_WRITE(RING_MI_MODE(engine->mmio_base),
+ _MASKED_BIT_DISABLE(STOP_RING));
+
I915_WRITE(RING_HWS_PGA(engine->mmio_base),
engine->status_page.ggtt_offset);
POSTING_READ(RING_HWS_PGA(engine->mmio_base));
@@ -1789,6 +1792,19 @@ static void enable_execlists(struct intel_engine_cs
*engine)
engine->execlists.csb_head = -1;
}
+static bool unexpected_starting_state(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *dev_priv = engine->i915;
+ bool unexpected = false;
+
+ if (I915_READ(RING_MI_MODE(engine->mmio_base)) & STOP_RING) {
+ DRM_DEBUG_DRIVER("STOP_RING still
[Intel-gfx] ✓ Fi.CI.BAT: success for GMBUS changes (rev5)
== Series Details == Series: GMBUS changes (rev5) URL : https://patchwork.freedesktop.org/series/41632/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4204 -> Patchwork_9045 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9045 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9045, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41632/revisions/5/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9045: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9045 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) Possible fixes igt@kms_flip@basic-flip-vs-wf_vblank: fi-cnl-psr: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (42 -> 39) == Additional (1): fi-byt-j1900 Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4204 -> Patchwork_9045 CI_DRM_4204: 1bffedaef627748248914f5a043e379fee0b121d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9045: f91237f2fdac166a3483e40ba7c673949c0057fe @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Linux commits == f91237f2fdac drm/i915/gmbus: Enable burst read cc8aaf86e7e8 drm/i915/gmbus: Increase the Bytes per Rd/Wr Op == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9045/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Store a pointer to intel_context in i915_request
On 2018.05.18 09:42:47 +0100, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2018-05-18 08:43:33) > > > > On 18/05/2018 04:21, Zhenyu Wang wrote: > > > On 2018.05.17 22:26:32 +0100, Chris Wilson wrote: > > >> To ease the frequent and ugly pointer dance of > > >> &request->gem_context->engine[request->engine->id] during request > > >> submission, store that pointer as request->hw_context. One major > > >> advantage that we will exploit later is that this decouples the logical > > >> context state from the engine itself. > > >> > > >> v2: Set mock_context->ops so we don't crash and burn in selftests. > > >> Cleanups from Tvrtko. > > >> > > >> Signed-off-by: Chris Wilson > > >> Cc: Tvrtko Ursulin > > >> --- > > >> drivers/gpu/drm/i915/gvt/mmio_context.c | 6 +- > > >> drivers/gpu/drm/i915/gvt/mmio_context.h | 2 +- > > >> drivers/gpu/drm/i915/gvt/scheduler.c | 141 +++--- > > >> drivers/gpu/drm/i915/gvt/scheduler.h | 1 - > > > > > > gvt change looks fine to me. > > > > > > Acked-by: Zhenyu Wang > > > > Excellent, thanks! > > > > And I think I already have my r-b earlier for non-GVT parts. So let me > > repeat it: > > > > Reviewed-by: Tvrtko Ursulin > > Thanks. Applied, please yell if I broke anything, or better yet donate > some machines to testing intel-gfx@ :) Well, looks it does break guest boot, patch mail is following. ;) I do like to have gvt regression test for CI at least for easy case e.g VM boot normal and better instruct some igt cases after boot. If that's just machine resource issue, I can raise to mangement to see if anyone can help. > > There will be a few more changes to make struct intel_context a first > class citizen for i915_request if Tvrtko manages to whip me or the api > into shape. So expect a little more upheaval in the coming months. > I'm thinking an api like: > > ce = intel_context_get_and_lock(context, engine); > > rq = i915_request_get(ce); > ... > i915_request_add(rq); > > intel_context_put_and_unlock(ce); > > (get_and_lock() is a helper around _get() and _lock()) > > In the gvt case, I expect you will want to manage your intel_contexts > explicitly as the ref/pin/locked phases is slightly longer for you than > the typical construct-a-request used elsewhere. Note also that the goal > is to replace the struct_mutex with fine grained locks. yeah, looks we do need better refactor for those request/context preparation and shadowing steps, even we've tried twice. -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gvt: Fix crash after request->hw_context change
When we do shadowing, workload's request might not be allocated yet,
so we still require shadow context's object. And when complete workload,
delay to zero workload's request pointer after used for update guest context.
Fixes: 1fc44d9b1afb ("drm/i915: Store a pointer to intel_context in
i915_request")
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/scheduler.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 2efb723b90cb..00f79fc940da 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -125,8 +125,9 @@ static int populate_shadow_context(struct
intel_vgpu_workload *workload)
struct intel_vgpu *vgpu = workload->vgpu;
struct intel_gvt *gvt = vgpu->gvt;
int ring_id = workload->ring_id;
+ struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
struct drm_i915_gem_object *ctx_obj =
- workload->req->hw_context->state->obj;
+ shadow_ctx->__engine[ring_id].state->obj;
struct execlist_ring_context *shadow_ring_context;
struct page *page;
void *dst;
@@ -595,8 +596,6 @@ static int prepare_workload(struct intel_vgpu_workload
*workload)
return ret;
}
- update_shadow_pdps(workload);
-
ret = intel_vgpu_sync_oos_pages(workload->vgpu);
if (ret) {
gvt_vgpu_err("fail to vgpu sync oos pages\n");
@@ -615,6 +614,8 @@ static int prepare_workload(struct intel_vgpu_workload
*workload)
goto err_unpin_mm;
}
+ update_shadow_pdps(workload);
+
ret = prepare_shadow_batch_buffer(workload);
if (ret) {
gvt_vgpu_err("fail to prepare_shadow_batch_buffer\n");
@@ -825,7 +826,7 @@ static void complete_current_workload(struct intel_gvt
*gvt, int ring_id)
scheduler->current_workload[ring_id];
struct intel_vgpu *vgpu = workload->vgpu;
struct intel_vgpu_submission *s = &vgpu->submission;
- struct i915_request *rq;
+ struct i915_request *rq = workload->req;
int event;
mutex_lock(&vgpu->vgpu_lock);
@@ -835,7 +836,6 @@ static void complete_current_workload(struct intel_gvt
*gvt, int ring_id)
* switch to make sure request is completed.
* For the workload w/o request, directly complete the workload.
*/
- rq = fetch_and_zero(&workload->req);
if (rq) {
wait_event(workload->shadow_ctx_status_wq,
!atomic_read(&workload->shadow_ctx_active));
@@ -866,7 +866,7 @@ static void complete_current_workload(struct intel_gvt
*gvt, int ring_id)
intel_context_unpin(rq->hw_context);
mutex_unlock(&rq->i915->drm.struct_mutex);
- i915_request_put(rq);
+ i915_request_put(fetch_and_zero(&workload->req));
}
gvt_dbg_sched("ring id %d complete workload %p status %d\n",
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/lvds: Move acpi lid notification registration to registration phase
Quoting Jani Nikula (2018-05-18 10:59:02) > On Fri, 18 May 2018, Chris Wilson wrote: > > Delay registering ourselves with the acpi lid notification mechansim > > until we are registering the connectors after initialisation is > > complete. This prevents a possibilty of trying to handle the lid > > notification before we are ready with the danger of chasing > > uninitialised function pointers. > > > > BUG: unable to handle kernel NULL pointer dereference at > > IP: (null) > > PGD 0 P4D 0 > > Oops: 0010 [#1] PREEMPT SMP PTI > > Modules linked in: arc4(+) iwldvm(+) i915(+) mac80211 i2c_algo_bit > > coretemp mei_wdt iwlwifi drm_kms_helper kvm_intel wmi_bmof iTCO_wdt > > iTCO_vendor_support kvm snd_hda_codec_conexant snd_hda_codec_generic drm > > psmouse cfg80211 irqbypass input_leds pcspkr i2c_i801 snd_hda_intel > > snd_hda_codec thinkpad_acpi snd_hda_core mei_me lpc_ich snd_hwdep e1000e > > wmi nvram snd_pcm mei snd_timer shpchp ptp pps_core rfkill syscopyarea snd > > intel_agp sysfillrect intel_gtt soundcore sysimgblt battery led_class > > fb_sys_fops ac rtc_cmos agpgart evdev mac_hid acpi_cpufreq ip_tables > > x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto crypto_simd > > glue_helper cryptd aes_x86_64 xts algif_skcipher af_alg dm_crypt dm_mod > > sd_mod uas usb_storage serio_raw atkbd libps2 ahci libahci uhci_hcd libata > > scsi_mod ehci_pci > > ehci_hcd usbcore usb_common i8042 serio > > CPU: 1 PID: 378 Comm: systemd-logind Not tainted 4.16.8-1-ARCH #1 > > Hardware name: LENOVO 7454CTO/7454CTO, BIOS 6DET72WW (3.22 ) 10/25/2012 > > RIP: 0010: (null) > > RSP: 0018:af4580c33a18 EFLAGS: 00010287 > > RAX: RBX: 947533558000 RCX: 003e > > RDX: c0aa80c0 RSI: af4580c33a3c RDI: 947534e4c000 > > RBP: 947533558338 R08: 947534598930 R09: c0a928b1 > > R10: d8f181d5fd40 R11: R12: c0a928b1 > > R13: 947533558368 R14: c0a928a9 R15: 947534e4c000 > > FS: 7f3dc4ddb940() GS:94753928() > > knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: CR3: 6e214000 CR4: 000406e0 > > Call Trace: > > ? intel_modeset_setup_hw_state+0x385/0xf60 [i915] > > ? __intel_display_resume+0x1e/0xc0 [i915] > > ? intel_display_resume+0xcc/0x120 [i915] > > ? intel_lid_notify+0xbc/0xc0 [i915] > > ? notifier_call_chain+0x47/0x70 > > ? blocking_notifier_call_chain+0x3e/0x60 > > ? acpi_lid_notify_state+0x8f/0x1d0 > > ? acpi_lid_update_state+0x49/0x70 > > ? acpi_lid_input_open+0x60/0x90 > > ? input_open_device+0x5d/0xa0 > > ? evdev_open+0x1ba/0x1e0 [evdev] > > ? chrdev_open+0xa3/0x1b0 > > ? cdev_put.part.0+0x20/0x20 > > ? do_dentry_open+0x14c/0x300 > > ? path_openat+0x30c/0x1240 > > ? current_time+0x16/0x60 > > ? do_filp_open+0x93/0x100 > > ? __check_object_size+0xfb/0x180 > > ? do_sys_open+0x186/0x210 > > ? do_syscall_64+0x74/0x190 > > ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 > > Code: Bad RIP value. > > RIP: (null) RSP: af4580c33a18 > > CR2: > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106559 > > Signed-off-by: Chris Wilson > > Cc: Maarten Lankhorst > > Cc: Ville Syrjälä > > Cc: Daniel Vetter > > Cc: sta...@vger.kernel.org ? > Fixes: ? commit c1c7af60892070e4b82ad63bbfb95ae745056de0 Author: Jesse Barnes Date: Thu Sep 10 15:28:03 2009 -0700 drm/i915: force mode set at lid open time ? Would be a fair estimate, since even then we should have assumed we would be ready to respond to a very early notify. Except the infrastructure to delay registration didn't exist until much later. So probably cc:stable as we couldn't do much before commit aaf285e2e0ff490e924dbcdfd08e8274c3093354 Author: Chris Wilson Date: Wed Jun 15 13:17:47 2016 +0100 drm: Add a callback from connector registering anyway. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt: Fix crash after request->hw_context change
Quoting Zhenyu Wang (2018-05-18 11:13:05) > When we do shadowing, workload's request might not be allocated yet, > so we still require shadow context's object. And when complete workload, > delay to zero workload's request pointer after used for update guest context. Please allocate the context earlier then. The point is that until you do, shadow_ctx->__engine[ring_id]->state is *undefined* and this code is still illegal. :-p The intent is that you start tracking the lifetime of the state you are using because the assumptions made here will not hold for much longer. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/lvds: Move acpi lid notification registration to registration phase
== Series Details == Series: drm/i915/lvds: Move acpi lid notification registration to registration phase URL : https://patchwork.freedesktop.org/series/43390/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4203_full -> Patchwork_9042_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9042_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9042_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43390/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9042_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: SKIP -> PASS +3 == Known issues == Here are the changes found in Patchwork_9042_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@flip-vs-modeset-interruptible: shard-kbl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +19 igt@kms_flip_tiling@flip-x-tiled: shard-hsw: PASS -> DMESG-WARN (fdo#102614) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-hsw: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS igt@kms_flip@2x-flip-vs-blocking-wf-vblank: shard-glk: FAIL -> PASS igt@kms_flip@modeset-vs-vblank-race: shard-glk: FAIL (fdo#103060) -> PASS igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc: shard-glk: FAIL (fdo#104724, fdo#103167) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4203 -> Patchwork_9042 CI_DRM_4203: 76b6f2aaa6103e0c09fd87c3979aeb256a701615 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9042: 62b28ba957be6064cc05db5a50fc5f722713c7e0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9042/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Reject NV12 planes with odd width/start position
== Series Details == Series: drm/i915: Reject NV12 planes with odd width/start position URL : https://patchwork.freedesktop.org/series/43403/ State : failure == Summary == Applying: drm/i915: Reject NV12 planes with odd width/start position error: Failed to merge in the changes. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/intel_atomic_plane.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_atomic_plane.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_atomic_plane.c Patch failed at 0001 drm/i915: Reject NV12 planes with odd width/start position The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Limit searching for PIN_HIGH
Quoting Chris Wilson (2018-05-18 13:07:16) > Quoting Joonas Lahtinen (2018-05-18 11:05:36) > > Quoting Chris Wilson (2018-05-13 10:50:09) > > > To no surprise (since we've flip-flopped over the use of PIN_HIGH a few > > > times), doing a search by address over a pathologically fragmented > > > address space is exceeding slow. To protect ourselves from nearly > > > unbounded latency (think searching a million holes while under > > > struct_mutex), limit the search for the highest available hole and > > > fallback to best-fit if it fails. > > > > > > Signed-off-by: Chris Wilson > > > Cc: Joonas Lahtinen > > > > Some testcase or measurement to quote before merging? > > igt/gem_ctx_thrash goes from hours to seconds. Thats a good merit, do add it :) Regards, Joonas > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
== Series Details == Series: drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset URL : https://patchwork.freedesktop.org/series/43404/ State : warning == Summary == $ dim checkpatch origin/drm-tip e01c159ce05b drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] total: 0 errors, 1 warnings, 0 checks, 40 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix crash after request->hw_context change
== Series Details == Series: drm/i915/gvt: Fix crash after request->hw_context change URL : https://patchwork.freedesktop.org/series/43406/ State : failure == Summary == Applying: drm/i915/gvt: Fix crash after request->hw_context change error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gvt/scheduler.c). error: could not build fake ancestor Patch failed at 0001 drm/i915/gvt: Fix crash after request->hw_context change The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
== Series Details ==
Series: drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
URL : https://patchwork.freedesktop.org/series/43404/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4205 -> Patchwork_9047 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9047 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9047, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/43404/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9047:
=== IGT changes ===
Warnings
igt@gem_exec_gttfill@basic:
fi-pnv-d510:SKIP -> PASS
== Known issues ==
Here are the changes found in Patchwork_9047 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_frontbuffer_tracking@basic:
fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#102614, fdo#106103)
fi-hsw-peppy: PASS -> DMESG-FAIL (fdo#102614, fdo#106103)
Possible fixes
igt@kms_flip@basic-flip-vs-wf_vblank:
{fi-cfl-guc}: FAIL (fdo#103928) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928
fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103
== Participating hosts (43 -> 37) ==
Missing(6): fi-ilk-m540 fi-bxt-dsi fi-byt-j1900 fi-byt-squawks
fi-bsw-cyan fi-skl-6700hq
== Build changes ==
* Linux: CI_DRM_4205 -> Patchwork_9047
CI_DRM_4205: 921a7738e856643993ea0889dd5a936c22151649 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9047: e01c159ce05bb1471d058ca945d5d386a2fe9512 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @
git://anongit.freedesktop.org/piglit
== Linux commits ==
e01c159ce05b drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9047/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix crash after request->hw_context change
Quoting Patchwork (2018-05-18 11:55:01) > == Series Details == > > Series: drm/i915/gvt: Fix crash after request->hw_context change > URL : https://patchwork.freedesktop.org/series/43406/ > State : failure > > == Summary == > > Applying: drm/i915/gvt: Fix crash after request->hw_context change > error: sha1 information is lacking or useless > (drivers/gpu/drm/i915/gvt/scheduler.c). > error: could not build fake ancestor > Patch failed at 0001 drm/i915/gvt: Fix crash after request->hw_context change Wrong tree used as teh baseline, could you resend? Or an alternative to avoid dereferencing state outside of being pinned? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
On 18/05/2018 11:09, Chris Wilson wrote: Inside the live_hangcheck (reset) selftests, we occasionally see failures like <7>[ 239.094840] i915_gem_set_wedged rcs0 <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) <7>[ 239.094848] i915_gem_set_wedged Requests: <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280, tail 02a8, batch 0x_] <7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000 <7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8 <7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8 <7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8 <7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10 <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle] <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260 <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 0002 <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled) <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139 <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @ 5164ms: igt/rcs0[5977]/8 <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @ 5165ms: igt/rcs0[5977]/2 <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @ 5165ms: igt/rcs0[5977]/3 <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @ 5164ms: igt/rcs0[5977]/2 <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @ 5165ms: igt/rcs0[5977]/4 <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for 19a99 where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET! The RING_MODE indicates that is idle and has the STOP_RING bit set, so try clearing it. v2: Only clear the bit on restarting the ring, as we want to be sure the STOP_RING bit is kept if reset fails on wedging. v3: Spot when the ring state doesn't make sense when re-initialising the engine and dump it to the logs so that we don't have to wait for an error later and try to guess what happened earlier. v4: Prepare to print all the unexpected state, not just the first. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 3744f5750624..ba8411ba4abf 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1781,6 +1781,9 @@ static void enable_execlists(struct intel_engine_cs *engine) I915_WRITE(RING_MODE_GEN7(engine), _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE)); + I915_WRITE(RING_MI_MODE(engine->mmio_base), + _MASKED_BIT_DISABLE(STOP_RING)); Worries me a bit to clear it unconditionally since documentation says nothing (that I can find) about this scenario. + I915_WRITE(RING_HWS_PGA(engine->mmio_base), engine->status_page.ggtt_offset); POSTING_READ(RING_HWS_PGA(engine->mmio_base)); @@ -1789,6 +1792,19 @@ static void enable_execlists(struct intel_engine_cs *engine) engine->execlists.csb_head = -1; } +static bool unexpected_starting_state(struct
Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
Quoting Tvrtko Ursulin (2018-05-18 12:05:17) > > On 18/05/2018 11:09, Chris Wilson wrote: > > Inside the live_hangcheck (reset) selftests, we occasionally see > > failures like > > > > <7>[ 239.094840] i915_gem_set_wedged rcs0 > > <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last > > 19a9a, hangcheck 0 [5158 ms] > > <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) > > <7>[ 239.094848] i915_gem_set_wedged Requests: > > <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] > > prio=1024 @ 5159ms: (null) > > <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] > > prio=139 @ 5159ms: igt/rcs0[5977]/1 > > <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] > > prio=1024 @ 5159ms: (null) > > <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix > > 0280, tail 02a8, batch 0x_] > > <7>[ 239.100050] i915_gem_set_wedged ring->start: > > 0x00283000 > > <7>[ 239.100053] i915_gem_set_wedged ring->head: > > 0x01f8 > > <7>[ 239.100055] i915_gem_set_wedged ring->tail: > > 0x02a8 > > <7>[ 239.100057] i915_gem_set_wedged ring->emit: > > 0x02a8 > > <7>[ 239.100059] i915_gem_set_wedged ring->space: > > 0x0f10 > > <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 > > <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 > > <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 > > <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 > > <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle] > > <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe > > <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c > > <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d > > <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260 > > <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x > > <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 > > <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 > > 0002 > > <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 > > cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no > > (enabled) > > <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, > > ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) > > <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, > > ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 > > <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 > > <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] > > prio=1024 @ 5164ms: (null) > > <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] > > prio=139 @ 5164ms: igt/rcs0[5977]/1 > > <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139 > > <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 > > @ 5164ms: igt/rcs0[5977]/8 > > <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 > > @ 5165ms: igt/rcs0[5977]/2 > > <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 > > @ 5165ms: igt/rcs0[5977]/3 > > <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 > > @ 5164ms: igt/rcs0[5977]/2 > > <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 > > @ 5165ms: igt/rcs0[5977]/4 > > <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting > > for 19a99 > > > > where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET! > > The RING_MODE indicates that is idle and has the STOP_RING bit set, so > > try clearing it. > > > > v2: Only clear the bit on restarting the ring, as we want to be sure the > > STOP_RING bit is kept if reset fails on wedging. > > v3: Spot when the ring state doesn't make sense when re-initialising the > > engine and dump it to the logs so that we don't have to wait for an > > error later and try to guess what happened earlier. > > v4: Prepare to print all the unexpected state, not just the first. > > > > Signed-off-by: Chris Wilson > > Cc: Tvrtko Ursulin > > --- > > drivers/gpu/drm/i915/intel_lrc.c | 22 ++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > > b/drivers/gpu/drm/i915/intel_lrc.c > > index 3744f5750624..ba8411ba4abf 100644 > > --- a/drivers/gpu/drm/i915/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/intel_lrc.c > > @@ -1781,6 +1781,9 @@ static void enable_execlists(struct intel_engine_cs > > *engine) > > I915_WRITE(RING_MODE_GEN7(engine), > > _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE)); >
Re: [Intel-gfx] [PATCH 029/262] drm/i915: Track the purgeable objects on a separate eviction list
On 17 May 2018 at 07:03, Chris Wilson wrote:
> Currently the purgeable objects, I915_MADV_DONTNEED, as mixed in the
> normal bound/unbound lists. Every shrinker pass starts with an attempt
> to purge from this set of unneeded objects, which entails us doing a
> walk over both lists looking for any candidates. If there are none, and
> since we are shrinking we can reasonably assume that the lists are
> full!, this becomes a very slow futile walk.
>
> If we separate out the purgeable objects into own list, this search then
> becomes its own phase that is preferentially handled during shrinking.
> Instead the cost becomes that we then need to filter the purgeable list
> if we want to distinguish between bound and unbound objects.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 13 ---
> drivers/gpu/drm/i915/i915_gem.c | 49 ++--
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 28 +++---
> drivers/gpu/drm/i915/i915_vma.c | 2 +-
> 4 files changed, 60 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 56ffdd523893..1043e164 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -926,6 +926,10 @@ struct i915_gem_mm {
> * not actually have any pages attached.
> */
> struct list_head unbound_list;
> + /**
> +* List of objects which are purgeable. May be active.
> +*/
> + struct list_head purge_list;
>
> /** List of all objects in gtt_space, currently mmaped by userspace.
> * All objects within this list must also be on bound_list.
> @@ -3310,11 +3314,10 @@ unsigned long i915_gem_shrink(struct drm_i915_private
> *i915,
> unsigned long target,
> unsigned long *nr_scanned,
> unsigned flags);
> -#define I915_SHRINK_PURGEABLE 0x1
> -#define I915_SHRINK_UNBOUND 0x2
> -#define I915_SHRINK_BOUND 0x4
> -#define I915_SHRINK_ACTIVE 0x8
> -#define I915_SHRINK_VMAPS 0x10
> +#define I915_SHRINK_UNBOUND BIT(0)
> +#define I915_SHRINK_BOUND BIT(1)
> +#define I915_SHRINK_ACTIVE BIT(2)
> +#define I915_SHRINK_VMAPS BIT(3)
> unsigned long i915_gem_shrink_all(struct drm_i915_private *i915);
> void i915_gem_shrinker_register(struct drm_i915_private *i915);
> void i915_gem_shrinker_unregister(struct drm_i915_private *i915);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 42d95f6490f8..be3092a03722 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1672,8 +1672,6 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
> *data,
>
> static void i915_gem_object_bump_inactive_ggtt(struct drm_i915_gem_object
> *obj)
> {
> - struct drm_i915_private *i915;
> - struct list_head *list;
> struct i915_vma *vma;
>
> GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
> @@ -1688,11 +1686,16 @@ static void i915_gem_object_bump_inactive_ggtt(struct
> drm_i915_gem_object *obj)
> list_move_tail(&vma->vm_link, &vma->vm->inactive_list);
> }
>
> - i915 = to_i915(obj->base.dev);
> - spin_lock(&i915->mm.obj_lock);
> - list = obj->bind_count ? &i915->mm.bound_list :
> &i915->mm.unbound_list;
> - list_move_tail(&obj->mm.link, list);
> - spin_unlock(&i915->mm.obj_lock);
> + if (obj->mm.madv == I915_MADV_WILLNEED) {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct list_head *list;
> +
> + spin_lock(&i915->mm.obj_lock);
> + list = obj->bind_count ?
> + &i915->mm.bound_list : &i915->mm.unbound_list;
> + list_move_tail(&obj->mm.link, list);
> + spin_unlock(&i915->mm.obj_lock);
> + }
> }
>
> /**
> @@ -2531,7 +2534,7 @@ static int i915_gem_object_get_pages_gtt(struct
> drm_i915_gem_object *obj)
> sg_page_sizes = 0;
> for (i = 0; i < page_count; i++) {
> const unsigned int shrink[] = {
> - I915_SHRINK_BOUND | I915_SHRINK_UNBOUND |
> I915_SHRINK_PURGEABLE,
> + I915_SHRINK_BOUND | I915_SHRINK_UNBOUND,
> 0,
> }, *s = shrink;
> gfp_t gfp = noreclaim;
> @@ -4519,7 +4522,7 @@ int
> i915_gem_madvise_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file_priv)
> {
> - struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_madvise *args = data;
> struct drm_i915_gem_object *obj;
> int err;
> @@ -4542,7 +4545,7 @@ i915_gem_madvise_ioctl(struct drm_device *dev, void
> *data,
>
> if (i915_gem_object_has_pages(obj) &&
>
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915: Make intel_engine_dump irqsafe
== Series Details == Series: series starting with [CI,1/3] drm/i915: Make intel_engine_dump irqsafe URL : https://patchwork.freedesktop.org/series/43396/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4204_full -> Patchwork_9043_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9043_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9043_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43396/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9043_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP igt@gem_exec_schedule@deep-vebox: shard-kbl: SKIP -> PASS +1 igt@kms_cursor_crc@cursor-256x256-offscreen: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9043_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) +2 igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt: shard-kbl: PASS -> DMESG-WARN (fdo#103313, fdo#103558, fdo#105602) +3 igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-gtt: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) +26 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: shard-kbl: PASS -> DMESG-WARN (fdo#106247) igt@kms_frontbuffer_tracking@fbc-suspend: shard-kbl: PASS -> DMESG-WARN (fdo#103841, fdo#103558, fdo#105602) igt@kms_rotation_crc@primary-rotation-180: shard-hsw: PASS -> FAIL (fdo#104724, fdo#103925) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_flip@blocking-wf_vblank: shard-hsw: FAIL (fdo#103928) -> PASS igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +2 igt@kms_rotation_crc@primary-rotation-90: shard-apl: FAIL (fdo#104724, fdo#103925) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106247 https://bugs.freedesktop.org/show_bug.cgi?id=106247 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4204 -> Patchwork_9043 CI_DRM_4204: 1bffedaef627748248914f5a043e379fee0b121d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9043: 2f68093ce8d2ebf7c52166136c6e3e1ba948e561 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9043/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
On 18/05/2018 12:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 12:05:17) On 18/05/2018 11:09, Chris Wilson wrote: Inside the live_hangcheck (reset) selftests, we occasionally see failures like <7>[ 239.094840] i915_gem_set_wedged rcs0 <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) <7>[ 239.094848] i915_gem_set_wedged Requests: <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280, tail 02a8, batch 0x_] <7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000 <7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8 <7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8 <7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8 <7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10 <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle] <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260 <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 0002 <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled) <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139 <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @ 5164ms: igt/rcs0[5977]/8 <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @ 5165ms: igt/rcs0[5977]/2 <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @ 5165ms: igt/rcs0[5977]/3 <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @ 5164ms: igt/rcs0[5977]/2 <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @ 5165ms: igt/rcs0[5977]/4 <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for 19a99 where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET! The RING_MODE indicates that is idle and has the STOP_RING bit set, so try clearing it. v2: Only clear the bit on restarting the ring, as we want to be sure the STOP_RING bit is kept if reset fails on wedging. v3: Spot when the ring state doesn't make sense when re-initialising the engine and dump it to the logs so that we don't have to wait for an error later and try to guess what happened earlier. v4: Prepare to print all the unexpected state, not just the first. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 3744f5750624..ba8411ba4abf 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1781,6 +1781,9 @@ static void enable_execlists(struct intel_engine_cs *engine) I915_WRITE(RING_MODE_GEN7(engine), _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE)); + I915_WRITE(RING_MI_MODE(engine->mmio_base), +_MASKED_BIT_DISABLE(STOP_RING)); Worries me a bit to clear it unconditionally since documentation says nothing (that I can find) about this scenario. + I915_WRITE(RING_HWS_PGA(engine->mmio_base), engine->status_page.ggtt_offs
Re: [Intel-gfx] [PATCH 029/262] drm/i915: Track the purgeable objects on a separate eviction list
Quoting Matthew Auld (2018-05-18 12:36:30) > On 17 May 2018 at 07:03, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/i915_vma.c > > b/drivers/gpu/drm/i915/i915_vma.c > > index 9324d476e0a7..96039c4ef434 100644 > > --- a/drivers/gpu/drm/i915/i915_vma.c > > +++ b/drivers/gpu/drm/i915/i915_vma.c > > @@ -624,7 +624,7 @@ i915_vma_remove(struct i915_vma *vma) > > * no more VMAs exist. > > */ > > spin_lock(&i915->mm.obj_lock); > > - if (--obj->bind_count == 0) > > + if (--obj->bind_count == 0 && obj->mm.madv == I915_MADV_WILLNEED) > > How does this play with volatile objects, like gem object internal, > since they are DONTNEED while pinned? Not brilliant as they are left on the unbound_list rather than promoted to the purge_lit. They will still be reaped eventually, but I don't expect it to make any difference in practice (since they are either short lived shadow batches, or longer lived and quite-oft pinned ringbuffers). It really just means stop poking at mm.madv directly, and probably just make the decision to mark as purgeable from the start and play fewer games. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 28/40] drm/i915: Handle HDCP2.2 downstream topology change
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [PATCH v3 28/40] drm/i915: Handle HDCP2.2 downstream topology
>change
>
>When repeater notifies a downstream topology change, this patch
>reauthenticate the repeater alone with out disabling the hdcp encryption. If
>that
Don’t leave a space b/w with and out.
With that fix.
Reviewed-by: Uma Shankar
>fails then complete reauthentication is executed.
>
>v2:
> Rebased.
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index e2aec73aefe3..fd30e2b1ddc3 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -1497,8 +1497,23 @@ static int intel_hdcp2_check_link(struct
>intel_connector *connector)
> goto out;
> }
>
>- DRM_INFO("[%s:%d] HDCP2.2 link failed, retrying authentication\n",
>- connector->base.name, connector->base.base.id);
>+ if (ret == DRM_HDCP_TOPOLOGY_CHANGE) {
>+ if (hdcp->hdcp_value ==
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
>+ goto out;
>+
>+ DRM_DEBUG_KMS("HDCP2.2 Downstream topology change\n");
>+ ret = hdcp2_authenticate_repeater_topology(connector);
>+ if (!ret) {
>+ hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+ schedule_work(&hdcp->hdcp_prop_work);
>+ goto out;
>+ }
>+ DRM_ERROR("[%s:%d] Repeater topology auth failed.(%d)\n",
>+connector->base.name, connector->base.base.id, ret);
>+ } else {
>+ DRM_ERROR("[%s:%d] HDCP2.2 link failed, retrying auth\n",
>+ connector->base.name, connector->base.base.id);
>+ }
>
> ret = _intel_hdcp2_disable(connector);
> if (ret) {
>--
>2.7.4
>
>___
>dri-devel mailing list
>dri-de...@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP"
On Wed, 16 May 2018, Lucas De Marchi wrote:
> This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677.
>
> This fails on a Dell XPS13 9350 machine giving me just a black screen.
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane count = 4
> [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
> Training failed at link rate = 54, lane count = 4
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane count = 4
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane count = 4
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane count = 4
> [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
> Training failed at link rate = 54, lane count = 4
> [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
> Training failed at link rate = 54, lane count = 4
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane count = 4
> [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
> Training failed at link rate = 54, lane count = 4
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane count = 4
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane count = 4
> [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:59:eDP-1] Link
> Training failed at link rate = 54, lane count = 4
>
> On a working kernel, previous to this commit I have:
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> failed at link rate = 54, lane count = 4
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 27, Lane count = 4
We had this kind of issues *before* any link fallback, way back when we
just plunged on ignoring issues. Actually I imagined we were going to do
that for eDP when c0cfb10d9e1d ("drm/i915/edp: Do not do link training
fallback or prune modes on EDP") was introduced, but looks like we
don't.
Does this work? It might not, because way back we used to have a full
clock recovery step within channel eq error path, and that then worked
just fine.
BR,
Jani.
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 3fcaa98b9055..7315ee01f984 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -323,7 +323,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
- if (!intel_dp_link_training_clock_recovery(intel_dp))
+ if (!intel_dp_link_training_clock_recovery(intel_dp) &&
+ !intel_dp_is_edp(intel_dp))
goto failure_handling;
if (!intel_dp_link_training_channel_equalization(intel_dp))
goto failure_handling;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reject NV12 planes with odd width/start position
On Thu, May 17, 2018 at 12:07:14PM -0700, Fritz Koenig wrote:
> Planes with an odd width will appear to have an incorrect
> stride. When the start position is odd the controller
> can lock up.
Just remove the strange NV12 check from the %2 checks in
intel_check_sprite_plane()?
>
> Signed-off-by: Fritz Koenig
> ---
>
> Hi,
>
> This appears to be a limitation of the hardware that is not being
> checked. Is this supported and am I not enabling it correctly?
>
>
> drivers/gpu/drm/i915/intel_atomic_plane.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 7481ce85746b..ca4553592ab9 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -188,6 +188,21 @@ int intel_plane_atomic_check_with_state(const struct
> intel_crtc_state *old_crtc_
> else
> crtc_state->active_planes &= ~BIT(intel_plane->id);
>
> + /*
> + * NV12 plane is not allowed to start from an odd position or
> + * end on an odd position.
> + */
> + if (state->fb && (DRM_FORMAT_NV12 == state->fb->format->format)) {
> + if ((intel_state->base.src_w >> 16) & 1) {
> + DRM_DEBUG_KMS("Invalid Source: Yuv format does not
> support odd width\n");
> + return -EINVAL;
> + }
> + if ((intel_state->base.src_x >> 16) & 1) {
> + DRM_DEBUG_KMS("Invalid Source: Yuv format does not
> support odd x pos\n");
> + return -EINVAL;
> + }
> + }
> +
> return intel_plane_atomic_calc_changes(old_crtc_state,
> &crtc_state->base,
> old_plane_state,
> --
> 2.17.0.441.gb46fe60e1d-goog
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
Quoting Tvrtko Ursulin (2018-05-18 12:50:41) > > On 18/05/2018 12:10, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-05-18 12:05:17) > >> > >> On 18/05/2018 11:09, Chris Wilson wrote: > >>> Inside the live_hangcheck (reset) selftests, we occasionally see > >>> failures like > >>> > >>> <7>[ 239.094840] i915_gem_set_wedged rcs0 > >>> <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last > >>> 19a9a, hangcheck 0 [5158 ms] > >>> <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) > >>> <7>[ 239.094848] i915_gem_set_wedged Requests: > >>> <7>[ 239.095052] i915_gem_set_wedged first 19a99 > >>> [e8c:5f] prio=1024 @ 5159ms: (null) > >>> <7>[ 239.095056] i915_gem_set_wedged last 19a9a > >>> [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 > >>> <7>[ 239.095059] i915_gem_set_wedged active 19a99 > >>> [e8c:5f] prio=1024 @ 5159ms: (null) > >>> <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix > >>> 0280, tail 02a8, batch 0x_] > >>> <7>[ 239.100050] i915_gem_set_wedged ring->start: > >>> 0x00283000 > >>> <7>[ 239.100053] i915_gem_set_wedged ring->head: > >>> 0x01f8 > >>> <7>[ 239.100055] i915_gem_set_wedged ring->tail: > >>> 0x02a8 > >>> <7>[ 239.100057] i915_gem_set_wedged ring->emit: > >>> 0x02a8 > >>> <7>[ 239.100059] i915_gem_set_wedged ring->space: > >>> 0x0f10 > >>> <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 > >>> <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 > >>> <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 > >>> <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 > >>> <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 > >>> [idle] > >>> <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe > >>> <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c > >>> <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d > >>> <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: > >>> 0x_00283260 > >>> <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x > >>> <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 > >>> <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 > >>> 0002 > >>> <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 > >>> cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no > >>> (enabled) > >>> <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, > >>> ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) > >>> <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, > >>> ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: > >>> igt/rcs0[5977]/1 > >>> <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 > >>> <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] > >>> prio=1024 @ 5164ms: (null) > >>> <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] > >>> prio=139 @ 5164ms: igt/rcs0[5977]/1 > >>> <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139 > >>> <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] > >>> prio=132 @ 5164ms: igt/rcs0[5977]/8 > >>> <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] > >>> prio=121 @ 5165ms: igt/rcs0[5977]/2 > >>> <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] > >>> prio=82 @ 5165ms: igt/rcs0[5977]/3 > >>> <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] > >>> prio=44 @ 5164ms: igt/rcs0[5977]/2 > >>> <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] > >>> prio=20 @ 5165ms: igt/rcs0[5977]/4 > >>> <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting > >>> for 19a99 > >>> > >>> where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET! > >>> The RING_MODE indicates that is idle and has the STOP_RING bit set, so > >>> try clearing it. > >>> > >>> v2: Only clear the bit on restarting the ring, as we want to be sure the > >>> STOP_RING bit is kept if reset fails on wedging. > >>> v3: Spot when the ring state doesn't make sense when re-initialising the > >>> engine and dump it to the logs so that we don't have to wait for an > >>> error later and try to guess what happened earlier. > >>> v4: Prepare to print all the unexpected state, not just the first. > >>> > >>> Signed-off-by: Chris Wilson > >>> Cc: Tvrtko Ursulin > >>> --- > >>>drivers/gpu/drm/i915/intel_lrc.c | 22 ++ > >>>1 file changed, 22 insertions(+) > >>> > >>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >>> b/drivers/gpu/drm/i915/intel_lrc.c > >>> index 3744f5750624..ba8411ba4abf 100644 > >>> --- a/dri
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP" (rev2)
== Series Details ==
Series: Revert "drm/i915/edp: Do not do link training fallback or prune modes
on EDP" (rev2)
URL : https://patchwork.freedesktop.org/series/43278/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4217d2e38954 Revert "drm/i915/edp: Do not do link training fallback or prune
modes on EDP"
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit c0cfb10d9e1d ("drm/i915/edp: Do
not do link training fallback or prune modes on EDP")'
#8:
> This reverts commit c0cfb10d9e1de490e36d3b9d4228c0ea0ca30677.
-:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#11:
> [drm:intel_dp_start_link_train [i915]] [CONNECTOR:59:eDP-1] Link Training
> Passed at Link Rate = 54, Lane count = 4
-:30: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit c0cfb10d9e1d ("drm/i915/edp: Do
not do link training fallback or prune modes on EDP")'
#30:
that for eDP when c0cfb10d9e1d ("drm/i915/edp: Do not do link training
-:54: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 3 errors, 1 warnings, 0 checks, 9 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/psr: vbt change for psr (rev8)
== Series Details == Series: drm/i915/psr: vbt change for psr (rev8) URL : https://patchwork.freedesktop.org/series/41289/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4204_full -> Patchwork_9044_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9044_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9044_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41289/revisions/8/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9044_full: === IGT changes === Possible regressions igt@kms_vblank@pipe-a-query-idle: shard-kbl: PASS -> FAIL Warnings igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: shard-kbl: SKIP -> PASS igt@kms_cursor_crc@cursor-256x256-offscreen: shard-snb: SKIP -> PASS igt@kms_plane_lowres@pipe-c-tiling-x: shard-apl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9044_full that come from known issues: === IGT changes === Issues hit igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) +1 igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt: shard-kbl: PASS -> DMESG-WARN (fdo#105602, fdo#103558, fdo#103313) +3 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: shard-apl: PASS -> DMESG-FAIL (fdo#105602, fdo#103558) igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: shard-apl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +9 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) igt@kms_universal_plane@universal-plane-gen9-features-pipe-a: shard-kbl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +9 igt@kms_vblank@pipe-c-ts-continuation-suspend: shard-kbl: PASS -> DMESG-WARN (fdo#103841, fdo#105602, fdo#103558) Possible fixes igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: shard-glk: FAIL (fdo#104873) -> PASS igt@kms_flip@2x-flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_flip@blocking-wf_vblank: shard-hsw: FAIL (fdo#103928) -> PASS igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_rotation_crc@primary-rotation-90: shard-apl: FAIL (fdo#104724, fdo#103925) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4204 -> Patchwork_9044 CI_DRM_4204: 1bffedaef627748248914f5a043e379fee0b121d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9044: 46adf06c3a05a9975ff258f3e786bd31c79173e1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9044/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 30/40] drm/i915: Initialize HDCP2.2 and its MEI interface
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 30/40] drm/i915: Initialize HDCP2.2 and its MEI
>interface
>
>Initialize HDCP2.2 support. This includes the mei interface initialization
>along with
>required notifier registration.
>
>v2:
> mei interface handle is protected with mutex. [Chris Wilson]
>v3:
> Notifiers are used for the mei interface state.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_dp.c | 3 +-
> drivers/gpu/drm/i915/intel_drv.h | 5 +-
> drivers/gpu/drm/i915/intel_hdcp.c | 104
>+-
> drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
> 4 files changed, 109 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>index 9a4a51e79fa1..955a20208097 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -6381,7 +6381,8 @@ intel_dp_init_connector(struct intel_digital_port
>*intel_dig_port,
> intel_dp_add_properties(intel_dp, connector);
>
> if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
>- int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim);
>+ int ret = intel_hdcp_init(intel_connector, &intel_dp_hdcp_shim,
>+false);
> if (ret)
> DRM_DEBUG_KMS("HDCP init failed, skipping.\n");
> }
>diff --git a/drivers/gpu/drm/i915/intel_drv.h
>b/drivers/gpu/drm/i915/intel_drv.h
>index ca06d9a158f6..2f14756b4b0e 100644
>--- a/drivers/gpu/drm/i915/intel_drv.h
>+++ b/drivers/gpu/drm/i915/intel_drv.h
>@@ -442,7 +442,7 @@ struct intel_hdcp {
> /* mei interface related information */
> struct mei_cl_device *cldev;
> struct mei_hdcp_data mei_data;
>-
>+ struct notifier_block mei_cldev_nb;
> struct delayed_work hdcp2_check_work;
> };
>
>@@ -1928,7 +1928,8 @@ void intel_hdcp_atomic_check(struct drm_connector
>*connector,
>struct drm_connector_state *old_state,
>struct drm_connector_state *new_state); int
>intel_hdcp_init(struct intel_connector *connector,
>- const struct intel_hdcp_shim *hdcp_shim);
>+ const struct intel_hdcp_shim *hdcp_shim,
>+ bool hdcp2_supported);
> int intel_hdcp_enable(struct intel_connector *connector); int
>intel_hdcp_disable(struct intel_connector *connector); int
>intel_hdcp_check_link(struct intel_connector *connector); diff --git
>a/drivers/gpu/drm/i915/intel_hdcp.c b/drivers/gpu/drm/i915/intel_hdcp.c
>index 53d35ee8f683..6eb58a833c7d 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -11,6 +11,7 @@
> #include
> #include
> #include
>+#include
>
> #include "intel_drv.h"
> #include "i915_reg.h"
>@@ -25,6 +26,7 @@ static int _intel_hdcp2_enable(struct intel_connector
>*connector); static int _intel_hdcp2_disable(struct intel_connector
>*connector);
>static void intel_hdcp2_check_work(struct work_struct *work); static int
>intel_hdcp2_check_link(struct intel_connector *connector);
>+static int intel_hdcp2_init(struct intel_connector *connector);
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
> const struct intel_hdcp_shim *shim) @@ -
>686,11 +688,15 @@ bool is_hdcp_supported(struct drm_i915_private *dev_priv,
>enum port port) }
>
> int intel_hdcp_init(struct intel_connector *connector,
>- const struct intel_hdcp_shim *hdcp_shim)
>+ const struct intel_hdcp_shim *hdcp_shim,
>+ bool hdcp2_supported)
> {
> struct intel_hdcp *hdcp = &connector->hdcp;
> int ret;
>
>+ if (!hdcp_shim)
>+ return -EINVAL;
>+
> ret = drm_connector_attach_content_protection_property(
> &connector->base);
> if (ret)
>@@ -699,7 +705,12 @@ int intel_hdcp_init(struct intel_connector *connector,
> hdcp->hdcp_shim = hdcp_shim;
> mutex_init(&hdcp->hdcp_mutex);
> INIT_DELAYED_WORK(&hdcp->hdcp_check_work,
>intel_hdcp_check_work);
>+ INIT_DELAYED_WORK(&hdcp->hdcp2_check_work,
>intel_hdcp2_check_work);
> INIT_WORK(&hdcp->hdcp_prop_work, intel_hdcp_prop_work);
>+
>+ if (hdcp2_supported)
>+ intel_hdcp2_init(connector);
>+
> return 0;
> }
>
>@@ -1565,3 +1576,94 @@ static void intel_hdcp2_check_work(struct
>work_struct *work)
> schedule_delayed_work(&hdcp->hdcp2_check_work,
> DRM_HDCP2_CHECK_PERIOD_MS);
> }
>+
Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
On 18/05/2018 13:28, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 12:50:41) On 18/05/2018 12:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 12:05:17) On 18/05/2018 11:09, Chris Wilson wrote: Inside the live_hangcheck (reset) selftests, we occasionally see failures like <7>[ 239.094840] i915_gem_set_wedged rcs0 <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) <7>[ 239.094848] i915_gem_set_wedged Requests: <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280, tail 02a8, batch 0x_] <7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000 <7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8 <7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8 <7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8 <7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10 <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle] <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260 <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 0002 <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled) <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139 <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @ 5164ms: igt/rcs0[5977]/8 <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @ 5165ms: igt/rcs0[5977]/2 <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @ 5165ms: igt/rcs0[5977]/3 <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @ 5164ms: igt/rcs0[5977]/2 <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @ 5165ms: igt/rcs0[5977]/4 <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for 19a99 where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET! The RING_MODE indicates that is idle and has the STOP_RING bit set, so try clearing it. v2: Only clear the bit on restarting the ring, as we want to be sure the STOP_RING bit is kept if reset fails on wedging. v3: Spot when the ring state doesn't make sense when re-initialising the engine and dump it to the logs so that we don't have to wait for an error later and try to guess what happened earlier. v4: Prepare to print all the unexpected state, not just the first. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 3744f5750624..ba8411ba4abf 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1781,6 +1781,9 @@ static void enable_execlists(struct intel_engine_cs *engine) I915_WRITE(RING_MODE_GEN7(engine), _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE)); + I915_WRITE(RING_MI_MODE(engine->mmio_base), +_MASKED_BIT_DISABLE(STOP_RING)); Worries me a bit to clear it unconditionally since documentation says nothing (that I can find) about this scenario. +
Re: [Intel-gfx] [PATCH v3 31/40] drm/i915: Schedule hdcp_check_link in _intel_hdcp_enable
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 31/40] drm/i915: Schedule hdcp_check_link in
>_intel_hdcp_enable
>
>As a preparation for making the intel_hdcp_enable as common function for both
>HDCP1.4 and HDCP2.2, HDCP1.4 check_link scheduling is moved into
>_intel_hdcp_enable() function.
Looks ok to me.
Reviewed-by: Uma Shankar
>
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 6eb58a833c7d..383e35689fbd 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -627,7 +627,7 @@ static int _intel_hdcp_enable(struct intel_connector
>*connector)
> ret = intel_hdcp_auth(conn_to_dig_port(connector),
> hdcp->hdcp_shim);
> if (!ret)
>- return 0;
>+ break;
>
> DRM_DEBUG_KMS("HDCP Auth failure (%d)\n", ret);
>
>@@ -635,7 +635,12 @@ static int _intel_hdcp_enable(struct intel_connector
>*connector)
> _intel_hdcp_disable(connector);
> }
>
>- DRM_ERROR("HDCP authentication failed (%d tries/%d)\n", tries, ret);
>+ if (i != tries)
>+ schedule_delayed_work(&hdcp->hdcp_check_work,
>+DRM_HDCP_CHECK_PERIOD_MS);
>+ else
>+ DRM_ERROR("HDCP authentication failed (%d tries/%d)\n",
>+tries, ret);
> return ret;
> }
>
>@@ -730,8 +735,6 @@ int intel_hdcp_enable(struct intel_connector *connector)
>
> hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
> schedule_work(&hdcp->hdcp_prop_work);
>- schedule_delayed_work(&hdcp->hdcp_check_work,
>-DRM_HDCP_CHECK_PERIOD_MS);
> out:
> mutex_unlock(&hdcp->hdcp_mutex);
> return ret;
>--
>2.7.4
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 32/40] drm/i915: Enable superior HDCP ver that is capable
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 32/40] drm/i915: Enable superior HDCP ver that
>is
>capable
>
>Considering that HDCP2.2 is more secure than HDCP1.4, When a setup supports
>HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
>
>v2:
> Included few optimization suggestions [Chris Wilson]
> Commit message is updated as per the rebased version.
>v3:
> No changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 76
>+++
> 1 file changed, 69 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 383e35689fbd..01701d7b7b07 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -27,6 +27,57 @@ static int _intel_hdcp2_disable(struct intel_connector
>*connector); static void intel_hdcp2_check_work(struct work_struct *work);
>static int intel_hdcp2_check_link(struct intel_connector *connector); static
>int
>intel_hdcp2_init(struct intel_connector *connector);
>+static inline
>+int intel_hdcp_read_valid_bksv(struct intel_digital_port *intel_dig_port,
>+ const struct intel_hdcp_shim *shim, u8 *bksv);
>static
>struct
>+intel_digital_port *conn_to_dig_port(struct intel_connector
>+*connector);
>+
>+static inline
Don’t have it as inline.
>+bool panel_supports_hdcp(struct intel_connector *connector) {
>+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+ struct intel_hdcp *hdcp = &connector->hdcp;
>+ bool capable = false;
>+ u8 bksv[5];
>+
>+ if (hdcp->hdcp_shim) {
>+ if (hdcp->hdcp_shim->hdcp_capable) {
>+ hdcp->hdcp_shim->hdcp_capable(intel_dig_port,
>&capable);
>+ } else {
>+ if (!intel_hdcp_read_valid_bksv(intel_dig_port,
>+ hdcp->hdcp_shim,
>bksv))
>+ capable = true;
>+ }
>+ }
Leave a blank line.
>+ return capable;
>+}
>+
>+static inline
>+bool panel_supports_hdcp2(struct intel_connector *connector) {
>+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
>+ struct intel_hdcp *hdcp = &connector->hdcp;
>+ bool capable = false;
>+
>+ if (hdcp->hdcp2_supported)
>+ hdcp->hdcp_shim->hdcp_2_2_capable(intel_dig_port, &capable);
This looks a bit odd. We are going inside if hdcp2.2 is supported and checking
for capable.
I guess it needs a bit of renaming to make them implicit(Supported and capable
sounds
confusing). I believe supported is for platform and capable is for panel ?
>+
>+ return capable;
>+}
>+
>+/* Is HDCP1.4 capable on Platform and Panel */ static inline bool
>+intel_hdcp_capable(struct intel_connector *connector) {
>+ return (connector->hdcp.hdcp_shim &&
>panel_supports_hdcp(connector));
>+}
>+
>+/* Is HDCP2.2 capable on Platform and Panel */ static inline bool
>+intel_hdcp2_capable(struct intel_connector *connector) {
>+ return (connector->hdcp.hdcp2_supported &&
>+ panel_supports_hdcp2(connector));
>+}
>
> static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
> const struct intel_hdcp_shim *shim) @@ -
>722,20 +773,27 @@ int intel_hdcp_init(struct intel_connector *connector, int
>intel_hdcp_enable(struct intel_connector *connector) {
> struct intel_hdcp *hdcp = &connector->hdcp;
>- int ret;
>+ int ret = -EINVAL;
>
> if (!hdcp->hdcp_shim)
> return -ENOENT;
>
> mutex_lock(&hdcp->hdcp_mutex);
>
>- ret = _intel_hdcp_enable(connector);
>- if (ret)
>- goto out;
>+ /*
>+ * Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
>+ * is capable of HDCP2.2, it is preferred to use HDCP2.2.
>+ */
>+ if (intel_hdcp2_capable(connector))
>+ ret = _intel_hdcp2_enable(connector);
>+ else if (intel_hdcp_capable(connector))
>+ ret = _intel_hdcp_enable(connector);
>+
>+ if (!ret) {
>+ hdcp->hdcp_value =
>DRM_MODE_CONTENT_PROTECTION_ENABLED;
>+ schedule_work(&hdcp->hdcp_prop_work);
>+ }
>
>- hdcp->hdcp_value = DRM_MODE_CONTENT_PROTECTION_ENABLED;
>- schedule_work(&hdcp->hdcp_prop_work);
>-out:
> mutex_unlock(&hdcp->hdcp_mutex);
> return ret;
> }
>@@ -752,10 +810,14 @@ int intel_hdcp_disable(struct intel_connector
>*connector)
>
> if (hdcp->hdcp_value !=
>DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP" (rev2)
== Series Details == Series: Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP" (rev2) URL : https://patchwork.freedesktop.org/series/43278/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4206 -> Patchwork_9049 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9049 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9049, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43278/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9049: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9049 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_frontbuffer_tracking@basic: fi-cnl-y3: PASS -> FAIL (fdo#104724, fdo#103167) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-hsw-4770r: FAIL (fdo#103481) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 == Participating hosts (43 -> 39) == Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4206 -> Patchwork_9049 CI_DRM_4206: e84f2b258f41e62419c58fcf0b85d917abbe849e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9049: 4217d2e389544979635223f9364b6a26ff525760 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Linux commits == 4217d2e38954 Revert "drm/i915/edp: Do not do link training fallback or prune modes on EDP" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9049/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 33/40] drm/i915: Enable HDCP1.4 incase of HDCP2.2 failure
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 33/40] drm/i915: Enable HDCP1.4 incase of
>HDCP2.2 failure
>
>When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is enabled.
>
Looks ok.
Reviewed-by: Uma Shankar
>v2:
> Rebased.
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_hdcp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
>b/drivers/gpu/drm/i915/intel_hdcp.c
>index 01701d7b7b07..5707830a4617 100644
>--- a/drivers/gpu/drm/i915/intel_hdcp.c
>+++ b/drivers/gpu/drm/i915/intel_hdcp.c
>@@ -786,7 +786,9 @@ int intel_hdcp_enable(struct intel_connector *connector)
>*/
> if (intel_hdcp2_capable(connector))
> ret = _intel_hdcp2_enable(connector);
>- else if (intel_hdcp_capable(connector))
>+
>+ /* When HDCP2.2 fails, HDCP1.4 will be attempted */
>+ if (ret && intel_hdcp_capable(connector))
> ret = _intel_hdcp_enable(connector);
>
> if (!ret) {
>--
>2.7.4
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 34/40] drm/i915: hdcp_check_link only on CP_IRQ
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Ramalingam C
>Sent: Tuesday, April 3, 2018 7:28 PM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
>seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;
>jani.nik...@linux.intel.com; Winkler, Tomas ;
>Usyskin, Alexander
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH v3 34/40] drm/i915: hdcp_check_link only on CP_IRQ
>
>HDCP check link is invoked only on CP_IRQ detection, instead of all short
>pulses.
>
Looks ok.
Reviewed-by: Uma Shankar
>v3:
> No Changes.
>
>Signed-off-by: Ramalingam C
>---
> drivers/gpu/drm/i915/intel_dp.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>index 955a20208097..4a9f5a690528 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -4467,8 +4467,10 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>
> if (sink_irq_vector & DP_AUTOMATED_TEST_REQUEST)
> intel_dp_handle_test_request(intel_dp);
>- if (sink_irq_vector & (DP_CP_IRQ | DP_SINK_SPECIFIC_IRQ))
>- DRM_DEBUG_DRIVER("CP or sink specific irq
>unhandled\n");
>+ if (sink_irq_vector & DP_CP_IRQ)
>+ intel_hdcp_check_link(intel_dp->attached_connector);
>+ if (sink_irq_vector & DP_SINK_SPECIFIC_IRQ)
>+ DRM_DEBUG_DRIVER("Sink specific irq unhandled\n");
> }
>
> /* defer to the hotplug work for link retraining if needed */ @@ -5438,9
>+5440,6 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool
>long_hpd)
>
> handled = intel_dp_short_pulse(intel_dp);
>
>- /* Short pulse can signify loss of hdcp authentication */
>- intel_hdcp_check_link(intel_dp->attached_connector);
>-
> if (!handled) {
> intel_dp->detect_done = false;
> goto put_power;
>--
>2.7.4
>
>___
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/5] Add ChromeOS EC CEC Support
Hi All, The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support through it's Embedded Controller, to enable the Linux CEC Core to communicate with it and get the CEC Physical Address from the correct HDMI Connector, the following must be added/changed: - Add the CEC sub-device registration in the ChromeOS EC MFD Driver - Add the CEC related commands and events definitions into the EC MFD driver - Add a way to get a CEC notifier with it's (optional) connector name - Add the CEC notifier to the i915 HDMI driver - Add the proper ChromeOS EC CEC Driver The CEC notifier with the connector name is the tricky point, since even on Device-Tree platforms, there is no way to distinguish between multiple HDMI connectors from the same DRM driver. The solution I implemented is pretty simple and only adds an optional connector name to eventually distinguish an HDMI connector notifier from another if they share the same device. Feel free to comment this patchset ! Changes since v2: - Add i915 port_identifier() and use this stable name as cec_notifier conn name - Fixed and cleaned up the CEC commands and events handling - Rebased the CEC sub-device registration on top of Enric's serie - Fixed comments typo on cec driver - Protected the DMI match only with PCI and DMI Kconfigs Changes since v1: - Added cec_notifier_put to intel_hdmi - Fixed all small reported issues on the EC CEC driver - Moved the cec_notifier_get out of the #if .. #else .. #endif Changes since RFC: - Moved CEC sub-device registration after CEC commands and events definitions patch - Removed get_notifier_get_byname - Added CEC_CORE select into i915 Kconfig - Removed CEC driver fallback if notifier is not configured on HW, added explicit warn - Fixed CEC core return type on error - Moved to cros-ec-cec media platform directory - Use bus_find_device() to find the pci i915 device instead of get_notifier_get_byname() - Fix Logical Address setup - Added comment about HW support - Removed memset of msg structures Neil Armstrong (5): media: cec-notifier: Get notifier by device and connector name drm/i915: hdmi: add CEC notifier to intel_hdmi mfd: cros-ec: Introduce CEC commands and events definitions. mfd: cros_ec_dev: Add CEC sub-device registration media: platform: Add Chrome OS EC CEC driver drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/intel_display.h | 20 ++ drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_hdmi.c| 13 + drivers/media/cec/cec-notifier.c | 11 +- drivers/media/platform/Kconfig | 11 + drivers/media/platform/Makefile | 2 + drivers/media/platform/cros-ec-cec/Makefile | 1 + drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++ drivers/mfd/cros_ec_dev.c| 16 ++ drivers/platform/chrome/cros_ec_proto.c | 40 ++- include/linux/mfd/cros_ec.h | 2 +- include/linux/mfd/cros_ec_commands.h | 80 ++ include/media/cec-notifier.h | 27 +- 14 files changed, 557 insertions(+), 16 deletions(-) create mode 100644 drivers/media/platform/cros-ec-cec/Makefile create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-by: Stefan Adolfsson
Signed-off-by: Neil Armstrong
---
drivers/platform/chrome/cros_ec_proto.c | 40 +
include/linux/mfd/cros_ec.h | 2 +-
include/linux/mfd/cros_ec_commands.h| 80 +
3 files changed, 112 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_proto.c
b/drivers/platform/chrome/cros_ec_proto.c
index e7bbdf9..c4f6c44 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -504,10 +504,31 @@ int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
}
EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
+static int get_next_event_xfer(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg,
+ int version, uint32_t size)
+{
+ int ret;
+
+ msg->version = version;
+ msg->command = EC_CMD_GET_NEXT_EVENT;
+ msg->insize = size;
+ msg->outsize = 0;
+
+ ret = cros_ec_cmd_xfer(ec_dev, msg);
+ if (ret > 0) {
+ ec_dev->event_size = ret - 1;
+ memcpy(&ec_dev->event_data, msg->data, ec_dev->event_size);
+ }
+
+ return ret;
+}
+
static int get_next_event(struct cros_ec_device *ec_dev)
{
u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
struct cros_ec_command *msg = (struct cros_ec_command *)&buffer;
+ static int cmd_version = 1;
int ret;
if (ec_dev->suspended) {
@@ -515,18 +536,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
return -EHOSTDOWN;
}
- msg->version = 0;
- msg->command = EC_CMD_GET_NEXT_EVENT;
- msg->insize = sizeof(ec_dev->event_data);
- msg->outsize = 0;
+ if (cmd_version == 1) {
+ ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event_v1));
+ if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
+ return ret;
- ret = cros_ec_cmd_xfer(ec_dev, msg);
- if (ret > 0) {
- ec_dev->event_size = ret - 1;
- memcpy(&ec_dev->event_data, msg->data,
- sizeof(ec_dev->event_data));
+ /* Fallback to version 0 for future send attempts */
+ cmd_version = 0;
}
+ ret = get_next_event_xfer(ec_dev, msg, cmd_version,
+ sizeof(struct ec_response_get_next_event));
+
return ret;
}
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index f36125e..32caef3 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -147,7 +147,7 @@ struct cros_ec_device {
bool mkbp_event_supported;
struct blocking_notifier_head event_notifier;
- struct ec_response_get_next_event event_data;
+ struct ec_response_get_next_event_v1 event_data;
int event_size;
u32 host_event_wake_mask;
};
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index f2edd99..16c3a2b 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -804,6 +804,8 @@ enum ec_feature_code {
EC_FEATURE_MOTION_SENSE_FIFO = 24,
/* EC has RTC feature that can be controlled by host commands */
EC_FEATURE_RTC = 27,
+ /* EC supports CEC commands */
+ EC_FEATURE_CEC = 35,
};
#define EC_FEATURE_MASK_0(event_code) (1UL << (event_code % 32))
@@ -2078,6 +2080,12 @@ enum ec_mkbp_event {
/* EC sent a sysrq command */
EC_MKBP_EVENT_SYSRQ = 6,
+ /* Notify the AP that something happened on CEC */
+ EC_MKBP_CEC_EVENT = 8,
+
+ /* Send an incoming CEC message to the AP */
+ EC_MKBP_EVENT_CEC_MESSAGE = 9,
+
/* Number of MKBP events */
EC_MKBP_EVENT_COUNT,
};
@@ -2093,12 +2101,31 @@ union ec_response_get_next_data {
uint32_t sysrq;
} __packed;
+union ec_response_get_next_data_v1 {
+ uint8_t key_matrix[16];
+
+ /* Unaligned */
+ uint32_t host_event;
+
+ uint32_t buttons;
+ uint32_t switches;
+ uint32_t sysrq;
+ uint32_t cec_events;
+ uint8_tcec_message[16];
+} __packed;
+
struct ec_response_get_next_event {
uint8_t event_type;
/* Followed by event data if any */
union ec_response_get_next_data data;
} __packed;
+struct ec_response_get_next_event_v1 {
+ uint8_t event_type;
+ /* Followed by event data if any */
+ union ec_response_get_next_data_v1 data;
+} __packed;
+
[Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/intel_display.h | 20
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c| 13 +
4 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index dfd9588..2d65d56 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,7 @@ config DRM_I915
select SYNC_FILE
select IOSF_MBI
select CRC32
+ select CEC_CORE if CEC_NOTIFIER
help
Choose this option if you have a system that has "Intel Graphics
Media Accelerator" or "HD Graphics" integrated graphics,
diff --git a/drivers/gpu/drm/i915/intel_display.h
b/drivers/gpu/drm/i915/intel_display.h
index 4e7418b..c68d1c8 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -126,6 +126,26 @@ enum port {
#define port_name(p) ((p) + 'A')
+static inline const char *port_identifier(enum port port)
+{
+ switch (port) {
+ case PORT_A:
+ return "Port A";
+ case PORT_B:
+ return "Port B";
+ case PORT_C:
+ return "Port C";
+ case PORT_D:
+ return "Port D";
+ case PORT_E:
+ return "Port E";
+ case PORT_F:
+ return "Port F";
+ default:
+ return "";
+ }
+}
+
enum dpio_channel {
DPIO_CH0,
DPIO_CH1
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d436858..b50e51b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
/**
* __wait_for - magic wait macro
@@ -1001,6 +1002,7 @@ struct intel_hdmi {
bool has_audio;
bool rgb_quant_range_selectable;
struct intel_connector *attached_connector;
+ struct cec_notifier *notifier;
};
struct intel_dp_mst_encoder;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1baef4a..d522b5b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
connected = true;
}
+ cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
+
return connected;
}
@@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
{
enum drm_connector_status status;
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
@@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
+ if (status != connector_status_connected)
+ cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
+
return status;
}
@@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder,
static void intel_hdmi_destroy(struct drm_connector *connector)
{
+ if (intel_attached_hdmi(connector)->notifier)
+ cec_notifier_put(intel_attached_hdmi(connector)->notifier);
kfree(to_intel_connector(connector)->detect_edid);
drm_connector_cleanup(connector);
kfree(connector);
@@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
}
+
+ intel_hdmi->notifier = cec_notifier_get_conn(dev->dev,
+port_identifier(port));
+ if (!intel_hdmi->notifier)
+ DRM_DEBUG_KMS("CEC notifier get failed\n");
}
void intel_hdmi_init(struct drm_i915_private *dev_priv,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver
The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address and handles
all the messages retries and will only expose Success or Error.
The controller will be tied to the HDMI CEC notifier by using the platform
DMI Data and the i915 device name and connector name.
Signed-off-by: Neil Armstrong
---
drivers/media/platform/Kconfig | 11 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/cros-ec-cec/Makefile | 1 +
drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++
4 files changed, 361 insertions(+)
create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c7a1cf8..e55a8ed2 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
if CEC_PLATFORM_DRIVERS
+config VIDEO_CROS_EC_CEC
+ tristate "Chrome OS EC CEC driver"
+ depends on MFD_CROS_EC || COMPILE_TEST
+ select CEC_CORE
+ select CEC_NOTIFIER
+ ---help---
+ If you say yes here you will get support for the
+ Chrome OS Embedded Controller's CEC.
+ The CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
config VIDEO_MESON_AO_CEC
tristate "Amlogic Meson AO CEC driver"
depends on ARCH_MESON || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 932515d..830696f 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+=
qcom/camss-8x16/
obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
obj-y += meson/
+
+obj-y += cros-ec-cec/
diff --git a/drivers/media/platform/cros-ec-cec/Makefile
b/drivers/media/platform/cros-ec-cec/Makefile
new file mode 100644
index 000..9ce97f9
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
new file mode 100644
index 000..7e1e275
--- /dev/null
+++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
@@ -0,0 +1,347 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * CEC driver for Chrome OS Embedded Controller
+ *
+ * Copyright (c) 2018 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRV_NAME "cros-ec-cec"
+
+/**
+ * struct cros_ec_cec - Driver data for EC CEC
+ *
+ * @cros_ec: Pointer to EC device
+ * @notifier: Notifier info for responding to EC events
+ * @adap: CEC adapter
+ * @notify: CEC notifier pointer
+ * @rx_msg: storage for a received message
+ */
+struct cros_ec_cec {
+ struct cros_ec_device *cros_ec;
+ struct notifier_block notifier;
+ struct cec_adapter *adap;
+ struct cec_notifier *notify;
+ struct cec_msg rx_msg;
+};
+
+static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint8_t *cec_message = cros_ec->event_data.data.cec_message;
+ unsigned int len = cros_ec->event_size;
+
+ cros_ec_cec->rx_msg.len = len;
+ memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
+
+ cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
+}
+
+static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
+{
+ struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
+ uint32_t events = cros_ec->event_data.data.cec_events;
+
+ if (events & EC_MKBP_CEC_SEND_OK)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_OK);
+
+ /* FW takes care of all retries, tell core to avoid more retries */
+ if (events & EC_MKBP_CEC_SEND_FAILED)
+ cec_transmit_attempt_done(cros_ec_cec->adap,
+ CEC_TX_STATUS_MAX_RETRIES |
+ CEC_TX_STATUS_NACK);
+}
+
+static int cros_ec_cec_event(struct notifier_block *nb,
+unsigned long queued_during_suspend,
+void *_notify)
+{
+ struct cros_ec_cec *cros_ec_cec;
+ struct cros_ec_device *cros_ec;
+
+ cros_ec_cec = container_of(nb, struct cros_ec_cec, notifier);
+ cros_ec = cros_ec_cec->cros_ec;
+
+
[Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
index 1d6dc5c..272969e 100644
--- a/drivers/mfd/cros_ec_dev.c
+++ b/drivers/mfd/cros_ec_dev.c
@@ -383,6 +383,10 @@ static void cros_ec_sensors_register(struct cros_ec_dev
*ec)
kfree(msg);
}
+static const struct mfd_cell cros_ec_cec_cells[] = {
+ { .name = "cros-ec-cec" }
+};
+
static const struct mfd_cell cros_ec_rtc_cells[] = {
{ .name = "cros-ec-rtc" }
};
@@ -426,6 +430,18 @@ static int ec_device_probe(struct platform_device *pdev)
if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
cros_ec_sensors_register(ec);
+ /* Check whether this EC instance has CEC host command support */
+ if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
+ retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
+cros_ec_cec_cells,
+ARRAY_SIZE(cros_ec_cec_cells),
+NULL, 0, NULL);
+ if (retval)
+ dev_err(ec->dev,
+ "failed to add cros-ec-cec device: %d\n",
+ retval);
+ }
+
/* Check whether this EC instance has RTC host command support */
if (cros_ec_check_features(ec, EC_FEATURE_RTC)) {
retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at least 2 HDMI connectors, this patch also
adds the possibility to add a connector name tied to the notifier device
to form a tuple and associate different CEC controllers for each HDMI
connectors.
Signed-off-by: Neil Armstrong
---
drivers/media/cec/cec-notifier.c | 11 ---
include/media/cec-notifier.h | 27 ---
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c
index 16dffa0..dd2078b 100644
--- a/drivers/media/cec/cec-notifier.c
+++ b/drivers/media/cec/cec-notifier.c
@@ -21,6 +21,7 @@ struct cec_notifier {
struct list_head head;
struct kref kref;
struct device *dev;
+ const char *conn;
struct cec_adapter *cec_adap;
void (*callback)(struct cec_adapter *adap, u16 pa);
@@ -30,13 +31,14 @@ struct cec_notifier {
static LIST_HEAD(cec_notifiers);
static DEFINE_MUTEX(cec_notifiers_lock);
-struct cec_notifier *cec_notifier_get(struct device *dev)
+struct cec_notifier *cec_notifier_get_conn(struct device *dev, const char
*conn)
{
struct cec_notifier *n;
mutex_lock(&cec_notifiers_lock);
list_for_each_entry(n, &cec_notifiers, head) {
- if (n->dev == dev) {
+ if (n->dev == dev &&
+ (!conn || !strcmp(n->conn, conn))) {
kref_get(&n->kref);
mutex_unlock(&cec_notifiers_lock);
return n;
@@ -46,6 +48,8 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
if (!n)
goto unlock;
n->dev = dev;
+ if (conn)
+ n->conn = kstrdup(conn, GFP_KERNEL);
n->phys_addr = CEC_PHYS_ADDR_INVALID;
mutex_init(&n->lock);
kref_init(&n->kref);
@@ -54,7 +58,7 @@ struct cec_notifier *cec_notifier_get(struct device *dev)
mutex_unlock(&cec_notifiers_lock);
return n;
}
-EXPORT_SYMBOL_GPL(cec_notifier_get);
+EXPORT_SYMBOL_GPL(cec_notifier_get_conn);
static void cec_notifier_release(struct kref *kref)
{
@@ -62,6 +66,7 @@ static void cec_notifier_release(struct kref *kref)
container_of(kref, struct cec_notifier, kref);
list_del(&n->head);
+ kfree(n->conn);
kfree(n);
}
diff --git a/include/media/cec-notifier.h b/include/media/cec-notifier.h
index cf0add7..814eeef 100644
--- a/include/media/cec-notifier.h
+++ b/include/media/cec-notifier.h
@@ -20,8 +20,10 @@ struct cec_notifier;
#if IS_REACHABLE(CONFIG_CEC_CORE) && IS_ENABLED(CONFIG_CEC_NOTIFIER)
/**
- * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * cec_notifier_get_conn - find or create a new cec_notifier for the given
+ * device and connector tuple.
* @dev: device that sends the events.
+ * @conn: the connector name from which the event occurs
*
* If a notifier for device @dev already exists, then increase the refcount
* and return that notifier.
@@ -31,7 +33,8 @@ struct cec_notifier;
*
* Return NULL if the memory could not be allocated.
*/
-struct cec_notifier *cec_notifier_get(struct device *dev);
+struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+ const char *conn);
/**
* cec_notifier_put - decrease refcount and delete when the refcount reaches 0.
@@ -85,7 +88,8 @@ void cec_register_cec_notifier(struct cec_adapter *adap,
struct cec_notifier *notifier);
#else
-static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+static inline struct cec_notifier *cec_notifier_get_conn(struct device *dev,
+const char *conn)
{
/* A non-NULL pointer is expected on success */
return (struct cec_notifier *)0xdeadfeed;
@@ -121,6 +125,23 @@ static inline void cec_register_cec_notifier(struct
cec_adapter *adap,
#endif
/**
+ * cec_notifier_get - find or create a new cec_notifier for the given device.
+ * @dev: device that sends the events.
+ *
+ * If a notifier for device @dev already exists, then increase the refcount
+ * and return that notifier.
+ *
+ * If it doesn't exist, then allocate a new notifier struct and return a
+ * pointer to that new struct.
+ *
+ * Return NULL if the memory could not be allocated.
+ */
+static inline struct cec_notifier *cec_notifier_get(struct device *dev)
+{
+ return cec_notifier_get_conn(dev, NULL);
+}
+
+/**
* cec_notifier_phys_addr_invalidate() - set the physical address to INVALID
*
* @n: the CEC notifier
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@l
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add ChromeOS EC CEC Support (rev4)
== Series Details == Series: Add ChromeOS EC CEC Support (rev4) URL : https://patchwork.freedesktop.org/series/43162/ State : failure == Summary == Applying: media: cec-notifier: Get notifier by device and connector name Applying: drm/i915: hdmi: add CEC notifier to intel_hdmi Applying: mfd: cros-ec: Introduce CEC commands and events definitions. Applying: mfd: cros_ec_dev: Add CEC sub-device registration error: sha1 information is lacking or useless (drivers/mfd/cros_ec_dev.c). error: could not build fake ancestor Patch failed at 0004 mfd: cros_ec_dev: Add CEC sub-device registration The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for GMBUS changes (rev5)
== Series Details == Series: GMBUS changes (rev5) URL : https://patchwork.freedesktop.org/series/41632/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4204_full -> Patchwork_9045_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9045_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9045_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41632/revisions/5/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9045_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP +1 igt@gem_exec_schedule@deep-vebox: shard-kbl: SKIP -> PASS +1 igt@kms_cursor_crc@cursor-256x256-offscreen: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9045_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560) igt@kms_atomic_transition@1x-modeset-transitions-nonblocking: shard-glk: PASS -> FAIL (fdo#105703) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105707) igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) +1 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: shard-glk: PASS -> DMESG-WARN (fdo#106247) +1 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_flip@blocking-wf_vblank: shard-hsw: FAIL (fdo#103928) -> PASS igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: FAIL (fdo#100368) -> PASS +1 igt@kms_rotation_crc@primary-rotation-90: shard-apl: FAIL (fdo#104724, fdo#103925) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105707 https://bugs.freedesktop.org/show_bug.cgi?id=105707 fdo#106247 https://bugs.freedesktop.org/show_bug.cgi?id=106247 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4204 -> Patchwork_9045 CI_DRM_4204: 1bffedaef627748248914f5a043e379fee0b121d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9045: f91237f2fdac166a3483e40ba7c673949c0057fe @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9045/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi
On Fri, May 18, 2018 at 03:05:01PM +0200, Neil Armstrong wrote:
> This patchs adds the cec_notifier feature to the intel_hdmi part
> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
> between each HDMI ports.
> The changes will allow the i915 HDMI code to notify EDID and HPD changes
> to an eventual CEC adapter.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/intel_display.h | 20
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c| 13 +
> 4 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index dfd9588..2d65d56 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,7 @@ config DRM_I915
> select SYNC_FILE
> select IOSF_MBI
> select CRC32
> + select CEC_CORE if CEC_NOTIFIER
> help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 4e7418b..c68d1c8 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -126,6 +126,26 @@ enum port {
>
> #define port_name(p) ((p) + 'A')
>
> +static inline const char *port_identifier(enum port port)
> +{
> + switch (port) {
> + case PORT_A:
> + return "Port A";
> + case PORT_B:
> + return "Port B";
> + case PORT_C:
> + return "Port C";
> + case PORT_D:
> + return "Port D";
> + case PORT_E:
> + return "Port E";
> + case PORT_F:
> + return "Port F";
> + default:
> + return "";
> + }
> +}
I don't think we need this in the header. A static function will do.
And I was actually thinking something a bit fancier like:
snprintf("%s/port-%s", dev_name(dev), port_id(port));
Oh, I see you already pass the device in so I guess we don't need
that in the port id?
> +
> enum dpio_channel {
> DPIO_CH0,
> DPIO_CH1
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d436858..b50e51b 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> /**
> * __wait_for - magic wait macro
> @@ -1001,6 +1002,7 @@ struct intel_hdmi {
> bool has_audio;
> bool rgb_quant_range_selectable;
> struct intel_connector *attached_connector;
> + struct cec_notifier *notifier;
I was wondering if we need any ifdefs around this stuff, but I guess not
since it's just a pointer and all the functions seem to have empty
static inlines for the CEC=n case.
> };
>
> struct intel_dp_mst_encoder;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1baef4a..d522b5b 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1868,6 +1868,8 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> connected = true;
> }
>
> + cec_notifier_set_phys_addr_from_edid(intel_hdmi->notifier, edid);
> +
> return connected;
> }
>
> @@ -1876,6 +1878,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
> {
> enum drm_connector_status status;
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
> @@ -1891,6 +1894,9 @@ intel_hdmi_detect(struct drm_connector *connector, bool
> force)
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
>
> + if (status != connector_status_connected)
> + cec_notifier_phys_addr_invalidate(intel_hdmi->notifier);
> +
> return status;
> }
>
> @@ -2031,6 +2037,8 @@ static void chv_hdmi_pre_enable(struct intel_encoder
> *encoder,
>
> static void intel_hdmi_destroy(struct drm_connector *connector)
> {
> + if (intel_attached_hdmi(connector)->notifier)
> + cec_notifier_put(intel_attached_hdmi(connector)->notifier);
> kfree(to_intel_connector(connector)->detect_edid);
> drm_connector_cleanup(connector);
> kfree(connector);
> @@ -2358,6 +2366,11 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> u32 temp = I915_READ(PEG_BAND_GAP_DATA);
> I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
> }
> +
> + intel_hdmi->notifier = cec_notifier_get_conn(dev->dev,
> + port_identifier(port));
> + if (!intel_hdmi->notifier)
> + DRM_DEBUG_KMS("CEC notifier g
Re: [Intel-gfx] [PATCH 030/262] drm/i915: Refactor unsettting obj->mm.pages
On 17 May 2018 at 07:03, Chris Wilson wrote:
> As i915_gem_object_phys_attach() wants to play dirty and mess around
> with obj->mm.pages itself (replacing the shmemfs with a DMA allocation),
> refactor the gubbins so into i915_gem_object_unset_pages() that we don't
> have to duplicate all the secrets.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem.c | 68 ++---
> 1 file changed, 37 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index be3092a03722..4e480874563f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2410,29 +2410,15 @@ static void __i915_gem_object_reset_page_iter(struct
> drm_i915_gem_object *obj)
> rcu_read_unlock();
> }
>
> -void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
> -enum i915_mm_subclass subclass)
> +static struct sg_table *
> +__i915_gem_object_unset_pages(struct drm_i915_gem_object *obj)
> {
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> struct sg_table *pages;
>
> - if (i915_gem_object_has_pinned_pages(obj))
> - return;
> -
> - GEM_BUG_ON(obj->bind_count);
> - if (!i915_gem_object_has_pages(obj))
> - return;
> -
> - /* May be called by shrinker from within get_pages() (on another bo)
> */
> - mutex_lock_nested(&obj->mm.lock, subclass);
> - if (unlikely(atomic_read(&obj->mm.pages_pin_count)))
> - goto unlock;
> -
> - /* ->put_pages might need to allocate memory for the bit17 swizzle
> -* array, hence protect them from being reaped by removing them from
> gtt
> -* lists early. */
> pages = fetch_and_zero(&obj->mm.pages);
> - GEM_BUG_ON(!pages);
> + if (!pages)
> + return NULL;
>
> spin_lock(&i915->mm.obj_lock);
> list_del(&obj->mm.link);
> @@ -2451,12 +2437,37 @@ void __i915_gem_object_put_pages(struct
> drm_i915_gem_object *obj,
> }
>
> __i915_gem_object_reset_page_iter(obj);
> + obj->mm.page_sizes.phys = obj->mm.page_sizes.sg = 0;
> +
> + return pages;
> +}
> +
> +void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
> +enum i915_mm_subclass subclass)
> +{
> + struct sg_table *pages;
> +
> + if (i915_gem_object_has_pinned_pages(obj))
> + return;
>
> + GEM_BUG_ON(obj->bind_count);
> + if (!i915_gem_object_has_pages(obj))
> + return;
> +
> + /* May be called by shrinker from within get_pages() (on another bo)
> */
> + mutex_lock_nested(&obj->mm.lock, subclass);
> + if (unlikely(atomic_read(&obj->mm.pages_pin_count)))
> + goto unlock;
> +
> + /*
> +* ->put_pages might need to allocate memory for the bit17 swizzle
> +* array, hence protect them from being reaped by removing them from
> gtt
> +* lists early.
> +*/
> + pages = __i915_gem_object_unset_pages(obj);
> if (!IS_ERR(pages))
> obj->ops->put_pages(obj, pages);
>
> - obj->mm.page_sizes.phys = obj->mm.page_sizes.sg = 0;
> -
> unlock:
> mutex_unlock(&obj->mm.lock);
> }
> @@ -6013,16 +6024,7 @@ int i915_gem_object_attach_phys(struct
> drm_i915_gem_object *obj, int align)
> goto err_unlock;
> }
>
> - pages = fetch_and_zero(&obj->mm.pages);
> - if (pages) {
> - struct drm_i915_private *i915 = to_i915(obj->base.dev);
> -
> - __i915_gem_object_reset_page_iter(obj);
> -
> - spin_lock(&i915->mm.obj_lock);
> - list_del(&obj->mm.link);
> - spin_unlock(&i915->mm.obj_lock);
> - }
> + pages = __i915_gem_object_unset_pages(obj);
>
> obj->ops = &i915_gem_phys_ops;
>
> @@ -6040,7 +6042,11 @@ int i915_gem_object_attach_phys(struct
> drm_i915_gem_object *obj, int align)
>
> err_xfer:
> obj->ops = &i915_gem_object_ops;
> - obj->mm.pages = pages;
> + if (!IS_ERR(pages)) {
!IS_ERR_OR_NULL
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration
2018-05-18 15:05 GMT+02:00 Neil Armstrong :
> The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
> when the CEC feature bit is present.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/mfd/cros_ec_dev.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c
> index 1d6dc5c..272969e 100644
> --- a/drivers/mfd/cros_ec_dev.c
> +++ b/drivers/mfd/cros_ec_dev.c
> @@ -383,6 +383,10 @@ static void cros_ec_sensors_register(struct cros_ec_dev
> *ec)
> kfree(msg);
> }
>
> +static const struct mfd_cell cros_ec_cec_cells[] = {
> + { .name = "cros-ec-cec" }
> +};
> +
> static const struct mfd_cell cros_ec_rtc_cells[] = {
> { .name = "cros-ec-rtc" }
> };
> @@ -426,6 +430,18 @@ static int ec_device_probe(struct platform_device *pdev)
> if (cros_ec_check_features(ec, EC_FEATURE_MOTION_SENSE))
> cros_ec_sensors_register(ec);
>
> + /* Check whether this EC instance has CEC host command support */
> + if (cros_ec_check_features(ec, EC_FEATURE_CEC)) {
> + retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
> +cros_ec_cec_cells,
> +ARRAY_SIZE(cros_ec_cec_cells),
> +NULL, 0, NULL);
> + if (retval)
> + dev_err(ec->dev,
> + "failed to add cros-ec-cec device: %d\n",
> + retval);
> + }
> +
> /* Check whether this EC instance has RTC host command support */
> if (cros_ec_check_features(ec, EC_FEATURE_RTC)) {
> retval = mfd_add_devices(ec->dev, PLATFORM_DEVID_AUTO,
> --
> 2.7.4
>
Reviewed-by: Enric Balletbo i Serra
Thanks,
Enric
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: Use intel_fb_obj() everywhere
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/intel_display.c | 19 ++-
drivers/gpu/drm/i915/intel_fbdev.c | 9 +
3 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 52515445ac40..e9b1b8df6ef5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1908,7 +1908,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
fbdev_fb->base.format->cpp[0] * 8,
fbdev_fb->base.modifier,
drm_framebuffer_read_refcount(&fbdev_fb->base));
- describe_obj(m, fbdev_fb->obj);
+ describe_obj(m, intel_fb_obj(&fbdev_fb->base));
seq_putc(m, '\n');
}
#endif
@@ -1926,7 +1926,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
fb->base.format->cpp[0] * 8,
fb->base.modifier,
drm_framebuffer_read_refcount(&fb->base));
- describe_obj(m, fb->obj);
+ describe_obj(m, intel_fb_obj(&fb->base));
seq_putc(m, '\n');
}
mutex_unlock(&dev->mode_config.fb_lock);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c9ec88acad9c..1b2cf631305e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2474,6 +2474,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
{
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct intel_rotation_info *rot_info = &intel_fb->rot_info;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
u32 gtt_offset_rotated = 0;
unsigned int max_size = 0;
int i, num_planes = fb->format->num_planes;
@@ -2538,7 +2539,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
* fb layout agrees with the fence layout. We already check
that the
* fb stride matches the fence stride elsewhere.
*/
- if (i == 0 && i915_gem_object_is_tiled(intel_fb->obj) &&
+ if (i == 0 && i915_gem_object_is_tiled(obj) &&
(x + width) * cpp > fb->pitches[i]) {
DRM_DEBUG_KMS("bad fb plane %d offset: 0x%x\n",
i, fb->offsets[i]);
@@ -2623,9 +2624,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
max_size = max(max_size, offset + size);
}
- if (max_size * tile_size > intel_fb->obj->base.size) {
+ if (max_size * tile_size > obj->base.size) {
DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu
bytes)\n",
- max_size * tile_size, intel_fb->obj->base.size);
+ max_size * tile_size, obj->base.size);
return -EINVAL;
}
@@ -14082,14 +14083,15 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
drm_framebuffer_cleanup(fb);
- i915_gem_object_lock(intel_fb->obj);
- WARN_ON(!intel_fb->obj->framebuffer_references--);
- i915_gem_object_unlock(intel_fb->obj);
+ i915_gem_object_lock(obj);
+ WARN_ON(!obj->framebuffer_references--);
+ i915_gem_object_unlock(obj);
- i915_gem_object_put(intel_fb->obj);
+ i915_gem_object_put(obj);
kfree(intel_fb);
}
@@ -14098,8 +14100,7 @@ static int intel_user_framebuffer_create_handle(struct
drm_framebuffer *fb,
struct drm_file *file,
unsigned int *handle)
{
- struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
- struct drm_i915_gem_object *obj = intel_fb->obj;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
if (obj->userptr.mm) {
DRM_DEBUG("attempting to use a userptr for a framebuffer,
denied\n");
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index e9e02b58b7be..fb2f9fce34cd 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -47,7 +47,7 @@
static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
{
- struct drm_i915_gem_object *obj = ifbdev->fb->obj;
+ struct drm_i915_ge
[Intel-gfx] [PATCH v2 2/2] drm/i915: Move GEM BO inside drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
v2: Only hold a single reference per framebuffer, not per plane. (Ville)
Signed-off-by: Daniel Stone
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1b2cf631305e..12226a2c8d39 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14370,9 +14370,9 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
i, fb->pitches[i], stride_alignment);
goto err;
}
- }
- intel_fb->obj = obj;
+ fb->obj[i] = &obj->base;
+ }
ret = intel_fill_fb_info(dev_priv, fb);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 12002fc77235..03e1d1d7fb58 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -194,7 +194,6 @@ enum intel_output_type {
struct intel_framebuffer {
struct drm_framebuffer base;
- struct drm_i915_gem_object *obj;
struct intel_rotation_info rot_info;
/* for each plane in the normal GTT view */
@@ -1005,7 +1004,7 @@ struct cxsr_latency {
#define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer, base)
#define to_intel_plane(x) container_of(x, struct intel_plane, base)
#define to_intel_plane_state(x) container_of(x, struct intel_plane_state, base)
-#define intel_fb_obj(x) (x ? to_intel_framebuffer(x)->obj : NULL)
+#define intel_fb_obj(x) (((x) && (x)->obj[0]) ? to_intel_bo((x)->obj[0]) :
NULL)
struct intel_hdmi {
i915_reg_t hdmi_reg;
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/2] drm/i915: Use intel_fb_obj() everywhere
== Series Details == Series: series starting with [v2,1/2] drm/i915: Use intel_fb_obj() everywhere URL : https://patchwork.freedesktop.org/series/43418/ State : warning == Summary == $ dim checkpatch origin/drm-tip a498ec6deeb8 drm/i915: Use intel_fb_obj() everywhere a7a2fce7f362 drm/i915: Move GEM BO inside drm_framebuffer -:54: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects? #54: FILE: drivers/gpu/drm/i915/intel_drv.h:1007: +#define intel_fb_obj(x) (((x) && (x)->obj[0]) ? to_intel_bo((x)->obj[0]) : NULL) total: 0 errors, 0 warnings, 1 checks, 26 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/2] drm/i915: Use intel_fb_obj() everywhere
== Series Details == Series: series starting with [v2,1/2] drm/i915: Use intel_fb_obj() everywhere URL : https://patchwork.freedesktop.org/series/43418/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Use intel_fb_obj() everywhere -O:drivers/gpu/drm/i915/intel_display.c:2623:28: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/intel_display.c:2623:28: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:2624:28: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_display.c:2624:28: warning: expression using sizeof(void) Commit: drm/i915: Move GEM BO inside drm_framebuffer Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 0/5] Add ChromeOS EC CEC Support
Hi Neil, 2018-05-18 15:04 GMT+02:00 Neil Armstrong : > Hi All, > > The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support > through it's Embedded Controller, to enable the Linux CEC Core to communicate > with it and get the CEC Physical Address from the correct HDMI Connector, the > following must be added/changed: > - Add the CEC sub-device registration in the ChromeOS EC MFD Driver > - Add the CEC related commands and events definitions into the EC MFD driver > - Add a way to get a CEC notifier with it's (optional) connector name > - Add the CEC notifier to the i915 HDMI driver > - Add the proper ChromeOS EC CEC Driver > > The CEC notifier with the connector name is the tricky point, since even on > Device-Tree platforms, there is no way to distinguish between multiple HDMI > connectors from the same DRM driver. The solution I implemented is pretty > simple and only adds an optional connector name to eventually distinguish > an HDMI connector notifier from another if they share the same device. > > Feel free to comment this patchset ! > > Changes since v2: > - Add i915 port_identifier() and use this stable name as cec_notifier conn > name > - Fixed and cleaned up the CEC commands and events handling > - Rebased the CEC sub-device registration on top of Enric's serie > - Fixed comments typo on cec driver > - Protected the DMI match only with PCI and DMI Kconfigs > Just because I got confused when I saw two v2 in my inbox. This is v3, right? > Changes since v1: > - Added cec_notifier_put to intel_hdmi > - Fixed all small reported issues on the EC CEC driver > - Moved the cec_notifier_get out of the #if .. #else .. #endif > > Changes since RFC: > - Moved CEC sub-device registration after CEC commands and events > definitions patch > - Removed get_notifier_get_byname > - Added CEC_CORE select into i915 Kconfig > - Removed CEC driver fallback if notifier is not configured on HW, added > explicit warn > - Fixed CEC core return type on error > - Moved to cros-ec-cec media platform directory > - Use bus_find_device() to find the pci i915 device instead of > get_notifier_get_byname() > - Fix Logical Address setup > - Added comment about HW support > - Removed memset of msg structures > > Neil Armstrong (5): > media: cec-notifier: Get notifier by device and connector name > drm/i915: hdmi: add CEC notifier to intel_hdmi > mfd: cros-ec: Introduce CEC commands and events definitions. > mfd: cros_ec_dev: Add CEC sub-device registration > media: platform: Add Chrome OS EC CEC driver > > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/intel_display.h | 20 ++ > drivers/gpu/drm/i915/intel_drv.h | 2 + > drivers/gpu/drm/i915/intel_hdmi.c| 13 + > drivers/media/cec/cec-notifier.c | 11 +- > drivers/media/platform/Kconfig | 11 + > drivers/media/platform/Makefile | 2 + > drivers/media/platform/cros-ec-cec/Makefile | 1 + > drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 > +++ > drivers/mfd/cros_ec_dev.c| 16 ++ > drivers/platform/chrome/cros_ec_proto.c | 40 ++- > include/linux/mfd/cros_ec.h | 2 +- > include/linux/mfd/cros_ec_commands.h | 80 ++ > include/media/cec-notifier.h | 27 +- > 14 files changed, 557 insertions(+), 16 deletions(-) > create mode 100644 drivers/media/platform/cros-ec-cec/Makefile > create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c > > -- > 2.7.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Use intel_fb_obj() everywhere
== Series Details == Series: series starting with [v2,1/2] drm/i915: Use intel_fb_obj() everywhere URL : https://patchwork.freedesktop.org/series/43418/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4206 -> Patchwork_9051 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/43418/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9051 that come from known issues: === IGT changes === Issues hit igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: PASS -> FAIL (fdo#102575) igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: PASS -> DMESG-FAIL (fdo#106103, fdo#102614) Possible fixes igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-hsw-4770r: FAIL (fdo#103481) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 == Participating hosts (43 -> 39) == Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-skl-6700hq == Build changes == * Linux: CI_DRM_4206 -> Patchwork_9051 CI_DRM_4206: e84f2b258f41e62419c58fcf0b85d917abbe849e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9051: a7a2fce7f36208c9c41b9d68dd544cfcfa67c22d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Linux commits == a7a2fce7f362 drm/i915: Move GEM BO inside drm_framebuffer a498ec6deeb8 drm/i915: Use intel_fb_obj() everywhere == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9051/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Move GEM BO inside drm_framebuffer
On Fri, May 18, 2018 at 02:48:44PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass.
>
> v2: Only hold a single reference per framebuffer, not per plane. (Ville)
>
> Signed-off-by: Daniel Stone
> Cc: Ville Syrjälä
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
> ---
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> drivers/gpu/drm/i915/intel_drv.h | 3 +--
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 1b2cf631305e..12226a2c8d39 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14370,9 +14370,9 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> i, fb->pitches[i], stride_alignment);
> goto err;
> }
> - }
>
> - intel_fb->obj = obj;
> + fb->obj[i] = &obj->base;
> + }
>
> ret = intel_fill_fb_info(dev_priv, fb);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 12002fc77235..03e1d1d7fb58 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -194,7 +194,6 @@ enum intel_output_type {
>
> struct intel_framebuffer {
> struct drm_framebuffer base;
> - struct drm_i915_gem_object *obj;
> struct intel_rotation_info rot_info;
>
> /* for each plane in the normal GTT view */
> @@ -1005,7 +1004,7 @@ struct cxsr_latency {
> #define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer,
> base)
> #define to_intel_plane(x) container_of(x, struct intel_plane, base)
> #define to_intel_plane_state(x) container_of(x, struct intel_plane_state,
> base)
> -#define intel_fb_obj(x) (x ? to_intel_framebuffer(x)->obj : NULL)
> +#define intel_fb_obj(x) (((x) && (x)->obj[0]) ? to_intel_bo((x)->obj[0]) :
> NULL)
We don't need the obj[0] null check. For most things we just assume
that the base object is at offset 0. And in case of drm_i915_gem_object
it looks like we even have a BUILD_BUG_ON() to make sure. So you may
want to drop that part.
Series is
Reviewed-by: Ville Syrjälä
>
> struct intel_hdmi {
> i915_reg_t hdmi_reg;
> --
> 2.17.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
Quoting Tvrtko Ursulin (2018-05-18 13:36:52) > > On 18/05/2018 13:28, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-05-18 12:50:41) > >> > >> On 18/05/2018 12:10, Chris Wilson wrote: > >>> Quoting Tvrtko Ursulin (2018-05-18 12:05:17) > > On 18/05/2018 11:09, Chris Wilson wrote: > > Inside the live_hangcheck (reset) selftests, we occasionally see > > failures like > > > > <7>[ 239.094840] i915_gem_set_wedged rcs0 > > <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last > > 19a9a, hangcheck 0 [5158 ms] > > <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global > > 1) > > <7>[ 239.094848] i915_gem_set_wedged Requests: > > <7>[ 239.095052] i915_gem_set_wedged first 19a99 > > [e8c:5f] prio=1024 @ 5159ms: (null) > > <7>[ 239.095056] i915_gem_set_wedged last 19a9a > > [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 > > <7>[ 239.095059] i915_gem_set_wedged active 19a99 > > [e8c:5f] prio=1024 @ 5159ms: (null) > > <7>[ 239.095062] i915_gem_set_wedged [head 0220, > > postfix 0280, tail 02a8, batch 0x_] > > <7>[ 239.100050] i915_gem_set_wedged ring->start: > > 0x00283000 > > <7>[ 239.100053] i915_gem_set_wedged ring->head: > > 0x01f8 > > <7>[ 239.100055] i915_gem_set_wedged ring->tail: > > 0x02a8 > > <7>[ 239.100057] i915_gem_set_wedged ring->emit: > > 0x02a8 > > <7>[ 239.100059] i915_gem_set_wedged ring->space: > > 0x0f10 > > <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 > > <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 > > <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 > > <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 > > <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 > > [idle] > > <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe > > <7>[ 239.100104] i915_gem_set_wedged ACTHD: > > 0x_609c > > <7>[ 239.100108] i915_gem_set_wedged BBADDR: > > 0x_609d > > <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: > > 0x_00283260 > > <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x > > <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 > > <7>[ 239.100120] i915_gem_set_wedged Execlist status: > > 0x00044052 0002 > > <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 > > cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no > > (enabled) > > <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, > > ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) > > <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, > > ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: > > igt/rcs0[5977]/1 > > <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 > > <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] > > prio=1024 @ 5164ms: (null) > > <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] > > prio=139 @ 5164ms: igt/rcs0[5977]/1 > > <7>[ 239.100340] i915_gem_set_wedged Queue priority: > > 139 > > <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] > > prio=132 @ 5164ms: igt/rcs0[5977]/8 > > <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] > > prio=121 @ 5165ms: igt/rcs0[5977]/2 > > <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] > > prio=82 @ 5165ms: igt/rcs0[5977]/3 > > <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] > > prio=44 @ 5164ms: igt/rcs0[5977]/2 > > <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] > > prio=20 @ 5165ms: igt/rcs0[5977]/4 > > <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] > > waiting for 19a99 > > > > where the GPU saw an arbitration point and idles; AND HAS NOT BEEN > > RESET! > > The RING_MODE indicates that is idle and has the STOP_RING bit set, so > > try clearing it. > > > > v2: Only clear the bit on restarting the ring, as we want to be sure the > > STOP_RING bit is kept if reset fails on wedging. > > v3: Spot when the ring state doesn't make sense when re-initialising the > > engine and dump it to the logs so that we don't have to wait for an > > error later and try to guess what happened earlier. > > v4: Prepare to print all the unexpected state, not just the first. > > > > Signed-off-by: Chris Wilson
Re: [Intel-gfx] [PATCH] drm/i915: Reject NV12 planes with odd width/start position
On Fri, May 18, 2018 at 03:25:26PM +0300, Ville Syrjälä wrote:
> On Thu, May 17, 2018 at 12:07:14PM -0700, Fritz Koenig wrote:
> > Planes with an odd width will appear to have an incorrect
> > stride. When the start position is odd the controller
> > can lock up.
>
> Just remove the strange NV12 check from the %2 checks in
> intel_check_sprite_plane()?
Hmm. Actually that wouldn't help the "primary" plane. I guess we want to
put this check into skl_check_nv12_surface() until we have a better
place for it, or until someone fixes the initial phase stuff to actually
handle this correctly.
>
> >
> > Signed-off-by: Fritz Koenig
> > ---
> >
> > Hi,
> >
> > This appears to be a limitation of the hardware that is not being
> > checked. Is this supported and am I not enabling it correctly?
> >
> >
> > drivers/gpu/drm/i915/intel_atomic_plane.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > index 7481ce85746b..ca4553592ab9 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > @@ -188,6 +188,21 @@ int intel_plane_atomic_check_with_state(const struct
> > intel_crtc_state *old_crtc_
> > else
> > crtc_state->active_planes &= ~BIT(intel_plane->id);
> >
> > + /*
> > +* NV12 plane is not allowed to start from an odd position or
> > +* end on an odd position.
> > +*/
> > + if (state->fb && (DRM_FORMAT_NV12 == state->fb->format->format)) {
> > + if ((intel_state->base.src_w >> 16) & 1) {
> > + DRM_DEBUG_KMS("Invalid Source: Yuv format does not
> > support odd width\n");
> > + return -EINVAL;
> > + }
> > + if ((intel_state->base.src_x >> 16) & 1) {
> > + DRM_DEBUG_KMS("Invalid Source: Yuv format does not
> > support odd x pos\n");
> > + return -EINVAL;
> > + }
> > + }
> > +
> > return intel_plane_atomic_calc_changes(old_crtc_state,
> >&crtc_state->base,
> >old_plane_state,
> > --
> > 2.17.0.441.gb46fe60e1d-goog
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reject NV12 planes with odd width/start position
Quoting Fritz Koenig (2018-05-17 20:07:14)
> Planes with an odd width will appear to have an incorrect
> stride. When the start position is odd the controller
> can lock up.
>
> Signed-off-by: Fritz Koenig
> ---
>
> Hi,
>
> This appears to be a limitation of the hardware that is not being
> checked. Is this supported and am I not enabling it correctly?
>
>
> drivers/gpu/drm/i915/intel_atomic_plane.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 7481ce85746b..ca4553592ab9 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -188,6 +188,21 @@ int intel_plane_atomic_check_with_state(const struct
> intel_crtc_state *old_crtc_
> else
> crtc_state->active_planes &= ~BIT(intel_plane->id);
>
> + /*
> +* NV12 plane is not allowed to start from an odd position or
> +* end on an odd position.
> +*/
> + if (state->fb && (DRM_FORMAT_NV12 == state->fb->format->format)) {
> + if ((intel_state->base.src_w >> 16) & 1) {
> + DRM_DEBUG_KMS("Invalid Source: Yuv format does not
> support odd width\n");
It may seem obvious from the message that src_w is odd, but it's always
nice to include as much information as possible for debugging; in this
case "%x", src_w.
if ((intel_state->base.src_w | intel_state->base.src_x) & BIT(16)) ?
I'd leave that question of style to Ville though.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits
On Gen8+ this register is not priviledged and we want to use it in
Mesa to implement a feature required by GPA called Null Hardware. The
idea is to have the command parser turn 3DPRIMITIVE/GPGPU_WALKER into
NOOPs.
This patch just whitelists the bits that we need and that are
currently not used by the kernel.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 8
drivers/gpu/drm/i915/i915_reg.h| 3 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 95478db9998b..1db6447460eb 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -534,6 +534,14 @@ struct drm_i915_reg_descriptor {
{ .addr = _reg ## _UDW(idx) }
static const struct drm_i915_reg_descriptor gen7_render_regs[] = {
+ REG32(INSTPM,
+ .mask = ~((INSTPM_3D_STATE_INSTRUCTION_DISABLE |
+INSTPM_3D_RENDERING_INSTRUCTION_DISABLE |
+INSTPM_3D_MEDIA_INSTRUCTION_DISABLE) << 16 |
+ (INSTPM_3D_STATE_INSTRUCTION_DISABLE |
+INSTPM_3D_RENDERING_INSTRUCTION_DISABLE |
+INSTPM_3D_MEDIA_INSTRUCTION_DISABLE)),
+ .value = 0),
REG64(GPGPU_THREADS_DISPATCHED),
REG64(HS_INVOCATION_COUNT),
REG64(DS_INVOCATION_COUNT),
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 196a0eb79272..2db9b6a177d9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2531,6 +2531,9 @@ enum i915_power_well_id {
#define INSTPM_FORCE_ORDERING(1<<7) /* GEN6+
*/
#define INSTPM_TLB_INVALIDATE(1<<9)
#define INSTPM_SYNC_FLUSH(1<<5)
+#define INSTPM_3D_MEDIA_INSTRUCTION_DISABLE (1<<3) /* GEN6+ */
+#define INSTPM_3D_RENDERING_INSTRUCTION_DISABLE (1<<2) /* GEN6+ */
+#define INSTPM_3D_STATE_INSTRUCTION_DISABLE (1<<1) /* GEN6+ */
#define ACTHD _MMIO(0x20c8)
#define MEM_MODE _MMIO(0x20cc)
#define MEM_DISPLAY_B_TRICKLE_FEED_DISABLE (1<<3) /* 830 only */
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Rename the remaining gen4 references to g4x in the DP code
On Thu, May 17, 2018 at 08:49:27PM +0300, Jani Nikula wrote:
> On Thu, 17 May 2018, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > i965 does not have native DP. Let's rename the remaining gen4 references
> > in the DP code to g4x.
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Jani Nikula
Thanks. Entire series pushed to dinq.
>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 10 +-
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index cd4c60bfc4c2..102070940095 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -56,7 +56,7 @@ struct dp_link_dpll {
> > struct dpll dpll;
> > };
> >
> > -static const struct dp_link_dpll gen4_dpll[] = {
> > +static const struct dp_link_dpll g4x_dpll[] = {
> > { 162000,
> > { .p1 = 2, .p2 = 10, .n = 2, .m1 = 23, .m2 = 8 } },
> > { 27,
> > @@ -1550,8 +1550,8 @@ intel_dp_set_clock(struct intel_encoder *encoder,
> > int i, count = 0;
> >
> > if (IS_G4X(dev_priv)) {
> > - divisor = gen4_dpll;
> > - count = ARRAY_SIZE(gen4_dpll);
> > + divisor = g4x_dpll;
> > + count = ARRAY_SIZE(g4x_dpll);
> > } else if (HAS_PCH_SPLIT(dev_priv)) {
> > divisor = pch_dpll;
> > count = ARRAY_SIZE(pch_dpll);
> > @@ -3451,7 +3451,7 @@ static uint32_t chv_signal_levels(struct intel_dp
> > *intel_dp)
> > }
> >
> > static uint32_t
> > -gen4_signal_levels(uint8_t train_set)
> > +g4x_signal_levels(uint8_t train_set)
> > {
> > uint32_tsignal_levels = 0;
> >
> > @@ -3572,7 +3572,7 @@ intel_dp_set_signal_levels(struct intel_dp *intel_dp)
> > signal_levels = snb_cpu_edp_signal_levels(train_set);
> > mask = EDP_LINK_TRAIN_VOL_EMP_MASK_SNB;
> > } else {
> > - signal_levels = gen4_signal_levels(train_set);
> > + signal_levels = g4x_signal_levels(train_set);
> > mask = DP_VOLTAGE_MASK | DP_PRE_EMPHASIS_MASK;
> > }
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable LVDS on Radiant P845
On Fri, Mar 09, 2018 at 11:22:04PM +0100, Ondrej Zary wrote:
> Radiant P845 does not have LVDS, only VGA.
>
> Signed-off-by: Ondrej Zary
Since we failed with the VBT approach I've gone and pushed this
as is to dinq (with cc:stable and the bugzilla link added).
Thanks for the patch.
> ---
> drivers/gpu/drm/i915/intel_lvds.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index ef80499113ee..6939e63d8bae 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -819,6 +819,14 @@ static const struct dmi_system_id intel_no_lvds[] = {
> DMI_EXACT_MATCH(DMI_BOARD_NAME, "D525MW"),
> },
> },
> + {
> + .callback = intel_no_lvds_dmi_callback,
> + .ident = "Radiant P845",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Radiant Systems Inc"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "P845"),
> + },
> + },
>
> { } /* terminating entry */
> };
> --
> Ondrej Zary
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits
On 18/05/18 15:26, Lionel Landwerlin wrote: On Gen8+ this register is not priviledged and we want to use it in Mesa to implement a feature required by GPA called Null Hardware. The idea is to have the command parser turn 3DPRIMITIVE/GPGPU_WALKER into NOOPs. This patch just whitelists the bits that we need and that are currently not used by the kernel. One thing I don't really know is whether is should be considered an issue with the current command parser and therefore be backported as a fix. It would certainly make things easier because we can't really detect the behavior from userspace. - Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915: Use intel_fb_obj() everywhere
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone
Reviewed-by: Ville Syrjälä
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/intel_display.c | 19 ++-
drivers/gpu/drm/i915/intel_fbdev.c | 9 +
3 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 52515445ac40..e9b1b8df6ef5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1908,7 +1908,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
fbdev_fb->base.format->cpp[0] * 8,
fbdev_fb->base.modifier,
drm_framebuffer_read_refcount(&fbdev_fb->base));
- describe_obj(m, fbdev_fb->obj);
+ describe_obj(m, intel_fb_obj(&fbdev_fb->base));
seq_putc(m, '\n');
}
#endif
@@ -1926,7 +1926,7 @@ static int i915_gem_framebuffer_info(struct seq_file *m,
void *data)
fb->base.format->cpp[0] * 8,
fb->base.modifier,
drm_framebuffer_read_refcount(&fb->base));
- describe_obj(m, fb->obj);
+ describe_obj(m, intel_fb_obj(&fb->base));
seq_putc(m, '\n');
}
mutex_unlock(&dev->mode_config.fb_lock);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c9ec88acad9c..1b2cf631305e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2474,6 +2474,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
{
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
struct intel_rotation_info *rot_info = &intel_fb->rot_info;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
u32 gtt_offset_rotated = 0;
unsigned int max_size = 0;
int i, num_planes = fb->format->num_planes;
@@ -2538,7 +2539,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
* fb layout agrees with the fence layout. We already check
that the
* fb stride matches the fence stride elsewhere.
*/
- if (i == 0 && i915_gem_object_is_tiled(intel_fb->obj) &&
+ if (i == 0 && i915_gem_object_is_tiled(obj) &&
(x + width) * cpp > fb->pitches[i]) {
DRM_DEBUG_KMS("bad fb plane %d offset: 0x%x\n",
i, fb->offsets[i]);
@@ -2623,9 +2624,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
max_size = max(max_size, offset + size);
}
- if (max_size * tile_size > intel_fb->obj->base.size) {
+ if (max_size * tile_size > obj->base.size) {
DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu
bytes)\n",
- max_size * tile_size, intel_fb->obj->base.size);
+ max_size * tile_size, obj->base.size);
return -EINVAL;
}
@@ -14082,14 +14083,15 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
drm_framebuffer_cleanup(fb);
- i915_gem_object_lock(intel_fb->obj);
- WARN_ON(!intel_fb->obj->framebuffer_references--);
- i915_gem_object_unlock(intel_fb->obj);
+ i915_gem_object_lock(obj);
+ WARN_ON(!obj->framebuffer_references--);
+ i915_gem_object_unlock(obj);
- i915_gem_object_put(intel_fb->obj);
+ i915_gem_object_put(obj);
kfree(intel_fb);
}
@@ -14098,8 +14100,7 @@ static int intel_user_framebuffer_create_handle(struct
drm_framebuffer *fb,
struct drm_file *file,
unsigned int *handle)
{
- struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
- struct drm_i915_gem_object *obj = intel_fb->obj;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
if (obj->userptr.mm) {
DRM_DEBUG("attempting to use a userptr for a framebuffer,
denied\n");
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index e9e02b58b7be..fb2f9fce34cd 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -47,7 +47,7 @@
static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
{
- struct drm_i915_gem_object *obj = ifbdev->fb->obj;
+ struct dr
[Intel-gfx] [PATCH v3 2/2] drm/i915: Move GEM BO inside drm_framebuffer
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
v2: Only hold a single reference per framebuffer, not per plane. (Ville)
v3: Drop NULL check in intel_fb_obj. (Ville)
Signed-off-by: Daniel Stone
Reviewed-by: Ville Syrjälä
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 3 +--
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1b2cf631305e..12226a2c8d39 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14370,9 +14370,9 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
i, fb->pitches[i], stride_alignment);
goto err;
}
- }
- intel_fb->obj = obj;
+ fb->obj[i] = &obj->base;
+ }
ret = intel_fill_fb_info(dev_priv, fb);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 12002fc77235..9cb1dc219af8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -194,7 +194,6 @@ enum intel_output_type {
struct intel_framebuffer {
struct drm_framebuffer base;
- struct drm_i915_gem_object *obj;
struct intel_rotation_info rot_info;
/* for each plane in the normal GTT view */
@@ -1005,7 +1004,7 @@ struct cxsr_latency {
#define to_intel_framebuffer(x) container_of(x, struct intel_framebuffer, base)
#define to_intel_plane(x) container_of(x, struct intel_plane, base)
#define to_intel_plane_state(x) container_of(x, struct intel_plane_state, base)
-#define intel_fb_obj(x) (x ? to_intel_framebuffer(x)->obj : NULL)
+#define intel_fb_obj(x) ((x) ? to_intel_bo((x)->obj[0]) : NULL)
struct intel_hdmi {
i915_reg_t hdmi_reg;
--
2.17.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits
Quoting Lionel Landwerlin (2018-05-18 15:29:21) > On 18/05/18 15:26, Lionel Landwerlin wrote: > > On Gen8+ this register is not priviledged and we want to use it in > > Mesa to implement a feature required by GPA called Null Hardware. The > > idea is to have the command parser turn 3DPRIMITIVE/GPGPU_WALKER into > > NOOPs. > > > > This patch just whitelists the bits that we need and that are > > currently not used by the kernel. > > > > One thing I don't really know is whether is should be considered an > issue with the current command parser and therefore be backported as a fix. > It would certainly make things easier because we can't really detect the > behavior from userspace. You can always bump the cmdparser version. The cmdparser doesn't no-op, it just rejects if a command is outside the whitelist, right? It would be detectable... The key question is whether INSTPM is context saved on gen7. A test in gem_exec_parse to confirm we allow INSTPM in the command parser and that one context does not leak to another would be useful. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
On 18/05/2018 15:13, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 13:36:52) On 18/05/2018 13:28, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 12:50:41) On 18/05/2018 12:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-18 12:05:17) On 18/05/2018 11:09, Chris Wilson wrote: Inside the live_hangcheck (reset) selftests, we occasionally see failures like <7>[ 239.094840] i915_gem_set_wedged rcs0 <7>[ 239.094843] i915_gem_set_wedged current seqno 19a98, last 19a9a, hangcheck 0 [5158 ms] <7>[ 239.094846] i915_gem_set_wedged Reset count: 6239 (global 1) <7>[ 239.094848] i915_gem_set_wedged Requests: <7>[ 239.095052] i915_gem_set_wedged first 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095056] i915_gem_set_wedged last 19a9a [e81:1a] prio=139 @ 5159ms: igt/rcs0[5977]/1 <7>[ 239.095059] i915_gem_set_wedged active 19a99 [e8c:5f] prio=1024 @ 5159ms: (null) <7>[ 239.095062] i915_gem_set_wedged [head 0220, postfix 0280, tail 02a8, batch 0x_] <7>[ 239.100050] i915_gem_set_wedged ring->start: 0x00283000 <7>[ 239.100053] i915_gem_set_wedged ring->head: 0x01f8 <7>[ 239.100055] i915_gem_set_wedged ring->tail: 0x02a8 <7>[ 239.100057] i915_gem_set_wedged ring->emit: 0x02a8 <7>[ 239.100059] i915_gem_set_wedged ring->space: 0x0f10 <7>[ 239.100085] i915_gem_set_wedged RING_START: 0x00283000 <7>[ 239.100088] i915_gem_set_wedged RING_HEAD: 0x0260 <7>[ 239.100091] i915_gem_set_wedged RING_TAIL: 0x02a8 <7>[ 239.100094] i915_gem_set_wedged RING_CTL: 0x0001 <7>[ 239.100097] i915_gem_set_wedged RING_MODE: 0x0300 [idle] <7>[ 239.100100] i915_gem_set_wedged RING_IMR: fefe <7>[ 239.100104] i915_gem_set_wedged ACTHD: 0x_609c <7>[ 239.100108] i915_gem_set_wedged BBADDR: 0x_609d <7>[ 239.100111] i915_gem_set_wedged DMA_FADDR: 0x_00283260 <7>[ 239.100114] i915_gem_set_wedged IPEIR: 0x <7>[ 239.100117] i915_gem_set_wedged IPEHR: 0x0280 <7>[ 239.100120] i915_gem_set_wedged Execlist status: 0x00044052 0002 <7>[ 239.100124] i915_gem_set_wedged Execlist CSB read 5 [5 cached], write 5 [5 from hws], interrupt posted? no, tasklet queued? no (enabled) <7>[ 239.100128] i915_gem_set_wedged ELSP[0] count=1, ring->start=00283000, rq: 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100132] i915_gem_set_wedged ELSP[1] count=1, ring->start=00257000, rq: 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100135] i915_gem_set_wedged HW active? 0x5 <7>[ 239.100250] i915_gem_set_wedged E 19a99 [e8c:5f] prio=1024 @ 5164ms: (null) <7>[ 239.100338] i915_gem_set_wedged E 19a9a [e81:1a] prio=139 @ 5164ms: igt/rcs0[5977]/1 <7>[ 239.100340] i915_gem_set_wedged Queue priority: 139 <7>[ 239.100343] i915_gem_set_wedged Q 0 [e98:19] prio=132 @ 5164ms: igt/rcs0[5977]/8 <7>[ 239.100346] i915_gem_set_wedged Q 0 [e84:19] prio=121 @ 5165ms: igt/rcs0[5977]/2 <7>[ 239.100349] i915_gem_set_wedged Q 0 [e87:19] prio=82 @ 5165ms: igt/rcs0[5977]/3 <7>[ 239.100352] i915_gem_set_wedged Q 0 [e84:1a] prio=44 @ 5164ms: igt/rcs0[5977]/2 <7>[ 239.100356] i915_gem_set_wedged Q 0 [e8b:19] prio=20 @ 5165ms: igt/rcs0[5977]/4 <7>[ 239.100362] i915_gem_set_wedged drv_selftest [5894] waiting for 19a99 where the GPU saw an arbitration point and idles; AND HAS NOT BEEN RESET! The RING_MODE indicates that is idle and has the STOP_RING bit set, so try clearing it. v2: Only clear the bit on restarting the ring, as we want to be sure the STOP_RING bit is kept if reset fails on wedging. v3: Spot when the ring state doesn't make sense when re-initialising the engine and dump it to the logs so that we don't have to wait for an error later and try to guess what happened earlier. v4: Prepare to print all the unexpected state, not just the first. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 3744f5750624..ba8411ba4abf 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1781,6 +1781,9 @@ static void enable_execlists(struct intel_engine_cs *engine) I915_WRITE(RING_MODE_GEN7(engine), _MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE)); + I915_WRITE(RING_MI_MODE(engine->mmio_base), +_MASKED_BIT_DISABLE(STOP_RING)); Worries me a bit to clear it un
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset
== Series Details == Series: drm/i915: Flush the ring stop bit after clearing RING_HEAD in reset URL : https://patchwork.freedesktop.org/series/43404/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4205_full -> Patchwork_9047_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9047_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9047_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/43404/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9047_full: === IGT changes === Possible regressions igt@gem_exec_await@wide-contexts: shard-apl: PASS -> FAIL Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: SKIP -> PASS +1 igt@gem_exec_schedule@deep-vebox: shard-kbl: PASS -> SKIP +1 igt@kms_plane_lowres@pipe-c-tiling-x: shard-apl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9047_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@dpms-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@plain-flip-ts-check-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +1 igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc: shard-glk: PASS -> FAIL (fdo#103167, fdo#104724) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip@2x-plain-flip-fb-recreate-interruptible: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: shard-apl: DMESG-FAIL (fdo#105602, fdo#103558) -> PASS igt@kms_pipe_crc_basic@hang-read-crc-pipe-c: shard-apl: DMESG-WARN (fdo#105602, fdo#103558) -> PASS +9 igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 9) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4205 -> Patchwork_9047 CI_DRM_4205: 921a7738e856643993ea0889dd5a936c22151649 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4487: eccae1360d6d01e73c6af2bd97122cef708207ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9047: e01c159ce05bb1471d058ca945d5d386a2fe9512 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4487: 6ab75f7eb5e1dccbb773e1739beeb2d7cbd6ad0d @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9047/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits
== Series Details == Series: drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits URL : https://patchwork.freedesktop.org/series/43420/ State : warning == Summary == $ dim checkpatch origin/drm-tip 2fac9bc00108 drm/i915/cmdparser: Whitelist INSTPM instruction parsing disable bits -:44: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #44: FILE: drivers/gpu/drm/i915/i915_reg.h:2534: +#define INSTPM_3D_MEDIA_INSTRUCTION_DISABLE (1<<3) /* GEN6+ */ ^ -:45: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #45: FILE: drivers/gpu/drm/i915/i915_reg.h:2535: +#define INSTPM_3D_RENDERING_INSTRUCTION_DISABLE (1<<2) /* GEN6+ */ ^ -:46: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #46: FILE: drivers/gpu/drm/i915/i915_reg.h:2536: +#define INSTPM_3D_STATE_INSTRUCTION_DISABLE (1<<1) /* GEN6+ */ ^ total: 0 errors, 0 warnings, 3 checks, 23 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/1] drm/i915: Consult VBT "LVDS config" bits to determine whether internal LVDS is present
From: Ville Syrjälä
VBT seems to have some bits to tell us whether the internal LVDS port
has something hooked up. In theory one might expect the VBT to not have
a child device for the LVDS port if there's no panel hooked up, but
in practice many VBTs still add the child device. The "LVDS config" bits
seem more reliable though, so let's check those.
So far we've used the "LVDS config" bits to check for eDP support on
ILK+, and disable the internal LVDS when the value is 3. That value
is actually documented as "Both internal LVDS and SDVO LVDS", but in
practice it looks to mean "eDP" on all the ilk+ VBTs I've seen. So let's
keep that interpretation, but for pre-ILK we will consider the value
3 to also indicate the presence of the internal LVDS.
Currently we have 25 DMI matches for the "no internal LVDS" quirk. In an
effort to reduce that let's toss in a WARN when the DMI match and VBT
both tell us that the internal LVDS is not present. The hope is that
people will report a bug, and then we can just nuke the corresponding
entry from the DMI quirk list. Credits to Jani for this idea.
v2: Split the basic int_lvds_support thing to a separate patch (Jani)
v3: Rebase
v4: Limit this to VBT version >= 134
Cc: Jani Nikula
Cc: Ondrej Zary
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_bios.c | 28 +---
drivers/gpu/drm/i915/intel_lvds.c | 5 -
drivers/gpu/drm/i915/intel_vbt_defs.h | 2 +-
3 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 5c863e2714ec..26b59118ef7b 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -518,9 +518,31 @@ parse_driver_features(struct drm_i915_private *dev_priv,
if (!driver)
return;
- if (INTEL_GEN(dev_priv) >= 5 &&
- driver->lvds_config == BDB_DRIVER_FEATURE_EDP)
- dev_priv->vbt.int_lvds_support = 0;
+ if (INTEL_GEN(dev_priv) >= 5) {
+ /*
+* Note that we consider BDB_DRIVER_FEATURE_INT_SDVO_LVDS
+* to mean "eDP". The VBT spec doesn't agree with that
+* interpretation, but real world VBTs seem to.
+*/
+ if (driver->lvds_config != BDB_DRIVER_FEATURE_INT_LVDS)
+ dev_priv->vbt.int_lvds_support = 0;
+ } else {
+ /*
+* FIXME it's not clear which BDB version has the LVDS config
+* bits defined. Revision history in the VBT spec says:
+* "0.92 | Add two definitions for VBT value of LVDS Active
+* Config (00b and 11b values defined) | 06/13/2005"
+* but does not the specify the BDB version.
+*
+* So far version 134 (on i945gm) is the oldest VBT observed
+* in the wild with the bits correctly populated. Version
+* 108 (on i85x) does not have the bits correctly populated.
+*/
+ if (bdb->version >= 134 &&
+ driver->lvds_config != BDB_DRIVER_FEATURE_INT_LVDS &&
+ driver->lvds_config != BDB_DRIVER_FEATURE_INT_SDVO_LVDS)
+ dev_priv->vbt.int_lvds_support = 0;
+ }
DRM_DEBUG_KMS("DRRS State Enabled:%d\n", driver->drrs_enabled);
/*
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index cda46bfa7041..a78d2b181819 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -973,8 +973,11 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
return;
/* Skip init on machines we know falsely report LVDS */
- if (dmi_check_system(intel_no_lvds))
+ if (dmi_check_system(intel_no_lvds)) {
+ WARN(!dev_priv->vbt.int_lvds_support,
+"Useless DMI match. Internal LVDS support disabled by
VBT\n");
return;
+ }
if (!dev_priv->vbt.int_lvds_support) {
DRM_DEBUG_KMS("Internal LVDS support disabled by VBT\n");
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 458468237b5f..39c804624179 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -635,7 +635,7 @@ struct bdb_sdvo_lvds_options {
#define BDB_DRIVER_FEATURE_NO_LVDS 0
#define BDB_DRIVER_FEATURE_INT_LVDS1
#define BDB_DRIVER_FEATURE_SDVO_LVDS 2
-#define BDB_DRIVER_FEATURE_EDP 3
+#define BDB_DRIVER_FEATURE_INT_SDVO_LVDS 3
struct bdb_driver_features {
u8 boot_dev_algorithm:1;
--
2.16.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver
Hi Neil,
2018-05-18 15:05 GMT+02:00 Neil Armstrong :
> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the
A minor nit, there is a "consensus" on tell cros-ec as "ChromeOS
Embedded Controller" or "ChromeOS EC". Yes, I know that you can see in
the kernel many other ways to refer to the ChromeOS EC, but to
standardize a little bit, could you replace all occurrences s/Chrome
OS/ChromeOS/. Thanks.
> driver for such feature of the Embedded Controller.
>
> This driver is part of the cros-ec MFD and will be add as a sub-device when
> the feature bit is exposed by the EC.
>
> The controller will only handle a single logical address and handles
> all the messages retries and will only expose Success or Error.
>
> The controller will be tied to the HDMI CEC notifier by using the platform
> DMI Data and the i915 device name and connector name.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/media/platform/Kconfig | 11 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/cros-ec-cec/Makefile | 1 +
> drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347
> +++
> 4 files changed, 361 insertions(+)
> create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
> create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c
>
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index c7a1cf8..e55a8ed2 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -546,6 +546,17 @@ menuconfig CEC_PLATFORM_DRIVERS
>
> if CEC_PLATFORM_DRIVERS
>
> +config VIDEO_CROS_EC_CEC
> + tristate "Chrome OS EC CEC driver"
here
> + depends on MFD_CROS_EC || COMPILE_TEST
> + select CEC_CORE
> + select CEC_NOTIFIER
> + ---help---
> + If you say yes here you will get support for the
> + Chrome OS Embedded Controller's CEC.
here
> + The CEC bus is present in the HDMI connector and enables
> communication
> + between compatible devices.
> +
> config VIDEO_MESON_AO_CEC
> tristate "Amlogic Meson AO CEC driver"
> depends on ARCH_MESON || COMPILE_TEST
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index 932515d..830696f 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -92,3 +92,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+=
> qcom/camss-8x16/
> obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
>
> obj-y += meson/
> +
> +obj-y += cros-ec-cec/
> diff --git a/drivers/media/platform/cros-ec-cec/Makefile
> b/drivers/media/platform/cros-ec-cec/Makefile
> new file mode 100644
> index 000..9ce97f9
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_VIDEO_CROS_EC_CEC) += cros-ec-cec.o
> diff --git a/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> new file mode 100644
> index 000..7e1e275
> --- /dev/null
> +++ b/drivers/media/platform/cros-ec-cec/cros-ec-cec.c
> @@ -0,0 +1,347 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * CEC driver for Chrome OS Embedded Controller
and here
> + *
> + * Copyright (c) 2018 BayLibre, SAS
> + * Author: Neil Armstrong
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRV_NAME "cros-ec-cec"
> +
> +/**
> + * struct cros_ec_cec - Driver data for EC CEC
> + *
> + * @cros_ec: Pointer to EC device
> + * @notifier: Notifier info for responding to EC events
> + * @adap: CEC adapter
> + * @notify: CEC notifier pointer
> + * @rx_msg: storage for a received message
> + */
> +struct cros_ec_cec {
> + struct cros_ec_device *cros_ec;
> + struct notifier_block notifier;
> + struct cec_adapter *adap;
> + struct cec_notifier *notify;
> + struct cec_msg rx_msg;
> +};
> +
> +static void handle_cec_message(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint8_t *cec_message = cros_ec->event_data.data.cec_message;
> + unsigned int len = cros_ec->event_size;
> +
> + cros_ec_cec->rx_msg.len = len;
> + memcpy(cros_ec_cec->rx_msg.msg, cec_message, len);
> +
> + cec_received_msg(cros_ec_cec->adap, &cros_ec_cec->rx_msg);
> +}
> +
> +static void handle_cec_event(struct cros_ec_cec *cros_ec_cec)
> +{
> + struct cros_ec_device *cros_ec = cros_ec_cec->cros_ec;
> + uint32_t events = cros_ec->event_data.data.cec_events;
> +
> + if (events & EC_MKBP_CEC_SEND_OK)
> + cec_transmit_attempt_done(cros_ec_cec->adap,
> + CEC_TX_STATUS_OK);
> +
> + /* FW takes care of all retries, tell core to avoid m
