Re: [Intel-gfx] [PATCH v2] drm/i915/skl+: ddb allocation algorithm optimization
Hi, On 7/3/2018 4:56 AM, Rodrigo Vivi wrote: On Fri, Jun 29, 2018 at 03:13:35PM +0530, Mahesh Kumar wrote: This patch implements new DDB allocation algorithm as per HW team recommendation. This algo takecare of scenario where we allocate less DDB for the planes with lower relative pixel rate, but they require more DDB to work. It also takes care of enabling same watermark level for each Usually "It also" in a commit message is a good indication that we should be doing more than one patch. Enabling same watermark level for each plane in CRTC is byproduct of this algorithm. But Agree will rework on patch and try to break it as much as possible. I think I should Add old cover letter as well to explain what is new algo optimization all about. plane in crtc, for efficient power saving. This algorithm uses fixed ddb allocation for cursor planes. Ealier version of this patch reverted due to regression. And it was root caused to following: New algorithm required more DDB for cursor plane but as cursor plane has fixed allocation it's DDB was not sufficient and WM level-0 was getting disabled, resulting in blank screen. Now we use old DDB allocation logic only for cursor plane. I really don't see on spec old and new DDB allocation logics. Actually now spec have 2 method for DDB allocation (Added based on our request). So new Algorithm is nothing but second method of allocation logic. Only thing different for cursor that I see there is that a workaround on watermark calculation where "For each plane, except cursor..." "Number of planes, except cursor..." This is not what I see in this patch, but maybe because the patch is too big. so for each plane we first calculate WM then try to find maximum level that can be enabled with available DDB for pipe and distribute DDB accordingly. but for cursor Now I'm allocating DDB first (8block or 32 blocks based on number of CRTC similar to old method) that is the difference from previous version of patch. Changes: - add reason for revert in commit msg (Maarten) - Fix checkpatch checks Testcase: igt/kms_plane_multiple Signed-off-by: Mahesh Kumar Cc: Rodrigo Vivi Well, since I'm on cc and I was the one that reverted that because I noticed on my own machine I opened this patch for review many times here already, but I gave up completely every time because this patch is hard to review. Agree, My bad, will try to split this patch but I'm afraid main patch still be lengthy please bare with me. So this time I won't fully give up and at least put some comments... So, overall it is hard to match the spec differences because this patch is trying to do all at once. Smaller patches should be better. --- drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/intel_pm.c | 376 +++- 2 files changed, 219 insertions(+), 162 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2b684f431c60..f5d636a6d121 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1212,8 +1212,9 @@ struct skl_ddb_values { struct skl_wm_level { bool plane_en; - uint16_t plane_res_b; - uint8_t plane_res_l; + u16 plane_res_b; + u8 plane_res_l; + u16 min_dbuf_req; }; /* Stores plane specific WM parameters */ diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 533e6886..d1564a08a202 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3802,17 +3802,37 @@ static unsigned int intel_get_ddb_size(struct drm_i915_private *dev_priv, return ddb_size; } +static int +skl_get_num_pipes_active(struct drm_i915_private *dev_priv, +const struct intel_crtc_state *cstate) +{ + struct drm_atomic_state *state = cstate->base.state; + const struct intel_atomic_state *intel_state; + int num_active; + + if (WARN_ON(!state) || !cstate->base.active) + return hweight32(dev_priv->active_crtcs); + + intel_state = to_intel_atomic_state(state); + + if (intel_state->active_pipe_changes) + num_active = hweight32(intel_state->active_crtcs); + else + num_active = hweight32(dev_priv->active_crtcs); + + return num_active; +} This entire function here is something that should come in a separated patch. This is new change in this version. I should have created separate patch. will do so. + static void -skl_ddb_get_pipe_allocation_limits(struct drm_device *dev, +skl_ddb_get_pipe_allocation_limits(struct drm_i915_private *dev_priv, const struct intel_crtc_state *cstate, const unsigned int total_data_rate, struct skl_ddb_allocation *ddb, - struct skl_ddb_entry *alloc, /* out */ -
[Intel-gfx] [PULL] gvt-fixes for 4.18
Hi, Here's two gvt fixes for 4.18. One is for guest warning to change virtual transcoder mode for DVI to align with our virtual display, and one to fix possible partial GGTT entry update from guest. thanks -- The following changes since commit 7a3727f385dc64773db1c144f6b15c1e9d4735bb: drm/i915: Enable provoking vertex fix on Gen9 systems. (2018-06-19 15:48:24 +0300) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-fixes-2018-07-03 for you to fetch changes up to a4cae23cc05ccec749c2fc70fa9d8cda7c582319: drm/i915/gvt: changed DDI mode emulation type (2018-07-02 11:09:59 +0800) gvt-fixes-2018-07-03 - replace virtual transcoder mode as DVI to fix guest warning (Xiaolin) - fix partial GGTT entry write (Yan) Xiaolin Zhang (1): drm/i915/gvt: changed DDI mode emulation type Zhao Yan (1): drm/i915/gvt: fix a bug of partially write ggtt enties drivers/gpu/drm/i915/gvt/display.c | 6 ++-- drivers/gpu/drm/i915/gvt/gtt.c | 58 ++ drivers/gpu/drm/i915/gvt/gtt.h | 2 ++ 3 files changed, 63 insertions(+), 3 deletions(-) -- 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
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_pipe_crc_basic: expect setting bad source to fail
Hi, On 7/2/2018 4:57 PM, Maarten Lankhorst wrote: Op 02-07-18 om 13:16 schreef Mahesh Kumar: Now crc-core framework verifies the source string passed by the user. So setting bad-source will fail. Expect file write to fail in bad-source subtest of kms_pipe_crc_basic. Signed-off-by: Mahesh Kumar --- tests/kms_pipe_crc_basic.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c index 235fdc38..2d4dfee8 100644 --- a/tests/kms_pipe_crc_basic.c +++ b/tests/kms_pipe_crc_basic.c @@ -48,8 +48,7 @@ static struct { static void test_bad_source(data_t *data) { - igt_assert(igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo")); - igt_assert(openat(data->debugfs, "crtc-0/crc/data", O_WRONLY) == -1); + igt_assert(!igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo")); } #define N_CRCS 3 New behavior makes more sense. Reviewed-by: Maarten Lankhorst Do you have igt commit rights? thanks for review. I don't have commit rights -Mahesh ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
Hi Ville, Can we please get this merged to DINQ? Regards, Abhay -Original Message- From: Du, Wenkai Sent: Thursday, June 21, 2018 1:16 PM To: Kumar, Abhay ; intel-gfx@lists.freedesktop.org; Syrjala, Ville Cc: Nikula, Jani Subject: Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled On 6/21/2018 11:43 AM, Kumar, Abhay wrote: > + Wenkai > > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > Behalf Of Abhay Kumar > Sent: Tuesday, June 19, 2018 3:01 PM > To: intel-gfx@lists.freedesktop.org; Syrjala, Ville > > Cc: Nikula, Jani > Subject: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on > glk/cnl when audio power is enabled > > From: Ville Syrjälä > > CDCLK has to be at least twice the BLCK regardless of audio. Audio driver has > to probe using this hook and increase the clock even in absence of any > display. > > v2: Use atomic refcount for get_power, put_power so that we can > call each once(Abhay). > v3: Reset power well 2 to avoid any transaction on iDisp link > during cdclk change(Abhay). > v4: Remove Power well 2 reset workaround(Ville). > v5: Remove unwanted Power well 2 register defined in v4(Abhay). > > Signed-off-by: Ville Syrjälä > Signed-off-by: Abhay Kumar Tested-by: Wenkai Du > --- > drivers/gpu/drm/i915/i915_drv.h | 3 ++ > drivers/gpu/drm/i915/intel_audio.c | 67 > +--- > drivers/gpu/drm/i915/intel_cdclk.c | 29 +--- > drivers/gpu/drm/i915/intel_display.c | 7 +++- > drivers/gpu/drm/i915/intel_drv.h | 2 ++ > 5 files changed, 83 insertions(+), 25 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > b/drivers/gpu/drm/i915/i915_drv.h index 6104d7115054..a4a386a5db69 > 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1702,6 +1702,7 @@ struct drm_i915_private { > unsigned int hpll_freq; > unsigned int fdi_pll_freq; > unsigned int czclk_freq; > + u32 get_put_refcount; > > struct { > /* > @@ -1719,6 +1720,8 @@ struct drm_i915_private { > struct intel_cdclk_state actual; > /* The current hardware cdclk state */ > struct intel_cdclk_state hw; > + > + int force_min_cdclk; > } cdclk; > > /** > diff --git a/drivers/gpu/drm/i915/intel_audio.c > b/drivers/gpu/drm/i915/intel_audio.c > index 3ea566f99450..ca8f04c7cbb3 100644 > --- a/drivers/gpu/drm/i915/intel_audio.c > +++ b/drivers/gpu/drm/i915/intel_audio.c > @@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder > *encoder, > > if (!connector->eld[0]) > return; > - > DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n", >connector->base.id, >connector->name, > @@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct drm_i915_private > *dev_priv) > } > } > > +static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv, > + bool enable) > +{ > + struct drm_modeset_acquire_ctx ctx; > + struct drm_atomic_state *state; > + int ret; > + > + drm_modeset_acquire_init(&ctx, 0); > + state = drm_atomic_state_alloc(&dev_priv->drm); > + if (WARN_ON(!state)) > + return; > + > + state->acquire_ctx = &ctx; > + > +retry: > + to_intel_atomic_state(state)->modeset = true; > + to_intel_atomic_state(state)->cdclk.force_min_cdclk = > + enable ? 2 * 96000 : 0; > + > + /* > + * Protects dev_priv->cdclk.force_min_cdclk > + * Need to lock this here in case we have no active pipes > + * and thus wouldn't lock it during the commit otherwise. > + */ > + ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex, > &ctx); > + if (!ret) > + ret = drm_atomic_commit(state); > + > + if (ret == -EDEADLK) { > + drm_atomic_state_clear(state); > + drm_modeset_backoff(&ctx); > + goto retry; > + } > + > + WARN_ON(ret); > + > + drm_atomic_state_put(state); > + > + drm_modeset_drop_locks(&ctx); > + drm_modeset_acquire_fini(&ctx); > +} > + > static void i915_audio_component_get_power(struct device *kdev) { > - intel_display_power_get(kdev_to_i915(kdev), POWER_DOMAIN_AUDIO); > + struct drm_i915_private *dev_priv = kdev_to_i915(kdev); > + > + dev_priv->get_put_refcount++; > + > + /* Force cdclk to 2*BCLK during first time get power call */ > + if (dev_priv->get_put_refcount == 1) > + if (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) > + glk_force_audio_cdclk(dev_priv, true); > + > + intel_display_power_get(dev_priv, POWER_DOMAIN_AUDIO); > } > > static void i915_audio_component_put_power(struct device *kdev) { > - intel_displa
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Optimize the read/write fence_reg on SNB+
== Series Details == Series: drm/i915: Optimize the read/write fence_reg on SNB+ URL : https://patchwork.freedesktop.org/series/45801/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4417_full -> Patchwork_9503_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9503_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9503_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9503_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd2: shard-kbl: PASS -> SKIP igt@kms_cursor_legacy@cursor-vs-flip-legacy: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9503_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-glk: PASS -> INCOMPLETE (fdo#107094) igt@drv_selftest@mock_scatterlist: shard-kbl: NOTRUN -> DMESG-WARN (fdo#103667) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) +2 igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-hsw: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: FAIL (fdo#102887) -> PASS igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#107094 https://bugs.freedesktop.org/show_bug.cgi?id=107094 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4417 -> Patchwork_9503 CI_DRM_4417: e781af726c3ad36c18cc21203189459dd2cbdd43 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9503: e8b6a25966721c297a1d15b6c0749775bcc086cb @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9503/shards.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: write fence reg only once on VGPU
Hi Zhao, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on v4.18-rc3 next-20180702] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Zhao-Yakui/drm-i915-the-Read-Write-optimization-of-fence-reg/20180703-102412 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-randconfig-x073-201826 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): In file included from include/linux/kernel.h:10:0, from include/linux/list.h:9, from include/linux/agp_backend.h:33, from include/drm/drmP.h:35, from drivers/gpu/drm/i915/i915_gem_fence_reg.c:24: drivers/gpu/drm/i915/i915_gem_fence_reg.c: In function 'i965_write_fence_reg': drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:25: error: 'i915' undeclared (first use in this function); did you mean 'to_i915'? if (intel_vgpu_active(i915)) ^ include/linux/compiler.h:58:30: note: in definition of macro '__trace_if' if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ ^~~~ >> drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:3: note: in expansion of macro >> 'if' if (intel_vgpu_active(i915)) ^~ drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:25: note: each undeclared identifier is reported only once for each function it appears in if (intel_vgpu_active(i915)) ^ include/linux/compiler.h:58:30: note: in definition of macro '__trace_if' if (__builtin_constant_p(!!(cond)) ? !!(cond) : \ ^~~~ >> drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:3: note: in expansion of macro >> 'if' if (intel_vgpu_active(i915)) ^~ vim +/if +98 drivers/gpu/drm/i915/i915_gem_fence_reg.c > 24 #include 25 #include 26 #include "i915_drv.h" 27 28 /** 29 * DOC: fence register handling 30 * 31 * Important to avoid confusions: "fences" in the i915 driver are not execution 32 * fences used to track command completion but hardware detiler objects which 33 * wrap a given range of the global GTT. Each platform has only a fairly limited 34 * set of these objects. 35 * 36 * Fences are used to detile GTT memory mappings. They're also connected to the 37 * hardware frontbuffer render tracking and hence interact with frontbuffer 38 * compression. Furthermore on older platforms fences are required for tiled 39 * objects used by the display engine. They can also be used by the render 40 * engine - they're required for blitter commands and are optional for render 41 * commands. But on gen4+ both display (with the exception of fbc) and rendering 42 * have their own tiling state bits and don't need fences. 43 * 44 * Also note that fences only support X and Y tiling and hence can't be used for 45 * the fancier new tiling formats like W, Ys and Yf. 46 * 47 * Finally note that because fences are such a restricted resource they're 48 * dynamically associated with objects. Furthermore fence state is committed to 49 * the hardware lazily to avoid unnecessary stalls on gen2/3. Therefore code must 50 * explicitly call i915_gem_object_get_fence() to synchronize fencing status 51 * for cpu access. Also note that some code wants an unfenced view, for those 52 * cases the fence can be removed forcefully with i915_gem_object_put_fence(). 53 * 54 * Internally these functions will synchronize with userspace access by removing 55 * CPU ptes into GTT mmaps (not the GTT ptes themselves) as needed. 56 */ 57 58 #define pipelined 0 59 60 static void i965_write_fence_reg(struct drm_i915_fence_reg *fence, 61 struct i915_vma *vma) 62 { 63 i915_reg_t fence_reg_lo, fence_reg_hi; 64 int fence_pitch_shift; 65 u64 val; 66 struct drm_i915_private *dev_priv = fence->i915; 67 68 if (INTEL_GEN(fence->i915) >= 6) { 69 fence_reg_lo = FENCE_REG_GEN6_LO(fence->id); 70 fence_reg_hi = FENCE_REG_GEN6_HI(fence->id); 71 fence_pitch_shift = GEN6_FENCE_PITCH_SHIFT; 72 73 } else { 74 fence_reg_lo = FENCE_REG_965_LO(fence->id); 75 fenc
Re: [Intel-gfx] [PATCH 2/2] drm/i915: write fence reg only once on VGPU
Hi Zhao, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.18-rc3 next-20180702] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Zhao-Yakui/drm-i915-the-Read-Write-optimization-of-fence-reg/20180703-102412 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-randconfig-x074-201826 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/gpu//drm/i915/i915_gem_fence_reg.c: In function 'i965_write_fence_reg': >> drivers/gpu//drm/i915/i915_gem_fence_reg.c:98:25: error: 'i915' undeclared >> (first use in this function); did you mean 'to_i915'? if (intel_vgpu_active(i915)) ^~~~ to_i915 drivers/gpu//drm/i915/i915_gem_fence_reg.c:98:25: note: each undeclared identifier is reported only once for each function it appears in vim +98 drivers/gpu//drm/i915/i915_gem_fence_reg.c 59 60 static void i965_write_fence_reg(struct drm_i915_fence_reg *fence, 61 struct i915_vma *vma) 62 { 63 i915_reg_t fence_reg_lo, fence_reg_hi; 64 int fence_pitch_shift; 65 u64 val; 66 struct drm_i915_private *dev_priv = fence->i915; 67 68 if (INTEL_GEN(fence->i915) >= 6) { 69 fence_reg_lo = FENCE_REG_GEN6_LO(fence->id); 70 fence_reg_hi = FENCE_REG_GEN6_HI(fence->id); 71 fence_pitch_shift = GEN6_FENCE_PITCH_SHIFT; 72 73 } else { 74 fence_reg_lo = FENCE_REG_965_LO(fence->id); 75 fence_reg_hi = FENCE_REG_965_HI(fence->id); 76 fence_pitch_shift = I965_FENCE_PITCH_SHIFT; 77 } 78 79 val = 0; 80 if (vma) { 81 unsigned int stride = i915_gem_object_get_stride(vma->obj); 82 83 GEM_BUG_ON(!i915_vma_is_map_and_fenceable(vma)); 84 GEM_BUG_ON(!IS_ALIGNED(vma->node.start, I965_FENCE_PAGE)); 85 GEM_BUG_ON(!IS_ALIGNED(vma->fence_size, I965_FENCE_PAGE)); 86 GEM_BUG_ON(!IS_ALIGNED(stride, 128)); 87 88 val = (vma->node.start + vma->fence_size - I965_FENCE_PAGE) << 32; 89 val |= vma->node.start; 90 val |= (u64)((stride / 128) - 1) << fence_pitch_shift; 91 if (i915_gem_object_get_tiling(vma->obj) == I915_TILING_Y) 92 val |= BIT(I965_FENCE_TILING_Y_SHIFT); 93 val |= I965_FENCE_REG_VALID; 94 } 95 96 if (INTEL_GEN(fence->i915) >= 6) { 97 /* Use the 64-bit RW to read/write fence reg on SNB+ */ > 98 if (intel_vgpu_active(i915)) 99 I915_WRITE64_FW(fence_reg_lo, val); 100 else { 101 I915_WRITE64_FW(fence_reg_lo, 0); 102 I915_READ64(fence_reg_lo); 103 104 I915_WRITE64_FW(fence_reg_lo, val); 105 I915_READ64(fence_reg_lo); 106 } 107 } else { 108 /* To w/a incoherency with non-atomic 64-bit register updates, 109 * we split the 64-bit update into two 32-bit writes. In order 110 * for a partial fence not to be evaluated between writes, we 111 * precede the update with write to turn off the fence register, 112 * and only enable the fence as the last step. 113 * 114 * For extra levels of paranoia, we make sure each step lands 115 * before applying the next step. 116 */ 117 I915_WRITE(fence_reg_lo, 0); 118 POSTING_READ(fence_reg_lo); 119 120 I915_WRITE(fence_reg_hi, upper_32_bits(val)); 121 I915_WRITE(fence_reg_lo, lower_32_bits(val)); 122 POSTING_READ(fence_reg_lo); 123 } 124 } 125 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ 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: Optimize the read/write fence_reg on SNB+
== Series Details == Series: drm/i915: Optimize the read/write fence_reg on SNB+ URL : https://patchwork.freedesktop.org/series/45801/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4417 -> Patchwork_9503 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9503 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9503, 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/45801/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9503: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9503 that come from known issues: === IGT changes === Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 == Participating hosts (45 -> 40) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4417 -> Patchwork_9503 CI_DRM_4417: e781af726c3ad36c18cc21203189459dd2cbdd43 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9503: e8b6a25966721c297a1d15b6c0749775bcc086cb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e8b6a2596672 drm/i915: write fence reg only once on VGPU 51157a4ce265 drm/i915: Use 64-bit to Read/Write fence reg on SNB+ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9503/issues.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: Optimize the read/write fence_reg on SNB+
== Series Details == Series: drm/i915: Optimize the read/write fence_reg on SNB+ URL : https://patchwork.freedesktop.org/series/45801/ State : warning == Summary == $ dim checkpatch origin/drm-tip 51157a4ce265 drm/i915: Use 64-bit to Read/Write fence reg on SNB+ e8b6a2596672 drm/i915: write fence reg only once on VGPU -:30: CHECK:BRACES: Unbalanced braces around else statement #30: FILE: drivers/gpu/drm/i915/i915_gem_fence_reg.c:100: + else { total: 0 errors, 0 warnings, 1 checks, 20 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: write fence reg only once on VGPU
On VGPU scenario the read/write operation of fence_reg will be trapped by the GVT-g. And then gvt-g follows the HW spec to write the fence_reg. So it is unnecessary to read/write fence reg several times. This will help to reduce the unnecessary trap of fence_reg mmio operation. V1->V2: Fix one typo error of parameter when calling intel_vgpu_active Signed-off-by: Zhao Yakui --- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c b/drivers/gpu/drm/i915/i915_gem_fence_reg.c index d92fe03..9c97976 100644 --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c @@ -95,11 +95,15 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg *fence, if (INTEL_GEN(fence->i915) >= 6) { /* Use the 64-bit RW to read/write fence reg on SNB+ */ - I915_WRITE64_FW(fence_reg_lo, 0); - I915_READ64(fence_reg_lo); - - I915_WRITE64_FW(fence_reg_lo, val); - I915_READ64(fence_reg_lo); + if (intel_vgpu_active(dev_priv)) + I915_WRITE64_FW(fence_reg_lo, val); + else { + I915_WRITE64_FW(fence_reg_lo, 0); + I915_READ64(fence_reg_lo); + + I915_WRITE64_FW(fence_reg_lo, val); + I915_READ64(fence_reg_lo); + } } else { /* To w/a incoherency with non-atomic 64-bit register updates, * we split the 64-bit update into two 32-bit writes. In order -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/2] drm/i915: Optimize the read/write fence_reg on SNB+
V1->V2: Fix one typo error. Zhao Yakui (2): drm/i915: Use 64-bit to Read/Write fence reg on SNB+ drm/i915: write fence reg only once on VGPU drivers/gpu/drm/i915/i915_gem_fence_reg.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) -- 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/2] drm/i915: Use 64-bit to Read/Write fence reg on SNB+
Based on HW spec the fence reg on SNB+ is defined as 64-bit. Just follow the b-spec to use 64-bit read/write mode. Signed-off-by: Zhao Yakui --- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c b/drivers/gpu/drm/i915/i915_gem_fence_reg.c index d548ac0..d92fe03 100644 --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c @@ -63,6 +63,7 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg *fence, i915_reg_t fence_reg_lo, fence_reg_hi; int fence_pitch_shift; u64 val; + struct drm_i915_private *dev_priv = fence->i915; if (INTEL_GEN(fence->i915) >= 6) { fence_reg_lo = FENCE_REG_GEN6_LO(fence->id); @@ -92,9 +93,14 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg *fence, val |= I965_FENCE_REG_VALID; } - if (!pipelined) { - struct drm_i915_private *dev_priv = fence->i915; + if (INTEL_GEN(fence->i915) >= 6) { + /* Use the 64-bit RW to read/write fence reg on SNB+ */ + I915_WRITE64_FW(fence_reg_lo, 0); + I915_READ64(fence_reg_lo); + I915_WRITE64_FW(fence_reg_lo, val); + I915_READ64(fence_reg_lo); + } else { /* To w/a incoherency with non-atomic 64-bit register updates, * we split the 64-bit update into two 32-bit writes. In order * for a partial fence not to be evaluated between writes, we -- 2.7.4 ___ 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: write fence reg only once on VGPU
>-Original Message- >From: Zhao, Yakui >Sent: Tuesday, July 3, 2018 10:22 AM >To: intel-gfx@lists.freedesktop.org >Cc: zhen...@linux.intel.com; Zhao, Yakui >Subject: [PATCH 2/2] drm/i915: write fence reg only once on VGPU > >On VGPU scenario the read/write operation of fence_reg will be trapped by >the GVT-g. And then gvt-g follows the HW spec to write the fence_reg. >So it is unnecessary to read/write fence reg several times. This will help to >reduce the unnecessary trap of fence_reg mmio operation. > Sorry for one typo. The V2 will be sent. >Signed-off-by: Zhao Yakui >--- > drivers/gpu/drm/i915/i915_gem_fence_reg.c | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) > >diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c >b/drivers/gpu/drm/i915/i915_gem_fence_reg.c >index d92fe03..55bf6d9 100644 >--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c >+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c >@@ -95,11 +95,15 @@ static void i965_write_fence_reg(struct >drm_i915_fence_reg *fence, > > if (INTEL_GEN(fence->i915) >= 6) { > /* Use the 64-bit RW to read/write fence reg on SNB+ */ >- I915_WRITE64_FW(fence_reg_lo, 0); >- I915_READ64(fence_reg_lo); >- >- I915_WRITE64_FW(fence_reg_lo, val); >- I915_READ64(fence_reg_lo); >+ if (intel_vgpu_active(i915)) >+ I915_WRITE64_FW(fence_reg_lo, val); >+ else { >+ I915_WRITE64_FW(fence_reg_lo, 0); >+ I915_READ64(fence_reg_lo); >+ >+ I915_WRITE64_FW(fence_reg_lo, val); >+ I915_READ64(fence_reg_lo); >+ } > } else { > /* To w/a incoherency with non-atomic 64-bit register updates, >* we split the 64-bit update into two 32-bit writes. In order >-- >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: failure for drm/i915: the Read/Write optimization of fence reg
== Series Details == Series: drm/i915: the Read/Write optimization of fence reg URL : https://patchwork.freedesktop.org/series/45800/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/i915_gem_fence_reg.o drivers/gpu/drm/i915/i915_gem_fence_reg.c: In function ‘i965_write_fence_reg’: drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:25: error: ‘i915’ undeclared (first use in this function); did you mean ‘to_i915’? if (intel_vgpu_active(i915)) ^~~~ to_i915 drivers/gpu/drm/i915/i915_gem_fence_reg.c:98:25: note: each undeclared identifier is reported only once for each function it appears in scripts/Makefile.build:317: recipe for target 'drivers/gpu/drm/i915/i915_gem_fence_reg.o' failed make[4]: *** [drivers/gpu/drm/i915/i915_gem_fence_reg.o] Error 1 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1034: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: write fence reg only once on VGPU
On VGPU scenario the read/write operation of fence_reg will be trapped by the GVT-g. And then gvt-g follows the HW spec to write the fence_reg. So it is unnecessary to read/write fence reg several times. This will help to reduce the unnecessary trap of fence_reg mmio operation. Signed-off-by: Zhao Yakui --- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c b/drivers/gpu/drm/i915/i915_gem_fence_reg.c index d92fe03..55bf6d9 100644 --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c @@ -95,11 +95,15 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg *fence, if (INTEL_GEN(fence->i915) >= 6) { /* Use the 64-bit RW to read/write fence reg on SNB+ */ - I915_WRITE64_FW(fence_reg_lo, 0); - I915_READ64(fence_reg_lo); - - I915_WRITE64_FW(fence_reg_lo, val); - I915_READ64(fence_reg_lo); + if (intel_vgpu_active(i915)) + I915_WRITE64_FW(fence_reg_lo, val); + else { + I915_WRITE64_FW(fence_reg_lo, 0); + I915_READ64(fence_reg_lo); + + I915_WRITE64_FW(fence_reg_lo, val); + I915_READ64(fence_reg_lo); + } } else { /* To w/a incoherency with non-atomic 64-bit register updates, * we split the 64-bit update into two 32-bit writes. In order -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] drm/i915: the Read/Write optimization of fence reg
Zhao Yakui (2): drm/i915: Use 64-bit to Read/Write fence reg on SNB+ drm/i915: write fence reg only once on VGPU drivers/gpu/drm/i915/i915_gem_fence_reg.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Use 64-bit to Read/Write fence reg on SNB+
Based on HW spec the fence reg on SNB+ is defined as 64-bit. Just follow the b-spec to use 64-bit read/write mode. Signed-off-by: Zhao Yakui --- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c b/drivers/gpu/drm/i915/i915_gem_fence_reg.c index d548ac0..d92fe03 100644 --- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c @@ -63,6 +63,7 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg *fence, i915_reg_t fence_reg_lo, fence_reg_hi; int fence_pitch_shift; u64 val; + struct drm_i915_private *dev_priv = fence->i915; if (INTEL_GEN(fence->i915) >= 6) { fence_reg_lo = FENCE_REG_GEN6_LO(fence->id); @@ -92,9 +93,14 @@ static void i965_write_fence_reg(struct drm_i915_fence_reg *fence, val |= I965_FENCE_REG_VALID; } - if (!pipelined) { - struct drm_i915_private *dev_priv = fence->i915; + if (INTEL_GEN(fence->i915) >= 6) { + /* Use the 64-bit RW to read/write fence reg on SNB+ */ + I915_WRITE64_FW(fence_reg_lo, 0); + I915_READ64(fence_reg_lo); + I915_WRITE64_FW(fence_reg_lo, val); + I915_READ64(fence_reg_lo); + } else { /* To w/a incoherency with non-atomic 64-bit register updates, * we split the 64-bit update into two 32-bit writes. In order * for a partial fence not to be evaluated between writes, we -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/skl+: ddb allocation algorithm optimization
On Fri, Jun 29, 2018 at 03:13:35PM +0530, Mahesh Kumar wrote: > This patch implements new DDB allocation algorithm as per HW team > recommendation. This algo takecare of scenario where we allocate less DDB > for the planes with lower relative pixel rate, but they require more DDB > to work. > It also takes care of enabling same watermark level for each Usually "It also" in a commit message is a good indication that we should be doing more than one patch. > plane in crtc, for efficient power saving. > This algorithm uses fixed ddb allocation for cursor planes. > > Ealier version of this patch reverted due to regression. And it was root > caused to following: > New algorithm required more DDB for cursor plane but as cursor plane has > fixed allocation it's DDB was not sufficient and WM level-0 was getting > disabled, resulting in blank screen. Now we use old DDB allocation logic > only for cursor plane. I really don't see on spec old and new DDB allocation logics. Only thing different for cursor that I see there is that a workaround on watermark calculation where "For each plane, except cursor..." "Number of planes, except cursor..." This is not what I see in this patch, but maybe because the patch is too big. > > Changes: > - add reason for revert in commit msg (Maarten) > - Fix checkpatch checks > > Testcase: igt/kms_plane_multiple > Signed-off-by: Mahesh Kumar > Cc: Rodrigo Vivi Well, since I'm on cc and I was the one that reverted that because I noticed on my own machine I opened this patch for review many times here already, but I gave up completely every time because this patch is hard to review. So this time I won't fully give up and at least put some comments... So, overall it is hard to match the spec differences because this patch is trying to do all at once. Smaller patches should be better. > --- > drivers/gpu/drm/i915/i915_drv.h | 5 +- > drivers/gpu/drm/i915/intel_pm.c | 376 > +++- > 2 files changed, 219 insertions(+), 162 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 2b684f431c60..f5d636a6d121 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1212,8 +1212,9 @@ struct skl_ddb_values { > > struct skl_wm_level { > bool plane_en; > - uint16_t plane_res_b; > - uint8_t plane_res_l; > + u16 plane_res_b; > + u8 plane_res_l; > + u16 min_dbuf_req; > }; > > /* Stores plane specific WM parameters */ > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 533e6886..d1564a08a202 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3802,17 +3802,37 @@ static unsigned int intel_get_ddb_size(struct > drm_i915_private *dev_priv, > return ddb_size; > } > > +static int > +skl_get_num_pipes_active(struct drm_i915_private *dev_priv, > + const struct intel_crtc_state *cstate) > +{ > + struct drm_atomic_state *state = cstate->base.state; > + const struct intel_atomic_state *intel_state; > + int num_active; > + > + if (WARN_ON(!state) || !cstate->base.active) > + return hweight32(dev_priv->active_crtcs); > + > + intel_state = to_intel_atomic_state(state); > + > + if (intel_state->active_pipe_changes) > + num_active = hweight32(intel_state->active_crtcs); > + else > + num_active = hweight32(dev_priv->active_crtcs); > + > + return num_active; > +} This entire function here is something that should come in a separated patch. > + > static void > -skl_ddb_get_pipe_allocation_limits(struct drm_device *dev, > +skl_ddb_get_pipe_allocation_limits(struct drm_i915_private *dev_priv, > const struct intel_crtc_state *cstate, > const unsigned int total_data_rate, > struct skl_ddb_allocation *ddb, > -struct skl_ddb_entry *alloc, /* out */ > -int *num_active /* out */) > +int num_active, > +struct skl_ddb_entry *alloc /* out */) you don't need to invert the order when removing the pointer... but again, all this num_active seems to be in a separated patch > { > struct drm_atomic_state *state = cstate->base.state; > struct intel_atomic_state *intel_state = to_intel_atomic_state(state); > - struct drm_i915_private *dev_priv = to_i915(dev); > struct drm_crtc *for_crtc = cstate->base.crtc; > unsigned int pipe_size, ddb_size; > int nth_active_pipe; > @@ -3820,17 +3840,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device > *dev, > if (WARN_ON(!state) || !cstate->base.active) { > alloc->start = 0; > alloc->end = 0; > - *num_active = hweight32(dev_priv->active_
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Show who pinned the pages when a leak is hit (rev3)
== Series Details == Series: drm/i915: Show who pinned the pages when a leak is hit (rev3) URL : https://patchwork.freedesktop.org/series/45770/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4417_full -> Patchwork_9501_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9501_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9501_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9501_full: === IGT changes === Possible regressions igt@kms_universal_plane@cursor-fb-leak-pipe-b: shard-apl: PASS -> FAIL Warnings igt@gem_exec_schedule@deep-render: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9501_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: NOTRUN -> INCOMPLETE (fdo#103665) shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@drv_selftest@mock_scatterlist: shard-kbl: NOTRUN -> DMESG-WARN (fdo#103667) igt@gem_exec_schedule@pi-ringfull-render: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@gem_workarounds@suspend-resume-context: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_cursor_legacy@cursorb-vs-flipb-varying-size: shard-glk: PASS -> DMESG-WARN (fdo#105763) +1 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-hsw: PASS -> FAIL (fdo#99912) igt@prime_vgem@basic-fence-flip: shard-apl: PASS -> FAIL (fdo#104008) Possible fixes igt@kms_atomic_transition@1x-modeset-transitions-nonblocking-fencing: shard-glk: FAIL (fdo#105703) -> PASS igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: FAIL (fdo#103355) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: FAIL (fdo#102887) -> PASS igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS +1 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103667 https://bugs.freedesktop.org/show_bug.cgi?id=103667 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105703 https://bugs.freedesktop.org/show_bug.cgi?id=105703 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4417 -> Patchwork_9501 CI_DRM_4417: e781af726c3ad36c18cc21203189459dd2cbdd43 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9501: 5b98af961955ee65cce7cc3a70892d3809240398 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9501/shards.html ___ 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: Show who pinned the pages when a leak is hit (rev3)
== Series Details == Series: drm/i915: Show who pinned the pages when a leak is hit (rev3) URL : https://patchwork.freedesktop.org/series/45770/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4417 -> Patchwork_9501 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45770/revisions/3/mbox/ == Known issues == Here are the changes found in Patchwork_9501 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 == Participating hosts (45 -> 40) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4417 -> Patchwork_9501 CI_DRM_4417: e781af726c3ad36c18cc21203189459dd2cbdd43 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9501: 5b98af961955ee65cce7cc3a70892d3809240398 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5b98af961955 drm/i915: Show who pinned the pages when a leak is hit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9501/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Show who pinned the pages when a leak is hit (rev3)
== Series Details == Series: drm/i915: Show who pinned the pages when a leak is hit (rev3) URL : https://patchwork.freedesktop.org/series/45770/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Show who pinned the pages when a leak is hit -drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3666: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] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Show who pinned the pages when a leak is hit (rev3)
== Series Details == Series: drm/i915: Show who pinned the pages when a leak is hit (rev3) URL : https://patchwork.freedesktop.org/series/45770/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5b98af961955 drm/i915: Show who pinned the pages when a leak is hit -:209: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #209: FILE: drivers/gpu/drm/i915/i915_gem_object.h:253: + spinlock_t debug_lock; total: 0 errors, 0 warnings, 1 checks, 200 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Show who pinned the pages when a leak is hit
Currently, we emit a warning when freeing an object if we do so with the pages still pinned (presumably as they are still in use somewhere). This only tells us that there is a problem, but doesn't tell us anything about the object or who might be pinning them and so provides no clue as to track down the problem. Let's try tracking everyone who pins the pages to see if we strike it lucky and catch the culprit red handed. v2: Suppress oom warnings, they will happen given sufficient abuse. References: https://bugs.freedesktop.org/show_bug.cgi?id=105360 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 1 + drivers/gpu/drm/i915/i915_drv.h| 2 + drivers/gpu/drm/i915/i915_gem.c| 5 +- drivers/gpu/drm/i915/i915_gem_object.c | 109 + drivers/gpu/drm/i915/i915_gem_object.h | 34 5 files changed, 150 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 9de8b1c51a5c..84052becb279 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -43,6 +43,7 @@ config DRM_I915_DEBUG_GEM bool "Insert extra checks into the GEM internals" default n depends on DRM_I915_WERROR +select STACKDEPOT help Enable extra sanity checks (including BUGs) along the GEM driver paths that may slow the system down and if hit hang the machine. diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2cefe4c30f88..cc334a0fc91d 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2990,6 +2990,8 @@ i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) { might_lock(&obj->mm.lock); + track_i915_gem_object_pin_pages(obj); + if (atomic_inc_not_zero(&obj->mm.pages_pin_count)) return 0; diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 048b722cf27c..749f5f5a31f8 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2465,6 +2465,7 @@ void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj, if (!IS_ERR(pages)) obj->ops->put_pages(obj, pages); + untrack_i915_gem_object_pin_pages(obj); unlock: mutex_unlock(&obj->mm.lock); } @@ -4876,8 +4877,10 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915, if (obj->ops->release) obj->ops->release(obj); - if (WARN_ON(i915_gem_object_has_pinned_pages(obj))) + if (WARN_ON(i915_gem_object_has_pinned_pages(obj))) { + show_i915_gem_object_pin_pages(obj); atomic_set(&obj->mm.pages_pin_count, 0); + } __i915_gem_object_put_pages(obj, I915_MM_NORMAL); GEM_BUG_ON(i915_gem_object_has_pages(obj)); diff --git a/drivers/gpu/drm/i915/i915_gem_object.c b/drivers/gpu/drm/i915/i915_gem_object.c index aab8cdd80e6d..39b1e84bf494 100644 --- a/drivers/gpu/drm/i915/i915_gem_object.c +++ b/drivers/gpu/drm/i915/i915_gem_object.c @@ -25,6 +25,115 @@ #include "i915_drv.h" #include "i915_gem_object.h" +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) + +#include + +#define STACKDEPTH 12 + +void track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) +{ + unsigned long entries[STACKDEPTH]; + struct stack_trace trace = { + .entries = entries, + .max_entries = ARRAY_SIZE(entries), + .skip = 1 + }; + unsigned long flags; + depot_stack_handle_t stack, *stacks; + + save_stack_trace(&trace); + if (trace.nr_entries && + trace.entries[trace.nr_entries - 1] == ULONG_MAX) + trace.nr_entries--; + + stack = depot_save_stack(&trace, GFP_KERNEL | __GFP_NOWARN); + if (!stack) + return; + + spin_lock_irqsave(&obj->mm.debug_lock, flags); + stacks = krealloc(obj->mm.debug_owners, + (obj->mm.debug_count + 1) * sizeof(*stacks), + GFP_NOWAIT | __GFP_NOWARN); + if (stacks) { + stacks[obj->mm.debug_count++] = stack; + obj->mm.debug_owners = stacks; + } + spin_unlock_irqrestore(&obj->mm.debug_lock, flags); +} + +void untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) +{ + depot_stack_handle_t *stacks; + unsigned long flags; + + spin_lock_irqsave(&obj->mm.debug_lock, flags); + stacks = fetch_and_zero(&obj->mm.debug_owners); + obj->mm.debug_count = 0; + spin_unlock_irqrestore(&obj->mm.debug_lock, flags); + + kfree(stacks); +} + +static int cmphandle(const void *_a, const void *_b) +{ + const depot_stack_handle_t * const a = _a, * const b = _b; + + if (*a < *b) + return -1; + else if (*a > *b)
Re: [Intel-gfx] [PATCH] usb/icl: Work around ACPI boottime crash
Quoting Imre Deak (2018-07-02 14:57:56) > Work around the following boot time crash: > > [ 10.456056] CPU: 1 PID: 220 Comm: systemd-udevd Tainted: GW > 4.17.0-rc7-CI-CI_DRM_4040+ #182 > [ 10.465828] Hardware name: Intel Corporation Ice Lake Client > Platform/IceLake U DDR4 SODIMM PD RVP, BIOS > +ICLSFWR1.R00.2204.A00.1805172221 05/17/2018 > [ 10.479168] RIP: 0010:acpi_ps_complete_this_op+0xa7/0x22a > [ 10.484627] RSP: 0018:c93a7578 EFLAGS: 00010202 > [ 10.489881] RAX: 6b6b6b6b6b6b6b6b RBX: 8804abeda9c8 RCX: > 0020 > [ 10.497045] RDX: RSI: 88049e604a68 RDI: > > [ 10.504213] RBP: R08: 8804abeda9c8 R09: > > [ 10.511376] R10: R11: R12: > 000e > [ 10.518542] R13: 88049e604a68 R14: 88049e604a68 R15: > a00263c2 > [ 10.525713] FS: 7ff6d85f18c0() GS:8804be88() > knlGS: > [ 10.533839] CS: 0010 DS: ES: CR0: 80050033 > [ 10.539616] CR2: 7ff6d73cff40 CR3: 00049f794001 CR4: > 00760ee0 > [ 10.546783] DR0: DR1: DR2: > > [ 10.553949] DR3: DR6: fffe0ff0 DR7: > 0400 > [ 10.561112] PKRU: 5554 > [ 10.563849] Call Trace: > [ 10.566323] acpi_ps_complete_op+0x49/0x3f1 > [ 10.570537] acpi_ps_parse_loop+0x94c/0x9bb > [ 10.574754] ? acpi_ds_delete_walk_state+0x113/0x131 > [ 10.579750] acpi_ps_parse_aml+0x1a2/0x4af > [ 10.583875] acpi_ps_execute_method+0x1e9/0x2a5 > [ 10.588435] acpi_ns_evaluate+0x2e4/0x42c > [ 10.592473] acpi_evaluate_object+0x1fd/0x3a8 > [ 10.596873] usb_acpi_find_companion+0xee/0x1f0 [usbcore] > [ 10.602319] acpi_platform_notify+0x33/0xa0 > [ 10.606532] device_add+0x197/0x600 > [ 10.610048] ? __init_waitqueue_head+0x36/0x50 > [ 10.614529] usb_hub_create_port_device+0x11d/0x340 [usbcore] > [ 10.620314] hub_probe+0x9a5/0x1010 [usbcore] > [ 10.624701] ? _raw_spin_unlock_irqrestore+0x51/0x60 > [ 10.629730] usb_probe_interface+0x13f/0x300 [usbcore] > [ 10.634900] driver_probe_device+0x302/0x470 > [ 10.639198] ? __driver_attach+0xe0/0xe0 > [ 10.643147] bus_for_each_drv+0x59/0x90 > [ 10.647013] __device_attach+0xb7/0x130 > [ 10.650878] bus_probe_device+0x9c/0xb0 > [ 10.654745] device_add+0x3c5/0x600 > [ 10.658270] usb_set_configuration+0x540/0x880 [usbcore] > [ 10.663621] generic_probe+0x28/0x80 [usbcore] > [ 10.668097] driver_probe_device+0x302/0x470 > [ 10.672393] ? __driver_attach+0xe0/0xe0 > [ 10.676346] bus_for_each_drv+0x59/0x90 > [ 10.680211] __device_attach+0xb7/0x130 > [ 10.684076] bus_probe_device+0x9c/0xb0 > [ 10.687940] device_add+0x3c5/0x600 > [ 10.691464] usb_new_device+0x269/0x490 [usbcore] > [ 10.696206] usb_add_hcd+0x558/0x850 [usbcore] > [ 10.700682] xhci_pci_probe+0x13d/0x240 [xhci_pci] > [ 10.705534] pci_device_probe+0xa1/0x130 > [ 10.709484] driver_probe_device+0x302/0x470 > [ 10.713784] __driver_attach+0xb9/0xe0 > [ 10.717562] ? driver_probe_device+0x470/0x470 > [ 10.722033] ? driver_probe_device+0x470/0x470 > [ 10.726505] bus_for_each_dev+0x64/0x90 > [ 10.730370] ? preempt_count_sub+0x92/0xd0 > [ 10.734495] bus_add_driver+0x164/0x260 > [ 10.738362] ? 0xa004e000 > [ 10.741704] driver_register+0x57/0xc0 > [ 10.745482] ? 0xa004e000 > [ 10.748824] do_one_initcall+0x4a/0x350 > [ 10.752690] ? do_init_module+0x22/0x20a > [ 10.756643] ? rcu_read_lock_sched_held+0x74/0x80 > [ 10.761377] ? kmem_cache_alloc_trace+0x284/0x2e0 > [ 10.766114] do_init_module+0x5b/0x20a > [ 10.769895] load_module+0x250d/0x2b20 > [ 10.773678] ? kernel_read+0x2c/0x40 > [ 10.777285] ? __se_sys_finit_module+0xaa/0xc0 > [ 10.781759] __se_sys_finit_module+0xaa/0xc0 > [ 10.786061] do_syscall_64+0x54/0x190 > [ 10.789752] entry_SYSCALL_64_after_hwframe+0x49/0xbe > [ 10.794831] RIP: 0033:0x7ff6d74664d9 > [ 10.798430] RSP: 002b:7ffd91e7dd78 EFLAGS: 0246 ORIG_RAX: > 0139 > [ 10.806033] RAX: ffda RBX: 560519bfae20 RCX: > 7ff6d74664d9 > [ 10.813195] RDX: RSI: 7ff6d795ce23 RDI: > 000e > [ 10.820360] RBP: 7ff6d795ce23 R08: R09: > > [ 10.827523] R10: 000e R11: 0246 R12: > > [ 10.834690] R13: 560519bf9a30 R14: 0002 R15: > 0aba9500 > [ 10.841862] Code: c2 10 5f ea 81 48 c7 c6 f0 5e ea 81 bf 7c 00 00 00 e8 0d > 7c 00 00 31 ed e9 88 01 00 00 48 8b 03 31 ed 48 85 c0 > +0f 84 e9 00 00 00 <4c> 8b 60 28 4d 85 e4 0f 84 dc 00 00 00 0f b7 78 0a e8 62 > fe ff > [ 10.860832] RIP: acpi_ps_complete_this_op+0xa7/0x22a RSP: c93a7578 > [ 10.867907] ---[ end trace 3a0d2ee1129bc71e ]--- > > Cc: Chris Wils
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2)
== Series Details == Series: drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2) URL : https://patchwork.freedesktop.org/series/45580/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4413_full -> Patchwork_9500_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9500_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9500_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9500_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-render: shard-kbl: PASS -> SKIP igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9500_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_schedule@pi-ringfull-bsd2: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#102887) +1 igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#103822, fdo#104724) +1 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_workarounds@suspend-resume-context: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_flip@plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE -> FAIL (fdo#105347) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4413 -> Patchwork_9500 CI_DRM_4413: df42fb566d33f5889c8d61f9929d3e72d4a16813 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9500: 1a05980f45a6d7c09fdfdb2761611bee4803cdad @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9500/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 2/2] drm/i915: Wait for PSR exit before checking for vblank evasion
On Fri, 2018-06-29 at 16:26 -0700, Dhinakaran Pandiyan wrote: > On Wed, 2018-06-27 at 13:02 -0700, Tarun Vyas wrote: > > > > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, > > then > > the pipe_update_start call schedules itself out to check back > > later. > > > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 > > but > > lags w.r.t core kernel code, hot plugging an external display > > triggers > > tons of "potential atomic update errors" in the dmesg, on *pipe A*. > > A > > closer analysis reveals that we try to read the scanline 3 times > > and > > eventually timeout, b/c PSR hasn't exited fully leading to a > > PIPEDSL > > stuck @ 1599. This issue is not seen on upstream kernels, b/c for > > *some* > > reason we loop inside intel_pipe_update start for ~2+ msec which in > > this > > case is more than enough to exit PSR fully, hence an *unstuck* > > PIPEDSL > > counter, hence no error. On the other hand, the ChromeOS kernel > > spends > > ~1.1 msec looping inside intel_pipe_update_start and hence errors > > out > > b/c the source is still in PSR. > > > > Regardless, we should wait for PSR exit (if PSR is disabled, we > > incur > > a ~1-2 usec penalty) before reading the PIPEDSL, b/c if we haven't > > fully exited PSR, then checking for vblank evasion isn't actually > > applicable. > > > > v4: Comment explaining psr_wait after enabling VBL interrupts (DK) > > > > v5: CAN_PSR() to handle platforms that don't support PSR. > > > > v6: Handle local_irq_disable on early return (Chris) > > Series Reviewed-by: Dhinakaran Pandiyan > > > Daniel's questions were addressed over IRC, I'll push this version if > they aren't any other concerns. and pushed to -dinq with Daniel's irc ack. " ickle: danvet ack on the PSR wait_for_idle series? sure" ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/psr: Add psr1 live status
On Wed, 2018-06-27 at 13:38 +0530, vathsala nagaraju wrote: > From: Vathsala Nagaraju > > Prints live state of psr1.Extending the existing > PSR2 live state function to cover psr1. > > Tested on KBL with psr2 and psr1 panel. > > v2: rebase > v3: DK > Rename psr2_live_status to psr_source_status. > v4: DK > Move EDP_PSR_STATUS_STATE_SHIFT below EDP_PSR_STATUS_STATE_MASK. > Pass seq to psr_source_status, handle source status prints in > psr_source_status. > v5: Fixed CI warning messages > v6: > Remove extra space in the title before the colon.(DK) > Rebase. (Jani) > v7: Use tabs for indenting the values.(Jani) > v8: Addressed dk's review comments. > > Cc: Rodrigo Vivi > Cc: Dhinakaran Pandiyan > > Reviewed-by: Dhinakaran Pandiyan > Signed-off-by: Vathsala Nagaraju I have pushed this version to -dinq, thanks for addressing the reviews. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove unecessary check for unsupported modifiers for NV12
On Thu, 2018-06-28 at 11:36 -0700, Dhinakaran Pandiyan wrote: > On Thu, 2018-06-28 at 08:48 +0200, Daniel Vetter wrote: > > > > On Wed, Jun 27, 2018 at 11:18:54PM -0700, Dhinakaran Pandiyan > > wrote: > > > > > > > > > There is already a check to allow only RGB formats with CCS > > > modifiers. > > > > > > Signed-off-by: Dhinakaran Pandiyan > > > > > Reviewed-by: Daniel Vetter > > > Thanks for the reviews. Pushed this to -dinq. ___ 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: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev3)
== Series Details == Series: drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev3) URL : https://patchwork.freedesktop.org/series/45774/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4413_full -> Patchwork_9499_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9499_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9499_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9499_full: === IGT changes === Possible regressions igt@kms_available_modes_crc@available_mode_test_crc: shard-apl: PASS -> FAIL Warnings igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS +2 == Known issues == Here are the changes found in Patchwork_9499_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_big: shard-hsw: PASS -> INCOMPLETE (fdo#103540) +1 igt@gem_exec_schedule@pi-ringfull-bsd2: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105189) igt@kms_flip@2x-plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_flip_tiling@flip-y-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4413 -> Patchwork_9499 CI_DRM_4413: df42fb566d33f5889c8d61f9929d3e72d4a16813 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9499: e3d5d0eb50dde824f73f6ee82168f9d3b284bf71 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9499/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/gen11: Preempt-to-idle support in execlists.
On 29/06/18 09:50, Lis, Tomasz wrote: On 2018-06-11 18:37, Daniele Ceraolo Spurio wrote: On 25/05/18 11:26, Tomasz Lis wrote: The patch adds support of preempt-to-idle requesting by setting a proper bit within Execlist Control Register, and receiving preemption result from Context Status Buffer. Preemption in previous gens required a special batch buffer to be executed, so the Command Streamer never preempted to idle directly. In Icelake it is possible, as there is a hardware mechanism to inform the kernel about status of the preemption request. This patch does not cover using the new preemption mechanism when GuC is active. v2: Added needs_preempt_context() change so that it is not created when preempt-to-idle is supported. (Chris) Updated setting HWACK flag so that it is cleared after preempt-to-dle. (Chris, Daniele) Updated to use I915_ENGINE_HAS_PREEMPTION flag. (Chris) v3: Fixed needs_preempt_context() change. (Chris) Merged preemption trigger functions to one. (Chris) Fixed conyext state tonot assume COMPLETED_MASK after preemption, since idle-to-idle case will not have it set. v4: Simplified needs_preempt_context() change. (Daniele) Removed clearing HWACK flag in idle-to-idle preempt. (Daniele) Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc: Michal Winiarski Cc: Mika Kuoppala Bspec: 18922 Signed-off-by: Tomasz Lis --- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_gem_context.c | 3 +- drivers/gpu/drm/i915/i915_pci.c | 3 +- drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/intel_lrc.c | 113 +-- drivers/gpu/drm/i915/intel_lrc.h | 1 + 6 files changed, 86 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 487922f..35eddf7 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2534,6 +2534,8 @@ intel_info(const struct drm_i915_private *dev_priv) ((dev_priv)->info.has_logical_ring_elsq) #define HAS_LOGICAL_RING_PREEMPTION(dev_priv) \ ((dev_priv)->info.has_logical_ring_preemption) +#define HAS_HW_PREEMPT_TO_IDLE(dev_priv) \ + ((dev_priv)->info.has_hw_preempt_to_idle) #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 45393f6..341a5ff 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -455,7 +455,8 @@ destroy_kernel_context(struct i915_gem_context **ctxp) static bool needs_preempt_context(struct drm_i915_private *i915) { - return HAS_LOGICAL_RING_PREEMPTION(i915); + return HAS_LOGICAL_RING_PREEMPTION(i915) && + !HAS_HW_PREEMPT_TO_IDLE(i915); } int i915_gem_contexts_init(struct drm_i915_private *dev_priv) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index 97a91e6a..ee09926 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -593,7 +593,8 @@ static const struct intel_device_info intel_cannonlake_info = { GEN(11), \ .ddb_size = 2048, \ .has_csr = 0, \ - .has_logical_ring_elsq = 1 + .has_logical_ring_elsq = 1, \ + .has_hw_preempt_to_idle = 1 static const struct intel_device_info intel_icelake_11_info = { GEN11_FEATURES, diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index 933e316..4eb97b5 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -98,6 +98,7 @@ enum intel_platform { func(has_logical_ring_contexts); \ func(has_logical_ring_elsq); \ func(has_logical_ring_preemption); \ + func(has_hw_preempt_to_idle); \ func(has_overlay); \ func(has_pooled_eu); \ func(has_psr); \ diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 8a6058b..f95cb37 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -154,6 +154,7 @@ #define GEN8_CTX_STATUS_ACTIVE_IDLE (1 << 3) #define GEN8_CTX_STATUS_COMPLETE (1 << 4) #define GEN8_CTX_STATUS_LITE_RESTORE (1 << 15) +#define GEN11_CTX_STATUS_PREEMPT_IDLE (1 << 29) #define GEN8_CTX_STATUS_COMPLETED_MASK \ (GEN8_CTX_STATUS_COMPLETE | GEN8_CTX_STATUS_PREEMPTED) @@ -522,31 +523,46 @@ static void port_assign(struct execlist_port *port, struct i915_request *rq) static void inject_preempt_context(struct intel_engine_cs *engine) continuing the discussion from the previous patch, I still think that we should rename this function now that it doesn't inject a context on some gens. A new function name should be relatively trivial to handle from other patch series hitting the area (compared to having a second
Re: [Intel-gfx] [PATCH 10/10] drm/vmwgfx: Use drm_plane_mask() & co.
Reviewed-by: Sinclair Yeh I assume you'll upstream this as part of your series? On Tue, Jun 26, 2018 at 10:47:16PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Use drm_{plane,connector}_mask() where appropriate. > > Cc: VMware Graphics > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > index ef96ba7432ad..17e01423ead1 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c > @@ -535,9 +535,9 @@ int vmw_du_crtc_atomic_check(struct drm_crtc *crtc, >struct drm_crtc_state *new_state) > { > struct vmw_display_unit *du = vmw_crtc_to_du(new_state->crtc); > - int connector_mask = 1 << drm_connector_index(&du->connector); > + int connector_mask = drm_connector_mask(&du->connector); > bool has_primary = new_state->plane_mask & > -BIT(drm_plane_index(crtc->primary)); > +drm_plane_mask(crtc->primary); > > /* We always want to have an active plane with an active CRTC */ > if (has_primary != new_state->enable) > -- > 2.16.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 8/9] drm/tinydrm: Use drm_fbdev_generic_setup()
On 07/02/2018 08:54 AM, Noralf Trønnes wrote: Make full use of the generic fbdev client. Cc: David Lechner Signed-off-by: Noralf Trønnes --- Reviewed-by: David Lechner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 9/9] drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
On 07/02/2018 08:54 AM, Noralf Trønnes wrote: Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has moved to drm_fbdev_generic_setup(). Cc: Laurent Pinchart Signed-off-by: Noralf Trønnes --- Reviewed-by: David Lechner ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for usb/icl: Work around ACPI boottime crash
== Series Details == Series: usb/icl: Work around ACPI boottime crash URL : https://patchwork.freedesktop.org/series/45778/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4412_full -> Patchwork_9498_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_9498_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-apl: PASS -> FAIL (fdo#105347) igt@gem_tiled_fence_blits@normal: shard-snb: NOTRUN -> INCOMPLETE (fdo#105411) igt@gem_workarounds@suspend-resume-context: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_suspend@shrink: shard-glk: FAIL (fdo#106886) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105189) -> PASS igt@kms_flip@2x-plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#105363, fdo#102887) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@perf_pmu@busy-idle-no-semaphores-vecs0: shard-snb: INCOMPLETE (fdo#105411) -> SKIP fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4412 -> Patchwork_9498 CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9498: f195f00e11e20013ab321df784e9b806aefc81c6 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9498/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] Improve crc-core driver interface
+ Harry and Leo On Mon, Jul 2, 2018 at 7:07 AM, Mahesh Kumar wrote: > This series improves crc-core <-> driver interface. > This series adds following functionality in the crc-core > - Now control node will print all the available sources if >implemented by driver along with current source. > - Setting of sorce will fail if provided source is not supported > - cleanup of crtc_crc_open function first allocate memory before >enabling CRC generation > - Don't block open() call instead wait in crc read call. > > Following IGT will fail due to crc-core <-> driver interface change > igt@kms_pipe_crc_basic@bad-source > ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X > ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X-frame-sequence > In nonblocking crc tests we'll get lesser crc's due to skipping crc > > AMD/Rockchip/rcar code path is not validated and need inputs > > Changes: > - Add dri-devel in Cc > Changes rev2: > - now get_crc_sources returns a constant pointer to an array of >source list and crc-core does the verification > Changes rev3: > - reorg patches to push non r-b patches to the last > - add r-b tag > > Cc: dri-de...@lists.freedesktop.org > > Mahesh Kumar (10): > drm: crc: Introduce verify_crc_source callback > drm: crc: Introduce get_crc_sources callback > drm/rockchip/crc: Implement verify_crc_source callback > drm/amdgpu_dm/crc: Implement verify_crc_source callback > drm/rcar-du/crc: Implement verify_crc_source callback > drm/i915/crc: implement verify_crc_source callback > drm/i915/crc: implement get_crc_sources callback > drm/crc: Cleanup crtc_crc_open function > Revert "drm: crc: Wait for a frame before returning from open()" > drm: crc: Introduce pre_crc_read function > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 7 +- > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 20 +++- > drivers/gpu/drm/drm_debugfs_crc.c | 79 -- > drivers/gpu/drm/i915/intel_display.c | 2 + > drivers/gpu/drm/i915/intel_drv.h | 9 +- > drivers/gpu/drm/i915/intel_pipe_crc.c | 119 > - > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 45 +++- > drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 26 - > include/drm/drm_crtc.h | 48 - > 10 files changed, 305 insertions(+), 51 deletions(-) > > -- > 2.16.2 > > ___ > 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
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2)
== Series Details == Series: drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2) URL : https://patchwork.freedesktop.org/series/45580/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4413 -> Patchwork_9500 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45580/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9500 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#105128) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 == Participating hosts (45 -> 40) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4413 -> Patchwork_9500 CI_DRM_4413: df42fb566d33f5889c8d61f9929d3e72d4a16813 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9500: 1a05980f45a6d7c09fdfdb2761611bee4803cdad @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1a05980f45a6 drm/tilcdc: Use drm_connector_has_possible_encoder() 51b4ba4680b6 drm/msm: Use drm_connector_has_possible_encoder() f2e15e4ea45b drm: Add drm_connector_has_possible_encoder() a84c10f13c19 drm/radeon: Use drm_connector_for_each_possible_encoder() 8807427952c1 drm/nouveau: Use drm_connector_for_each_possible_encoder() 9ac85a361c63 drm/amdgpu: Use drm_connector_for_each_possible_encoder() c31cba14dcaa drm: Add drm_connector_for_each_possible_encoder() bd08e651f318 drm/i915: Nuke intel_mst_best_encoder() 27feace2e181 drm/fb-helper: Eliminate the .best_encoder() usage == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9500/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic-helper: Use old/new state in drm_atomic_helper_commit_planes_on_crtc()
On Wed, Jun 27, 2018 at 10:59:49AM +0200, Daniel Vetter wrote: > On Tue, Jun 26, 2018 at 11:41:44PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Update drm_atomic_helper_commit_planes_on_crtc() to use explicit old/new > > states instead of relying on obj->state. > > > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Daniel Vetter Thansk. Pushed to drm-misc-next. > > > --- > > drivers/gpu/drm/drm_atomic_helper.c | 15 ++- > > 1 file changed, 10 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > b/drivers/gpu/drm/drm_atomic_helper.c > > index e022cacdae34..8008a7de2e10 100644 > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > @@ -2342,11 +2342,13 @@ drm_atomic_helper_commit_planes_on_crtc(struct > > drm_crtc_state *old_crtc_state) > > const struct drm_crtc_helper_funcs *crtc_funcs; > > struct drm_crtc *crtc = old_crtc_state->crtc; > > struct drm_atomic_state *old_state = old_crtc_state->state; > > + struct drm_crtc_state *new_crtc_state = > > + drm_atomic_get_new_crtc_state(old_state, crtc); > > struct drm_plane *plane; > > unsigned plane_mask; > > > > plane_mask = old_crtc_state->plane_mask; > > - plane_mask |= crtc->state->plane_mask; > > + plane_mask |= new_crtc_state->plane_mask; > > > > crtc_funcs = crtc->helper_private; > > if (crtc_funcs && crtc_funcs->atomic_begin) > > @@ -2355,6 +2357,8 @@ drm_atomic_helper_commit_planes_on_crtc(struct > > drm_crtc_state *old_crtc_state) > > drm_for_each_plane_mask(plane, crtc->dev, plane_mask) { > > struct drm_plane_state *old_plane_state = > > drm_atomic_get_old_plane_state(old_state, plane); > > + struct drm_plane_state *new_plane_state = > > + drm_atomic_get_new_plane_state(old_state, plane); > > const struct drm_plane_helper_funcs *plane_funcs; > > > > plane_funcs = plane->helper_private; > > @@ -2362,13 +2366,14 @@ drm_atomic_helper_commit_planes_on_crtc(struct > > drm_crtc_state *old_crtc_state) > > if (!old_plane_state || !plane_funcs) > > continue; > > > > - WARN_ON(plane->state->crtc && plane->state->crtc != crtc); > > + WARN_ON(new_plane_state->crtc && > > + new_plane_state->crtc != crtc); > > > > - if (drm_atomic_plane_disabling(old_plane_state, plane->state) && > > + if (drm_atomic_plane_disabling(old_plane_state, > > new_plane_state) && > > plane_funcs->atomic_disable) > > plane_funcs->atomic_disable(plane, old_plane_state); > > - else if (plane->state->crtc || > > -drm_atomic_plane_disabling(old_plane_state, > > plane->state)) > > + else if (new_plane_state->crtc || > > +drm_atomic_plane_disabling(old_plane_state, > > new_plane_state)) > > plane_funcs->atomic_update(plane, old_plane_state); > > } > > > > -- > > 2.16.4 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- 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 01/10] drm: Add drm_plane_mask()
On Tue, Jun 26, 2018 at 01:09:53PM -0700, Rodrigo Vivi wrote: > On Tue, Jun 26, 2018 at 10:47:07PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Add drm_plane_mask() which returns the 1< > We already have an identical drm_crtc_mask() for crtcs. > > > > Mostly performed with coccinelle: > > @@ > > @@ > > - (1< > + drm_plane_mask( > > ...) > > - ) > > > > @@ > > @@ > > - 1< > + drm_plane_mask( > > ...) > > > > @@ > > @@ > > - BIT(drm_plane_index( > > + drm_plane_mask( > > ...) > > - ) > > > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Rodrigo Vivi Series pushed to drm-misc-next. Thanks for the reviews/acks. > > > --- > > drivers/gpu/drm/drm_atomic.c| 4 ++-- > > drivers/gpu/drm/drm_framebuffer.c | 2 +- > > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- > > include/drm/drm_plane.h | 14 -- > > 4 files changed, 16 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c > > index 178842380f75..684c9d3a1d6c 100644 > > --- a/drivers/gpu/drm/drm_atomic.c > > +++ b/drivers/gpu/drm/drm_atomic.c > > @@ -1581,7 +1581,7 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state > > *plane_state, > > if (WARN_ON(IS_ERR(crtc_state))) > > return PTR_ERR(crtc_state); > > > > - crtc_state->plane_mask &= ~(1 << drm_plane_index(plane)); > > + crtc_state->plane_mask &= ~drm_plane_mask(plane); > > } > > > > plane_state->crtc = crtc; > > @@ -1591,7 +1591,7 @@ drm_atomic_set_crtc_for_plane(struct drm_plane_state > > *plane_state, > >crtc); > > if (IS_ERR(crtc_state)) > > return PTR_ERR(crtc_state); > > - crtc_state->plane_mask |= (1 << drm_plane_index(plane)); > > + crtc_state->plane_mask |= drm_plane_mask(plane); > > } > > > > if (crtc) > > diff --git a/drivers/gpu/drm/drm_framebuffer.c > > b/drivers/gpu/drm/drm_framebuffer.c > > index ed90974a452a..781af1d42d76 100644 > > --- a/drivers/gpu/drm/drm_framebuffer.c > > +++ b/drivers/gpu/drm/drm_framebuffer.c > > @@ -847,7 +847,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb) > > if (ret) > > goto unlock; > > > > - plane_mask |= BIT(drm_plane_index(plane)); > > + plane_mask |= drm_plane_mask(plane); > > } > > > > /* This list is only filled when disable_crtcs is set. */ > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c > > b/drivers/gpu/drm/drm_simple_kms_helper.c > > index 7a00455ca568..9d87961da1db 100644 > > --- a/drivers/gpu/drm/drm_simple_kms_helper.c > > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c > > @@ -52,7 +52,7 @@ static int drm_simple_kms_crtc_check(struct drm_crtc > > *crtc, > > struct drm_crtc_state *state) > > { > > bool has_primary = state->plane_mask & > > - BIT(drm_plane_index(crtc->primary)); > > + drm_plane_mask(crtc->primary); > > > > /* We always want to have an active plane with an active CRTC */ > > if (has_primary != state->enable) > > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h > > index 7d4d6c7f0afd..cee9dfaaa740 100644 > > --- a/include/drm/drm_plane.h > > +++ b/include/drm/drm_plane.h > > @@ -639,10 +639,20 @@ void drm_plane_cleanup(struct drm_plane *plane); > > * Given a registered plane, return the index of that plane within a DRM > > * device's list of planes. > > */ > > -static inline unsigned int drm_plane_index(struct drm_plane *plane) > > +static inline unsigned int drm_plane_index(const struct drm_plane *plane) > > { > > return plane->index; > > } > > + > > +/** > > + * drm_plane_mask - find the mask of a registered plane > > + * @plane: plane to find mask for > > + */ > > +static inline u32 drm_plane_mask(const struct drm_plane *plane) > > +{ > > + return 1 << drm_plane_index(plane); > > +} > > + > > struct drm_plane * drm_plane_from_index(struct drm_device *dev, int idx); > > void drm_plane_force_disable(struct drm_plane *plane); > > > > @@ -678,7 +688,7 @@ static inline struct drm_plane *drm_plane_find(struct > > drm_device *dev, > > */ > > #define drm_for_each_plane_mask(plane, dev, plane_mask) \ > > list_for_each_entry((plane), &(dev)->mode_config.plane_list, head) \ > > - for_each_if ((plane_mask) & (1 << drm_plane_index(plane))) > > + for_each_if ((plane_mask) & drm_plane_mask(plane)) > > > > /** > > * drm_for_each_legacy_plane - iterate over all planes for legacy userspace > > -- > > 2.16.4 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.f
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2)
== Series Details == Series: drm: Third attempt at fixing the fb-helper .best_encoder() mess (rev2) URL : https://patchwork.freedesktop.org/series/45580/ State : warning == Summary == $ dim checkpatch origin/drm-tip 27feace2e181 drm/fb-helper: Eliminate the .best_encoder() usage bd08e651f318 drm/i915: Nuke intel_mst_best_encoder() c31cba14dcaa drm: Add drm_connector_for_each_possible_encoder() -:139: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'connector' - possible side-effects? #139: FILE: include/drm/drm_connector.h:1202: +#define drm_connector_for_each_possible_encoder(connector, encoder, __i) \ + for ((__i) = 0; (__i) < ARRAY_SIZE((connector)->encoder_ids) && \ +(connector)->encoder_ids[(__i)] != 0; (__i)++) \ + for_each_if((encoder) = \ + drm_encoder_find((connector)->dev, NULL, \ +(connector)->encoder_ids[(__i)])) \ + -:139: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__i' - possible side-effects? #139: FILE: include/drm/drm_connector.h:1202: +#define drm_connector_for_each_possible_encoder(connector, encoder, __i) \ + for ((__i) = 0; (__i) < ARRAY_SIZE((connector)->encoder_ids) && \ +(connector)->encoder_ids[(__i)] != 0; (__i)++) \ + for_each_if((encoder) = \ + drm_encoder_find((connector)->dev, NULL, \ +(connector)->encoder_ids[(__i)])) \ + total: 0 errors, 0 warnings, 2 checks, 99 lines checked 9ac85a361c63 drm/amdgpu: Use drm_connector_for_each_possible_encoder() 8807427952c1 drm/nouveau: Use drm_connector_for_each_possible_encoder() a84c10f13c19 drm/radeon: Use drm_connector_for_each_possible_encoder() f2e15e4ea45b drm: Add drm_connector_has_possible_encoder() -:23: WARNING:LONG_LINE_COMMENT: line over 100 characters #23: FILE: drivers/gpu/drm/drm_connector.c:335: + * drm_connector_has_possible_encoder - check if the connector and encoder are assosicated with each other total: 0 errors, 1 warnings, 0 checks, 38 lines checked 51b4ba4680b6 drm/msm: Use drm_connector_has_possible_encoder() 1a05980f45a6 drm/tilcdc: Use drm_connector_has_possible_encoder() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for tests/kms_pipe_crc_basic: expect setting bad source to fail
== Series Details == Series: tests/kms_pipe_crc_basic: expect setting bad source to fail URL : https://patchwork.freedesktop.org/series/45768/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4404 -> IGTPW_1521 = == Summary - FAILURE == Serious unknown changes coming with IGTPW_1521 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in IGTPW_1521, 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/45768/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in IGTPW_1521: === IGT changes === Possible regressions igt@kms_pipe_crc_basic@bad-source: {fi-cfl-8109u}: PASS -> FAIL fi-pnv-d510:PASS -> FAIL fi-skl-6770hq: PASS -> FAIL fi-bdw-5557u: PASS -> FAIL fi-bwr-2160:PASS -> FAIL fi-snb-2520m: PASS -> FAIL fi-elk-e7500: PASS -> FAIL fi-hsw-4770r: PASS -> FAIL fi-glk-j4005: PASS -> FAIL fi-cfl-8700k: PASS -> FAIL fi-hsw-peppy: PASS -> FAIL fi-bdw-gvtdvm: PASS -> FAIL fi-ilk-650: PASS -> FAIL fi-kbl-7567u: PASS -> FAIL fi-skl-guc: PASS -> FAIL fi-whl-u: PASS -> FAIL fi-cfl-guc: PASS -> FAIL fi-bxt-j4205: PASS -> FAIL fi-skl-6700hq: PASS -> FAIL fi-ivb-3520m: PASS -> FAIL fi-skl-gvtdvm: PASS -> FAIL fi-gdg-551: PASS -> FAIL fi-kbl-7500u: PASS -> FAIL {fi-kbl-x1275}: PASS -> FAIL fi-kbl-guc: PASS -> FAIL fi-skl-6600u: PASS -> FAIL fi-glk-dsi: PASS -> FAIL fi-blb-e6850: PASS -> FAIL fi-ivb-3770:PASS -> FAIL fi-skl-6700k2: PASS -> FAIL fi-bsw-n3050: PASS -> FAIL fi-snb-2600:PASS -> FAIL fi-hsw-4770:PASS -> FAIL fi-kbl-7560u: PASS -> FAIL fi-bxt-dsi: PASS -> FAIL fi-byt-n2820: PASS -> FAIL fi-skl-6260u: PASS -> FAIL fi-kbl-r: PASS -> FAIL fi-byt-j1900: PASS -> FAIL fi-cfl-s3: PASS -> FAIL Warnings igt@kms_pipe_crc_basic@read-crc-pipe-b: {fi-cfl-8109u}: PASS -> SKIP +36 {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). == Participating hosts (45 -> 40) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * IGT: IGT_4531 -> IGTPW_1521 CI_DRM_4404: ceaab659002c938f1788b7458d5081fadc3c1ddc @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_1521: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1521/ IGT_4531: a14bc8b4d69eaca189665de505e6b10cbfbb7730 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_1521/issues.html ___ 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: Add generic fbdev emulation
== Series Details == Series: drm: Add generic fbdev emulation URL : https://patchwork.freedesktop.org/series/45777/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4412_full -> Patchwork_9497_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9497_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9497_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9497_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9497_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_schedule@pi-ringfull-render: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@gem_tiled_fence_blits@normal: shard-snb: NOTRUN -> INCOMPLETE (fdo#105411) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@kms_flip_tiling@flip-x-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_suspend@shrink: shard-glk: FAIL (fdo#106886) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105189) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_flip_tiling@flip-y-tiled: shard-glk: FAIL (fdo#104724) -> PASS igt@perf_pmu@busy-idle-no-semaphores-vecs0: shard-snb: INCOMPLETE (fdo#105411) -> SKIP Warnings igt@drv_selftest@live_gtt: shard-glk: INCOMPLETE (fdo#103359, k.org#198133) -> FAIL (fdo#105347) fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4412 -> Patchwork_9497 CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9497: 8c681fb6ac510d791eeaee34a1fdc3508c79067c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9497/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 05/17] lib: Spin fast, retire early
On 02/07/2018 10:07, Chris Wilson wrote: When using the pollable spinner, we often want to use it as a means of ensuring the task is running on the GPU before switching to something else. In which case we don't want to add extra delay inside the spinner, but the current 1000 NOPs add on order of 5us, which is often larger than the target latency. v2: Don't change perf_pmu as that is sensitive to the extra CPU latency from a tight GPU spinner. Signed-off-by: Chris Wilson Reviewed-by: Antonio Argenziano #v1 Reviewed-by: Joonas Lahtinen #v1 Cc: Tvrtko Ursulin --- lib/igt_dummyload.c | 3 ++- lib/igt_dummyload.h | 1 + tests/gem_ctx_isolation.c | 1 + tests/gem_eio.c | 1 + tests/gem_exec_latency.c | 4 ++-- 5 files changed, 7 insertions(+), 3 deletions(-) diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c index 94efdf745..7beb66244 100644 --- a/lib/igt_dummyload.c +++ b/lib/igt_dummyload.c @@ -199,7 +199,8 @@ emit_recursive_batch(igt_spin_t *spin, * between function calls, that appears enough to keep SNB out of * trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262 */ - batch += 1000; + if (!(opts->flags & IGT_SPIN_FAST)) + batch += 1000; igt_require(!snb) or something, given the comment whose last two lines can be seen in the diff above? Regards, Tvrtko /* recurse */ r = &relocs[obj[BATCH].relocation_count++]; diff --git a/lib/igt_dummyload.h b/lib/igt_dummyload.h index c794f2544..e80a12451 100644 --- a/lib/igt_dummyload.h +++ b/lib/igt_dummyload.h @@ -52,6 +52,7 @@ struct igt_spin_factory { #define IGT_SPIN_FENCE_OUT (1 << 0) #define IGT_SPIN_POLL_RUN (1 << 1) +#define IGT_SPIN_FAST (1 << 2) igt_spin_t * __igt_spin_batch_factory(int fd, const struct igt_spin_factory *opts); diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c index 2e19e8c03..4325e1c28 100644 --- a/tests/gem_ctx_isolation.c +++ b/tests/gem_ctx_isolation.c @@ -560,6 +560,7 @@ static void inject_reset_context(int fd, unsigned int engine) struct igt_spin_factory opts = { .ctx = gem_context_create(fd), .engine = engine, + .flags = IGT_SPIN_FAST, }; igt_spin_t *spin; diff --git a/tests/gem_eio.c b/tests/gem_eio.c index 0ec1aaec9..3162a3170 100644 --- a/tests/gem_eio.c +++ b/tests/gem_eio.c @@ -160,6 +160,7 @@ static igt_spin_t * __spin_poll(int fd, uint32_t ctx, unsigned long flags) struct igt_spin_factory opts = { .ctx = ctx, .engine = flags, + .flags = IGT_SPIN_FAST, }; if (gem_can_store_dword(fd, opts.engine)) diff --git a/tests/gem_exec_latency.c b/tests/gem_exec_latency.c index 75811f325..de16322a6 100644 --- a/tests/gem_exec_latency.c +++ b/tests/gem_exec_latency.c @@ -65,7 +65,7 @@ poll_ring(int fd, unsigned ring, const char *name) { const struct igt_spin_factory opts = { .engine = ring, - .flags = IGT_SPIN_POLL_RUN, + .flags = IGT_SPIN_POLL_RUN | IGT_SPIN_FAST, }; struct timespec tv = {}; unsigned long cycles; @@ -464,7 +464,7 @@ rthog_latency_on_ring(int fd, unsigned int engine, const char *name, unsigned in #define MMAP_SZ (64 << 10) const struct igt_spin_factory opts = { .engine = engine, - .flags = IGT_SPIN_POLL_RUN, + .flags = IGT_SPIN_POLL_RUN | IGT_SPIN_FAST, }; struct rt_pkt *results; unsigned int engines[16]; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 04/17] lib: Convert spin batch constructor to a factory
On 02/07/2018 10:07, Chris Wilson wrote: In order to make adding more options easier, expose the full set of options to the caller. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- lib/igt_dummyload.c| 147 + lib/igt_dummyload.h| 42 +- tests/drv_missed_irq.c | 2 +- tests/gem_busy.c | 17 ++-- tests/gem_ctx_isolation.c | 26 +++--- tests/gem_eio.c| 13 ++- tests/gem_exec_fence.c | 16 ++-- tests/gem_exec_latency.c | 18 +++- tests/gem_exec_nop.c | 4 +- tests/gem_exec_reloc.c | 10 ++- tests/gem_exec_schedule.c | 27 -- tests/gem_exec_suspend.c | 2 +- tests/gem_fenced_exec_thrash.c | 2 +- tests/gem_shrink.c | 4 +- tests/gem_spin_batch.c | 4 +- tests/gem_sync.c | 5 +- tests/gem_wait.c | 4 +- tests/kms_busy.c | 10 ++- tests/kms_cursor_legacy.c | 7 +- tests/perf_pmu.c | 33 +--- tests/pm_rps.c | 9 +- 21 files changed, 189 insertions(+), 213 deletions(-) diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c index 3809b4e61..94efdf745 100644 --- a/lib/igt_dummyload.c +++ b/lib/igt_dummyload.c @@ -75,12 +75,9 @@ fill_reloc(struct drm_i915_gem_relocation_entry *reloc, reloc->write_domain = write_domains; } -#define OUT_FENCE (1 << 0) -#define POLL_RUN (1 << 1) - static int -emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine, -uint32_t dep, unsigned int flags) +emit_recursive_batch(igt_spin_t *spin, +int fd, const struct igt_spin_factory *opts) { #define SCRATCH 0 #define BATCH 1 @@ -95,21 +92,18 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine, int i; nengine = 0; - if (engine == ALL_ENGINES) { - for_each_engine(fd, engine) { - if (engine) { - if (flags & POLL_RUN) - igt_require(!(flags & POLL_RUN) || - gem_can_store_dword(fd, engine)); - - engines[nengine++] = engine; - } + if (opts->engine == ALL_ENGINES) { + unsigned int engine; + + for_each_physical_engine(fd, engine) { + if (opts->flags & IGT_SPIN_POLL_RUN && + !gem_can_store_dword(fd, engine)) + continue; + + engines[nengine++] = engine; } } else { - gem_require_ring(fd, engine); - igt_require(!(flags & POLL_RUN) || - gem_can_store_dword(fd, engine)); - engines[nengine++] = engine; + engines[nengine++] = opts->engine; } igt_require(nengine); @@ -130,20 +124,20 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine, execbuf->buffer_count++; batch_start = batch; - if (dep) { - igt_assert(!(flags & POLL_RUN)); + if (opts->dependency) { + igt_assert(!(opts->flags & IGT_SPIN_POLL_RUN)); /* dummy write to dependency */ - obj[SCRATCH].handle = dep; + obj[SCRATCH].handle = opts->dependency; fill_reloc(&relocs[obj[BATCH].relocation_count++], - dep, 1020, + opts->dependency, 1020, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER); execbuf->buffer_count++; - } else if (flags & POLL_RUN) { + } else if (opts->flags & IGT_SPIN_POLL_RUN) { unsigned int offset; - igt_assert(!dep); + igt_assert(!opts->dependency); if (gen == 4 || gen == 5) { execbuf->flags |= I915_EXEC_SECURE; @@ -231,9 +225,9 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine, execbuf->buffers_ptr = to_user_pointer(obj + (2 - execbuf->buffer_count)); - execbuf->rsvd1 = ctx; + execbuf->rsvd1 = opts->ctx; - if (flags & OUT_FENCE) + if (opts->flags & IGT_SPIN_FENCE_OUT) execbuf->flags |= I915_EXEC_FENCE_OUT; for (i = 0; i < nengine; i++) { @@ -242,7 +236,7 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine, gem_execbuf_wr(fd, execbuf); - if (flags & OUT_FENCE) { + if (opts->flags & IGT_SPIN_FENCE_OUT) { int _fd = execbuf->rsvd2 >> 32; igt_assert(_fd >= 0); @@ -271,16 +265,14 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine, } static igt
[Intel-gfx] [PATCH v3 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()
From: Ville Syrjälä Use drm_connector_for_each_possible_encoder() for iterating connector->encoder_ids[]. A bit more convenient not having to deal with the implementation details. v2: Replace drm_for_each_connector_encoder_ids() with drm_connector_for_each_possible_encoder() (Daniel) v3: Initialize nv_encoder to NULL to shut up gcc/smatch Cc: Dan Carpenter Cc: Daniel Vetter Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org Signed-off-by: Ville Syrjälä Reviewed-by: Alex Deucher #v1 --- drivers/gpu/drm/nouveau/nouveau_connector.c | 23 --- 1 file changed, 4 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 7b557c354307..bb46c1d489cf 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -363,19 +363,11 @@ module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400); struct nouveau_encoder * find_encoder(struct drm_connector *connector, int type) { - struct drm_device *dev = connector->dev; struct nouveau_encoder *nv_encoder; struct drm_encoder *enc; - int i, id; - - for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) { - id = connector->encoder_ids[i]; - if (!id) - break; + int i; - enc = drm_encoder_find(dev, NULL, id); - if (!enc) - continue; + drm_connector_for_each_possible_encoder(connector, enc, i) { nv_encoder = nouveau_encoder(enc); if (type == DCB_OUTPUT_ANY || @@ -420,7 +412,7 @@ nouveau_connector_ddc_detect(struct drm_connector *connector) struct nouveau_connector *nv_connector = nouveau_connector(connector); struct nouveau_drm *drm = nouveau_drm(dev); struct nvkm_gpio *gpio = nvxx_gpio(&drm->client.device); - struct nouveau_encoder *nv_encoder; + struct nouveau_encoder *nv_encoder = NULL; struct drm_encoder *encoder; int i, panel = -ENODEV; @@ -436,14 +428,7 @@ nouveau_connector_ddc_detect(struct drm_connector *connector) } } - for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) { - int id = connector->encoder_ids[i]; - if (id == 0) - break; - - encoder = drm_encoder_find(dev, NULL, id); - if (!encoder) - continue; + drm_connector_for_each_possible_encoder(connector, encoder, i) { nv_encoder = nouveau_encoder(encoder); if (nv_encoder->dcb->type == DCB_OUTPUT_DP) { -- 2.16.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 drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev3)
== Series Details == Series: drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev3) URL : https://patchwork.freedesktop.org/series/45774/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4413 -> Patchwork_9499 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45774/revisions/3/mbox/ == Known issues == Here are the changes found in Patchwork_9499 that come from known issues: === IGT changes === Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 == Participating hosts (45 -> 40) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4413 -> Patchwork_9499 CI_DRM_4413: df42fb566d33f5889c8d61f9929d3e72d4a16813 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9499: e3d5d0eb50dde824f73f6ee82168f9d3b284bf71 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e3d5d0eb50dd drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9499/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for usb/icl: Work around ACPI boottime crash
== Series Details == Series: usb/icl: Work around ACPI boottime crash URL : https://patchwork.freedesktop.org/series/45778/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4412 -> Patchwork_9498 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45778/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9498 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 == Participating hosts (43 -> 40) == Additional (1): fi-byt-j1900 Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4412 -> Patchwork_9498 CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9498: f195f00e11e20013ab321df784e9b806aefc81c6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f195f00e11e2 usb/icl: Work around ACPI boottime crash == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9498/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: abstract and document register picking macros
On Fri, 29 Jun 2018, Rodrigo Vivi wrote: > On Fri, Jun 29, 2018 at 01:20:39PM +0300, Jani Nikula wrote: >> Try to describe what the pick variants do, and which to prefer. No >> functional changes. >> >> Signed-off-by: Jani Nikula > > Reviewed-by: Rodrigo Vivi Thanks, pushed. BR, Jani. > >> >> --- >> >> Let the naming bikeshed fest begin! >> --- >> drivers/gpu/drm/i915/i915_reg.h | 28 ++-- >> 1 file changed, 22 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h >> b/drivers/gpu/drm/i915/i915_reg.h >> index c30cfcd90754..7dc774682922 100644 >> --- a/drivers/gpu/drm/i915/i915_reg.h >> +++ b/drivers/gpu/drm/i915/i915_reg.h >> @@ -139,19 +139,35 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) >> return !i915_mmio_reg_equal(reg, INVALID_MMIO_REG); >> } >> >> +/* >> + * Given the first two numbers __a and __b of arbitrarily many evenly spaced >> + * numbers, pick the 0-based __index'th value. >> + * >> + * Always prefer this over _PICK() if the numbers are evenly spaced. >> + */ >> +#define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a))) >> + >> +/* >> + * Given the arbitrary numbers in varargs, pick the 0-based __index'th >> number. >> + * >> + * Always prefer _PICK_EVEN() over this if the numbers are evenly spaced. >> + */ >> #define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index]) >> >> -#define _PIPE(pipe, a, b) ((a) + (pipe) * ((b) - (a))) >> +/* >> + * Named helper wrappers around _PICK_EVEN() and _PICK(). >> + */ >> +#define _PIPE(pipe, a, b) _PICK_EVEN(pipe, a, b) >> #define _MMIO_PIPE(pipe, a, b) _MMIO(_PIPE(pipe, a, b)) >> -#define _PLANE(plane, a, b) _PIPE(plane, a, b) >> +#define _PLANE(plane, a, b) _PICK_EVEN(plane, a, b) >> #define _MMIO_PLANE(plane, a, b) _MMIO_PIPE(plane, a, b) >> -#define _TRANS(tran, a, b) ((a) + (tran) * ((b) - (a))) >> +#define _TRANS(tran, a, b) _PICK_EVEN(tran, a, b) >> #define _MMIO_TRANS(tran, a, b) _MMIO(_TRANS(tran, a, b)) >> -#define _PORT(port, a, b) ((a) + (port) * ((b) - (a))) >> +#define _PORT(port, a, b) _PICK_EVEN(port, a, b) >> #define _MMIO_PORT(port, a, b) _MMIO(_PORT(port, a, b)) >> #define _MMIO_PIPE3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c)) >> #define _MMIO_PORT3(pipe, a, b, c) _MMIO(_PICK(pipe, a, b, c)) >> -#define _PLL(pll, a, b) ((a) + (pll) * ((b) - (a))) >> +#define _PLL(pll, a, b) _PICK_EVEN(pll, a, b) >> #define _MMIO_PLL(pll, a, b) _MMIO(_PLL(pll, a, b)) >> #define _PHY3(phy, ...) _PICK(phy, __VA_ARGS__) >> #define _MMIO_PHY3(phy, a, b, c) _MMIO(_PHY3(phy, a, b, c)) >> @@ -6874,7 +6890,7 @@ enum { >> #define _PS_ECC_STAT_2B 0x68AD0 >> #define _PS_ECC_STAT_1C 0x691D0 >> >> -#define _ID(id, a, b) ((a) + (id) * ((b) - (a))) >> +#define _ID(id, a, b) _PICK_EVEN(id, a, b) >> #define SKL_PS_CTRL(pipe, id) _MMIO_PIPE(pipe,\ >> _ID(id, _PS_1A_CTRL, _PS_2A_CTRL), \ >> _ID(id, _PS_1B_CTRL, _PS_2B_CTRL)) >> -- >> 2.11.0 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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: Add generic fbdev emulation
== Series Details == Series: drm: Add generic fbdev emulation URL : https://patchwork.freedesktop.org/series/45777/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4412 -> Patchwork_9497 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45777/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9497 that come from known issues: === IGT changes === Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 == Participating hosts (43 -> 40) == Additional (1): fi-byt-j1900 Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4412 -> Patchwork_9497 CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9497: 8c681fb6ac510d791eeaee34a1fdc3508c79067c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8c681fb6ac51 drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() 1decaf928232 drm/tinydrm: Use drm_fbdev_generic_setup() 5d0b6c2e1752 drm/fb-helper: Finish the generic fbdev emulation 10fdb59e4e4a drm/debugfs: Add internal client debugfs file 03ee165264d0 drm/client: Add client callbacks 3f78d617c951 drm/cma-helper: Use the generic fbdev emulation 8aa54780abbc drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap 5c343c927656 drm/fb-helper: Add generic fbdev emulation .fb_probe function 44cb6f91d1db drm: Begin an API for in-kernel clients == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9497/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Add generic fbdev emulation
== Series Details == Series: drm: Add generic fbdev emulation URL : https://patchwork.freedesktop.org/series/45777/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm: Begin an API for in-kernel clients Okay! Commit: drm/fb-helper: Add generic fbdev emulation .fb_probe function +drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void) +drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1006:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1007:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1008:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void) -drivers/gpu/drm/drm_fb_helper.c:1009:20: warning: expression using sizeof(void) Commit: drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap Okay! Commit: drm/cma-helper: Use the generic fbdev emulation Okay! Commit: drm/client: Add client callbacks Okay! Commit: drm/debugfs: Add internal client debugfs file Okay! Commit: drm/fb-helper: Finish the generic fbdev emulation Okay! Commit: drm/tinydrm: Use drm_fbdev_generic_setup() Okay! Commit: drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support.
From: Stanislav Lisovskiy PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification. v2: Edited commit message, removed redundant whitespaces. v3: Fixed fallthrough logic for the format switch cases. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_display.c | 10 ++ drivers/gpu/drm/i915/intel_sprite.c | 5 + 2 files changed, 15 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 56818a45181c..2447a620abb5 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = { DRM_FORMAT_YVYU, DRM_FORMAT_UYVY, DRM_FORMAT_VYUY, + DRM_FORMAT_AYUV, }; static const uint32_t skl_pri_planar_formats[] = { @@ -102,6 +103,7 @@ static const uint32_t skl_pri_planar_formats[] = { DRM_FORMAT_UYVY, DRM_FORMAT_VYUY, DRM_FORMAT_NV12, + DRM_FORMAT_AYUV, }; static const uint64_t skl_format_modifiers_noccs[] = { @@ -3497,6 +3499,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format) return PLANE_CTL_FORMAT_XRGB_2101010; case DRM_FORMAT_XBGR2101010: return PLANE_CTL_ORDER_RGBX | PLANE_CTL_FORMAT_XRGB_2101010; + case DRM_FORMAT_AYUV: + return PLANE_CTL_FORMAT_AYUV; case DRM_FORMAT_YUYV: return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV; case DRM_FORMAT_YVYU: @@ -13371,6 +13375,11 @@ static bool skl_plane_format_mod_supported(struct drm_plane *_plane, } switch (format) { + case DRM_FORMAT_AYUV: + if (modifier == DRM_FORMAT_MOD_LINEAR || + modifier == I915_FORMAT_MOD_X_TILED || + modifier == I915_FORMAT_MOD_Y_TILED) + return true; case DRM_FORMAT_XRGB: case DRM_FORMAT_XBGR: case DRM_FORMAT_ARGB: @@ -14510,6 +14519,7 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, goto err; } break; + case DRM_FORMAT_AYUV: case DRM_FORMAT_YUYV: case DRM_FORMAT_UYVY: case DRM_FORMAT_YVYU: diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 344c0e709b19..0a6958f07dae 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1405,6 +1405,11 @@ static bool skl_plane_format_mod_supported(struct drm_plane *_plane, } switch (format) { + case DRM_FORMAT_AYUV: + if (modifier == DRM_FORMAT_MOD_LINEAR || + modifier == I915_FORMAT_MOD_X_TILED || + modifier == I915_FORMAT_MOD_Y_TILED) + return true; case DRM_FORMAT_XRGB: case DRM_FORMAT_XBGR: case DRM_FORMAT_ARGB: -- 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 drm: Add generic fbdev emulation
== Series Details == Series: drm: Add generic fbdev emulation URL : https://patchwork.freedesktop.org/series/45777/ State : warning == Summary == $ dim checkpatch origin/drm-tip 44cb6f91d1db drm: Begin an API for in-kernel clients -:26: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #26: new file mode 100644 -:31: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #31: FILE: Documentation/gpu/drm-client.rst:1: += total: 0 errors, 2 warnings, 0 checks, 412 lines checked 5c343c927656 drm/fb-helper: Add generic fbdev emulation .fb_probe function 8aa54780abbc drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap 3f78d617c951 drm/cma-helper: Use the generic fbdev emulation -:359: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #359: FILE: drivers/gpu/drm/drm_fb_cma_helper.c:172: +struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev, + unsigned int preferred_bpp, unsigned int max_conn_count) total: 0 errors, 0 warnings, 1 checks, 425 lines checked 03ee165264d0 drm/client: Add client callbacks 10fdb59e4e4a drm/debugfs: Add internal client debugfs file 5d0b6c2e1752 drm/fb-helper: Finish the generic fbdev emulation 1decaf928232 drm/tinydrm: Use drm_fbdev_generic_setup() 8c681fb6ac51 drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() ___ 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: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev2)
== Series Details == Series: drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. (rev2) URL : https://patchwork.freedesktop.org/series/45774/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4412 -> Patchwork_9496 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45774/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9496 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-glk-dsi: PASS -> DMESG-WARN (fdo#106954) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106954 https://bugs.freedesktop.org/show_bug.cgi?id=106954 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4412 -> Patchwork_9496 CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9496: 8821d5e9ab048a4e4947e7b51f6d79b5d368de68 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 8821d5e9ab04 drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9496/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()
On Mon, Jul 02, 2018 at 04:04:45PM +0300, Ville Syrjälä wrote: > On Sat, Jun 30, 2018 at 10:12:21PM +0300, Dan Carpenter wrote: > > Hi Ville, > > > > Thank you for the patch! Perhaps something to improve: > > > > url: > > https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-Third-attempt-at-fixing-the-fb-helper-best_encoder-mess/20180629-014202 > > base: git://people.freedesktop.org/~airlied/linux.git drm-next > > > > smatch warnings: > > drivers/gpu/drm/nouveau/nouveau_connector.c:461 > > nouveau_connector_ddc_detect() error: uninitialized symbol 'nv_encoder'. > > > > # > > https://github.com/0day-ci/linux/commit/7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06 > > git remote add linux-review https://github.com/0day-ci/linux > > git remote update linux-review > > git checkout 7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06 > > vim +/nv_encoder +461 drivers/gpu/drm/nouveau/nouveau_connector.c > > > > 6ee738610 Ben Skeggs 2009-12-11 407 > > 8777c5c11 Ben Skeggs 2014-06-06 408 static struct nouveau_encoder * > > 8777c5c11 Ben Skeggs 2014-06-06 409 > > nouveau_connector_ddc_detect(struct drm_connector *connector) > > 6ee738610 Ben Skeggs 2009-12-11 410 { > > 6ee738610 Ben Skeggs 2009-12-11 411 struct drm_device *dev = > > connector->dev; > > 1a1841d30 Ben Skeggs 2012-12-10 412 struct nouveau_connector > > *nv_connector = nouveau_connector(connector); > > 77145f1cb Ben Skeggs 2012-07-31 413 struct nouveau_drm *drm = > > nouveau_drm(dev); > > 1167c6bc5 Ben Skeggs 2016-05-18 414 struct nvkm_gpio *gpio = > > nvxx_gpio(&drm->client.device); > > 8777c5c11 Ben Skeggs 2014-06-06 415 struct nouveau_encoder > > *nv_encoder; > > 6d385c0aa Rob Clark 2014-07-17 416 struct drm_encoder *encoder; > > 1a1841d30 Ben Skeggs 2012-12-10 417 int i, panel = -ENODEV; > > 1a1841d30 Ben Skeggs 2012-12-10 418 > > 1a1841d30 Ben Skeggs 2012-12-10 419 /* eDP panels need powering on > > by us (if the VBIOS doesn't default it > > 1a1841d30 Ben Skeggs 2012-12-10 420* to on) before doing any AUX > > channel transactions. LVDS panel power > > 1a1841d30 Ben Skeggs 2012-12-10 421* is handled by the SOR > > itself, and not required for LVDS DDC. > > 1a1841d30 Ben Skeggs 2012-12-10 422*/ > > 1a1841d30 Ben Skeggs 2012-12-10 423 if (nv_connector->type == > > DCB_CONNECTOR_eDP) { > > 2ea7249fe Ben Skeggs 2015-08-20 424 panel = > > nvkm_gpio_get(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff); > > 1a1841d30 Ben Skeggs 2012-12-10 425 if (panel == 0) { > > 2ea7249fe Ben Skeggs 2015-08-20 426 > > nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, 1); > > 1a1841d30 Ben Skeggs 2012-12-10 427 msleep(300); > > 1a1841d30 Ben Skeggs 2012-12-10 428 } > > 1a1841d30 Ben Skeggs 2012-12-10 429 } > > 6ee738610 Ben Skeggs 2009-12-11 430 > > 7ec8bb653 Ville Syrjälä 2018-06-28 431 > > drm_connector_for_each_possible_encoder(connector, encoder, i) { > > 6d385c0aa Rob Clark 2014-07-17 432 nv_encoder = > > nouveau_encoder(encoder); > > > > ^ > > If we enter the loop that means nv_encoder is non-NULL. Smatch can't > > prove that we always enter the loop in this case for whatever reason but > > my guess is that we always do. > > > > 4ca2b7120 Francisco Jerez 2010-08-08 433 > > 8777c5c11 Ben Skeggs 2014-06-06 434 if > > (nv_encoder->dcb->type == DCB_OUTPUT_DP) { > > 8777c5c11 Ben Skeggs 2014-06-06 435 int ret = > > nouveau_dp_detect(nv_encoder); > > 52aa30f25 Ben Skeggs 2016-11-04 436 if (ret == > > NOUVEAU_DP_MST) > > 52aa30f25 Ben Skeggs 2016-11-04 437 return > > NULL; > > 52aa30f25 Ben Skeggs 2016-11-04 438 if (ret == > > NOUVEAU_DP_SST) > > 8777c5c11 Ben Skeggs 2014-06-06 439 break; > > 8777c5c11 Ben Skeggs 2014-06-06 440 } else > > 39c1c9011 Lukas Wunner2016-01-11 441 if > > ((vga_switcheroo_handler_flags() & > > 39c1c9011 Lukas Wunner2016-01-11 442 > > VGA_SWITCHEROO_CAN_SWITCH_DDC) && > > 39c1c9011 Lukas Wunner2016-01-11 443 > > nv_encoder->dcb->type == DCB_OUTPUT_LVDS && > > 39c1c9011 Lukas Wunner2016-01-11 444 nv_encoder->i2c) { > > 39c1c9011 Lukas Wunner2016-01-11 445 int ret; > > 39c1c9011 Lukas Wunner2016-01-11 446 > > vga_switcheroo_lock_ddc(dev->pdev); > > 39c1c9011 Lukas Wunner2016-01-11 447 ret = > > nvkm_probe_i2c(nv_encoder->i2c, 0x50); > > 39c1c9011 Lukas Wunner2016-01-11 448 > > vga_switcheroo_unlock_ddc(dev->pdev); > > 39c1c9011 Lukas Wunner
[Intel-gfx] [PATCH] usb/icl: Work around ACPI boottime crash
Work around the following boot time crash: [ 10.456056] CPU: 1 PID: 220 Comm: systemd-udevd Tainted: GW 4.17.0-rc7-CI-CI_DRM_4040+ #182 [ 10.465828] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS +ICLSFWR1.R00.2204.A00.1805172221 05/17/2018 [ 10.479168] RIP: 0010:acpi_ps_complete_this_op+0xa7/0x22a [ 10.484627] RSP: 0018:c93a7578 EFLAGS: 00010202 [ 10.489881] RAX: 6b6b6b6b6b6b6b6b RBX: 8804abeda9c8 RCX: 0020 [ 10.497045] RDX: RSI: 88049e604a68 RDI: [ 10.504213] RBP: R08: 8804abeda9c8 R09: [ 10.511376] R10: R11: R12: 000e [ 10.518542] R13: 88049e604a68 R14: 88049e604a68 R15: a00263c2 [ 10.525713] FS: 7ff6d85f18c0() GS:8804be88() knlGS: [ 10.533839] CS: 0010 DS: ES: CR0: 80050033 [ 10.539616] CR2: 7ff6d73cff40 CR3: 00049f794001 CR4: 00760ee0 [ 10.546783] DR0: DR1: DR2: [ 10.553949] DR3: DR6: fffe0ff0 DR7: 0400 [ 10.561112] PKRU: 5554 [ 10.563849] Call Trace: [ 10.566323] acpi_ps_complete_op+0x49/0x3f1 [ 10.570537] acpi_ps_parse_loop+0x94c/0x9bb [ 10.574754] ? acpi_ds_delete_walk_state+0x113/0x131 [ 10.579750] acpi_ps_parse_aml+0x1a2/0x4af [ 10.583875] acpi_ps_execute_method+0x1e9/0x2a5 [ 10.588435] acpi_ns_evaluate+0x2e4/0x42c [ 10.592473] acpi_evaluate_object+0x1fd/0x3a8 [ 10.596873] usb_acpi_find_companion+0xee/0x1f0 [usbcore] [ 10.602319] acpi_platform_notify+0x33/0xa0 [ 10.606532] device_add+0x197/0x600 [ 10.610048] ? __init_waitqueue_head+0x36/0x50 [ 10.614529] usb_hub_create_port_device+0x11d/0x340 [usbcore] [ 10.620314] hub_probe+0x9a5/0x1010 [usbcore] [ 10.624701] ? _raw_spin_unlock_irqrestore+0x51/0x60 [ 10.629730] usb_probe_interface+0x13f/0x300 [usbcore] [ 10.634900] driver_probe_device+0x302/0x470 [ 10.639198] ? __driver_attach+0xe0/0xe0 [ 10.643147] bus_for_each_drv+0x59/0x90 [ 10.647013] __device_attach+0xb7/0x130 [ 10.650878] bus_probe_device+0x9c/0xb0 [ 10.654745] device_add+0x3c5/0x600 [ 10.658270] usb_set_configuration+0x540/0x880 [usbcore] [ 10.663621] generic_probe+0x28/0x80 [usbcore] [ 10.668097] driver_probe_device+0x302/0x470 [ 10.672393] ? __driver_attach+0xe0/0xe0 [ 10.676346] bus_for_each_drv+0x59/0x90 [ 10.680211] __device_attach+0xb7/0x130 [ 10.684076] bus_probe_device+0x9c/0xb0 [ 10.687940] device_add+0x3c5/0x600 [ 10.691464] usb_new_device+0x269/0x490 [usbcore] [ 10.696206] usb_add_hcd+0x558/0x850 [usbcore] [ 10.700682] xhci_pci_probe+0x13d/0x240 [xhci_pci] [ 10.705534] pci_device_probe+0xa1/0x130 [ 10.709484] driver_probe_device+0x302/0x470 [ 10.713784] __driver_attach+0xb9/0xe0 [ 10.717562] ? driver_probe_device+0x470/0x470 [ 10.722033] ? driver_probe_device+0x470/0x470 [ 10.726505] bus_for_each_dev+0x64/0x90 [ 10.730370] ? preempt_count_sub+0x92/0xd0 [ 10.734495] bus_add_driver+0x164/0x260 [ 10.738362] ? 0xa004e000 [ 10.741704] driver_register+0x57/0xc0 [ 10.745482] ? 0xa004e000 [ 10.748824] do_one_initcall+0x4a/0x350 [ 10.752690] ? do_init_module+0x22/0x20a [ 10.756643] ? rcu_read_lock_sched_held+0x74/0x80 [ 10.761377] ? kmem_cache_alloc_trace+0x284/0x2e0 [ 10.766114] do_init_module+0x5b/0x20a [ 10.769895] load_module+0x250d/0x2b20 [ 10.773678] ? kernel_read+0x2c/0x40 [ 10.777285] ? __se_sys_finit_module+0xaa/0xc0 [ 10.781759] __se_sys_finit_module+0xaa/0xc0 [ 10.786061] do_syscall_64+0x54/0x190 [ 10.789752] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 10.794831] RIP: 0033:0x7ff6d74664d9 [ 10.798430] RSP: 002b:7ffd91e7dd78 EFLAGS: 0246 ORIG_RAX: 0139 [ 10.806033] RAX: ffda RBX: 560519bfae20 RCX: 7ff6d74664d9 [ 10.813195] RDX: RSI: 7ff6d795ce23 RDI: 000e [ 10.820360] RBP: 7ff6d795ce23 R08: R09: [ 10.827523] R10: 000e R11: 0246 R12: [ 10.834690] R13: 560519bf9a30 R14: 0002 R15: 0aba9500 [ 10.841862] Code: c2 10 5f ea 81 48 c7 c6 f0 5e ea 81 bf 7c 00 00 00 e8 0d 7c 00 00 31 ed e9 88 01 00 00 48 8b 03 31 ed 48 85 c0 +0f 84 e9 00 00 00 <4c> 8b 60 28 4d 85 e4 0f 84 dc 00 00 00 0f b7 78 0a e8 62 fe ff [ 10.860832] RIP: acpi_ps_complete_this_op+0xa7/0x22a RSP: c93a7578 [ 10.867907] ---[ end trace 3a0d2ee1129bc71e ]--- Cc: Chris Wilson Signed-off-by: Imre Deak --- drivers/usb/core/usb-acpi.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c index e221861b3187..8424b3a27e7e 100644 --- a/drivers/usb/core/u
Re: [Intel-gfx] [PATCH v2] drm/i915: Try GGTT mmapping whole object as partial
On 30 June 2018 at 10:05, Chris Wilson wrote: > If the whole object is already pinned by HW for use as scanout, we will > fail to move it to the mappable region and so must resort to using a > partial VMA covering the whole object. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104513 > Fixes: aa136d9d72c2 ("drm/i915: Convert partial ggtt vma to full ggtt if it > spans the entire object") > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: Matthew Auld Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 8/9] drm/tinydrm: Use drm_fbdev_generic_setup()
Make full use of the generic fbdev client. Cc: David Lechner Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +-- drivers/gpu/drm/tinydrm/ili9225.c | 1 - drivers/gpu/drm/tinydrm/ili9341.c | 1 - drivers/gpu/drm/tinydrm/mi0283qt.c | 1 - drivers/gpu/drm/tinydrm/st7586.c| 1 - drivers/gpu/drm/tinydrm/st7735r.c | 1 - 6 files changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c index 24a33bf862fa..19c7f70adfa5 100644 --- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c +++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c @@ -204,7 +204,7 @@ static int tinydrm_register(struct tinydrm_device *tdev) if (ret) return ret; - ret = drm_fb_cma_fbdev_init_with_funcs(drm, 0, 0, tdev->fb_funcs); + ret = drm_fbdev_generic_setup(drm, 0); if (ret) DRM_ERROR("Failed to initialize fbdev: %d\n", ret); @@ -214,7 +214,6 @@ static int tinydrm_register(struct tinydrm_device *tdev) static void tinydrm_unregister(struct tinydrm_device *tdev) { drm_atomic_helper_shutdown(tdev->drm); - drm_fb_cma_fbdev_fini(tdev->drm); drm_dev_unregister(tdev->drm); } diff --git a/drivers/gpu/drm/tinydrm/ili9225.c b/drivers/gpu/drm/tinydrm/ili9225.c index 841c69aba059..455fefe012f5 100644 --- a/drivers/gpu/drm/tinydrm/ili9225.c +++ b/drivers/gpu/drm/tinydrm/ili9225.c @@ -368,7 +368,6 @@ static struct drm_driver ili9225_driver = { DRIVER_ATOMIC, .fops = &ili9225_fops, TINYDRM_GEM_DRIVER_OPS, - .lastclose = drm_fb_helper_lastclose, .name = "ili9225", .desc = "Ilitek ILI9225", .date = "20171106", diff --git a/drivers/gpu/drm/tinydrm/ili9341.c b/drivers/gpu/drm/tinydrm/ili9341.c index 8864dcde6edc..6701037749a7 100644 --- a/drivers/gpu/drm/tinydrm/ili9341.c +++ b/drivers/gpu/drm/tinydrm/ili9341.c @@ -145,7 +145,6 @@ static struct drm_driver ili9341_driver = { .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | DRIVER_ATOMIC, .fops = &ili9341_fops, TINYDRM_GEM_DRIVER_OPS, - .lastclose = drm_fb_helper_lastclose, .debugfs_init = mipi_dbi_debugfs_init, .name = "ili9341", .desc = "Ilitek ILI9341", diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c b/drivers/gpu/drm/tinydrm/mi0283qt.c index 015d03f2acba..d7bb4c5e6657 100644 --- a/drivers/gpu/drm/tinydrm/mi0283qt.c +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c @@ -154,7 +154,6 @@ static struct drm_driver mi0283qt_driver = { DRIVER_ATOMIC, .fops = &mi0283qt_fops, TINYDRM_GEM_DRIVER_OPS, - .lastclose = drm_fb_helper_lastclose, .debugfs_init = mipi_dbi_debugfs_init, .name = "mi0283qt", .desc = "Multi-Inno MI0283QT", diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c index 5c29e3803ecb..2fcbc3067d71 100644 --- a/drivers/gpu/drm/tinydrm/st7586.c +++ b/drivers/gpu/drm/tinydrm/st7586.c @@ -304,7 +304,6 @@ static struct drm_driver st7586_driver = { DRIVER_ATOMIC, .fops = &st7586_fops, TINYDRM_GEM_DRIVER_OPS, - .lastclose = drm_fb_helper_lastclose, .debugfs_init = mipi_dbi_debugfs_init, .name = "st7586", .desc = "Sitronix ST7586", diff --git a/drivers/gpu/drm/tinydrm/st7735r.c b/drivers/gpu/drm/tinydrm/st7735r.c index 6c7b15c9da4f..3081bc57c116 100644 --- a/drivers/gpu/drm/tinydrm/st7735r.c +++ b/drivers/gpu/drm/tinydrm/st7735r.c @@ -120,7 +120,6 @@ static struct drm_driver st7735r_driver = { DRIVER_ATOMIC, .fops = &st7735r_fops, TINYDRM_GEM_DRIVER_OPS, - .lastclose = drm_fb_helper_lastclose, .debugfs_init = mipi_dbi_debugfs_init, .name = "st7735r", .desc = "Sitronix ST7735R", -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 7/9] drm/fb-helper: Finish the generic fbdev emulation
This adds a drm_fbdev_generic_setup() function that sets up generic fbdev emulation with client callbacks for restore, hotplug and unregister. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_helper.c | 117 include/drm/drm_fb_helper.h | 7 +++ 2 files changed, 124 insertions(+) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index bea3a0cb324a..e2f0db1432aa 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -67,6 +67,9 @@ static DEFINE_MUTEX(kernel_fb_helper_lock); * helper functions used by many drivers to implement the kernel mode setting * interfaces. * + * Drivers that support a dumb buffer with a virtual address and mmap support, + * should try out the generic fbdev emulation using drm_fbdev_generic_setup(). + * * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it * down by calling drm_fb_helper_fbdev_teardown(). * @@ -3118,6 +3121,120 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_helper, } EXPORT_SYMBOL(drm_fb_helper_generic_probe); +static const struct drm_fb_helper_funcs drm_fb_helper_generic_funcs = { + .fb_probe = drm_fb_helper_generic_probe, +}; + +static void drm_fbdev_client_unregister(struct drm_client_dev *client) +{ + struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client); + + if (fb_helper->fbdev) { + drm_fb_helper_unregister_fbi(fb_helper); + /* drm_fbdev_fb_destroy() takes care of cleanup */ + return; + } + + /* Did drm_fb_helper_fbdev_setup() run? */ + if (fb_helper->dev) + drm_fb_helper_fini(fb_helper); + + drm_client_release(client); + kfree(fb_helper); +} + +static int drm_fbdev_client_restore(struct drm_client_dev *client) +{ + struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client); + + drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper); + + return 0; +} + +static int drm_fbdev_client_hotplug(struct drm_client_dev *client) +{ + struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client); + struct drm_device *dev = client->dev; + int ret; + + /* If drm_fb_helper_fbdev_setup() failed, we only try once */ + if (!fb_helper->dev && fb_helper->funcs) + return 0; + + if (dev->fb_helper) + return drm_fb_helper_hotplug_event(dev->fb_helper); + + if (!dev->mode_config.num_connector) + return 0; + + ret = drm_fb_helper_fbdev_setup(dev, fb_helper, &drm_fb_helper_generic_funcs, + fb_helper->preferred_bpp, 0); + if (ret) { + fb_helper->dev = NULL; + fb_helper->fbdev = NULL; + return ret; + } + + return 0; +} + +static const struct drm_client_funcs drm_fbdev_client_funcs = { + .owner = THIS_MODULE, + .unregister = drm_fbdev_client_unregister, + .restore= drm_fbdev_client_restore, + .hotplug= drm_fbdev_client_hotplug, +}; + +/** + * drm_fb_helper_generic_fbdev_setup() - Setup generic fbdev emulation + * @dev: DRM device + * @preferred_bpp: Preferred bits per pixel for the device. + * @dev->mode_config.preferred_depth is used if this is zero. + * + * This function sets up generic fbdev emulation for drivers that supports + * dumb buffers with a virtual address and that can be mmap'ed. + * + * Restore, hotplug events and teardown are all taken care of. Drivers that do + * suspend/resume need to call drm_fb_helper_set_suspend_unlocked() themselves. + * Simple drivers might use drm_mode_config_helper_suspend(). + * + * Drivers that set the dirty callback on their framebuffer will get a shadow + * fbdev buffer that is blitted onto the real buffer. This is done in order to + * make deferred I/O work with all kinds of buffers. + * + * This function is safe to call even when there are no connectors present. + * Setup will be retried on the next hotplug event. + * + * Returns: + * Zero on success or negative error code on failure. + */ +int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp) +{ + struct drm_fb_helper *fb_helper; + int ret; + + if (!drm_fbdev_emulation) + return 0; + + fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL); + if (!fb_helper) + return -ENOMEM; + + ret = drm_client_new(dev, &fb_helper->client, "fbdev", &drm_fbdev_client_funcs); + if (ret) { + kfree(fb_helper); + return ret; + } + + fb_helper->preferred_bpp = preferred_bpp; + + drm_fbdev_client_hotplug(&fb_helper->client); + + return 0; +} +EXPORT_SYMBOL(drm_fbdev_generic_setup); + /* The Kconfig DRM_KMS_HELPER selects FRAMEBUFFER_CONSOLE (if !EXPERT) * but the module doesn't depend on any fb console
[Intel-gfx] [PATCH v4 4/9] drm/cma-helper: Use the generic fbdev emulation
This switches the CMA helper drivers that use its fbdev emulation over to the generic fbdev emulation. It's the first phase of using generic fbdev. A later phase will use DRM client callbacks for the lastclose/hotplug/remove callbacks. There are currently 2 fbdev init/fini functions: - drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini - drm_fbdev_cma_init/drm_fbdev_cma_fini This is because the work on generic fbdev came up during a fbdev refactoring and thus wasn't completed. No point in completing that refactoring when drivers will soon move to drm_fb_helper_generic_probe(). tinydrm uses drm_fb_cma_fbdev_init_with_funcs(). Cc: Laurent Pinchart Signed-off-by: Noralf Trønnes Acked-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_cma_helper.c | 360 +--- include/drm/drm_fb_cma_helper.h | 3 - 2 files changed, 42 insertions(+), 321 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 186d00adfb5f..5762a7c441e9 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -18,6 +18,7 @@ */ #include +#include #include #include #include @@ -26,11 +27,8 @@ #include #include -#define DEFAULT_FBDEFIO_DELAY_MS 50 - struct drm_fbdev_cma { struct drm_fb_helperfb_helper; - const struct drm_framebuffer_funcs *fb_funcs; }; /** @@ -44,36 +42,6 @@ struct drm_fbdev_cma { * * An fbdev framebuffer backed by cma is also available by calling * drm_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down. - * If the &drm_framebuffer_funcs.dirty callback is set, fb_deferred_io will be - * set up automatically. &drm_framebuffer_funcs.dirty is called by - * drm_fb_helper_deferred_io() in process context (&struct delayed_work). - * - * Example fbdev deferred io code:: - * - * static int driver_fb_dirty(struct drm_framebuffer *fb, - *struct drm_file *file_priv, - *unsigned flags, unsigned color, - *struct drm_clip_rect *clips, - *unsigned num_clips) - * { - * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0); - * ... push changes ... - * return 0; - * } - * - * static struct drm_framebuffer_funcs driver_fb_funcs = { - * .destroy = drm_gem_fb_destroy, - * .create_handle = drm_gem_fb_create_handle, - * .dirty = driver_fb_dirty, - * }; - * - * Initialize:: - * - * fbdev = drm_fb_cma_fbdev_init_with_funcs(dev, 16, - * dev->mode_config.num_crtc, - * dev->mode_config.num_connector, - * &driver_fb_funcs); - * */ static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper) @@ -131,153 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer *fb, } EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr); -static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma) -{ - return dma_mmap_writecombine(info->device, vma, info->screen_base, -info->fix.smem_start, info->fix.smem_len); -} - -static struct fb_ops drm_fbdev_cma_ops = { - .owner = THIS_MODULE, - DRM_FB_HELPER_DEFAULT_OPS, - .fb_fillrect= drm_fb_helper_sys_fillrect, - .fb_copyarea= drm_fb_helper_sys_copyarea, - .fb_imageblit = drm_fb_helper_sys_imageblit, - .fb_mmap= drm_fb_cma_mmap, -}; - -static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info, - struct vm_area_struct *vma) -{ - fb_deferred_io_mmap(info, vma); - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot); - - return 0; -} - -static int drm_fbdev_cma_defio_init(struct fb_info *fbi, - struct drm_gem_cma_object *cma_obj) -{ - struct fb_deferred_io *fbdefio; - struct fb_ops *fbops; - - /* -* Per device structures are needed because: -* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap -* fbdefio: individual delays -*/ - fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL); - fbops = kzalloc(sizeof(*fbops), GFP_KERNEL); - if (!fbdefio || !fbops) { - kfree(fbdefio); - kfree(fbops); - return -ENOMEM; - } - - /* can't be offset from vaddr since dirty() uses cma_obj */ - fbi->screen_buffer = cma_obj->vaddr; - /* fb_deferred_io_fault() needs a physical address */ - fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer)); - - *fbops = *fbi->fbops; - fbi->fbops = fbops; - - fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS); - fbdefio->deferred_io = drm_fb_helper_deferred_io; - fbi->fbdef
[Intel-gfx] [PATCH v4 6/9] drm/debugfs: Add internal client debugfs file
Print the names of the internal clients currently attached. Reviewed-by: Daniel Vetter Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_client.c | 28 drivers/gpu/drm/drm_debugfs.c | 7 +++ include/drm/drm_client.h | 3 +++ 3 files changed, 38 insertions(+) diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c index f05ee98bd10c..e8d7b259ff22 100644 --- a/drivers/gpu/drm/drm_client.c +++ b/drivers/gpu/drm/drm_client.c @@ -375,3 +375,31 @@ void drm_client_framebuffer_delete(struct drm_client_buffer *buffer) drm_client_buffer_delete(buffer); } EXPORT_SYMBOL(drm_client_framebuffer_delete); + +#ifdef CONFIG_DEBUG_FS +static int drm_client_debugfs_internal_clients(struct seq_file *m, void *data) +{ + struct drm_info_node *node = m->private; + struct drm_device *dev = node->minor->dev; + struct drm_printer p = drm_seq_file_printer(m); + struct drm_client_dev *client; + + mutex_lock(&dev->clientlist_mutex); + list_for_each_entry(client, &dev->clientlist, list) + drm_printf(&p, "%s\n", client->name); + mutex_unlock(&dev->clientlist_mutex); + + return 0; +} + +static const struct drm_info_list drm_client_debugfs_list[] = { + { "internal_clients", drm_client_debugfs_internal_clients, 0 }, +}; + +int drm_client_debugfs_init(struct drm_minor *minor) +{ + return drm_debugfs_create_files(drm_client_debugfs_list, + ARRAY_SIZE(drm_client_debugfs_list), + minor->debugfs_root, minor); +} +#endif diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c index b2482818fee8..50a20bfc07ea 100644 --- a/drivers/gpu/drm/drm_debugfs.c +++ b/drivers/gpu/drm/drm_debugfs.c @@ -28,6 +28,7 @@ #include #include +#include #include #include #include @@ -164,6 +165,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id, DRM_ERROR("Failed to create framebuffer debugfs file\n"); return ret; } + + ret = drm_client_debugfs_init(minor); + if (ret) { + DRM_ERROR("Failed to create client debugfs file\n"); + return ret; + } } if (dev->driver->debugfs_init) { diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h index 02cbb02714d8..e03ac786b0e1 100644 --- a/include/drm/drm_client.h +++ b/include/drm/drm_client.h @@ -10,6 +10,7 @@ struct drm_device; struct drm_file; struct drm_framebuffer; struct drm_gem_object; +struct drm_minor; struct module; /** @@ -146,4 +147,6 @@ struct drm_client_buffer * drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32 height, u32 format); void drm_client_framebuffer_delete(struct drm_client_buffer *buffer); +int drm_client_debugfs_init(struct drm_minor *minor); + #endif -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 9/9] drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()
Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has moved to drm_fbdev_generic_setup(). Cc: Laurent Pinchart Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_fb_cma_helper.c | 21 - include/drm/drm_fb_cma_helper.h | 3 --- 2 files changed, 24 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 718c7f961d8a..9da36a6271d3 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -99,27 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer *fb, } EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr); -/** - * drm_fb_cma_fbdev_init_with_funcs() - Allocate and initialize fbdev emulation - * @dev: DRM device - * @preferred_bpp: Preferred bits per pixel for the device. - * @dev->mode_config.preferred_depth is used if this is zero. - * @max_conn_count: Maximum number of connectors. - * @dev->mode_config.num_connector is used if this is zero. - * @funcs: Framebuffer functions, in particular a custom dirty() callback. - * Can be NULL. - * - * Returns: - * Zero on success or negative error code on failure. - */ -int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev, - unsigned int preferred_bpp, unsigned int max_conn_count, - const struct drm_framebuffer_funcs *funcs) -{ - return drm_fb_cma_fbdev_init(dev, preferred_bpp, max_conn_count); -} -EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_init_with_funcs); - /** * drm_fb_cma_fbdev_init() - Allocate and initialize fbdev emulation * @dev: DRM device diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h index a0546c3451f9..96e26e3b9a0c 100644 --- a/include/drm/drm_fb_cma_helper.h +++ b/include/drm/drm_fb_cma_helper.h @@ -16,9 +16,6 @@ struct drm_mode_fb_cmd2; struct drm_plane; struct drm_plane_state; -int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev, - unsigned int preferred_bpp, unsigned int max_conn_count, - const struct drm_framebuffer_funcs *funcs); int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int preferred_bpp, unsigned int max_conn_count); void drm_fb_cma_fbdev_fini(struct drm_device *dev); -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 5/9] drm/client: Add client callbacks
Add client callbacks and hook them up. Add a list of clients per drm_device. Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_client.c| 92 - drivers/gpu/drm/drm_drv.c | 7 +++ drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- drivers/gpu/drm/drm_fb_helper.c | 11 - drivers/gpu/drm/drm_file.c | 3 ++ drivers/gpu/drm/drm_probe_helper.c | 3 ++ include/drm/drm_client.h| 75 +- include/drm/drm_device.h| 14 ++ 8 files changed, 201 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c index 9c9b8ac7aea3..f05ee98bd10c 100644 --- a/drivers/gpu/drm/drm_client.c +++ b/drivers/gpu/drm/drm_client.c @@ -4,6 +4,7 @@ */ #include +#include #include #include #include @@ -66,6 +67,7 @@ EXPORT_SYMBOL(drm_client_close); * @dev: DRM device * @client: DRM client * @name: Client name + * @funcs: DRM client functions (optional) * * Use drm_client_put() to free the client. * @@ -73,24 +75,47 @@ EXPORT_SYMBOL(drm_client_close); * Zero on success or negative error code on failure. */ int drm_client_new(struct drm_device *dev, struct drm_client_dev *client, - const char *name) + const char *name, const struct drm_client_funcs *funcs) { + bool registered; int ret; if (!drm_core_check_feature(dev, DRIVER_MODESET) || !dev->driver->dumb_create || !dev->driver->gem_prime_vmap) return -ENOTSUPP; + if (funcs && !try_module_get(funcs->owner)) + return -ENODEV; + client->dev = dev; client->name = name; + client->funcs = funcs; ret = drm_client_open(client); if (ret) - return ret; + goto err_put_module; + + mutex_lock(&dev->clientlist_mutex); + registered = dev->registered; + if (registered) + list_add(&client->list, &dev->clientlist); + mutex_unlock(&dev->clientlist_mutex); + if (!registered) { + ret = -ENODEV; + goto err_close; + } drm_dev_get(dev); return 0; + +err_close: + drm_client_close(client); +err_put_module: + if (funcs) + module_put(funcs->owner); + + return ret; } EXPORT_SYMBOL(drm_client_new); @@ -116,9 +141,72 @@ void drm_client_release(struct drm_client_dev *client) drm_client_close(client); drm_dev_put(dev); + if (client->funcs) + module_put(client->funcs->owner); } EXPORT_SYMBOL(drm_client_release); +void drm_client_dev_unregister(struct drm_device *dev) +{ + struct drm_client_dev *client, *tmp; + + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return; + + mutex_lock(&dev->clientlist_mutex); + list_for_each_entry_safe(client, tmp, &dev->clientlist, list) { + list_del(&client->list); + if (client->funcs && client->funcs->unregister) { + client->funcs->unregister(client); + } else { + drm_client_release(client); + kfree(client); + } + } + mutex_unlock(&dev->clientlist_mutex); +} + +void drm_client_dev_hotplug(struct drm_device *dev) +{ + struct drm_client_dev *client; + int ret; + + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return; + + mutex_lock(&dev->clientlist_mutex); + list_for_each_entry(client, &dev->clientlist, list) { + if (!client->funcs || !client->funcs->hotplug) + continue; + + ret = client->funcs->hotplug(client); + DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret); + } + mutex_unlock(&dev->clientlist_mutex); +} +EXPORT_SYMBOL(drm_client_dev_hotplug); + +void drm_client_dev_restore(struct drm_device *dev) +{ + struct drm_client_dev *client; + int ret; + + if (!drm_core_check_feature(dev, DRIVER_MODESET)) + return; + + mutex_lock(&dev->clientlist_mutex); + list_for_each_entry(client, &dev->clientlist, list) { + if (!client->funcs || !client->funcs->restore) + continue; + + ret = client->funcs->restore(client); + DRM_DEV_DEBUG_KMS(dev->dev, "%s: ret=%d\n", client->name, ret); + if (!ret) /* The first one to return zero gets the privilege to restore */ + break; + } + mutex_unlock(&dev->clientlist_mutex); +} + static void drm_client_buffer_delete(struct drm_client_buffer *buffer) { struct drm_device *dev = buffer->client->dev; diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c index e7ff0b03328b..6eb935bb2f92 100644 --- a/drivers/gpu/drm/drm_drv.c +++ b/drivers/gpu/d
[Intel-gfx] [PATCH v4 0/9] drm: Add generic fbdev emulation
This patchset adds generic fbdev emulation for drivers that supports GEM based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An API is begun to support in-kernel clients in general. Change this version: Fix a bug in an error path that the kbuild test robot caught. Change previous version: Rework client removal (again). Drop reference counting, only allow the driver to remove a client. Noralf. Changes since version 3: - drm/cma-helper: Use the generic fbdev emulation: Fix error path - Remove setting .lastclose in new tinydrm driver ili9341 Changes since version 2: - Applied first 3 patches to drm-misc-next - Drop client reference counting and only allow the driver to release clients. Noralf Trønnes (9): drm: Begin an API for in-kernel clients drm/fb-helper: Add generic fbdev emulation .fb_probe function drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap drm/cma-helper: Use the generic fbdev emulation drm/client: Add client callbacks drm/debugfs: Add internal client debugfs file drm/fb-helper: Finish the generic fbdev emulation drm/tinydrm: Use drm_fbdev_generic_setup() drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() Documentation/gpu/drm-client.rst| 12 + Documentation/gpu/index.rst | 1 + drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/drm_client.c| 405 drivers/gpu/drm/drm_debugfs.c | 7 + drivers/gpu/drm/drm_drv.c | 8 + drivers/gpu/drm/drm_fb_cma_helper.c | 379 +++--- drivers/gpu/drm/drm_fb_helper.c | 316 +- drivers/gpu/drm/drm_file.c | 3 + drivers/gpu/drm/drm_probe_helper.c | 3 + drivers/gpu/drm/pl111/pl111_drv.c | 2 + drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +- drivers/gpu/drm/tinydrm/ili9225.c | 1 - drivers/gpu/drm/tinydrm/ili9341.c | 1 - drivers/gpu/drm/tinydrm/mi0283qt.c | 1 - drivers/gpu/drm/tinydrm/st7586.c| 1 - drivers/gpu/drm/tinydrm/st7735r.c | 1 - include/drm/drm_client.h| 152 +++ include/drm/drm_device.h| 21 ++ include/drm/drm_fb_cma_helper.h | 6 - include/drm/drm_fb_helper.h | 38 +++ 21 files changed, 1010 insertions(+), 353 deletions(-) create mode 100644 Documentation/gpu/drm-client.rst create mode 100644 drivers/gpu/drm/drm_client.c create mode 100644 include/drm/drm_client.h -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/9] drm/fb-helper: Add generic fbdev emulation .fb_probe function
This is the first step in getting generic fbdev emulation. A drm_fb_helper_funcs.fb_probe function is added which uses the DRM client API to get a framebuffer backed by a dumb buffer. Signed-off-by: Noralf Trønnes Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 192 +++- include/drm/drm_fb_helper.h | 31 +++ 2 files changed, 222 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index cab14f253384..0a0a577ebc3c 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -30,6 +30,7 @@ #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include +#include #include #include #include @@ -738,6 +739,24 @@ static void drm_fb_helper_resume_worker(struct work_struct *work) console_unlock(); } +static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper, + struct drm_clip_rect *clip) +{ + struct drm_framebuffer *fb = fb_helper->fb; + unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0); + size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp; + void *src = fb_helper->fbdev->screen_buffer + offset; + void *dst = fb_helper->buffer->vaddr + offset; + size_t len = (clip->x2 - clip->x1) * cpp; + unsigned int y; + + for (y = clip->y1; y < clip->y2; y++) { + memcpy(dst, src, len); + src += fb->pitches[0]; + dst += fb->pitches[0]; + } +} + static void drm_fb_helper_dirty_work(struct work_struct *work) { struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper, @@ -753,8 +772,12 @@ static void drm_fb_helper_dirty_work(struct work_struct *work) spin_unlock_irqrestore(&helper->dirty_lock, flags); /* call dirty callback only when it has been really touched */ - if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) + if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) { + /* Generic fbdev uses a shadow buffer */ + if (helper->buffer) + drm_fb_helper_dirty_blit_real(helper, &clip_copy); helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip_copy, 1); + } } /** @@ -2921,6 +2944,173 @@ void drm_fb_helper_output_poll_changed(struct drm_device *dev) } EXPORT_SYMBOL(drm_fb_helper_output_poll_changed); +/* @user: 1=userspace, 0=fbcon */ +static int drm_fbdev_fb_open(struct fb_info *info, int user) +{ + struct drm_fb_helper *fb_helper = info->par; + + if (!try_module_get(fb_helper->dev->driver->fops->owner)) + return -ENODEV; + + return 0; +} + +static int drm_fbdev_fb_release(struct fb_info *info, int user) +{ + struct drm_fb_helper *fb_helper = info->par; + + module_put(fb_helper->dev->driver->fops->owner); + + return 0; +} + +/* + * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of + * unregister_framebuffer() or fb_release(). + */ +static void drm_fbdev_fb_destroy(struct fb_info *info) +{ + struct drm_fb_helper *fb_helper = info->par; + struct fb_info *fbi = fb_helper->fbdev; + struct fb_ops *fbops = NULL; + void *shadow = NULL; + + if (fbi->fbdefio) { + fb_deferred_io_cleanup(fbi); + shadow = fbi->screen_buffer; + fbops = fbi->fbops; + } + + drm_fb_helper_fini(fb_helper); + + if (shadow) { + vfree(shadow); + kfree(fbops); + } + + drm_client_framebuffer_delete(fb_helper->buffer); + drm_client_release(&fb_helper->client); + kfree(fb_helper); +} + +static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma) +{ + struct drm_fb_helper *fb_helper = info->par; + + if (fb_helper->dev->driver->gem_prime_mmap) + return fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma); + else + return -ENODEV; +} + +static struct fb_ops drm_fbdev_fb_ops = { + .owner = THIS_MODULE, + DRM_FB_HELPER_DEFAULT_OPS, + .fb_open= drm_fbdev_fb_open, + .fb_release = drm_fbdev_fb_release, + .fb_destroy = drm_fbdev_fb_destroy, + .fb_mmap= drm_fbdev_fb_mmap, + .fb_read= drm_fb_helper_sys_read, + .fb_write = drm_fb_helper_sys_write, + .fb_fillrect= drm_fb_helper_sys_fillrect, + .fb_copyarea= drm_fb_helper_sys_copyarea, + .fb_imageblit = drm_fb_helper_sys_imageblit, +}; + +static struct fb_deferred_io drm_fbdev_defio = { + .delay = HZ / 20, + .deferred_io= drm_fb_helper_deferred_io, +}; + +/** + * drm_fb_helper_generic_probe - Generic fbdev emulation probe helper + * @fb_helper: fbdev helper structure + * @sizes: describes fbdev size and scanout surface
[Intel-gfx] [PATCH v4 3/9] drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
These are needed for pl111 to use the generic fbdev emulation. Cc: Eric Anholt Signed-off-by: Noralf Trønnes Reviewed-by: Eric Anholt --- drivers/gpu/drm/pl111/pl111_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/pl111/pl111_drv.c b/drivers/gpu/drm/pl111/pl111_drv.c index 054b93689d94..17a38e85ba7d 100644 --- a/drivers/gpu/drm/pl111/pl111_drv.c +++ b/drivers/gpu/drm/pl111/pl111_drv.c @@ -250,6 +250,8 @@ static struct drm_driver pl111_drm_driver = { .gem_prime_import_sg_table = pl111_gem_import_sg_table, .gem_prime_export = drm_gem_prime_export, .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, + .gem_prime_mmap = drm_gem_cma_prime_mmap, + .gem_prime_vmap = drm_gem_cma_prime_vmap, #if defined(CONFIG_DEBUG_FS) .debugfs_init = pl111_debugfs_init, -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/9] drm: Begin an API for in-kernel clients
This the beginning of an API for in-kernel clients. First out is a way to get a framebuffer backed by a dumb buffer. Only GEM drivers are supported. The original idea of using an exported dma-buf was dropped because it also creates an anonomous file descriptor which doesn't work when the buffer is created from a kernel thread. The easy way out is to use drm_driver.gem_prime_vmap to get the virtual address, which requires a GEM object. This excludes the vmwgfx driver which is the only non-GEM driver apart from the legacy ones. A solution for vmwgfx will have to be worked out later if it wants to support the client API which it probably will when we have a bootsplash client. Signed-off-by: Noralf Trønnes Reviewed-by: Daniel Vetter --- Documentation/gpu/drm-client.rst | 12 ++ Documentation/gpu/index.rst | 1 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_client.c | 289 +++ drivers/gpu/drm/drm_drv.c| 1 + include/drm/drm_client.h | 76 ++ include/drm/drm_device.h | 7 + 7 files changed, 387 insertions(+), 1 deletion(-) create mode 100644 Documentation/gpu/drm-client.rst create mode 100644 drivers/gpu/drm/drm_client.c create mode 100644 include/drm/drm_client.h diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst new file mode 100644 index ..7e672063e7eb --- /dev/null +++ b/Documentation/gpu/drm-client.rst @@ -0,0 +1,12 @@ += +Kernel clients += + +.. kernel-doc:: drivers/gpu/drm/drm_client.c + :doc: overview + +.. kernel-doc:: include/drm/drm_client.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_client.c + :export: diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 00288f34c5a6..1fcf8e851e15 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi + drm-client drivers vga-switcheroo vgaarbiter diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 69c13517ea3a..d6657a61d037 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -18,7 +18,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \ drm_encoder.o drm_mode_object.o drm_property.o \ drm_plane.o drm_color_mgmt.o drm_print.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ - drm_syncobj.o drm_lease.o drm_writeback.o + drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o drm-$(CONFIG_DRM_VM) += drm_vm.o diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c new file mode 100644 index ..9c9b8ac7aea3 --- /dev/null +++ b/drivers/gpu/drm/drm_client.c @@ -0,0 +1,289 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright 2018 Noralf Trønnes + */ + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "drm_crtc_internal.h" +#include "drm_internal.h" + +/** + * DOC: overview + * + * This library provides support for clients running in the kernel like fbdev and bootsplash. + * Currently it's only partially implemented, just enough to support fbdev. + * + * GEM drivers which provide a GEM based dumb buffer with a virtual address are supported. + */ + +static int drm_client_open(struct drm_client_dev *client) +{ + struct drm_device *dev = client->dev; + struct drm_file *file; + + file = drm_file_alloc(dev->primary); + if (IS_ERR(file)) + return PTR_ERR(file); + + mutex_lock(&dev->filelist_mutex); + list_add(&file->lhead, &dev->filelist_internal); + mutex_unlock(&dev->filelist_mutex); + + client->file = file; + + return 0; +} + +static void drm_client_close(struct drm_client_dev *client) +{ + struct drm_device *dev = client->dev; + + mutex_lock(&dev->filelist_mutex); + list_del(&client->file->lhead); + mutex_unlock(&dev->filelist_mutex); + + drm_file_free(client->file); +} +EXPORT_SYMBOL(drm_client_close); + +/** + * drm_client_new - Create a DRM client + * @dev: DRM device + * @client: DRM client + * @name: Client name + * + * Use drm_client_put() to free the client. + * + * Returns: + * Zero on success or negative error code on failure. + */ +int drm_client_new(struct drm_device *dev, struct drm_client_dev *client, + const char *name) +{ + int ret; + + if (!drm_core_check_feature(dev, DRIVER_MODESET) || + !dev->driver->dumb_create || !dev->driver->gem_prime_vmap) + return -ENOTSUPP; + + client->dev = dev; + client->name = name; + + ret = drm_client_open(client); + if (ret) + return ret; + + drm_dev_get(dev);
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Show who pinned the pages when a leak is hit (rev2)
== Series Details == Series: drm/i915: Show who pinned the pages when a leak is hit (rev2) URL : https://patchwork.freedesktop.org/series/45770/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4412_full -> Patchwork_9495_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9495_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9495_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9495_full: === IGT changes === Possible regressions igt@gem_pwrite@big-cpu-random: shard-kbl: PASS -> DMESG-WARN +5 igt@gem_pwrite@big-gtt-backwards: shard-hsw: PASS -> DMESG-WARN +6 igt@gem_pwrite@big-gtt-random: shard-apl: PASS -> DMESG-WARN +3 shard-glk: PASS -> DMESG-WARN +3 igt@gem_pwrite@huge-gtt-fbr: shard-snb: PASS -> DMESG-WARN +5 Warnings igt@gem_mocs_settings@mocs-rc6-render: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9495_full that come from known issues: === IGT changes === Issues hit igt@gem_tiled_fence_blits@normal: shard-snb: NOTRUN -> INCOMPLETE (fdo#105411) igt@gem_workarounds@suspend-resume-context: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@kms_flip@2x-flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_flip@plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_suspend@shrink: shard-glk: FAIL (fdo#106886) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105189) -> PASS igt@kms_flip@2x-plain-flip-fb-recreate: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#102887, fdo#105363) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724) -> PASS +1 igt@kms_rotation_crc@sprite-rotation-180: shard-snb: FAIL (fdo#104724, fdo#103925) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS igt@perf_pmu@busy-idle-no-semaphores-vecs0: shard-snb: INCOMPLETE (fdo#105411) -> SKIP fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103925 https://bugs.freedesktop.org/show_bug.cgi?id=103925 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4412 -> Patchwork_9495 CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9495: cd6455c5f8ad1d2336f31839edaa97525824b157 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9495/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support.
From: Stanislav Lisovskiy PLANE_CTL_FORMAT_AYUV is already supported, according to hardware specification. v2: Edited commit message, removed redundant whitespaces. Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_display.c | 7 +++ drivers/gpu/drm/i915/intel_sprite.c | 2 ++ 2 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 56818a45181c..d6de5ddcb912 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = { DRM_FORMAT_YVYU, DRM_FORMAT_UYVY, DRM_FORMAT_VYUY, + DRM_FORMAT_AYUV, }; static const uint32_t skl_pri_planar_formats[] = { @@ -102,6 +103,7 @@ static const uint32_t skl_pri_planar_formats[] = { DRM_FORMAT_UYVY, DRM_FORMAT_VYUY, DRM_FORMAT_NV12, + DRM_FORMAT_AYUV, }; static const uint64_t skl_format_modifiers_noccs[] = { @@ -3497,6 +3499,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format) return PLANE_CTL_FORMAT_XRGB_2101010; case DRM_FORMAT_XBGR2101010: return PLANE_CTL_ORDER_RGBX | PLANE_CTL_FORMAT_XRGB_2101010; + case DRM_FORMAT_AYUV: + return PLANE_CTL_FORMAT_AYUV; case DRM_FORMAT_YUYV: return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV; case DRM_FORMAT_YVYU: @@ -13396,6 +13400,8 @@ static bool skl_plane_format_mod_supported(struct drm_plane *_plane, modifier == I915_FORMAT_MOD_Y_TILED) return true; /* fall through */ + case DRM_FORMAT_AYUV: + return true; default: return false; } @@ -14510,6 +14516,7 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, goto err; } break; + case DRM_FORMAT_AYUV: case DRM_FORMAT_YUYV: case DRM_FORMAT_UYVY: case DRM_FORMAT_YVYU: diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 344c0e709b19..8f95f8aad513 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1423,6 +1423,8 @@ static bool skl_plane_format_mod_supported(struct drm_plane *_plane, case DRM_FORMAT_NV12: if (modifier == I915_FORMAT_MOD_Yf_TILED) return true; + case DRM_FORMAT_AYUV: + return true; /* fall through */ case DRM_FORMAT_C8: if (modifier == DRM_FORMAT_MOD_LINEAR || -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1] drm/i915: Adding YUV444 packed format(DRM_FORMAT_AYUV) support.
From: Stanislav Lisovskiy --- drivers/gpu/drm/i915/intel_display.c | 8 drivers/gpu/drm/i915/intel_sprite.c | 3 +++ 2 files changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 56818a45181c..4bc702193c88 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -86,6 +86,7 @@ static const uint32_t skl_primary_formats[] = { DRM_FORMAT_YVYU, DRM_FORMAT_UYVY, DRM_FORMAT_VYUY, + DRM_FORMAT_AYUV, }; static const uint32_t skl_pri_planar_formats[] = { @@ -102,6 +103,7 @@ static const uint32_t skl_pri_planar_formats[] = { DRM_FORMAT_UYVY, DRM_FORMAT_VYUY, DRM_FORMAT_NV12, + DRM_FORMAT_AYUV, }; static const uint64_t skl_format_modifiers_noccs[] = { @@ -2446,6 +2448,7 @@ static const struct drm_format_info ccs_formats[] = { { .format = DRM_FORMAT_ABGR, .depth = 32, .num_planes = 2, .cpp = { 4, 1, }, .hsub = 8, .vsub = 16, }, }; + static const struct drm_format_info * lookup_format_info(const struct drm_format_info formats[], int num_formats, u32 format) @@ -3497,6 +3500,8 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format) return PLANE_CTL_FORMAT_XRGB_2101010; case DRM_FORMAT_XBGR2101010: return PLANE_CTL_ORDER_RGBX | PLANE_CTL_FORMAT_XRGB_2101010; + case DRM_FORMAT_AYUV: + return PLANE_CTL_FORMAT_AYUV; case DRM_FORMAT_YUYV: return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV; case DRM_FORMAT_YVYU: @@ -13396,6 +13401,8 @@ static bool skl_plane_format_mod_supported(struct drm_plane *_plane, modifier == I915_FORMAT_MOD_Y_TILED) return true; /* fall through */ + case DRM_FORMAT_AYUV: + return true; default: return false; } @@ -14510,6 +14517,7 @@ static int intel_framebuffer_init(struct intel_framebuffer *intel_fb, goto err; } break; + case DRM_FORMAT_AYUV: case DRM_FORMAT_YUYV: case DRM_FORMAT_UYVY: case DRM_FORMAT_YVYU: diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 344c0e709b19..1bc446987720 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -585,6 +585,7 @@ vlv_update_plane(struct intel_plane *plane, I915_WRITE_FW(SPCONSTALPHA(pipe, plane_id), 0); I915_WRITE_FW(SPSIZE(pipe, plane_id), (crtc_h << 16) | crtc_w); + I915_WRITE_FW(SPCNTR(pipe, plane_id), sprctl); I915_WRITE_FW(SPSURF(pipe, plane_id), intel_plane_ggtt_offset(plane_state) + sprsurf_offset); @@ -1423,6 +1424,8 @@ static bool skl_plane_format_mod_supported(struct drm_plane *_plane, case DRM_FORMAT_NV12: if (modifier == I915_FORMAT_MOD_Yf_TILED) return true; + case DRM_FORMAT_AYUV: + return true; /* fall through */ case DRM_FORMAT_C8: if (modifier == DRM_FORMAT_MOD_LINEAR || -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/9] drm/nouveau: Use drm_connector_for_each_possible_encoder()
On Sat, Jun 30, 2018 at 10:12:21PM +0300, Dan Carpenter wrote: > Hi Ville, > > Thank you for the patch! Perhaps something to improve: > > url: > https://github.com/0day-ci/linux/commits/Ville-Syrjala/drm-Third-attempt-at-fixing-the-fb-helper-best_encoder-mess/20180629-014202 > base: git://people.freedesktop.org/~airlied/linux.git drm-next > > smatch warnings: > drivers/gpu/drm/nouveau/nouveau_connector.c:461 > nouveau_connector_ddc_detect() error: uninitialized symbol 'nv_encoder'. > > # > https://github.com/0day-ci/linux/commit/7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06 > git remote add linux-review https://github.com/0day-ci/linux > git remote update linux-review > git checkout 7ec8bb65386edfb0b2bdc8e8391eb5e6eac44c06 > vim +/nv_encoder +461 drivers/gpu/drm/nouveau/nouveau_connector.c > > 6ee738610 Ben Skeggs 2009-12-11 407 > 8777c5c11 Ben Skeggs 2014-06-06 408 static struct nouveau_encoder * > 8777c5c11 Ben Skeggs 2014-06-06 409 > nouveau_connector_ddc_detect(struct drm_connector *connector) > 6ee738610 Ben Skeggs 2009-12-11 410 { > 6ee738610 Ben Skeggs 2009-12-11 411 struct drm_device *dev = > connector->dev; > 1a1841d30 Ben Skeggs 2012-12-10 412 struct nouveau_connector > *nv_connector = nouveau_connector(connector); > 77145f1cb Ben Skeggs 2012-07-31 413 struct nouveau_drm *drm = > nouveau_drm(dev); > 1167c6bc5 Ben Skeggs 2016-05-18 414 struct nvkm_gpio *gpio = > nvxx_gpio(&drm->client.device); > 8777c5c11 Ben Skeggs 2014-06-06 415 struct nouveau_encoder > *nv_encoder; > 6d385c0aa Rob Clark 2014-07-17 416 struct drm_encoder *encoder; > 1a1841d30 Ben Skeggs 2012-12-10 417 int i, panel = -ENODEV; > 1a1841d30 Ben Skeggs 2012-12-10 418 > 1a1841d30 Ben Skeggs 2012-12-10 419 /* eDP panels need powering on > by us (if the VBIOS doesn't default it > 1a1841d30 Ben Skeggs 2012-12-10 420 * to on) before doing any AUX > channel transactions. LVDS panel power > 1a1841d30 Ben Skeggs 2012-12-10 421 * is handled by the SOR > itself, and not required for LVDS DDC. > 1a1841d30 Ben Skeggs 2012-12-10 422 */ > 1a1841d30 Ben Skeggs 2012-12-10 423 if (nv_connector->type == > DCB_CONNECTOR_eDP) { > 2ea7249fe Ben Skeggs 2015-08-20 424 panel = > nvkm_gpio_get(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff); > 1a1841d30 Ben Skeggs 2012-12-10 425 if (panel == 0) { > 2ea7249fe Ben Skeggs 2015-08-20 426 > nvkm_gpio_set(gpio, 0, DCB_GPIO_PANEL_POWER, 0xff, 1); > 1a1841d30 Ben Skeggs 2012-12-10 427 msleep(300); > 1a1841d30 Ben Skeggs 2012-12-10 428 } > 1a1841d30 Ben Skeggs 2012-12-10 429 } > 6ee738610 Ben Skeggs 2009-12-11 430 > 7ec8bb653 Ville Syrjälä 2018-06-28 431 > drm_connector_for_each_possible_encoder(connector, encoder, i) { > 6d385c0aa Rob Clark 2014-07-17 432 nv_encoder = > nouveau_encoder(encoder); > > ^ > If we enter the loop that means nv_encoder is non-NULL. Smatch can't > prove that we always enter the loop in this case for whatever reason but > my guess is that we always do. > > 4ca2b7120 Francisco Jerez 2010-08-08 433 > 8777c5c11 Ben Skeggs 2014-06-06 434 if > (nv_encoder->dcb->type == DCB_OUTPUT_DP) { > 8777c5c11 Ben Skeggs 2014-06-06 435 int ret = > nouveau_dp_detect(nv_encoder); > 52aa30f25 Ben Skeggs 2016-11-04 436 if (ret == > NOUVEAU_DP_MST) > 52aa30f25 Ben Skeggs 2016-11-04 437 return > NULL; > 52aa30f25 Ben Skeggs 2016-11-04 438 if (ret == > NOUVEAU_DP_SST) > 8777c5c11 Ben Skeggs 2014-06-06 439 break; > 8777c5c11 Ben Skeggs 2014-06-06 440 } else > 39c1c9011 Lukas Wunner2016-01-11 441 if > ((vga_switcheroo_handler_flags() & > 39c1c9011 Lukas Wunner2016-01-11 442 > VGA_SWITCHEROO_CAN_SWITCH_DDC) && > 39c1c9011 Lukas Wunner2016-01-11 443 > nv_encoder->dcb->type == DCB_OUTPUT_LVDS && > 39c1c9011 Lukas Wunner2016-01-11 444 nv_encoder->i2c) { > 39c1c9011 Lukas Wunner2016-01-11 445 int ret; > 39c1c9011 Lukas Wunner2016-01-11 446 > vga_switcheroo_lock_ddc(dev->pdev); > 39c1c9011 Lukas Wunner2016-01-11 447 ret = > nvkm_probe_i2c(nv_encoder->i2c, 0x50); > 39c1c9011 Lukas Wunner2016-01-11 448 > vga_switcheroo_unlock_ddc(dev->pdev); > 39c1c9011 Lukas Wunner2016-01-11 449 if (ret) > 39c1c9011 Lukas Wunner2016-01-11 450 break; > 39c1c9011 Lukas Wunner2016-01-11 451
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon 02-07-18 14:39:50, Christian König wrote: [...] > Not wanting to block something as important as this, so feel free to add an > Acked-by: Christian König to the patch. Thanks a lot! > Let's rather face the next topic: Any idea how to runtime test this? This is a good question indeed. One way to do that would be triggering the OOM killer from the context which uses each of these mmu notifiers (one at the time) and see how that works. You would see the note in the log whenever the notifier would block. The primary thing to test is how often the oom reaper really had to back off completely. > I mean I can rather easily provide a test which crashes an AMD GPU, which in > turn then would mean that the MMU notifier would block forever without this > patch. Well, you do not really have to go that far. It should be sufficient to do the above. The current code would simply back of without releasing any memory. The patch should help to reclaim some memory. > But do you know a way to let the OOM killer kill a specific process? Yes, you can set its oom_score_adj to 1000 which means always select that task. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/20] drm/i915/icl: Power down unused DSI lanes
> -Original Message- > From: Nikula, Jani > Sent: Monday, July 2, 2018 6:12 PM > To: Chauhan, Madhav ; intel- > g...@lists.freedesktop.org > Cc: Zanoni, Paulo R ; Shankar, Uma > ; Vivi, Rodrigo ; > Chauhan, Madhav > Subject: Re: [PATCH 06/20] drm/i915/icl: Power down unused DSI lanes > > On Fri, 15 Jun 2018, Madhav Chauhan wrote: > > To save power, unused lanes should be powered down using the bitfield > > of PORT_CL_DW10. > > > > Signed-off-by: Madhav Chauhan > > --- > > drivers/gpu/drm/i915/intel_dsi_new.c | 44 > > > > 1 file changed, 44 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c > > b/drivers/gpu/drm/i915/intel_dsi_new.c > > index 5ec4016..baaf46d 100644 > > --- a/drivers/gpu/drm/i915/intel_dsi_new.c > > +++ b/drivers/gpu/drm/i915/intel_dsi_new.c > > @@ -74,6 +74,47 @@ static void gen11_dsi_enable_io_power(struct > intel_encoder *encoder) > > intel_display_power_get(dev_priv, > POWER_DOMAIN_PORT_DDI_B_IO); } > > > > +static void gen11_dsi_power_up_lanes(struct intel_encoder *encoder) { > > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > > + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base); > > + enum port port; > > + u32 tmp; > > + u32 lane_mask; > > + > > + switch (intel_dsi->lane_count) { > > + case 1: > > + lane_mask = PWR_DOWN_LN_3_1_0; > > + break; > > + case 2: > > + lane_mask = PWR_DOWN_LN_3_1; > > + break; > > + case 3: > > + lane_mask = PWR_DOWN_LN_3; > > + break; > > + case 4: > > + lane_mask = PWR_UP_ALL_LANES; > > + break; > > + default: > > Just put the default label next to case 4 to reduce duplication. > > > + lane_mask = PWR_UP_ALL_LANES; > > + break; > > + } > > + > > + lane_mask = lane_mask << PWR_DOWN_LN_SHIFT; > > Include the shifts in the macros as discussed. > > With those, > > Reviewed-by: Jani Nikula Ok. Thanks for review Regards, Madhav > > > + > > + for_each_dsi_port(port, intel_dsi->ports) { > > + tmp = I915_READ(ICL_PORT_CL_DW10(port)); > > + tmp &= ~PWR_DOWN_LN_MASK; > > + I915_WRITE(ICL_PORT_CL_DW10(port), tmp | lane_mask); > > + } > > +} > > + > > +static void gen11_dsi_enable_port_and_phy(struct intel_encoder > > +*encoder) { > > + /* step 4a: power up all lanes of the DDI used by DSI */ > > + gen11_dsi_power_up_lanes(encoder); > > +} > > + > > static void __attribute__((unused)) gen11_dsi_pre_enable( > > struct intel_encoder *encoder, > > const struct intel_crtc_state *pipe_config, > @@ -84,4 +125,7 @@ > > static void __attribute__((unused)) gen11_dsi_pre_enable( > > > > /* step3: enable DSI PLL */ > > gen11_dsi_program_esc_clk_div(encoder); > > + > > + /* step4: enable DSI port and DPHY */ > > + gen11_dsi_enable_port_and_phy(encoder); > > } > > -- > 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 06/20] drm/i915/icl: Power down unused DSI lanes
On Fri, 15 Jun 2018, Madhav Chauhan wrote: > To save power, unused lanes should be powered > down using the bitfield of PORT_CL_DW10. > > Signed-off-by: Madhav Chauhan > --- > drivers/gpu/drm/i915/intel_dsi_new.c | 44 > > 1 file changed, 44 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c > b/drivers/gpu/drm/i915/intel_dsi_new.c > index 5ec4016..baaf46d 100644 > --- a/drivers/gpu/drm/i915/intel_dsi_new.c > +++ b/drivers/gpu/drm/i915/intel_dsi_new.c > @@ -74,6 +74,47 @@ static void gen11_dsi_enable_io_power(struct intel_encoder > *encoder) > intel_display_power_get(dev_priv, POWER_DOMAIN_PORT_DDI_B_IO); > } > > +static void gen11_dsi_power_up_lanes(struct intel_encoder *encoder) > +{ > + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > + struct intel_dsi *intel_dsi = enc_to_intel_dsi(&encoder->base); > + enum port port; > + u32 tmp; > + u32 lane_mask; > + > + switch (intel_dsi->lane_count) { > + case 1: > + lane_mask = PWR_DOWN_LN_3_1_0; > + break; > + case 2: > + lane_mask = PWR_DOWN_LN_3_1; > + break; > + case 3: > + lane_mask = PWR_DOWN_LN_3; > + break; > + case 4: > + lane_mask = PWR_UP_ALL_LANES; > + break; > + default: Just put the default label next to case 4 to reduce duplication. > + lane_mask = PWR_UP_ALL_LANES; > + break; > + } > + > + lane_mask = lane_mask << PWR_DOWN_LN_SHIFT; Include the shifts in the macros as discussed. With those, Reviewed-by: Jani Nikula > + > + for_each_dsi_port(port, intel_dsi->ports) { > + tmp = I915_READ(ICL_PORT_CL_DW10(port)); > + tmp &= ~PWR_DOWN_LN_MASK; > + I915_WRITE(ICL_PORT_CL_DW10(port), tmp | lane_mask); > + } > +} > + > +static void gen11_dsi_enable_port_and_phy(struct intel_encoder *encoder) > +{ > + /* step 4a: power up all lanes of the DDI used by DSI */ > + gen11_dsi_power_up_lanes(encoder); > +} > + > static void __attribute__((unused)) gen11_dsi_pre_enable( > struct intel_encoder *encoder, > const struct intel_crtc_state *pipe_config, > @@ -84,4 +125,7 @@ static void __attribute__((unused)) gen11_dsi_pre_enable( > > /* step3: enable DSI PLL */ > gen11_dsi_program_esc_clk_div(encoder); > + > + /* step4: enable DSI port and DPHY */ > + gen11_dsi_enable_port_and_phy(encoder); > } -- 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] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Am 02.07.2018 um 14:35 schrieb Michal Hocko: On Mon 02-07-18 14:24:29, Christian König wrote: Am 02.07.2018 um 14:20 schrieb Michal Hocko: On Mon 02-07-18 14:13:42, Christian König wrote: Am 02.07.2018 um 13:54 schrieb Michal Hocko: On Mon 02-07-18 11:14:58, Christian König wrote: Am 27.06.2018 um 09:44 schrieb Michal Hocko: This is the v2 of RFC based on the feedback I've received so far. The code even compiles as a bonus ;) I haven't runtime tested it yet, mostly because I have no idea how. Any further feedback is highly appreciated of course. That sounds like it should work and at least the amdgpu changes now look good to me on first glance. Can you split that up further in the usual way? E.g. adding the blockable flag in one patch and fixing all implementations of the MMU notifier in follow up patches. But such a code would be broken, no? Ignoring the blockable state will simply lead to lockups until the fixup parts get applied. Well to still be bisect-able you only need to get the interface change in first with fixing the function signature of the implementations. That would only work if those functions return -AGAIN unconditionally. Otherwise they would pretend to not block while that would be obviously incorrect. This doesn't sound correct to me. Then add all the new code to the implementations and last start to actually use the new interface. That is a pattern we use regularly and I think it's good practice to do this. But we do rely on the proper blockable handling. Yeah, but you could add the handling only after you have all the implementations in place. Don't you? Yeah, but then I would be adding a code with no user. And I really prefer to no do so because then the code is harder to argue about. Is the split up really worth it? I was thinking about that but had hard times to end up with something that would be bisectable. Well, except for returning -EBUSY until all notifiers are implemented. Which I found confusing. It at least makes reviewing changes much easier, cause as driver maintainer I can concentrate on the stuff only related to me. Additional to that when you cause some unrelated side effect in a driver we can much easier pinpoint the actual change later on when the patch is smaller. This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd changes. If you are worried to give r-b only for those then this can be done even for larger patches. Just make your Reviewd-by more specific R-b: name # For BLA BLA Yeah, possible alternative but more work for me when I review it :) I definitely do not want to add more work to reviewers and I completely see how massive "flag days" like these are not popular but I really didn't find a reasonable way around that would be both correct and wouldn't add much more churn on the way. So if you really insist then I would really appreciate a hint on the way to achive the same without any above downsides. Well, I don't insist on this. It's just from my point of view that this patch doesn't needs to be one patch, but could be split up. Well, if there are more people with the same concern I can try to do that. But if your only concern is to focus on your particular part then I guess it would be easier both for you and me to simply apply the patch and use git show $files_for_your_subystem on your end. I have put the patch to attempts/oom-vs-mmu-notifiers branch to my tree at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git Not wanting to block something as important as this, so feel free to add an Acked-by: Christian König to the patch. Let's rather face the next topic: Any idea how to runtime test this? I mean I can rather easily provide a test which crashes an AMD GPU, which in turn then would mean that the MMU notifier would block forever without this patch. But do you know a way to let the OOM killer kill a specific process? Regards, Christian. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon 02-07-18 14:24:29, Christian König wrote: > Am 02.07.2018 um 14:20 schrieb Michal Hocko: > > On Mon 02-07-18 14:13:42, Christian König wrote: > > > Am 02.07.2018 um 13:54 schrieb Michal Hocko: > > > > On Mon 02-07-18 11:14:58, Christian König wrote: > > > > > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > > > > > This is the v2 of RFC based on the feedback I've received so far. > > > > > > The > > > > > > code even compiles as a bonus ;) I haven't runtime tested it yet, > > > > > > mostly > > > > > > because I have no idea how. > > > > > > > > > > > > Any further feedback is highly appreciated of course. > > > > > That sounds like it should work and at least the amdgpu changes now > > > > > look > > > > > good to me on first glance. > > > > > > > > > > Can you split that up further in the usual way? E.g. adding the > > > > > blockable > > > > > flag in one patch and fixing all implementations of the MMU notifier > > > > > in > > > > > follow up patches. > > > > But such a code would be broken, no? Ignoring the blockable state will > > > > simply lead to lockups until the fixup parts get applied. > > > Well to still be bisect-able you only need to get the interface change in > > > first with fixing the function signature of the implementations. > > That would only work if those functions return -AGAIN unconditionally. > > Otherwise they would pretend to not block while that would be obviously > > incorrect. This doesn't sound correct to me. > > > > > Then add all the new code to the implementations and last start to > > > actually > > > use the new interface. > > > > > > That is a pattern we use regularly and I think it's good practice to do > > > this. > > But we do rely on the proper blockable handling. > > Yeah, but you could add the handling only after you have all the > implementations in place. Don't you? Yeah, but then I would be adding a code with no user. And I really prefer to no do so because then the code is harder to argue about. > > > > Is the split up really worth it? I was thinking about that but had hard > > > > times to end up with something that would be bisectable. Well, except > > > > for returning -EBUSY until all notifiers are implemented. Which I found > > > > confusing. > > > It at least makes reviewing changes much easier, cause as driver > > > maintainer > > > I can concentrate on the stuff only related to me. > > > > > > Additional to that when you cause some unrelated side effect in a driver > > > we > > > can much easier pinpoint the actual change later on when the patch is > > > smaller. > > > > > > > > This way I'm pretty sure Felix and I can give an rb on the > > > > > amdgpu/amdkfd > > > > > changes. > > > > If you are worried to give r-b only for those then this can be done even > > > > for larger patches. Just make your Reviewd-by more specific > > > > R-b: name # For BLA BLA > > > Yeah, possible alternative but more work for me when I review it :) > > I definitely do not want to add more work to reviewers and I completely > > see how massive "flag days" like these are not popular but I really > > didn't find a reasonable way around that would be both correct and > > wouldn't add much more churn on the way. So if you really insist then I > > would really appreciate a hint on the way to achive the same without any > > above downsides. > > Well, I don't insist on this. It's just from my point of view that this > patch doesn't needs to be one patch, but could be split up. Well, if there are more people with the same concern I can try to do that. But if your only concern is to focus on your particular part then I guess it would be easier both for you and me to simply apply the patch and use git show $files_for_your_subystem on your end. I have put the patch to attempts/oom-vs-mmu-notifiers branch to my tree at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active()
On 02/07/2018 12:44, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-07-02 12:34:51) @@ -1921,6 +1914,8 @@ void i915_vma_move_to_active(struct i915_vma *vma, if (flags & EXEC_OBJECT_NEEDS_FENCE) i915_gem_active_set(&vma->last_fence, rq); + + export_fence(vma, rq, flags); Don't care about new extra reservation object operations from the other i915_move_to_active_callers? No. Not filling the reservation_object is an underhand shortcut. It should never be not correct to track the fences for an object. Doing it in one place correctly, should prevent cheating. Fair enough. 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] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Am 02.07.2018 um 14:20 schrieb Michal Hocko: On Mon 02-07-18 14:13:42, Christian König wrote: Am 02.07.2018 um 13:54 schrieb Michal Hocko: On Mon 02-07-18 11:14:58, Christian König wrote: Am 27.06.2018 um 09:44 schrieb Michal Hocko: This is the v2 of RFC based on the feedback I've received so far. The code even compiles as a bonus ;) I haven't runtime tested it yet, mostly because I have no idea how. Any further feedback is highly appreciated of course. That sounds like it should work and at least the amdgpu changes now look good to me on first glance. Can you split that up further in the usual way? E.g. adding the blockable flag in one patch and fixing all implementations of the MMU notifier in follow up patches. But such a code would be broken, no? Ignoring the blockable state will simply lead to lockups until the fixup parts get applied. Well to still be bisect-able you only need to get the interface change in first with fixing the function signature of the implementations. That would only work if those functions return -AGAIN unconditionally. Otherwise they would pretend to not block while that would be obviously incorrect. This doesn't sound correct to me. Then add all the new code to the implementations and last start to actually use the new interface. That is a pattern we use regularly and I think it's good practice to do this. But we do rely on the proper blockable handling. Yeah, but you could add the handling only after you have all the implementations in place. Don't you? Is the split up really worth it? I was thinking about that but had hard times to end up with something that would be bisectable. Well, except for returning -EBUSY until all notifiers are implemented. Which I found confusing. It at least makes reviewing changes much easier, cause as driver maintainer I can concentrate on the stuff only related to me. Additional to that when you cause some unrelated side effect in a driver we can much easier pinpoint the actual change later on when the patch is smaller. This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd changes. If you are worried to give r-b only for those then this can be done even for larger patches. Just make your Reviewd-by more specific R-b: name # For BLA BLA Yeah, possible alternative but more work for me when I review it :) I definitely do not want to add more work to reviewers and I completely see how massive "flag days" like these are not popular but I really didn't find a reasonable way around that would be both correct and wouldn't add much more churn on the way. So if you really insist then I would really appreciate a hint on the way to achive the same without any above downsides. Well, I don't insist on this. It's just from my point of view that this patch doesn't needs to be one patch, but could be split up. Could be that I just don't know the code or the consequences of adding that well enough to really judge. Christian. ___ 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: Show who pinned the pages when a leak is hit (rev2)
== Series Details == Series: drm/i915: Show who pinned the pages when a leak is hit (rev2) URL : https://patchwork.freedesktop.org/series/45770/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4412 -> Patchwork_9495 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45770/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9495 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-skl-gvtdvm: PASS -> DMESG-WARN (fdo#106954) Possible fixes igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@prime_vgem@basic-fence-flip: fi-ilk-650: FAIL (fdo#104008) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106954 https://bugs.freedesktop.org/show_bug.cgi?id=106954 == Participating hosts (43 -> 39) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4412 -> Patchwork_9495 CI_DRM_4412: 3cd46a79b208e82ba0b2da4282e59312a79d29cc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9495: cd6455c5f8ad1d2336f31839edaa97525824b157 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cd6455c5f8ad drm/i915: Show who pinned the pages when a leak is hit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9495/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon 02-07-18 14:13:42, Christian König wrote: > Am 02.07.2018 um 13:54 schrieb Michal Hocko: > > On Mon 02-07-18 11:14:58, Christian König wrote: > > > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > > > This is the v2 of RFC based on the feedback I've received so far. The > > > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > > > because I have no idea how. > > > > > > > > Any further feedback is highly appreciated of course. > > > That sounds like it should work and at least the amdgpu changes now look > > > good to me on first glance. > > > > > > Can you split that up further in the usual way? E.g. adding the blockable > > > flag in one patch and fixing all implementations of the MMU notifier in > > > follow up patches. > > But such a code would be broken, no? Ignoring the blockable state will > > simply lead to lockups until the fixup parts get applied. > > Well to still be bisect-able you only need to get the interface change in > first with fixing the function signature of the implementations. That would only work if those functions return -AGAIN unconditionally. Otherwise they would pretend to not block while that would be obviously incorrect. This doesn't sound correct to me. > Then add all the new code to the implementations and last start to actually > use the new interface. > > That is a pattern we use regularly and I think it's good practice to do > this. But we do rely on the proper blockable handling. > > Is the split up really worth it? I was thinking about that but had hard > > times to end up with something that would be bisectable. Well, except > > for returning -EBUSY until all notifiers are implemented. Which I found > > confusing. > > It at least makes reviewing changes much easier, cause as driver maintainer > I can concentrate on the stuff only related to me. > > Additional to that when you cause some unrelated side effect in a driver we > can much easier pinpoint the actual change later on when the patch is > smaller. > > > > > > This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd > > > changes. > > If you are worried to give r-b only for those then this can be done even > > for larger patches. Just make your Reviewd-by more specific > > R-b: name # For BLA BLA > > Yeah, possible alternative but more work for me when I review it :) I definitely do not want to add more work to reviewers and I completely see how massive "flag days" like these are not popular but I really didn't find a reasonable way around that would be both correct and wouldn't add much more churn on the way. So if you really insist then I would really appreciate a hint on the way to achive the same without any above downsides. -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/10] drm/i915/crc: implement verify_crc_source callback
Op 02-07-18 om 13:07 schreef Mahesh Kumar: > This patch implements verify_crc_source callback function introduced > earlier in this series. > > Signed-off-by: Mahesh Kumar > Cc: dri-de...@lists.freedesktop.org > Reviewed-by: Maarten Lankhorst > --- Patch 6 and 7 were acked for inclusion through drm-misc by Jani: https://people.freedesktop.org/~cbrill/dri-log/?channel=intel-gfx&highlight_names=&date=2018-07-02 But we still need ack from the other maintainers to get this patch merged. :) Could you ping a few maintainers? ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
Am 02.07.2018 um 13:54 schrieb Michal Hocko: On Mon 02-07-18 11:14:58, Christian König wrote: Am 27.06.2018 um 09:44 schrieb Michal Hocko: This is the v2 of RFC based on the feedback I've received so far. The code even compiles as a bonus ;) I haven't runtime tested it yet, mostly because I have no idea how. Any further feedback is highly appreciated of course. That sounds like it should work and at least the amdgpu changes now look good to me on first glance. Can you split that up further in the usual way? E.g. adding the blockable flag in one patch and fixing all implementations of the MMU notifier in follow up patches. But such a code would be broken, no? Ignoring the blockable state will simply lead to lockups until the fixup parts get applied. Well to still be bisect-able you only need to get the interface change in first with fixing the function signature of the implementations. Then add all the new code to the implementations and last start to actually use the new interface. That is a pattern we use regularly and I think it's good practice to do this. Is the split up really worth it? I was thinking about that but had hard times to end up with something that would be bisectable. Well, except for returning -EBUSY until all notifiers are implemented. Which I found confusing. It at least makes reviewing changes much easier, cause as driver maintainer I can concentrate on the stuff only related to me. Additional to that when you cause some unrelated side effect in a driver we can much easier pinpoint the actual change later on when the patch is smaller. This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd changes. If you are worried to give r-b only for those then this can be done even for larger patches. Just make your Reviewd-by more specific R-b: name # For BLA BLA Yeah, possible alternative but more work for me when I review it :) Regards, Christian. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Show who pinned the pages when a leak is hit (rev2)
== Series Details == Series: drm/i915: Show who pinned the pages when a leak is hit (rev2) URL : https://patchwork.freedesktop.org/series/45770/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Show who pinned the pages when a leak is hit -drivers/gpu/drm/i915/selftests/../i915_drv.h:3664:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3666: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] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Show who pinned the pages when a leak is hit (rev2)
== Series Details == Series: drm/i915: Show who pinned the pages when a leak is hit (rev2) URL : https://patchwork.freedesktop.org/series/45770/ State : warning == Summary == $ dim checkpatch origin/drm-tip cd6455c5f8ad drm/i915: Show who pinned the pages when a leak is hit -:207: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #207: FILE: drivers/gpu/drm/i915/i915_gem_object.h:253: + spinlock_t debug_lock; total: 0 errors, 0 warnings, 1 checks, 200 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 01/17] lib: Report file cache as available system memory
Quoting Tvrtko Ursulin (2018-07-02 12:54:18) > > On 02/07/2018 10:07, Chris Wilson wrote: > > sysinfo() doesn't include all reclaimable memory. In particular it > > excludes the majority of global_node_page_state(NR_FILE_PAGES), > > reclaimable pages that are a copy of on-disk files It seems the only way > > to obtain this counter is by parsing /proc/meminfo. For comparison, > > check vm_enough_memory() which includes NR_FILE_PAGES as available > > (sadly there's no way to call vm_enough_memory() directly either!) > > > > v2: Pay attention to what one writes. > > > > Signed-off-by: Chris Wilson > > --- > > lib/intel_os.c | 36 +++- > > 1 file changed, 31 insertions(+), 5 deletions(-) > > > > diff --git a/lib/intel_os.c b/lib/intel_os.c > > index 885ffdcec..5bd18fc52 100644 > > --- a/lib/intel_os.c > > +++ b/lib/intel_os.c > > @@ -84,6 +84,18 @@ intel_get_total_ram_mb(void) > > return retval / (1024*1024); > > } > > > > +static uint64_t get_meminfo(const char *info, const char *tag) > > +{ > > + const char *str; > > + unsigned long val; > > + > > + str = strstr(info, tag); > > + if (str && sscanf(str + strlen(tag), " %lu", &val) == 1) > > + return (uint64_t)val << 10; > > + > > + return 0; > > Might be safer to assert format was as expected and keywords we expect > are there, rather than silently return zero. Definitely prefer not to assert here if we can help it. igt_warn should be obvious enough to catch change in tags, but not if the information changes. > > +} > > + > > /** > >* intel_get_avail_ram_mb: > >* > > @@ -96,17 +108,31 @@ intel_get_avail_ram_mb(void) > > uint64_t retval; > > > > #ifdef HAVE_STRUCT_SYSINFO_TOTALRAM /* Linux */ > > - struct sysinfo sysinf; > > + char *info; > > int fd; > > > > fd = drm_open_driver(DRIVER_INTEL); > > intel_purge_vm_caches(fd); > > close(fd); > > > > - igt_assert(sysinfo(&sysinf) == 0); > > - retval = sysinf.freeram; > > - retval += min(sysinf.freeswap, sysinf.bufferram); > > - retval *= sysinf.mem_unit; > > + fd = open("/proc", O_RDONLY); > > + info = igt_sysfs_get(fd, "meminfo"); > > + close(fd); > > + > > + if (info) { > > + retval = get_meminfo(info, "MemAvailable: "); > > + retval += get_meminfo(info, "Buffers: "); > > + retval += get_meminfo(info, "Cached: "); > > + retval += get_meminfo(info, "SwapCached: "); > > I think it would be more robust to have no trailing space in tag strings. There was a reason iirc, but I think it was just for debug convenience. > > + free(info); > > + } else { > > + struct sysinfo sysinf; > > + > > + igt_assert(sysinfo(&sysinf) == 0); > > + retval = sysinf.freeram; > > + retval += min(sysinf.freeswap, sysinf.bufferram); > > + retval *= sysinf.mem_unit; > > + } > > Not sure it is worth keeping this path - will we ever not have > /proc/meminfo? I expect someone will eventually deem it to be too dangerous information and remove it. I felt since we had the code here, we might as well try. Technically /proc doesn't have to be mounted. :| > > #elif defined(_SC_PAGESIZE) && defined(_SC_AVPHYS_PAGES) /* Solaris */ > > long pagesize, npages; > > > > > > Google agrees with you that sysinfo indeed has this limitation. So in > general no complaints. > > One tiny detail might be that this would now return a too large value - > doesn't count that it should not swap out itself when thinking about > free memory. But I don't think that is for this level of API to concern > with - it is definitely way more correct to report page cache. The question we ask is whether or not the test itself will be swapped out; I don't mind if we swap others out in order to run the test. We do after all try and purge memory to make it all available to ourselves, and part of that was in the belief that it would make the filecache available to us. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 03/17] igt/gem_set_tiling_vs_pwrite: Show the erroneous value
On 02/07/2018 10:07, Chris Wilson wrote: Signed-off-by: Chris Wilson --- tests/gem_set_tiling_vs_pwrite.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/gem_set_tiling_vs_pwrite.c b/tests/gem_set_tiling_vs_pwrite.c index 006edfe4e..f0126b648 100644 --- a/tests/gem_set_tiling_vs_pwrite.c +++ b/tests/gem_set_tiling_vs_pwrite.c @@ -75,7 +75,7 @@ igt_simple_main memset(data, 0, OBJECT_SIZE); gem_read(fd, handle, 0, data, OBJECT_SIZE); for (i = 0; i < OBJECT_SIZE/4; i++) - igt_assert(i == data[i]); + igt_assert_eq_u32(data[i], i); /* touch it before changing the tiling, so that the fence sticks around */ gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT); @@ -88,7 +88,7 @@ igt_simple_main memset(data, 0, OBJECT_SIZE); gem_read(fd, handle, 0, data, OBJECT_SIZE); for (i = 0; i < OBJECT_SIZE/4; i++) - igt_assert(i == data[i]); + igt_assert_eq_u32(data[i], i); munmap(ptr, OBJECT_SIZE); 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] [igt-dev] [PATCH i-g-t 02/17] igt/gem_tiled_partial_pwrite_pread: Check for known swizzling
On 02/07/2018 10:07, Chris Wilson wrote: As we want to compare a templated tiling pattern against the target_bo, we need to know that the swizzling is compatible. Or else the two tiling pattern may differ due to underlying page address that we cannot know, and so the test may sporadically fail. References: https://bugs.freedesktop.org/show_bug.cgi?id=102575 Signed-off-by: Chris Wilson --- tests/gem_tiled_partial_pwrite_pread.c | 24 1 file changed, 24 insertions(+) diff --git a/tests/gem_tiled_partial_pwrite_pread.c b/tests/gem_tiled_partial_pwrite_pread.c index fe573c37c..83c57c07d 100644 --- a/tests/gem_tiled_partial_pwrite_pread.c +++ b/tests/gem_tiled_partial_pwrite_pread.c @@ -249,6 +249,24 @@ static void test_partial_read_writes(void) } } +static bool known_swizzling(uint32_t handle) +{ + struct drm_i915_gem_get_tiling2 { + uint32_t handle; + uint32_t tiling_mode; + uint32_t swizzle_mode; + uint32_t phys_swizzle_mode; + } arg = { + .handle = handle, + }; +#define DRM_IOCTL_I915_GEM_GET_TILING2 DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_GET_TILING, struct Can't we rely on this being in system headers by now? drm_i915_gem_get_tiling2) + + if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_GET_TILING2, &arg)) + return false; + + return arg.phys_swizzle_mode == arg.swizzle_mode; +} + igt_main { uint32_t tiling_mode = I915_TILING_X; @@ -271,6 +289,12 @@ igt_main &tiling_mode, &scratch_pitch, 0); igt_assert(tiling_mode == I915_TILING_X); igt_assert(scratch_pitch == 4096); + + /* +* As we want to compare our template tiled pattern against +* the target bo, we need consistent swizzling on both. +*/ + igt_require(known_swizzling(scratch_bo->handle)); staging_bo = drm_intel_bo_alloc(bufmgr, "staging bo", BO_SIZE, 4096); tiled_staging_bo = drm_intel_bo_alloc_tiled(bufmgr, "scratch bo", 1024, BO_SIZE/4096, 4, Another option could be to keep allocating until we found one in the memory area with compatible swizzling? Like this it may be some noise in the test pass<->skip transitions. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Show who pinned the pages when a leak is hit
Currently, we emit a warning when freeing an object if we do so with the pages still pinned (presumably as they are still in use somewhere). This only tells us that there is a problem, but doesn't tell us anything about the object or who might be pinning them and so provides no clue as to track down the problem. Let's try tracking everyone who pins the pages to see if we strike it lucky and catch the culprit red handed. References: https://bugs.freedesktop.org/show_bug.cgi?id=105360 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 1 + drivers/gpu/drm/i915/i915_drv.h| 2 + drivers/gpu/drm/i915/i915_gem.c| 5 +- drivers/gpu/drm/i915/i915_gem_object.c | 109 + drivers/gpu/drm/i915/i915_gem_object.h | 34 5 files changed, 150 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 9de8b1c51a5c..84052becb279 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -43,6 +43,7 @@ config DRM_I915_DEBUG_GEM bool "Insert extra checks into the GEM internals" default n depends on DRM_I915_WERROR +select STACKDEPOT help Enable extra sanity checks (including BUGs) along the GEM driver paths that may slow the system down and if hit hang the machine. diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2cefe4c30f88..cc334a0fc91d 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2990,6 +2990,8 @@ i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) { might_lock(&obj->mm.lock); + track_i915_gem_object_pin_pages(obj); + if (atomic_inc_not_zero(&obj->mm.pages_pin_count)) return 0; diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 8954db6ab083..e56240dc93f3 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2459,6 +2459,7 @@ void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj, if (!IS_ERR(pages)) obj->ops->put_pages(obj, pages); + untrack_i915_gem_object_pin_pages(obj); unlock: mutex_unlock(&obj->mm.lock); } @@ -4870,8 +4871,10 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915, if (obj->ops->release) obj->ops->release(obj); - if (WARN_ON(i915_gem_object_has_pinned_pages(obj))) + if (WARN_ON(i915_gem_object_has_pinned_pages(obj))) { + show_i915_gem_object_pin_pages(obj); atomic_set(&obj->mm.pages_pin_count, 0); + } __i915_gem_object_put_pages(obj, I915_MM_NORMAL); GEM_BUG_ON(i915_gem_object_has_pages(obj)); diff --git a/drivers/gpu/drm/i915/i915_gem_object.c b/drivers/gpu/drm/i915/i915_gem_object.c index aab8cdd80e6d..bad7fac72bdd 100644 --- a/drivers/gpu/drm/i915/i915_gem_object.c +++ b/drivers/gpu/drm/i915/i915_gem_object.c @@ -25,6 +25,115 @@ #include "i915_drv.h" #include "i915_gem_object.h" +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) + +#include + +#define STACKDEPTH 12 + +void track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) +{ + unsigned long entries[STACKDEPTH]; + struct stack_trace trace = { + .entries = entries, + .max_entries = ARRAY_SIZE(entries), + .skip = 1 + }; + unsigned long flags; + depot_stack_handle_t stack, *stacks; + + save_stack_trace(&trace); + if (trace.nr_entries && + trace.entries[trace.nr_entries - 1] == ULONG_MAX) + trace.nr_entries--; + + stack = depot_save_stack(&trace, GFP_KERNEL); + if (!stack) + return; + + spin_lock_irqsave(&obj->mm.debug_lock, flags); + stacks = krealloc(obj->mm.debug_owners, + (obj->mm.debug_count + 1) * sizeof(*stacks), + GFP_NOWAIT); + if (stacks) { + stacks[obj->mm.debug_count++] = stack; + obj->mm.debug_owners = stacks; + } + spin_unlock_irqrestore(&obj->mm.debug_lock, flags); +} + +void untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) +{ + depot_stack_handle_t *stacks; + unsigned long flags; + + spin_lock_irqsave(&obj->mm.debug_lock, flags); + stacks = fetch_and_zero(&obj->mm.debug_owners); + obj->mm.debug_count = 0; + spin_unlock_irqrestore(&obj->mm.debug_lock, flags); + + kfree(stacks); +} + +static int cmphandle(const void *_a, const void *_b) +{ + const depot_stack_handle_t * const a = _a, * const b = _b; + + if (*a < *b) + return -1; + else if (*a > *b) + return 1; + else + return 0; +} + +void show_i915_gem_object_p
Re: [Intel-gfx] [PATCH] drm/i915: Show who pinned the pages when a leak is hit
Quoting Chris Wilson (2018-07-02 12:44:52) > @@ -451,6 +460,31 @@ i915_gem_object_get_tile_row_size(struct > drm_i915_gem_object *obj) > int i915_gem_object_set_tiling(struct drm_i915_gem_object *obj, >unsigned int tiling, unsigned int stride); > > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) > + > +void track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj); > +void untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj); > +void show_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj); > + > +#else > + > +static inline void > +track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) > +{ > +} > + > +static inline void > +untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) > +{ > +} > + > +static inline void > +show_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) > +{ > +} > + > +#endif Grr, didn't notice in the rebase that i915_gem_object_pin_pages was no longer here. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 01/17] lib: Report file cache as available system memory
On 02/07/2018 10:07, Chris Wilson wrote: sysinfo() doesn't include all reclaimable memory. In particular it excludes the majority of global_node_page_state(NR_FILE_PAGES), reclaimable pages that are a copy of on-disk files It seems the only way to obtain this counter is by parsing /proc/meminfo. For comparison, check vm_enough_memory() which includes NR_FILE_PAGES as available (sadly there's no way to call vm_enough_memory() directly either!) v2: Pay attention to what one writes. Signed-off-by: Chris Wilson --- lib/intel_os.c | 36 +++- 1 file changed, 31 insertions(+), 5 deletions(-) diff --git a/lib/intel_os.c b/lib/intel_os.c index 885ffdcec..5bd18fc52 100644 --- a/lib/intel_os.c +++ b/lib/intel_os.c @@ -84,6 +84,18 @@ intel_get_total_ram_mb(void) return retval / (1024*1024); } +static uint64_t get_meminfo(const char *info, const char *tag) +{ + const char *str; + unsigned long val; + + str = strstr(info, tag); + if (str && sscanf(str + strlen(tag), " %lu", &val) == 1) + return (uint64_t)val << 10; + + return 0; Might be safer to assert format was as expected and keywords we expect are there, rather than silently return zero. +} + /** * intel_get_avail_ram_mb: * @@ -96,17 +108,31 @@ intel_get_avail_ram_mb(void) uint64_t retval; #ifdef HAVE_STRUCT_SYSINFO_TOTALRAM /* Linux */ - struct sysinfo sysinf; + char *info; int fd; fd = drm_open_driver(DRIVER_INTEL); intel_purge_vm_caches(fd); close(fd); - igt_assert(sysinfo(&sysinf) == 0); - retval = sysinf.freeram; - retval += min(sysinf.freeswap, sysinf.bufferram); - retval *= sysinf.mem_unit; + fd = open("/proc", O_RDONLY); + info = igt_sysfs_get(fd, "meminfo"); + close(fd); + + if (info) { + retval = get_meminfo(info, "MemAvailable: "); + retval += get_meminfo(info, "Buffers: "); + retval += get_meminfo(info, "Cached: "); + retval += get_meminfo(info, "SwapCached: "); I think it would be more robust to have no trailing space in tag strings. + free(info); + } else { + struct sysinfo sysinf; + + igt_assert(sysinfo(&sysinf) == 0); + retval = sysinf.freeram; + retval += min(sysinf.freeswap, sysinf.bufferram); + retval *= sysinf.mem_unit; + } Not sure it is worth keeping this path - will we ever not have /proc/meminfo? #elif defined(_SC_PAGESIZE) && defined(_SC_AVPHYS_PAGES) /* Solaris */ long pagesize, npages; Google agrees with you that sysinfo indeed has this limitation. So in general no complaints. One tiny detail might be that this would now return a too large value - doesn't count that it should not swap out itself when thinking about free memory. But I don't think that is for this level of API to concern with - it is definitely way more correct to report page cache. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers
On Mon 02-07-18 11:14:58, Christian König wrote: > Am 27.06.2018 um 09:44 schrieb Michal Hocko: > > This is the v2 of RFC based on the feedback I've received so far. The > > code even compiles as a bonus ;) I haven't runtime tested it yet, mostly > > because I have no idea how. > > > > Any further feedback is highly appreciated of course. > > That sounds like it should work and at least the amdgpu changes now look > good to me on first glance. > > Can you split that up further in the usual way? E.g. adding the blockable > flag in one patch and fixing all implementations of the MMU notifier in > follow up patches. But such a code would be broken, no? Ignoring the blockable state will simply lead to lockups until the fixup parts get applied. Is the split up really worth it? I was thinking about that but had hard times to end up with something that would be bisectable. Well, except for returning -EBUSY until all notifiers are implemented. Which I found confusing. > This way I'm pretty sure Felix and I can give an rb on the amdgpu/amdkfd > changes. If you are worried to give r-b only for those then this can be done even for larger patches. Just make your Reviewd-by more specific R-b: name # For BLA BLA -- Michal Hocko SUSE Labs ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Improve crc-core driver interface (rev4)
== Series Details == Series: Improve crc-core driver interface (rev4) URL : https://patchwork.freedesktop.org/series/45246/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4411 -> Patchwork_9494 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9494 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9494, 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/45246/revisions/4/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9494: === IGT changes === Possible regressions igt@gem_exec_suspend@basic-s3: {fi-cfl-8109u}: PASS -> DMESG-WARN igt@kms_pipe_crc_basic@bad-source: {fi-cfl-8109u}: PASS -> FAIL +1 fi-skl-6770hq: PASS -> FAIL +6 fi-bwr-2160:PASS -> FAIL +4 fi-hsw-4770r: PASS -> FAIL +6 fi-glk-j4005: PASS -> FAIL fi-cfl-8700k: PASS -> FAIL +6 {fi-kbl-x1275}: PASS -> FAIL fi-kbl-guc: PASS -> FAIL fi-glk-dsi: PASS -> FAIL fi-bsw-n3050: PASS -> FAIL igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-ivb-3520m: PASS -> FAIL +6 fi-cfl-s3: PASS -> FAIL +6 fi-skl-6700hq: PASS -> FAIL +6 fi-skl-guc: PASS -> FAIL +6 fi-blb-e6850: PASS -> FAIL +4 igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence: fi-ilk-650: PASS -> FAIL +4 fi-elk-e7500: PASS -> FAIL +4 fi-byt-n2820: PASS -> FAIL +4 fi-snb-2520m: PASS -> FAIL +4 igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b: fi-bdw-5557u: PASS -> FAIL +6 fi-pnv-d510:PASS -> FAIL +4 fi-skl-6600u: PASS -> FAIL +6 fi-bxt-dsi: PASS -> FAIL +6 fi-hsw-4770:PASS -> FAIL +6 fi-cfl-guc: PASS -> FAIL +6 fi-ivb-3770:PASS -> FAIL +6 igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: fi-hsw-peppy: PASS -> FAIL +6 fi-bdw-gvtdvm: PASS -> FAIL +6 fi-gdg-551: PASS -> FAIL +4 fi-kbl-7500u: PASS -> FAIL +6 fi-snb-2600:PASS -> FAIL +4 igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: fi-kbl-7567u: PASS -> FAIL +6 fi-skl-6260u: PASS -> FAIL +6 fi-skl-6700k2: PASS -> FAIL +6 fi-skl-gvtdvm: PASS -> FAIL +6 fi-bxt-j4205: PASS -> FAIL +6 fi-kbl-7560u: PASS -> FAIL +6 fi-whl-u: PASS -> FAIL +6 fi-kbl-r: PASS -> FAIL +6 Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9494 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c: fi-glk-j4005: PASS -> FAIL (fdo#106211) +5 fi-bsw-n3050: PASS -> FAIL (fdo#106211) +1 igt@kms_pipe_crc_basic@nonblocking-crc-pipe-c-frame-sequence: fi-glk-dsi: PASS -> FAIL (fdo#106211) +5 {name}: This element is suppressed. This means it is ignored when computing the status of the difference (SUCCESS, WARNING, or FAILURE). fdo#106211 https://bugs.freedesktop.org/show_bug.cgi?id=106211 == Participating hosts (44 -> 39) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4411 -> Patchwork_9494 CI_DRM_4411: 3fd8031a8f5d378ebda63131f6b504c3c4a5eb93 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4532: 840d12e2f050b784552197403d6575a57b6e896d @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9494: 43533286914804b8dd5bc3d683945a5bce9be6e6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 435332869148 drm: crc: Introduce pre_crc_read function 39240b6ce9c5 Revert "drm: crc: Wait for a frame before returning from open()" 92d712d5c8bf drm/crc: Cleanup crtc_crc_open function f1a6ac764e69 drm/i915/crc: implement get_crc_sources callback 29e0bbaabf60 drm/i915/crc: implement verify_crc_source callback c75c0d05c696 drm/rcar-du/crc: Implement verify_crc_source callback 649d027b2b34 drm/amdgpu_dm/crc: Implement verify_crc_source callback 8993123ebcb1 drm/rockchip/crc: Implement verify_crc_source callback d5dac505c466 drm: crc: Introduce get_crc_sources callback 2fe8786784e0 drm: crc: Introduce verify_crc_source callback == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9494/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://
[Intel-gfx] [PATCH] drm/i915: Show who pinned the pages when a leak is hit
Currently, we emit a warning when freeing an object if we do so with the pages still pinned (presumably as they are still in use somewhere). This only tells us that there is a problem, but doesn't tell us anything about the object or who might be pinning them and so provides no clue as to track down the problem. Let's try tracking everyone who pins the pages to see if we strike it lucky and catch the culprit red handed. References: https://bugs.freedesktop.org/show_bug.cgi?id=105360 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 1 + drivers/gpu/drm/i915/i915_gem.c| 5 +- drivers/gpu/drm/i915/i915_gem_object.c | 109 + drivers/gpu/drm/i915/i915_gem_object.h | 34 4 files changed, 148 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 9de8b1c51a5c..84052becb279 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -43,6 +43,7 @@ config DRM_I915_DEBUG_GEM bool "Insert extra checks into the GEM internals" default n depends on DRM_I915_WERROR +select STACKDEPOT help Enable extra sanity checks (including BUGs) along the GEM driver paths that may slow the system down and if hit hang the machine. diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 8954db6ab083..e56240dc93f3 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2459,6 +2459,7 @@ void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj, if (!IS_ERR(pages)) obj->ops->put_pages(obj, pages); + untrack_i915_gem_object_pin_pages(obj); unlock: mutex_unlock(&obj->mm.lock); } @@ -4870,8 +4871,10 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915, if (obj->ops->release) obj->ops->release(obj); - if (WARN_ON(i915_gem_object_has_pinned_pages(obj))) + if (WARN_ON(i915_gem_object_has_pinned_pages(obj))) { + show_i915_gem_object_pin_pages(obj); atomic_set(&obj->mm.pages_pin_count, 0); + } __i915_gem_object_put_pages(obj, I915_MM_NORMAL); GEM_BUG_ON(i915_gem_object_has_pages(obj)); diff --git a/drivers/gpu/drm/i915/i915_gem_object.c b/drivers/gpu/drm/i915/i915_gem_object.c index aab8cdd80e6d..e1f60e4e17ce 100644 --- a/drivers/gpu/drm/i915/i915_gem_object.c +++ b/drivers/gpu/drm/i915/i915_gem_object.c @@ -25,6 +25,115 @@ #include "i915_drv.h" #include "i915_gem_object.h" +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM) + +#include + +#define STACKDEPTH 12 + +void track_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) +{ + unsigned long entries[STACKDEPTH]; + struct stack_trace trace = { + .entries = entries, + .max_entries = ARRAY_SIZE(entries), + .skip = 1 + }; + unsigned long flags; + depot_stack_handle_t stack, *stacks; + + save_stack_trace(&trace); + if (trace.nr_entries && + trace.entries[trace.nr_entries - 1] == ULONG_MAX) + trace.nr_entries--; + + stack = depot_save_stack(&trace, GFP_NOWAIT); + if (!stack) + return; + + spin_lock_irqsave(&obj->mm.debug_lock, flags); + stacks = krealloc(obj->mm.debug_owners, + (obj->mm.debug_count + 1) * sizeof(*stacks), + GFP_NOWAIT); + if (stacks) { + stacks[obj->mm.debug_count++] = stack; + obj->mm.debug_owners = stacks; + } + spin_unlock_irqrestore(&obj->mm.debug_lock, flags); +} + +void untrack_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) +{ + depot_stack_handle_t *stacks; + unsigned long flags; + + spin_lock_irqsave(&obj->mm.debug_lock, flags); + stacks = fetch_and_zero(&obj->mm.debug_owners); + obj->mm.debug_count = 0; + spin_unlock_irqrestore(&obj->mm.debug_lock, flags); + + kfree(stacks); +} + +static int cmphandle(const void *_a, const void *_b) +{ + const depot_stack_handle_t * const a = _a, * const b = _b; + + if (*a < *b) + return -1; + else if (*a > *b) + return 1; + else + return 0; +} + +void show_i915_gem_object_pin_pages(struct drm_i915_gem_object *obj) +{ + unsigned long entries[STACKDEPTH]; + depot_stack_handle_t *stacks; + unsigned long flags, count, i; + char *buf; + + spin_lock_irqsave(&obj->mm.debug_lock, flags); + stacks = fetch_and_zero(&obj->mm.debug_owners); + count = fetch_and_zero(&obj->mm.debug_count); + spin_unlock_irqrestore(&obj->mm.debug_lock, flags); + if (!count) + return; + + DRM_DEBUG_DRIVER("obj %p leaked pa
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active()
Quoting Tvrtko Ursulin (2018-07-02 12:34:51) > > @@ -1921,6 +1914,8 @@ void i915_vma_move_to_active(struct i915_vma *vma, > > > > if (flags & EXEC_OBJECT_NEEDS_FENCE) > > i915_gem_active_set(&vma->last_fence, rq); > > + > > + export_fence(vma, rq, flags); > > Don't care about new extra reservation object operations from the other > i915_move_to_active_callers? No. Not filling the reservation_object is an underhand shortcut. It should never be not correct to track the fences for an object. Doing it in one place correctly, should prevent cheating. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Move i915_vma_move_to_active() to i915_vma.c
On 29/06/2018 23:54, Chris Wilson wrote: i915_vma_move_to_active() has grown beyond its execbuf origins, and should take its rightful place in i915_vma.c as a method for i915_vma! Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h| 3 -- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 61 -- drivers/gpu/drm/i915/i915_vma.c| 61 ++ drivers/gpu/drm/i915/i915_vma.h| 4 ++ 4 files changed, 65 insertions(+), 64 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index cd8f69a00e86..1c04872890d4 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3099,9 +3099,6 @@ i915_gem_obj_finish_shmem_access(struct drm_i915_gem_object *obj) } int __must_check i915_mutex_lock_interruptible(struct drm_device *dev); -int __must_check i915_vma_move_to_active(struct i915_vma *vma, -struct i915_request *rq, -unsigned int flags); int i915_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev, struct drm_mode_create_dumb *args); diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 97136e4ce91d..3f0c612d42e7 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1868,67 +1868,6 @@ static bool i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec) return true; } -static void export_fence(struct i915_vma *vma, -struct i915_request *rq, -unsigned int flags) -{ - struct reservation_object *resv = vma->resv; - - /* -* Ignore errors from failing to allocate the new fence, we can't -* handle an error right now. Worst case should be missed -* synchronisation leading to rendering corruption. -*/ - reservation_object_lock(resv, NULL); - if (flags & EXEC_OBJECT_WRITE) - reservation_object_add_excl_fence(resv, &rq->fence); - else if (reservation_object_reserve_shared(resv) == 0) - reservation_object_add_shared_fence(resv, &rq->fence); - reservation_object_unlock(resv); -} - -int i915_vma_move_to_active(struct i915_vma *vma, - struct i915_request *rq, - unsigned int flags) -{ - struct drm_i915_gem_object *obj = vma->obj; - const unsigned int idx = rq->engine->id; - - lockdep_assert_held(&rq->i915->drm.struct_mutex); - GEM_BUG_ON(!drm_mm_node_allocated(&vma->node)); - - /* -* Add a reference if we're newly entering the active list. -* The order in which we add operations to the retirement queue is -* vital here: mark_active adds to the start of the callback list, -* such that subsequent callbacks are called first. Therefore we -* add the active reference first and queue for it to be dropped -* *last*. -*/ - if (!i915_vma_is_active(vma)) - obj->active_count++; - i915_vma_set_active(vma, idx); - i915_gem_active_set(&vma->last_read[idx], rq); - list_move_tail(&vma->vm_link, &vma->vm->active_list); - - obj->write_domain = 0; - if (flags & EXEC_OBJECT_WRITE) { - obj->write_domain = I915_GEM_DOMAIN_RENDER; - - if (intel_fb_obj_invalidate(obj, ORIGIN_CS)) - i915_gem_active_set(&obj->frontbuffer_write, rq); - - obj->read_domains = 0; - } - obj->read_domains |= I915_GEM_GPU_DOMAINS; - - if (flags & EXEC_OBJECT_NEEDS_FENCE) - i915_gem_active_set(&vma->last_fence, rq); - - export_fence(vma, rq, flags); - return 0; -} - static int i915_reset_gen7_sol_offsets(struct i915_request *rq) { u32 *cs; diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index d0e606e9b27a..7635c27e7e8b 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -859,6 +859,67 @@ void i915_vma_revoke_mmap(struct i915_vma *vma) list_del(&vma->obj->userfault_link); } +static void export_fence(struct i915_vma *vma, +struct i915_request *rq, +unsigned int flags) +{ + struct reservation_object *resv = vma->resv; + + /* +* Ignore errors from failing to allocate the new fence, we can't +* handle an error right now. Worst case should be missed +* synchronisation leading to rendering corruption. +*/ + reservation_object_lock(resv, NULL); + if (flags & EXEC_OBJECT_WRITE) + reservation_object_add_excl_fence(resv, &rq->fence); + else if (reservation_object_reserve_shared(resv) == 0) + reser
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Start returning an error from i915_vma_move_to_active()
On 29/06/2018 23:54, Chris Wilson wrote: Handling such a late error in request construction is tricky, but to accommodate future patches which may allocate here, we potentially could err. To handle the error after already adjusting global state to track the new request, we must finish and submit the request. But we don't want to use the request as not everything is being tracked by it, so we opt to cancel the commands inside the request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/scheduler.c | 6 - drivers/gpu/drm/i915/i915_drv.h | 6 ++--- drivers/gpu/drm/i915/i915_gem_execbuffer.c| 25 +-- drivers/gpu/drm/i915/i915_gem_render_state.c | 2 +- drivers/gpu/drm/i915/selftests/huge_pages.c | 9 +-- .../drm/i915/selftests/i915_gem_coherency.c | 4 +-- .../gpu/drm/i915/selftests/i915_gem_context.c | 12 +++-- .../gpu/drm/i915/selftests/i915_gem_object.c | 7 +++--- drivers/gpu/drm/i915/selftests/i915_request.c | 8 -- .../gpu/drm/i915/selftests/intel_hangcheck.c | 11 ++-- drivers/gpu/drm/i915/selftests/intel_lrc.c| 11 ++-- .../drm/i915/selftests/intel_workarounds.c| 5 +++- 12 files changed, 78 insertions(+), 28 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c index 928818f218f7..b0e566956b8d 100644 --- a/drivers/gpu/drm/i915/gvt/scheduler.c +++ b/drivers/gpu/drm/i915/gvt/scheduler.c @@ -476,7 +476,11 @@ static int prepare_shadow_batch_buffer(struct intel_vgpu_workload *workload) i915_gem_obj_finish_shmem_access(bb->obj); bb->accessing = false; - i915_vma_move_to_active(bb->vma, workload->req, 0); + ret = i915_vma_move_to_active(bb->vma, + workload->req, + 0); + if (ret) + goto err; } } return 0; diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index ce7d06332884..cd8f69a00e86 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3099,9 +3099,9 @@ i915_gem_obj_finish_shmem_access(struct drm_i915_gem_object *obj) } int __must_check i915_mutex_lock_interruptible(struct drm_device *dev); -void i915_vma_move_to_active(struct i915_vma *vma, -struct i915_request *rq, -unsigned int flags); +int __must_check i915_vma_move_to_active(struct i915_vma *vma, +struct i915_request *rq, +unsigned int flags); int i915_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev, struct drm_mode_create_dumb *args); diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 91f20445147f..97136e4ce91d 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1165,12 +1165,16 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb, goto err_request; GEM_BUG_ON(!reservation_object_test_signaled_rcu(batch->resv, true)); - i915_vma_move_to_active(batch, rq, 0); - i915_vma_unpin(batch); + err = i915_vma_move_to_active(batch, rq, 0); + if (err) + goto skip_request; - i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE); + err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE); + if (err) + goto skip_request; rq->batch = batch; + i915_vma_unpin(batch); cache->rq = rq; cache->rq_cmd = cmd; @@ -1179,6 +1183,8 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb, /* Return with batch mapping (cmd) still pinned */ return 0; +skip_request: + i915_request_skip(rq, err); err_request: i915_request_add(rq); err_unpin: @@ -1818,7 +1824,11 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb) unsigned int flags = eb->flags[i]; struct i915_vma *vma = eb->vma[i]; - i915_vma_move_to_active(vma, eb->request, flags); + err = i915_vma_move_to_active(vma, eb->request, flags); + if (unlikely(err)) { + i915_request_skip(eb->request, err); + return err; + } __eb_unreserve_vma(vma, flags); vma->exec_flags = NULL; @@ -1877,9 +1887,9 @@ static void export_fence(struct i915_vma *vma, reservation_object_unlock(resv); } -void i915_vma_move_to_active(struct i915_vma *vma, -struct i915_request *rq, -unsigned int flags) +int i915_vma_move_to_active(struct i915_vma *vma, +
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Export i915_request_skip()
On 29/06/2018 23:54, Chris Wilson wrote: In the next patch, we will want to start skipping requests on failing to complete their payloads. So export the utility function current used to make requests inoperable following a failed gpu reset. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 25 +++-- drivers/gpu/drm/i915/i915_request.c | 21 + drivers/gpu/drm/i915/i915_request.h | 2 ++ 3 files changed, 26 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 8954db6ab083..2ff6251483ce 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3074,25 +3074,6 @@ int i915_gem_reset_prepare(struct drm_i915_private *dev_priv) return err; } -static void skip_request(struct i915_request *request) -{ - void *vaddr = request->ring->vaddr; - u32 head; - - /* As this request likely depends on state from the lost -* context, clear out all the user operations leaving the -* breadcrumb at the end (so we get the fence notifications). -*/ - head = request->head; - if (request->postfix < head) { - memset(vaddr + head, 0, request->ring->size - head); - head = 0; - } - memset(vaddr + head, 0, request->postfix - head); - - dma_fence_set_error(&request->fence, -EIO); -} - static void engine_skip_context(struct i915_request *request) { struct intel_engine_cs *engine = request->engine; @@ -3107,10 +3088,10 @@ static void engine_skip_context(struct i915_request *request) list_for_each_entry_continue(request, &engine->timeline.requests, link) if (request->gem_context == hung_ctx) - skip_request(request); + i915_request_skip(request, -EIO); list_for_each_entry(request, &timeline->requests, link) - skip_request(request); + i915_request_skip(request, -EIO); spin_unlock(&timeline->lock); spin_unlock_irqrestore(&engine->timeline.lock, flags); @@ -3153,7 +3134,7 @@ i915_gem_reset_request(struct intel_engine_cs *engine, if (stalled) { i915_gem_context_mark_guilty(request->gem_context); - skip_request(request); + i915_request_skip(request, -EIO); /* If this context is now banned, skip all pending requests. */ if (i915_gem_context_is_banned(request->gem_context)) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index a2f7e9358450..7ae08b68121e 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -1013,6 +1013,27 @@ i915_request_await_object(struct i915_request *to, return ret; } +void i915_request_skip(struct i915_request *rq, int error) +{ + void *vaddr = rq->ring->vaddr; + u32 head; + + GEM_BUG_ON(!IS_ERR_VALUE((long)error)); This gets checked by dma_fence_set_error below but if you want to have it explicitly spelled out here OK. + dma_fence_set_error(&rq->fence, error); + + /* +* As this request likely depends on state from the lost +* context, clear out all the user operations leaving the +* breadcrumb at the end (so we get the fence notifications). +*/ + head = rq->infix; + if (rq->postfix < head) { + memset(vaddr + head, 0, rq->ring->size - head); + head = 0; + } + memset(vaddr + head, 0, rq->postfix - head); +} + /* * NB: This function is not allowed to fail. Doing so would mean the the * request is not being tracked for completion but the work itself is diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h index 7ee220ded9c9..a355a081485f 100644 --- a/drivers/gpu/drm/i915/i915_request.h +++ b/drivers/gpu/drm/i915/i915_request.h @@ -258,6 +258,8 @@ void i915_request_add(struct i915_request *rq); void __i915_request_submit(struct i915_request *request); void i915_request_submit(struct i915_request *request); +void i915_request_skip(struct i915_request *request, int error); + void __i915_request_unsubmit(struct i915_request *request); void i915_request_unsubmit(struct i915_request *request); With sounds of grumbling for code movement with changes: 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 1/6] drm/i915: Refactor export_fence() after i915_vma_move_to_active()
On 29/06/2018 23:54, Chris Wilson wrote: Currently all callers are responsible for adding the vma to the active timeline and then exporting its fence. Combine the two operations into i915_vma_move_to_active() to move all the extra handling from the callers to the single site. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c| 47 +-- drivers/gpu/drm/i915/selftests/huge_pages.c | 4 -- .../drm/i915/selftests/i915_gem_coherency.c | 4 -- .../gpu/drm/i915/selftests/i915_gem_context.c | 4 -- .../gpu/drm/i915/selftests/i915_gem_object.c | 4 -- 5 files changed, 21 insertions(+), 42 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index c2dd9b4cdace..91f20445147f 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -1166,15 +1166,9 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb, GEM_BUG_ON(!reservation_object_test_signaled_rcu(batch->resv, true)); i915_vma_move_to_active(batch, rq, 0); - reservation_object_lock(batch->resv, NULL); - reservation_object_add_excl_fence(batch->resv, &rq->fence); - reservation_object_unlock(batch->resv); i915_vma_unpin(batch); i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE); - reservation_object_lock(vma->resv, NULL); - reservation_object_add_excl_fence(vma->resv, &rq->fence); - reservation_object_unlock(vma->resv); rq->batch = batch; @@ -1771,25 +1765,6 @@ static int eb_relocate(struct i915_execbuffer *eb) return eb_relocate_slow(eb); } -static void eb_export_fence(struct i915_vma *vma, - struct i915_request *rq, - unsigned int flags) -{ - struct reservation_object *resv = vma->resv; - - /* -* Ignore errors from failing to allocate the new fence, we can't -* handle an error right now. Worst case should be missed -* synchronisation leading to rendering corruption. -*/ - reservation_object_lock(resv, NULL); - if (flags & EXEC_OBJECT_WRITE) - reservation_object_add_excl_fence(resv, &rq->fence); - else if (reservation_object_reserve_shared(resv) == 0) - reservation_object_add_shared_fence(resv, &rq->fence); - reservation_object_unlock(resv); -} - static int eb_move_to_gpu(struct i915_execbuffer *eb) { const unsigned int count = eb->buffer_count; @@ -1844,7 +1819,6 @@ static int eb_move_to_gpu(struct i915_execbuffer *eb) struct i915_vma *vma = eb->vma[i]; i915_vma_move_to_active(vma, eb->request, flags); - eb_export_fence(vma, eb->request, flags); __eb_unreserve_vma(vma, flags); vma->exec_flags = NULL; @@ -1884,6 +1858,25 @@ static bool i915_gem_check_execbuffer(struct drm_i915_gem_execbuffer2 *exec) return true; } +static void export_fence(struct i915_vma *vma, +struct i915_request *rq, +unsigned int flags) +{ + struct reservation_object *resv = vma->resv; + + /* +* Ignore errors from failing to allocate the new fence, we can't +* handle an error right now. Worst case should be missed +* synchronisation leading to rendering corruption. +*/ + reservation_object_lock(resv, NULL); + if (flags & EXEC_OBJECT_WRITE) + reservation_object_add_excl_fence(resv, &rq->fence); + else if (reservation_object_reserve_shared(resv) == 0) + reservation_object_add_shared_fence(resv, &rq->fence); + reservation_object_unlock(resv); +} + void i915_vma_move_to_active(struct i915_vma *vma, struct i915_request *rq, unsigned int flags) @@ -1921,6 +1914,8 @@ void i915_vma_move_to_active(struct i915_vma *vma, if (flags & EXEC_OBJECT_NEEDS_FENCE) i915_gem_active_set(&vma->last_fence, rq); + + export_fence(vma, rq, flags); Don't care about new extra reservation object operations from the other i915_move_to_active_callers? Regards, Tvrtko } static int i915_reset_gen7_sol_offsets(struct i915_request *rq) diff --git a/drivers/gpu/drm/i915/selftests/huge_pages.c b/drivers/gpu/drm/i915/selftests/huge_pages.c index b5e87fcdcdae..358fc81f6c99 100644 --- a/drivers/gpu/drm/i915/selftests/huge_pages.c +++ b/drivers/gpu/drm/i915/selftests/huge_pages.c @@ -998,10 +998,6 @@ static int gpu_write(struct i915_vma *vma, i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE); - reservation_object_lock(vma->resv, NULL); - reservation_object_add_excl_fence(vma->resv, &rq->fence); - reservation_object_unlock(vma->resv); - err_request: i915_request_add(rq); diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_coherency.c b/drivers/gpu/drm/i
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_pipe_crc_basic: expect setting bad source to fail
Op 02-07-18 om 13:16 schreef Mahesh Kumar: > Now crc-core framework verifies the source string passed by the user. > So setting bad-source will fail. Expect file write to fail in bad-source > subtest of kms_pipe_crc_basic. > > Signed-off-by: Mahesh Kumar > --- > tests/kms_pipe_crc_basic.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c > index 235fdc38..2d4dfee8 100644 > --- a/tests/kms_pipe_crc_basic.c > +++ b/tests/kms_pipe_crc_basic.c > @@ -48,8 +48,7 @@ static struct { > > static void test_bad_source(data_t *data) > { > - igt_assert(igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo")); > - igt_assert(openat(data->debugfs, "crtc-0/crc/data", O_WRONLY) == -1); > + igt_assert(!igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo")); > } > > #define N_CRCS 3 New behavior makes more sense. Reviewed-by: Maarten Lankhorst Do you have igt commit rights? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/kms_pipe_crc_basic: expect setting bad source to fail
Now crc-core framework verifies the source string passed by the user. So setting bad-source will fail. Expect file write to fail in bad-source subtest of kms_pipe_crc_basic. Signed-off-by: Mahesh Kumar --- tests/kms_pipe_crc_basic.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c index 235fdc38..2d4dfee8 100644 --- a/tests/kms_pipe_crc_basic.c +++ b/tests/kms_pipe_crc_basic.c @@ -48,8 +48,7 @@ static struct { static void test_bad_source(data_t *data) { - igt_assert(igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo")); - igt_assert(openat(data->debugfs, "crtc-0/crc/data", O_WRONLY) == -1); + igt_assert(!igt_sysfs_set(data->debugfs, "crtc-0/crc/control", "foo")); } #define N_CRCS 3 -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/amdgpu_dm/crc: Implement verify_crc_source callback
This patch implements "verify_crc_source" callback function for AMD drm driver. Signed-off-by: Mahesh Kumar Cc: dri-de...@lists.freedesktop.org Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 16 3 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 66bd3cc3e387..dd97cbca0527 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2563,6 +2563,7 @@ static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs = { .atomic_duplicate_state = dm_crtc_duplicate_state, .atomic_destroy_state = dm_crtc_destroy_state, .set_crc_source = amdgpu_dm_crtc_set_crc_source, + .verify_crc_source = amdgpu_dm_crtc_verify_crc_source, .enable_vblank = dm_enable_vblank, .disable_vblank = dm_disable_vblank, }; diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h index a29dc35954c9..e43ed064dc46 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h @@ -260,9 +260,13 @@ amdgpu_dm_remove_sink_from_freesync_module(struct drm_connector *connector); #ifdef CONFIG_DEBUG_FS int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name, size_t *values_cnt); +int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, +const char *src_name, +size_t *values_cnt); void amdgpu_dm_crtc_handle_crc_irq(struct drm_crtc *crtc); #else #define amdgpu_dm_crtc_set_crc_source NULL +#define amdgpu_dm_crtc_verify_crc_source NULL #define amdgpu_dm_crtc_handle_crc_irq(x) #endif diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c index 52f2c01349e3..dfcca594d52a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c @@ -46,6 +46,22 @@ static enum amdgpu_dm_pipe_crc_source dm_parse_crc_source(const char *source) return AMDGPU_DM_PIPE_CRC_SOURCE_INVALID; } +int +amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const char *src_name, +size_t *values_cnt) +{ + enum amdgpu_dm_pipe_crc_source source = dm_parse_crc_source(src_name); + + if (source < 0) { + DRM_DEBUG_DRIVER("Unknown CRC source %s for CRTC%d\n", +src_name, crtc->index); + return -EINVAL; + } + + *values_cnt = 3; + return 0; +} + int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name, size_t *values_cnt) { -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915/crc: implement get_crc_sources callback
This patch implements get_crc_sources callback, which returns list of all the valid crc sources supported by driver in current platform. Changes since V1: - Return array of crc sources Signed-off-by: Mahesh Kumar Cc: dri-de...@lists.freedesktop.org Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_drv.h | 3 +++ drivers/gpu/drm/i915/intel_pipe_crc.c | 7 +++ 3 files changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 977ee4c7ef7b..6918c5127473 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -12894,6 +12894,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = { .atomic_destroy_state = intel_crtc_destroy_state, .set_crc_source = intel_crtc_set_crc_source, .verify_crc_source = intel_crtc_verify_crc_source, + .get_crc_sources = intel_crtc_get_crc_sources, }; struct wait_rps_boost { diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 764b53dfe7de..99e3b6477d39 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -2158,11 +2158,14 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name, size_t *values_cnt); int intel_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name, size_t *values_cnt); +const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc, + size_t *count); void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc); void intel_crtc_enable_pipe_crc(struct intel_crtc *crtc); #else #define intel_crtc_set_crc_source NULL #define intel_crtc_verify_crc_source NULL +#define intel_crtc_get_crc_sources NULL static inline void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc) { } diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c b/drivers/gpu/drm/i915/intel_pipe_crc.c index a37521380f94..1dffc346f1bc 100644 --- a/drivers/gpu/drm/i915/intel_pipe_crc.c +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c @@ -1001,6 +1001,13 @@ intel_is_valid_crc_source(struct drm_i915_private *dev_priv, return ivb_crc_source_valid(dev_priv, source); } +const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc, + size_t *count) +{ + *count = ARRAY_SIZE(pipe_crc_sources); + return pipe_crc_sources; +} + int intel_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name, size_t *values_cnt) { -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx