Re: [Intel-gfx] [i915] WARNING: CPU: 2 PID: 183 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060
Hey, Op 19-04-18 om 04:52 schreef Fengguang Wu: > Hello, > > FYI this happens in mainline kernel and at least dates back to v4.13 . > > [ 75.245840] > [ 75.247783] /opt/deb/gawk_1%3a4.1.4+dfsg-1_amd64.deb > [ 75.247785] > [ 75.248145] [ cut here ] > [ 75.248446] Could not determine valid watermarks for inherited state > [ 75.248889] WARNING: CPU: 2 PID: 183 at > drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3be/0x1060 > [i915] > [ 75.249372] /opt/deb/sysstat_11.6.0-1_amd64.deb > [ 75.249617] Modules linked in: > [ 75.249619] > [ 75.249883] crc32c_intel(+) ghash_clmulni_intel pcbc wmi_bmof ahci > libahci snd_hda_intel i915(+) uvcvideo videobuf2_vmalloc aesni_intel > crypto_simd cryptd videobuf2_memops glue_helper snd_hda_codec videobuf2_v4l2 > pcspkr videobuf2_common serio_raw drm_kms_helper snd_hda_core snd_hwdep > libata snd_pcm syscopyarea sysfillrect sysimgblt fb_sys_fops bcma snd_timer > snd soundcore drm videodev shpchp ideapad_laptop wmi sparse_keymap rfkill > video ip_tables > [ 75.252346] CPU: 2 PID: 183 Comm: systemd-udevd Not tainted 4.17.0-rc1 #1 > [ 75.252718] Hardware name: LENOVO IdeaPad U410/Lenovo , BIOS > 65CN15WW 06/05/2012 > [ 75.253140] (Reading database ... 2202 files and directories currently > installed.) > [ 75.253229] RIP: 0010:intel_modeset_init+0x3be/0x1060 [i915] > [ 75.253230] > [ 75.254044] RSP: 0018:c99f7af0 EFLAGS: 00010282 > [ 75.254339] RAX: 0038 RBX: 88011bfc RCX: > 0006 > [ 75.254731] RDX: 0007 RSI: 0082 RDI: > 88011f296910 > [ 75.255121] RBP: 88011933e400 R08: 0363 R09: > 000a > [ 75.255512] R10: c99f7988 R11: 82d4e10d R12: > 88011933fc00 > [ 75.255898] R13: ffea R14: R15: > 88011bfc0358 > [ 75.256290] FS: 7f0b39a7d8c0() GS:88011f28() > knlGS: > [ 75.256731] CS: 0010 DS: ES: CR0: 80050033 > [ 75.257050] CR2: 7f599dcec750 CR3: 00011bdcc004 CR4: > 001606e0 > [ 75.257111] Preparing to unpack .../opt/deb/debconf_1.5.66_all.deb ... > [ 75.257449] Call Trace: > [ 75.257450] > [ 75.258115] i915_driver_load+0xa99/0xee0 [i915] > [ 75.258388] ? acpi_dev_found+0x5f/0x70: > acpi_dev_found at > drivers/acpi/utils.c:737 > [ 75.258616] local_pci_probe+0x42/0xa0: > local_pci_probe at > drivers/pci/pci-driver.c:304 > [ 75.258835] ? _cond_resched+0x19/0x30: > _cond_resched at > kernel/sched/core.c:4982 > [ 75.259055] pci_device_probe+0x11d/0x180: > pci_call_probe at > drivers/pci/pci-driver.c:358 >(inlined by) > __pci_device_probe at drivers/pci/pci-driver.c:383 >(inlined by) pci_device_probe > at drivers/pci/pci-driver.c:423 > [ 75.259287] driver_probe_device+0x30b/0x480: > really_probe at > drivers/base/dd.c:449 >(inlined by) > driver_probe_device at drivers/base/dd.c:590 > [ 75.259531] __driver_attach+0xb8/0xe0: > __driver_attach at > drivers/base/dd.c:824 > [ 75.259661] Unpacking debconf (1.5.66) over (1.5.59) ... > [ 75.259748] ? driver_probe_device+0x480/0x480: > __driver_attach at > drivers/base/dd.c:794 > [ 75.259749] > [ 75.260394] bus_for_each_dev+0x65/0x90: > bus_for_each_dev at > drivers/base/bus.c:310 > [ 75.260624] bus_add_driver+0x161/0x260: > bus_add_driver at > drivers/base/bus.c:668 > [ 75.260849] ? 0xa0553000 > [ 75.261042] driver_register+0x57/0xc0: > driver_register at > drivers/base/driver.c:167 > [ 75.261259] ? 0xa0553000 > [ 75.261451] do_one_initcall+0x36/0x1bb: > do_one_initcall at > init/main.c:883 > [ 75.261676] ? _cond_resched+0x19/0x30: > _cond_resched at > kernel/sched/core.c:4982 > [ 75.261898] ? kmem_cache_alloc_trace+0x3e/0x1e0: > slab_pre_alloc_hook at > mm/slab.h:423 >(inlined by) slab_alloc_node > at mm/slub.c:2667 >(inlined by) slab_alloc at > mm/slub.c:2749 >(inlined by) > kmem_cache_alloc_trace at mm/slub.c:2766 > [ 75.262166] do_init_module+0x5b/0x
Re: [Intel-gfx] [PATCH] drm/i915: Refine the has_audio assignment
>-Original Message- >From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] >Sent: Thursday, April 19, 2018 2:13 PM >To: Shi, Yang A ; Jani Nikula >; >intel-gfx@lists.freedesktop.org >Subject: RE: [Intel-gfx] [PATCH] drm/i915: Refine the has_audio assignment > >Quoting Shi, Yang A (2018-04-19 02:22:33) >> >-Original Message- >> >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >> >Sent: Wednesday, April 18, 2018 8:44 PM >> >To: Chris Wilson ; Shi, Yang A >> >; intel-gfx@lists.freedesktop.org >> >Cc: Shi, Yang A >> >Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refine the has_audio >> >assignment >> > >> >On Fri, 13 Apr 2018, Chris Wilson wrote: >> >> Quoting Yang (2018-04-13 05:06:45) >> >>> From: Yang Shi >> >>> >> >>> Refine the has_audio assignment for dp and hdmi. >> >> >> >> s/Refine/Ignore the user override for/ >> >> >> >> Why? >> > >> >Yang, we'll need the explanation before we continue with review or >> >even consider merging. We routinely ignore patches where questions go >> >unanswered. >> > >> >BR, >> >Jani. >> >> This code change is just to make driver code more readable. >> If(condition) value = a else value = condition looks redundancy. > >Read the patch again, AUTO != ON. >-Chris Yes, I make a mistake and misunderstand such code. BR. Yang. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Refine the has_audio assignment
Quoting Shi, Yang A (2018-04-19 02:22:33) > >-Original Message- > >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >Sent: Wednesday, April 18, 2018 8:44 PM > >To: Chris Wilson ; Shi, Yang A > >; > >intel-gfx@lists.freedesktop.org > >Cc: Shi, Yang A > >Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refine the has_audio assignment > > > >On Fri, 13 Apr 2018, Chris Wilson wrote: > >> Quoting Yang (2018-04-13 05:06:45) > >>> From: Yang Shi > >>> > >>> Refine the has_audio assignment for dp and hdmi. > >> > >> s/Refine/Ignore the user override for/ > >> > >> Why? > > > >Yang, we'll need the explanation before we continue with review or even > >consider > >merging. We routinely ignore patches where questions go unanswered. > > > >BR, > >Jani. > > This code change is just to make driver code more readable. > If(condition) value = a else value = condition looks redundancy. Read the patch again, AUTO != ON. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read
For the PW results: https://patchwork.freedesktop.org/series/41877/ it didn't fix the CRC mismatch on: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8731/shard-snb6/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html but that test has always failed on SNB: http://gfx-ci.fi.intel.com/cibuglog/?action_failures_history=-1&failures_test=igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw&failures_machine=shard-snb so I don't think you brake anything with this patch. Mika, do you know if waiting for the extra vblank was done with some purpose? > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Mika Kahola > Sent: Wednesday, April 18, 2018 10:57 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH] drm/i915: Wait for vblank after register read > > When reading out CRC's we wait for a vblank on intel_dp_sink_crc_start() > function. When we start reading out CRC's in intel_dp_sink_crc() loop we > first wait for a vblank yielding that all in all we end up waiting two > vblanks on > the first iteration round. Therefore, let's move the > intel_wait_for_vblank() as the last routine that we do in an iteration loop in > intel_dp_sink_crc(). > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103166 > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/intel_dp.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > b/drivers/gpu/drm/i915/intel_dp.c index 62f82c4..6eb97fa 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -3972,13 +3972,14 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, > struct intel_crtc_state *crtc_s > return ret; > > do { > - intel_wait_for_vblank(dev_priv, intel_crtc- > >pipe); > - > if (drm_dp_dpcd_readb(&intel_dp->aux, > > DP_TEST_SINK_MISC, &buf) < 0) { > ret = -EIO; > goto stop; > } > + > + intel_wait_for_vblank(dev_priv, intel_crtc- > >pipe); > + > count = buf & DP_TEST_COUNT_MASK; > > } while (--attempts && count == 0); > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt/gem_ppgtt: Flush the driver to idle before counting leaks
I have a cunning plan to make the vma open/close lazy to cache frequent reallocations (as buffers are passed between applications, e.g. DRI). However, this will mean that we will not be immediately closing vma and so need to tell the kernel to process the idle handlers before checking for leaks. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- tests/gem_ppgtt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/gem_ppgtt.c b/tests/gem_ppgtt.c index bed95db83..575b0e9d3 100644 --- a/tests/gem_ppgtt.c +++ b/tests/gem_ppgtt.c @@ -236,7 +236,7 @@ static void flink_and_close(void) gem_sync(fd2, flinked_bo); gem_close(fd2, flinked_bo); - igt_drop_caches_set(fd, DROP_RETIRE); + igt_drop_caches_set(fd, DROP_RETIRE | DROP_IDLE); /* the flinked bo VMA should have been cleared now, so a new bo of the * same size should get the same offset @@ -286,7 +286,7 @@ static void flink_and_exit(void) exec_and_get_offset(fd3, gem_create(fd3, 4096)); close(fd3); - igt_drop_caches_set(fd, DROP_ACTIVE | DROP_RETIRE); + igt_drop_caches_set(fd, DROP_ACTIVE | DROP_RETIRE | DROP_IDLE); igt_assert(!igt_debugfs_search(fd, "i915_gem_gtt", match)); close(fd); -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
On Wednesday 18 April 2018 08:47 PM, Ville Syrjälä wrote: On Wed, Apr 18, 2018 at 09:20:23AM +0300, Jani Nikula wrote: On Wed, 18 Apr 2018, Ramalingam C wrote: On Tuesday 17 April 2018 11:39 PM, Ville Syrjälä wrote: On Tue, Apr 17, 2018 at 02:25:32PM +0530, Ramalingam C wrote: >From Gen9 onwards Bspec says HW supports Max Bytes per single RD/WR op is 511Bytes instead of previous 256Bytes used in SW. This change allows the max bytes per op upto 511Bytes from Gen9 onwards. v2: No Change. v3: Inline function for max_xfer_size and renaming of the macro.[Jani] Cc: Jani Nikula Cc: Chris Wilson Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_i2c.c | 11 +-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 475cac07d3e6..be6114a0e8ab 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3013,6 +3013,7 @@ enum i915_power_well_id { #define GMBUS_CYCLE_STOP (4<<25) #define GMBUS_BYTE_COUNT_SHIFT 16 #define GMBUS_BYTE_COUNT_MAX 256U +#define GEN9_GMBUS_BYTE_COUNT_MAX 511U #define GMBUS_SLAVE_INDEX_SHIFT 8 #define GMBUS_SLAVE_ADDR_SHIFT 1 #define GMBUS_SLAVE_READ (1<<0) diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index e6875509bcd9..4367827d7661 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -361,6 +361,13 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv) return ret; } +static inline +unsigned int gmbus_max_xfer_size(struct drm_i915_private *dev_priv) +{ + return (INTEL_GEN(dev_priv) >= 9) ? GEN9_GMBUS_BYTE_COUNT_MAX : + GMBUS_BYTE_COUNT_MAX; Hmm. You sure about this 256 limit on older HW? The spec does sort of say that 0-256 is the valid range, but the SPT+ docs still have that same text, and the register has always had 9 bits for byte count. I don't see any statements saying that they changed this in any way for SPT. It only talks about >511 bytes needing the special treatment. If we do this the I think you should just drop the defines and put the raw numbers into this function. The extra indirection just makes life harder. Also pointless parens around the GEN>9 check. Even I couldn't get any place where BSpec says 256Bytes is the limit for any platform. Everywhere 9bits are used. And when I cross verified with other OS usage 511Bytes is used as limit across all platforms. Just to be cautious for not breaking any older platforms out in linux world, I limited the extension of the limit to the known and easily testable platforms at my desk (Gen9+) Do you suggest we should apply 511Bytes as max limit for all platforms? Do we have any means to test this new limit on all supported legacy platforms? Except enabling the full potential of the HW in SW, I dont see any ROI here as most of the GMBUS reqs are <256Bytes. Only in case of HDCP2.2 we need single read cycle for 538Bytes. we have couple of options here: Please share your opinion to choose one of them. 1. Just dont change the upper limit for RD/WR. Keep it as it is at 256Bytes. Anyway no user demands it. 2. As per HW capability, Change the upper limit for RD/WR to 511Bytes for all platforms. This is needs the functional verification on all legacy plat supported. 3. Change the upper limit for RD/WR to 511Bytes for newer platforms, say Gen9+. Please let's not change the limit for old platforms for absolutely no gain. And if Ville insists anyway, let's leave that as a separate follow-up change that can easily be reverted later. I might consider using the 511 limit only for platforms that HAS_GMBUS_BURST_READ too. The original limit seems to have been added in 9535c4757b88 ("drm/i915: cope with large i2c transfers") citing "the specs". Any recollection anyone? Chris? "Duble buffered data register and a 9 bit counter support 0 byte to 256 Byte transfers." has always been in the spec (and still is for SPT+). Seems like gap in Bspec. Just today HW team has clarified that all platforms support 511Bytes for single Gmbus read and write cycle. --Ram ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12
> -Original Message- > From: Kahola, Mika > Sent: Wednesday, April 18, 2018 5:39 PM > To: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add > skl_check_nv12_surface for NV12 > > On Wed, 2018-04-18 at 09:38 +0530, Vidya Srinivas wrote: > > From: Maarten Lankhorst > > > > We skip src trunction/adjustments for > > NV12 case and handle the sizes directly. > > Without this, pipe fifo underruns are seen on APL/KBL. > > > > v2: For NV12, making the src coordinates multiplier of 4 > > > > v3: Moving all the src coords handling code for NV12 to > > skl_check_nv12_surface > The patch looks good to me. > > Reviewed-by: Mika Kahola Thank you. Will add the RB in next push. Regards Vidya > > > > > Signed-off-by: Maarten Lankhorst > > Signed-off-by: Vidya Srinivas > > --- > > drivers/gpu/drm/i915/intel_display.c | 39 > > > > drivers/gpu/drm/i915/intel_sprite.c | 15 ++ > > 2 files changed, 50 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > b/drivers/gpu/drm/i915/intel_display.c > > index 925402e..b8dbaca 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct > > intel_crtc_state *crtc_state, > > return 0; > > } > > > > +static int > > +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state, > > + struct intel_plane_state *plane_state) { > > + int crtc_x2 = plane_state->base.crtc_x + plane_state- > > >base.crtc_w; > > + int crtc_y2 = plane_state->base.crtc_y + plane_state- > > >base.crtc_h; > > + > > + if (((plane_state->base.src_x >> 16) % 4) != 0 || > > + ((plane_state->base.src_y >> 16) % 4) != 0 || > > + ((plane_state->base.src_w >> 16) % 4) != 0 || > > + ((plane_state->base.src_h >> 16) % 4) != 0) { > > + DRM_DEBUG_KMS("src coords must be multiple of 4 for > > NV12\n"); > > + return -EINVAL; > > + } > > + > > + /* Clipping would cause a 1-3 pixel gap at the edge of the > > screen? */ > > + if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state- > > >pipe_src_w % 4) || > > + (crtc_y2 > crtc_state->pipe_src_h && crtc_state- > > >pipe_src_h % 4)) { > > + DRM_DEBUG_KMS("It's not possible to clip %u,%u to > > %u,%u\n", > > + crtc_x2, crtc_y2, > > + crtc_state->pipe_src_w, crtc_state- > > >pipe_src_h); > > + return -EINVAL; > > + } > > + > > + plane_state->base.src.x1 = > > + DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) > > << 18; > > + plane_state->base.src.x2 = > > + DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) > > << 18; > > + plane_state->base.src.y1 = > > + DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) > > << 18; > > + plane_state->base.src.y2 = > > + DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) > > << 18; > > + > > + return 0; > > +} > > + > > static int skl_check_nv12_aux_surface(struct intel_plane_state > > *plane_state) > > { > > const struct drm_framebuffer *fb = plane_state->base.fb; @@ - > 3201,6 > > +3237,9 @@ int skl_check_plane_surface(const struct intel_crtc_state > > *crtc_state, > > * the main surface setup depends on it. > > */ > > if (fb->format->format == DRM_FORMAT_NV12) { > > + ret = skl_check_nv12_surface(crtc_state, > > plane_state); > > + if (ret) > > + return ret; > > ret = skl_check_nv12_aux_surface(plane_state); > > if (ret) > > return ret; > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > > b/drivers/gpu/drm/i915/intel_sprite.c > > index 8b7947d..f9985fb 100644 > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane > > *plane, > > return vscale; > > } > > > > - /* Make the source viewport size an exact multiple > > of the scaling factors. */ > > - drm_rect_adjust_size(src, > > - drm_rect_width(dst) * hscale - > > drm_rect_width(src), > > - drm_rect_height(dst) * vscale - > > drm_rect_height(src)); > > + if (fb->format->format != DRM_FORMAT_NV12) { > > + /* > > + * Make the source viewport size > > + * an exact multiple of the scaling factors > > + */ > > + drm_rect_adjust_size(src, > > + (drm_rect_width(dst) * > > hscale - > > + drm_rect_width(src)), > > + (drm_rect_height(dst) * > > vscale - > > +
Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12
> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Thursday, April 19, 2018 12:06 AM > To: Maarten Lankhorst > Cc: Srinivas, Vidya ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add > skl_check_nv12_surface for NV12 > > On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote: > > Op 18-04-18 om 17:32 schreef Ville Syrjälä: > > > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote: > > >> From: Maarten Lankhorst > > >> mailto:maarten.lankho...@linux.intel.com>> > > >> > > >> We skip src trunction/adjustments for > > >> NV12 case and handle the sizes directly. > > >> Without this, pipe fifo underruns are seen on APL/KBL. > > >> > > >> v2: For NV12, making the src coordinates multiplier of 4 > > >> > > >> v3: Moving all the src coords handling code for NV12 to > > >> skl_check_nv12_surface > > >> > > >> Signed-off-by: Maarten Lankhorst > > >> mailto:maarten.lankho...@linux.intel.com>> > > >> Signed-off-by: Vidya Srinivas > > >> mailto:vidya.srini...@intel.com>> > > >> --- > > >> drivers/gpu/drm/i915/intel_display.c | 39 > > >> > > >> drivers/gpu/drm/i915/intel_sprite.c | 15 ++ > > >> 2 files changed, 50 insertions(+), 4 deletions(-) > > >> > > >> diff --git a/drivers/gpu/drm/i915/intel_display.c > > >> b/drivers/gpu/drm/i915/intel_display.c > > >> index 925402e..b8dbaca 100644 > > >> --- a/drivers/gpu/drm/i915/intel_display.c > > >> +++ b/drivers/gpu/drm/i915/intel_display.c > > >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const > struct intel_crtc_state *crtc_state, > > >> return 0; > > >> } > > >> > > >> +static int > > >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state, > > >> + struct intel_plane_state > > >> *plane_state) { > > >> +int crtc_x2 = plane_state->base.crtc_x + > > >> plane_state->base.crtc_w; > > >> +int crtc_y2 = plane_state->base.crtc_y + > > >> +plane_state->base.crtc_h; > > >> + > > >> +if (((plane_state->base.src_x >> 16) % 4) != 0 || > > >> +((plane_state->base.src_y >> 16) % 4) != 0 || > > >> +((plane_state->base.src_w >> 16) % 4) != 0 || > > >> +((plane_state->base.src_h >> 16) % 4) != 0) { > > >> +DRM_DEBUG_KMS("src coords must be > > >> multiple of 4 for > NV12\n"); > > >> +return -EINVAL; > > >> +} > > > I don't really see why we should check these. The clipped > > > coordinates are what matters. > > > > To propagate our limits to the userspace. I think we should do it for > > all formats, but NV12 is the first YUV format we have tests for. If we > > could we should do something similar for the other YUV formats, but they > have different requirements. > > > > In case of NV12 we don't have existing userspace, there will be > > nothing that breaks if we enforce limits from the start. > > But what about sub-pixel coordinates? You're totally ignoring them here. > We need to come up with some proper rules for this stuff. > > > > > >> + > > >> +/* Clipping would cause a 1-3 pixel gap at the edge of > > >> the screen? */ > > >> +if ((crtc_x2 > crtc_state->pipe_src_w && > > >> crtc_state->pipe_src_w % > 4) || > > >> +(crtc_y2 > crtc_state->pipe_src_h && > > >> crtc_state->pipe_src_h % 4)) > { > > >> +DRM_DEBUG_KMS("It's not possible to > > >> clip %u,%u to > %u,%u\n", > > >> + crtc_x2, crtc_y2, > > >> + > > >> crtc_state->pipe_src_w, crtc_state->pipe_src_h); > > >> +return -EINVAL; > > >> +} > > > Why should we care? The current code already plays it fast and loose > > > and allows the dst rectangle to shrink to accomodate the hw limits. > > > If we want to change that we should change it universally. > > > > Unfortunately for the other formats we already have an existing > > userspace > > (X.org) that doesn't perform any validation. We can't change it for > > that, but we can prevent future mistakes. > > We should do it uniformly. Not per-format. That will make the code > unmaintainable real quick. > > > > > >> + > > >> +plane_state->base.src.x1 = > > >> + > > >> DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << > 18; > > >> +plane_state->base.src.x2 = > > >> + > > >> DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << > 18; > > >> +plane_state->base.src.y1 = > > >> +
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/fbdev: Enable late fbdev initial configuration (rev4)
== Series Details == Series: drm/i915/fbdev: Enable late fbdev initial configuration (rev4) URL : https://patchwork.freedesktop.org/series/41851/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4067_full -> Patchwork_8744_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8744_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8744_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41851/revisions/4/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8744_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: SKIP -> PASS +2 igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: PASS -> SKIP +3 == Known issues == Here are the changes found in Patchwork_8744_full that come from known issues: === IGT changes === Issues hit igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: PASS -> INCOMPLETE (fdo#103665, fdo#106023) igt@kms_flip@2x-dpms-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: PASS -> FAIL (fdo#102887) igt@kms_flip@2x-plain-flip-fb-recreate: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@2x-wf_vblank-ts-check: shard-hsw: PASS -> FAIL (fdo#103928) igt@kms_flip@flip-vs-modeset-vs-hang-interruptible: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602, fdo#103313) +1 igt@kms_sysfs_edid_timing: shard-apl: PASS -> WARN (fdo#100047) igt@pm_rpm@basic-pci-d3-state: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) +2 Possible fixes igt@kms_flip@wf_vblank-ts-check-interruptible: shard-apl: FAIL (fdo#100368) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 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#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4067 -> Patchwork_8744 CI_DRM_4067: 1c7ccdf37b04bedb10e2191d34dfbba62beb79ea @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8744: d356736d30be910191082e9535bee7f55303cd9e @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8744/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Refine the has_audio assignment
>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Wednesday, April 18, 2018 8:44 PM >To: Chris Wilson ; Shi, Yang A >; >intel-gfx@lists.freedesktop.org >Cc: Shi, Yang A >Subject: Re: [Intel-gfx] [PATCH] drm/i915: Refine the has_audio assignment > >On Fri, 13 Apr 2018, Chris Wilson wrote: >> Quoting Yang (2018-04-13 05:06:45) >>> From: Yang Shi >>> >>> Refine the has_audio assignment for dp and hdmi. >> >> s/Refine/Ignore the user override for/ >> >> Why? > >Yang, we'll need the explanation before we continue with review or even >consider >merging. We routinely ignore patches where questions go unanswered. > >BR, >Jani. This code change is just to make driver code more readable. If(condition) value = a else value = condition looks redundancy. BR. Yang. > > >-- >Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: set minimum CD clock to twice the BCLK.
On 4/18/2018 8:41 AM, Ville Syrjälä wrote: On Wed, Apr 18, 2018 at 01:49:23PM +0300, Jani Nikula wrote: On Tue, 17 Apr 2018, "Kumar, Abhay" wrote: On 4/17/2018 12:06 PM, Abhay Kumar wrote: In glk when device boots with only 1366x768 panel, HDA codec doesn't comeup. This result in no audio forever as cdclk is < 96Mhz. This change will ensure CD clock to be twice of BCLK. v2: - Address comment (Jani) - New design approach v3: - Typo fix on top of v1 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937 Signed-off-by: Abhay Kumar --- drivers/gpu/drm/i915/intel_cdclk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index dc7db8a2caf8..6e93af4a46ea 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -2143,7 +2143,7 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state) /* According to BSpec, "The CD clock frequency must be at least twice * the frequency of the Azalia BCLK." and BCLK is 96 MHz by default. */ - if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9) + if (INTEL_GEN(dev_priv) >= 9) min_cdclk = max(2 * 96000, min_cdclk); /* Hi Ville, Jani, Since right version of this patch is taking time(doing modeset and cdclk bump) as we need to poke sound driver. Can we please get this v3(same as v1 with typo fix in comment) version of patch merged. This works all the time and will unblock Audio and lot of folks. without this patch audio card is not getting detected at all and blocking basic audio feature. I expanded on the code comment, rewrote the commit message, added cc: stable, and resent the patch [1]. It's not a patch I much like, it's not even a complete fix, and I would like this to be addressed properly going forward. However, the proper fix is I think too invasive for stable, so here we are. I'm trying to at least explain in the comment and commit message what's going on, for posterity. Ville, I'm not going to push the patch without your ack, but we can't sit on this forever either. The patch papers over the most common failure case, for now, so perhaps it'll buy us time to find a proper solution. While I don't particularly like this patch I also agree that it's the least risky way to go for stable. So Acked-by: Ville Syrjälä Abhay, if we merge this, I do expect your support in figuring out and testing the proper fix. This is not it. I also want to see a better solution going forward. Yes will work on this. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
== Series Details == Series: series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function URL : https://patchwork.freedesktop.org/series/41923/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8743_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8743_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8743_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41923/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8743_full: === IGT changes === Possible regressions igt@gem_eio@suspend: shard-hsw: PASS -> DMESG-WARN Warnings igt@gem_mocs_settings@mocs-rc6-dirty-render: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_8743_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@modeset-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) shard-apl: PASS -> FAIL (fdo#103060) igt@kms_flip@plain-flip-fb-recreate-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_mmap_write_crc: shard-apl: PASS -> FAIL (fdo#103286) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) igt@prime_vgem@basic-fence-flip: shard-apl: PASS -> FAIL (fdo#104008) Possible fixes igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-farfromfence: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +2 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#103286 https://bugs.freedesktop.org/show_bug.cgi?id=103286 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8743 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8743: 524271645ddca56c7333fb096cb311eb98a5cbc3 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8743/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/fbdev: Enable late fbdev initial configuration (rev4)
== Series Details == Series: drm/i915/fbdev: Enable late fbdev initial configuration (rev4) URL : https://patchwork.freedesktop.org/series/41851/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4067 -> Patchwork_8744 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41851/revisions/4/mbox/ == Known issues == Here are the changes found in Patchwork_8744 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: fi-skl-guc: PASS -> FAIL (fdo#103191) igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fi-skl-guc: FAIL (fdo#103191) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (34 -> 30) == Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-bxt-dsi fi-skl-6700hq == Build changes == * Linux: CI_DRM_4067 -> Patchwork_8744 CI_DRM_4067: 1c7ccdf37b04bedb10e2191d34dfbba62beb79ea @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8744: d356736d30be910191082e9535bee7f55303cd9e @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == d356736d30be drm/i915/fbdev: Enable late fbdev initial configuration == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8744/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/fbdev: Enable late fbdev initial configuration
If the initial fbdev configuration(intel_fbdev_initial_config()) runs and there still no sink connected it will cause drm_fb_helper_initial_config() to return 0 as no error happened(but internally the return is -EAGAIN). Because no framebuffer was allocated, when a sink is connected intel_fbdev_output_poll_changed() will not execute drm_fb_helper_hotplug_event() that would trigger another try to do the initial fbdev configuration. So here allowing drm_fb_helper_hotplug_event() to be executed when there is not frambebuffer allocated and fbdev was not setup yet. This issue also happens when a MST DP sink is connected since boot, as the MST topology is discovered in parallel if intel_fbdev_initial_config() is executed before the first sink MST is discovered it will cause this same issue. This is a follow up patch of https://patchwork.freedesktop.org/patch/196089/ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425 Cc: Rodrigo Vivi Signed-off-by: Chris Wilson Signed-off-by: José Roberto de Souza --- Changes from v1: - not creating a dump framebuffer anymore, instead just allowing drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet. drivers/gpu/drm/i915/intel_fbdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index 7d41d139341b..e9e02b58b7be 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -807,7 +807,7 @@ void intel_fbdev_output_poll_changed(struct drm_device *dev) return; intel_fbdev_sync(ifbdev); - if (ifbdev->vma) + if (ifbdev->vma || ifbdev->helper.deferred_setup) drm_fb_helper_hotplug_event(&ifbdev->helper); } -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers
== Series Details == Series: series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers URL : https://patchwork.freedesktop.org/series/41911/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8740_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8740_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8740_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41911/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8740_full: === IGT changes === Possible regressions igt@gem_eio@unwedge-stress: shard-apl: PASS -> FAIL Warnings igt@gem_mocs_settings@mocs-rc6-dirty-render: shard-kbl: SKIP -> PASS +2 == Known issues == Here are the changes found in Patchwork_8740_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@modeset-vs-vblank-race: shard-apl: PASS -> FAIL (fdo#103060) igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@plain-flip-ts-check: shard-hsw: PASS -> FAIL (fdo#103928) igt@kms_flip@plain-flip-ts-check-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-farfromfence: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +2 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8740 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8740: 80a6c86f4aeac5561931d675ac82e01624e37eb8 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8740/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 series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
== Series Details == Series: series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function URL : https://patchwork.freedesktop.org/series/41923/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8743 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41923/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8743 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) fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 == Participating hosts (33 -> 31) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8743 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8743: 524271645ddca56c7333fb096cb311eb98a5cbc3 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == 524271645ddc drm/i915/dp: Avoid concurrent access when HW is using aux ch 87008545c0f1 drm/i915/dp: Improve intel_dp_aux_is_busy() 5a9cc41f7e89 drm/i915/dp: Move code to check if aux ch is busy to a function 16a97441a986 drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side e463ec258771 drm/i915/psr: Handle PSR RFB storage error 440ab6965b08 drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink 0a466f97bd5a drm/i915/psr: Remove intel_crtc_state parameter from disable() f0dbcdf6 drm/i915/psr: Move PSR exit specific code to hardware specific function 9dc8e92b44ac drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8743/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 series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
== Series Details == Series: series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function URL : https://patchwork.freedesktop.org/series/41923/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function Okay! Commit: drm/i915/psr: Move PSR exit specific code to hardware specific function -drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression using sizeof(void) Commit: drm/i915/psr: Remove intel_crtc_state parameter from disable() -drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression using sizeof(void) Commit: drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink Okay! Commit: drm/i915/psr: Handle PSR RFB storage error Okay! Commit: drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side Okay! Commit: drm/i915/dp: Move code to check if aux ch is busy to a function Okay! Commit: drm/i915/dp: Improve intel_dp_aux_is_busy() Okay! Commit: drm/i915/dp: Avoid concurrent access when HW is using aux ch Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
== Series Details == Series: series starting with [v2,1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function URL : https://patchwork.freedesktop.org/series/41923/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9dc8e92b44ac drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function f0dbcdf6 drm/i915/psr: Move PSR exit specific code to hardware specific function 0a466f97bd5a drm/i915/psr: Remove intel_crtc_state parameter from disable() 440ab6965b08 drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink -:54: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line #54: FILE: drivers/gpu/drm/i915/intel_psr.c:1002: + if (dev_priv->psr.active || dev_priv->psr.busy_frontbuffer_bits + || work_busy(&dev_priv->psr.work.work)) total: 0 errors, 0 warnings, 1 checks, 78 lines checked e463ec258771 drm/i915/psr: Handle PSR RFB storage error 16a97441a986 drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side -:32: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #32: FILE: drivers/gpu/drm/i915/i915_reg.h:4019: +#define EDP_PSR_CRC_ENABLE (1<<10) /* BDW+ */ ^ total: 0 errors, 0 warnings, 1 checks, 60 lines checked 5a9cc41f7e89 drm/i915/dp: Move code to check if aux ch is busy to a function -:41: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.txt #41: FILE: drivers/gpu/drm/i915/intel_dp.c:1080: + msleep(1); total: 0 errors, 1 warnings, 0 checks, 70 lines checked 87008545c0f1 drm/i915/dp: Improve intel_dp_aux_is_busy() 524271645ddc drm/i915/dp: Avoid concurrent access when HW is using aux ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/9] drm/i915/psr: Move PSR exit specific code to hardware specific function
To proper execute PSR exit it was using 'if (HAS_DDI(dev_priv))' to differentiate between VLV/CHV and HSW+ hardware, so here moving each hardware handling to his own function. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi --- No changes from v1. drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_psr.c | 94 +++- 2 files changed, 56 insertions(+), 39 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 8e8667d9b084..476bca872d48 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -617,6 +617,7 @@ struct i915_psr { void (*enable_sink)(struct intel_dp *); void (*activate)(struct intel_dp *); void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *); + void (*exit)(struct intel_dp *intel_dp); }; enum intel_pch { diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 659180656f5b..ebc47e2b08ca 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -844,53 +844,67 @@ static void intel_psr_work(struct work_struct *work) mutex_unlock(&dev_priv->psr.lock); } -static void intel_psr_exit(struct drm_i915_private *dev_priv) +static void hsw_psr_exit(struct intel_dp *intel_dp) { - struct intel_dp *intel_dp = dev_priv->psr.enabled; - struct drm_crtc *crtc = dp_to_dig_port(intel_dp)->base.base.crtc; + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); + struct drm_device *dev = dig_port->base.base.dev; + struct drm_i915_private *dev_priv = to_i915(dev); + u32 val; + + if (dev_priv->psr.psr2_enabled) { + val = I915_READ(EDP_PSR2_CTL); + WARN_ON(!(val & EDP_PSR2_ENABLE)); + I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE); + } else { + val = I915_READ(EDP_PSR_CTL); + WARN_ON(!(val & EDP_PSR_ENABLE)); + I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE); + } +} + +static void vlv_psr_exit(struct intel_dp *intel_dp) +{ + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); + struct drm_device *dev = dig_port->base.base.dev; + struct drm_i915_private *dev_priv = to_i915(dev); + struct drm_crtc *crtc = dig_port->base.base.crtc; enum pipe pipe = to_intel_crtc(crtc)->pipe; u32 val; - if (!dev_priv->psr.active) - return; + val = I915_READ(VLV_PSRCTL(pipe)); - if (HAS_DDI(dev_priv)) { - if (dev_priv->psr.psr2_enabled) { - val = I915_READ(EDP_PSR2_CTL); - WARN_ON(!(val & EDP_PSR2_ENABLE)); - I915_WRITE(EDP_PSR2_CTL, val & ~EDP_PSR2_ENABLE); - } else { - val = I915_READ(EDP_PSR_CTL); - WARN_ON(!(val & EDP_PSR_ENABLE)); - I915_WRITE(EDP_PSR_CTL, val & ~EDP_PSR_ENABLE); - } - } else { - val = I915_READ(VLV_PSRCTL(pipe)); + /* +* Here we do the transition drirectly from +* PSR_state 3 (active - no Remote Frame Buffer (RFB) update) to +* PSR_state 5 (exit). +* PSR State 4 (active with single frame update) can be skipped. +* On PSR_state 5 (exit) Hardware is responsible to transition +* back to PSR_state 1 (inactive). +* Now we are at Same state after vlv_psr_enable_source. +*/ + val &= ~VLV_EDP_PSR_ACTIVE_ENTRY; + I915_WRITE(VLV_PSRCTL(pipe), val); - /* -* Here we do the transition drirectly from -* PSR_state 3 (active - no Remote Frame Buffer (RFB) update) to -* PSR_state 5 (exit). -* PSR State 4 (active with single frame update) can be skipped. -* On PSR_state 5 (exit) Hardware is responsible to transition -* back to PSR_state 1 (inactive). -* Now we are at Same state after vlv_psr_enable_source. -*/ - val &= ~VLV_EDP_PSR_ACTIVE_ENTRY; - I915_WRITE(VLV_PSRCTL(pipe), val); + /* +* Send AUX wake up - Spec says after transitioning to PSR +* active we have to send AUX wake up by writing 01h in DPCD +* 600h of sink device. +* XXX: This might slow down the transition, but without this +* HW doesn't complete the transition to PSR_state 1 and we +* never get the screen updated. +*/ + drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, + DP_SET_POWER_D0); +} - /* -* Send AUX wake up - Spec says after transitioning to PSR -* active we have to send AUX wake up by writing 01h in DPCD -* 600h of sink device. -* XXX: This m
[Intel-gfx] [PATCH v2 7/9] drm/i915/dp: Move code to check if aux ch is busy to a function
This reduces the spaghetti that intel_dp_aux_xfer(). Moved doing less changes possible here, improvements to the new function in further patch. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan --- New patch in this series. drivers/gpu/drm/i915/intel_dp.c | 52 + 1 file changed, 34 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 701963a192ee..a11465c62950 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1062,6 +1062,38 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp *intel_dp, DP_AUX_CH_CTL_SYNC_PULSE_SKL(32); } +static bool intel_dp_aux_is_busy(struct intel_dp *intel_dp) +{ + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); + struct drm_i915_private *dev_priv = + to_i915(intel_dig_port->base.base.dev); + i915_reg_t ch_ctl; + uint32_t status; + int try; + + ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp); + + for (try = 0; try < 3; try++) { + status = I915_READ_NOTRACE(ch_ctl); + if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0) + break; + msleep(1); + } + + if (try == 3) { + static u32 last_status = -1; + const u32 status = I915_READ(ch_ctl); + + if (status != last_status) { + WARN(1, "dp_aux_ch not started status 0x%08x\n", +status); + last_status = status; + } + } + + return true; +} + static int intel_dp_aux_xfer(struct intel_dp *intel_dp, const uint8_t *send, int send_bytes, @@ -1074,7 +1106,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp, i915_reg_t ch_ctl, ch_data[5]; uint32_t aux_clock_divider; int i, ret, recv_bytes; - uint32_t status; + uint32_t status = 0; int try, clock = 0; bool has_aux_irq = HAS_AUX_IRQ(dev_priv); bool vdd; @@ -1102,23 +1134,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp, intel_dp_check_edp(intel_dp); /* Try to wait for any previous AUX channel activity */ - for (try = 0; try < 3; try++) { - status = I915_READ_NOTRACE(ch_ctl); - if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0) - break; - msleep(1); - } - - if (try == 3) { - static u32 last_status = -1; - const u32 status = I915_READ(ch_ctl); - - if (status != last_status) { - WARN(1, "dp_aux_ch not started status 0x%08x\n", -status); - last_status = status; - } - + if (intel_dp_aux_is_busy(intel_dp)) { ret = -EBUSY; goto out; } -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/9] drm/i915/psr: Handle PSR RFB storage error
Sink will interrupt source when it have any problem saving or reading the remote frame buffer. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi --- Changes from v1: - printing a debug message when sink assert a error drivers/gpu/drm/i915/intel_psr.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 4cb27faab707..558b08a43f9e 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -1156,6 +1156,18 @@ void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp) intel_psr_exit(dev_priv); } + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_ERROR_STATUS, &val) != 1) { + DRM_DEBUG_KMS("PSR_ERROR_STATUS read failed\n"); + goto dpcd_error; + } + + if (val & DP_PSR_RFB_STORAGE_ERROR) { + DRM_DEBUG_KMS("PSR RFB storage error, exiting PSR\n"); + intel_psr_exit(dev_priv); + } + /* clear status register */ + drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_ERROR_STATUS, val); + /* TODO: handle other PSR/PSR2 errors */ dpcd_error: intel_psr_schedule_activate_work(dev_priv); -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/9] drm/i915/psr: Remove intel_crtc_state parameter from disable()
It is only used by VLV/CHV and we can get this information from intel_dp for those platforms. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi Cc: Lucas De Marchi Cc: Ville Syrjälä --- Changes from v1: - not using legacy drm_crtc pointer(struct drm_crtc *crtc = intel_dig_port->base.base.crtc) drivers/gpu/drm/i915/i915_drv.h | 3 +-- drivers/gpu/drm/i915/intel_psr.c | 17 +++-- 2 files changed, 8 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 476bca872d48..f5ffb3d72cef 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -612,8 +612,7 @@ struct i915_psr { void (*enable_source)(struct intel_dp *, const struct intel_crtc_state *); - void (*disable_source)(struct intel_dp *, - const struct intel_crtc_state *); + void (*disable_source)(struct intel_dp *intel_dp); void (*enable_sink)(struct intel_dp *); void (*activate)(struct intel_dp *); void (*setup_vsc)(struct intel_dp *, const struct intel_crtc_state *); diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index ebc47e2b08ca..934498505356 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -665,38 +665,35 @@ void intel_psr_enable(struct intel_dp *intel_dp, mutex_unlock(&dev_priv->psr.lock); } -static void vlv_psr_disable(struct intel_dp *intel_dp, - const struct intel_crtc_state *old_crtc_state) +static void vlv_psr_disable(struct intel_dp *intel_dp) { struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); struct drm_device *dev = intel_dig_port->base.base.dev; struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc); uint32_t val; if (dev_priv->psr.active) { /* Put VLV PSR back to PSR_state 0 (disabled). */ if (intel_wait_for_register(dev_priv, - VLV_PSRSTAT(crtc->pipe), + VLV_PSRSTAT(intel_dp->active_pipe), VLV_EDP_PSR_IN_TRANS, 0, 1)) WARN(1, "PSR transition took longer than expected\n"); - val = I915_READ(VLV_PSRCTL(crtc->pipe)); + val = I915_READ(VLV_PSRCTL(intel_dp->active_pipe)); val &= ~VLV_EDP_PSR_ACTIVE_ENTRY; val &= ~VLV_EDP_PSR_ENABLE; val &= ~VLV_EDP_PSR_MODE_MASK; - I915_WRITE(VLV_PSRCTL(crtc->pipe), val); + I915_WRITE(VLV_PSRCTL(intel_dp->active_pipe), val); dev_priv->psr.active = false; } else { - WARN_ON(vlv_is_psr_active_on_pipe(dev, crtc->pipe)); + WARN_ON(vlv_is_psr_active_on_pipe(dev, intel_dp->active_pipe)); } } -static void hsw_psr_disable(struct intel_dp *intel_dp, - const struct intel_crtc_state *old_crtc_state) +static void hsw_psr_disable(struct intel_dp *intel_dp) { struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); struct drm_device *dev = intel_dig_port->base.base.dev; @@ -765,7 +762,7 @@ void intel_psr_disable(struct intel_dp *intel_dp, return; } - dev_priv->psr.disable_source(intel_dp, old_crtc_state); + dev_priv->psr.disable_source(intel_dp); /* Disable PSR on Sink */ drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, 0); -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 8/9] drm/i915/dp: Improve intel_dp_aux_is_busy()
- Doing earlier return when not busy - using u32 instead of uint32_t - counting from 3 to 0 as it is is the most common in the driver - using DRM_WARN() instead of WARN() - adding aux port name to the debug message - nuking last_status, it is one static variable to all DP ports also 2 different aux transactions with the same message size would have the same ch_ctl value, if really desired to reduce the number of debug messages it should be implemented a per aux ch last_status - no need to sleep in the last try - sleeping for 1 aux ch transaction time Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan --- New patch in this series. drivers/gpu/drm/i915/intel_dp.c | 23 --- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index a11465c62950..258e23961456 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1068,28 +1068,21 @@ static bool intel_dp_aux_is_busy(struct intel_dp *intel_dp) struct drm_i915_private *dev_priv = to_i915(intel_dig_port->base.base.dev); i915_reg_t ch_ctl; - uint32_t status; - int try; + u32 status; + unsigned int try; ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp); - for (try = 0; try < 3; try++) { + for (try = 3; try; try--) { status = I915_READ_NOTRACE(ch_ctl); if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0) - break; - msleep(1); + return false; + if (try > 1) + usleep_range(400, 500); } - if (try == 3) { - static u32 last_status = -1; - const u32 status = I915_READ(ch_ctl); - - if (status != last_status) { - WARN(1, "dp_aux_ch not started status 0x%08x\n", -status); - last_status = status; - } - } + DRM_WARN("DP aux %c is busy 0x%08x\n", +aux_ch_name(intel_dp->aux_ch), status); return true; } -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 9/9] drm/i915/dp: Avoid concurrent access when HW is using aux ch
This will avoid some cases of concurrent access to aux ch registers when hardware is using it(HW uses it when PSR, GTC and aux frame is enabled). It is just first step to see if this scenario happens, if so it will be properly handled as described in bspec. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan --- New patch in this series, this is replacing to the patches in this series that was exiting PSR before a aux transaction. As discussed with Dhinakaran, let's check first if this scenary happens if so I will bring those patches back. drivers/gpu/drm/i915/intel_dp.c | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 258e23961456..74abd4cd93dd 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1062,7 +1062,7 @@ static uint32_t skl_get_aux_send_ctl(struct intel_dp *intel_dp, DP_AUX_CH_CTL_SYNC_PULSE_SKL(32); } -static bool intel_dp_aux_is_busy(struct intel_dp *intel_dp) +static bool intel_dp_aux_is_busy(struct intel_dp *intel_dp, unsigned int tries) { struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); struct drm_i915_private *dev_priv = @@ -1073,7 +1073,7 @@ static bool intel_dp_aux_is_busy(struct intel_dp *intel_dp) ch_ctl = intel_dp->aux_ch_ctl_reg(intel_dp); - for (try = 3; try; try--) { + for (try = tries; try; try--) { status = I915_READ_NOTRACE(ch_ctl); if ((status & DP_AUX_CH_CTL_SEND_BUSY) == 0) return false; @@ -1127,7 +1127,7 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp, intel_dp_check_edp(intel_dp); /* Try to wait for any previous AUX channel activity */ - if (intel_dp_aux_is_busy(intel_dp)) { + if (intel_dp_aux_is_busy(intel_dp, 3)) { ret = -EBUSY; goto out; } @@ -1148,6 +1148,18 @@ intel_dp_aux_xfer(struct intel_dp *intel_dp, /* Must try at least 3 times according to DP spec */ for (try = 0; try < 5; try++) { + /* WA: try to avoid concurrent access to aux ch +* registers while hardware is using it, the other +* way is not handled at all. +*/ + if (intel_dp_aux_is_busy(intel_dp, 1)) { + DRM_ERROR("Aux ch %c is busy, hw is using it", + aux_ch_name(intel_dp->aux_ch)); + /* sleep for a transaction time */ + usleep_range(400, 500); + continue; + } + /* Load the send data into the aux channel data registers */ for (i = 0; i < send_bytes; i += 4) I915_WRITE(ch_data[i >> 2], -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/9] drm/i915/psr: Begin to handle PSR/PSR2 errors set by sink
eDP spec states that sink device will do a short pulse in HPD line when there is a PSR/PSR2 error that needs to be handled by source, this is handling the first and most simples error: DP_PSR_SINK_INTERNAL_ERROR. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi --- Changes from v1: - printing a debug message when sink assert a error drivers/gpu/drm/i915/intel_dp.c | 2 ++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_psr.c | 48 +--- 3 files changed, 47 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 62f82c4298ac..701963a192ee 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4462,6 +4462,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp) if (intel_dp_needs_link_retrain(intel_dp)) return false; + intel_psr_hpd_short_pulse_handle(intel_dp); + if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) { DRM_DEBUG_KMS("Link Training Compliance Test requested\n"); /* Send a Hotplug Uevent to userspace to start modeset */ diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index 5bd2263407b2..b79e15ecd052 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -1901,6 +1901,7 @@ void intel_psr_single_frame_update(struct drm_i915_private *dev_priv, unsigned frontbuffer_bits); void intel_psr_compute_config(struct intel_dp *intel_dp, struct intel_crtc_state *crtc_state); +void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp); /* intel_runtime_pm.c */ int intel_power_domains_init(struct drm_i915_private *); diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 934498505356..4cb27faab707 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -996,6 +996,15 @@ void intel_psr_invalidate(struct drm_i915_private *dev_priv, mutex_unlock(&dev_priv->psr.lock); } +static void intel_psr_schedule_activate_work(struct drm_i915_private *dev_priv) +{ + if (dev_priv->psr.active || dev_priv->psr.busy_frontbuffer_bits + || work_busy(&dev_priv->psr.work.work)) + return; + + schedule_delayed_work(&dev_priv->psr.work, msecs_to_jiffies(100)); +} + /** * intel_psr_flush - Flush PSR * @dev_priv: i915 device @@ -1052,10 +1061,8 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, } } - if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits) - if (!work_busy(&dev_priv->psr.work.work)) - schedule_delayed_work(&dev_priv->psr.work, - msecs_to_jiffies(100)); + intel_psr_schedule_activate_work(dev_priv); + mutex_unlock(&dev_priv->psr.lock); } @@ -1122,3 +1129,36 @@ void intel_psr_init(struct drm_i915_private *dev_priv) dev_priv->psr.exit = hsw_psr_exit; } } + +void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp) +{ + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); + struct drm_device *dev = intel_dig_port->base.base.dev; + struct drm_i915_private *dev_priv = to_i915(dev); + struct i915_psr *psr = &dev_priv->psr; + uint8_t val; + + if (!HAS_PSR(dev_priv) || !intel_dp_is_edp(intel_dp)) + return; + + mutex_lock(&psr->lock); + + if (psr->enabled != intel_dp) + goto not_enabled; + + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_STATUS, &val) != 1) { + DRM_DEBUG_KMS("PSR_STATUS read failed\n"); + goto dpcd_error; + } + + if ((val & DP_PSR_SINK_STATE_MASK) == DP_PSR_SINK_INTERNAL_ERROR) { + DRM_DEBUG_KMS("PSR sink internal error, exiting PSR\n"); + intel_psr_exit(dev_priv); + } + + /* TODO: handle other PSR/PSR2 errors */ +dpcd_error: + intel_psr_schedule_activate_work(dev_priv); +not_enabled: + mutex_unlock(&psr->lock); +} -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/9] drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side
Sink can be configured to calculate the CRC over the static frame and compare with the CRC calculated and transmited in the VSC SDP by source, if there is a mismatch sink will do a short pulse in HPD and set DP_PSR_LINK_CRC_ERROR on DP_PSR_ERROR_STATUS. Also spec recommends to disable MAX_SLEEP as a trigger to exit PSR when CRC check is enabled to improve power savings. Spec: 7723 Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi --- Changes from v1: - printing a debug message when sink assert a error drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_psr.c | 24 +--- 2 files changed, 18 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index fb106026a1f4..d3efbd654889 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4016,6 +4016,7 @@ enum { #define EDP_PSR_SKIP_AUX_EXIT(1<<12) #define EDP_PSR_TP1_TP2_SEL (0<<11) #define EDP_PSR_TP1_TP3_SEL (1<<11) +#define EDP_PSR_CRC_ENABLE (1<<10) /* BDW+ */ #define EDP_PSR_TP2_TP3_TIME_500us (0<<8) #define EDP_PSR_TP2_TP3_TIME_100us (1<<8) #define EDP_PSR_TP2_TP3_TIME_2500us (2<<8) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 558b08a43f9e..1920e7d03e06 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -290,6 +290,8 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp) dpcd_val |= DP_PSR_ENABLE_PSR2; if (dev_priv->psr.link_standby) dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE; + if (!dev_priv->psr.psr2_enabled && INTEL_GEN(dev_priv) >= 8) + dpcd_val |= DP_PSR_CRC_VERIFICATION; drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, dpcd_val); drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0); @@ -377,6 +379,9 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp) else val |= EDP_PSR_TP1_TP2_SEL; + if (INTEL_GEN(dev_priv) >= 8) + val |= EDP_PSR_CRC_ENABLE; + val |= I915_READ(EDP_PSR_CTL) & EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK; I915_WRITE(EDP_PSR_CTL, val); } @@ -602,10 +607,12 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp, * preventing other hw tracking issues now we can rely * on frontbuffer tracking. */ - I915_WRITE(EDP_PSR_DEBUG, - EDP_PSR_DEBUG_MASK_MEMUP | - EDP_PSR_DEBUG_MASK_HPD | - EDP_PSR_DEBUG_MASK_LPSP); + u32 val = EDP_PSR_DEBUG_MASK_MEMUP | EDP_PSR_DEBUG_MASK_HPD + | EDP_PSR_DEBUG_MASK_LPSP; + + if (INTEL_GEN(dev_priv) >= 8) + val |= EDP_PSR_DEBUG_MASK_MAX_SLEEP; + I915_WRITE(EDP_PSR_DEBUG, val); } } @@ -1161,14 +1168,17 @@ void intel_psr_hpd_short_pulse_handle(struct intel_dp *intel_dp) goto dpcd_error; } - if (val & DP_PSR_RFB_STORAGE_ERROR) { - DRM_DEBUG_KMS("PSR RFB storage error, exiting PSR\n"); + if (val & (DP_PSR_RFB_STORAGE_ERROR | DP_PSR_LINK_CRC_ERROR)) { + if (val & DP_PSR_RFB_STORAGE_ERROR) + DRM_DEBUG_KMS("PSR RFB storage error, exiting PSR\n"); + if (val & DP_PSR_LINK_CRC_ERROR) + DRM_DEBUG_KMS("PSR Link CRC error, exiting PSR\n"); intel_psr_exit(dev_priv); } /* clear status register */ drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_ERROR_STATUS, val); - /* TODO: handle other PSR/PSR2 errors */ + /* TODO: handle PSR2 errors */ dpcd_error: intel_psr_schedule_activate_work(dev_priv); not_enabled: -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/9] drm/i915/psr: Move specific HSW+ WARN_ON to HSW+ function
It was reading some random register in VLV and CHV. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi --- No changes from v1. drivers/gpu/drm/i915/intel_psr.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 69a5b276f4d8..659180656f5b 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -424,6 +424,11 @@ static void hsw_psr_activate(struct intel_dp *intel_dp) struct drm_device *dev = dig_port->base.base.dev; struct drm_i915_private *dev_priv = to_i915(dev); + if (dev_priv->psr.psr2_enabled) + WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE); + else + WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE); + /* On HSW+ after we enable PSR on source it will activate it * as soon as it match configure idle_frame count. So * we just actually enable it here on activation time. @@ -549,10 +554,6 @@ static void intel_psr_activate(struct intel_dp *intel_dp) struct drm_device *dev = intel_dig_port->base.base.dev; struct drm_i915_private *dev_priv = to_i915(dev); - if (dev_priv->psr.psr2_enabled) - WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE); - else - WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE); WARN_ON(dev_priv->psr.active); lockdep_assert_held(&dev_priv->psr.lock); -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v11,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev16)
== Series Details == Series: series starting with [v11,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev16) URL : https://patchwork.freedesktop.org/series/40503/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8742 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8742 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8742, 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/40503/revisions/16/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8742: === IGT changes === Possible regressions igt@debugfs_test@read_all_entries: fi-cfl-u: PASS -> DMESG-WARN fi-cfl-s3: PASS -> DMESG-WARN fi-skl-6260u: PASS -> DMESG-WARN fi-skl-gvtdvm: PASS -> DMESG-WARN fi-bdw-gvtdvm: PASS -> DMESG-WARN fi-bxt-j4205: PASS -> DMESG-WARN fi-kbl-7500u: PASS -> DMESG-WARN fi-bdw-5557u: PASS -> DMESG-WARN fi-kbl-r: PASS -> DMESG-WARN fi-skl-guc: PASS -> DMESG-WARN fi-kbl-7567u: PASS -> DMESG-WARN fi-glk-j4005: NOTRUN -> DMESG-WARN fi-skl-6600u: PASS -> DMESG-WARN fi-bxt-dsi: NOTRUN -> DMESG-WARN fi-cfl-8700k: PASS -> DMESG-WARN fi-bsw-n3050: PASS -> DMESG-WARN fi-skl-6700k2: PASS -> DMESG-WARN fi-skl-6770hq: PASS -> DMESG-WARN igt@gem_ringfill@basic-default-hang: fi-cnl-y3: PASS -> DMESG-WARN == Known issues == Here are the changes found in Patchwork_8742 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (33 -> 31) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8742 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8742: 9960162c61d7419eb49300fa91164e0f5e32898b @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == 9960162c61d7 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads 0f9b8e8c4c75 drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8742/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v4,1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes
== Series Details == Series: series starting with [v4,1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes URL : https://patchwork.freedesktop.org/series/41909/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8739_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8739_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8739_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41909/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8739_full: === IGT changes === Possible regressions igt@kms_frontbuffer_tracking@fbc-suspend: shard-kbl: PASS -> DMESG-WARN +3 igt@perf@gen8-unprivileged-single-ctx-counters: shard-kbl: PASS -> FAIL +1 shard-apl: PASS -> FAIL Warnings igt@drv_missed_irq: shard-apl: PASS -> SKIP igt@gem_mocs_settings@mocs-rc6-dirty-render: shard-kbl: SKIP -> PASS +2 igt@prime_vgem@sync-bsd2: shard-kbl: PASS -> SKIP +31 == Known issues == Here are the changes found in Patchwork_8739_full that come from known issues: === IGT changes === Issues hit igt@gem_eio@execbuf: shard-apl: PASS -> INCOMPLETE (fdo#103927) +1 igt@kms_flip@2x-wf_vblank-ts-check: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@modeset-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) +1 igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) igt@prime_busy@wait-hang-vebox: shard-kbl: PASS -> INCOMPLETE (fdo#103665) +4 Possible fixes igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-farfromfence: shard-kbl: DMESG-WARN (fdo#105602, fdo#103558) -> PASS +1 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#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8739 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8739: f6e5a01f3c8931f5b6420e877f8a8e596821926f @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8739/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v11,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev16)
== Series Details == Series: series starting with [v11,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev16) URL : https://patchwork.freedesktop.org/series/40503/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0f9b8e8c4c75 drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads -:63: CHECK:LINE_SPACING: Please don't use multiple blank lines #63: FILE: drivers/gpu/drm/i915/intel_device_info.c:722: + total: 0 errors, 0 warnings, 1 checks, 90 lines checked 9960162c61d7 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads -:47: WARNING:BAD_SIGN_OFF: Duplicate signature #47: Reviewed-by: Oscar Mateo total: 0 errors, 1 warnings, 0 checks, 50 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v11 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 4/18/2018 3:01 PM, Yunwei Zhang wrote: WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each subsequent MMIO read will be forwarded to a specific slice/subslice combination as read is unicast. This is OK since slice/subslice specific register values are consistent in almost all cases across slice/subslice. There are rare occasions such as INSTDONE that this value will be dependent on slice/subslice combo, in such cases, we need to program 0xFDC and recover this after. This is already covered by read_subslice_reg. Also, 0xFDC will lose its information after TDR/engine reset/power state change. References: HSD#1405586840, BSID#0575 v2: - use fls() instead of find_last_bit() (Chris) - added INTEL_SSEU to extract sseu from device info. (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Change the ordered of passing arguments and etc. (Ursulin) v7: - Rebased. v8: - Reviewed by Oscar - Store default MCR value instead of calculate on the run. (Oscar) v9: - Changed naming and label fixes. (Oscar) - Store only the selector instead of whole MCR. (Oscar) v10: - Improved comments, naming and line breaknig. (Oscar) v11: - Moved the comment to most relavent block. (Oscar) Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Yunwei Zhang Reviewed-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_device_info.c | 47 drivers/gpu/drm/i915/intel_device_info.h | 3 ++ drivers/gpu/drm/i915/intel_engine_cs.c | 10 +++ 3 files changed, 55 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index a32ba72..ea62d45 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -719,6 +719,51 @@ static u32 read_timestamp_frequency(struct drm_i915_private *dev_priv) return 0; } + +static void sanitize_mcr(struct intel_device_info *info) +{ + struct drm_i915_private *dev_priv = + container_of(info, struct drm_i915_private, info); + u32 mcr; + u32 mcr_slice_subslice_mask; + u32 mcr_slice_subslice_select; + u32 slice = fls(info->sseu.slice_mask); + u32 subslice = fls(info->sseu.subslice_mask[slice]); + + if (INTEL_GEN(dev_priv) >= 11) { + mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | + GEN11_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) | + GEN11_MCR_SUBSLICE(subslice); + } else { + mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK | + GEN8_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) | + GEN8_MCR_SUBSLICE(subslice); + } + + mcr = I915_READ(GEN8_MCR_SELECTOR); + mcr &= ~mcr_slice_subslice_mask; + + /* +* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl +* Before any MMIO read into slice/subslice specific registers, MCR +* packet control register needs to be programmed to point to any +* enabled s/ss pair. Otherwise, incorrect values will be returned. +* This means each subsequent MMIO read will be forwarded to an +* specific s/ss combination, but this is OK since these registers +* are consistent across s/ss in almost all cases. In the rare +* occasions, such as INSTDONE, where this value is dependent +* on s/ss combo, the read should be done with read_subslice_reg. +*/ + if (INTEL_GEN(dev_priv) >= 10) + mcr |= mcr_slice_subslice_select; + + I915_WRITE(GEN8_MCR_SELECTOR, mcr); + + info->default_mcr_s_ss_select = mcr_slice_subslice_select; Sorry: forget my r-b, this is broken. For GENs that do not need the WA, info->default_mcr_s_ss_select should be 0 +} + /** * intel_device_info_runtime_init - initialize runtime info * @info: intel device info struct @@ -851,6 +896,8 @@ void intel_device_info_runtime_init(struct intel_device_info *info) else if (INTEL_INFO(dev_priv)->gen >= 11) gen11_sseu_info_init(dev_priv); + sanitize_mcr(info); + /* Initialize command stream timestamp frequency */ info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv); } diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index 933e316..2feccee 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_inf
[Intel-gfx] [PATCH v11 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each subsequent MMIO read will be forwarded to a specific slice/subslice combination as read is unicast. This is OK since slice/subslice specific register values are consistent in almost all cases across slice/subslice. There are rare occasions such as INSTDONE that this value will be dependent on slice/subslice combo, in such cases, we need to program 0xFDC and recover this after. This is already covered by read_subslice_reg. Also, 0xFDC will lose its information after TDR/engine reset/power state change. References: HSD#1405586840, BSID#0575 v2: - use fls() instead of find_last_bit() (Chris) - added INTEL_SSEU to extract sseu from device info. (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Change the ordered of passing arguments and etc. (Ursulin) v7: - Rebased. v8: - Reviewed by Oscar - Store default MCR value instead of calculate on the run. (Oscar) v9: - Changed naming and label fixes. (Oscar) - Store only the selector instead of whole MCR. (Oscar) v10: - Improved comments, naming and line breaknig. (Oscar) v11: - Moved the comment to most relavent block. (Oscar) Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Yunwei Zhang Reviewed-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_device_info.c | 47 drivers/gpu/drm/i915/intel_device_info.h | 3 ++ drivers/gpu/drm/i915/intel_engine_cs.c | 10 +++ 3 files changed, 55 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index a32ba72..ea62d45 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -719,6 +719,51 @@ static u32 read_timestamp_frequency(struct drm_i915_private *dev_priv) return 0; } + +static void sanitize_mcr(struct intel_device_info *info) +{ + struct drm_i915_private *dev_priv = + container_of(info, struct drm_i915_private, info); + u32 mcr; + u32 mcr_slice_subslice_mask; + u32 mcr_slice_subslice_select; + u32 slice = fls(info->sseu.slice_mask); + u32 subslice = fls(info->sseu.subslice_mask[slice]); + + if (INTEL_GEN(dev_priv) >= 11) { + mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | + GEN11_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) | + GEN11_MCR_SUBSLICE(subslice); + } else { + mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK | + GEN8_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) | + GEN8_MCR_SUBSLICE(subslice); + } + + mcr = I915_READ(GEN8_MCR_SELECTOR); + mcr &= ~mcr_slice_subslice_mask; + + /* +* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl +* Before any MMIO read into slice/subslice specific registers, MCR +* packet control register needs to be programmed to point to any +* enabled s/ss pair. Otherwise, incorrect values will be returned. +* This means each subsequent MMIO read will be forwarded to an +* specific s/ss combination, but this is OK since these registers +* are consistent across s/ss in almost all cases. In the rare +* occasions, such as INSTDONE, where this value is dependent +* on s/ss combo, the read should be done with read_subslice_reg. +*/ + if (INTEL_GEN(dev_priv) >= 10) + mcr |= mcr_slice_subslice_select; + + I915_WRITE(GEN8_MCR_SELECTOR, mcr); + + info->default_mcr_s_ss_select = mcr_slice_subslice_select; +} + /** * intel_device_info_runtime_init - initialize runtime info * @info: intel device info struct @@ -851,6 +896,8 @@ void intel_device_info_runtime_init(struct intel_device_info *info) else if (INTEL_INFO(dev_priv)->gen >= 11) gen11_sseu_info_init(dev_priv); + sanitize_mcr(info); + /* Initialize command stream timestamp frequency */ info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv); } diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index 933e316..2feccee 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -176,6 +176,9 @@ struct intel_device_info { /* Slice/subslice/EU info */ struct sseu_dev_info sseu; + /* default selected slice/subslice in MCR packet con
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/crc: Only report a single overflow when a CRC fd is opened
== Series Details == Series: drm/crc: Only report a single overflow when a CRC fd is opened URL : https://patchwork.freedesktop.org/series/41897/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8737_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8737_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8737_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41897/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8737_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: PASS -> SKIP igt@perf_pmu@rc6: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_8737_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: PASS -> FAIL (fdo#102887) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_suspend@forcewake: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-farfromfence: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +2 igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 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#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8737 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8737: e17f1c739f3f4bfe59ec5192330fdea1e109ea34 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8737/shards.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 gpu: drm: i915: Change return type to vm_fault_t (rev2)
== Series Details == Series: gpu: drm: i915: Change return type to vm_fault_t (rev2) URL : https://patchwork.freedesktop.org/series/41893/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8736_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8736_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8736_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41893/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8736_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-bsd1: shard-kbl: PASS -> SKIP +1 igt@gem_mocs_settings@mocs-rc6-bsd2: shard-kbl: SKIP -> PASS igt@kms_vblank@pipe-a-query-forked-busy: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8736_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@plain-flip-ts-check: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-farfromfence: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +2 igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 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#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8736 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8736: 045e647f1204c28a28882560da315568d838e3ea @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8736/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v10,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev15)
== Series Details == Series: series starting with [v10,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev15) URL : https://patchwork.freedesktop.org/series/40503/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8741 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8741 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8741, 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/40503/revisions/15/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8741: === IGT changes === Possible regressions igt@debugfs_test@read_all_entries: fi-cfl-u: PASS -> DMESG-WARN fi-cfl-s3: PASS -> DMESG-WARN fi-skl-6260u: PASS -> DMESG-WARN fi-skl-gvtdvm: PASS -> DMESG-WARN fi-bdw-gvtdvm: PASS -> DMESG-WARN fi-bxt-j4205: PASS -> DMESG-WARN fi-kbl-7500u: PASS -> DMESG-WARN fi-bdw-5557u: PASS -> DMESG-WARN fi-kbl-r: PASS -> DMESG-WARN fi-skl-guc: PASS -> DMESG-WARN fi-kbl-7567u: PASS -> DMESG-WARN fi-glk-j4005: NOTRUN -> DMESG-WARN fi-skl-6600u: PASS -> DMESG-WARN fi-bxt-dsi: NOTRUN -> DMESG-WARN fi-cfl-8700k: PASS -> DMESG-WARN fi-bsw-n3050: PASS -> DMESG-WARN fi-skl-6700k2: PASS -> DMESG-WARN fi-skl-6770hq: PASS -> DMESG-WARN igt@gem_ringfill@basic-default-hang: fi-cnl-y3: PASS -> DMESG-WARN == Known issues == Here are the changes found in Patchwork_8741 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) fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) +1 Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (33 -> 31) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8741 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8741: c243c40dcab2358a6001f5edf03bb78a66f2e8cc @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == c243c40dcab2 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads 4d91b554a00a drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8741/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
On 4/18/2018 1:23 PM, Yunwei Zhang wrote: L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0 instead of correct values. However, this is not going to be the case in any production silicon. Therefore, we only check at initialization and issue a warning should this really happen. References: HSDES#1405586840 v2: - use fls instead of find_last_bit (Chris) - use is_power_of_2() instead of counting bit set (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Move local variable into scope where they are used (Ursulin) - use a new local variable to reduce long line of code (Ursulin) v6: - Some coding style and use more local variables for clearer logic (Ursulin) v7: - Rebased. v8: - Reviewed by Oscar. v9: - Fixed label location. (Oscar) v10: - Improved comments and replaced magical number. (Oscar) Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Yunwei Zhang Reviewed-by: Oscar Mateo Re- Reviewed-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 4 drivers/gpu/drm/i915/intel_device_info.c | 34 2 files changed, 38 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index fb10602..6c9c01b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2709,6 +2709,10 @@ enum i915_power_well_id { #define GEN10_F2_SS_DIS_SHIFT 18 #define GEN10_F2_SS_DIS_MASK(0xf << GEN10_F2_SS_DIS_SHIFT) +#define GEN10_MIRROR_FUSE3 _MMIO(0x9118) +#define GEN10_L3BANK_PAIR_COUNT 4 +#define GEN10_L3BANK_MASK 0x0F + #define GEN8_EU_DISABLE0 _MMIO(0x9134) #define GEN8_EU_DIS0_S0_MASK0xff #define GEN8_EU_DIS0_S1_SHIFT 24 diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index 3791b52..a42842d 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -741,6 +741,40 @@ static void sanitize_mcr(struct intel_device_info *info) u32 slice = fls(info->sseu.slice_mask); u32 subslice = fls(info->sseu.subslice_mask[slice]); + /* +* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl +* L3Banks could be fused off in single slice scenario. If that is +* the case, we might need to program MCR select to a valid L3Bank +* by default, to make sure we correctly read certain registers +* later on (in the range 0xB100 - 0xB3FF). +* This might be incompatible with +* WaProgramMgsrForCorrectSliceSpecificMmioReads. +* Fortunately, this should not happen in production hardware, so +* we only assert that this is the case (instead of implementing +* something more complex that requires checking the range of every +* MMIO read). +*/ + if (INTEL_GEN(dev_priv) >= 10 && + is_power_of_2(info->sseu.slice_mask)) { + /* +* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches +* enabled subslice, no need to redirect MCR packet +*/ + u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3); + u8 ss_mask = info->sseu.subslice_mask[slice]; + + u8 enabled_mask = (ss_mask | ss_mask >> + GEN10_L3BANK_PAIR_COUNT) & + GEN10_L3BANK_MASK; + u8 disabled_mask = fuse3 & GEN10_L3BANK_MASK; + + /* +* Production silicon should have matched L3Bank and +* subslice enabled +*/ + WARN_ON((enabled_mask & disabled_mask) != enabled_mask); + } + if (INTEL_GEN(dev_priv) >= 11) { mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 4/18/2018 1:23 PM, Yunwei Zhang wrote: WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each subsequent MMIO read will be forwarded to a specific slice/subslice combination as read is unicast. This is OK since slice/subslice specific register values are consistent in almost all cases across slice/subslice. There are rare occasions such as INSTDONE that this value will be dependent on slice/subslice combo, in such cases, we need to program 0xFDC and recover this after. This is already covered by read_subslice_reg. Also, 0xFDC will lose its information after TDR/engine reset/power state change. References: HSD#1405586840, BSID#0575 v2: - use fls() instead of find_last_bit() (Chris) - added INTEL_SSEU to extract sseu from device info. (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Change the ordered of passing arguments and etc. (Ursulin) v7: - Rebased. v8: - Reviewed by Oscar - Store default MCR value instead of calculate on the run. (Oscar) v9: - Changed naming and label fixes. (Oscar) - Store only the selector instead of whole MCR. (Oscar) v10: - Improved comments, naming and line breaknig. (Oscar) Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Yunwei Zhang Reviewed-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_device_info.c | 48 drivers/gpu/drm/i915/intel_device_info.h | 3 ++ drivers/gpu/drm/i915/intel_engine_cs.c | 10 +++ 3 files changed, 56 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index a32ba72..3791b52 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -719,6 +719,52 @@ static u32 read_timestamp_frequency(struct drm_i915_private *dev_priv) return 0; } + +/* + * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl + * Before any MMIO read into slice/subslice specific registers, MCR + * packet control register needs to be programmed to point to any + * enabled s/ss pair. Otherwise, incorrect values will be returned. + * This means each subsequent MMIO read will be forwarded to an + * specific s/ss combination, but this is OK since these registers + * are consistent across s/ss in almost all cases. In the rare + * occasions, such as INSTDONE, where this value is dependent + * on s/ss combo, the read should be done with read_subslice_reg. + */ If you move the above comment block to the actual WA, which is: if (INTEL_GEN(dev_priv) >= 10) mcr |= mcr_slice_subslice_select; this patch is: Reviewed-by: Oscar Mateo this time for real :) +static void sanitize_mcr(struct intel_device_info *info) +{ + struct drm_i915_private *dev_priv = + container_of(info, struct drm_i915_private, info); + u32 mcr; + u32 mcr_slice_subslice_mask; + u32 mcr_slice_subslice_select; + u32 slice = fls(info->sseu.slice_mask); + u32 subslice = fls(info->sseu.subslice_mask[slice]); + + if (INTEL_GEN(dev_priv) >= 11) { + mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | + GEN11_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) | + GEN11_MCR_SUBSLICE(subslice); + } else { + mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK | + GEN8_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) | + GEN8_MCR_SUBSLICE(subslice); + } + + mcr = I915_READ(GEN8_MCR_SELECTOR); + mcr &= ~mcr_slice_subslice_mask; + + /* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl */ + if (INTEL_GEN(dev_priv) >= 10) + mcr |= mcr_slice_subslice_select; + + I915_WRITE(GEN8_MCR_SELECTOR, mcr); + + info->default_mcr_s_ss_select = mcr_slice_subslice_select; +} + /** * intel_device_info_runtime_init - initialize runtime info * @info: intel device info struct @@ -851,6 +897,8 @@ void intel_device_info_runtime_init(struct intel_device_info *info) else if (INTEL_INFO(dev_priv)->gen >= 11) gen11_sseu_info_init(dev_priv); + sanitize_mcr(info); + /* Initialize command stream timestamp frequency */ info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv); } diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index 933e316..2feccee 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v10,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev15)
== Series Details == Series: series starting with [v10,1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev15) URL : https://patchwork.freedesktop.org/series/40503/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4d91b554a00a drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads -:61: CHECK:LINE_SPACING: Please don't use multiple blank lines #61: FILE: drivers/gpu/drm/i915/intel_device_info.c:722: + total: 0 errors, 0 warnings, 1 checks, 91 lines checked c243c40dcab2 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0 instead of correct values. However, this is not going to be the case in any production silicon. Therefore, we only check at initialization and issue a warning should this really happen. References: HSDES#1405586840 v2: - use fls instead of find_last_bit (Chris) - use is_power_of_2() instead of counting bit set (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Move local variable into scope where they are used (Ursulin) - use a new local variable to reduce long line of code (Ursulin) v6: - Some coding style and use more local variables for clearer logic (Ursulin) v7: - Rebased. v8: - Reviewed by Oscar. v9: - Fixed label location. (Oscar) v10: - Improved comments and replaced magical number. (Oscar) Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Yunwei Zhang Reviewed-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 4 drivers/gpu/drm/i915/intel_device_info.c | 34 2 files changed, 38 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index fb10602..6c9c01b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2709,6 +2709,10 @@ enum i915_power_well_id { #define GEN10_F2_SS_DIS_SHIFT18 #define GEN10_F2_SS_DIS_MASK (0xf << GEN10_F2_SS_DIS_SHIFT) +#defineGEN10_MIRROR_FUSE3 _MMIO(0x9118) +#define GEN10_L3BANK_PAIR_COUNT 4 +#define GEN10_L3BANK_MASK 0x0F + #define GEN8_EU_DISABLE0 _MMIO(0x9134) #define GEN8_EU_DIS0_S0_MASK 0xff #define GEN8_EU_DIS0_S1_SHIFT24 diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index 3791b52..a42842d 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -741,6 +741,40 @@ static void sanitize_mcr(struct intel_device_info *info) u32 slice = fls(info->sseu.slice_mask); u32 subslice = fls(info->sseu.subslice_mask[slice]); + /* +* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl +* L3Banks could be fused off in single slice scenario. If that is +* the case, we might need to program MCR select to a valid L3Bank +* by default, to make sure we correctly read certain registers +* later on (in the range 0xB100 - 0xB3FF). +* This might be incompatible with +* WaProgramMgsrForCorrectSliceSpecificMmioReads. +* Fortunately, this should not happen in production hardware, so +* we only assert that this is the case (instead of implementing +* something more complex that requires checking the range of every +* MMIO read). +*/ + if (INTEL_GEN(dev_priv) >= 10 && + is_power_of_2(info->sseu.slice_mask)) { + /* +* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches +* enabled subslice, no need to redirect MCR packet +*/ + u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3); + u8 ss_mask = info->sseu.subslice_mask[slice]; + + u8 enabled_mask = (ss_mask | ss_mask >> + GEN10_L3BANK_PAIR_COUNT) & + GEN10_L3BANK_MASK; + u8 disabled_mask = fuse3 & GEN10_L3BANK_MASK; + + /* +* Production silicon should have matched L3Bank and +* subslice enabled +*/ + WARN_ON((enabled_mask & disabled_mask) != enabled_mask); + } + if (INTEL_GEN(dev_priv) >= 11) { mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each subsequent MMIO read will be forwarded to a specific slice/subslice combination as read is unicast. This is OK since slice/subslice specific register values are consistent in almost all cases across slice/subslice. There are rare occasions such as INSTDONE that this value will be dependent on slice/subslice combo, in such cases, we need to program 0xFDC and recover this after. This is already covered by read_subslice_reg. Also, 0xFDC will lose its information after TDR/engine reset/power state change. References: HSD#1405586840, BSID#0575 v2: - use fls() instead of find_last_bit() (Chris) - added INTEL_SSEU to extract sseu from device info. (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Change the ordered of passing arguments and etc. (Ursulin) v7: - Rebased. v8: - Reviewed by Oscar - Store default MCR value instead of calculate on the run. (Oscar) v9: - Changed naming and label fixes. (Oscar) - Store only the selector instead of whole MCR. (Oscar) v10: - Improved comments, naming and line breaknig. (Oscar) Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Yunwei Zhang Reviewed-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_device_info.c | 48 drivers/gpu/drm/i915/intel_device_info.h | 3 ++ drivers/gpu/drm/i915/intel_engine_cs.c | 10 +++ 3 files changed, 56 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index a32ba72..3791b52 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -719,6 +719,52 @@ static u32 read_timestamp_frequency(struct drm_i915_private *dev_priv) return 0; } + +/* + * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl + * Before any MMIO read into slice/subslice specific registers, MCR + * packet control register needs to be programmed to point to any + * enabled s/ss pair. Otherwise, incorrect values will be returned. + * This means each subsequent MMIO read will be forwarded to an + * specific s/ss combination, but this is OK since these registers + * are consistent across s/ss in almost all cases. In the rare + * occasions, such as INSTDONE, where this value is dependent + * on s/ss combo, the read should be done with read_subslice_reg. + */ +static void sanitize_mcr(struct intel_device_info *info) +{ + struct drm_i915_private *dev_priv = + container_of(info, struct drm_i915_private, info); + u32 mcr; + u32 mcr_slice_subslice_mask; + u32 mcr_slice_subslice_select; + u32 slice = fls(info->sseu.slice_mask); + u32 subslice = fls(info->sseu.subslice_mask[slice]); + + if (INTEL_GEN(dev_priv) >= 11) { + mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | + GEN11_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) | + GEN11_MCR_SUBSLICE(subslice); + } else { + mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK | + GEN8_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) | + GEN8_MCR_SUBSLICE(subslice); + } + + mcr = I915_READ(GEN8_MCR_SELECTOR); + mcr &= ~mcr_slice_subslice_mask; + + /* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl */ + if (INTEL_GEN(dev_priv) >= 10) + mcr |= mcr_slice_subslice_select; + + I915_WRITE(GEN8_MCR_SELECTOR, mcr); + + info->default_mcr_s_ss_select = mcr_slice_subslice_select; +} + /** * intel_device_info_runtime_init - initialize runtime info * @info: intel device info struct @@ -851,6 +897,8 @@ void intel_device_info_runtime_init(struct intel_device_info *info) else if (INTEL_INFO(dev_priv)->gen >= 11) gen11_sseu_info_init(dev_priv); + sanitize_mcr(info); + /* Initialize command stream timestamp frequency */ info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv); } diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index 933e316..2feccee 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -176,6 +176,9 @@ struct intel_device_info { /* Slice/subslice/EU info */ struct sseu_dev_info sseu; + /* default selected slice/subslice in MCR packet control */ + u32 default_mcr_s_ss_select; + u32 cs_times
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/audio: set minimum CD clock to twice the BCLK
== Series Details == Series: drm/i915/audio: set minimum CD clock to twice the BCLK URL : https://patchwork.freedesktop.org/series/41888/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8735_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8735_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8735_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41888/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8735_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-bsd1: shard-kbl: PASS -> SKIP igt@gem_mocs_settings@mocs-rc6-bsd2: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_8735_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic: shard-hsw: PASS -> FAIL (fdo#104873) igt@kms_flip@modeset-vs-vblank-race: shard-snb: PASS -> FAIL (fdo#103060) igt@kms_flip@modeset-vs-vblank-race-interruptible: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) igt@perf@short-reads: shard-kbl: PASS -> FAIL (fdo#103183) Possible fixes igt@drv_suspend@forcewake: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-farfromfence: shard-kbl: DMESG-WARN (fdo#105602, fdo#103558) -> PASS +2 igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 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#103183 https://bugs.freedesktop.org/show_bug.cgi?id=103183 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8735 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8735: bfb500c3510f626c212169ec498ddee1413c9736 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8735/shards.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 series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2)
== Series Details == Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2) URL : https://patchwork.freedesktop.org/series/41827/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8734_full = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41827/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_8734_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@2x-modeset-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@wf_vblank-ts-check-interruptible: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) igt@prime_mmap_coherency@read: shard-hsw: PASS -> DMESG-WARN (fdo#102614) +1 Possible fixes igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 3) == Missing(6): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-kbl shard-glkb == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8734 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8734: d45621446c373467ef2f658526ce56b70a42fba7 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8734/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, Here's the first misc-fixes pull. It unfortunately contains a backmerge due to Eric committing Daniel's patch before I had a chance to fast forward. Anyways, it's not too convoluted, so I'll try to win the race this week :-). In general, this is going to become more common as the number of committers grows. If it bugs you, let me know and we'll figure out a process to avoid it. drm-misc-fixes-2018-04-18-1: drm-misc-fixes: stable: vc4: Fix memory leak during BO teardown (Daniel) dp: Add i2c retry for LSPCON adapters (Imre) hdcp: Fix device count mask (Ramalingam) Cc: Daniel J Blueman Cc: Ramalingam C Cheers, Sean The following changes since commit a10beabba213924d876f2d10ca9351aeab93f58a: Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-04-13 09:25:21 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-04-18-1 for you to fetch changes up to 7eb2c4dd54ff841f2fe509a84973eb25fa20bda2: drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state (2018-04-18 16:33:14 +0300) drm-misc-fixes: stable: vc4: Fix memory leak during BO teardown (Daniel) dp: Add i2c retry for LSPCON adapters (Imre) hdcp: Fix device count mask (Ramalingam) Cc: Daniel J Blueman Cc: Ramalingam C Daniel J Blueman (1): drm/vc4: Fix memory leak during BO teardown Imre Deak (1): drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state Ramalingam C (1): drm: Fix HDCP downstream dev count read Sean Paul (1): Merge airlied/drm-next into drm-misc-fixes drivers/gpu/drm/drm_dp_dual_mode_helper.c | 39 -- drivers/gpu/drm/vc4/vc4_bo.c | 2 ++ drivers/gpu/drm/vc4/vc4_validate_shaders.c | 1 + include/drm/drm_hdcp.h | 2 +- 4 files changed, 36 insertions(+), 8 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers
== Series Details == Series: series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers URL : https://patchwork.freedesktop.org/series/41911/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8740 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41911/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8740 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (33 -> 31) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8740 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8740: 80a6c86f4aeac5561931d675ac82e01624e37eb8 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == 80a6c86f4aea drm/i915: Pack params to engine->schedule() into a struct 7d660e218d01 drm/i915: Rename priotree to sched f9eaeb0abf9f drm/i915: Move the priotree struct to its own headers == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8740/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 series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers
== Series Details == Series: series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers URL : https://patchwork.freedesktop.org/series/41911/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Move the priotree struct to its own headers Okay! Commit: drm/i915: Rename priotree to sched Okay! Commit: drm/i915: Pack params to engine->schedule() into a struct -drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3656: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 series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers
== Series Details == Series: series starting with [CI,1/3] drm/i915: Move the priotree struct to its own headers URL : https://patchwork.freedesktop.org/series/41911/ State : warning == Summary == $ dim checkpatch origin/drm-tip f9eaeb0abf9f drm/i915: Move the priotree struct to its own headers -:72: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #72: new file mode 100644 -:77: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #77: FILE: drivers/gpu/drm/i915/i915_scheduler.h:1: +/* total: 0 errors, 2 warnings, 0 checks, 108 lines checked 7d660e218d01 drm/i915: Rename priotree to sched 80a6c86f4aea drm/i915: Pack params to engine->schedule() into a struct ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915: Rename priotree to sched
Having moved the priotree struct into i915_scheduler.h, identify it as the scheduling element and rebrand into i915_sched. This becomes more useful as we start attaching more information we require to propagate through the scheduler. v2: Use i915_sched_node for future distinctiveness Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_request.c | 66 +- drivers/gpu/drm/i915/i915_request.h | 6 +- drivers/gpu/drm/i915/i915_scheduler.h | 4 +- drivers/gpu/drm/i915/intel_engine_cs.c | 4 +- drivers/gpu/drm/i915/intel_guc_submission.c | 8 +-- drivers/gpu/drm/i915/intel_lrc.c| 77 +++-- 7 files changed, 85 insertions(+), 82 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index effaf982b19b..6b5b9b3ded02 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -1278,7 +1278,7 @@ static void record_request(struct i915_request *request, struct drm_i915_error_request *erq) { erq->context = request->ctx->hw_id; - erq->priority = request->priotree.priority; + erq->priority = request->sched.priority; erq->ban_score = atomic_read(&request->ctx->ban_score); erq->seqno = request->global_seqno; erq->jiffies = request->emitted_jiffies; diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index 9ca9c24b4421..dfcc6a0df3fb 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -125,22 +125,22 @@ i915_dependency_free(struct drm_i915_private *i915, } static void -__i915_priotree_add_dependency(struct i915_priotree *pt, - struct i915_priotree *signal, - struct i915_dependency *dep, - unsigned long flags) +__i915_sched_node_add_dependency(struct i915_sched_node *node, +struct i915_sched_node *signal, +struct i915_dependency *dep, +unsigned long flags) { INIT_LIST_HEAD(&dep->dfs_link); list_add(&dep->wait_link, &signal->waiters_list); - list_add(&dep->signal_link, &pt->signalers_list); + list_add(&dep->signal_link, &node->signalers_list); dep->signaler = signal; dep->flags = flags; } static int -i915_priotree_add_dependency(struct drm_i915_private *i915, -struct i915_priotree *pt, -struct i915_priotree *signal) +i915_sched_node_add_dependency(struct drm_i915_private *i915, + struct i915_sched_node *node, + struct i915_sched_node *signal) { struct i915_dependency *dep; @@ -148,16 +148,18 @@ i915_priotree_add_dependency(struct drm_i915_private *i915, if (!dep) return -ENOMEM; - __i915_priotree_add_dependency(pt, signal, dep, I915_DEPENDENCY_ALLOC); + __i915_sched_node_add_dependency(node, signal, dep, +I915_DEPENDENCY_ALLOC); return 0; } static void -i915_priotree_fini(struct drm_i915_private *i915, struct i915_priotree *pt) +i915_sched_node_fini(struct drm_i915_private *i915, +struct i915_sched_node *node) { - struct i915_dependency *dep, *next; + struct i915_dependency *dep, *tmp; - GEM_BUG_ON(!list_empty(&pt->link)); + GEM_BUG_ON(!list_empty(&node->link)); /* * Everyone we depended upon (the fences we wait to be signaled) @@ -165,8 +167,8 @@ i915_priotree_fini(struct drm_i915_private *i915, struct i915_priotree *pt) * However, retirement is run independently on each timeline and * so we may be called out-of-order. */ - list_for_each_entry_safe(dep, next, &pt->signalers_list, signal_link) { - GEM_BUG_ON(!i915_priotree_signaled(dep->signaler)); + list_for_each_entry_safe(dep, tmp, &node->signalers_list, signal_link) { + GEM_BUG_ON(!i915_sched_node_signaled(dep->signaler)); GEM_BUG_ON(!list_empty(&dep->dfs_link)); list_del(&dep->wait_link); @@ -175,8 +177,8 @@ i915_priotree_fini(struct drm_i915_private *i915, struct i915_priotree *pt) } /* Remove ourselves from everyone who depends upon us */ - list_for_each_entry_safe(dep, next, &pt->waiters_list, wait_link) { - GEM_BUG_ON(dep->signaler != pt); + list_for_each_entry_safe(dep, tmp, &node->waiters_list, wait_link) { + GEM_BUG_ON(dep->signaler != node); GEM_BUG_ON(!list_empty(&dep->dfs_link)); list_del(&dep->signal_link); @@ -186,12 +188,12 @@ i915_priotree_fini(struct drm_i915_p
[Intel-gfx] [CI 3/3] drm/i915: Pack params to engine->schedule() into a struct
Today we only want to pass along the priority to engine->schedule(), but in the future we want to have much more control over the various aspects of the GPU during a context's execution, for example controlling the frequency allowed. As we need an ever growing number of parameters for scheduling, move those into a struct for convenience. v2: Move the anonymous struct into its own function for legibility and ye olde gcc. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/gvt/scheduler.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 3 ++- drivers/gpu/drm/i915/i915_gem.c | 18 + drivers/gpu/drm/i915/i915_gem_context.c | 8 drivers/gpu/drm/i915/i915_gem_context.h | 13 +--- drivers/gpu/drm/i915/i915_gpu_error.c | 8 drivers/gpu/drm/i915/i915_gpu_error.h | 5 +++-- drivers/gpu/drm/i915/i915_request.c | 4 ++-- drivers/gpu/drm/i915/i915_request.h | 1 + drivers/gpu/drm/i915/i915_scheduler.h | 17 +++- drivers/gpu/drm/i915/intel_display.c | 11 +- drivers/gpu/drm/i915/intel_engine_cs.c| 18 ++--- drivers/gpu/drm/i915/intel_guc_submission.c | 2 +- drivers/gpu/drm/i915/intel_lrc.c | 20 ++- drivers/gpu/drm/i915/intel_ringbuffer.h | 4 +++- .../gpu/drm/i915/selftests/intel_hangcheck.c | 4 ++-- drivers/gpu/drm/i915/selftests/intel_lrc.c| 8 +--- 17 files changed, 91 insertions(+), 55 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c index 638abe84857c..f3d21849b0cb 100644 --- a/drivers/gpu/drm/i915/gvt/scheduler.c +++ b/drivers/gpu/drm/i915/gvt/scheduler.c @@ -1135,7 +1135,7 @@ int intel_vgpu_setup_submission(struct intel_vgpu *vgpu) return PTR_ERR(s->shadow_ctx); if (HAS_LOGICAL_RING_PREEMPTION(vgpu->gvt->dev_priv)) - s->shadow_ctx->priority = INT_MAX; + s->shadow_ctx->sched.priority = INT_MAX; bitmap_zero(s->shadow_ctx_desc_updated, I915_NUM_ENGINES); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 8e8667d9b084..028691108125 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -75,6 +75,7 @@ #include "i915_gem_timeline.h" #include "i915_gpu_error.h" #include "i915_request.h" +#include "i915_scheduler.h" #include "i915_vma.h" #include "intel_gvt.h" @@ -3158,7 +3159,7 @@ int i915_gem_object_wait(struct drm_i915_gem_object *obj, struct intel_rps_client *rps); int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj, unsigned int flags, - int priority); + const struct i915_sched_attr *attr); #define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX int __must_check diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 4c9d2a6f7d28..795ca83aed7a 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -564,7 +564,8 @@ i915_gem_object_wait_reservation(struct reservation_object *resv, return timeout; } -static void __fence_set_priority(struct dma_fence *fence, int prio) +static void __fence_set_priority(struct dma_fence *fence, +const struct i915_sched_attr *attr) { struct i915_request *rq; struct intel_engine_cs *engine; @@ -577,11 +578,12 @@ static void __fence_set_priority(struct dma_fence *fence, int prio) rcu_read_lock(); if (engine->schedule) - engine->schedule(rq, prio); + engine->schedule(rq, attr); rcu_read_unlock(); } -static void fence_set_priority(struct dma_fence *fence, int prio) +static void fence_set_priority(struct dma_fence *fence, + const struct i915_sched_attr *attr) { /* Recurse once into a fence-array */ if (dma_fence_is_array(fence)) { @@ -589,16 +591,16 @@ static void fence_set_priority(struct dma_fence *fence, int prio) int i; for (i = 0; i < array->num_fences; i++) - __fence_set_priority(array->fences[i], prio); + __fence_set_priority(array->fences[i], attr); } else { - __fence_set_priority(fence, prio); + __fence_set_priority(fence, attr); } } int i915_gem_object_wait_priority(struct drm_i915_gem_object *obj, unsigned int flags, - int prio) + const struct i915_sched_attr *attr) { struct dma_fence *excl; @@ -613,7 +615,7 @@ i915_gem_object_wait_priority(struct drm_i915_gem_object *obj, return ret; for (i = 0; i < count; i++)
[Intel-gfx] [CI 1/3] drm/i915: Move the priotree struct to its own headers
Over time the priotree has grown from a sorted list to a more complicated structure for propagating constraints along the dependency chain to try and resolve priority inversion. Start to segregate this information from the rest of the request/fence tracking. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_request.h | 39 +- drivers/gpu/drm/i915/i915_scheduler.h | 57 +++ 2 files changed, 58 insertions(+), 38 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_scheduler.h diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h index 7d6eb82eeb91..e6f7c5f4ec7f 100644 --- a/drivers/gpu/drm/i915/i915_request.h +++ b/drivers/gpu/drm/i915/i915_request.h @@ -28,6 +28,7 @@ #include #include "i915_gem.h" +#include "i915_scheduler.h" #include "i915_sw_fence.h" #include @@ -48,44 +49,6 @@ struct intel_signal_node { struct list_head link; }; -struct i915_dependency { - struct i915_priotree *signaler; - struct list_head signal_link; - struct list_head wait_link; - struct list_head dfs_link; - unsigned long flags; -#define I915_DEPENDENCY_ALLOC BIT(0) -}; - -/* - * "People assume that time is a strict progression of cause to effect, but - * actually, from a nonlinear, non-subjective viewpoint, it's more like a big - * ball of wibbly-wobbly, timey-wimey ... stuff." -The Doctor, 2015 - * - * Requests exist in a complex web of interdependencies. Each request - * has to wait for some other request to complete before it is ready to be run - * (e.g. we have to wait until the pixels have been rendering into a texture - * before we can copy from it). We track the readiness of a request in terms - * of fences, but we also need to keep the dependency tree for the lifetime - * of the request (beyond the life of an individual fence). We use the tree - * at various points to reorder the requests whilst keeping the requests - * in order with respect to their various dependencies. - */ -struct i915_priotree { - struct list_head signalers_list; /* those before us, we depend upon */ - struct list_head waiters_list; /* those after us, they depend upon us */ - struct list_head link; - int priority; -}; - -enum { - I915_PRIORITY_MIN = I915_CONTEXT_MIN_USER_PRIORITY - 1, - I915_PRIORITY_NORMAL = I915_CONTEXT_DEFAULT_PRIORITY, - I915_PRIORITY_MAX = I915_CONTEXT_MAX_USER_PRIORITY + 1, - - I915_PRIORITY_INVALID = INT_MIN -}; - struct i915_capture_list { struct i915_capture_list *next; struct i915_vma *vma; diff --git a/drivers/gpu/drm/i915/i915_scheduler.h b/drivers/gpu/drm/i915/i915_scheduler.h new file mode 100644 index ..9d6ea9fa6e59 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_scheduler.h @@ -0,0 +1,57 @@ +/* + * SPDX-License-Identifier: MIT + * + * Copyright © 2018 Intel Corporation + */ + +#ifndef _I915_SCHEDULER_H_ +#define _I915_SCHEDULER_H_ + +#include + +#include + +enum { + I915_PRIORITY_MIN = I915_CONTEXT_MIN_USER_PRIORITY - 1, + I915_PRIORITY_NORMAL = I915_CONTEXT_DEFAULT_PRIORITY, + I915_PRIORITY_MAX = I915_CONTEXT_MAX_USER_PRIORITY + 1, + + I915_PRIORITY_INVALID = INT_MIN +}; + +/* + * "People assume that time is a strict progression of cause to effect, but + * actually, from a nonlinear, non-subjective viewpoint, it's more like a big + * ball of wibbly-wobbly, timey-wimey ... stuff." -The Doctor, 2015 + * + * Requests exist in a complex web of interdependencies. Each request + * has to wait for some other request to complete before it is ready to be run + * (e.g. we have to wait until the pixels have been rendering into a texture + * before we can copy from it). We track the readiness of a request in terms + * of fences, but we also need to keep the dependency tree for the lifetime + * of the request (beyond the life of an individual fence). We use the tree + * at various points to reorder the requests whilst keeping the requests + * in order with respect to their various dependencies. + * + * There is no active component to the "scheduler". As we know the dependency + * DAG of each request, we are able to insert it into a sorted queue when it + * is ready, and are able to reorder its portion of the graph to accommodate + * dynamic priority changes. + */ +struct i915_priotree { + struct list_head signalers_list; /* those before us, we depend upon */ + struct list_head waiters_list; /* those after us, they depend upon us */ + struct list_head link; + int priority; +}; + +struct i915_dependency { + struct i915_priotree *signaler; + struct list_head signal_link; + struct list_head wait_link; + struct list_head dfs_link; + unsigned long flags; +#define I915_DEPENDENCY_ALLOC BIT(0) +}; + +#endif /* _I915_SCHEDULER_H_ */ -- 2.17.0 ___ Intel-gfx mailing list In
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance
== Series Details == Series: drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance URL : https://patchwork.freedesktop.org/series/41883/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8733_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8733_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8733_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41883/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8733_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-dirty-render: shard-kbl: SKIP -> PASS +2 igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: PASS -> SKIP +1 == Known issues == Here are the changes found in Patchwork_8733_full that come from known issues: === IGT changes === Issues hit igt@gem_exec_store@cachelines-bsd: shard-hsw: PASS -> FAIL (fdo#17) igt@kms_flip@2x-flip-vs-wf_vblank: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_flip@flip-vs-wf_vblank-interruptible: shard-apl: PASS -> FAIL (fdo#100368) igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-blt: shard-apl: PASS -> FAIL (fdo#103167) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-farfromfence: shard-kbl: DMESG-WARN (fdo#105602, fdo#103558) -> PASS +2 igt@kms_setmode@basic: shard-kbl: FAIL (fdo#99912) -> PASS fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8733 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8733: 7f451ce363f70a1962ea45efa8fc972afcbc000d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8733/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12
On Wed, Apr 18, 2018 at 08:06:57PM +0200, Maarten Lankhorst wrote: > Op 18-04-18 om 17:32 schreef Ville Syrjälä: > > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote: > >> From: Maarten Lankhorst > >> > >> We skip src trunction/adjustments for > >> NV12 case and handle the sizes directly. > >> Without this, pipe fifo underruns are seen on APL/KBL. > >> > >> v2: For NV12, making the src coordinates multiplier of 4 > >> > >> v3: Moving all the src coords handling code for NV12 > >> to skl_check_nv12_surface > >> > >> Signed-off-by: Maarten Lankhorst > >> Signed-off-by: Vidya Srinivas > >> --- > >> drivers/gpu/drm/i915/intel_display.c | 39 > >> > >> drivers/gpu/drm/i915/intel_sprite.c | 15 ++ > >> 2 files changed, 50 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_display.c > >> b/drivers/gpu/drm/i915/intel_display.c > >> index 925402e..b8dbaca 100644 > >> --- a/drivers/gpu/drm/i915/intel_display.c > >> +++ b/drivers/gpu/drm/i915/intel_display.c > >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct > >> intel_crtc_state *crtc_state, > >>return 0; > >> } > >> > >> +static int > >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state, > >> + struct intel_plane_state *plane_state) > >> +{ > >> + int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w; > >> + int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h; > >> + > >> + if (((plane_state->base.src_x >> 16) % 4) != 0 || > >> + ((plane_state->base.src_y >> 16) % 4) != 0 || > >> + ((plane_state->base.src_w >> 16) % 4) != 0 || > >> + ((plane_state->base.src_h >> 16) % 4) != 0) { > >> + DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n"); > >> + return -EINVAL; > >> + } > > I don't really see why we should check these. The clipped coordinates > > are what matters. > > To propagate our limits to the userspace. I think we should do it for all > formats, > but NV12 is the first YUV format we have tests for. If we could we should do > something similar for the other YUV formats, but they have different > requirements. > > In case of NV12 we don't have existing userspace, there will be nothing that > breaks if we enforce limits from the start. But what about sub-pixel coordinates? You're totally ignoring them here. We need to come up with some proper rules for this stuff. > > >> + > >> + /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */ > >> + if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) || > >> + (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) { > >> + DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n", > >> +crtc_x2, crtc_y2, > >> +crtc_state->pipe_src_w, crtc_state->pipe_src_h); > >> + return -EINVAL; > >> + } > > Why should we care? The current code already plays it fast and loose > > and allows the dst rectangle to shrink to accomodate the hw limits. > > If we want to change that we should change it universally. > > Unfortunately for the other formats we already have an existing userspace > (X.org) that doesn't perform any validation. We can't change it for that, > but we can prevent future mistakes. We should do it uniformly. Not per-format. That will make the code unmaintainable real quick. > > >> + > >> + plane_state->base.src.x1 = > >> + DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18; > >> + plane_state->base.src.x2 = > >> + DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18; > >> + plane_state->base.src.y1 = > >> + DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18; > >> + plane_state->base.src.y2 = > >> + DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18; > > Since this can now increase the size of the source rectangle our > > scaling factor checks are no longer 100% valid. We might end up with > > a scaling factor that is too high. > > > > I don't really like any of these "let's make NV12 behave special" > > tricks. We should make the code behave the same way for all pixel > > formats instead of adding format specific hacks. > > This is not nivalid because we restrict the original src coordinates to be > a multiple of 4, you can only clip to something smaller, not to something > bigger. :) The clipped coordinates can be whatever thanks to scaling/etc. Also why are we trying to make everything a multiple of four? I don't remember any hw restrictions like that. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for gpu: drm: i915: Change return type to vm_fault_t (rev2)
On Wed, Apr 18, 2018 at 9:24 PM, Patchwork wrote: > == Series Details == > > Series: gpu: drm: i915: Change return type to vm_fault_t (rev2) > URL : https://patchwork.freedesktop.org/series/41893/ > State : warning > > == Summary == > > $ dim checkpatch origin/drm-tip > 045e647f1204 gpu: drm: i915: Change return type to vm_fault_t > -:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit > <12+ chars of sha1> ("")' - ie: 'commit 1c8f422059ae ("mm: change > return type to vm_fault_t")' Does it mean I need to send v3 with correction ? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12
Op 18-04-18 om 17:32 schreef Ville Syrjälä: > On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote: >> From: Maarten Lankhorst >> >> We skip src trunction/adjustments for >> NV12 case and handle the sizes directly. >> Without this, pipe fifo underruns are seen on APL/KBL. >> >> v2: For NV12, making the src coordinates multiplier of 4 >> >> v3: Moving all the src coords handling code for NV12 >> to skl_check_nv12_surface >> >> Signed-off-by: Maarten Lankhorst >> Signed-off-by: Vidya Srinivas >> --- >> drivers/gpu/drm/i915/intel_display.c | 39 >> >> drivers/gpu/drm/i915/intel_sprite.c | 15 ++ >> 2 files changed, 50 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_display.c >> b/drivers/gpu/drm/i915/intel_display.c >> index 925402e..b8dbaca 100644 >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++ b/drivers/gpu/drm/i915/intel_display.c >> @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct >> intel_crtc_state *crtc_state, >> return 0; >> } >> >> +static int >> +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state, >> + struct intel_plane_state *plane_state) >> +{ >> +int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w; >> +int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h; >> + >> +if (((plane_state->base.src_x >> 16) % 4) != 0 || >> +((plane_state->base.src_y >> 16) % 4) != 0 || >> +((plane_state->base.src_w >> 16) % 4) != 0 || >> +((plane_state->base.src_h >> 16) % 4) != 0) { >> +DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n"); >> +return -EINVAL; >> +} > I don't really see why we should check these. The clipped coordinates > are what matters. To propagate our limits to the userspace. I think we should do it for all formats, but NV12 is the first YUV format we have tests for. If we could we should do something similar for the other YUV formats, but they have different requirements. In case of NV12 we don't have existing userspace, there will be nothing that breaks if we enforce limits from the start. >> + >> +/* Clipping would cause a 1-3 pixel gap at the edge of the screen? */ >> +if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) || >> +(crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) { >> +DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n", >> + crtc_x2, crtc_y2, >> + crtc_state->pipe_src_w, crtc_state->pipe_src_h); >> +return -EINVAL; >> +} > Why should we care? The current code already plays it fast and loose > and allows the dst rectangle to shrink to accomodate the hw limits. > If we want to change that we should change it universally. Unfortunately for the other formats we already have an existing userspace (X.org) that doesn't perform any validation. We can't change it for that, but we can prevent future mistakes. >> + >> +plane_state->base.src.x1 = >> +DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18; >> +plane_state->base.src.x2 = >> +DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18; >> +plane_state->base.src.y1 = >> +DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18; >> +plane_state->base.src.y2 = >> +DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18; > Since this can now increase the size of the source rectangle our > scaling factor checks are no longer 100% valid. We might end up with > a scaling factor that is too high. > > I don't really like any of these "let's make NV12 behave special" > tricks. We should make the code behave the same way for all pixel > formats instead of adding format specific hacks. This is not nivalid because we restrict the original src coordinates to be a multiple of 4, you can only clip to something smaller, not to something bigger. :) ___ 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: Wait for vblank after register read
== Series Details == Series: drm/i915: Wait for vblank after register read URL : https://patchwork.freedesktop.org/series/41877/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4066_full -> Patchwork_8731_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8731_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8731_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41877/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8731_full: === IGT changes === Possible regressions igt@kms_flip@blocking-absolute-wf_vblank-interruptible: shard-apl: PASS -> FAIL Warnings igt@gem_mocs_settings@mocs-rc6-dirty-render: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_8731_full that come from known issues: === IGT changes === Issues hit igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) igt@kms_vblank@pipe-b-accuracy-idle: shard-hsw: PASS -> FAIL (fdo#102583) igt@pm_rpm@universal-planes: shard-kbl: PASS -> DMESG-WARN (fdo#103558, fdo#105602) Possible fixes igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_flip@2x-dpms-vs-vblank-race: shard-hsw: FAIL (fdo#103060) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-blocking-wf-vblank: shard-hsw: FAIL (fdo#100368) -> PASS igt@kms_sysfs_edid_timing: shard-apl: WARN (fdo#100047) -> PASS igt@prime_self_import@basic-with_fd_dup: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102583 https://bugs.freedesktop.org/show_bug.cgi?id=102583 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8731 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8731: e03bb4d9e64828ac5797f6750752437e0a683383 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8731/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Enable late fbdev initial configuration
On Wed, 2018-04-18 at 17:55 +0100, Chris Wilson wrote: > Quoting Souza, Jose (2018-04-18 17:42:47) > > On Wed, 2018-04-18 at 09:26 +0100, Chris Wilson wrote: > > > Quoting Souza, Jose (2018-04-18 01:07:16) > > > > On Wed, 2018-04-18 at 00:44 +0100, Chris Wilson wrote: > > > > > Quoting José Roberto de Souza (2018-04-17 23:34:18) > > > > > > If the initial fbdev > > > > > > configuration(intel_fbdev_initial_config()) > > > > > > runs and > > > > > > there still no sink connected it will cause > > > > > > drm_fb_helper_initial_config() to return 0 as no error > > > > > > happened(but > > > > > > internally the return is -EAGAIN). > > > > > > Because no framebuffer was allocated, when a sink is > > > > > > connected > > > > > > intel_fbdev_output_poll_changed() will not execute > > > > > > drm_fb_helper_hotplug_event() that would trigger another > > > > > > try to > > > > > > do > > > > > > the > > > > > > initial fbdev configuration. > > > > > > > > > > > > So here creating a dummy framebuffer of 800x600, so > > > > > > drm_fb_helper_hotplug_event() will be executed and fbdev > > > > > > can be > > > > > > properly > > > > > > setup when a sink is connected, if needed the dummy > > > > > > framebuffer > > > > > > will be > > > > > > freed and a new with the proper size will be allocated. > > > > > > > > > > > > This issue also happens when a MST DP sink is connected > > > > > > since > > > > > > boot, > > > > > > as > > > > > > the MST topology is discovered in parallel if > > > > > > intel_fbdev_initial_config() > > > > > > is executed before the first sink MST is discovered it will > > > > > > cause > > > > > > this > > > > > > same issue. > > > > > > > > > > > > This is a follow up patch of > > > > > > https://patchwork.freedesktop.org/patch/196089/ > > > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=1041 > > > > > > 58 > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=1044 > > > > > > 25 > > > > > > Cc: Chris Wilson > > > > > > Cc: Rodrigo Vivi > > > > > > Signed-off-by: José Roberto de Souza > > > > > > --- > > > > > > drivers/gpu/drm/i915/intel_fbdev.c | 24 > > > > > > +++- > > > > > > 1 file changed, 23 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > > > > > > b/drivers/gpu/drm/i915/intel_fbdev.c > > > > > > index 7d41d139341b..773577d39782 100644 > > > > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > > > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > > > > > @@ -696,14 +696,36 @@ int intel_fbdev_init(struct > > > > > > drm_device > > > > > > *dev) > > > > > > return 0; > > > > > > } > > > > > > > > > > > > +static void intel_fbdev_dummy_fb_create(struct intel_fbdev > > > > > > *ifbdev) > > > > > > +{ > > > > > > + struct drm_fb_helper_surface_size sizes; > > > > > > + > > > > > > + sizes.fb_width = 800; > > > > > > + sizes.fb_height = 600; > > > > > > + sizes.surface_width = sizes.fb_width; > > > > > > + sizes.surface_height = sizes.fb_height; > > > > > > + sizes.surface_bpp = 32; > > > > > > + sizes.surface_depth = 24; > > > > > > + > > > > > > + if (intelfb_create(&ifbdev->helper, &sizes)) > > > > > > + DRM_ERROR("Unable to create dummy > > > > > > framebufer"); > > > > > > +} > > > > > > + > > > > > > static void intel_fbdev_initial_config(void *data, > > > > > > async_cookie_t > > > > > > cookie) > > > > > > { > > > > > > struct intel_fbdev *ifbdev = data; > > > > > > > > > > > > /* Due to peculiar init order wrt to hpd handling > > > > > > this > > > > > > is > > > > > > separate. */ > > > > > > if (drm_fb_helper_initial_config(&ifbdev->helper, > > > > > > -ifbdev- > > > > > > > preferred_bpp)) > > > > > > > > > > > > +ifbdev- > > > > > > > preferred_bpp)) { > > > > > > > > > > > > intel_fbdev_unregister(to_i915(ifbdev- > > > > > > > helper.dev)); > > > > > > > > > > > > + return; > > > > > > + } > > > > > > + > > > > > > + mutex_lock(&ifbdev->helper.lock); > > > > > > + if (!ifbdev->vma) > > > > > > + intel_fbdev_dummy_fb_create(ifbdev); > > > > > > + mutex_unlock(&ifbdev->helper.lock); > > > > > > } > > > > > > > > > > Did you try > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > > > > > b/drivers/gpu/drm/i915/intel_fbdev.c > > > > > index 65a3313723c9..4120c635742d 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > > > > @@ -493,6 +493,7 @@ static bool > > > > > intel_fb_initial_config(struct > > > > > drm_fb_helper *fb_helper, > > > > > bail: > > > > > DRM_DEBUG_KMS("Not using firmware > > > > > configuration\n"); > > > > > memcpy(enabled, save_enabled, count); > > > > > + fb_helper->
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes
== Series Details == Series: series starting with [v4,1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes URL : https://patchwork.freedesktop.org/series/41909/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8739 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41909/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8739 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (33 -> 31) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8739 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8739: f6e5a01f3c8931f5b6420e877f8a8e596821926f @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == f6e5a01f3c89 HAX enable guc for CI 03aa3dbadc8a drm/i915: Add code to accept valid locked WOPCM register values c531aeed1378 drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset register a83dfdf266d5 drm/i915: Always do WOPCM partitioning based on real firmware sizes == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8739/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/4] HAX enable guc for CI
Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/4] drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset register
The enable_guc modparam is used to enable/disable GuC/HuC FW uploading dynamically during i915 module loading. If WOPCM offset register was locked without having HUC_LOADING_AGENT_GUC bit set to 1, the module reloading with both GuC and HuC FW will fail since we need to set this bit to 1 for HuC FW uploading. Since HUC_LOADING_AGENT_GUC bit has no impact on GuC FW uploading, this patch updates the register updating code to make sure the WOPCM offset register is always locked with HUC_LOADING_AGENT_GUC bit set to 1 which will guarantee successful uploading of both GuC and HuC FW. We will further take care of the locked values in the following enhancement patch. v4: - Fixed typo in commit message (Michal Wajdeczko) Signed-off-by: Jackie Li Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Michal Winiarski Cc: John Spotswood Cc: Joonas Lahtinen Reviewed-by: John Spotswood --- drivers/gpu/drm/i915/intel_wopcm.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c index 74bf76f..b1c08ca 100644 --- a/drivers/gpu/drm/i915/intel_wopcm.c +++ b/drivers/gpu/drm/i915/intel_wopcm.c @@ -238,8 +238,6 @@ static inline int write_and_verify(struct drm_i915_private *dev_priv, int intel_wopcm_init_hw(struct intel_wopcm *wopcm) { struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm); - u32 huc_agent; - u32 mask; int err; if (!USES_GUC(dev_priv)) @@ -255,10 +253,10 @@ int intel_wopcm_init_hw(struct intel_wopcm *wopcm) if (err) goto err_out; - huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0; - mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent; err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET, - wopcm->guc.base | huc_agent, mask, + wopcm->guc.base | HUC_LOADING_AGENT_GUC, + GUC_WOPCM_OFFSET_MASK | HUC_LOADING_AGENT_GUC | + GUC_WOPCM_OFFSET_VALID, GUC_WOPCM_OFFSET_VALID); if (err) goto err_out; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes
After enabled the WOPCM write-once registers locking status checking, reloading of the i915 module will fail with modparam enable_guc set to 3 (enable GuC and HuC firmware loading) if the module was originally loaded with enable_guc set to 1 (only enable GuC firmware loading). This is because WOPCM registers were updated and locked without considering the HuC FW size. Since we need both GuC and HuC FW sizes to determine the final layout of WOPCM, we should always calculate the WOPCM layout based on the actual sizes of the GuC and HuC firmware available for a specific platform if we need continue to support enable/disable HuC FW loading dynamically with enable_guc modparam. This patch splits uC firmware fetching into two stages. First stage is to fetch the firmware image and verify the firmware header. uC firmware will be marked as verified and this will make FW info available for following WOPCM layout calculation. The second stage is to create a GEM object and copy the FW data into the created GEM object which will only be available when GuC/HuC loading is enabled by enable_guc modparam. This will guarantee that the WOPCM layout will be always be calculated correctly without making any assumptions to the GuC and HuC firmware sizes. v3: - Rebase v4: - Renamed the new parameter add to intel_uc_fw_fetch (Michal) Signed-off-by: Jackie Li Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Michal Winiarski Cc: John Spotswood Cc: Joonas Lahtinen Reviewed-by: John Spotswood --- drivers/gpu/drm/i915/intel_uc.c| 14 -- drivers/gpu/drm/i915/intel_uc_fw.c | 31 --- drivers/gpu/drm/i915/intel_uc_fw.h | 7 +-- 3 files changed, 29 insertions(+), 23 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 1cffaf7..73b8f6c 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -172,11 +172,8 @@ void intel_uc_init_early(struct drm_i915_private *i915) sanitize_options_early(i915); - if (USES_GUC(i915)) - intel_uc_fw_fetch(i915, &guc->fw); - - if (USES_HUC(i915)) - intel_uc_fw_fetch(i915, &huc->fw); + intel_uc_fw_fetch(i915, &guc->fw, USES_GUC(i915)); + intel_uc_fw_fetch(i915, &huc->fw, USES_HUC(i915)); } void intel_uc_cleanup_early(struct drm_i915_private *i915) @@ -184,11 +181,8 @@ void intel_uc_cleanup_early(struct drm_i915_private *i915) struct intel_guc *guc = &i915->guc; struct intel_huc *huc = &i915->huc; - if (USES_HUC(i915)) - intel_uc_fw_fini(&huc->fw); - - if (USES_GUC(i915)) - intel_uc_fw_fini(&guc->fw); + intel_uc_fw_fini(&huc->fw); + intel_uc_fw_fini(&guc->fw); guc_free_load_err_log(guc); } diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c b/drivers/gpu/drm/i915/intel_uc_fw.c index 6e8e0b5..c1fed06 100644 --- a/drivers/gpu/drm/i915/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/intel_uc_fw.c @@ -33,11 +33,13 @@ * * @dev_priv: device private * @uc_fw: uC firmware + * @fetch: whether fetch uC firmware into GEM object or not * - * Fetch uC firmware into GEM obj. + * Fetch and verify uC firmware and copy firmware data into GEM object if + * @fetch is true. */ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv, - struct intel_uc_fw *uc_fw) + struct intel_uc_fw *uc_fw, bool fetch) { struct pci_dev *pdev = dev_priv->drm.pdev; struct drm_i915_gem_object *obj; @@ -154,17 +156,24 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv, goto fail; } - obj = i915_gem_object_create_from_data(dev_priv, fw->data, fw->size); - if (IS_ERR(obj)) { - err = PTR_ERR(obj); - DRM_DEBUG_DRIVER("%s fw object_create err=%d\n", -intel_uc_fw_type_repr(uc_fw->type), err); - goto fail; + uc_fw->size = fw->size; + uc_fw->fetch_status = INTEL_UC_FIRMWARE_VERIFIED; + + if (fetch) { + obj = i915_gem_object_create_from_data(dev_priv, fw->data, + fw->size); + if (IS_ERR(obj)) { + err = PTR_ERR(obj); + DRM_DEBUG_DRIVER("%s fw object_create err=%d\n", +intel_uc_fw_type_repr(uc_fw->type), +err); + goto fail; + } + + uc_fw->obj = obj; + uc_fw->fetch_status = INTEL_UC_FIRMWARE_SUCCESS; } - uc_fw->obj = obj; - uc_fw->size = fw->size; - uc_fw->fetch_status = INTEL_UC_FIRMWARE_SUCCESS; DRM_DEBUG_DRIVER("%s fw fetch %s\n", intel_uc_fw_type_repr(uc_fw->type), intel_uc_fw_status_repr(uc_fw->fetch_status)); diff --git a/drivers/gpu/drm
[Intel-gfx] [PATCH v4 3/4] drm/i915: Add code to accept valid locked WOPCM register values
In current code, we only compare the locked WOPCM register values with the calculated values. However, we can continue loading GuC/HuC firmware if the locked (or partially locked) values were valid for current GuC/HuC firmware sizes. This patch added a new code path to verify whether the locked register values can be used for GuC/HuC firmware loading, it will recalculate the verify the new values if these registers were partially locked, so that we won't fail the GuC/HuC firmware loading even if the locked register values are different from the calculated ones. v2: - Update WOPCM register only if it's not locked v4: - Fixed typo in code comments (Michal) - Refined function names and parameters (Michal) - Avoided duplicated function calls (Michal) - Refined register updating ordering (Michal) Signed-off-by: Jackie Li Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Michal Winiarski Cc: John Spotswood Cc: Joonas Lahtinen Reviewed-by: John Spotswood --- drivers/gpu/drm/i915/intel_wopcm.c | 251 - 1 file changed, 194 insertions(+), 57 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c index b1c08ca..8fdcc48 100644 --- a/drivers/gpu/drm/i915/intel_wopcm.c +++ b/drivers/gpu/drm/i915/intel_wopcm.c @@ -51,6 +51,8 @@ /* 8KB from GUC_WOPCM_RESERVED is reserved for GuC stack. */ #define GUC_WOPCM_STACK_RESERVED (8 * 1024) +/* GuC WOPCM Size value needs to be aligned to 4KB. */ +#define GUC_WOPCM_SIZE_ALIGNMENT (1UL << GUC_WOPCM_SIZE_SHIFT) /* GuC WOPCM Offset value needs to be aligned to 16KB. */ #define GUC_WOPCM_OFFSET_ALIGNMENT (1UL << GUC_WOPCM_OFFSET_SHIFT) @@ -86,60 +88,104 @@ static inline u32 context_reserved_size(struct drm_i915_private *i915) return 0; } -static inline int gen9_check_dword_gap(u32 guc_wopcm_base, u32 guc_wopcm_size) +static inline int gen9_check_dword_gap(struct intel_wopcm *wopcm) { - u32 offset; + u32 gen9_min_guc_wopcm_size = wopcm->guc.base + GEN9_GUC_WOPCM_OFFSET + + sizeof(u32); /* * GuC WOPCM size shall be at least a dword larger than the offset from * WOPCM base (GuC WOPCM offset from WOPCM base + GEN9_GUC_WOPCM_OFFSET) * due to hardware limitation on Gen9. */ - offset = guc_wopcm_base + GEN9_GUC_WOPCM_OFFSET; - if (offset > guc_wopcm_size || - (guc_wopcm_size - offset) < sizeof(u32)) { + if (wopcm->guc.size < gen9_min_guc_wopcm_size) { DRM_ERROR("GuC WOPCM size %uKiB is too small. %uKiB needed.\n", - guc_wopcm_size / 1024, - (u32)(offset + sizeof(u32)) / 1024); + wopcm->guc.size / 1024, + gen9_min_guc_wopcm_size / 1024); return -E2BIG; } return 0; } -static inline int gen9_check_huc_fw_fits(u32 guc_wopcm_size, u32 huc_fw_size) +static inline int gen9_check_huc_fw_fits(struct intel_wopcm *wopcm, +u32 huc_fw_size) { + u32 available_guc_wopcm = wopcm->guc.size - GUC_WOPCM_RESERVED; + /* * On Gen9 & CNL A0, hardware requires the total available GuC WOPCM * size to be larger than or equal to HuC firmware size. Otherwise, * firmware uploading would fail. */ - if (huc_fw_size > guc_wopcm_size - GUC_WOPCM_RESERVED) { + if (huc_fw_size > available_guc_wopcm) { DRM_ERROR("HuC FW (%uKiB) won't fit in GuC WOPCM (%uKiB).\n", - huc_fw_size / 1024, - (guc_wopcm_size - GUC_WOPCM_RESERVED) / 1024); + huc_fw_size / 1024, available_guc_wopcm / 1024); return -E2BIG; } return 0; } -static inline int check_hw_restriction(struct drm_i915_private *i915, - u32 guc_wopcm_base, u32 guc_wopcm_size, +static inline int check_hw_restriction(struct intel_wopcm *wopcm, u32 huc_fw_size) { + struct drm_i915_private *i915 = wopcm_to_i915(wopcm); int err = 0; if (IS_GEN9(i915)) - err = gen9_check_dword_gap(guc_wopcm_base, guc_wopcm_size); + err = gen9_check_dword_gap(wopcm); if (!err && (IS_GEN9(i915) || IS_CNL_REVID(i915, CNL_REVID_A0, CNL_REVID_A0))) - err = gen9_check_huc_fw_fits(guc_wopcm_size, huc_fw_size); + err = gen9_check_huc_fw_fits(wopcm, huc_fw_size); return err; } +static inline u32 fw_usable_wopcm_size(struct intel_wopcm *wopcm) +{ + struct drm_i915_private *i915 = wopcm_to_i915(wopcm); + u32 ctx_rsvd_size = context_reserved_size(i915); + + return wopcm->size - ctx_rsvd_size; +} + +static inline u32 min_guc_wopcm_size(u32 guc_fw_size) +{ + return ALIGN(guc_fw_s
Re: [Intel-gfx] [PATCH i-g-t 09/11] trace.pl: Add support for colouring context execution
One suggestion below, otherwise : Reviewed-by: Lionel Landwerlin On 06/03/18 04:43, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Add the command line switch which uses different colours for different context execution boxes. Signed-off-by: Tvrtko Ursulin Cc: John Harrison --- scripts/trace.pl | 41 +++-- 1 file changed, 39 insertions(+), 2 deletions(-) diff --git a/scripts/trace.pl b/scripts/trace.pl index e7ce273ef26a..ff61dea0768d 100755 --- a/scripts/trace.pl +++ b/scripts/trace.pl @@ -40,6 +40,7 @@ my $trace = 0; my $avg_delay_stats = 0; my $squash_context_id = 0; my $gpu_timeline = 0; +my $colour_contexts = 0; my @args; @@ -110,6 +111,8 @@ Usage: --squash-ctx-id Squash context id by substracting engine id from ctx id. --gpu-timeline Draw overall GPU busy timeline. + --colour-contexts / -c Use different colours for different + context execution boxes. ENDHELP exit 0; @@ -279,6 +282,20 @@ sub arg_skip_box return @_; } +sub arg_colour_contexts +{ + return unless scalar(@_); + + if ($_[0] eq '--colour-contexts' or + $_[0] eq '--color-contexts' or + $_[0] eq '-c') { + shift @_; + $colour_contexts = 1; + } + + return @_; +} + @args = @ARGV; while (@args) { my $left = scalar(@args); @@ -294,6 +311,7 @@ while (@args) { @args = arg_split_requests(@args); @args = arg_ignore_ring(@args); @args = arg_skip_box(@args); + @args = arg_colour_contexts(@args); last if $left == scalar(@args); } @@ -581,6 +599,7 @@ foreach my $key (@sorted_keys) { my $last_ts = 0; my $first_ts; +my $min_ctx; foreach my $key (@sorted_keys) { my $ring = $db{$key}->{'ring'}; @@ -590,6 +609,8 @@ foreach my $key (@sorted_keys) { $first_ts = $db{$key}->{'queue'} if not defined $first_ts or $db{$key}->{'queue'} < $first_ts; $last_ts = $end if $end > $last_ts; + $min_ctx = $db{$key}->{'ctx'} if not defined $min_ctx or +$db{$key}->{'ctx'} < $min_ctx; $db{$key}->{'context-complete-delay'} = $end - $notify; $db{$key}->{'execute-delay'} = $start - $db{$key}->{'submit'}; @@ -721,6 +742,8 @@ foreach my $key (keys %reqwait) { say sprintf('GPU: %.2f%% idle, %.2f%% busy', $flat_busy{'gpu-idle'}, $flat_busy{'gpu-busy'}) unless $html; +my $execute_colour = $colour_contexts ? 'multi-colour' : 'pink'; + print < @@ -741,7 +764,7 @@ print{'name'}, $db{$key}->{'ctx'}, $db{$key}->{'seqno'}); @@ -898,7 +934,8 @@ foreach my $key (sort sortQueue keys %db) { if (exists $db{$key}->{'incomplete'}) { $style = 'color: white; background-color: red;'; } else { - $style = 'color: black; background-color: pink;'; + $style = 'color: black; background-color: ' . + ctx_colour($ctx) . ';'; } $content = "$name $db{$key}->{'port'}"; $content .= ' ??? ' if exists $db{$key}->{'incomplete'}; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
On 4/18/2018 9:40 AM, Oscar Mateo wrote: On 4/17/2018 3:59 PM, Yunwei Zhang wrote: L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0 instead of correct values. However, this is not going to be the case in any production silicon. Therefore, we only check at initialization and issue a warning should this really happen. References: HSDES#1405586840 v2: - use fls instead of find_last_bit (Chris) - use is_power_of_2() instead of counting bit set (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Move local variable into scope where they are used (Ursulin) - use a new local variable to reduce long line of code (Ursulin) v6: - Some coding style and use more local variables for clearer logic (Ursulin) v7: - Rebased. v8: - Reviewed by Oscar. v9: - Fixed label location. (Oscar) Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Yunwei Zhang Reviewed-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 4 drivers/gpu/drm/i915/intel_device_info.c | 23 +++ 2 files changed, 27 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index fb10602..6c9c01b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2709,6 +2709,10 @@ enum i915_power_well_id { #define GEN10_F2_SS_DIS_SHIFT 18 #define GEN10_F2_SS_DIS_MASK (0xf << GEN10_F2_SS_DIS_SHIFT) +#define GEN10_MIRROR_FUSE3 _MMIO(0x9118) +#define GEN10_L3BANK_PAIR_COUNT 4 +#define GEN10_L3BANK_MASK 0x0F + #define GEN8_EU_DISABLE0 _MMIO(0x9134) #define GEN8_EU_DIS0_S0_MASK 0xff #define GEN8_EU_DIS0_S1_SHIFT 24 diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index 1a4288f..530b6ba 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -729,6 +729,29 @@ static void sanitize_mcr(struct intel_device_info *info) u32 slice = fls(info->sseu.slice_mask); u32 subslice = fls(info->sseu.subslice_mask[slice]); + /* + * WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl + * L3Banks could be fused off in single slice scenario, however, if + * more than one slice is enabled, this should not happen. + */ Maybe a better explanation is warranted: /* * WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl * L3Banks could be fused off in single slice scenario. If that is the case, * we might need to program MCR select to a valid L3Bank by default, * to make sure we correctly read certain registers later on * (in the range 0xB100 - 0xB3FF). * This might be incompatible with WaProgramMgsrForCorrectSliceSpecificMmioReads. * Fortunately, this should not happen in production hardware, so we only * assert that this is the case (instead of implementing something more complex * that requires checking the range of every MMIO read). */ + if (is_power_of_2(info->sseu.slice_mask)) { This WA is only required for GEN >= 10. In other GENs, GEN10_MIRROR_FUSE3 does not even exist! + /* + * read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches + * enabled subslice, no need to redirect MCR packet + */ + u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3); + u8 ss_mask = info->sseu.subslice_mask[slice]; + + u8 enabled_mask = (ss_mask | ss_mask >> 4) & 0xf; + u8 disabled_mask = fuse3 & 0xf; + You defined GEN10_L3BANK_MASK. Might as well use it :) + /* + * Production silicon should have matched L3Bank and + * subslice enabled + */ + WARN_ON((enabled_mask & disabled_mask) != enabled_mask); + } + if (INTEL_GEN(dev_priv) >= 11) { mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK; ___ 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 07/11] trace.pl: Move min/max timestamp lookup to last loop
Reviewed-by: Lionel Landwerlin On 06/03/18 04:43, Tvrtko Ursulin wrote: From: Tvrtko Ursulin It makes sense to fetch the min and max timestamp only after the last sort of the array. Signed-off-by: Tvrtko Ursulin Cc: John Harrison --- scripts/trace.pl | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/scripts/trace.pl b/scripts/trace.pl index d49d25d6c1ca..27b39efcebbd 100755 --- a/scripts/trace.pl +++ b/scripts/trace.pl @@ -531,8 +531,6 @@ foreach my $key (keys %db) { # GPU time accounting my (%running, %runnable, %queued, %batch_avg, %batch_total_avg, %batch_count); my (%submit_avg, %execute_avg, %ctxsave_avg); -my $last_ts = 0; -my $first_ts; sub sortStart { my $as = $db{$a}->{'start'}; @@ -554,9 +552,6 @@ foreach my $key (@sorted_keys) { my $ring = $db{$key}->{'ring'}; my $end = $db{$key}->{'end'}; - $first_ts = $db{$key}->{'queue'} if not defined $first_ts or $db{$key}->{'queue'} < $first_ts; - $last_ts = $end if $end > $last_ts; - # correct duration of merged batches if ($correct_durations and exists $db{$key}->{'no-end'}) { my $ctx = $db{$key}->{'ctx'}; @@ -584,12 +579,18 @@ foreach my $key (@sorted_keys) { @sorted_keys = sort sortStart keys %db if $re_sort; +my $last_ts = 0; +my $first_ts; + foreach my $key (@sorted_keys) { my $ring = $db{$key}->{'ring'}; my $end = $db{$key}->{'end'}; my $start = $db{$key}->{'start'}; my $notify = $db{$key}->{'notify'}; + $first_ts = $db{$key}->{'queue'} if not defined $first_ts or $db{$key}->{'queue'} < $first_ts; + $last_ts = $end if $end > $last_ts; + $db{$key}->{'context-complete-delay'} = $end - $notify; $db{$key}->{'execute-delay'} = $start - $db{$key}->{'submit'}; $db{$key}->{'submit-delay'} = $db{$key}->{'submit'} - $db{$key}->{'queue'}; ___ 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 06/11] trace.pl: Move sortQueue near its user
Reviewed-by: Lionel Landwerlin On 06/03/18 04:43, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Just to clear up some space for incoming code refactoring. Signed-off-by: Tvrtko Ursulin Cc: John Harrison --- scripts/trace.pl | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/scripts/trace.pl b/scripts/trace.pl index 509df6c0dd8b..d49d25d6c1ca 100755 --- a/scripts/trace.pl +++ b/scripts/trace.pl @@ -545,17 +545,6 @@ sub sortStart { return $val; } -sub sortQueue { - my $as = $db{$a}->{'queue'}; - my $bs = $db{$b}->{'queue'}; - my $val; - - $val = $as <=> $bs; - $val = $a cmp $b if $val == 0; - - return $val; -} - my @sorted_keys = sort sortStart keys %db; my $re_sort = 0; @@ -859,6 +848,17 @@ print < var items = new vis.DataSet([ ENDHTML +sub sortQueue { + my $as = $db{$a}->{'queue'}; + my $bs = $db{$b}->{'queue'}; + my $val; + + $val = $as <=> $bs; + $val = $a cmp $b if $val == 0; + + return $val; +} + my $i = 0; foreach my $key (sort sortQueue keys %db) { my ($name, $ctx, $seqno) = ($db{$key}->{'name'}, $db{$key}->{'ctx'}, $db{$key}->{'seqno'}); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Enable late fbdev initial configuration
Quoting Souza, Jose (2018-04-18 17:42:47) > On Wed, 2018-04-18 at 09:26 +0100, Chris Wilson wrote: > > Quoting Souza, Jose (2018-04-18 01:07:16) > > > On Wed, 2018-04-18 at 00:44 +0100, Chris Wilson wrote: > > > > Quoting José Roberto de Souza (2018-04-17 23:34:18) > > > > > If the initial fbdev > > > > > configuration(intel_fbdev_initial_config()) > > > > > runs and > > > > > there still no sink connected it will cause > > > > > drm_fb_helper_initial_config() to return 0 as no error > > > > > happened(but > > > > > internally the return is -EAGAIN). > > > > > Because no framebuffer was allocated, when a sink is connected > > > > > intel_fbdev_output_poll_changed() will not execute > > > > > drm_fb_helper_hotplug_event() that would trigger another try to > > > > > do > > > > > the > > > > > initial fbdev configuration. > > > > > > > > > > So here creating a dummy framebuffer of 800x600, so > > > > > drm_fb_helper_hotplug_event() will be executed and fbdev can be > > > > > properly > > > > > setup when a sink is connected, if needed the dummy framebuffer > > > > > will be > > > > > freed and a new with the proper size will be allocated. > > > > > > > > > > This issue also happens when a MST DP sink is connected since > > > > > boot, > > > > > as > > > > > the MST topology is discovered in parallel if > > > > > intel_fbdev_initial_config() > > > > > is executed before the first sink MST is discovered it will > > > > > cause > > > > > this > > > > > same issue. > > > > > > > > > > This is a follow up patch of > > > > > https://patchwork.freedesktop.org/patch/196089/ > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158 > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425 > > > > > Cc: Chris Wilson > > > > > Cc: Rodrigo Vivi > > > > > Signed-off-by: José Roberto de Souza > > > > > --- > > > > > drivers/gpu/drm/i915/intel_fbdev.c | 24 > > > > > +++- > > > > > 1 file changed, 23 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > > > > > b/drivers/gpu/drm/i915/intel_fbdev.c > > > > > index 7d41d139341b..773577d39782 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > > > > @@ -696,14 +696,36 @@ int intel_fbdev_init(struct drm_device > > > > > *dev) > > > > > return 0; > > > > > } > > > > > > > > > > +static void intel_fbdev_dummy_fb_create(struct intel_fbdev > > > > > *ifbdev) > > > > > +{ > > > > > + struct drm_fb_helper_surface_size sizes; > > > > > + > > > > > + sizes.fb_width = 800; > > > > > + sizes.fb_height = 600; > > > > > + sizes.surface_width = sizes.fb_width; > > > > > + sizes.surface_height = sizes.fb_height; > > > > > + sizes.surface_bpp = 32; > > > > > + sizes.surface_depth = 24; > > > > > + > > > > > + if (intelfb_create(&ifbdev->helper, &sizes)) > > > > > + DRM_ERROR("Unable to create dummy framebufer"); > > > > > +} > > > > > + > > > > > static void intel_fbdev_initial_config(void *data, > > > > > async_cookie_t > > > > > cookie) > > > > > { > > > > > struct intel_fbdev *ifbdev = data; > > > > > > > > > > /* Due to peculiar init order wrt to hpd handling this > > > > > is > > > > > separate. */ > > > > > if (drm_fb_helper_initial_config(&ifbdev->helper, > > > > > -ifbdev- > > > > > >preferred_bpp)) > > > > > +ifbdev- > > > > > >preferred_bpp)) { > > > > > intel_fbdev_unregister(to_i915(ifbdev- > > > > > > helper.dev)); > > > > > > > > > > + return; > > > > > + } > > > > > + > > > > > + mutex_lock(&ifbdev->helper.lock); > > > > > + if (!ifbdev->vma) > > > > > + intel_fbdev_dummy_fb_create(ifbdev); > > > > > + mutex_unlock(&ifbdev->helper.lock); > > > > > } > > > > > > > > Did you try > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > > > > b/drivers/gpu/drm/i915/intel_fbdev.c > > > > index 65a3313723c9..4120c635742d 100644 > > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > > > @@ -493,6 +493,7 @@ static bool intel_fb_initial_config(struct > > > > drm_fb_helper *fb_helper, > > > > bail: > > > > DRM_DEBUG_KMS("Not using firmware > > > > configuration\n"); > > > > memcpy(enabled, save_enabled, count); > > > > + fb_helper->deferred_setup = true; > > > > > > This is too earlier to set deferred_setup when > > > intel_fb_initial_config() fails, > > > __drm_fb_helper_initial_config_and_unlock() will then try to > > > probe/create a fb but as there is no sink connected it will fail > > > too. > > > > > > Also __drm_fb_helper_initial_config_and_unlock() is already setting > > > deferred_setup if both attempts fails. > > > > So... > > > > diff --git a/drivers/gpu
Re: [Intel-gfx] [PATCH v9 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 4/18/2018 9:45 AM, Oscar Mateo wrote: On 4/18/2018 9:38 AM, Chris Wilson wrote: Quoting Oscar Mateo (2018-04-18 17:30:41) On 4/17/2018 3:58 PM, Yunwei Zhang wrote: + /* + * HW expects MCR to be programed to a enabled slice/subslice pair + * before any MMIO read into slice/subslice register + */ The comment above makes more sense in sanitize_mcr, together with the WA label. You can make it a bit more verbose with the info in the commit message. Something like this: /* * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl * Before any MMIO read into slice/subslice specific registers, MCR * packet control register needs to be programmed to point to any * enabled s/ss pair. Otherwise, incorrect values will be returned. * This means each subsequent MMIO read will be forwarded to an * specific s/ss combination, but this is OK since these registers * are consistent across s/ss in almost all cases. In the rare * occasions, such as INSTDONE, where this value is dependent * on s/ss combo, the read shoud be done with read_subslice_reg. */ I don't think any other comment is required here. Apart from the answer to the earlier question, what mmio read after this point? If all slice/subslice register access is through this function, what are you trying to protect? Very curious. -Chris The problem is that the BSpec does not have a comprehensive list of registers that live in the slice/subslice, so it's difficult to know when this is going to become a problem. For example, I know from previous experience that the MOCS tables are replicated across slices (that's why we couldn't let UMD decide when to shutdown them: because the MOCS tables get lost as soon as you reconfigure the number of s/ss. The only way to do this in by poking in the context, so that the MOCS gets reprogrammed immediately after). This hasn't been an issue until know because the hardware would route your read to a valid s/ss combo whenever the MCR select was 0s. Apparently, this is not the case anymore... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 4/18/2018 9:38 AM, Chris Wilson wrote: Quoting Oscar Mateo (2018-04-18 17:30:41) On 4/17/2018 3:58 PM, Yunwei Zhang wrote: + /* + * HW expects MCR to be programed to a enabled slice/subslice pair + * before any MMIO read into slice/subslice register + */ The comment above makes more sense in sanitize_mcr, together with the WA label. You can make it a bit more verbose with the info in the commit message. Something like this: /* * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl * Before any MMIO read into slice/subslice specific registers, MCR * packet control register needs to be programmed to point to any * enabled s/ss pair. Otherwise, incorrect values will be returned. * This means each subsequent MMIO read will be forwarded to an * specific s/ss combination, but this is OK since these registers * are consistent across s/ss in almost all cases. In the rare * occasions, such as INSTDONE, where this value is dependent * on s/ss combo, the read shoud be done with read_subslice_reg. */ I don't think any other comment is required here. Apart from the answer to the earlier question, what mmio read after this point? If all slice/subslice register access is through this function, what are you trying to protect? Very curious. -Chris The problem is that the BSpec does not have a comprehensive list of registers that live in the slice/subslice, so it's difficult to know when this is going to become a problem. For example, I know from previous experience that the MOCS tables are replicated across slices (that's why we couldn't let UMD decide when to shutdown them: because the MOCS tables get lost as soon as you reconfigure the number of s/ss. The only way to do this in by poking in the context, so that the MOCS gets reprogrammed immediately after). ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Enabling content-type setting for HDMI displays.
== Series Details == Series: Enabling content-type setting for HDMI displays. URL : https://patchwork.freedesktop.org/series/41876/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4065_full -> Patchwork_8730_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8730_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8730_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41876/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8730_full: === IGT changes === Warnings igt@gem_exec_schedule@deep-vebox: shard-kbl: PASS -> SKIP +1 igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS +3 == Known issues == Here are the changes found in Patchwork_8730_full that come from known issues: === IGT changes === Issues hit igt@kms_color@pipe-a-legacy-gamma: shard-kbl: PASS -> DMESG-WARN (fdo#105602, fdo#103558) +18 igt@kms_flip@modeset-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) igt@kms_sysfs_edid_timing: shard-apl: PASS -> WARN (fdo#100047) Possible fixes igt@gem_eio@in-flight-suspend: shard-kbl: DMESG-WARN (fdo#103313) -> PASS igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: INCOMPLETE (fdo#103665, fdo#106023) -> PASS igt@kms_cursor_crc@cursor-256x85-offscreen: shard-hsw: DMESG-FAIL -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-pgflip-blt: shard-kbl: DMESG-WARN (fdo#105602, fdo#103558) -> PASS +20 igt@kms_frontbuffer_tracking@fbc-farfromfence: shard-kbl: DMESG-WARN (fdo#105602, fdo#103313, fdo#103558) -> PASS +4 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103313 https://bugs.freedesktop.org/show_bug.cgi?id=103313 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 4) == Missing(5): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-glkb == Build changes == * Linux: CI_DRM_4065 -> Patchwork_8730 CI_DRM_4065: c7cec67f9e1da120bc3b8782bb8013b285789c96 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8730: 73070dc1a0d9ce14dcda607deb37f2eb9e4f6061 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8730/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/fbdev: Enable late fbdev initial configuration
On Wed, 2018-04-18 at 09:26 +0100, Chris Wilson wrote: > Quoting Souza, Jose (2018-04-18 01:07:16) > > On Wed, 2018-04-18 at 00:44 +0100, Chris Wilson wrote: > > > Quoting José Roberto de Souza (2018-04-17 23:34:18) > > > > If the initial fbdev > > > > configuration(intel_fbdev_initial_config()) > > > > runs and > > > > there still no sink connected it will cause > > > > drm_fb_helper_initial_config() to return 0 as no error > > > > happened(but > > > > internally the return is -EAGAIN). > > > > Because no framebuffer was allocated, when a sink is connected > > > > intel_fbdev_output_poll_changed() will not execute > > > > drm_fb_helper_hotplug_event() that would trigger another try to > > > > do > > > > the > > > > initial fbdev configuration. > > > > > > > > So here creating a dummy framebuffer of 800x600, so > > > > drm_fb_helper_hotplug_event() will be executed and fbdev can be > > > > properly > > > > setup when a sink is connected, if needed the dummy framebuffer > > > > will be > > > > freed and a new with the proper size will be allocated. > > > > > > > > This issue also happens when a MST DP sink is connected since > > > > boot, > > > > as > > > > the MST topology is discovered in parallel if > > > > intel_fbdev_initial_config() > > > > is executed before the first sink MST is discovered it will > > > > cause > > > > this > > > > same issue. > > > > > > > > This is a follow up patch of > > > > https://patchwork.freedesktop.org/patch/196089/ > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158 > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425 > > > > Cc: Chris Wilson > > > > Cc: Rodrigo Vivi > > > > Signed-off-by: José Roberto de Souza > > > > --- > > > > drivers/gpu/drm/i915/intel_fbdev.c | 24 > > > > +++- > > > > 1 file changed, 23 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > > > > b/drivers/gpu/drm/i915/intel_fbdev.c > > > > index 7d41d139341b..773577d39782 100644 > > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > > > @@ -696,14 +696,36 @@ int intel_fbdev_init(struct drm_device > > > > *dev) > > > > return 0; > > > > } > > > > > > > > +static void intel_fbdev_dummy_fb_create(struct intel_fbdev > > > > *ifbdev) > > > > +{ > > > > + struct drm_fb_helper_surface_size sizes; > > > > + > > > > + sizes.fb_width = 800; > > > > + sizes.fb_height = 600; > > > > + sizes.surface_width = sizes.fb_width; > > > > + sizes.surface_height = sizes.fb_height; > > > > + sizes.surface_bpp = 32; > > > > + sizes.surface_depth = 24; > > > > + > > > > + if (intelfb_create(&ifbdev->helper, &sizes)) > > > > + DRM_ERROR("Unable to create dummy framebufer"); > > > > +} > > > > + > > > > static void intel_fbdev_initial_config(void *data, > > > > async_cookie_t > > > > cookie) > > > > { > > > > struct intel_fbdev *ifbdev = data; > > > > > > > > /* Due to peculiar init order wrt to hpd handling this > > > > is > > > > separate. */ > > > > if (drm_fb_helper_initial_config(&ifbdev->helper, > > > > -ifbdev- > > > > >preferred_bpp)) > > > > +ifbdev- > > > > >preferred_bpp)) { > > > > intel_fbdev_unregister(to_i915(ifbdev- > > > > > helper.dev)); > > > > > > > > + return; > > > > + } > > > > + > > > > + mutex_lock(&ifbdev->helper.lock); > > > > + if (!ifbdev->vma) > > > > + intel_fbdev_dummy_fb_create(ifbdev); > > > > + mutex_unlock(&ifbdev->helper.lock); > > > > } > > > > > > Did you try > > > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > > > b/drivers/gpu/drm/i915/intel_fbdev.c > > > index 65a3313723c9..4120c635742d 100644 > > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > > @@ -493,6 +493,7 @@ static bool intel_fb_initial_config(struct > > > drm_fb_helper *fb_helper, > > > bail: > > > DRM_DEBUG_KMS("Not using firmware > > > configuration\n"); > > > memcpy(enabled, save_enabled, count); > > > + fb_helper->deferred_setup = true; > > > > This is too earlier to set deferred_setup when > > intel_fb_initial_config() fails, > > __drm_fb_helper_initial_config_and_unlock() will then try to > > probe/create a fb but as there is no sink connected it will fail > > too. > > > > Also __drm_fb_helper_initial_config_and_unlock() is already setting > > deferred_setup if both attempts fails. > > So... > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > b/drivers/gpu/drm/i915/intel_fbdev.c > index 7d41d139341b..5f138a03dd2a 100644 > --- a/drivers/gpu/drm/i915/intel_fbdev.c > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > @@ -807,7 +807,7 @@ void intel_fbdev_output_poll_changed(struct > drm_device *dev) > re
Re: [Intel-gfx] [PATCH v9 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads
On 4/17/2018 3:59 PM, Yunwei Zhang wrote: L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0 instead of correct values. However, this is not going to be the case in any production silicon. Therefore, we only check at initialization and issue a warning should this really happen. References: HSDES#1405586840 v2: - use fls instead of find_last_bit (Chris) - use is_power_of_2() instead of counting bit set (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Move local variable into scope where they are used (Ursulin) - use a new local variable to reduce long line of code (Ursulin) v6: - Some coding style and use more local variables for clearer logic (Ursulin) v7: - Rebased. v8: - Reviewed by Oscar. v9: - Fixed label location. (Oscar) Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Yunwei Zhang Reviewed-by: Oscar Mateo --- drivers/gpu/drm/i915/i915_reg.h | 4 drivers/gpu/drm/i915/intel_device_info.c | 23 +++ 2 files changed, 27 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index fb10602..6c9c01b 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2709,6 +2709,10 @@ enum i915_power_well_id { #define GEN10_F2_SS_DIS_SHIFT 18 #define GEN10_F2_SS_DIS_MASK(0xf << GEN10_F2_SS_DIS_SHIFT) +#define GEN10_MIRROR_FUSE3 _MMIO(0x9118) +#define GEN10_L3BANK_PAIR_COUNT 4 +#define GEN10_L3BANK_MASK 0x0F + #define GEN8_EU_DISABLE0 _MMIO(0x9134) #define GEN8_EU_DIS0_S0_MASK0xff #define GEN8_EU_DIS0_S1_SHIFT 24 diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index 1a4288f..530b6ba 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -729,6 +729,29 @@ static void sanitize_mcr(struct intel_device_info *info) u32 slice = fls(info->sseu.slice_mask); u32 subslice = fls(info->sseu.subslice_mask[slice]); + /* +* WaProgramMgsrForL3BankSpecificMmioReads: cnl,icl +* L3Banks could be fused off in single slice scenario, however, if +* more than one slice is enabled, this should not happen. +*/ + if (is_power_of_2(info->sseu.slice_mask)) { This WA is only required for GEN >= 10. In other GENs, GEN10_MIRROR_FUSE3 does not even exist! + /* +* read FUSE3 for enabled L3 Bank IDs, if L3 Bank matches +* enabled subslice, no need to redirect MCR packet +*/ + u32 fuse3 = I915_READ(GEN10_MIRROR_FUSE3); + u8 ss_mask = info->sseu.subslice_mask[slice]; + + u8 enabled_mask = (ss_mask | ss_mask >> 4) & 0xf; + u8 disabled_mask = fuse3 & 0xf; + You defined GEN10_L3BANK_MASK. Might as well use it :) + /* +* Production silicon should have matched L3Bank and +* subslice enabled +*/ + WARN_ON((enabled_mask & disabled_mask) != enabled_mask); + } + if (INTEL_GEN(dev_priv) >= 11) { mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
Quoting Oscar Mateo (2018-04-18 17:30:41) > > > On 4/17/2018 3:58 PM, Yunwei Zhang wrote: > > + /* > > + * HW expects MCR to be programed to a enabled slice/subslice pair > > + * before any MMIO read into slice/subslice register > > + */ > > The comment above makes more sense in sanitize_mcr, together with the WA > label. You can make it a bit more verbose with the info in the commit > message. Something like this: > > /* > * WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl > * Before any MMIO read into slice/subslice specific registers, MCR > * packet control register needs to be programmed to point to any > * enabled s/ss pair. Otherwise, incorrect values will be returned. > * This means each subsequent MMIO read will be forwarded to an > * specific s/ss combination, but this is OK since these registers > * are consistent across s/ss in almost all cases. In the rare > * occasions, such as INSTDONE, where this value is dependent > * on s/ss combo, the read shoud be done with read_subslice_reg. > */ > > I don't think any other comment is required here. Apart from the answer to the earlier question, what mmio read after this point? If all slice/subslice register access is through this function, what are you trying to protect? Very curious. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Don't use -ETIMEDOUT from inside a test
== Series Details == Series: drm/i915/selftests: Don't use -ETIMEDOUT from inside a test URL : https://patchwork.freedesktop.org/series/41828/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4065_full -> Patchwork_8728_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_8728_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8728_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/41828/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8728_full: === IGT changes === Warnings igt@kms_atomic@atomic_invalid_params: shard-snb: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_8728_full that come from known issues: === IGT changes === Issues hit igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-hsw: PASS -> FAIL (fdo#102887) igt@kms_flip@2x-modeset-vs-vblank-race: shard-hsw: PASS -> FAIL (fdo#103060) igt@kms_flip@2x-plain-flip-ts-check: shard-hsw: PASS -> FAIL (fdo#100368) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@kms_cursor_crc@cursor-256x85-offscreen: shard-hsw: DMESG-FAIL -> 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#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (9 -> 3) == Missing(6): shard-glk8 shard-glk6 shard-glk7 shard-glk shard-kbl shard-glkb == Build changes == * Linux: CI_DRM_4065 -> Patchwork_8728 CI_DRM_4065: c7cec67f9e1da120bc3b8782bb8013b285789c96 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8728: 500d4881d94713807a515b0de2f6cf5125e276de @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8728/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 1/2] drm/i915: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
On 4/17/2018 3:58 PM, Yunwei Zhang wrote: WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each subsequent MMIO read will be forwarded to a specific slice/subslice combination as read is unicast. This is OK since slice/subslice specific register values are consistent in almost all cases across slice/subslice. There are rare occasions such as INSTDONE that this value will be dependent on slice/subslice combo, in such cases, we need to program 0xFDC and recover this after. This is already covered by read_subslice_reg. Also, 0xFDC will lose its information after TDR/engine reset/power state change. References: HSD#1405586840, BSID#0575 v2: - use fls() instead of find_last_bit() (Chris) - added INTEL_SSEU to extract sseu from device info. (Chris) v3: - rebase on latest tip v5: - Added references (Mika) - Change the ordered of passing arguments and etc. (Ursulin) v7: - Rebased. v8: - Reviewed by Oscar - Store default MCR value instead of calculate on the run. (Oscar) v9: - Changed naming and label fixes. (Oscar) - Store only the selector instead of whole MCR. (Oscar) Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin Signed-off-by: Yunwei Zhang Reviewed-by: Oscar Mateo --- drivers/gpu/drm/i915/intel_device_info.c | 35 drivers/gpu/drm/i915/intel_device_info.h | 3 +++ drivers/gpu/drm/i915/intel_engine_cs.c | 14 - 3 files changed, 47 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index a32ba72..1a4288f 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/intel_device_info.c @@ -719,6 +719,39 @@ static u32 read_timestamp_frequency(struct drm_i915_private *dev_priv) return 0; } +static void sanitize_mcr(struct intel_device_info *info) +{ + struct drm_i915_private *dev_priv = + container_of(info, struct drm_i915_private, info); + u32 mcr; + u32 mcr_slice_subslice_mask; + u32 mcr_slice_subslice_select; + u32 slice = fls(info->sseu.slice_mask); + u32 subslice = fls(info->sseu.subslice_mask[slice]); + + if (INTEL_GEN(dev_priv) >= 11) { + mcr_slice_subslice_mask = GEN11_MCR_SLICE_MASK | + GEN11_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN11_MCR_SLICE(slice) | + GEN11_MCR_SUBSLICE(subslice); + } else { + mcr_slice_subslice_mask = GEN8_MCR_SLICE_MASK | + GEN8_MCR_SUBSLICE_MASK; + mcr_slice_subslice_select = GEN8_MCR_SLICE(slice) | + GEN8_MCR_SUBSLICE(subslice); + } + + mcr = I915_READ(GEN8_MCR_SELECTOR); + mcr &= ~mcr_slice_subslice_mask; + + /* WaProgramMgsrForCorrectSliceSpecificMmioReads:cnl,icl */ + if (INTEL_GEN(dev_priv) >= 10) + mcr |= mcr_slice_subslice_select; Blank line here. The I915_WRITE is both for the WA and for the sanitation of the register. + I915_WRITE(GEN8_MCR_SELECTOR, mcr); + + info->default_mcr_ss_select = mcr_slice_subslice_select; +} + /** * intel_device_info_runtime_init - initialize runtime info * @info: intel device info struct @@ -851,6 +884,8 @@ void intel_device_info_runtime_init(struct intel_device_info *info) else if (INTEL_INFO(dev_priv)->gen >= 11) gen11_sseu_info_init(dev_priv); + sanitize_mcr(info); + /* Initialize command stream timestamp frequency */ info->cs_timestamp_frequency_khz = read_timestamp_frequency(dev_priv); } diff --git a/drivers/gpu/drm/i915/intel_device_info.h b/drivers/gpu/drm/i915/intel_device_info.h index 933e316..2c47a62 100644 --- a/drivers/gpu/drm/i915/intel_device_info.h +++ b/drivers/gpu/drm/i915/intel_device_info.h @@ -176,6 +176,9 @@ struct intel_device_info { /* Slice/subslice/EU info */ struct sseu_dev_info sseu; + /* default selected slice/subslice in MCR packet control */ + u32 default_mcr_ss_select; + default_mcr_s_ss_select? (yes, I know we are not coherent with the meaning of 's' and 'ss' in many other places). u32 cs_timestamp_frequency_khz; struct color_luts { diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 1a83707..1ba2826 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -831,18 +831,22 @@ read_subslice_reg(struct drm_i915_private *dev_priv, int slice, intel_uncore_forcewake_get__l
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Move request->ctx aside
== Series Details == Series: series starting with [1/3] drm/i915: Move request->ctx aside URL : https://patchwork.freedesktop.org/series/41903/ State : failure == Summary == Applying: drm/i915: Move request->ctx aside error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_request.c). error: could not build fake ancestor Patch failed at 0001 drm/i915: Move request->ctx aside The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/crc: Only report a single overflow when a CRC fd is opened
== Series Details == Series: drm/crc: Only report a single overflow when a CRC fd is opened URL : https://patchwork.freedesktop.org/series/41897/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8737 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41897/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8737 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927) Possible fixes igt@gem_mmap_gtt@basic-small-bo-tiledx: fi-gdg-551: FAIL (fdo#102575) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (33 -> 32) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8737 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8737: e17f1c739f3f4bfe59ec5192330fdea1e109ea34 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == e17f1c739f3f drm/crc: Only report a single overflow when a CRC fd is opened == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8737/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/crc: Only report a single overflow when a CRC fd is opened
== Series Details == Series: drm/crc: Only report a single overflow when a CRC fd is opened URL : https://patchwork.freedesktop.org/series/41897/ State : warning == Summary == $ dim checkpatch origin/drm-tip e17f1c739f3f drm/crc: Only report a single overflow when a CRC fd is opened -:52: WARNING:TYPO_SPELLING: 'occured' may be misspelled - perhaps 'occurred'? #52: FILE: include/drm/drm_debugfs_crc.h:46: + * @overflow: whether an overflow occured. total: 0 errors, 1 warnings, 0 checks, 37 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for gpu: drm: i915: Change return type to vm_fault_t (rev2)
== Series Details == Series: gpu: drm: i915: Change return type to vm_fault_t (rev2) URL : https://patchwork.freedesktop.org/series/41893/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8736 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41893/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_8736 that come from known issues: === IGT changes === Issues hit igt@kms_frontbuffer_tracking@basic: fi-cnl-y3: PASS -> FAIL (fdo#103167) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927) fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 == Participating hosts (33 -> 32) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8736 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8736: 045e647f1204c28a28882560da315568d838e3ea @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == 045e647f1204 gpu: drm: i915: Change return type to vm_fault_t == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8736/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 10/11] drm: Add aspect ratio parsing in DRM layer
On 4/17/2018 11:17 PM, Ville Syrjälä wrote: On Tue, Apr 17, 2018 at 10:45:07AM +0530, Nautiyal, Ankit K wrote: On 4/6/2018 11:14 PM, Ville Syrjälä wrote: On Fri, Apr 06, 2018 at 10:55:14PM +0530, Nautiyal, Ankit K wrote: This patch is causing failure of IGT test kms_3d. The kms_3d test expects the no. of 3d modes to be 13. (The test has hard-coded value for expected no. of 3d modes as 13) But due to the addition of "matching aspect_ratio" in drm_mode_equal in this patch, the total no. of modes in the connector modelist is increased by 2, resulting in failure of assertion 'mode_count==13'. If kms_3d isn't setting the aspect ratio cap how is it affected by these changes? In drm_mode.c, the drm_mode_connector_list_update() uses drm_mode_equal, to remove duplicate modes in connector_modes from the connector->probe_modes. Earlier, it wasn't matching for aspect-ratio and was discarding two of the modes with aspect ratio, as duplicates of other modes in the list. Later, when we are pruning the modes in drm_mode_get_connector, the logic there assumes, that the modes are in a sorted order so that we just match with the last valid mode for uniqueness. This isn't the case with the spoofed edid in kms_3d. Earlier, I was thinking if we should change the no. of expected modes in kms_3d, but that's not correct approach. So finally, The pruning logic needs to be changed, to do away with any assumption and check all the modes in the list for duplicates. This however will take more time to remove duplicates. Any other suggestions on this? What are all the modes this EDID gives us? The order in which the modes are listed in the EDID should not be relevant as we sort the mode list ourselves, and thus similar modes should appear back to back on the list. So I don't really understand how we fail to discard these two modes. As we know the kms_3d test does not set the aspect ratio cap, the modes with aspect-ratios must be pruned, unless they are unique. Now the list of mode in kms_3d is something like this: ... 1280x720@60 flags 0x1c005 [3D mode - top and bottom] ->1 1280x720@60 flags 0x4005 [3D mode -frame packing] -> 2 1280x720@60 flags 0x1c005 [3D mode -top and bottom with aspect ratio]->3 1280x720@60 flags 0x4005 [3D mode frame packing with aspect ratio] ->4 ... The first two 3D modes are able to pass and are added in the drm_mode_get_connector mode list. For third mode , the 3d mode with aspect ratio, must be pruned if not unique. So we check with the last valid mode in the list (1280x720@60 flags 0x4005). Everything matches except the 3d mode flags. So it gets added to the list. For the fourth again, the mode with aspect ratio must be pruned, (not unique), but when we check with the last valid mode, the 3d flags doesn't match, and we add that also in the list. had the list been sorted by flag also: 1280x720@60 flags 0x1c005 [3D mode top and bottom] 1280x720@60 flags 0x1c005 [3D mode top and bottom with aspect ratio] 1280x720@60 flags 0x4005 [3D mode frame packing] 1280x720@60 flags 0x4005 [3D mode frame packing aspect ratio] the aspect-ratio modes would have been pruned. To avoid these scenarios, the best way is to modify the pruning logic to check against the whole list of already added modes. I will send a patch for that shortly. Regards, Ankit Regards -Ankit Perhaps this need to be handled in the test. -Regards, Ankit On 4/6/2018 10:34 PM, Nautiyal, Ankit K wrote: From: "Sharma, Shashank" Current DRM layer functions don't parse aspect ratio information while converting a user mode->kernel mode or vice versa. This causes modeset to pick mode with wrong aspect ratio, eventually causing failures in HDMI compliance test cases, due to wrong VIC. This patch adds aspect ratio information in DRM's mode conversion and mode comparision functions, to make sure kernel picks mode with right aspect ratio (as per the VIC). Background: This patch was once reviewed and merged, and later reverted due to lack of DRM cap protection. This is a re-spin of this patch, this time with DRM cap protection, to avoid aspect ratio information, when the client doesn't request for it. Review link: https://pw-emeril.freedesktop.org/patch/104068/ Background discussion: https://patchwork.kernel.org/patch/9379057/ Signed-off-by: Shashank Sharma Signed-off-by: Lin, Jia Signed-off-by: Akashdeep Sharma Reviewed-by: Jim Bride (V2) Reviewed-by: Jose Abreu (V4) Cc: Ville Syrjala Cc: Jim Bride Cc: Jose Abreu Cc: Ankit Nautiyal V3: modified the aspect-ratio check in drm_mode_equal as per new flags provided by Ville. https://patchwork.freedesktop.org/patch/188043/ V4: rebase V5: rebase V6: As recommended by Ville, avoided matching of aspect-ratio in drm_fb_helper, while trying to find a common mode among connectors for the target clone mode. V7: rebase V8: rebase V9: rebase V10: rebase --- drivers/gpu/drm/drm_fb_helper.c | 12 ++-- drivers/gpu/drm/drm_modes.c | 35 +
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for gpu: drm: i915: Change return type to vm_fault_t (rev2)
== Series Details == Series: gpu: drm: i915: Change return type to vm_fault_t (rev2) URL : https://patchwork.freedesktop.org/series/41893/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: gpu: drm: i915: Change return type to vm_fault_t -drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3656: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 gpu: drm: i915: Change return type to vm_fault_t (rev2)
== Series Details == Series: gpu: drm: i915: Change return type to vm_fault_t (rev2) URL : https://patchwork.freedesktop.org/series/41893/ State : warning == Summary == $ dim checkpatch origin/drm-tip 045e647f1204 gpu: drm: i915: Change return type to vm_fault_t -:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("")' - ie: 'commit 1c8f422059ae ("mm: change return type to vm_fault_t")' #11: Reference id -> 1c8f422059ae ("mm: change return type to total: 1 errors, 0 warnings, 0 checks, 64 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Print unadorned pointers
On 2018-04-18 05:24 AM, Alexey Brodkin wrote: > After commit ad67b74 ("printk: hash addresses printed with %p") > pointers are being hashed when printed. However, this makes > debug output completely useless. Switch to %px in order to see the > unadorned kernel pointers. My understanding of the printk pointer hashing change was to force people to think more carefully when they really need to print a kernel pointer. When it is only used to identify an object, then a hash works just fine. Most of the changes I see in amdgpu/amdkfd fall into this category. As I see it, changing all %p to %px by a script takes the thought process out of it and subverts the intention of the original pointer hashing change. Regards, Felix > > This was done with the following one-liner: > find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i > '/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} + > > Signed-off-by: Alexey Brodkin > Cc: Borislav Petkov > Cc: Tobin C. Harding > Cc: Alex Deucher > Cc: Andrey Grodzovsky > Cc: Arnd Bergmann > Cc: Benjamin Gaignard > Cc: Chen-Yu Tsai > Cc: Christian Gmeiner > Cc: "Christian König" > Cc: Cihangir Akturk > Cc: CK Hu > Cc: Daniel Vetter > Cc: Dave Airlie > Cc: David Airlie > Cc: "David (ChunMing) Zhou" > Cc: Gerd Hoffmann > Cc: Greg Kroah-Hartman > Cc: Gustavo Padovan > Cc: Harry Wentland > Cc: "Heiko Stübner" > Cc: Ingo Molnar > Cc: Jani Nikula > Cc: "Jerry (Fangzhi) Zuo" > Cc: Joonas Lahtinen > Cc: Krzysztof Kozlowski > Cc: "Leo (Sunpeng) Li" > Cc: Lucas Stach > Cc: Maarten Lankhorst > Cc: Matthias Brugger > Cc: Maxime Ripard > Cc: "Michel Dänzer" > Cc: Oded Gabbay > Cc: Philipp Zabel > Cc: Rob Clark > Cc: Rodrigo Vivi > Cc: Roger He > Cc: Roman Li > Cc: Russell King > Cc: Samuel Li > Cc: Sandy Huang > Cc: Sean Paul > Cc: Shirish S > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: Tom Lendacky > Cc: Tony Cheng > Cc: Vincent Abriou > Cc: VMware Graphics > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: etna...@lists.freedesktop.org > Cc: freedr...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Cc: virtualizat...@lists.linux-foundation.org > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 14 +++ > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c| 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_device.c| 10 ++--- > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_events.c| 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 18 - > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++ > .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 2 +- > drivers/gpu/drm/armada/armada_gem.c| 12 +++--- > drivers/gpu/drm/drm_atomic.c | 44 > +++--- > drivers/gpu/drm/drm_bufs.c | 8 ++-- > drivers/gpu/drm/drm_dp_mst_topology.c | 4 +- > drivers/gpu/drm/drm_lease.c| 6 +-- > drivers/gpu/drm/drm_lock.c | 2 +- > drivers/gpu/drm/drm_scatter.c | 4 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 +-- > drivers/gpu/drm/i810/i810_dma.c| 2 +- > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/intel_display.c | 2 +- > drivers/gpu/drm/i915/intel_guc_ct.c| 4 +- > drivers/gpu/drm/i915/intel_guc_submission.c| 2 +- > drivers/gpu/drm/i915/intel_uc_fw.c | 2 +- > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +- > drivers/gpu/drm/mga/mga_warp.c | 2 +- > drivers/gpu/drm/msm/msm_drv.c | 4 +- > drivers/gpu/drm/qxl/qxl_cmd.c | 4 +- > drivers/gpu/drm/qxl/qxl_fb.c | 2 +- > drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- > drivers/gpu/drm/radeon/radeon_display.c| 2 +- > drivers/gpu/drm/radeon/radeon_dp_mst.c | 12 +++--- > drivers/gpu/drm/radeon/radeon_object.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +- > drivers/gpu/drm/savage/savage_bci.c| 2 +- > drivers/gpu/drm/sti/sti_gdp.c | 4 +- > drivers/gpu/drm/sti/sti_mixer.c| 2 +- > drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 +- > drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +- > drivers/gpu/drm/udl/udl_fb.c
Re: [Intel-gfx] [PATCH] drm: Print unadorned pointers
On Wed, Apr 18, 2018 at 12:24:50PM +0300, Alexey Brodkin wrote: > After commit ad67b74 ("printk: hash addresses printed with %p") > pointers are being hashed when printed. However, this makes > debug output completely useless. Switch to %px in order to see the > unadorned kernel pointers. > > This was done with the following one-liner: > find drivers/gpu/drm -type f -name "*.c" -exec sed -r -i > '/DRM_DEBUG|KERN_DEBUG|pr_debug/ s/%p\b/%px/g' {} + > > Signed-off-by: Alexey Brodkin > Cc: Borislav Petkov > Cc: Tobin C. Harding > Cc: Alex Deucher > Cc: Andrey Grodzovsky > Cc: Arnd Bergmann > Cc: Benjamin Gaignard > Cc: Chen-Yu Tsai > Cc: Christian Gmeiner > Cc: "Christian König" > Cc: Cihangir Akturk > Cc: CK Hu > Cc: Daniel Vetter > Cc: Dave Airlie > Cc: David Airlie > Cc: "David (ChunMing) Zhou" > Cc: Gerd Hoffmann > Cc: Greg Kroah-Hartman > Cc: Gustavo Padovan > Cc: Harry Wentland > Cc: "Heiko Stübner" > Cc: Ingo Molnar > Cc: Jani Nikula > Cc: "Jerry (Fangzhi) Zuo" > Cc: Joonas Lahtinen > Cc: Krzysztof Kozlowski > Cc: "Leo (Sunpeng) Li" > Cc: Lucas Stach > Cc: Maarten Lankhorst > Cc: Matthias Brugger > Cc: Maxime Ripard > Cc: "Michel Dänzer" > Cc: Oded Gabbay > Cc: Philipp Zabel > Cc: Rob Clark > Cc: Rodrigo Vivi > Cc: Roger He > Cc: Roman Li > Cc: Russell King > Cc: Samuel Li > Cc: Sandy Huang > Cc: Sean Paul > Cc: Shirish S > Cc: Sinclair Yeh > Cc: Thomas Hellstrom > Cc: Tom Lendacky > Cc: Tony Cheng > Cc: Vincent Abriou > Cc: VMware Graphics > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-arm-...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: etna...@lists.freedesktop.org > Cc: freedr...@lists.freedesktop.org > Cc: amd-...@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Cc: virtualizat...@lists.linux-foundation.org > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 14 +++ > drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c| 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_device.c| 10 ++--- > drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c | 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_events.c| 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +- > drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 +- > drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 18 - > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++ > .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 2 +- > drivers/gpu/drm/armada/armada_gem.c| 12 +++--- > drivers/gpu/drm/drm_atomic.c | 44 > +++--- > drivers/gpu/drm/drm_bufs.c | 8 ++-- > drivers/gpu/drm/drm_dp_mst_topology.c | 4 +- > drivers/gpu/drm/drm_lease.c| 6 +-- > drivers/gpu/drm/drm_lock.c | 2 +- > drivers/gpu/drm/drm_scatter.c | 4 +- > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 +-- > drivers/gpu/drm/i810/i810_dma.c| 2 +- > drivers/gpu/drm/i915/i915_perf.c | 2 +- > drivers/gpu/drm/i915/intel_display.c | 2 +- > drivers/gpu/drm/i915/intel_guc_ct.c| 4 +- > drivers/gpu/drm/i915/intel_guc_submission.c| 2 +- > drivers/gpu/drm/i915/intel_uc_fw.c | 2 +- > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +- > drivers/gpu/drm/mga/mga_warp.c | 2 +- > drivers/gpu/drm/msm/msm_drv.c | 4 +- > drivers/gpu/drm/qxl/qxl_cmd.c | 4 +- > drivers/gpu/drm/qxl/qxl_fb.c | 2 +- > drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- > drivers/gpu/drm/radeon/radeon_display.c| 2 +- > drivers/gpu/drm/radeon/radeon_dp_mst.c | 12 +++--- > drivers/gpu/drm/radeon/radeon_object.c | 2 +- > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 2 +- > drivers/gpu/drm/savage/savage_bci.c| 2 +- > drivers/gpu/drm/sti/sti_gdp.c | 4 +- > drivers/gpu/drm/sti/sti_mixer.c| 2 +- > drivers/gpu/drm/sun4i/sun4i_crtc.c | 4 +- > drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +- > drivers/gpu/drm/udl/udl_fb.c | 2 +- > drivers/gpu/drm/via/via_dma.c | 4 +- > drivers/gpu/drm/via/via_irq.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c| 2 +- > 45 files changed, 120 insertions(+), 120 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c > index 1d6e1479da38..32e85fe83152 100644 > --- a/drivers
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/audio: set minimum CD clock to twice the BCLK
== Series Details == Series: drm/i915/audio: set minimum CD clock to twice the BCLK URL : https://patchwork.freedesktop.org/series/41888/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8735 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41888/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8735 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (33 -> 31) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8735 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8735: bfb500c3510f626c212169ec498ddee1413c9736 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == bfb500c3510f drm/i915/audio: set minimum CD clock to twice the BCLK == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8735/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: set minimum CD clock to twice the BCLK.
On Wed, Apr 18, 2018 at 01:49:23PM +0300, Jani Nikula wrote: > On Tue, 17 Apr 2018, "Kumar, Abhay" wrote: > > On 4/17/2018 12:06 PM, Abhay Kumar wrote: > >> In glk when device boots with only 1366x768 panel, HDA codec doesn't > >> comeup. > >> This result in no audio forever as cdclk is < 96Mhz. > >> This change will ensure CD clock to be twice of BCLK. > >> > >> v2: > >> - Address comment (Jani) > >> - New design approach > >> v3: - Typo fix on top of v1 > >> > >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937 > >> Signed-off-by: Abhay Kumar > >> --- > >> drivers/gpu/drm/i915/intel_cdclk.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c > >> b/drivers/gpu/drm/i915/intel_cdclk.c > >> index dc7db8a2caf8..6e93af4a46ea 100644 > >> --- a/drivers/gpu/drm/i915/intel_cdclk.c > >> +++ b/drivers/gpu/drm/i915/intel_cdclk.c > >> @@ -2143,7 +2143,7 @@ int intel_crtc_compute_min_cdclk(const struct > >> intel_crtc_state *crtc_state) > >>/* According to BSpec, "The CD clock frequency must be at least twice > >> * the frequency of the Azalia BCLK." and BCLK is 96 MHz by default. > >> */ > >> - if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9) > >> + if (INTEL_GEN(dev_priv) >= 9) > >>min_cdclk = max(2 * 96000, min_cdclk); > >> > >>/* > > Hi Ville, Jani, > > > > Since right version of this patch is taking time(doing modeset and > > cdclk bump) as we need to poke sound driver. Can we please get this > > v3(same as v1 with typo fix in comment) version of patch merged. > > This works all the time and will unblock Audio and lot of folks. without > > this patch audio card is not getting detected at all and blocking basic > > audio feature. > > I expanded on the code comment, rewrote the commit message, added cc: > stable, and resent the patch [1]. > > It's not a patch I much like, it's not even a complete fix, and I would > like this to be addressed properly going forward. However, the proper > fix is I think too invasive for stable, so here we are. I'm trying to at > least explain in the comment and commit message what's going on, for > posterity. > > Ville, I'm not going to push the patch without your ack, but we can't > sit on this forever either. The patch papers over the most common > failure case, for now, so perhaps it'll buy us time to find a proper > solution. While I don't particularly like this patch I also agree that it's the least risky way to go for stable. So Acked-by: Ville Syrjälä > > Abhay, if we merge this, I do expect your support in figuring out and > testing the proper fix. This is not it. I also want to see a better solution going forward. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/crc: Only report a single overflow when a CRC fd is opened
On Wed, Apr 18, 2018 at 02:51:21PM +0200, Maarten Lankhorst wrote: > This reduces the amount of spam when you debug a CRC reading > program. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gpu/drm/drm_debugfs_crc.c | 9 - > include/drm/drm_debugfs_crc.h | 3 ++- > 2 files changed, 10 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_debugfs_crc.c > b/drivers/gpu/drm/drm_debugfs_crc.c > index 9f8312137cad..5a052c511e62 100644 > --- a/drivers/gpu/drm/drm_debugfs_crc.c > +++ b/drivers/gpu/drm/drm_debugfs_crc.c > @@ -139,6 +139,7 @@ static int crtc_crc_data_count(struct drm_crtc_crc *crc) > static void crtc_crc_cleanup(struct drm_crtc_crc *crc) > { > kfree(crc->entries); > + crc->overflow = false; > crc->entries = NULL; > crc->head = 0; > crc->tail = 0; > @@ -391,8 +392,14 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool > has_frame, > tail = crc->tail; > > if (CIRC_SPACE(head, tail, DRM_CRC_ENTRIES_NR) < 1) { > + bool overflow = crc->overflow; 'was_overflow' or something to indicate this is the old value? > + > + crc->overflow = true; > spin_unlock(&crc->lock); > - DRM_ERROR("Overflow of CRC buffer, userspace reads too > slow.\n"); > + > + if (!overflow) > + DRM_ERROR("Overflow of CRC buffer, userspace reads too > slow.\n"); would make this a bit less confusing perhaps. Now it reads as "if (no overflow) DRM_ERROR("we have an overflow");" which makes no sense on the first glance. Apart from that Reviewed-by: Ville Syrjälä > + > return -ENOBUFS; > } > > diff --git a/include/drm/drm_debugfs_crc.h b/include/drm/drm_debugfs_crc.h > index 7d63b1d4adb9..b225eeb30d05 100644 > --- a/include/drm/drm_debugfs_crc.h > +++ b/include/drm/drm_debugfs_crc.h > @@ -43,6 +43,7 @@ struct drm_crtc_crc_entry { > * @lock: protects the fields in this struct > * @source: name of the currently configured source of CRCs > * @opened: whether userspace has opened the data file for reading > + * @overflow: whether an overflow occured. > * @entries: array of entries, with size of %DRM_CRC_ENTRIES_NR > * @head: head of circular queue > * @tail: tail of circular queue > @@ -52,7 +53,7 @@ struct drm_crtc_crc_entry { > struct drm_crtc_crc { > spinlock_t lock; > const char *source; > - bool opened; > + bool opened, overflow; > struct drm_crtc_crc_entry *entries; > int head, tail; > size_t values_cnt; > -- > 2.17.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/audio: set minimum CD clock to twice the BCLK
== Series Details == Series: drm/i915/audio: set minimum CD clock to twice the BCLK URL : https://patchwork.freedesktop.org/series/41888/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/audio: set minimum CD clock to twice the BCLK -O:drivers/gpu/drm/i915/intel_cdclk.c:2147:29: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_cdclk.c:2159:29: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: Add skl_check_nv12_surface for NV12
On Wed, Apr 18, 2018 at 09:38:13AM +0530, Vidya Srinivas wrote: > From: Maarten Lankhorst > > We skip src trunction/adjustments for > NV12 case and handle the sizes directly. > Without this, pipe fifo underruns are seen on APL/KBL. > > v2: For NV12, making the src coordinates multiplier of 4 > > v3: Moving all the src coords handling code for NV12 > to skl_check_nv12_surface > > Signed-off-by: Maarten Lankhorst > Signed-off-by: Vidya Srinivas > --- > drivers/gpu/drm/i915/intel_display.c | 39 > > drivers/gpu/drm/i915/intel_sprite.c | 15 ++ > 2 files changed, 50 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 925402e..b8dbaca 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -3118,6 +3118,42 @@ static int skl_check_main_surface(const struct > intel_crtc_state *crtc_state, > return 0; > } > > +static int > +skl_check_nv12_surface(const struct intel_crtc_state *crtc_state, > +struct intel_plane_state *plane_state) > +{ > + int crtc_x2 = plane_state->base.crtc_x + plane_state->base.crtc_w; > + int crtc_y2 = plane_state->base.crtc_y + plane_state->base.crtc_h; > + > + if (((plane_state->base.src_x >> 16) % 4) != 0 || > + ((plane_state->base.src_y >> 16) % 4) != 0 || > + ((plane_state->base.src_w >> 16) % 4) != 0 || > + ((plane_state->base.src_h >> 16) % 4) != 0) { > + DRM_DEBUG_KMS("src coords must be multiple of 4 for NV12\n"); > + return -EINVAL; > + } I don't really see why we should check these. The clipped coordinates are what matters. > + > + /* Clipping would cause a 1-3 pixel gap at the edge of the screen? */ > + if ((crtc_x2 > crtc_state->pipe_src_w && crtc_state->pipe_src_w % 4) || > + (crtc_y2 > crtc_state->pipe_src_h && crtc_state->pipe_src_h % 4)) { > + DRM_DEBUG_KMS("It's not possible to clip %u,%u to %u,%u\n", > + crtc_x2, crtc_y2, > + crtc_state->pipe_src_w, crtc_state->pipe_src_h); > + return -EINVAL; > + } Why should we care? The current code already plays it fast and loose and allows the dst rectangle to shrink to accomodate the hw limits. If we want to change that we should change it universally. > + > + plane_state->base.src.x1 = > + DIV_ROUND_CLOSEST(plane_state->base.src.x1, 1 << 18) << 18; > + plane_state->base.src.x2 = > + DIV_ROUND_CLOSEST(plane_state->base.src.x2, 1 << 18) << 18; > + plane_state->base.src.y1 = > + DIV_ROUND_CLOSEST(plane_state->base.src.y1, 1 << 18) << 18; > + plane_state->base.src.y2 = > + DIV_ROUND_CLOSEST(plane_state->base.src.y2, 1 << 18) << 18; Since this can now increase the size of the source rectangle our scaling factor checks are no longer 100% valid. We might end up with a scaling factor that is too high. I don't really like any of these "let's make NV12 behave special" tricks. We should make the code behave the same way for all pixel formats instead of adding format specific hacks. > + > + return 0; > +} > + > static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state) > { > const struct drm_framebuffer *fb = plane_state->base.fb; > @@ -3201,6 +3237,9 @@ int skl_check_plane_surface(const struct > intel_crtc_state *crtc_state, >* the main surface setup depends on it. >*/ > if (fb->format->format == DRM_FORMAT_NV12) { > + ret = skl_check_nv12_surface(crtc_state, plane_state); > + if (ret) > + return ret; > ret = skl_check_nv12_aux_surface(plane_state); > if (ret) > return ret; > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > b/drivers/gpu/drm/i915/intel_sprite.c > index 8b7947d..f9985fb 100644 > --- a/drivers/gpu/drm/i915/intel_sprite.c > +++ b/drivers/gpu/drm/i915/intel_sprite.c > @@ -1035,10 +1035,17 @@ intel_check_sprite_plane(struct intel_plane *plane, > return vscale; > } > > - /* Make the source viewport size an exact multiple of the > scaling factors. */ > - drm_rect_adjust_size(src, > - drm_rect_width(dst) * hscale - > drm_rect_width(src), > - drm_rect_height(dst) * vscale - > drm_rect_height(src)); > + if (fb->format->format != DRM_FORMAT_NV12) { > + /* > + * Make the source viewport size > + * an exact multiple of the scaling factors > + */ > + drm_rect_adjust_size(src, > + (drm_rect_width(dst) * hscale - > + drm_rect_width(src
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2)
== Series Details == Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2) URL : https://patchwork.freedesktop.org/series/41827/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8734 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41827/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_8734 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-ivb-3520m: PASS -> DMESG-WARN (fdo#106084) Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (33 -> 32) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8734 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8734: d45621446c373467ef2f658526ce56b70a42fba7 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == d45621446c37 drm/i915: Pack params to engine->schedule() into a struct a11ef25b82dd drm/i915: Rename priotree to sched 690cae7b1c87 drm/i915: Move the priotree struct to its own headers == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8734/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] just some guess work to findout the culprit. If this breaks then we know what do.
On Wed, 14 Feb 2018, "Kumar, Abhijeet" wrote: > On 2/14/2018 4:48 PM, Takashi Iwai wrote: >> On Wed, 14 Feb 2018 10:06:19 +0100, >> Kumar, Abhijeet wrote: >>> >>> >>> On 2/14/2018 2:17 PM, Chris Wilson wrote: Quoting Kumar, Abhijeet (2018-02-14 04:53:57) > On 2/14/2018 9:36 AM, abhijeet.ku...@intel.com wrote: > > From: Abhijeet Kumar > > --- >sound/pci/hda/hda_codec.c | 2 +- >1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > index 8c1b07e300a8..377d5719b4cd 100644 > --- a/sound/pci/hda/hda_codec.c > +++ b/sound/pci/hda/hda_codec.c > @@ -2714,7 +2714,7 @@ static unsigned int > hda_sync_power_state(struct hda_codec *codec, > int count; > > for (count = 0;count < 500; count++) { > - state = snd_hda_codec_read(codec, fg, 0, > + state = snd_hdac_codec_read(&codec->core, fg, 0, > AC_VERB_GET_POWER_STATE, > 0); > if (state & AC_PWRST_ERROR){ > msleep(20); > > > Both tests are passing on hsw and bdw devices.I can conclude that none of > my > changes Where did you run this against CI? (Due to the nature of patchwork it will not have picked this up as a new revision.) >>> You can find it here https://patchwork.freedesktop.org/series/38212/. >>> I've reverted my patch and made my changes in hda_codec inorder to >>> demonstrate my changes is not >>> breaking it. > in "ALSA: hda: Make use of core codec functions to sync power state" is " > directly" causing the regression. > As this patch series changes the previously defined sync function similar > to > the latest one (the one defined > in the defaulter patch). If you have no answer, we will apply the revert to our CI so that we do not lose coverage. >>> I guess, I don't have any issue by reverting this single patch alone >>> as i already said this patch had >>> no functional change! It just had few optimization which i believe we >>> can skip for now. :) >> Well, it still doesn't explain. The loop count is 500 and we have >> msleep(1), so it should be almost identical with the jiffies timeout. > > Even when the loop count is 500 and we have msleep(1) in earlier defined > sync function. > We dont see wait_for_suspended assertion failing. See results for rev1 here > https://patchwork.freedesktop.org/series/38188/ >> We need more investigation, in which code path the bug is triggered. > > I'm convinced.It seems like some other issue which was hidden earlier > had come into play > because of trivial code movement. It needs more triage. Can we enable > debugs logs and > try the test again? I'm afraid I dont have the hardware with me locally > right now.I'll try arranging. > Meanwhile maybe someone from CI team can help with logs ? > > https://bugs.freedesktop.org/show_bug.cgi?id=105069 This remains an issue. The regressing commit is now in v4.17-rc1. We've reverted it in our local branches to unblock CI. Can we please get some closure here, if nothing else works then please revert and go back to the drawing board. BR, Jani. > > Warm Regards, > Abhijeet >> >> >> thanks, >> >> Takashi > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op
On Wed, Apr 18, 2018 at 09:20:23AM +0300, Jani Nikula wrote: > On Wed, 18 Apr 2018, Ramalingam C wrote: > > On Tuesday 17 April 2018 11:39 PM, Ville Syrjälä wrote: > >> On Tue, Apr 17, 2018 at 02:25:32PM +0530, Ramalingam C wrote: > >>> >From Gen9 onwards Bspec says HW supports Max Bytes per single RD/WR op is > >>> 511Bytes instead of previous 256Bytes used in SW. > >>> > >>> This change allows the max bytes per op upto 511Bytes from Gen9 onwards. > >>> > >>> v2: > >>>No Change. > >>> v3: > >>>Inline function for max_xfer_size and renaming of the macro.[Jani] > >>> > >>> Cc: Jani Nikula > >>> Cc: Chris Wilson > >>> Signed-off-by: Ramalingam C > >>> --- > >>> drivers/gpu/drm/i915/i915_reg.h | 1 + > >>> drivers/gpu/drm/i915/intel_i2c.c | 11 +-- > >>> 2 files changed, 10 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/i915/i915_reg.h > >>> b/drivers/gpu/drm/i915/i915_reg.h > >>> index 475cac07d3e6..be6114a0e8ab 100644 > >>> --- a/drivers/gpu/drm/i915/i915_reg.h > >>> +++ b/drivers/gpu/drm/i915/i915_reg.h > >>> @@ -3013,6 +3013,7 @@ enum i915_power_well_id { > >>> #define GMBUS_CYCLE_STOP (4<<25) > >>> #define GMBUS_BYTE_COUNT_SHIFT 16 > >>> #define GMBUS_BYTE_COUNT_MAX 256U > >>> +#define GEN9_GMBUS_BYTE_COUNT_MAX 511U > >>> #define GMBUS_SLAVE_INDEX_SHIFT 8 > >>> #define GMBUS_SLAVE_ADDR_SHIFT 1 > >>> #define GMBUS_SLAVE_READ (1<<0) > >>> diff --git a/drivers/gpu/drm/i915/intel_i2c.c > >>> b/drivers/gpu/drm/i915/intel_i2c.c > >>> index e6875509bcd9..4367827d7661 100644 > >>> --- a/drivers/gpu/drm/i915/intel_i2c.c > >>> +++ b/drivers/gpu/drm/i915/intel_i2c.c > >>> @@ -361,6 +361,13 @@ gmbus_wait_idle(struct drm_i915_private *dev_priv) > >>> return ret; > >>> } > >>> > >>> +static inline > >>> +unsigned int gmbus_max_xfer_size(struct drm_i915_private *dev_priv) > >>> +{ > >>> + return (INTEL_GEN(dev_priv) >= 9) ? GEN9_GMBUS_BYTE_COUNT_MAX : > >>> + GMBUS_BYTE_COUNT_MAX; > >> Hmm. You sure about this 256 limit on older HW? The spec does sort of > >> say that 0-256 is the valid range, but the SPT+ docs still have that > >> same text, and the register has always had 9 bits for byte count. I > >> don't see any statements saying that they changed this in any way for > >> SPT. It only talks about >511 bytes needing the special treatment. > >> > >> If we do this the I think you should just drop the defines and put the > >> raw numbers into this function. The extra indirection just makes life > >> harder. Also pointless parens around the GEN>9 check. > > Even I couldn't get any place where BSpec says 256Bytes is the limit for > > any platform. Everywhere 9bits are used. > > And when I cross verified with other OS usage 511Bytes is used as limit > > across all platforms. > > > > Just to be cautious for not breaking any older platforms out in linux > > world, I limited the extension of the limit to the known > > and easily testable platforms at my desk (Gen9+) > > > > Do you suggest we should apply 511Bytes as max limit for all platforms? > > Do we have any means to test this new limit on all supported legacy > > platforms? > > > > Except enabling the full potential of the HW in SW, I dont see any ROI > > here as most of the GMBUS reqs are <256Bytes. > > Only in case of HDCP2.2 we need single read cycle for 538Bytes. > > > > we have couple of options here: Please share your opinion to choose one > > of them. > > 1. Just dont change the upper limit for RD/WR. Keep it as it is at > > 256Bytes. Anyway no user demands it. > > 2. As per HW capability, Change the upper limit for RD/WR to 511Bytes > > for all platforms. This is needs the functional verification on all > > legacy plat supported. > > 3. Change the upper limit for RD/WR to 511Bytes for newer platforms, say > > Gen9+. > > Please let's not change the limit for old platforms for absolutely no > gain. And if Ville insists anyway, let's leave that as a separate > follow-up change that can easily be reverted later. > > I might consider using the 511 limit only for platforms that > HAS_GMBUS_BURST_READ too. > > The original limit seems to have been added in 9535c4757b88 ("drm/i915: > cope with large i2c transfers") citing "the specs". Any recollection > anyone? Chris? "Duble buffered data register and a 9 bit counter support 0 byte to 256 Byte transfers." has always been in the spec (and still is for SPT+). -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2)
== Series Details == Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2) URL : https://patchwork.freedesktop.org/series/41827/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Move the priotree struct to its own headers Okay! Commit: drm/i915: Rename priotree to sched Okay! Commit: drm/i915: Pack params to engine->schedule() into a struct -drivers/gpu/drm/i915/selftests/../i915_drv.h:2207:33: warning: constant 0xea00 is so big it is unsigned long -drivers/gpu/drm/i915/selftests/../i915_drv.h:3655:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:2208:33: warning: constant 0xea00 is so big it is unsigned long +drivers/gpu/drm/i915/selftests/../i915_drv.h:3656: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 series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2)
== Series Details == Series: series starting with [v2,1/3] drm/i915: Move the priotree struct to its own headers (rev2) URL : https://patchwork.freedesktop.org/series/41827/ State : warning == Summary == $ dim checkpatch origin/drm-tip 690cae7b1c87 drm/i915: Move the priotree struct to its own headers -:72: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #72: new file mode 100644 -:77: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #77: FILE: drivers/gpu/drm/i915/i915_scheduler.h:1: +/* total: 0 errors, 2 warnings, 0 checks, 103 lines checked a11ef25b82dd drm/i915: Rename priotree to sched d45621446c37 drm/i915: Pack params to engine->schedule() into a struct ___ 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/icl: Adjust BSD2 semantics to mean any second VCS instance
== Series Details == Series: drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance URL : https://patchwork.freedesktop.org/series/41883/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8733 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41883/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8733 that come from known issues: === IGT changes === Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (33 -> 31) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8733 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8733: 7f451ce363f70a1962ea45efa8fc972afcbc000d @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == 7f451ce363f7 drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8733/issues.html ___ 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 v2 00/11] trace.pl fixes
On 06/03/2018 12:43, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Collection of fixes on top of John's recent work. Problems were mostly in the request split logic which had several issues both in my original version, and also after John's improvements. Handling of "incomplete" requests (the ones which received neither notify nor context complete) was also a bit incorrect. After this series it seems to work fine, famous last words. Anyway with my test data it correctly draws the timeline with no overalaps considering both merged requests and submission to port 1. I also added context colouring mode so it is easier to follow the timeline and started using hw_id for context id's for additional readability. v2: * Update for tracepoint renames. (new in series) * Remove hw_id change. (droppped from series) * Fix incomplete handling in split mode (-s). This did not work well for workloads which generate very few intel_engine_notify events. I am not that confident it is 100% correct now, but at least it doesn't crash the script and output for one other workload I had lying around looks correct. I guess the moral of the story here is split mode is not easy to get right if it is considered just a side project and more time needs to be set aside to triple-check it. John Harrison (4): scripts/trace.pl: More hash key optimisations scripts/trace.pl: Sort order scripts/trace.pl: Calculate stats only after all munging scripts/trace.pl: Simplify 'end' & 'notify' generation Tvrtko Ursulin (7): trace.pl: Catch-up with tracepoint renames From here v... trace.pl: Move sortQueue near its user trace.pl: Move min/max timestamp lookup to last loop trace.pl: Fix engine busy accounting in split mode trace.pl: Add support for colouring context execution trace.pl: Fix incomplete request handling trace.pl: Fix request split mode ... to here ^. Only six patches to review and four even don't need much thinking! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance
== Series Details == Series: drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance URL : https://patchwork.freedesktop.org/series/41883/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7f451ce363f7 drm/i915/icl: Adjust BSD2 semantics to mean any second VCS instance -:12: WARNING:TYPO_SPELLING: 'targetted' may be misspelled - perhaps 'targeted'? #12: it can be targetted by execbuf. total: 0 errors, 1 warnings, 0 checks, 36 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/fbdev: Enable late fbdev initial configuration (rev3)
== Series Details == Series: drm/i915/fbdev: Enable late fbdev initial configuration (rev3) URL : https://patchwork.freedesktop.org/series/41851/ State : failure == Summary == Applying: drm/i915/fbdev: Enable late fbdev initial configuration error: patch failed: drivers/gpu/drm/i915/intel_fbdev.c:807 error: drivers/gpu/drm/i915/intel_fbdev.c: patch does not apply error: Did you hand edit your patch? It does not apply to blobs recorded in its index. Using index info to reconstruct a base tree... Patch failed at 0001 drm/i915/fbdev: Enable late fbdev initial configuration The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Wait for vblank after register read
== Series Details == Series: drm/i915: Wait for vblank after register read URL : https://patchwork.freedesktop.org/series/41877/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4066 -> Patchwork_8731 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/41877/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_8731 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-cfl-s3: PASS -> FAIL (fdo#103481) Possible fixes igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-ivb-3520m: DMESG-WARN (fdo#106084) -> PASS fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#106084 https://bugs.freedesktop.org/show_bug.cgi?id=106084 == Participating hosts (33 -> 31) == Additional (2): fi-glk-j4005 fi-bxt-dsi Missing(4): fi-ctg-p8600 fi-ilk-m540 fi-glk-1 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4066 -> Patchwork_8731 CI_DRM_4066: e1fbca4821d0700551df233285a5c28db09fd0f6 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4441: 83ba5b7d3bde48b383df41792fc9c955a5a23bdb @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8731: e03bb4d9e64828ac5797f6750752437e0a683383 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4441: e60d247eb359f044caf0c09904da14e39d7adca1 @ git://anongit.freedesktop.org/piglit == Linux commits == e03bb4d9e648 drm/i915: Wait for vblank after register read == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8731/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Store a pointer to intel_context in i915_request
To ease the frequent and ugly pointer dance of &request->gem_context->engine[request->engine->id] during request submission, store that pointer as request->hw_context. One major advantage that we will exploit later is that this decouples the logical context state from the engine itself. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gvt/mmio_context.c | 6 +- drivers/gpu/drm/i915/gvt/mmio_context.h | 2 +- drivers/gpu/drm/i915/gvt/scheduler.c | 141 ++-- drivers/gpu/drm/i915/gvt/scheduler.h | 1 - drivers/gpu/drm/i915/i915_debugfs.c | 20 ++- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gem.c | 14 +- drivers/gpu/drm/i915/i915_gem_context.c | 19 +-- drivers/gpu/drm/i915/i915_gem_context.h | 27 +++- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- drivers/gpu/drm/i915/i915_perf.c | 28 ++-- drivers/gpu/drm/i915/i915_request.c | 23 ++- drivers/gpu/drm/i915/i915_request.h | 3 +- drivers/gpu/drm/i915/intel_engine_cs.c| 61 --- drivers/gpu/drm/i915/intel_guc_ads.c | 2 +- drivers/gpu/drm/i915/intel_guc_submission.c | 15 +- drivers/gpu/drm/i915/intel_lrc.c | 151 +++--- drivers/gpu/drm/i915/intel_lrc.h | 7 - drivers/gpu/drm/i915/intel_ringbuffer.c | 104 +++- drivers/gpu/drm/i915/intel_ringbuffer.h | 9 +- drivers/gpu/drm/i915/selftests/mock_context.c | 7 + drivers/gpu/drm/i915/selftests/mock_engine.c | 41 +++-- .../gpu/drm/i915/selftests/mock_gem_device.c | 5 + 23 files changed, 381 insertions(+), 308 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c b/drivers/gpu/drm/i915/gvt/mmio_context.c index a5bac83d53a9..708170e61625 100644 --- a/drivers/gpu/drm/i915/gvt/mmio_context.c +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c @@ -446,9 +446,9 @@ static void switch_mocs(struct intel_vgpu *pre, struct intel_vgpu *next, #define CTX_CONTEXT_CONTROL_VAL0x03 -bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id) +bool is_inhibit_context(struct intel_context *ce) { - u32 *reg_state = ctx->engine[ring_id].lrc_reg_state; + const u32 *reg_state = ce->lrc_reg_state; u32 inhibit_mask = _MASKED_BIT_ENABLE(CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT); @@ -501,7 +501,7 @@ static void switch_mmio(struct intel_vgpu *pre, * itself. */ if (mmio->in_context && - !is_inhibit_context(s->shadow_ctx, ring_id)) + !is_inhibit_context(&s->shadow_ctx->__engine[ring_id])) continue; if (mmio->mask) diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.h b/drivers/gpu/drm/i915/gvt/mmio_context.h index 0439eb8057a8..5c3b9ff9f96a 100644 --- a/drivers/gpu/drm/i915/gvt/mmio_context.h +++ b/drivers/gpu/drm/i915/gvt/mmio_context.h @@ -49,7 +49,7 @@ void intel_gvt_switch_mmio(struct intel_vgpu *pre, void intel_gvt_init_engine_mmio_context(struct intel_gvt *gvt); -bool is_inhibit_context(struct i915_gem_context *ctx, int ring_id); +bool is_inhibit_context(struct intel_context *ce); int intel_vgpu_restore_inhibit_context(struct intel_vgpu *vgpu, struct i915_request *req); diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c index f64cccb2e793..c2e440200b0c 100644 --- a/drivers/gpu/drm/i915/gvt/scheduler.c +++ b/drivers/gpu/drm/i915/gvt/scheduler.c @@ -54,11 +54,8 @@ static void set_context_pdp_root_pointer( static void update_shadow_pdps(struct intel_vgpu_workload *workload) { - struct intel_vgpu *vgpu = workload->vgpu; - int ring_id = workload->ring_id; - struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx; struct drm_i915_gem_object *ctx_obj = - shadow_ctx->engine[ring_id].state->obj; + workload->req->hw_context->state->obj; struct execlist_ring_context *shadow_ring_context; struct page *page; @@ -128,9 +125,8 @@ static int populate_shadow_context(struct intel_vgpu_workload *workload) struct intel_vgpu *vgpu = workload->vgpu; struct intel_gvt *gvt = vgpu->gvt; int ring_id = workload->ring_id; - struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx; struct drm_i915_gem_object *ctx_obj = - shadow_ctx->engine[ring_id].state->obj; + workload->req->hw_context->state->obj; struct execlist_ring_context *shadow_ring_context; struct page *page; void *dst; @@ -280,10 +276,8 @@ static int shadow_context_status_change(struct notifier_block *nb, return NOTIFY_OK; } -static void shadow_context_descriptor_update(struct i915_gem_context *ctx, -
[Intel-gfx] [PATCH 1/3] drm/i915: Move request->ctx aside
In the next patch, we want to store the intel_context pointer inside i915_request, as it is frequently access via a convoluted dance when submitting the request to hw. Having two context pointers inside i915_request leads to confusion so first rename the existing i915_gem_context pointer to i915_request.gem_context. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/gvt/scheduler.c | 4 +-- drivers/gpu/drm/i915/i915_debugfs.c | 4 +-- drivers/gpu/drm/i915/i915_gem.c | 10 +++ drivers/gpu/drm/i915/i915_gpu_error.c | 18 +++- drivers/gpu/drm/i915/i915_request.c | 8 ++--- drivers/gpu/drm/i915/i915_request.h | 2 +- drivers/gpu/drm/i915/i915_trace.h | 6 ++-- drivers/gpu/drm/i915/intel_engine_cs.c| 2 +- drivers/gpu/drm/i915/intel_guc_submission.c | 7 +++-- drivers/gpu/drm/i915/intel_lrc.c | 29 ++- drivers/gpu/drm/i915/intel_ringbuffer.c | 11 +++ .../gpu/drm/i915/selftests/intel_hangcheck.c | 5 +++- drivers/gpu/drm/i915/selftests/intel_lrc.c| 2 +- 13 files changed, 58 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c b/drivers/gpu/drm/i915/gvt/scheduler.c index f3d21849b0cb..f64cccb2e793 100644 --- a/drivers/gpu/drm/i915/gvt/scheduler.c +++ b/drivers/gpu/drm/i915/gvt/scheduler.c @@ -205,7 +205,7 @@ static int populate_shadow_context(struct intel_vgpu_workload *workload) static inline bool is_gvt_request(struct i915_request *req) { - return i915_gem_context_force_single_submission(req->ctx); + return i915_gem_context_force_single_submission(req->gem_context); } static void save_ring_hw_state(struct intel_vgpu *vgpu, int ring_id) @@ -305,7 +305,7 @@ static int copy_workload_to_ring_buffer(struct intel_vgpu_workload *workload) struct i915_request *req = workload->req; if (IS_KABYLAKE(req->i915) && - is_inhibit_context(req->ctx, req->engine->id)) + is_inhibit_context(req->gem_context, req->engine->id)) intel_vgpu_restore_inhibit_context(vgpu, req); /* allocate shadow ring buffer */ diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index e0274f41bc76..792f69e44ba5 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -539,8 +539,8 @@ static int i915_gem_object_info(struct seq_file *m, void *data) struct i915_request, client_link); rcu_read_lock(); - task = pid_task(request && request->ctx->pid ? - request->ctx->pid : file->pid, + task = pid_task(request && request->gem_context->pid ? + request->gem_context->pid : file->pid, PIDTYPE_PID); print_file_stats(m, task ? task->comm : "", stats); rcu_read_unlock(); diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 795ca83aed7a..4dba735505d4 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3108,7 +3108,7 @@ static void skip_request(struct i915_request *request) static void engine_skip_context(struct i915_request *request) { struct intel_engine_cs *engine = request->engine; - struct i915_gem_context *hung_ctx = request->ctx; + struct i915_gem_context *hung_ctx = request->gem_context; struct intel_timeline *timeline; unsigned long flags; @@ -3118,7 +3118,7 @@ static void engine_skip_context(struct i915_request *request) spin_lock(&timeline->lock); list_for_each_entry_continue(request, &engine->timeline->requests, link) - if (request->ctx == hung_ctx) + if (request->gem_context == hung_ctx) skip_request(request); list_for_each_entry(request, &timeline->requests, link) @@ -3164,11 +3164,11 @@ i915_gem_reset_request(struct intel_engine_cs *engine, } if (stalled) { - i915_gem_context_mark_guilty(request->ctx); + i915_gem_context_mark_guilty(request->gem_context); skip_request(request); /* If this context is now banned, skip all pending requests. */ - if (i915_gem_context_is_banned(request->ctx)) + if (i915_gem_context_is_banned(request->gem_context)) engine_skip_context(request); } else { /* @@ -3178,7 +3178,7 @@ i915_gem_reset_request(struct intel_engine_cs *engine, */ request = i915_gem_find_active_request(engine); if (request) { - i915_gem_context_mark_innocent(request->ctx); + i915_gem_
[Intel-gfx] [PATCH 2/3] drm/i915: Move fiddling with engine->last_retired_context
Move the knowledge about resetting the current context tracking on the engine from inside i915_gem_context.c into intel_engine_cs.c Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c | 12 ++-- drivers/gpu/drm/i915/intel_engine_cs.c | 24 drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++ 3 files changed, 28 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 74435affe23f..2fe779cab298 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -514,16 +514,8 @@ void i915_gem_contexts_lost(struct drm_i915_private *dev_priv) lockdep_assert_held(&dev_priv->drm.struct_mutex); - for_each_engine(engine, dev_priv, id) { - engine->legacy_active_context = NULL; - engine->legacy_active_ppgtt = NULL; - - if (!engine->last_retired_context) - continue; - - engine->context_unpin(engine, engine->last_retired_context); - engine->last_retired_context = NULL; - } + for_each_engine(engine, dev_priv, id) + intel_engine_lost_context(engine); } void i915_gem_contexts_fini(struct drm_i915_private *i915) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 0248d64c2a72..4749426f9cad 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -1084,6 +1084,30 @@ void intel_engines_unpark(struct drm_i915_private *i915) } } + +/** + * intel_engine_lost_context: called when the GPU is reset into unknown state + * @engine: the engine + * + * We have either reset the GPU or otherwise about to lose state tracking of + * the current GPU logical state (e.g. suspend). On next use, it is therefore + * imperative that we make no presumptions about the current state and load + * from scratch. + */ +void intel_engine_lost_context(struct intel_engine_cs *engine) +{ + struct i915_gem_context *ctx; + + lockdep_assert_held(&engine->i915->drm.struct_mutex); + + engine->legacy_active_context = NULL; + engine->legacy_active_ppgtt = NULL; + + ctx = fetch_and_zero(&engine->last_retired_context); + if (ctx) + engine->context_unpin(engine, ctx); +} + bool intel_engine_can_store_dword(struct intel_engine_cs *engine) { switch (INTEL_GEN(engine->i915)) { diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h b/drivers/gpu/drm/i915/intel_ringbuffer.h index c5e27905b0e1..1231695fb4da 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h @@ -1044,6 +1044,8 @@ bool intel_engine_has_kernel_context(const struct intel_engine_cs *engine); void intel_engines_park(struct drm_i915_private *i915); void intel_engines_unpark(struct drm_i915_private *i915); +void intel_engine_lost_context(struct intel_engine_cs *engine); + void intel_engines_reset_default_submission(struct drm_i915_private *i915); unsigned int intel_engines_has_context_isolation(struct drm_i915_private *i915); -- 2.17.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx