Re: [Intel-gfx] [RFC] drm/i915: Fix assert_plane() warning on bootup with external display
>-Original Message- >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >Sent: Tuesday, June 19, 2018 5:00 AM >To: Shaikh, Azhar >Cc: Jani Nikula ; intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx] [RFC] drm/i915: Fix assert_plane() warning on bootup >with external display > >On Mon, Jun 18, 2018 at 09:40:38PM +, Shaikh, Azhar wrote: >> >> >> >-Original Message- >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >> >Sent: Monday, June 18, 2018 4:57 AM >> >To: Jani Nikula >> >Cc: Shaikh, Azhar ; >> >intel-gfx@lists.freedesktop.org >> >Subject: Re: [Intel-gfx] [RFC] drm/i915: Fix assert_plane() warning >> >on bootup with external display >> > >> >On Mon, Jun 18, 2018 at 11:18:52AM +0300, Jani Nikula wrote: >> >> On Sun, 17 Jun 2018, Azhar Shaikh wrote: >> >> > On KBL, WHL RVPs, booting up with an external display connected, >> >> > triggers below warning. This warning is not seen during hotplug. >> >> > >> >> > [3.615226] [ cut here ] >> >> > [3.619829] plane 1A assertion failure (expected on, current off) >> >> > [3.632039] WARNING: CPU: 2 PID: 354 at >> >drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb >> >> > [3.633920] iwlwifi :00:14.3: loaded firmware version >38.c0e03d94.0 >> >op_mode iwlmvm >> >> > [3.647157] Modules linked in: iwlwifi cfg80211 btusb btrtl btbcm >btintel >> >bluetooth ecdh_generic >> >> > [3.647163] CPU: 2 PID: 354 Comm: frecon Not tainted 4.17.0-rc7- >50176- >> >g655af12d39c2 #3 >> >> > [3.647165] Hardware name: Intel Corporation CoffeeLake Client >> >Platform/WhiskeyLake U DDR4 ERB, BIOS >> >CNLSFWR1.R00.X140.B00.1804040304 04/04/2018 >> >> > [3.684509] RIP: 0010:assert_plane+0x71/0xbb >> >> > [3.764451] Call Trace: >> >> > [3.766888] intel_atomic_commit_tail+0xa97/0xb77 >> >> > [3.771569] intel_atomic_commit+0x26a/0x279 >> >> > [3.771572] drm_atomic_helper_set_config+0x5c/0x76 >> >> > [3.780670] __drm_mode_set_config_internal+0x66/0x109 >> >> > [3.780672] drm_mode_setcrtc+0x4c9/0x5cc >> >> > [3.780674] ? drm_mode_getcrtc+0x162/0x162 >> >> > [3.789774] ? drm_mode_getcrtc+0x162/0x162 >> >> > [3.798108] drm_ioctl_kernel+0x8d/0xe4 >> >> > [3.801926] drm_ioctl+0x27d/0x368 >> >> > [3.805311] ? drm_mode_getcrtc+0x162/0x162 >> >> > [3.805314] ? selinux_file_ioctl+0x14e/0x199 >> >> > [3.805317] vfs_ioctl+0x21/0x2f >> >> > [3.813812] do_vfs_ioctl+0x491/0x4b4 >> >> > [3.813813] ? security_file_ioctl+0x37/0x4b >> >> > [3.813816] ksys_ioctl+0x55/0x75 >> >> > [3.820672] __x64_sys_ioctl+0x1a/0x1e >> >> > [3.820674] do_syscall_64+0x51/0x5f >> >> > [3.820678] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> >> > [3.828221] RIP: 0033:0x7b5e04953967 >> >> > [3.835504] RSP: 002b:7fff2eafb6f8 EFLAGS: 0246 ORIG_RAX: >> >0010 >> >> > [3.835505] RAX: ffda RBX: 0002 RCX: >> >7b5e04953967 >> >> > [3.835505] RDX: 7fff2eafb730 RSI: c06864a2 RDI: >> >000f >> >> > [3.835506] RBP: 7fff2eafb720 R08: R09: >> > >> >> > [3.835507] R10: 0070 R11: 0246 R12: >> >000f >> >> > [3.879988] R13: 56bc9dd7d210 R14: 7fff2eafb730 R15: >> >c06864a2 >> >> > [3.887081] Code: 48 c7 c7 06 71 a5 be 84 c0 48 c7 c2 06 fd a3 be 48 >> >> > 89 >f9 48 >> >0f 44 ca 84 db 48 0f 45 d7 48 c7 c7 df d3 a4 be 31 c0 e8 af a0 c0 ff >> ><0f> 0b eb 2b >> >48 c7 c7 06 fd a3 be 84 c0 48 c7 c2 06 71 a5 be 48 >> >> > [3.905845] WARNING: CPU: 2 PID: 354 at >> >drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb >> >> > [3.920964] ---[ end trace dac692f4ac46391a ]--- >> >> > >> >> > The warning is seen when mode_setcrtc() is called for pipeB >> >> > during bootup and before we get a mode_setcrtc() for pipeA, while >> >> > doing >> >> > update_crtcs() in intel_atomic_commit_tail(). >> >> > Now since, plane1A is still active after commit, update_crtcs() >> >> > is done for pipeA and eventually update_plane() for plane1A. >> >> > >> >> > intel_plane_state->ctl for plane1A is not updated since >> >> > set_modecrtc() is called for pipeB. So intel_plane_state->ctl for >> >> > plane 1A >> >will be 0x0. >> >> > So doing an update_plane() for plane1A, will result in clearing >> >> > PLANE_CTL_ENABLE bit, and hence the warning. >> >> > >> >> > To fix this warning, prior to updating the PLANE_CTL register >> >> > with intel_plane_state->ctl value, read PLANE_CTL register, OR it >> >> > with intel_plane_state->ctl and then write it to PLANE_CTL >> >> > register instead of just relying on intel_plane_state->ctl value. >> >> > >> >> > Signed-off-by: Azhar Shaikh >> >> > --- >> >> > drivers/gpu/drm/i915/intel_sprite.c | 3 +++ >> >> > 1 file changed, 3 insertions(+) >> >> > >> >> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c >> >> >
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, our first pull for 4.19, over 90 patches here, probably the most important ones are for the writeback connector support. Then we have a bunch of fixes to drivers, some interesting core cleanups and new panel drivers. This contains a backmerge of drm-next due to conflicts in drm_atomic.c Please pull, Gustavo drm-misc-next-2018-06-20-1: drm-misc-next for 4.19: UAPI Changes: - Add writeback connector (Brian Starkey/Liviu Dudau) - Add "content type" property to HDMI connectors (Stanislav Lisovskiy) Cross-subsystem Changes: - some devicetree Docs update Core Changes: - Reject over-sized allocation requests early (Chris Wilson) - gem-fb-helper: Always do implicit sync (Daniel Vetter) - dma-buf cleanups (Christian König) Driver Changes: - Fixes for the otm8009a panel driver (Philippe Cornu) - Add Innolux TV123WAM panel driver support (Sandeep Panda) - Move GEM BO to drm_framebuffer in few drivers (Daniel Stone) - i915 pinning improvements (Chris Wilson) - Stop consulting plane->fb/crtc in a few drivers (Ville Syrjälä) The following changes since commit daf0678c2036c918f01e4aa6035629d2debc2f30: Merge branch 'drm-next-4.18' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-06-15 11:32:29 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-06-20-1 for you to fetch changes up to f55786faa156370374c358d186eabf2f6e32e93f: drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build (2018-06-20 17:48:24 +0100) drm-misc-next for 4.19: UAPI Changes: - Add writeback connector (Brian Starkey/Liviu Dudau) - Add "content type" property to HDMI connectors (Stanislav Lisovskiy) Cross-subsystem Changes: - some devicetree Docs update Core Changes: - Reject over-sized allocation requests early (Chris Wilson) - gem-fb-helper: Always do implicit sync (Daniel Vetter) - dma-buf cleanups (Christian König) Driver Changes: - Fixes for the otm8009a panel driver (Philippe Cornu) - Add Innolux TV123WAM panel driver support (Sandeep Panda) - Move GEM BO to drm_framebuffer in few drivers (Daniel Stone) - i915 pinning improvements (Chris Wilson) - Stop consulting plane->fb/crtc in a few drivers (Ville Syrjälä) Alexandru Gheorghe (1): drm/atomic: Set current atomic state in drm_private_state Arnd Bergmann (1): drm/sun4i: mark PM functions as __maybe_unused Brian Starkey (2): drm: Add writeback connector type drm: writeback: Add out-fences for writeback connectors Chris Wilson (5): drm/mm: Reject over-sized allocation requests early drm/mm: Add a search-by-address variant to only inspect a single hole drm/i915: Limit searching for PIN_HIGH drm/i915: Pin the ring high drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build Christian König (2): dma_buf: remove device parameter from attach callback v2 dma-buf: remove kmap_atomic interface Colin Ian King (1): drm/xen-front: fix spelling mistake: "conector" -> "connector" Dan Carpenter (1): drm/v3d: Checking for NULL vs IS_ERR() Daniel Stone (14): drm/cirrus: Place GEM BOs in drm_framebuffer drm/cirrus: cirrus_framebuffer -> drm_framebuffer drm/virtio: Place GEM BOs in drm_framebuffer drm/armada: Move GEM BO to drm_framebuffer drm/gma500: Move GEM BO to drm_framebuffer drm/msm: Move GEM BOs to drm_framebuffer drm/mtk: Remove impossible internal error drm/mtk: Move GEM BO to drm_framebuffer drm/mtk: mtk_drm_fb -> drm_framebuffer drm/rockchip: Place GEM BOs in drm_framebuffer drm/rockchip: rockchip_drm_fb -> drm_framebuffer drm/omap: Move GEM BO to drm_framebuffer drm/omap: Move buffer pitch/offset to drm_framebuffer drm/gma500: Fix Medfield for drm_framebuffer move Daniel Vetter (3): drm/fb-helper: Fix typo on kerneldoc drm/gem-fb-helper: Always do implicit sync drm/vc4: Always obey implicit sync Dave Stevenson (1): drm/vc4: Add support for SAND modifier. Eric Anholt (2): drm: Trust format_mod_supported() when it OKs a plane modifier. drm/vc4: Add missing formats to vc4_format_mod_supported(). Gerd Hoffmann (1): dma-buf: make map_atomic and map function pointers optional Gustavo Padovan (1): Merge drm-upstream/drm-next into drm-misc-next Haneen Mohammed (1): drm: Add checks for atomic_[duplicate/destroy]_state with atomic drivers Heiko Stuebner (1): drm/rockchip: vop: split out core clock enablement into separate functions Inki Dae (1): drm/bridge: sil_sii8620: do not have a dependency of RC_CORE Julia Lawall (1): drm/rockchip: lvds: add missing of_node_put Jyri Sarha (2): drm/panel: Remove drm_panel_detach() calls from all panel drivers drm/panel: Add device_link from panel
Re: [Intel-gfx] [PATCH 19/24] drm/i915/icl: store the port type for TC ports
Em Qui, 2018-06-14 às 12:59 -0700, Rodrigo Vivi escreveu:
> On Mon, May 21, 2018 at 05:25:53PM -0700, Paulo Zanoni wrote:
> > The type is detected based on the interrupt ISR bit. Once detected,
> > it's not supposed to be changed, so we have some sanity checks for
> > that.
> >
> > Cc: Animesh Manna
> > Signed-off-by: Paulo Zanoni
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/intel_display.h | 7 +++
> > drivers/gpu/drm/i915/intel_dp.c | 36
> > +++-
> > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > 3 files changed, 43 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index c88185ed7594..fcedc600706b 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -137,6 +137,13 @@ enum tc_port {
> > I915_MAX_TC_PORTS
> > };
> >
> > +enum tc_port_type {
> > + TC_PORT_UNKNOWN = 0,
> > + TC_PORT_TYPEC,
> > + TC_PORT_TBT,
> > + TC_PORT_LEGACY,
> > +};
> > +
> > enum dpio_channel {
> > DPIO_CH0,
> > DPIO_CH1
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index b477124717e7..f3d5b9eed625 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4730,6 +4730,38 @@ static bool icl_combo_port_connected(struct
> > drm_i915_private *dev_priv,
> > return I915_READ(ICP_SDE_ISR) & ICP_DDI_HOTPLUG(port);
> > }
> >
> > +static void icl_update_tc_port_type(struct drm_i915_private
> > *dev_priv,
> > + struct intel_digital_port
> > *intel_dig_port,
> > + bool is_legacy, bool is_typec,
> > bool is_tbt)
> > +{
> > + enum port port = intel_dig_port->base.port;
> > + enum tc_port_type old_type = intel_dig_port->tc_type;
> > + const char *type_str;
> > +
> > + WARN_ON(is_legacy + is_typec + is_tbt != 1);
> > +
> > + if (is_legacy) {
> > + intel_dig_port->tc_type = TC_PORT_LEGACY;
> > + type_str = "legacy";
> > + } else if (is_typec) {
> > + intel_dig_port->tc_type = TC_PORT_TYPEC;
> > + type_str = "typec";
> > + } else if (is_tbt) {
> > + intel_dig_port->tc_type = TC_PORT_TBT;
> > + type_str = "tbt";
> > + } else {
> > + return;
> > + }
> > +
> > + /* Types are not supposed to be changed at runtime. */
> > + WARN_ON(old_type != TC_PORT_UNKNOWN &&
> > + old_type != intel_dig_port->tc_type);
> > +
> > + if (old_type != intel_dig_port->tc_type)
> > + DRM_DEBUG_KMS("Port %c has TC type %s\n",
> > port_name(port),
> > + type_str);
> > +}
> > +
> > static bool icl_tc_port_connected(struct drm_i915_private
> > *dev_priv,
> > struct intel_digital_port
> > *intel_dig_port)
> > {
> > @@ -4750,10 +4782,12 @@ static bool icl_tc_port_connected(struct
> > drm_i915_private *dev_priv,
> > if (cpu_isr & tbt_bit)
> > is_tbt = true;
> >
> > - WARN_ON(is_legacy + is_typec + is_tbt > 1);
> > if (!is_legacy && !is_typec && !is_tbt)
> > return false;
> >
> > + icl_update_tc_port_type(dev_priv, intel_dig_port,
> > is_legacy, is_typec,
> > + is_tbt);
>
> I really don't like the new chain of functions this patch here
> starts.
I don't like it either, but the hardware changed in a way that is
different from every previous platform.
>
> for all other platforms the function is_port_connect returns true or
> false
> immediately. For this TC/TBT design this start a new chain that not
> only
> check if it is connected but it also updates the status... and all in
> a
> chain of function calls
We have to figure out the port type (in case it's tc) during the
hotplug anyway since that's part of the hotplug sequence, for the
DFLEXDP* dance. If we keep passing it as a local variable and opt to do
later, we'll have to re-read the ISR bits anyway and we'll have to do
it right after. I don't see how that would actually help anything: it
could only increase the risk of de-sync when functions get moved
around.
>
> I didn't check the code now actually. I just remember for one rebase
> change that I did a while ago and saw these patches. Unfortunately I
> had no better idea on when exactly call the current status when I
> looked.
>
> Probably a totally separated function that is called outside right
> always
> along with is_port_connected
>
> update_tc_port()
> is_port_connected()
This would need to be in the inverse order and it would pretty much
just re-read the ISR bits again. Doable, but wouldn't solve the main
problem you complain about: is_connected() would still do a lot more
than just reading the ISR bits, in fact it would look exactly the same
as right now except it wouldn't set dig_port->tc_type.
>
> just to keep is_port_connect as simple as it is
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size
== Series Details == Series: series starting with [1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size URL : https://patchwork.freedesktop.org/series/45129/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4355 -> Patchwork_9376 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45129/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9376 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) Possible fixes igt@gem_ctx_create@basic-files: fi-skl-gvtdvm: INCOMPLETE (fdo#105600) -> PASS igt@gem_exec_gttfill@basic: fi-byt-n2820: FAIL (fdo#106744) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-skl-6260u: INCOMPLETE (fdo#104108) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#105600 https://bugs.freedesktop.org/show_bug.cgi?id=105600 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (44 -> 37) == Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4355 -> Patchwork_9376 CI_DRM_4355: 790b4a0a01ea9d0ce73bc8f5b3f4e7b3f9a703b1 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9376: 1731b40e13ccd39106b8842f467832717d1f3554 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1731b40e13cc drm/i915/fbc: Resize CFB in non-full modeset paths 19d0c5d7fa54 drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9376/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 [1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size
== Series Details == Series: series starting with [1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size URL : https://patchwork.freedesktop.org/series/45129/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size Okay! Commit: drm/i915/fbc: Resize CFB in non-full modeset paths -drivers/gpu/drm/i915/selftests/../i915_drv.h:3690:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3692:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/fbc: Resize CFB in non-full modeset paths
A simple page flip can cause the CFB required size to increase and
if it is bigger than the currently allocated CFB it needs to be
resized to activate FBC again.
Until now this case was not being handled but CI is starting to
get some of this errors.
So here it will free the old CFB and try to allocate the required
CFB in the schedule activation work, it will happen after one vblank
so is guarantee that FBC was completed disabled and is not using CFB.
Cc: Paulo Zanoni
Signed-off-by: José Roberto de Souza
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105683
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_fbc.c | 45
2 files changed, 31 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 735f695cb889..5a5c3b9e421e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -586,6 +586,8 @@ struct intel_fbc {
} work;
const char *no_fbc_reason;
+
+ bool cfb_try_resize;
};
/*
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index eb0f95390968..62f0c99d45c2 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -41,6 +41,9 @@
#include "intel_drv.h"
#include "i915_drv.h"
+static void __intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
+static int intel_fbc_alloc_cfb(struct intel_crtc *crtc);
+
static inline bool fbc_supported(struct drm_i915_private *dev_priv)
{
return HAS_FBC(dev_priv);
@@ -446,6 +449,15 @@ static void intel_fbc_work_fn(struct work_struct *__work)
goto retry;
}
+ if (fbc->cfb_try_resize) {
+ fbc->cfb_try_resize = false;
+ __intel_fbc_cleanup_cfb(dev_priv);
+ if (intel_fbc_alloc_cfb(crtc)) {
+ fbc->no_fbc_reason = "not enough stolen memory";
+ goto out;
+ }
+ }
+
intel_fbc_hw_activate(dev_priv);
work->scheduled = false;
@@ -846,22 +858,6 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
- /* It is possible for the required CFB size change without a
-* crtc->disable + crtc->enable since it is possible to change the
-* stride without triggering a full modeset. Since we try to
-* over-allocate the CFB, there's a chance we may keep FBC enabled even
-* if this happens, but if we exceed the current CFB size we'll have to
-* disable FBC. Notice that it would be possible to disable FBC, wait
-* for a frame, free the stolen node, then try to reenable FBC in case
-* we didn't get any invalidate/deactivate calls, but this would require
-* a lot of tracking just for a specific case. If we conclude it's an
-* important case, we can implement it later. */
- if (intel_fbc_calculate_cfb_size(dev_priv, >state_cache) >
- fbc->compressed_fb.size * fbc->threshold) {
- fbc->no_fbc_reason = "CFB requirements changed";
- return false;
- }
-
/*
* Work around a problem on GEN9+ HW, where enabling FBC on a plane
* having a Y offset that isn't divisible by 4 causes FIFO underrun
@@ -873,6 +869,22 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
+ if (!drm_mm_node_allocated(>compressed_fb))
+ return false;
+
+ /* It is possible for the required CFB size change without a
+* crtc->disable + crtc->enable since it is possible to change the
+* stride without triggering a full modeset. Since we try to
+* over-allocate the CFB, there's a chance we may keep FBC enabled even
+* if this happens, but if we exceed the current CFB size we'll have to
+* resize CFB.
+*/
+ if (intel_fbc_calculate_cfb_size(dev_priv, >state_cache) >
+ (fbc->compressed_fb.size * fbc->threshold)) {
+ fbc->cfb_try_resize = true;
+ DRM_DEBUG_KMS("CFB memory requirements have changed");
+ }
+
return true;
}
@@ -1204,6 +1216,7 @@ void intel_fbc_enable(struct intel_crtc *crtc,
fbc->enabled = true;
fbc->crtc = crtc;
+ fbc->cfb_try_resize = false;
out:
mutex_unlock(>lock);
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/fbc/cnl: Add GLK and CNL+ hardware tracking size
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_fbc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index b431b6733cc1..eb0f95390968 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -714,7 +714,10 @@ static bool intel_fbc_hw_tracking_covers_screen(struct
intel_crtc *crtc)
struct intel_fbc *fbc = _priv->fbc;
unsigned int effective_w, effective_h, max_w, max_h;
- if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) {
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+ max_w = 5120;
+ max_h = 4096;
+ } else if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv)) {
max_w = 4096;
max_h = 4096;
} else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: implement icl_digital_port_connected()
Hi Paulo,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20180620]
[cannot apply to v4.18-rc1]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Anusha-Srivatsa/drm-i915-icp-Add-Interrupt-Support/20180621-052041
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x011-201824 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/intel_dp.c: In function 'icl_tc_port_connected':
>> drivers/gpu/drm/i915/intel_dp.c:4766:19: error: implicit declaration of
>> function 'ICP_TC_HOTPLUG'; did you mean 'GEN11_TC_HOTPLUG'?
>> [-Werror=implicit-function-declaration]
u32 legacy_bit = ICP_TC_HOTPLUG(tc_port);
^~
GEN11_TC_HOTPLUG
cc1: some warnings being treated as errors
vim +4766 drivers/gpu/drm/i915/intel_dp.c
4760
4761 static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
4762struct intel_digital_port
*intel_dig_port)
4763 {
4764 enum port port = intel_dig_port->base.port;
4765 enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> 4766 u32 legacy_bit = ICP_TC_HOTPLUG(tc_port);
4767 u32 typec_bit = GEN11_TC_HOTPLUG(tc_port);
4768 u32 tbt_bit = GEN11_TBT_HOTPLUG(tc_port);
4769 bool is_legacy = false, is_typec = false, is_tbt = false;
4770 u32 cpu_isr;
4771
4772 if (I915_READ(SDEISR) & legacy_bit)
4773 is_legacy = true;
4774
4775 cpu_isr = I915_READ(GEN11_DE_HPD_ISR);
4776 if (cpu_isr & typec_bit)
4777 is_typec = true;
4778 if (cpu_isr & tbt_bit)
4779 is_tbt = true;
4780
4781 WARN_ON(is_legacy + is_typec + is_tbt > 1);
4782 if (!is_legacy && !is_typec && !is_tbt)
4783 return false;
4784
4785 return true;
4786 }
4787
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/icp: Add Interrupt Support
== Series Details == Series: series starting with [1/2] drm/i915/icp: Add Interrupt Support URL : https://patchwork.freedesktop.org/series/45124/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4354 -> Patchwork_9375 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45124/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9375 that come from known issues: === IGT changes === Possible fixes igt@gem_ctx_create@basic-files: fi-kbl-7567u: INCOMPLETE -> PASS igt@gem_exec_gttfill@basic: fi-byt-n2820: FAIL (fdo#106744) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (43 -> 38) == Additional (1): fi-byt-j1900 Missing(6): fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4354 -> Patchwork_9375 CI_DRM_4354: 370dde179b55a18cdc2a32d83a9dafcea1e434f4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4527: 04afec3ccfcb35e994f2e78254ff499f6b94f097 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9375: 51fd78b85ea1794cfab59cee53d3b6ada5af8ac1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 51fd78b85ea1 drm/i915/icl: implement icl_digital_port_connected() afaa9a9ef7cb drm/i915/icp: Add Interrupt Support == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9375/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: mark expected switch fall-through
On 06/20/2018 02:06 PM, Rodrigo Vivi wrote:
On Wed, Jun 20, 2018 at 08:31:00AM -0500, Gustavo A. R. Silva wrote:
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1470102 ("Missing break in switch")
Any other advantage besides coverity?
Can't we address it by marking as "Intentional" on the tool?
Yes. The advantage of this is that it will eventually allows to enable
-Wimplicit-fallthrough, hence, enabling the compiler to trigger a
warning, which will force us to double check if we are actually missing
a break before committing the code.
The change in the code has nothing to do with the Coverity tool. The
tool is only reporting the issue, which, in this case, is a false positive.
I'm afraid there will be so many more places to add fallthrough
marks
Oh yeah, there are around 1000 similar places in the whole codebase.
There is an ongoing effort to review each case. Months ago, it used to
be around 1500 of these cases.
Thanks
--
Gustavo
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 132fe63..6a40a77 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2566,6 +2566,7 @@ int icl_calc_dp_combo_pll_link(struct drm_i915_private
*dev_priv,
switch (index) {
default:
MISSING_CASE(index);
+ /* fall through */
case 0:
link_clock = 54;
break;
--
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] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/icp: Add Interrupt Support
== Series Details == Series: series starting with [1/2] drm/i915/icp: Add Interrupt Support URL : https://patchwork.freedesktop.org/series/45122/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/intel_dp.o drivers/gpu/drm/i915/intel_dp.c: In function ‘icl_tc_port_connected’: drivers/gpu/drm/i915/intel_dp.c:4766:19: error: implicit declaration of function ‘ICP_TC_HOTPLUG’; did you mean ‘GEN11_TC_HOTPLUG’? [-Werror=implicit-function-declaration] u32 legacy_bit = ICP_TC_HOTPLUG(tc_port); ^~ GEN11_TC_HOTPLUG cc1: all warnings being treated as errors scripts/Makefile.build:317: recipe for target 'drivers/gpu/drm/i915/intel_dp.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_dp.o] Error 1 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1034: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/icp: Add Interrupt Support
This patch addresses Interrupts from south display engine (SDE).
ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC.
Introduce these registers and their intended values.
Introduce icp_irq_handler().
v2:
- remove redundant register defines.(Lucas)
- Change register names to be more consistent with
previous platforms (Lucas)
Cc: Lucas De Marchi
Cc: Paulo Zanoni
Cc: Dhinakaran Pandiyan
Cc: Ville Syrjala
Signed-off-by: Anusha Srivatsa
[Paulo: coding style bikesheds and rebases].
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 134 +++-
drivers/gpu/drm/i915/i915_reg.h | 40
2 files changed, 172 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 46aaef5..7a7c4a2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -122,6 +122,15 @@ static const u32 hpd_gen11[HPD_NUM_PINS] = {
[HPD_PORT_F] = GEN11_TC4_HOTPLUG | GEN11_TBT4_HOTPLUG
};
+static const u32 hpd_icp[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = SDE_DDIA_HOTPLUG_ICP,
+ [HPD_PORT_B] = SDE_DDIB_HOTPLUG_ICP,
+ [HPD_PORT_C] = SDE_TC1_HOTPLUG_ICP,
+ [HPD_PORT_D] = SDE_TC2_HOTPLUG_ICP,
+ [HPD_PORT_E] = SDE_TC3_HOTPLUG_ICP,
+ [HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
+};
+
/* IIR can theoretically queue up two events. Be paranoid. */
#define GEN8_IRQ_RESET_NDX(type, which) do { \
I915_WRITE(GEN8_##type##_IMR(which), 0x); \
@@ -1586,6 +1595,34 @@ static bool bxt_port_hotplug_long_detect(enum port port,
u32 val)
}
}
+static bool icp_ddi_port_hotplug_long_detect(enum port port, u32 val)
+{
+ switch (port) {
+ case PORT_A:
+ return val & ICP_DDIA_HPD_LONG_DETECT;
+ case PORT_B:
+ return val & ICP_DDIB_HPD_LONG_DETECT;
+ default:
+ return false;
+ }
+}
+
+static bool icp_tc_port_hotplug_long_detect(enum port port, u32 val)
+{
+ switch (port) {
+ case PORT_C:
+ return val & ICP_TC_HPD_LONG_DETECT(PORT_TC1);
+ case PORT_D:
+ return val & ICP_TC_HPD_LONG_DETECT(PORT_TC2);
+ case PORT_E:
+ return val & ICP_TC_HPD_LONG_DETECT(PORT_TC3);
+ case PORT_F:
+ return val & ICP_TC_HPD_LONG_DETECT(PORT_TC4);
+ default:
+ return false;
+ }
+}
+
static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
{
switch (port) {
@@ -2385,6 +2422,43 @@ static void cpt_irq_handler(struct drm_i915_private
*dev_priv, u32 pch_iir)
cpt_serr_int_handler(dev_priv);
}
+static void icp_irq_handler(struct drm_i915_private *dev_priv, u32 pch_iir)
+{
+ u32 ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
+ u32 tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
+ u32 pin_mask = 0, long_mask = 0;
+
+ if (ddi_hotplug_trigger) {
+ u32 dig_hotplug_reg;
+
+ dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_DDI);
+ I915_WRITE(SHOTPLUG_CTL_DDI, dig_hotplug_reg);
+
+ intel_get_hpd_pins(dev_priv, _mask, _mask,
+ ddi_hotplug_trigger,
+ dig_hotplug_reg, hpd_icp,
+ icp_ddi_port_hotplug_long_detect);
+ }
+
+ if (tc_hotplug_trigger) {
+ u32 dig_hotplug_reg;
+
+ dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_TC);
+ I915_WRITE(SHOTPLUG_CTL_TC, dig_hotplug_reg);
+
+ intel_get_hpd_pins(dev_priv, _mask, _mask,
+ tc_hotplug_trigger,
+ dig_hotplug_reg, hpd_icp,
+ icp_tc_port_hotplug_long_detect);
+ }
+
+ if (pin_mask)
+ intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
+
+ if (pch_iir & SDE_GMBUS_ICP)
+ gmbus_irq_handler(dev_priv);
+}
+
static void spt_irq_handler(struct drm_i915_private *dev_priv, u32 pch_iir)
{
u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT &
@@ -2804,8 +2878,11 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
I915_WRITE(SDEIIR, iir);
ret = IRQ_HANDLED;
- if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
- HAS_PCH_CNP(dev_priv))
+ if (HAS_PCH_ICP(dev_priv))
+ icp_irq_handler(dev_priv, iir);
+ else if (HAS_PCH_SPT(dev_priv) ||
+HAS_PCH_KBP(dev_priv) ||
+HAS_PCH_CNP(dev_priv))
spt_irq_handler(dev_priv, iir);
else
cpt_irq_handler(dev_priv, iir);
@@ -3584,6 +3661,9 @@ static void gen11_irq_reset(struct drm_device
[Intel-gfx] [PATCH 2/2] drm/i915/icl: implement icl_digital_port_connected()
From: Paulo Zanoni
Do like the other functions and check for the ISR bits. We have plans
to add a few more checks in this code in the next patches, that's why
it's a little more verbose than it could be.
v2:
- Change the register names, to be consistent with
the rest of the platforms.
Cc: Animesh Manna
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Signed-off-by: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 5
drivers/gpu/drm/i915/intel_dp.c | 57 +
2 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e347055..f55e889 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7093,6 +7093,7 @@ enum {
#define GEN11_TC3_HOTPLUG (1 << 18)
#define GEN11_TC2_HOTPLUG (1 << 17)
#define GEN11_TC1_HOTPLUG (1 << 16)
+#define GEN11_TC_HOTPLUG(tc_port) (1 << ((tc_port) + 16))
#define GEN11_DE_TC_HOTPLUG_MASK (GEN11_TC4_HOTPLUG | \
GEN11_TC3_HOTPLUG | \
GEN11_TC2_HOTPLUG | \
@@ -7101,6 +7102,7 @@ enum {
#define GEN11_TBT3_HOTPLUG(1 << 2)
#define GEN11_TBT2_HOTPLUG(1 << 1)
#define GEN11_TBT1_HOTPLUG(1 << 0)
+#define GEN11_TBT_HOTPLUG(tc_port)(1 << (tc_port))
#define GEN11_DE_TBT_HOTPLUG_MASK (GEN11_TBT4_HOTPLUG | \
GEN11_TBT3_HOTPLUG | \
GEN11_TBT2_HOTPLUG | \
@@ -7525,6 +7527,9 @@ enum {
#define SDE_GMBUS_ICP(1 << 23)
#define SDE_DDIB_HOTPLUG_ICP (1 << 17)
#define SDE_DDIA_HOTPLUG_ICP (1 << 16)
+#define SDE_TC_HOTPLUG_ICP(tc_port)(1 << ((tc_port) + 24))
+#define SDE_DDI_HOTPLUG_ICP(port) (1 << ((port) + 16))
+
#define SDE_DDI_MASK_ICP (SDE_DDIB_HOTPLUG_ICP | \
SDE_DDIA_HOTPLUG_ICP)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6ac6c87..224cc71 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4750,6 +4750,61 @@ static bool bxt_digital_port_connected(struct
intel_encoder *encoder)
return I915_READ(GEN8_DE_PORT_ISR) & bit;
}
+static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *intel_dig_port)
+{
+ enum port port = intel_dig_port->base.port;
+
+ return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
+}
+
+static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *intel_dig_port)
+{
+ enum port port = intel_dig_port->base.port;
+ enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
+ u32 legacy_bit = SDE_TC_HOTPLUG_ICP(tc_port);
+ u32 typec_bit = GEN11_TC_HOTPLUG(tc_port);
+ u32 tbt_bit = GEN11_TBT_HOTPLUG(tc_port);
+ bool is_legacy = false, is_typec = false, is_tbt = false;
+ u32 cpu_isr;
+
+ if (I915_READ(SDEISR) & legacy_bit)
+ is_legacy = true;
+
+ cpu_isr = I915_READ(GEN11_DE_HPD_ISR);
+ if (cpu_isr & typec_bit)
+ is_typec = true;
+ if (cpu_isr & tbt_bit)
+ is_tbt = true;
+
+ WARN_ON(is_legacy + is_typec + is_tbt > 1);
+ if (!is_legacy && !is_typec && !is_tbt)
+ return false;
+
+ return true;
+}
+
+static bool icl_digital_port_connected(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_digital_port *dig_port = enc_to_dig_port(>base);
+
+ switch (encoder->hpd_pin) {
+ case HPD_PORT_A:
+ case HPD_PORT_B:
+ return icl_combo_port_connected(dev_priv, dig_port);
+ case HPD_PORT_C:
+ case HPD_PORT_D:
+ case HPD_PORT_E:
+ case HPD_PORT_F:
+ return icl_tc_port_connected(dev_priv, dig_port);
+ default:
+ MISSING_CASE(encoder->hpd_pin);
+ return false;
+ }
+}
+
/*
* intel_digital_port_connected - is the specified port connected?
* @encoder: intel_encoder
@@ -4777,6 +4832,8 @@ bool intel_digital_port_connected(struct intel_encoder
*encoder)
return bdw_digital_port_connected(encoder);
else if (IS_GEN9_LP(dev_priv))
return bxt_digital_port_connected(encoder);
+ else if (IS_ICELAKE(dev_priv))
+ return icl_digital_port_connected(encoder);
else
return spt_digital_port_connected(encoder);
}
--
2.7.4
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH] drm/i915: Disable bh around call to tasklet
Quoting Michel Thierry (2018-06-20 21:24:04)
> On 6/20/2018 6:59 AM, Chris Wilson wrote:
> > The guc submission backends expects to only be run from (at least)
> > softirq context, but during our intel_engine_is_idle() check we would
> > call into the tasklet to make sure it was flushed. As this could occur
> > from process context, occasionally we would be caught out using a
> > wait_for_atomic() not from an atomic context:
> >
> > [ 59.939091] WARN_ON_ONCE((1) && !(preempt_count() != 0))
> > [ 59.939142] WARNING: CPU: 1 PID: 2901 at
> > drivers/gpu/drm/i915/intel_guc_submission.c:615
> > guc_submission_tasklet+0x784/0xa90 [i915]
> > [ 59.939143] Modules linked in: vgem snd_hda_codec_hdmi
> > snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal
> > intel_powerclamp coretemp crct10dif_pclmul snd_hda_intel crc32_pclmul
> > snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core e1000e snd_pcm
> > mei_me mei prime_numbers
> > [ 59.939164] CPU: 1 PID: 2901 Comm: gem_exec_schedu Tainted: G U W
> > 4.18.0-rc1-g93475d62c730-drmtip_67+ #1
> > [ 59.939165] Hardware name: System manufacturer System Product
> > Name/Z170M-PLUS, BIOS 3610 03/29/2018
> > [ 59.939188] RIP: 0010:guc_submission_tasklet+0x784/0xa90 [i915]
> > [ 59.939189] Code: fc ff ff 80 3d 2f 87 11 00 00 0f 85 80 fb ff ff 48 c7
> > c6 f8 49 40 c0 48 c7 c7 80 41 3e c0 c6 05 14 87 11 00 01 e8 2c ea d6 d3
> > <0f> 0b e9 5f fb ff ff 8b 46 38 89 cf 31 c7 83 e7 c0 75 08 39 c1 0f
> > [ 59.939253] RSP: 0018:aafe08a03c10 EFLAGS: 00010286
> > [ 59.939255] RAX: RBX: 8f9112c246f0 RCX:
> > 0001
> > [ 59.939256] RDX: 8001 RSI: 95086d8e RDI:
> >
> > [ 59.939257] RBP: 8f9112c24680 R08: 9517be77 R09:
> >
> > [ 59.939258] R10: R11: R12:
> > 8f9112c24700
> > [ 59.939259] R13: 8f9112c24700 R14: R15:
> > 8f9112c242a8
> > [ 59.939260] FS: 7fc2cc7e5980() GS:8f9136c4()
> > knlGS:
> > [ 59.939261] CS: 0010 DS: ES: CR0: 80050033
> > [ 59.939262] CR2: 7fc2cc815040 CR3: 00021f10e003 CR4:
> > 003606e0
> > [ 59.939263] DR0: DR1: DR2:
> >
> > [ 59.939264] DR3: DR6: fffe0ff0 DR7:
> > 0400
> > [ 59.939265] Call Trace:
> > [ 59.939288] ? intel_engine_is_idle+0x64/0x160 [i915]
> > [ 59.939323] ? intel_engine_dump+0x638/0x890 [i915]
> > [ 59.939327] ? seq_printf+0x49/0x70
> > [ 59.939353] ? i915_engine_info+0xc8/0x100 [i915]
> > [ 59.939356] ? drm_get_color_range_name+0x20/0x20
> > [ 59.939361] ? seq_read+0xf1/0x470
> > [ 59.939365] ? trace_hardirqs_on_caller+0xe0/0x1b0
> > [ 59.939370] ? full_proxy_read+0x51/0x80
> > [ 59.939389] ? __vfs_read+0x31/0x170
> > [ 59.939395] ? do_sys_open+0x13b/0x240
> > [ 59.939398] ? rcu_read_lock_sched_held+0x6f/0x80
> > [ 59.939401] ? vfs_read+0x9e/0x140
> > [ 59.939404] ? ksys_read+0x50/0xc0
> > [ 59.939409] ? do_syscall_64+0x55/0x190
> > [ 59.939412] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > [ 59.939420] irq event stamp: 552834
> > [ 59.939422] hardirqs last enabled at (552833): []
> > console_unlock+0x3fc/0x600
> > [ 59.939425] hardirqs last disabled at (552834): []
> > error_entry+0x7c/0x100
> > [ 59.939451] softirqs last enabled at (552614): []
> > i915_request_add+0x2e3/0x7b0 [i915]
> > [ 59.939470] softirqs last disabled at (552604): []
> > i915_request_add+0x25b/0x7b0 [i915]
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106977
> > Fixes: dd0cf235d81f ("drm/i915: Speed up idle detection by kicking the
> > tasklets")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > Cc: Mika Kuoppala
> > Cc: Michal Wajdeczko
> > Cc: Michał Winiarski
> > Cc: Michel Thierry
> > ---
> > drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index 32bf3a408d46..d3264bd6e9dc 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -1000,10 +1000,12 @@ bool intel_engine_is_idle(struct intel_engine_cs
> > *engine)
> > if (READ_ONCE(engine->execlists.active)) {
> > struct intel_engine_execlists *execlists = >execlists;
> >
> > + local_bh_disable();
> > if (tasklet_trylock(>tasklet)) {
> > execlists->tasklet.func(execlists->tasklet.data);
> > tasklet_unlock(>tasklet);
> > }
> > + local_bh_enable();
>
> It could be just when USES_GUC_SUBMISSION is true, but nothing wrong
> with this.
Could do, but I think it's simpler overall if we say that tasklets are
[Intel-gfx] [PATCH 1/2] drm/i915/icp: Add Interrupt Support
This patch addresses Interrupts from south display engine (SDE).
ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC.
Introduce these registers and their intended values.
Introduce icp_irq_handler().
v2:
- remove redundant register defines.(Lucas)
- Change register names to be more consistent with
previous platforms (Lucas)
Cc: Lucas De Marchi
Cc: Paulo Zanoni
Cc: Dhinakaran Pandiyan
Cc: Ville Syrjala
Signed-off-by: Anusha Srivatsa
[Paulo: coding style bikesheds and rebases].
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 134 +++-
drivers/gpu/drm/i915/i915_reg.h | 40
2 files changed, 172 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 46aaef5..7a7c4a2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -122,6 +122,15 @@ static const u32 hpd_gen11[HPD_NUM_PINS] = {
[HPD_PORT_F] = GEN11_TC4_HOTPLUG | GEN11_TBT4_HOTPLUG
};
+static const u32 hpd_icp[HPD_NUM_PINS] = {
+ [HPD_PORT_A] = SDE_DDIA_HOTPLUG_ICP,
+ [HPD_PORT_B] = SDE_DDIB_HOTPLUG_ICP,
+ [HPD_PORT_C] = SDE_TC1_HOTPLUG_ICP,
+ [HPD_PORT_D] = SDE_TC2_HOTPLUG_ICP,
+ [HPD_PORT_E] = SDE_TC3_HOTPLUG_ICP,
+ [HPD_PORT_F] = SDE_TC4_HOTPLUG_ICP
+};
+
/* IIR can theoretically queue up two events. Be paranoid. */
#define GEN8_IRQ_RESET_NDX(type, which) do { \
I915_WRITE(GEN8_##type##_IMR(which), 0x); \
@@ -1586,6 +1595,34 @@ static bool bxt_port_hotplug_long_detect(enum port port,
u32 val)
}
}
+static bool icp_ddi_port_hotplug_long_detect(enum port port, u32 val)
+{
+ switch (port) {
+ case PORT_A:
+ return val & ICP_DDIA_HPD_LONG_DETECT;
+ case PORT_B:
+ return val & ICP_DDIB_HPD_LONG_DETECT;
+ default:
+ return false;
+ }
+}
+
+static bool icp_tc_port_hotplug_long_detect(enum port port, u32 val)
+{
+ switch (port) {
+ case PORT_C:
+ return val & ICP_TC_HPD_LONG_DETECT(PORT_TC1);
+ case PORT_D:
+ return val & ICP_TC_HPD_LONG_DETECT(PORT_TC2);
+ case PORT_E:
+ return val & ICP_TC_HPD_LONG_DETECT(PORT_TC3);
+ case PORT_F:
+ return val & ICP_TC_HPD_LONG_DETECT(PORT_TC4);
+ default:
+ return false;
+ }
+}
+
static bool spt_port_hotplug2_long_detect(enum port port, u32 val)
{
switch (port) {
@@ -2385,6 +2422,43 @@ static void cpt_irq_handler(struct drm_i915_private
*dev_priv, u32 pch_iir)
cpt_serr_int_handler(dev_priv);
}
+static void icp_irq_handler(struct drm_i915_private *dev_priv, u32 pch_iir)
+{
+ u32 ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
+ u32 tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
+ u32 pin_mask = 0, long_mask = 0;
+
+ if (ddi_hotplug_trigger) {
+ u32 dig_hotplug_reg;
+
+ dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_DDI);
+ I915_WRITE(SHOTPLUG_CTL_DDI, dig_hotplug_reg);
+
+ intel_get_hpd_pins(dev_priv, _mask, _mask,
+ ddi_hotplug_trigger,
+ dig_hotplug_reg, hpd_icp,
+ icp_ddi_port_hotplug_long_detect);
+ }
+
+ if (tc_hotplug_trigger) {
+ u32 dig_hotplug_reg;
+
+ dig_hotplug_reg = I915_READ(SHOTPLUG_CTL_TC);
+ I915_WRITE(SHOTPLUG_CTL_TC, dig_hotplug_reg);
+
+ intel_get_hpd_pins(dev_priv, _mask, _mask,
+ tc_hotplug_trigger,
+ dig_hotplug_reg, hpd_icp,
+ icp_tc_port_hotplug_long_detect);
+ }
+
+ if (pin_mask)
+ intel_hpd_irq_handler(dev_priv, pin_mask, long_mask);
+
+ if (pch_iir & SDE_GMBUS_ICP)
+ gmbus_irq_handler(dev_priv);
+}
+
static void spt_irq_handler(struct drm_i915_private *dev_priv, u32 pch_iir)
{
u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_SPT &
@@ -2804,8 +2878,11 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
I915_WRITE(SDEIIR, iir);
ret = IRQ_HANDLED;
- if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
- HAS_PCH_CNP(dev_priv))
+ if (HAS_PCH_ICP(dev_priv))
+ icp_irq_handler(dev_priv, iir);
+ else if (HAS_PCH_SPT(dev_priv) ||
+HAS_PCH_KBP(dev_priv) ||
+HAS_PCH_CNP(dev_priv))
spt_irq_handler(dev_priv, iir);
else
cpt_irq_handler(dev_priv, iir);
@@ -3584,6 +3661,9 @@ static void gen11_irq_reset(struct drm_device
[Intel-gfx] [PATCH 2/2] drm/i915/icl: implement icl_digital_port_connected()
From: Paulo Zanoni
Do like the other functions and check for the ISR bits. We have plans
to add a few more checks in this code in the next patches, that's why
it's a little more verbose than it could be.
v2:
- Change the register names, to be consistent with
the rest of the platforms.
Cc: Animesh Manna
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Signed-off-by: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h | 5
drivers/gpu/drm/i915/intel_dp.c | 57 +
2 files changed, 62 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e347055..f55e889 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7093,6 +7093,7 @@ enum {
#define GEN11_TC3_HOTPLUG (1 << 18)
#define GEN11_TC2_HOTPLUG (1 << 17)
#define GEN11_TC1_HOTPLUG (1 << 16)
+#define GEN11_TC_HOTPLUG(tc_port) (1 << ((tc_port) + 16))
#define GEN11_DE_TC_HOTPLUG_MASK (GEN11_TC4_HOTPLUG | \
GEN11_TC3_HOTPLUG | \
GEN11_TC2_HOTPLUG | \
@@ -7101,6 +7102,7 @@ enum {
#define GEN11_TBT3_HOTPLUG(1 << 2)
#define GEN11_TBT2_HOTPLUG(1 << 1)
#define GEN11_TBT1_HOTPLUG(1 << 0)
+#define GEN11_TBT_HOTPLUG(tc_port)(1 << (tc_port))
#define GEN11_DE_TBT_HOTPLUG_MASK (GEN11_TBT4_HOTPLUG | \
GEN11_TBT3_HOTPLUG | \
GEN11_TBT2_HOTPLUG | \
@@ -7525,6 +7527,9 @@ enum {
#define SDE_GMBUS_ICP(1 << 23)
#define SDE_DDIB_HOTPLUG_ICP (1 << 17)
#define SDE_DDIA_HOTPLUG_ICP (1 << 16)
+#define SDE_TC_HOTPLUG_ICP(tc_port)(1 << ((tc_port) + 24))
+#define SDE_DDI_HOTPLUG_ICP(port) (1 << ((port) + 16))
+
#define SDE_DDI_MASK_ICP (SDE_DDIB_HOTPLUG_ICP | \
SDE_DDIA_HOTPLUG_ICP)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6ac6c87..cc6c190 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4750,6 +4750,61 @@ static bool bxt_digital_port_connected(struct
intel_encoder *encoder)
return I915_READ(GEN8_DE_PORT_ISR) & bit;
}
+static bool icl_combo_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *intel_dig_port)
+{
+ enum port port = intel_dig_port->base.port;
+
+ return I915_READ(SDEISR) & SDE_DDI_HOTPLUG_ICP(port);
+}
+
+static bool icl_tc_port_connected(struct drm_i915_private *dev_priv,
+ struct intel_digital_port *intel_dig_port)
+{
+ enum port port = intel_dig_port->base.port;
+ enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
+ u32 legacy_bit = ICP_TC_HOTPLUG(tc_port);
+ u32 typec_bit = GEN11_TC_HOTPLUG(tc_port);
+ u32 tbt_bit = GEN11_TBT_HOTPLUG(tc_port);
+ bool is_legacy = false, is_typec = false, is_tbt = false;
+ u32 cpu_isr;
+
+ if (I915_READ(SDEISR) & legacy_bit)
+ is_legacy = true;
+
+ cpu_isr = I915_READ(GEN11_DE_HPD_ISR);
+ if (cpu_isr & typec_bit)
+ is_typec = true;
+ if (cpu_isr & tbt_bit)
+ is_tbt = true;
+
+ WARN_ON(is_legacy + is_typec + is_tbt > 1);
+ if (!is_legacy && !is_typec && !is_tbt)
+ return false;
+
+ return true;
+}
+
+static bool icl_digital_port_connected(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ struct intel_digital_port *dig_port = enc_to_dig_port(>base);
+
+ switch (encoder->hpd_pin) {
+ case HPD_PORT_A:
+ case HPD_PORT_B:
+ return icl_combo_port_connected(dev_priv, dig_port);
+ case HPD_PORT_C:
+ case HPD_PORT_D:
+ case HPD_PORT_E:
+ case HPD_PORT_F:
+ return icl_tc_port_connected(dev_priv, dig_port);
+ default:
+ MISSING_CASE(encoder->hpd_pin);
+ return false;
+ }
+}
+
/*
* intel_digital_port_connected - is the specified port connected?
* @encoder: intel_encoder
@@ -4777,6 +4832,8 @@ bool intel_digital_port_connected(struct intel_encoder
*encoder)
return bdw_digital_port_connected(encoder);
else if (IS_GEN9_LP(dev_priv))
return bxt_digital_port_connected(encoder);
+ else if (IS_ICELAKE(dev_priv))
+ return icl_digital_port_connected(encoder);
else
return spt_digital_port_connected(encoder);
}
--
2.7.4
___
Intel-gfx mailing list
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add Exec param to control data port coherency. (rev4)
== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev4) URL : https://patchwork.freedesktop.org/series/40181/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4348_full -> Patchwork_9373_full = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9373_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9373_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9373_full: === IGT changes === Possible regressions igt@gem_ctx_param@invalid-param-get: shard-apl: PASS -> FAIL +1 shard-glk: PASS -> FAIL +1 igt@gem_ctx_param@invalid-param-set: shard-kbl: PASS -> FAIL +1 shard-hsw: PASS -> FAIL +1 shard-snb: PASS -> FAIL +1 Warnings igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS +7 == Known issues == Here are the changes found in Patchwork_9373_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hugepages: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_exec_schedule@pi-ringfull-vebox: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@kms_flip@2x-flip-vs-expired-vblank: shard-hsw: PASS -> FAIL (fdo#102887) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) igt@perf@polling: shard-hsw: PASS -> FAIL (fdo#102252) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#105900) -> PASS igt@kms_flip@flip-vs-panning-vs-hang: shard-snb: DMESG-WARN (fdo#103821) -> PASS igt@kms_flip@plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-pri-shrfb-draw-mmap-wc: shard-glk: FAIL (fdo#103167, fdo#104724) -> PASS igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc: shard-kbl: FAIL (fdo#106067) -> PASS igt@perf@enable-disable: shard-kbl: DMESG-FAIL (fdo#106064) -> PASS igt@pm_rpm@system-suspend-execbuf: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@pm_rps@waitboost: shard-kbl: FAIL (fdo#102250) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: FAIL (fdo#105347) -> INCOMPLETE (fdo#103359, k.org#198133) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102250 https://bugs.freedesktop.org/show_bug.cgi?id=102250 fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106064 https://bugs.freedesktop.org/show_bug.cgi?id=106064 fdo#106067 https://bugs.freedesktop.org/show_bug.cgi?id=106067 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4348 -> Patchwork_9373 CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9373: 525e6ee946c85a6a1742df72a3e2d87695234bb1 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9373/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/24] drm/i915/icl: implement icl_digital_port_connected()
Em Ter, 2018-06-19 às 15:28 -0700, Lucas De Marchi escreveu:
> On Mon, May 21, 2018 at 05:25:52PM -0700, Paulo Zanoni wrote:
> > Do like the other functions and check for the ISR bits. We have
> > plans
> > to add a few more checks in this code in the next patches, that's
> > why
> > it's a little more verbose than it could be.
> >
> > Cc: Animesh Manna
> > Signed-off-by: Paulo Zanoni
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 5
> > drivers/gpu/drm/i915/intel_dp.c | 57
> > +
> > 2 files changed, 62 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 49a72320e794..24308d4435f5 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7055,6 +7055,7 @@ enum {
> > #define GEN11_TC3_HOTPLUG (1 << 18)
> > #define GEN11_TC2_HOTPLUG (1 << 17)
> > #define GEN11_TC1_HOTPLUG (1 << 16)
> > +#define GEN11_TC_HOTPLUG(tc_port) (1 << ((tc_port)
> > + 16))
> > #define GEN11_DE_TC_HOTPLUG_MASK (GEN11_TC4_HOTPLU
> > G | \
> > GEN11_TC3_HOTPLUG
> > | \
> > GEN11_TC2_HOTPLUG
> > | \
> > @@ -7063,6 +7064,7 @@ enum {
> > #define GEN11_TBT3_HOTPLUG(1 << 2)
> > #define GEN11_TBT2_HOTPLUG(1 << 1)
> > #define GEN11_TBT1_HOTPLUG(1 << 0)
> > +#define GEN11_TBT_HOTPLUG(tc_port)(1 <<
> > (tc_port))
> > #define GEN11_DE_TBT_HOTPLUG_MASK (GEN11_TBT4_HOTP
> > LUG | \
> > GEN11_TBT3_HOTPLU
> > G | \
> > GEN11_TBT2_HOTPLU
> > G | \
> > @@ -7486,6 +7488,9 @@ enum {
> > #define ICP_GMBUS(1 << 23)
> > #define ICP_DDIB_HOTPLUG (1 << 17)
> > #define ICP_DDIA_HOTPLUG (1 << 16)
> > +#define ICP_TC_HOTPLUG(tc_port)(1 << ((tc_port) +
> > 24))
> > +#define ICP_DDI_HOTPLUG(port) (1 << ((port) + 16))
> > +
> >
> > #define ICP_SDE_DDI_MASK (ICP_DDIB_HOTPLUG |
> > \
> > ICP_DDIA_HOTPLUG)
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 102070940095..b477124717e7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -4722,6 +4722,61 @@ static bool
> > bxt_digital_port_connected(struct intel_encoder *encoder)
> > return I915_READ(GEN8_DE_PORT_ISR) & bit;
> > }
> >
> > +static bool icl_combo_port_connected(struct drm_i915_private
> > *dev_priv,
> > +struct intel_digital_port
> > *intel_dig_port)
> > +{
> > + enum port port = intel_dig_port->base.port;
> > +
> > + return I915_READ(ICP_SDE_ISR) & ICP_DDI_HOTPLUG(port);
> > +}
> > +
> > +static bool icl_tc_port_connected(struct drm_i915_private
> > *dev_priv,
> > + struct intel_digital_port
> > *intel_dig_port)
> > +{
> > + enum port port = intel_dig_port->base.port;
> > + enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> > + u32 legacy_bit = ICP_TC_HOTPLUG(tc_port);
> > + u32 typec_bit = GEN11_TC_HOTPLUG(tc_port);
> > + u32 tbt_bit = GEN11_TBT_HOTPLUG(tc_port);
> > + bool is_legacy = false, is_typec = false, is_tbt = false;
> > + u32 cpu_isr;
>
> why *cpu*_isr? hpd_isr, isr or val would be better IMO
Because we have 2 ISR registers we check, one is on the CPU and the
other is on the PCH. We just don't have a variable for pch_isr because
we don't need. Jusc alling it "isr" or "hpd_isr" would be misleading.
>
> > +
> > + if (I915_READ(ICP_SDE_ISR) & legacy_bit)
> > + is_legacy = true;
> > +
> > + cpu_isr = I915_READ(GEN11_DE_HPD_ISR);
> > + if (cpu_isr & typec_bit)
> > + is_typec = true;
> > + if (cpu_isr & tbt_bit)
> > + is_tbt = true;
> > +
> > + WARN_ON(is_legacy + is_typec + is_tbt > 1);
> > + if (!is_legacy && !is_typec && !is_tbt)
> > + return false;
> > +
> > + return true;
>
> you know you could "return is_legacy + is_typec + is_tbt;", right?
> you
> are already doing it above, it may make sense to remove the extra
> branch. Or not.
Because the next patch adds code between the "return false" and the
last return, so I'd have to change it there.
>
> Feel free to disagree and push.
>
>
> Reviewed-by: Lucas De Marchi
Thanks,
Paulo
>
>
> Lucas De Marchi
>
> > +}
> > +
> > +static bool icl_digital_port_connected(struct intel_encoder
> > *encoder)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(encoder-
> > >base.dev);
> > + struct intel_digital_port *dig_port =
> > enc_to_dig_port(>base);
> > +
> > + switch (encoder->hpd_pin) {
> > + case HPD_PORT_A:
> > + case
Re: [Intel-gfx] [PATCH] drm/i915/psr: Fix warning in intel_psr_activate()
On Mon, 2018-06-18 at 15:27 -0700, Rodrigo Vivi wrote:
> On Mon, Jun 18, 2018 at 03:02:07PM -0700, Dhinakaran Pandiyan wrote:
> >
> > commit 5422b37c907e ("drm/i915/psr: Kill delays when activating psr
> > back.") removed the call to cancel a scheduled psr_work from
> > psr_disable() and instead added an early return in the work
> > function. But,
> > if the scheduled work item is executed after psr_enable(), we end
> > up
> > printing warnings as PSR is already enabled and active. So, put the
> > cancel_work call back in psr_disable().
> >
> > Cc: Rodrigo Vivi
> > Cc: José Roberto de Souza
> > Fixes: 5422b37c907e ("drm/i915/psr: Kill delays when activating psr
> > back.")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106948
> > Signed-off-by: Dhinakaran Pandiyan
> Reviewed-by: Rodrigo Vivi
>
> sorry and thanks for fixing it.
>
Not a problem. Thanks for the review, patch pushed to dinq
-DK
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable bh around call to tasklet
On 6/20/2018 6:59 AM, Chris Wilson wrote:
The guc submission backends expects to only be run from (at least)
softirq context, but during our intel_engine_is_idle() check we would
call into the tasklet to make sure it was flushed. As this could occur
from process context, occasionally we would be caught out using a
wait_for_atomic() not from an atomic context:
[ 59.939091] WARN_ON_ONCE((1) && !(preempt_count() != 0))
[ 59.939142] WARNING: CPU: 1 PID: 2901 at
drivers/gpu/drm/i915/intel_guc_submission.c:615
guc_submission_tasklet+0x784/0xa90 [i915]
[ 59.939143] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp
crct10dif_pclmul snd_hda_intel crc32_pclmul snd_hda_codec ghash_clmulni_intel
snd_hwdep snd_hda_core e1000e snd_pcm mei_me mei prime_numbers
[ 59.939164] CPU: 1 PID: 2901 Comm: gem_exec_schedu Tainted: G U W
4.18.0-rc1-g93475d62c730-drmtip_67+ #1
[ 59.939165] Hardware name: System manufacturer System Product
Name/Z170M-PLUS, BIOS 3610 03/29/2018
[ 59.939188] RIP: 0010:guc_submission_tasklet+0x784/0xa90 [i915]
[ 59.939189] Code: fc ff ff 80 3d 2f 87 11 00 00 0f 85 80 fb ff ff 48 c7 c6 f8 49
40 c0 48 c7 c7 80 41 3e c0 c6 05 14 87 11 00 01 e8 2c ea d6 d3 <0f> 0b e9 5f fb
ff ff 8b 46 38 89 cf 31 c7 83 e7 c0 75 08 39 c1 0f
[ 59.939253] RSP: 0018:aafe08a03c10 EFLAGS: 00010286
[ 59.939255] RAX: RBX: 8f9112c246f0 RCX: 0001
[ 59.939256] RDX: 8001 RSI: 95086d8e RDI:
[ 59.939257] RBP: 8f9112c24680 R08: 9517be77 R09:
[ 59.939258] R10: R11: R12: 8f9112c24700
[ 59.939259] R13: 8f9112c24700 R14: R15: 8f9112c242a8
[ 59.939260] FS: 7fc2cc7e5980() GS:8f9136c4()
knlGS:
[ 59.939261] CS: 0010 DS: ES: CR0: 80050033
[ 59.939262] CR2: 7fc2cc815040 CR3: 00021f10e003 CR4: 003606e0
[ 59.939263] DR0: DR1: DR2:
[ 59.939264] DR3: DR6: fffe0ff0 DR7: 0400
[ 59.939265] Call Trace:
[ 59.939288] ? intel_engine_is_idle+0x64/0x160 [i915]
[ 59.939323] ? intel_engine_dump+0x638/0x890 [i915]
[ 59.939327] ? seq_printf+0x49/0x70
[ 59.939353] ? i915_engine_info+0xc8/0x100 [i915]
[ 59.939356] ? drm_get_color_range_name+0x20/0x20
[ 59.939361] ? seq_read+0xf1/0x470
[ 59.939365] ? trace_hardirqs_on_caller+0xe0/0x1b0
[ 59.939370] ? full_proxy_read+0x51/0x80
[ 59.939389] ? __vfs_read+0x31/0x170
[ 59.939395] ? do_sys_open+0x13b/0x240
[ 59.939398] ? rcu_read_lock_sched_held+0x6f/0x80
[ 59.939401] ? vfs_read+0x9e/0x140
[ 59.939404] ? ksys_read+0x50/0xc0
[ 59.939409] ? do_syscall_64+0x55/0x190
[ 59.939412] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 59.939420] irq event stamp: 552834
[ 59.939422] hardirqs last enabled at (552833): []
console_unlock+0x3fc/0x600
[ 59.939425] hardirqs last disabled at (552834): []
error_entry+0x7c/0x100
[ 59.939451] softirqs last enabled at (552614): []
i915_request_add+0x2e3/0x7b0 [i915]
[ 59.939470] softirqs last disabled at (552604): []
i915_request_add+0x25b/0x7b0 [i915]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106977
Fixes: dd0cf235d81f ("drm/i915: Speed up idle detection by kicking the
tasklets")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Michel Thierry
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 32bf3a408d46..d3264bd6e9dc 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1000,10 +1000,12 @@ bool intel_engine_is_idle(struct intel_engine_cs
*engine)
if (READ_ONCE(engine->execlists.active)) {
struct intel_engine_execlists *execlists = >execlists;
+ local_bh_disable();
if (tasklet_trylock(>tasklet)) {
execlists->tasklet.func(execlists->tasklet.data);
tasklet_unlock(>tasklet);
}
+ local_bh_enable();
It could be just when USES_GUC_SUBMISSION is true, but nothing wrong
with this.
Reviewed-by: Michel Thierry
if (READ_ONCE(execlists->active))
return false;
___
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: Disable bh around call to tasklet
== Series Details == Series: drm/i915: Disable bh around call to tasklet URL : https://patchwork.freedesktop.org/series/45089/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4348_full -> Patchwork_9372_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9372_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9372_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9372_full: === IGT changes === Warnings igt@gem_render_linear_blits@basic: shard-kbl: SKIP -> PASS +6 igt@pm_rc6_residency@rc6-accuracy: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9372_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106560, fdo#106947) igt@gem_exec_schedule@pi-ringfull-vebox: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_frontbuffer_tracking@fbc-2p-shrfb-fliptrack: shard-glk: PASS -> FAIL (fdo#103167, fdo#104724) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#105900) -> PASS igt@kms_flip@flip-vs-panning-vs-hang: shard-snb: DMESG-WARN (fdo#103821) -> PASS igt@kms_flip@plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc: shard-kbl: FAIL (fdo#106067) -> PASS igt@perf@enable-disable: shard-kbl: DMESG-FAIL (fdo#106064) -> PASS igt@pm_rpm@system-suspend-execbuf: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@pm_rps@waitboost: shard-kbl: FAIL (fdo#102250) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: FAIL (fdo#105347) -> INCOMPLETE (k.org#198133, fdo#103359) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102250 https://bugs.freedesktop.org/show_bug.cgi?id=102250 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106064 https://bugs.freedesktop.org/show_bug.cgi?id=106064 fdo#106067 https://bugs.freedesktop.org/show_bug.cgi?id=106067 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4348 -> Patchwork_9372 CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9372: 6fae2763dc644a987ef2520e3ba41b10fce1edf6 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9372/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 drm/i915: mark expected switch fall-through
== Series Details == Series: drm/i915: mark expected switch fall-through URL : https://patchwork.freedesktop.org/series/45088/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4348_full -> Patchwork_9371_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9371_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9371_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9371_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS +7 == Known issues == Here are the changes found in Patchwork_9371_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_evict: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_exec_schedule@pi-ringfull-vebox: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@kms_flip@dpms-vs-vblank-race-interruptible: shard-glk: PASS -> FAIL (fdo#103060) igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_hangcheck: shard-apl: DMESG-FAIL (fdo#106947, fdo#106560) -> PASS igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#105900) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-panning-vs-hang: shard-snb: DMESG-WARN (fdo#103821) -> PASS igt@kms_flip@plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_flip_tiling@flip-to-x-tiled: shard-glk: FAIL (fdo#104724, fdo#103822) -> PASS +1 igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc: shard-kbl: FAIL (fdo#106067) -> PASS igt@perf@enable-disable: shard-kbl: DMESG-FAIL (fdo#106064) -> PASS igt@pm_rpm@system-suspend-execbuf: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@pm_rps@waitboost: shard-kbl: FAIL (fdo#102250) -> PASS Warnings igt@drv_selftest@live_gtt: shard-glk: FAIL (fdo#105347) -> INCOMPLETE (fdo#103359, k.org#198133) fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102250 https://bugs.freedesktop.org/show_bug.cgi?id=102250 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106064 https://bugs.freedesktop.org/show_bug.cgi?id=106064 fdo#106067 https://bugs.freedesktop.org/show_bug.cgi?id=106067 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4348 -> Patchwork_9371 CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9371: 4934357efe0e8f39afbeaba6dd3e25ee2cd790e8 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9371/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: mark expected switch fall-through
On Wed, Jun 20, 2018 at 08:31:00AM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Addresses-Coverity-ID: 1470102 ("Missing break in switch")
Any other advantage besides coverity?
Can't we address it by marking as "Intentional" on the tool?
I'm afraid there will be so many more places to add fallthrough
marks
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 132fe63..6a40a77 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2566,6 +2566,7 @@ int icl_calc_dp_combo_pll_link(struct drm_i915_private
> *dev_priv,
> switch (index) {
> default:
> MISSING_CASE(index);
> + /* fall through */
> case 0:
> link_clock = 54;
> break;
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH][next] drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us
On Wed, Jun 20, 2018 at 02:25:43PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently for the psr_table->tp2_tp3_wakeup_time case 3 there appears
> to be a copy-paste error from the previous switch statement where
> dev_priv->vbt.psr.tp1_wakeup_time_us is being assigned and I believe
> it should be dev_priv->vbt.psr.tp2_tp3_wakeup_time_us that should be
> assigned instead.
>
> Detected by CoverityScan, CID#1470105 ("Copy-paste error")
>
> Fixes: 77312ae8f071 ("drm/i915/psr: vbt change for psr")
> Signed-off-by: Colin Ian King
Reviewed-by: Rodrigo Vivi
pushing to dinq now. thanks for the patch.
> ---
> drivers/gpu/drm/i915/intel_bios.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 03f04b472394..e0a14be1080a 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -740,7 +740,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct
> bdb_header *bdb)
> dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 100;
> break;
> case 3:
> - dev_priv->vbt.psr.tp1_wakeup_time_us = 0;
> + dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 0;
> break;
> default:
> DRM_DEBUG_KMS("VBT tp2_tp3 wakeup time value %d is
> outside range[0-3], defaulting to max value 2500us\n",
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us
== Series Details == Series: drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us URL : https://patchwork.freedesktop.org/series/45083/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4348_full -> Patchwork_9370_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9370_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9370_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9370_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-vebox: shard-kbl: SKIP -> PASS +7 igt@pm_rc6_residency@rc6-accuracy: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9370_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_hangcheck: shard-kbl: PASS -> DMESG-FAIL (fdo#106947, fdo#106560) igt@kms_flip@modeset-vs-vblank-race: shard-glk: PASS -> FAIL (fdo#103060) igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-pgflip-blt: shard-glk: PASS -> FAIL (fdo#103167, fdo#104724) Possible fixes igt@drv_selftest@live_gtt: shard-kbl: FAIL (fdo#105347) -> PASS shard-glk: FAIL (fdo#105347) -> PASS igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#105900) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#102887) -> PASS igt@kms_flip@flip-vs-panning-vs-hang: shard-snb: DMESG-WARN (fdo#103821) -> PASS igt@kms_flip@plain-flip-ts-check: shard-glk: FAIL (fdo#100368) -> PASS igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-wc: shard-kbl: FAIL (fdo#106067) -> PASS igt@perf@enable-disable: shard-kbl: DMESG-FAIL (fdo#106064) -> PASS igt@pm_rps@waitboost: shard-kbl: FAIL (fdo#102250) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102250 https://bugs.freedesktop.org/show_bug.cgi?id=102250 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105900 https://bugs.freedesktop.org/show_bug.cgi?id=105900 fdo#106064 https://bugs.freedesktop.org/show_bug.cgi?id=106064 fdo#106067 https://bugs.freedesktop.org/show_bug.cgi?id=106067 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4348 -> Patchwork_9370 CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9370: 25bf73ee9f280d8fc68715e6332324aa0da3f7ad @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9370/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/selftests: Remove unused dmabuf->kmap routines, fix the build
Quoting Koenig, Christian (2018-06-20 17:28:33)
>
>
> Am 20.06.2018 18:22 schrieb Chris Wilson :
>
> Fix i915's CI build after the removal of the dmabuf->kmap interface that
> left the mock routines intact.
>
> In file included from drivers/gpu/drm/i915/i915_gem_dmabuf.c:335:0:
> drivers/gpu/drm/i915/selftests/mock_dmabuf.c:104:13: error:
> ‘mock_dmabuf_kunmap_atomic’ defined but not used [-Werror=unused-function]
> static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned
> long page_num, void *addr)
> drivers/gpu/drm/i915/selftests/mock_dmabuf.c:97:14: error:
> ‘mock_dmabuf_kmap_atomic’ defined but not used [-Werror=unused-function]
> static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned
> long page_num)
>
> Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
> Signed-off-by: Chris Wilson
>
>
> Reviewed-by: Christian König
>
> And sorry for the noise,
No worries, pushed to drm-misc-next, and so this never happened.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/24] drm/i915/icl: Add 10-bit support for hdmi
On Mon, May 21, 2018 at 05:25:51PM -0700, Paulo Zanoni wrote:
> From: "Sripada, Radhakrishna"
>
> Starting Icelake silicon supports 10-bpc hdmi to support certain
> media workloads. Currently hdmi supports 8 and 12 bpc. Plumbed
> in support for 10 bit hdmi.
>
> Cc: James Ausmus
> Cc: Jani Nikula
> Cc: Paulo Zanoni
> Cc: Manasi Navare
> Cc: Rodrigo Vivi
> Cc: Ville Syrjälä
> Signed-off-by: Radhakrishna Sripada
Still looks reasoanble to me so
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 64
> +--
> 1 file changed, 48 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 0ca4cc877520..53ac8bb85218 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1561,14 +1561,23 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
> /* check if we can do 8bpc */
> status = hdmi_port_clock_valid(hdmi, clock, true, force_dvi);
>
> - /* if we can't do 8bpc we may still be able to do 12bpc */
> - if (!HAS_GMCH_DISPLAY(dev_priv) && status != MODE_OK &&
> hdmi->has_hdmi_sink && !force_dvi)
> - status = hdmi_port_clock_valid(hdmi, clock * 3 / 2, true,
> force_dvi);
> + if (hdmi->has_hdmi_sink && !force_dvi) {
> + /* if we can't do 8bpc we may still be able to do 12bpc */
> + if (status != MODE_OK && !HAS_GMCH_DISPLAY(dev_priv))
> + status = hdmi_port_clock_valid(hdmi, clock * 3 / 2,
> +true, force_dvi);
> +
> + /* if we can't do 8,12bpc we may still be able to do 10bpc */
> + if (status != MODE_OK && INTEL_GEN(dev_priv) >= 11)
> + status = hdmi_port_clock_valid(hdmi, clock * 5 / 4,
> +true, force_dvi);
> + }
>
> return status;
> }
>
> -static bool hdmi_12bpc_possible(const struct intel_crtc_state *crtc_state)
> +static bool hdmi_deep_color_possible(const struct intel_crtc_state
> *crtc_state,
> + int bpc)
> {
> struct drm_i915_private *dev_priv =
> to_i915(crtc_state->base.crtc->dev);
> @@ -1580,6 +1589,9 @@ static bool hdmi_12bpc_possible(const struct
> intel_crtc_state *crtc_state)
> if (HAS_GMCH_DISPLAY(dev_priv))
> return false;
>
> + if (bpc == 10 && INTEL_GEN(dev_priv) < 11)
> + return false;
> +
> if (crtc_state->pipe_bpp <= 8*3)
> return false;
>
> @@ -1587,7 +1599,7 @@ static bool hdmi_12bpc_possible(const struct
> intel_crtc_state *crtc_state)
> return false;
>
> /*
> - * HDMI 12bpc affects the clocks, so it's only possible
> + * HDMI deep color affects the clocks, so it's only possible
>* when not cloning with other encoder types.
>*/
> if (crtc_state->output_types != 1 << INTEL_OUTPUT_HDMI)
> @@ -1602,16 +1614,24 @@ static bool hdmi_12bpc_possible(const struct
> intel_crtc_state *crtc_state)
> if (crtc_state->ycbcr420) {
> const struct drm_hdmi_info *hdmi = >hdmi;
>
> - if (!(hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36))
> + if (bpc == 12 && !(hdmi->y420_dc_modes &
> +DRM_EDID_YCBCR420_DC_36))
> + return false;
> + else if (bpc == 10 && !(hdmi->y420_dc_modes &
> + DRM_EDID_YCBCR420_DC_30))
> return false;
> } else {
> - if (!(info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36))
> + if (bpc == 12 && !(info->edid_hdmi_dc_modes &
> +DRM_EDID_HDMI_DC_36))
> + return false;
> + else if (bpc == 10 && !(info->edid_hdmi_dc_modes &
> + DRM_EDID_HDMI_DC_30))
> return false;
> }
> }
>
> /* Display WA #1139: glk */
> - if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
> + if (bpc == 12 && IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
> crtc_state->base.adjusted_mode.htotal > 5460)
> return false;
>
> @@ -1621,7 +1641,8 @@ static bool hdmi_12bpc_possible(const struct
> intel_crtc_state *crtc_state)
> static bool
> intel_hdmi_ycbcr420_config(struct drm_connector *connector,
> struct intel_crtc_state *config,
> -int *clock_12bpc, int *clock_8bpc)
> +int *clock_12bpc, int *clock_10bpc,
> +int *clock_8bpc)
> {
> struct intel_crtc *intel_crtc = to_intel_crtc(config->base.crtc);
>
> @@ -1633,6 +1654,7 @@
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build
Am 20.06.2018 18:22 schrieb Chris Wilson :
Fix i915's CI build after the removal of the dmabuf->kmap interface that
left the mock routines intact.
In file included from drivers/gpu/drm/i915/i915_gem_dmabuf.c:335:0:
drivers/gpu/drm/i915/selftests/mock_dmabuf.c:104:13: error:
‘mock_dmabuf_kunmap_atomic’ defined but not used [-Werror=unused-function]
static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
drivers/gpu/drm/i915/selftests/mock_dmabuf.c:97:14: error:
‘mock_dmabuf_kmap_atomic’ defined but not used [-Werror=unused-function]
static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num)
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Signed-off-by: Chris Wilson
Reviewed-by: Christian König
And sorry for the noise,
Christian.
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
---
drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
b/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
index f81fda8ea45e..ca682caf1062 100644
--- a/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
@@ -94,18 +94,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void
*vaddr)
vm_unmap_ram(vaddr, mock->npages);
}
-static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num)
-{
- struct mock_dmabuf *mock = to_mock(dma_buf);
-
- return kmap_atomic(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
-{
- kunmap_atomic(addr);
-}
-
static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
{
struct mock_dmabuf *mock = to_mock(dma_buf);
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build
Fix i915's CI build after the removal of the dmabuf->kmap interface that
left the mock routines intact.
In file included from drivers/gpu/drm/i915/i915_gem_dmabuf.c:335:0:
drivers/gpu/drm/i915/selftests/mock_dmabuf.c:104:13: error:
‘mock_dmabuf_kunmap_atomic’ defined but not used [-Werror=unused-function]
static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
drivers/gpu/drm/i915/selftests/mock_dmabuf.c:97:14: error:
‘mock_dmabuf_kmap_atomic’ defined but not used [-Werror=unused-function]
static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num)
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
---
drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
b/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
index f81fda8ea45e..ca682caf1062 100644
--- a/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
@@ -94,18 +94,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void
*vaddr)
vm_unmap_ram(vaddr, mock->npages);
}
-static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num)
-{
- struct mock_dmabuf *mock = to_mock(dma_buf);
-
- return kmap_atomic(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
-{
- kunmap_atomic(addr);
-}
-
static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
{
struct mock_dmabuf *mock = to_mock(dma_buf);
--
2.18.0.rc2
___
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: Add Exec param to control data port coherency. (rev4)
== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev4) URL : https://patchwork.freedesktop.org/series/40181/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4348 -> Patchwork_9373 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9373 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9373, 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/40181/revisions/4/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9373: === IGT changes === Warnings igt@gem_exec_gttfill@basic: fi-pnv-d510:PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9373 that come from known issues: === IGT changes === Issues hit igt@gem_ctx_create@basic-files: fi-kbl-7567u: PASS -> DMESG-WARN (fdo#106954) Possible fixes igt@drv_module_reload@basic-reload: fi-glk-j4005: DMESG-WARN (fdo#106248, fdo#106725) -> PASS fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 fdo#106954 https://bugs.freedesktop.org/show_bug.cgi?id=106954 == Participating hosts (44 -> 38) == Additional (1): fi-hsw-peppy Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4348 -> Patchwork_9373 CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9373: 525e6ee946c85a6a1742df72a3e2d87695234bb1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 525e6ee946c8 drm/i915: Add IOCTL Param to control data port coherency. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9373/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add Exec param to control data port coherency. (rev4)
== Series Details == Series: drm/i915: Add Exec param to control data port coherency. (rev4) URL : https://patchwork.freedesktop.org/series/40181/ State : warning == Summary == $ dim checkpatch origin/drm-tip 525e6ee946c8 drm/i915: Add IOCTL Param to control data port coherency. -:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #15: coherency at data port level. Keeping the coherency at that level is disabled -:125: WARNING:LINE_SPACING: Missing a blank line after declarations #125: FILE: drivers/gpu/drm/i915/i915_gem_context.c:717: + int ret; + ret = intel_lr_context_modify_data_port_coherency(ctx, true); -:134: WARNING:LINE_SPACING: Missing a blank line after declarations #134: FILE: drivers/gpu/drm/i915/i915_gem_context.c:726: + int ret; + ret = intel_lr_context_modify_data_port_coherency(ctx, false); -:244: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #244: FILE: drivers/gpu/drm/i915/intel_lrc.c:279: +* true, we should enodev for CNL. */ -:261: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #261: FILE: drivers/gpu/drm/i915/intel_lrc.c:296: +intel_lr_context_modify_data_port_coherency(struct i915_gem_context *ctx, + bool enable) -:290: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #290: FILE: drivers/gpu/drm/i915/intel_lrc.h:109: +intel_lr_context_modify_data_port_coherency(struct i915_gem_context *ctx, +bool enable); total: 0 errors, 4 warnings, 2 checks, 161 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 drm/i915: Disable bh around call to tasklet
== Series Details == Series: drm/i915: Disable bh around call to tasklet URL : https://patchwork.freedesktop.org/series/45089/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4348 -> Patchwork_9372 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45089/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9372 that come from known issues: === IGT changes === Issues hit igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) Possible fixes igt@drv_module_reload@basic-reload: fi-glk-j4005: DMESG-WARN (fdo#106725, fdo#106248) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 == Participating hosts (44 -> 38) == Additional (1): fi-hsw-peppy Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4348 -> Patchwork_9372 CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9372: 6fae2763dc644a987ef2520e3ba41b10fce1edf6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6fae2763dc64 drm/i915: Disable bh around call to tasklet == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9372/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/12] drm: Add generic fbdev emulation
Den 20.06.2018 15.52, skrev Noralf Trønnes:
Den 20.06.2018 11.34, skrev Daniel Vetter:
On Mon, Jun 18, 2018 at 04:17:27PM +0200, Noralf Trønnes wrote:
This patchset adds generic fbdev emulation for drivers that supports
GEM
based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An
API is begun to support in-kernel clients in general.
Notable changes since version 1:
- Rework client unregister code. I've used reference counting to manage
the fact that both the client itself and the driver through
drm_dev_unregister() can release the client. The client is now
released
using drm_client_put() instead of drm_client_free().
I started reviewing the reworked client register/unregister stuff,
and it
looks good, except this kref stuff here for clients. I don't understand
why you need this - as long as removal from dev->clientlist is properly
protected by the mutex, I don't see how both the client and the
device can
release the client at the same time. Of course this means that both the
device-trigger unregister and the client-triggered unregister must first
grab the mutex, remove the client from the list, and only if that was
done
succesfully, clean up the client. If the client is already removed from
the list (i.e. list_empty() is true) then you need to bail out to avoid
double-freeing.
I just suck at this :/
Use case:
Unloading client module at the same time as the device is unplugged.
The client module calls drm_client_release():
void drm_client_release(struct drm_client_dev *client)
{
struct drm_device *dev = client->dev;
mutex_lock(>clientlist_mutex);
list_del(>list);
drm_client_close(client);
mutex_unlock(>clientlist_mutex);
drm_dev_put(dev);
}
drm_device_unregister() calls drm_client_dev_unregister():
void drm_client_dev_unregister(struct drm_device *dev)
{
struct drm_client_dev *client;
mutex_lock(>clientlist_mutex);
list_for_each_entry(client, >clientlist, list) {
if (client->funcs && client->funcs->unregister)
client->funcs->unregister(client);
else
drm_client_release(client);
}
mutex_unlock(>clientlist_mutex);
}
How do I do this without deadlocking and without operating on a
drm_client_dev structure that has been freed in the other codepath?
There's one more quirk that I forgot:
If fbdev can't release the client on .unregister due to open fd's, the
list entry should be removed but releasing resources is deferred to
the last fd being closed.
Noralf.
Noralf.
I don't think there's a need to use a kref here. And kref has the tricky
issue that you tempt everyone into constructing references loops between
drm_device and drm_client (which require lots of jumping through
hoops in
your v1 to make sure you can break those reference loops).
- fbdev: Use a shadow buffer for framebuffers that have a dirty
callback. This makes the fbdev client truly generic and useable
for all
drivers. There's a blitting penalty, but this is generic
emulation after
all. The reason for needing a shadow buffer is that deferred I/O
only
works with kmalloc/vmalloc buffers and not with shmem buffers
(page->lru/mapping).
Yeah I think that's the only feasible option. Everyone who cares more
about fbdev performance can keep their driver-specific code. And for
other
drm_client users this shouldn't be a problem, since they know how to use
dirty and flipping between multiple buffers to drive kms as it was
designed. The issue really only exists for fbdev's assumption of a
direct
mmap of a dumb framebuffer, encoded into the uapi.
- Let tinydrm use the full fbdev client
\o/
Cheers, Daniel
Noralf.
Changes since version 1:
- Make it possible to embed struct drm_client_dev and drop the private
pointer
- Use kref reference counting to control client release since both the
client and the driver can release.
- Add comment about using dma-buf as a possibility with some rework
- Move buffer NULL check to drm_client_framebuffer_delete()
- Move client name to struct drm_client_dev
- Move up drm_dev_get/put calls to make them more visible
- Move drm_client_dev.list definition to later patch that makes use
of it
- Embed drm_client at the beginning of drm_fb_helper to avoid a fragile
transitional kfree hack in drm_client_release()
- Set owner in drm_fbdev_fb_ops
- Add kerneldoc to drm_fb_helper_generic_probe()
- Remove unused functions
- Change name drm_client_funcs.lastclose -> .restore
- Change name drm_client_funcs.remove -> .unregister
- Rework unregister code
- tinydrm: Use drm_fbdev_generic_setup() and remove
drm_fb_cma_fbdev_init_with_funcs()
David Herrmann (1):
drm: provide management functions for drm_file
Noralf Trønnes (11):
drm/file: Don't set master on in-kernel clients
drm: Make ioctls available for in-kernel clients
drm: Begin an API for in-kernel clients
drm/fb-helper: Add generic fbdev emulation .fb_probe function
drm/pl111: Set
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: mark expected switch fall-through
== Series Details == Series: drm/i915: mark expected switch fall-through URL : https://patchwork.freedesktop.org/series/45088/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4348 -> Patchwork_9371 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45088/revisions/1/mbox/ == Changes == No changes found == Participating hosts (44 -> 37) == Additional (1): fi-hsw-peppy Missing(8): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-glk-dsi fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4348 -> Patchwork_9371 CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9371: 4934357efe0e8f39afbeaba6dd3e25ee2cd790e8 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4934357efe0e drm/i915: mark expected switch fall-through == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9371/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1] drm/i915: Add IOCTL Param to control data port coherency.
The patch adds a parameter to control the data port coherency functionality on a per-context level. When the IOCTL is called, a command to switch data port coherency state is added to the ordered list. All prior requests are executed on old coherency settings, and all exec requests after the IOCTL will use new settings. Rationale: The OpenCL driver develpers requested a functionality to control cache coherency at data port level. Keeping the coherency at that level is disabled by default due to its performance costs. OpenCL driver is planning to enable it for a small subset of submissions, when such functionality is required. Below are answers to basic question explaining background of the functionality and reasoning for the proposed implementation: 1. Why do we need a coherency enable/disable switch for memory that is shared between CPU and GEN (GPU)? Memory coherency between CPU and GEN, while being a great feature that enables CL_MEM_SVM_FINE_GRAIN_BUFFER OCL capability on Intel GEN architecture, adds overhead related to tracking (snooping) memory inside different cache units (L1$, L2$, L3$, LLC$, etc.). At the same time, minority of modern OCL applications actually use CL_MEM_SVM_FINE_GRAIN_BUFFER (and hence require memory coherency between CPU and GPU). The goal of coherency enable/disable switch is to remove overhead of memory coherency when memory coherency is not needed. 2. Why do we need a global coherency switch? In order to support I/O commands from within EUs (Execution Units), Intel GEN ISA (GEN Instruction Set Assembly) contains dedicated "send" instructions. These send instructions provide several addressing models. One of these addressing models (named "stateless") provides most flexible I/O using plain virtual addresses (as opposed to buffer_handle+offset models). This "stateless" model is similar to regular memory load/store operations available on typical CPUs. Since this model provides I/O using arbitrary virtual addresses, it enables algorithmic designs that are based on pointer-to-pointer (e.g. buffer of pointers) concepts. For instance, it allows creating tree-like data structures such as: | NODE1 | | uint64_t data | +| | NODE* | NODE*| ++---+ / \ /\ | NODE2 || NODE3 | | uint64_t data || uint64_t data | +|+| | NODE* | NODE*|| NODE* | NODE*| ++---+++---+ Please note that pointers inside such structures can point to memory locations in different OCL allocations - e.g. NODE1 and NODE2 can reside in one OCL allocation while NODE3 resides in a completely separate OCL allocation. Additionally, such pointers can be shared with CPU (i.e. using SVM - Shared Virtual Memory feature). Using pointers from different allocations doesn't affect the stateless addressing model which even allows scattered reading from different allocations at the same time (i.e. by utilizing SIMD-nature of send instructions). When it comes to coherency programming, send instructions in stateless model can be encoded (at ISA level) to either use or disable coherency. However, for generic OCL applications (such as example with tree-like data structure), OCL compiler is not able to determine origin of memory pointed to by an arbitrary pointer - i.e. is not able to track given pointer back to a specific allocation. As such, it's not able to decide whether coherency is needed or not for specific pointer (or for specific I/O instruction). As a result, compiler encodes all stateless sends as coherent (doing otherwise would lead to functional issues resulting from data corruption). Please note that it would be possible to workaround this (e.g. based on allocations map and pointer bounds checking prior to each I/O instruction) but the performance cost of such workaround would be many times greater than the cost of keeping coherency always enabled. As such, enabling/disabling memory coherency at GEN ISA level is not feasible and alternative method is needed. Such alternative solution is to have a global coherency switch that allows disabling coherency for single (though entire) GPU submission. This is beneficial because this way we: * can enable (and pay for) coherency only in submissions that actually need coherency (submissions that use CL_MEM_SVM_FINE_GRAIN_BUFFER resources) * don't care about coherency at GEN ISA granularity (no performance impact) 3. Will coherency switch be used frequently? There are scenarios that will require frequent toggling of the coherency switch. E.g. an application has two OCL compute kernels: kern_master and kern_worker. kern_master uses, concurrently with CPU, some fine
[Intel-gfx] [PATCH v1] Second implementation of Data Port Coherency.
The OCL Team agreed to use IOCTL instead of Exec flag to switch coherency settings. Also: 1. I will follow this patch with IGT test for the new functionality. 2. The OCL Team will publish UMD patch for it. Tomasz Lis (1): drm/i915: Add IOCTL Param to control data port coherency. drivers/gpu/drm/i915/i915_gem_context.c | 41 ++ drivers/gpu/drm/i915/i915_gem_context.h | 6 drivers/gpu/drm/i915/intel_lrc.c| 51 + drivers/gpu/drm/i915/intel_lrc.h| 4 +++ include/uapi/drm/i915_drm.h | 1 + 5 files changed, 103 insertions(+) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us
== Series Details == Series: drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us URL : https://patchwork.freedesktop.org/series/45083/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4348 -> Patchwork_9370 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45083/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_9370 that come from known issues: === IGT changes === Issues hit igt@gem_exec_gttfill@basic: fi-byt-n2820: PASS -> FAIL (fdo#106744) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: NOTRUN -> DMESG-FAIL (fdo#106103, fdo#102614) igt@pm_rpm@basic-rte: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) Possible fixes igt@drv_module_reload@basic-reload: fi-glk-j4005: DMESG-WARN (fdo#106248, fdo#106725) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 fdo#106248 https://bugs.freedesktop.org/show_bug.cgi?id=106248 fdo#106725 https://bugs.freedesktop.org/show_bug.cgi?id=106725 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (44 -> 38) == Additional (1): fi-hsw-peppy Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-glk-dsi fi-bsw-cyan fi-ctg-p8600 fi-kbl-x1275 == Build changes == * Linux: CI_DRM_4348 -> Patchwork_9370 CI_DRM_4348: 3a2fbf8fe32d909c5d44e61e7d212ae694e9e473 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4526: 4bbfb4fb14b3deab9bc4db9911280b35c22b718c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9370: 25bf73ee9f280d8fc68715e6332324aa0da3f7ad @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 25bf73ee9f28 drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9370/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Disable bh around call to tasklet
The guc submission backends expects to only be run from (at least)
softirq context, but during our intel_engine_is_idle() check we would
call into the tasklet to make sure it was flushed. As this could occur
from process context, occasionally we would be caught out using a
wait_for_atomic() not from an atomic context:
[ 59.939091] WARN_ON_ONCE((1) && !(preempt_count() != 0))
[ 59.939142] WARNING: CPU: 1 PID: 2901 at
drivers/gpu/drm/i915/intel_guc_submission.c:615
guc_submission_tasklet+0x784/0xa90 [i915]
[ 59.939143] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp
crct10dif_pclmul snd_hda_intel crc32_pclmul snd_hda_codec ghash_clmulni_intel
snd_hwdep snd_hda_core e1000e snd_pcm mei_me mei prime_numbers
[ 59.939164] CPU: 1 PID: 2901 Comm: gem_exec_schedu Tainted: G U W
4.18.0-rc1-g93475d62c730-drmtip_67+ #1
[ 59.939165] Hardware name: System manufacturer System Product
Name/Z170M-PLUS, BIOS 3610 03/29/2018
[ 59.939188] RIP: 0010:guc_submission_tasklet+0x784/0xa90 [i915]
[ 59.939189] Code: fc ff ff 80 3d 2f 87 11 00 00 0f 85 80 fb ff ff 48 c7 c6
f8 49 40 c0 48 c7 c7 80 41 3e c0 c6 05 14 87 11 00 01 e8 2c ea d6 d3 <0f> 0b e9
5f fb ff ff 8b 46 38 89 cf 31 c7 83 e7 c0 75 08 39 c1 0f
[ 59.939253] RSP: 0018:aafe08a03c10 EFLAGS: 00010286
[ 59.939255] RAX: RBX: 8f9112c246f0 RCX: 0001
[ 59.939256] RDX: 8001 RSI: 95086d8e RDI:
[ 59.939257] RBP: 8f9112c24680 R08: 9517be77 R09:
[ 59.939258] R10: R11: R12: 8f9112c24700
[ 59.939259] R13: 8f9112c24700 R14: R15: 8f9112c242a8
[ 59.939260] FS: 7fc2cc7e5980() GS:8f9136c4()
knlGS:
[ 59.939261] CS: 0010 DS: ES: CR0: 80050033
[ 59.939262] CR2: 7fc2cc815040 CR3: 00021f10e003 CR4: 003606e0
[ 59.939263] DR0: DR1: DR2:
[ 59.939264] DR3: DR6: fffe0ff0 DR7: 0400
[ 59.939265] Call Trace:
[ 59.939288] ? intel_engine_is_idle+0x64/0x160 [i915]
[ 59.939323] ? intel_engine_dump+0x638/0x890 [i915]
[ 59.939327] ? seq_printf+0x49/0x70
[ 59.939353] ? i915_engine_info+0xc8/0x100 [i915]
[ 59.939356] ? drm_get_color_range_name+0x20/0x20
[ 59.939361] ? seq_read+0xf1/0x470
[ 59.939365] ? trace_hardirqs_on_caller+0xe0/0x1b0
[ 59.939370] ? full_proxy_read+0x51/0x80
[ 59.939389] ? __vfs_read+0x31/0x170
[ 59.939395] ? do_sys_open+0x13b/0x240
[ 59.939398] ? rcu_read_lock_sched_held+0x6f/0x80
[ 59.939401] ? vfs_read+0x9e/0x140
[ 59.939404] ? ksys_read+0x50/0xc0
[ 59.939409] ? do_syscall_64+0x55/0x190
[ 59.939412] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 59.939420] irq event stamp: 552834
[ 59.939422] hardirqs last enabled at (552833): []
console_unlock+0x3fc/0x600
[ 59.939425] hardirqs last disabled at (552834): []
error_entry+0x7c/0x100
[ 59.939451] softirqs last enabled at (552614): []
i915_request_add+0x2e3/0x7b0 [i915]
[ 59.939470] softirqs last disabled at (552604): []
i915_request_add+0x25b/0x7b0 [i915]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106977
Fixes: dd0cf235d81f ("drm/i915: Speed up idle detection by kicking the
tasklets")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
Cc: Michal Wajdeczko
Cc: Michał Winiarski
Cc: Michel Thierry
---
drivers/gpu/drm/i915/intel_engine_cs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 32bf3a408d46..d3264bd6e9dc 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1000,10 +1000,12 @@ bool intel_engine_is_idle(struct intel_engine_cs
*engine)
if (READ_ONCE(engine->execlists.active)) {
struct intel_engine_execlists *execlists = >execlists;
+ local_bh_disable();
if (tasklet_trylock(>tasklet)) {
execlists->tasklet.func(execlists->tasklet.data);
tasklet_unlock(>tasklet);
}
+ local_bh_enable();
if (READ_ONCE(execlists->active))
return false;
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: mark expected switch fall-through
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1470102 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 132fe63..6a40a77 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2566,6 +2566,7 @@ int icl_calc_dp_combo_pll_link(struct drm_i915_private
*dev_priv,
switch (index) {
default:
MISSING_CASE(index);
+ /* fall through */
case 0:
link_clock = 54;
break;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/12] drm: Add generic fbdev emulation
Den 20.06.2018 11.34, skrev Daniel Vetter:
On Mon, Jun 18, 2018 at 04:17:27PM +0200, Noralf Trønnes wrote:
This patchset adds generic fbdev emulation for drivers that supports GEM
based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An
API is begun to support in-kernel clients in general.
Notable changes since version 1:
- Rework client unregister code. I've used reference counting to manage
the fact that both the client itself and the driver through
drm_dev_unregister() can release the client. The client is now released
using drm_client_put() instead of drm_client_free().
I started reviewing the reworked client register/unregister stuff, and it
looks good, except this kref stuff here for clients. I don't understand
why you need this - as long as removal from dev->clientlist is properly
protected by the mutex, I don't see how both the client and the device can
release the client at the same time. Of course this means that both the
device-trigger unregister and the client-triggered unregister must first
grab the mutex, remove the client from the list, and only if that was done
succesfully, clean up the client. If the client is already removed from
the list (i.e. list_empty() is true) then you need to bail out to avoid
double-freeing.
I just suck at this :/
Use case:
Unloading client module at the same time as the device is unplugged.
The client module calls drm_client_release():
void drm_client_release(struct drm_client_dev *client)
{
struct drm_device *dev = client->dev;
mutex_lock(>clientlist_mutex);
list_del(>list);
drm_client_close(client);
mutex_unlock(>clientlist_mutex);
drm_dev_put(dev);
}
drm_device_unregister() calls drm_client_dev_unregister():
void drm_client_dev_unregister(struct drm_device *dev)
{
struct drm_client_dev *client;
mutex_lock(>clientlist_mutex);
list_for_each_entry(client, >clientlist, list) {
if (client->funcs && client->funcs->unregister)
client->funcs->unregister(client);
else
drm_client_release(client);
}
mutex_unlock(>clientlist_mutex);
}
How do I do this without deadlocking and without operating on a
drm_client_dev structure that has been freed in the other codepath?
Noralf.
I don't think there's a need to use a kref here. And kref has the tricky
issue that you tempt everyone into constructing references loops between
drm_device and drm_client (which require lots of jumping through hoops in
your v1 to make sure you can break those reference loops).
- fbdev: Use a shadow buffer for framebuffers that have a dirty
callback. This makes the fbdev client truly generic and useable for all
drivers. There's a blitting penalty, but this is generic emulation after
all. The reason for needing a shadow buffer is that deferred I/O only
works with kmalloc/vmalloc buffers and not with shmem buffers
(page->lru/mapping).
Yeah I think that's the only feasible option. Everyone who cares more
about fbdev performance can keep their driver-specific code. And for other
drm_client users this shouldn't be a problem, since they know how to use
dirty and flipping between multiple buffers to drive kms as it was
designed. The issue really only exists for fbdev's assumption of a direct
mmap of a dumb framebuffer, encoded into the uapi.
- Let tinydrm use the full fbdev client
\o/
Cheers, Daniel
Noralf.
Changes since version 1:
- Make it possible to embed struct drm_client_dev and drop the private
pointer
- Use kref reference counting to control client release since both the
client and the driver can release.
- Add comment about using dma-buf as a possibility with some rework
- Move buffer NULL check to drm_client_framebuffer_delete()
- Move client name to struct drm_client_dev
- Move up drm_dev_get/put calls to make them more visible
- Move drm_client_dev.list definition to later patch that makes use of it
- Embed drm_client at the beginning of drm_fb_helper to avoid a fragile
transitional kfree hack in drm_client_release()
- Set owner in drm_fbdev_fb_ops
- Add kerneldoc to drm_fb_helper_generic_probe()
- Remove unused functions
- Change name drm_client_funcs.lastclose -> .restore
- Change name drm_client_funcs.remove -> .unregister
- Rework unregister code
- tinydrm: Use drm_fbdev_generic_setup() and remove
drm_fb_cma_fbdev_init_with_funcs()
David Herrmann (1):
drm: provide management functions for drm_file
Noralf Trønnes (11):
drm/file: Don't set master on in-kernel clients
drm: Make ioctls available for in-kernel clients
drm: Begin an API for in-kernel clients
drm/fb-helper: Add generic fbdev emulation .fb_probe function
drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
drm/cma-helper: Use the generic fbdev emulation
drm/client: Add client callbacks
drm/debugfs: Add internal client debugfs file
drm/fb-helper: Finish the generic fbdev emulation
drm/tinydrm: Use drm_fbdev_generic_setup()
Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/icl: Do read-modify-write as needed during MG PLL programming
> -Original Message-
> From: Deak, Imre
> Sent: Tuesday, June 19, 2018 10:11 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kulkarni, Vandita ; Zanoni, Paulo R
> ; Ausmus, James
> Subject: [PATCH v3 2/2] drm/i915/icl: Do read-modify-write as needed
> during MG PLL programming
>
> Some MG PLL registers have fields that need to be preserved at their HW
> default or BIOS programmed values. So make sure we preserve them.
>
> v2:
> - Add comment to icl_mg_pll_write() explaining the need for register
> masks. (Vandita)
> - Fix patchwork checkpatch warning.
>
> v3:
> - Rebase on drm-tip.
>
> Cc: Vandita Kulkarni
> Cc: Paulo Zanoni
> Cc: James Ausmus
> Signed-off-by: Imre Deak
> Reviewed-by: James Ausmus (v1)
Looks good to me.
Reviewed-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 13
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 39
> +++
> 2 files changed, 48 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 4bfd7a9bd75f..65b87ee4
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9047,6 +9047,7 @@ enum skl_power_gate {
> #define _MG_REFCLKIN_CTL_PORT3 0x16A92C
> #define _MG_REFCLKIN_CTL_PORT4 0x16B92C
> #define MG_REFCLKIN_CTL_OD_2_MUX(x)((x) << 8)
> +#define MG_REFCLKIN_CTL_OD_2_MUX_MASK (0x7
> << 8)
> #define MG_REFCLKIN_CTL(port) _MMIO_PORT((port) - PORT_C, \
>_MG_REFCLKIN_CTL_PORT1, \
>_MG_REFCLKIN_CTL_PORT2)
> @@ -9056,7 +9057,9 @@ enum skl_power_gate {
> #define _MG_CLKTOP2_CORECLKCTL1_PORT3
> 0x16A8D8
> #define _MG_CLKTOP2_CORECLKCTL1_PORT4
> 0x16B8D8
> #define MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO(x) ((x)
> << 16)
> +#define MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO_MASK (0xff << 16)
> #define MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO(x) ((x)
> << 8)
> +#define MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO_MASK (0xff << 8)
> #define MG_CLKTOP2_CORECLKCTL1(port) _MMIO_PORT((port) - PORT_C,
> \
>
> _MG_CLKTOP2_CORECLKCTL1_PORT1, \
>
> _MG_CLKTOP2_CORECLKCTL1_PORT2)
> @@ -9066,9 +9069,13 @@ enum skl_power_gate {
> #define _MG_CLKTOP2_HSCLKCTL_PORT3 0x16A8D4
> #define _MG_CLKTOP2_HSCLKCTL_PORT4 0x16B8D4
> #define MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL(x) ((x)
> << 16)
> +#define MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL_MASK (0x1 << 16)
> #define MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL(x) ((x) << 14)
> +#define MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL_MASK (0x3
> << 14)
> #define MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO(x) ((x) << 12)
> +#define MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO_MASK (0x3
> << 12)
> #define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO(x) ((x) << 8)
> +#define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO_MASK (0xf
> << 8)
> #define MG_CLKTOP2_HSCLKCTL(port) _MMIO_PORT((port) - PORT_C, \
>
> _MG_CLKTOP2_HSCLKCTL_PORT1, \
>
> _MG_CLKTOP2_HSCLKCTL_PORT2)
> @@ -9142,12 +9149,18 @@ enum skl_power_gate {
> #define _MG_PLL_BIAS_PORT3 0x16AA14
> #define _MG_PLL_BIAS_PORT4 0x16BA14
> #define MG_PLL_BIAS_BIAS_GB_SEL(x) ((x) << 30)
> +#define MG_PLL_BIAS_BIAS_GB_SEL_MASK (0x3
> << 30)
> #define MG_PLL_BIAS_INIT_DCOAMP(x) ((x) << 24)
> +#define MG_PLL_BIAS_INIT_DCOAMP_MASK (0x3f
> << 24)
> #define MG_PLL_BIAS_BIAS_BONUS(x) ((x) << 16)
> +#define MG_PLL_BIAS_BIAS_BONUS_MASK(0xff << 16)
> #define MG_PLL_BIAS_BIASCAL_EN (1 << 15)
> #define MG_PLL_BIAS_CTRIM(x) ((x) << 8)
> +#define MG_PLL_BIAS_CTRIM_MASK (0x1f << 8)
> #define MG_PLL_BIAS_VREF_RDAC(x) ((x) << 5)
> +#define MG_PLL_BIAS_VREF_RDAC_MASK (0x7 << 5)
> #define MG_PLL_BIAS_IREFTRIM(x)((x) << 0)
> +#define MG_PLL_BIAS_IREFTRIM_MASK (0x1f << 0)
> #define MG_PLL_BIAS(port) _MMIO_PORT((port) - PORT_C,
> _MG_PLL_BIAS_PORT1, \
>_MG_PLL_BIAS_PORT2)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index d4c7bacbe83e..57342364fd30 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2945,10 +2945,21 @@ static bool icl_pll_get_hw_state(struct
> drm_i915_private *dev_priv,
> case DPLL_ID_ICL_MGPLL4:
> port = icl_mg_pll_id_to_port(id);
> hw_state->mg_refclkin_ctl =
> I915_READ(MG_REFCLKIN_CTL(port));
> + hw_state->mg_refclkin_ctl &=
[Intel-gfx] [PATCH][next] drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us
From: Colin Ian King
Currently for the psr_table->tp2_tp3_wakeup_time case 3 there appears
to be a copy-paste error from the previous switch statement where
dev_priv->vbt.psr.tp1_wakeup_time_us is being assigned and I believe
it should be dev_priv->vbt.psr.tp2_tp3_wakeup_time_us that should be
assigned instead.
Detected by CoverityScan, CID#1470105 ("Copy-paste error")
Fixes: 77312ae8f071 ("drm/i915/psr: vbt change for psr")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 03f04b472394..e0a14be1080a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -740,7 +740,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 100;
break;
case 3:
- dev_priv->vbt.psr.tp1_wakeup_time_us = 0;
+ dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 0;
break;
default:
DRM_DEBUG_KMS("VBT tp2_tp3 wakeup time value %d is
outside range[0-3], defaulting to max value 2500us\n",
--
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: success for drm/i915/selftests: Don't dereference an error pointer (rev3)
== Series Details == Series: drm/i915/selftests: Don't dereference an error pointer (rev3) URL : https://patchwork.freedesktop.org/series/45068/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4346_full -> Patchwork_9369_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9369_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9369_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9369_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-blt: shard-kbl: SKIP -> PASS +1 igt@gem_mocs_settings@mocs-rc6-bsd2: shard-kbl: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_9369_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> FAIL (fdo#105347) shard-glk: PASS -> INCOMPLETE (fdo#103359, k.org#198133) igt@drv_selftest@live_hangcheck: shard-apl: NOTRUN -> DMESG-FAIL (fdo#106947, fdo#106560) igt@drv_selftest@live_hugepages: shard-kbl: PASS -> INCOMPLETE (fdo#103665) igt@gem_exec_schedule@pi-ringfull-blt: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@gem_partial_pwrite_pread@reads: shard-snb: PASS -> INCOMPLETE (fdo#105411) igt@kms_setmode@basic: shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_gtt: shard-apl: INCOMPLETE (fdo#103927) -> PASS igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS +1 igt@gem_workarounds@suspend-resume-context: shard-glk: FAIL (fdo#103375) -> PASS igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: DMESG-WARN (fdo#105763, fdo#106538) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#102887) -> PASS fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560 fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4346 -> Patchwork_9369 CI_DRM_4346: 92d7e0feac3acdf911aacfcc8a5df92756e2d11a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4525: 578c645406d59138029fa6ef343fcc87c2d95d4c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9369: 56e640b507ebf11d953f1262c6b9afe855470fc0 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9369/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 1/2] lib: Spin fast, retire early
Quoting Chris Wilson (2018-06-20 14:57:05) > When using the pollable spinner, we often want to use it as a means of > ensuring the task is running on the GPU before switching to something > else. In which case we don't want to add extra delay inside the spinner, > but the current 1000 NOPs add on order of 5us, which is often larger > than the target latency. > > Signed-off-by: Chris Wilson > Reviewed-by: Antonio Argenziano Reviewed-by: Joonas Lahtinen Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Avoid ERR_PTR dereference
Quoting Chris Wilson (2018-06-20 14:24:41)
> Along the early error path for igt_switch_to_kernel_context we may try
> to dereference an invalid error pointer. Instead, return early rather
> than dump the GEM trace since we haven't yet emitted anything of
> interest.
>
> Reported-by: Dan Carpenter
> Fixes: 09a4c02e58c1 ("drm/i915: Look for an active kernel context before
> switching")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/2] igt/gem_sync: Alternate stress for nop+sync
More pebkac. The kettle wasn't working, that's my excuse. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] lib: Spin fast, retire early
When using the pollable spinner, we often want to use it as a means of
ensuring the task is running on the GPU before switching to something
else. In which case we don't want to add extra delay inside the spinner,
but the current 1000 NOPs add on order of 5us, which is often larger
than the target latency.
Signed-off-by: Chris Wilson
Reviewed-by: Antonio Argenziano
---
lib/igt_dummyload.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 3809b4e61..d73b4abd5 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -77,6 +77,7 @@ fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
#define OUT_FENCE (1 << 0)
#define POLL_RUN (1 << 1)
+#define SPIN_FAST (1 << 2)
static int
emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine,
@@ -205,7 +206,8 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t
ctx, unsigned engine,
* between function calls, that appears enough to keep SNB out of
* trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
*/
- batch += 1000;
+ if (!(flags & SPIN_FAST))
+ batch += 1000;
/* recurse */
r = [obj[BATCH].relocation_count++];
@@ -362,7 +364,7 @@ igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned
engine)
igt_spin_t *
__igt_spin_batch_new_poll(int fd, uint32_t ctx, unsigned engine)
{
- return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN);
+ return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN | SPIN_FAST);
}
/**
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] igt/perf_pmu: Fast slow then meander
Signed-off-by: Chris Wilson
---
tests/perf_pmu.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/tests/perf_pmu.c b/tests/perf_pmu.c
index 4570f926d..a2e20b8fc 100644
--- a/tests/perf_pmu.c
+++ b/tests/perf_pmu.c
@@ -206,11 +206,15 @@ static unsigned long __spin_wait(int fd, igt_spin_t *spin)
static igt_spin_t * __spin_sync(int fd, uint32_t ctx, unsigned long flags)
{
- igt_spin_t *spin = __spin_poll(fd, ctx, flags);
+ igt_spin_t *spin[2];
+
+ spin[0] = __spin_poll(fd, ctx, flags);
+ spin[1] = __igt_spin_batch_new(fd, ctx, flags, 0);
- __spin_wait(fd, spin);
+ __spin_wait(fd, spin[0]);
+ igt_spin_batch_free(fd, spin[0]);
- return spin;
+ return spin[1];
}
static igt_spin_t * spin_sync(int fd, uint32_t ctx, unsigned long flags)
--
2.18.0.rc2
___
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/selftests: Don't dereference an error pointer (rev3)
== Series Details == Series: drm/i915/selftests: Don't dereference an error pointer (rev3) URL : https://patchwork.freedesktop.org/series/45068/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4346 -> Patchwork_9369 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45068/revisions/3/mbox/ == Known issues == Here are the changes found in Patchwork_9369 that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: fi-glk-j4005: PASS -> FAIL (fdo#106765) igt@kms_flip@basic-flip-vs-dpms: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000) igt@kms_pipe_crc_basic@hang-read-crc-pipe-b: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106238) igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: fi-glk-j4005: PASS -> FAIL (fdo#103481) igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106097) Possible fixes igt@debugfs_test@read_all_entries: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@gem_exec_gttfill@basic: fi-byt-n2820: FAIL (fdo#106744) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106238 https://bugs.freedesktop.org/show_bug.cgi?id=106238 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 fdo#106765 https://bugs.freedesktop.org/show_bug.cgi?id=106765 == Participating hosts (42 -> 37) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4346 -> Patchwork_9369 CI_DRM_4346: 92d7e0feac3acdf911aacfcc8a5df92756e2d11a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4525: 578c645406d59138029fa6ef343fcc87c2d95d4c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9369: 56e640b507ebf11d953f1262c6b9afe855470fc0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 56e640b507eb drm/i915/selftests: Avoid ERR_PTR dereference == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9369/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] igt/gem_sync: Alternate stress for nop+sync
Apply a different sort of stress by timing how long it takes to sync a
second nop batch in the pipeline. We first start a spinner on the
engine, then when we know the GPU is active, we submit the second nop;
start timing as we then release the spinner and wait for the nop to
complete.
As with every other gem_sync test, it serves two roles. The first is
that it checks that we do not miss a wakeup under common stressful
conditions (the more conditions we check, the happier we will be that
they do not occur in practice). And the second role it fulfils, is that
it provides a very crude estimate for how long it takes for a nop to
execute from a running start (we already have a complimentary estimate
for an idle start).
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
tests/gem_sync.c | 90
1 file changed, 90 insertions(+)
diff --git a/tests/gem_sync.c b/tests/gem_sync.c
index 1e2e089a1..4cd97c58b 100644
--- a/tests/gem_sync.c
+++ b/tests/gem_sync.c
@@ -177,6 +177,92 @@ idle_ring(int fd, unsigned ring, int timeout)
gem_close(fd, object.handle);
}
+static void
+wakeup_ring(int fd, unsigned ring, int timeout)
+{
+ unsigned engines[16];
+ const char *names[16];
+ int num_engines = 0;
+
+ if (ring == ALL_ENGINES) {
+ for_each_physical_engine(fd, ring) {
+ if (!gem_can_store_dword(fd, ring))
+ continue;
+
+ names[num_engines] = e__->name;
+ engines[num_engines++] = ring;
+ if (num_engines == ARRAY_SIZE(engines))
+ break;
+ }
+ igt_require(num_engines);
+ } else {
+ gem_require_ring(fd, ring);
+ igt_require(gem_can_store_dword(fd, ring));
+ names[num_engines] = NULL;
+ engines[num_engines++] = ring;
+ }
+
+ intel_detect_and_clear_missed_interrupts(fd);
+ igt_fork(child, num_engines) {
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ struct drm_i915_gem_exec_object2 object;
+ struct drm_i915_gem_execbuffer2 execbuf;
+ double end, this, elapsed, now;
+ unsigned long cycles;
+ uint32_t cmd;
+ igt_spin_t *spin;
+
+ memset(, 0, sizeof(object));
+ object.handle = gem_create(fd, 4096);
+ gem_write(fd, object.handle, 0, , sizeof(bbe));
+
+ memset(, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = to_user_pointer();
+ execbuf.buffer_count = 1;
+ execbuf.flags = engines[child % num_engines];
+
+ spin = __igt_spin_batch_new_poll(fd, 0, execbuf.flags);
+ igt_assert(spin->running);
+ cmd = *spin->batch;
+
+ gem_execbuf(fd, );
+
+ igt_spin_batch_end(spin);
+ gem_sync(fd, object.handle);
+
+ end = gettime() + timeout;
+ elapsed = 0;
+ cycles = 0;
+ do {
+ *spin->batch = cmd;
+ *spin->running = 0;
+ gem_execbuf(fd, >execbuf);
+ while (!READ_ONCE(*spin->running))
+ ;
+
+ gem_execbuf(fd, );
+
+ this = gettime();
+ igt_spin_batch_end(spin);
+ gem_sync(fd, object.handle);
+ now = gettime();
+
+ elapsed += now - this;
+ cycles++;
+ } while (now < end);
+
+ igt_info("%s%sompleted %ld cycles: %.3f us\n",
+names[child % num_engines] ?: "",
+names[child % num_engines] ? " c" : "C",
+cycles, elapsed*1e6/cycles);
+
+ igt_spin_batch_free(fd, spin);
+ gem_close(fd, object.handle);
+ }
+ igt_waitchildren_timeout(timeout+10, NULL);
+ igt_assert_eq(intel_detect_and_clear_missed_interrupts(fd), 0);
+}
+
static void
store_ring(int fd, unsigned ring, int num_children, int timeout)
{
@@ -762,6 +848,8 @@ igt_main
sync_ring(fd, e->exec_id | e->flags, 1, 150);
igt_subtest_f("idle-%s", e->name)
idle_ring(fd, e->exec_id | e->flags, 150);
+ igt_subtest_f("wakeup-%s", e->name)
+ wakeup_ring(fd, e->exec_id | e->flags, 150);
igt_subtest_f("store-%s", e->name)
store_ring(fd, e->exec_id | e->flags, 1, 150);
igt_subtest_f("many-%s", e->name)
@@ -782,6 +870,8 @@ igt_main
sync_ring(fd, ALL_ENGINES, ncpus, 150);
igt_subtest("forked-store-each")
store_ring(fd, ALL_ENGINES, ncpus,
[Intel-gfx] [PATCH i-g-t 1/2] lib: Spin fast, retire early
When using the pollable spinner, we often want to use it as a means of
ensuring the task is running on the GPU before switching to something
else. In which case we don't want to add extra delay inside the spinner,
but the current 1000 NOPs add on order of 5us, which is often larger
than the target latency.
Signed-off-by: Chris Wilson
Reviewed-by: Antonio Argenziano
---
lib/igt_dummyload.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 3809b4e61..d73b4abd5 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -77,6 +77,7 @@ fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
#define OUT_FENCE (1 << 0)
#define POLL_RUN (1 << 1)
+#define SPIN_FAST (1 << 2)
static int
emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine,
@@ -205,7 +206,8 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t
ctx, unsigned engine,
* between function calls, that appears enough to keep SNB out of
* trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
*/
- batch += 1000;
+ if (!(flags & SPIN_FAST))
+ batch += 1000;
/* recurse */
r = [obj[BATCH].relocation_count++];
@@ -362,7 +364,7 @@ igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned
engine)
igt_spin_t *
__igt_spin_batch_new_poll(int fd, uint32_t ctx, unsigned engine)
{
- return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN);
+ return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN | SPIN_FAST);
}
/**
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
Best Regards,
Ramalingam C
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, June 20, 2018 5:14 PM
> To: C, Ramalingam
> Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Sean Paul ; Chris
> Wilson ; Nikula, Jani ;
> Winkler, Tomas ; Usyskin, Alexander
> ; Shankar, Uma ;
> Sharma, Shashank
> Subject: Re: [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
>
> On Wed, Jun 20, 2018 at 12:19 PM, Ramalingam C
> wrote:
> >
> >
> > On Thursday 31 May 2018 12:52 PM, Daniel Vetter wrote:
> >>
> >> On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
> >>>
> >>> Implements the DP adaptation specific HDCP2.2 functions.
> >>>
> >>> These functions perform the DPCD read and write for communicating
> >>> the
> >>> HDCP2.2 auth message back and forth.
> >>>
> >>> Note: Chris Wilson suggested alternate method for waiting for
> >>> CP_IRQ, than completions concept. WIP to understand and implement
> >>> that, if needed. Just to unblock the review of other changes, v2
> >>> still continues with completions.
> >>>
> >>> v2:
> >>>wait for cp_irq is merged with this patch. Rebased.
> >>> v3:
> >>>wait_queue is used for wait for cp_irq [Chris Wilson]
> >>> v4:
> >>>Style fixed.
> >>>%s/PARING/PAIRING
> >>>Few style fixes [Uma]
> >>>
> >>> Signed-off-by: Ramalingam C
> >>> ---
> >>> drivers/gpu/drm/i915/intel_dp.c | 358
> >>> ++
> >>> drivers/gpu/drm/i915/intel_drv.h | 7 +
> >>> drivers/gpu/drm/i915/intel_hdcp.c | 5 +
> >>> 3 files changed, 370 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >>> b/drivers/gpu/drm/i915/intel_dp.c index 528407d608c8..ee71a26ec23f
> >>> 100644
> >>> --- a/drivers/gpu/drm/i915/intel_dp.c
> >>> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >>> @@ -31,6 +31,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>> #include @@ -5057,6 +5058,28 @@ void
> >>> intel_dp_encoder_suspend(struct intel_encoder
> >>> *intel_encoder)
> >>> pps_unlock(intel_dp);
> >>> }
> >>> +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> >>> +int timeout) {
> >>> + long ret;
> >>> +
> >>> + /* Reinit */
> >>> + atomic_set(>cp_irq_recved, 0);
> >>> +
> >>> +#define C (atomic_read(>cp_irq_recved) > 0)
> >>> + ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue,
> >>> +C,
> >>> +
> >>> msecs_to_jiffies(timeout));
> >>> +
> >>> + if (ret > 0) {
> >>> + atomic_set(>cp_irq_recved, 0);
> >>> + return 0;
> >>> + } else if (!ret) {
> >>> + return -ETIMEDOUT;
> >>> + }
> >>> + return (int)ret;
> >>> +}
> >>> +
> >>> +
> >>> static
> >>> int intel_dp_hdcp_write_an_aksv(struct intel_digital_port
> >>> *intel_dig_port,
> >>> u8 *an) @@ -5275,6 +5298,335 @@ int
> >>> intel_dp_hdcp_capable(struct intel_digital_port *intel_dig_port,
> >>> return 0;
> >>> }
> >>> +static
> >>> +int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int
> >>> *offset)
> >>
> >> Ugh, this is annoying that we have to map things around like that.
> >> But looking at the numbers the standards really don't seem to match at all.
> >
> > Sorry i am not getting about not matching part.
> > You mean some offsets and timeouts are not matching with spec?
>
> match as in you can't just compute them using a base_offset + hdcp_msgid
> trick,
> you do have to use the lookup table. The numbers itself match the spec, it's
> just
> that the specs are all inconsistent with each another for no real good reason.
>
> >>
> >>
> >> Instead of open-coding this I suggested you use a table with a struct
> >> like:
> >>
> >> const static struct hdcp_dp {
> >> int hdcp_msg;
> >> int dpcd_offset;
> >> int timeout;
> >> /* whatever else you might need */ } hdcp_2_dp_table[] = {
> >> { HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, ... },
> >> ...
> >> };
> >>
> >> Then just search that table in the code instead of the huge switch
> >> table below.
> >
> > Suggesting this for cpu optimization or for coding style?
>
> Just coding style, having to check a table is easier than checking huge case
> statements. None of this code matters from a performance pov.
Sure Daniel. I will use array of struct here.
Thanks
-Ram
>
> >
> >
> >>
> >>> +{
> >>> + switch (byte) {
> >>> + case HDCP_2_2_AKE_INIT:
> >>> + *offset = DP_HDCP_2_2_AKE_INIT_OFFSET;
> >>> + break;
> >>> + case HDCP_2_2_AKE_SEND_CERT:
> >>> + *offset = DP_HDCP_2_2_AKE_SEND_CERT_OFFSET;
> >>> + break;
> >>> + case HDCP_2_2_AKE_NO_STORED_KM:
> >>> + *offset = DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET;
>
[Intel-gfx] [PATCH i-g-t 1/2] igt/gem_tiled_partial_pwrite_pread: Check for known swizzling
As we want to compare a templated tiling pattern against the target_bo,
we need to know that the swizzling is compatible. Or else the two
tiling pattern may differ due to underlying page address that we cannot
know, and so the test may sporadically fail.
References: https://bugs.freedesktop.org/show_bug.cgi?id=102575
Signed-off-by: Chris Wilson
---
tests/gem_tiled_partial_pwrite_pread.c | 24
1 file changed, 24 insertions(+)
diff --git a/tests/gem_tiled_partial_pwrite_pread.c
b/tests/gem_tiled_partial_pwrite_pread.c
index fe573c37c..83c57c07d 100644
--- a/tests/gem_tiled_partial_pwrite_pread.c
+++ b/tests/gem_tiled_partial_pwrite_pread.c
@@ -249,6 +249,24 @@ static void test_partial_read_writes(void)
}
}
+static bool known_swizzling(uint32_t handle)
+{
+ struct drm_i915_gem_get_tiling2 {
+ uint32_t handle;
+ uint32_t tiling_mode;
+ uint32_t swizzle_mode;
+ uint32_t phys_swizzle_mode;
+ } arg = {
+ .handle = handle,
+ };
+#define DRM_IOCTL_I915_GEM_GET_TILING2 DRM_IOWR (DRM_COMMAND_BASE +
DRM_I915_GEM_GET_TILING, struct drm_i915_gem_get_tiling2)
+
+ if (igt_ioctl(fd, DRM_IOCTL_I915_GEM_GET_TILING2, ))
+ return false;
+
+ return arg.phys_swizzle_mode == arg.swizzle_mode;
+}
+
igt_main
{
uint32_t tiling_mode = I915_TILING_X;
@@ -271,6 +289,12 @@ igt_main
_mode,
_pitch, 0);
igt_assert(tiling_mode == I915_TILING_X);
igt_assert(scratch_pitch == 4096);
+
+ /*
+* As we want to compare our template tiled pattern against
+* the target bo, we need consistent swizzling on both.
+*/
+ igt_require(known_swizzling(scratch_bo->handle));
staging_bo = drm_intel_bo_alloc(bufmgr, "staging bo", BO_SIZE,
4096);
tiled_staging_bo = drm_intel_bo_alloc_tiled(bufmgr, "scratch
bo", 1024,
BO_SIZE/4096, 4,
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] igt/gem_set_tiling_vs_pwrite: Show the erroneous value
Signed-off-by: Chris Wilson --- tests/gem_set_tiling_vs_pwrite.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/gem_set_tiling_vs_pwrite.c b/tests/gem_set_tiling_vs_pwrite.c index 006edfe4e..f0126b648 100644 --- a/tests/gem_set_tiling_vs_pwrite.c +++ b/tests/gem_set_tiling_vs_pwrite.c @@ -75,7 +75,7 @@ igt_simple_main memset(data, 0, OBJECT_SIZE); gem_read(fd, handle, 0, data, OBJECT_SIZE); for (i = 0; i < OBJECT_SIZE/4; i++) - igt_assert(i == data[i]); + igt_assert_eq_u32(data[i], i); /* touch it before changing the tiling, so that the fence sticks around */ gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT); @@ -88,7 +88,7 @@ igt_simple_main memset(data, 0, OBJECT_SIZE); gem_read(fd, handle, 0, data, OBJECT_SIZE); for (i = 0; i < OBJECT_SIZE/4; i++) - igt_assert(i == data[i]); + igt_assert_eq_u32(data[i], i); munmap(ptr, OBJECT_SIZE); -- 2.18.0.rc2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
On Wed, Jun 20, 2018 at 12:19 PM, Ramalingam C wrote:
>
>
> On Thursday 31 May 2018 12:52 PM, Daniel Vetter wrote:
>>
>> On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
>>>
>>> Implements the DP adaptation specific HDCP2.2 functions.
>>>
>>> These functions perform the DPCD read and write for communicating the
>>> HDCP2.2 auth message back and forth.
>>>
>>> Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
>>> than completions concept. WIP to understand and implement that,
>>> if needed. Just to unblock the review of other changes, v2 still
>>> continues with completions.
>>>
>>> v2:
>>>wait for cp_irq is merged with this patch. Rebased.
>>> v3:
>>>wait_queue is used for wait for cp_irq [Chris Wilson]
>>> v4:
>>>Style fixed.
>>>%s/PARING/PAIRING
>>>Few style fixes [Uma]
>>>
>>> Signed-off-by: Ramalingam C
>>> ---
>>> drivers/gpu/drm/i915/intel_dp.c | 358
>>> ++
>>> drivers/gpu/drm/i915/intel_drv.h | 7 +
>>> drivers/gpu/drm/i915/intel_hdcp.c | 5 +
>>> 3 files changed, 370 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>>> b/drivers/gpu/drm/i915/intel_dp.c
>>> index 528407d608c8..ee71a26ec23f 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -31,6 +31,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -5057,6 +5058,28 @@ void intel_dp_encoder_suspend(struct intel_encoder
>>> *intel_encoder)
>>> pps_unlock(intel_dp);
>>> }
>>> +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
>>> +int timeout)
>>> +{
>>> + long ret;
>>> +
>>> + /* Reinit */
>>> + atomic_set(>cp_irq_recved, 0);
>>> +
>>> +#define C (atomic_read(>cp_irq_recved) > 0)
>>> + ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
>>> +
>>> msecs_to_jiffies(timeout));
>>> +
>>> + if (ret > 0) {
>>> + atomic_set(>cp_irq_recved, 0);
>>> + return 0;
>>> + } else if (!ret) {
>>> + return -ETIMEDOUT;
>>> + }
>>> + return (int)ret;
>>> +}
>>> +
>>> +
>>> static
>>> int intel_dp_hdcp_write_an_aksv(struct intel_digital_port
>>> *intel_dig_port,
>>> u8 *an)
>>> @@ -5275,6 +5298,335 @@ int intel_dp_hdcp_capable(struct
>>> intel_digital_port *intel_dig_port,
>>> return 0;
>>> }
>>> +static
>>> +int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int
>>> *offset)
>>
>> Ugh, this is annoying that we have to map things around like that. But
>> looking at the numbers the standards really don't seem to match at all.
>
> Sorry i am not getting about not matching part.
> You mean some offsets and timeouts are not matching with spec?
match as in you can't just compute them using a base_offset +
hdcp_msgid trick, you do have to use the lookup table. The numbers
itself match the spec, it's just that the specs are all inconsistent
with each another for no real good reason.
>>
>>
>> Instead of open-coding this I suggested you use a table with a struct
>> like:
>>
>> const static struct hdcp_dp {
>> int hdcp_msg;
>> int dpcd_offset;
>> int timeout;
>> /* whatever else you might need */
>> } hdcp_2_dp_table[] = {
>> { HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, ... },
>> ...
>> };
>>
>> Then just search that table in the code instead of the huge switch table
>> below.
>
> Suggesting this for cpu optimization or for coding style?
Just coding style, having to check a table is easier than checking
huge case statements. None of this code matters from a performance
pov.
>
>
>>
>>> +{
>>> + switch (byte) {
>>> + case HDCP_2_2_AKE_INIT:
>>> + *offset = DP_HDCP_2_2_AKE_INIT_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_SEND_CERT:
>>> + *offset = DP_HDCP_2_2_AKE_SEND_CERT_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_NO_STORED_KM:
>>> + *offset = DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_STORED_KM:
>>> + *offset = DP_HDCP_2_2_AKE_STORED_KM_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_SEND_HPRIME:
>>> + *offset = DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_SEND_PAIRING_INFO:
>>> + *offset = DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET;
>>> + break;
>>> + case HDCP_2_2_LC_INIT:
>>> + *offset = DP_HDCP_2_2_LC_INIT_OFFSET;
>>> + break;
>>> + case HDCP_2_2_LC_SEND_LPRIME:
>>> + *offset = DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET;
>>> + break;
>>> + case HDCP_2_2_SKE_SEND_EKS:
>>> + *offset = DP_HDCP_2_2_SKE_SEND_EKS_OFFSET;
>>> +
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/selftests: Don't dereference an error pointer
== Series Details == Series: drm/i915/selftests: Don't dereference an error pointer URL : https://patchwork.freedesktop.org/series/45068/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4346 -> Patchwork_9368 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_9368 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9368, 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/45068/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9368: === IGT changes === Possible regressions igt@gem_ctx_create@basic-files: fi-cfl-8700k: PASS -> DMESG-WARN == Known issues == Here are the changes found in Patchwork_9368 that come from known issues: === IGT changes === Possible fixes igt@debugfs_test@read_all_entries: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@gem_exec_gttfill@basic: fi-byt-n2820: FAIL (fdo#106744) -> PASS igt@kms_flip@basic-flip-vs-modeset: fi-glk-j4005: DMESG-WARN (fdo#106000) -> PASS fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (42 -> 37) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4346 -> Patchwork_9368 CI_DRM_4346: 92d7e0feac3acdf911aacfcc8a5df92756e2d11a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4525: 578c645406d59138029fa6ef343fcc87c2d95d4c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9368: fc2addf3a0e0e20a5d5dc13665be16a5aba23957 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == fc2addf3a0e0 drm/i915/selftests: Don't dereference an error pointer == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9368/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for i915: make the probe asynchronous (rev3)
== Series Details == Series: i915: make the probe asynchronous (rev3) URL : https://patchwork.freedesktop.org/series/44159/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4346_full -> Patchwork_9367_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9367_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9367_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9367_full: === IGT changes === Warnings igt@gem_mocs_settings@mocs-rc6-blt: shard-kbl: SKIP -> PASS +1 == Known issues == Here are the changes found in Patchwork_9367_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> FAIL (fdo#105347) igt@gem_exec_schedule@pi-ringfull-blt: shard-kbl: NOTRUN -> FAIL (fdo#103158) igt@kms_draw_crc@draw-method-rgb565-blt-xtiled: shard-glk: PASS -> WARN (fdo#106974) igt@kms_flip@plain-flip-fb-recreate: shard-glk: PASS -> FAIL (fdo#100368) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#104724) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-render: shard-snb: PASS -> FAIL (fdo#103167, fdo#104724) igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping: shard-glk: PASS -> DMESG-WARN (fdo#105763) +1 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_gtt: shard-apl: INCOMPLETE (fdo#103927) -> PASS igt@gem_ppgtt@blt-vs-render-ctx0: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: DMESG-WARN (fdo#106538, fdo#105763) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105189) -> PASS igt@kms_flip@flip-vs-expired-vblank: shard-glk: FAIL (fdo#102887) -> PASS igt@kms_flip_tiling@flip-to-y-tiled: shard-glk: FAIL (fdo#103822, fdo#104724) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103158 https://bugs.freedesktop.org/show_bug.cgi?id=103158 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 fdo#106974 https://bugs.freedesktop.org/show_bug.cgi?id=106974 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4346 -> Patchwork_9367 CI_DRM_4346: 92d7e0feac3acdf911aacfcc8a5df92756e2d11a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4525: 578c645406d59138029fa6ef343fcc87c2d95d4c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9367: 5792ad56bb06cea462ea9be53eff6879debada8b @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9367/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] ctx-sync
As fascinating as this patch is, this isn't the one I meant to send. Oops, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Avoid ERR_PTR dereference
Along the early error path for igt_switch_to_kernel_context we may try
to dereference an invalid error pointer. Instead, return early rather
than dump the GEM trace since we haven't yet emitted anything of
interest.
Reported-by: Dan Carpenter
Fixes: 09a4c02e58c1 ("drm/i915: Look for an active kernel context before
switching")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/selftests/i915_gem_context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 836f1af8b833..90c3c36173ba 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -519,8 +519,8 @@ static int igt_switch_to_kernel_context(void *arg)
mutex_lock(>drm.struct_mutex);
ctx = kernel_context(i915);
if (IS_ERR(ctx)) {
- err = PTR_ERR(ctx);
- goto out_unlock;
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(ctx);
}
/* First check idling each individual engine */
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] ctx-sync
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index dc556595a845..2c310754e1f9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1780,12 +1780,31 @@ execlists_context_pin(struct intel_engine_cs *engine,
return __execlists_context_pin(engine, ctx, ce);
}
+static int await_context_update(struct i915_request *request)
+{
+ struct i915_vma *vma = request->hw_context->state;
+ struct dma_fence *fence;
+ int err = 0;
+
+ fence = reservation_object_get_excl_rcu(vma->resv);
+ if (fence) {
+ err = i915_request_await_dma_fence(request, fence);
+ dma_fence_put(fence);
+ }
+
+ return err;
+}
+
static int execlists_request_alloc(struct i915_request *request)
{
int ret;
GEM_BUG_ON(!request->hw_context->pin_count);
+ ret = await_context_update(request);
+ if (ret)
+ return ret;
+
/* Flush enough space to reduce the likelihood of waiting after
* we start building the request - in which case we will just
* have to repeat work.
--
2.18.0.rc2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] i915: make the probe asynchronous
On Wed, 20 Jun 2018, Feng Tang wrote: > On Wed, Jun 20, 2018 at 10:11:34AM +0300, Jani Nikula wrote: >> I suggested you do that within hdac_i915.c. Wait in snd_hdac_i915_init() >> below request_module(), complete in hdac_component_master_bind(). > > Sorry, I'm not familiar with the i915 HDAC detailed connection, but seems that > the hdac_component_master_bind() is a synchronous call (per my test), how > can we add a completion inside that? See Takashi's patch. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Don't dereference an error pointer
There is an error path where "ctx" is an error pointer so we can't
pass it to kernel_context_close().
Fixes: 09a4c02e58c1 ("drm/i915: Look for an active kernel context before
switching")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
index 836f1af8b833..e41036fcd97e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_context.c
@@ -541,7 +541,8 @@ static int igt_switch_to_kernel_context(void *arg)
err = -EIO;
mutex_unlock(>drm.struct_mutex);
- kernel_context_close(ctx);
+ if (!IS_ERR(ctx))
+ kernel_context_close(ctx);
return err;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
On Thursday 31 May 2018 12:52 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
Implements the DP adaptation specific HDCP2.2 functions.
These functions perform the DPCD read and write for communicating the
HDCP2.2 auth message back and forth.
Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
than completions concept. WIP to understand and implement that,
if needed. Just to unblock the review of other changes, v2 still
continues with completions.
v2:
wait for cp_irq is merged with this patch. Rebased.
v3:
wait_queue is used for wait for cp_irq [Chris Wilson]
v4:
Style fixed.
%s/PARING/PAIRING
Few style fixes [Uma]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 358 ++
drivers/gpu/drm/i915/intel_drv.h | 7 +
drivers/gpu/drm/i915/intel_hdcp.c | 5 +
3 files changed, 370 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 528407d608c8..ee71a26ec23f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -5057,6 +5058,28 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
pps_unlock(intel_dp);
}
+static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
+int timeout)
+{
+ long ret;
+
+ /* Reinit */
+ atomic_set(>cp_irq_recved, 0);
+
+#define C (atomic_read(>cp_irq_recved) > 0)
+ ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
+ msecs_to_jiffies(timeout));
+
+ if (ret > 0) {
+ atomic_set(>cp_irq_recved, 0);
+ return 0;
+ } else if (!ret) {
+ return -ETIMEDOUT;
+ }
+ return (int)ret;
+}
+
+
static
int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
@@ -5275,6 +5298,335 @@ int intel_dp_hdcp_capable(struct intel_digital_port
*intel_dig_port,
return 0;
}
+static
+int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int *offset)
Ugh, this is annoying that we have to map things around like that. But
looking at the numbers the standards really don't seem to match at all.
Sorry i am not getting about not matching part.
You mean some offsets and timeouts are not matching with spec?
Instead of open-coding this I suggested you use a table with a struct
like:
const static struct hdcp_dp {
int hdcp_msg;
int dpcd_offset;
int timeout;
/* whatever else you might need */
} hdcp_2_dp_table[] = {
{ HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, ... },
...
};
Then just search that table in the code instead of the huge switch table
below.
Suggesting this for cpu optimization or for coding style?
+{
+ switch (byte) {
+ case HDCP_2_2_AKE_INIT:
+ *offset = DP_HDCP_2_2_AKE_INIT_OFFSET;
+ break;
+ case HDCP_2_2_AKE_SEND_CERT:
+ *offset = DP_HDCP_2_2_AKE_SEND_CERT_OFFSET;
+ break;
+ case HDCP_2_2_AKE_NO_STORED_KM:
+ *offset = DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET;
+ break;
+ case HDCP_2_2_AKE_STORED_KM:
+ *offset = DP_HDCP_2_2_AKE_STORED_KM_OFFSET;
+ break;
+ case HDCP_2_2_AKE_SEND_HPRIME:
+ *offset = DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET;
+ break;
+ case HDCP_2_2_AKE_SEND_PAIRING_INFO:
+ *offset = DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET;
+ break;
+ case HDCP_2_2_LC_INIT:
+ *offset = DP_HDCP_2_2_LC_INIT_OFFSET;
+ break;
+ case HDCP_2_2_LC_SEND_LPRIME:
+ *offset = DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET;
+ break;
+ case HDCP_2_2_SKE_SEND_EKS:
+ *offset = DP_HDCP_2_2_SKE_SEND_EKS_OFFSET;
+ break;
+ case HDCP_2_2_REP_SEND_RECVID_LIST:
+ *offset = DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET;
+ break;
+ case HDCP_2_2_REP_SEND_ACK:
+ *offset = DP_HDCP_2_2_REP_SEND_ACK_OFFSET;
+ break;
+ case HDCP_2_2_REP_STREAM_MANAGE:
+ *offset = DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET;
+ break;
+ case HDCP_2_2_REP_STREAM_READY:
+ *offset = DP_HDCP_2_2_REP_STREAM_READY_OFFSET;
+ break;
+ case HDCP_2_2_ERRATA_DP_STREAM_TYPE:
+ *offset = DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET;
+ break;
+ default:
+ DRM_ERROR("Unrecognized Msg ID\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static inline
+int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+
Re: [Intel-gfx] [PATCH v4 39/41] drm/i915: Implement the HDCP2.2 support for HDMI
On Thursday 31 May 2018 12:54 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:58PM +0530, Ramalingam C wrote:
Implements the HDMI adaptation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2:
Rebased.
v3:
No Changes.
v4:
No more special handling of Gmbus burst read for AKE_SEND_CERT.
Style fixed with few naming. [Uma]
%s/PARING/PAIRING
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 186 ++
1 file changed, 186 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a5cc73101acb..042205e57e42 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1106,6 +1107,186 @@ bool intel_hdmi_hdcp_check_link(struct
intel_digital_port *intel_dig_port)
return true;
}
+static
+int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+ uint8_t *rx_status)
+{
+ return intel_hdmi_hdcp_read(intel_dig_port,
+ HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
+ rx_status,
+ HDCP_2_2_HDMI_RXSTATUS_LEN);
+}
+
+static inline
+int intel_hdmi_hdcp2_timeout_for_msg(uint8_t msg_id, bool is_paired)
So at a glance this is the same timeout stuff as for dp. I think this
should be moved out of the low-level callbacks into commont code. Maybe
wrap the low-level callbacks for read/write into small helper functions,
which then also do the timeout handling?
And I think the timeouts and availability checks should be done in the
hdcp flow directly, instead of far away from where the register read/write
is issue.
Since the msg availability detection is specific to the adaptation and
timeout
which also adaptation specific, is needed for msg availability detection.
So I feel it will look simple to keep them together in hdcp shim .
As you mentioned in the DP hdcp shim review, we could use the array of
struct holding timeout and offsets for a msg.
This will help to avoid the one of two switch cases used for mapping the
timeout and offsets with msg_id.
-Ram
Just to keep the entire register i/o closely together.
-Daniel
+{
+ int timeout;
+
+ switch (msg_id) {
+ case HDCP_2_2_AKE_SEND_CERT:
+ timeout = HDCP_2_2_CERT_TIMEOUT;
+ break;
+ case HDCP_2_2_AKE_SEND_HPRIME:
+ if (is_paired)
+ timeout = HDCP_2_2_HPRIME_PAIRED_TIMEOUT;
+ else
+ timeout = HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT;
+ break;
+ case HDCP_2_2_AKE_SEND_PAIRING_INFO:
+ timeout = HDCP_2_2_PAIRING_TIMEOUT;
+ break;
+ case HDCP_2_2_LC_SEND_LPRIME:
+ timeout = HDCP_2_2_HDMI_LPRIME_TIMEOUT;
+ break;
+ case HDCP_2_2_REP_SEND_RECVID_LIST:
+ timeout = HDCP_2_2_RECVID_LIST_TIMEOUT;
+ break;
+ case HDCP_2_2_REP_STREAM_READY:
+ timeout = HDCP_2_2_STREAM_READY_TIMEOUT;
+ break;
+ default:
+ timeout = -EINVAL;
+ DRM_ERROR("Unsupported msg_id: %d\n", (int)msg_id);
+ }
+
+ return timeout;
+}
+
+static inline
+int hdcp2_detect_msg_availability(struct intel_digital_port
*intel_digital_port,
+ uint8_t msg_id, bool *msg_ready,
+ ssize_t *msg_sz)
+{
+ uint8_t rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
+ int ret;
+
+ ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
+ if (ret < 0) {
+ DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
+ return ret;
+ }
+
+ *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8) |
+ rx_status[0]);
+
+ if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
+ *msg_ready = (HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
+*msg_sz);
+ else
+ *msg_ready = *msg_sz;
+
+ return 0;
+}
+
+static ssize_t
+intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
+ uint8_t msg_id, bool paired)
+{
+ bool msg_ready = false;
+ int timeout, ret;
+ ssize_t msg_sz;
+
+ timeout = intel_hdmi_hdcp2_timeout_for_msg(msg_id, paired);
+ if (timeout < 0)
+ return timeout;
+
+ ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
+msg_id, _ready, _sz),
+!ret && msg_ready && msg_sz, timeout * 1000,
+1000, 5 * 1000);
+ if (ret)
+ DRM_ERROR("msg_id: %d, ret:
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: make the probe asynchronous (rev3)
== Series Details == Series: i915: make the probe asynchronous (rev3) URL : https://patchwork.freedesktop.org/series/44159/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4346 -> Patchwork_9367 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/44159/revisions/3/mbox/ == Known issues == Here are the changes found in Patchwork_9367 that come from known issues: === IGT changes === Issues hit igt@prime_vgem@basic-fence-flip: fi-ilk-650: PASS -> FAIL (fdo#104008) Possible fixes igt@debugfs_test@read_all_entries: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@gem_exec_gttfill@basic: fi-byt-n2820: FAIL (fdo#106744) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@kms_flip@basic-plain-flip: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (42 -> 37) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4346 -> Patchwork_9367 CI_DRM_4346: 92d7e0feac3acdf911aacfcc8a5df92756e2d11a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4525: 578c645406d59138029fa6ef343fcc87c2d95d4c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9367: 5792ad56bb06cea462ea9be53eff6879debada8b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5792ad56bb06 i915: make the probe asynchronous == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9367/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dp: try normal detection on connector force enable (rev2)
== Series Details == Series: drm/i915/dp: try normal detection on connector force enable (rev2) URL : https://patchwork.freedesktop.org/series/45056/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4346_full -> Patchwork_9366_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_9366_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_9366_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_9366_full: === IGT changes === Warnings igt@gem_mmap_wc@set-cache-level: shard-snb: PASS -> SKIP igt@gem_mocs_settings@mocs-rc6-blt: shard-kbl: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_9366_full that come from known issues: === IGT changes === Issues hit igt@drv_selftest@live_gtt: shard-kbl: PASS -> FAIL (fdo#105347) shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) igt@gem_partial_pwrite_pread@reads: shard-snb: PASS -> INCOMPLETE (fdo#105411) igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: shard-glk: PASS -> FAIL (fdo#104873) igt@kms_draw_crc@draw-method-rgb565-blt-xtiled: shard-glk: PASS -> WARN (fdo#106974) igt@kms_flip_tiling@flip-y-tiled: shard-glk: PASS -> FAIL (fdo#104724, fdo#103822) igt@kms_plane_scaling@pipe-b-scaler-with-clipping-clamping: shard-glk: PASS -> DMESG-WARN (fdo#105763) +1 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@drv_selftest@live_gtt: shard-apl: INCOMPLETE (fdo#103927) -> PASS igt@gem_ppgtt@blt-vs-render-ctxn: shard-kbl: INCOMPLETE (fdo#106023, fdo#103665) -> PASS igt@gem_workarounds@suspend-resume-context: shard-glk: FAIL (fdo#103375) -> PASS igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic: shard-glk: FAIL (fdo#105454, fdo#106509) -> PASS igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: DMESG-WARN (fdo#106538, fdo#105763) -> PASS igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: FAIL (fdo#105189) -> PASS fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#103822 https://bugs.freedesktop.org/show_bug.cgi?id=103822 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#105189 https://bugs.freedesktop.org/show_bug.cgi?id=105189 fdo#105347 https://bugs.freedesktop.org/show_bug.cgi?id=105347 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106023 https://bugs.freedesktop.org/show_bug.cgi?id=106023 fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 fdo#106974 https://bugs.freedesktop.org/show_bug.cgi?id=106974 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4346 -> Patchwork_9366 CI_DRM_4346: 92d7e0feac3acdf911aacfcc8a5df92756e2d11a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4525: 578c645406d59138029fa6ef343fcc87c2d95d4c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9366: 2703dcc12d6c2781ad55288fd7fac0cc3debee65 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9366/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 i915: make the probe asynchronous (rev3)
== Series Details == Series: i915: make the probe asynchronous (rev3) URL : https://patchwork.freedesktop.org/series/44159/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5792ad56bb06 i915: make the probe asynchronous -:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #21: > > >> > > >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-ch...@chris-wilson.co.uk -:100: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 0 checks, 26 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] i915: make the probe asynchronous
On Wed, 20 Jun 2018 10:02:42 +0200,
Daniel Vetter wrote:
>
> On Wed, Jun 20, 2018 at 10:11:34AM +0300, Jani Nikula wrote:
> > On Wed, 20 Jun 2018, Feng Tang wrote:
> > > Hi Takashi,
> > >
> > > On Wed, Jun 20, 2018 at 08:35:05AM +0200, Takashi Iwai wrote:
> > >> On Wed, 20 Jun 2018 08:25:23 +0200,
> > >> Feng Tang wrote:
> > >> >
> > >> > Hi Jani/Chris/Takashi,
> > >> >
> > >> > On Wed, Jun 06, 2018 at 11:21:43AM +0300, Jani Nikula wrote:
> > >> > > >>
> > >> > > >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-ch...@chris-wilson.co.uk
> > >> > > >
> > >> > > > IIUC, you are waiting for the HDA audio driver to first handle the
> > >> > > > i915 sync probel case?
> > >> > >
> > >> > > I wouldn't hold my breath waiting. If you want to do i915 async
> > >> > > probe,
> > >> > > you'll probably have to figure hda out as well.
> > >> >
> > >> > I made the following patch based on 4.18-rc1, and tested on my machine,
> > >> > which basically works fine with Async probe taking effect (I tried
> > >> > builtin and modules way).
> > >> >
> > >> > Please review this initial version, and I'll separate to clean patches
> > >> > if you think it's OK. thanks!
> > >>
> > >> When you call an i915 function from HD-audio driver, you made already
> > >> a hard dependency. This is exactly what we want to avoid.
> > >
> > > Thanks for the info, I see your intension now.
> > >
> > > In previous discussion, Jani suggested to use a completion to indicate
> > > the probe done, I can't figure out another way :)
> >
> > I suggested you do that within hdac_i915.c. Wait in snd_hdac_i915_init()
> > below request_module(), complete in hdac_component_master_bind().
>
> I thgouth this kind of cross-driver dependency is supposed to be handled
> using EPROBE_DEFER? Why do we need to hand-roll that here?
>
> Or is this some other kind of synchronization need that needs a bespoke
> solution?
The binding with i915 from HD-audio controller is done in an async
work invoked from the probe callback. It makes harder to deal with
EPROBEDEFER.
IMO, a saner way would be to rather wait for the component binding.
The component mechanism is there just for that purpose, after all.
Does a patch like below work (totally untested)?
thanks,
Takashi
-- 8< --
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -23,6 +23,7 @@
#include
static struct i915_audio_component *hdac_acomp;
+static DECLARE_COMPLETION(acomp_bound);
/**
* snd_hdac_set_codec_wakeup - Enable / disable HDMI/DP codec wakeup
@@ -284,6 +285,7 @@ static int hdac_component_master_bind(struct device *dev)
goto out_unbind;
}
+ complete_all(_bound);
return 0;
out_unbind:
@@ -382,11 +384,8 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
if (ret < 0)
goto out_err;
- /*
-* Atm, we don't support deferring the component binding, so make sure
-* i915 is loaded and that the binding successfully completes.
-*/
request_module("i915");
+ wait_for_completion_timeout(_bound, 1); /* 10s timeout */
if (!acomp->ops) {
ret = -ENODEV;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] i915: make the probe asynchronous
Hi Jani,
On Wed, Jun 20, 2018 at 10:11:34AM +0300, Jani Nikula wrote:
> On Wed, 20 Jun 2018, Feng Tang wrote:
> > Hi Takashi,
> >
> > On Wed, Jun 20, 2018 at 08:35:05AM +0200, Takashi Iwai wrote:
> >> On Wed, 20 Jun 2018 08:25:23 +0200,
> >> Feng Tang wrote:
> >> >
> >> > Hi Jani/Chris/Takashi,
> >> >
> >> > On Wed, Jun 06, 2018 at 11:21:43AM +0300, Jani Nikula wrote:
> >> > > >>
> >> > > >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-ch...@chris-wilson.co.uk
> >> > > >
> >> > > > IIUC, you are waiting for the HDA audio driver to first handle the
> >> > > > i915 sync probel case?
> >> > >
> >> > > I wouldn't hold my breath waiting. If you want to do i915 async probe,
> >> > > you'll probably have to figure hda out as well.
> >> >
> >> > I made the following patch based on 4.18-rc1, and tested on my machine,
> >> > which basically works fine with Async probe taking effect (I tried
> >> > builtin and modules way).
> >> >
> >> > Please review this initial version, and I'll separate to clean patches
> >> > if you think it's OK. thanks!
> >>
> >> When you call an i915 function from HD-audio driver, you made already
> >> a hard dependency. This is exactly what we want to avoid.
> >
> > Thanks for the info, I see your intension now.
> >
> > In previous discussion, Jani suggested to use a completion to indicate
> > the probe done, I can't figure out another way :)
>
> I suggested you do that within hdac_i915.c. Wait in snd_hdac_i915_init()
> below request_module(), complete in hdac_component_master_bind().
Sorry, I'm not familiar with the i915 HDAC detailed connection, but seems that
the hdac_component_master_bind() is a synchronous call (per my test), how
can we add a completion inside that?
Thanks,
Feng
> BR,
> Jani.
>
> >
> > In my own debug patch, I had put a
> > #ifndef CONFIG_DRM_I915
> > static inline int wait_i915_probe_done() {return -ENODEV;}
> > #else
> >
> > #endif
> >
> > Is this fine?
> >
> > btw, for hdac_i915.c, if it is already bound with i915, can we make
> > it an separte module to dedpend on i915?
> >
> > Thanks,
> > Feng
> >
> >>
> >>
> >> thanks,
> >>
> >> Takashi
> >>
> >> >
> >> > - Feng
> >> >
> >> >
> >> > --
> >> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> >> > b/drivers/gpu/drm/i915/i915_pci.c
> >> > index 4364922..16a59ae 100644
> >> > --- a/drivers/gpu/drm/i915/i915_pci.c
> >> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> >> > @@ -671,6 +671,21 @@ static const struct pci_device_id pciidlist[] = {
> >> > };
> >> > MODULE_DEVICE_TABLE(pci, pciidlist);
> >> >
> >> > +static struct completion i915_probe_done;
> >> > +
> >> > +int wait_i915_probe_done(int timeout)
> >> > +{
> >> > +int ret;
> >> > +
> >> > +ret =
> >> > wait_for_completion_interruptible_timeout(_probe_done, timeout);
> >> > +if (ret <= 0)
> >> > +return -ENODEV;
> >> > +
> >> > +return 0;
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(wait_i915_probe_done);
> >> > +
> >> > +
> >> > static void i915_pci_remove(struct pci_dev *pdev)
> >> > {
> >> > struct drm_device *dev = pci_get_drvdata(pdev);
> >> > @@ -717,6 +732,7 @@ static int i915_pci_probe(struct pci_dev *pdev,
> >> > const struct pci_device_id *ent)
> >> > return err > 0 ? -ENOTTY : err;
> >> > }
> >> >
> >> > +complete_all(_probe_done);
> >> > return 0;
> >> > }
> >> >
> >> > @@ -726,6 +742,7 @@ static struct pci_driver i915_pci_driver = {
> >> > .probe = i915_pci_probe,
> >> > .remove = i915_pci_remove,
> >> > .driver.pm = _pm_ops,
> >> > +.driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> >> > };
> >> >
> >> > static int __init i915_init(void)
> >> > @@ -755,6 +772,8 @@ static int __init i915_init(void)
> >> > return 0;
> >> > }
> >> >
> >> > +init_completion(_probe_done);
> >> > +
> >> > return pci_register_driver(_pci_driver);
> >> > }
> >> >
> >> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> >> > index c9e5a66..adae172 100644
> >> > --- a/include/drm/i915_drm.h
> >> > +++ b/include/drm/i915_drm.h
> >> > @@ -36,6 +36,12 @@ extern bool i915_gpu_lower(void);
> >> > extern bool i915_gpu_busy(void);
> >> > extern bool i915_gpu_turbo_disable(void);
> >> >
> >> > +/*
> >> > + * For use by HDA driver for now
> >> > + * Return 0 on i915 probe is done, and -ENODEV on error
> >> > + */
> >> > +extern int wait_i915_probe_done(int timeout);
> >> > +
> >> > /* Exported from arch/x86/kernel/early-quirks.c */
> >> > extern struct resource intel_graphics_stolen_res;
> >> >
> >> > diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> >> > index cbe818e..48e5039 100644
> >> > --- a/sound/hda/hdac_i915.c
> >> > +++ b/sound/hda/hdac_i915.c
> >> > @@ -17,6 +17,7 @@
> >> > #include
> >> > #include
> >> > #include
> >> > +#include
> >> > #include
> >> > #include
> >> > #include
> >> > @@
Re: [Intel-gfx] [PATCH v2 00/12] drm: Add generic fbdev emulation
On Mon, Jun 18, 2018 at 04:17:27PM +0200, Noralf Trønnes wrote: > This patchset adds generic fbdev emulation for drivers that supports GEM > based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An > API is begun to support in-kernel clients in general. > > Notable changes since version 1: > > - Rework client unregister code. I've used reference counting to manage > the fact that both the client itself and the driver through > drm_dev_unregister() can release the client. The client is now released > using drm_client_put() instead of drm_client_free(). I started reviewing the reworked client register/unregister stuff, and it looks good, except this kref stuff here for clients. I don't understand why you need this - as long as removal from dev->clientlist is properly protected by the mutex, I don't see how both the client and the device can release the client at the same time. Of course this means that both the device-trigger unregister and the client-triggered unregister must first grab the mutex, remove the client from the list, and only if that was done succesfully, clean up the client. If the client is already removed from the list (i.e. list_empty() is true) then you need to bail out to avoid double-freeing. I don't think there's a need to use a kref here. And kref has the tricky issue that you tempt everyone into constructing references loops between drm_device and drm_client (which require lots of jumping through hoops in your v1 to make sure you can break those reference loops). > - fbdev: Use a shadow buffer for framebuffers that have a dirty > callback. This makes the fbdev client truly generic and useable for all > drivers. There's a blitting penalty, but this is generic emulation after > all. The reason for needing a shadow buffer is that deferred I/O only > works with kmalloc/vmalloc buffers and not with shmem buffers > (page->lru/mapping). Yeah I think that's the only feasible option. Everyone who cares more about fbdev performance can keep their driver-specific code. And for other drm_client users this shouldn't be a problem, since they know how to use dirty and flipping between multiple buffers to drive kms as it was designed. The issue really only exists for fbdev's assumption of a direct mmap of a dumb framebuffer, encoded into the uapi. > - Let tinydrm use the full fbdev client \o/ Cheers, Daniel > > Noralf. > > Changes since version 1: > - Make it possible to embed struct drm_client_dev and drop the private > pointer > - Use kref reference counting to control client release since both the > client and the driver can release. > - Add comment about using dma-buf as a possibility with some rework > - Move buffer NULL check to drm_client_framebuffer_delete() > - Move client name to struct drm_client_dev > - Move up drm_dev_get/put calls to make them more visible > - Move drm_client_dev.list definition to later patch that makes use of it > > - Embed drm_client at the beginning of drm_fb_helper to avoid a fragile > transitional kfree hack in drm_client_release() > - Set owner in drm_fbdev_fb_ops > - Add kerneldoc to drm_fb_helper_generic_probe() > > - Remove unused functions > - Change name drm_client_funcs.lastclose -> .restore > - Change name drm_client_funcs.remove -> .unregister > - Rework unregister code > > - tinydrm: Use drm_fbdev_generic_setup() and remove > drm_fb_cma_fbdev_init_with_funcs() > > David Herrmann (1): > drm: provide management functions for drm_file > > Noralf Trønnes (11): > drm/file: Don't set master on in-kernel clients > drm: Make ioctls available for in-kernel clients > drm: Begin an API for in-kernel clients > drm/fb-helper: Add generic fbdev emulation .fb_probe function > drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap > drm/cma-helper: Use the generic fbdev emulation > drm/client: Add client callbacks > drm/debugfs: Add internal client debugfs file > drm/fb-helper: Finish the generic fbdev emulation > drm/tinydrm: Use drm_fbdev_generic_setup() > drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() > > Documentation/gpu/drm-client.rst| 12 + > Documentation/gpu/index.rst | 1 + > drivers/gpu/drm/Makefile| 2 +- > drivers/gpu/drm/drm_client.c| 435 > > drivers/gpu/drm/drm_crtc_internal.h | 19 +- > drivers/gpu/drm/drm_debugfs.c | 7 + > drivers/gpu/drm/drm_drv.c | 8 + > drivers/gpu/drm/drm_dumb_buffers.c | 33 ++- > drivers/gpu/drm/drm_fb_cma_helper.c | 380 +++- > drivers/gpu/drm/drm_fb_helper.c | 330 - > drivers/gpu/drm/drm_file.c | 304 ++- > drivers/gpu/drm/drm_framebuffer.c | 42 ++- > drivers/gpu/drm/drm_internal.h | 2 + > drivers/gpu/drm/drm_ioctl.c | 4 +- >
Re: [Intel-gfx] [PATCH v2 09/12] drm/debugfs: Add internal client debugfs file
On Mon, Jun 18, 2018 at 04:17:36PM +0200, Noralf Trønnes wrote:
> Print the names of the internal clients currently attached.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_client.c | 28
> drivers/gpu/drm/drm_debugfs.c | 7 +++
> include/drm/drm_client.h | 2 ++
> 3 files changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index f1dc04d641cc..3ebb8fa34655 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -405,3 +405,31 @@ void drm_client_framebuffer_delete(struct
> drm_client_buffer *buffer)
> drm_client_buffer_delete(buffer);
> }
> EXPORT_SYMBOL(drm_client_framebuffer_delete);
> +
> +#ifdef CONFIG_DEBUG_FS
> +static int drm_client_debugfs_internal_clients(struct seq_file *m, void
> *data)
> +{
> + struct drm_info_node *node = m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct drm_printer p = drm_seq_file_printer(m);
> + struct drm_client_dev *client;
> +
> + mutex_lock(>clientlist_mutex);
> + list_for_each_entry(client, >clientlist, list)
> + drm_printf(, "%s\n", client->name);
> + mutex_unlock(>clientlist_mutex);
> +
> + return 0;
> +}
> +
> +static const struct drm_info_list drm_client_debugfs_list[] = {
> + { "internal_clients", drm_client_debugfs_internal_clients, 0 },
> +};
> +
> +int drm_client_debugfs_init(struct drm_minor *minor)
> +{
> + return drm_debugfs_create_files(drm_client_debugfs_list,
> + ARRAY_SIZE(drm_client_debugfs_list),
> + minor->debugfs_root, minor);
> +}
> +#endif
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index b2482818fee8..50a20bfc07ea 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -28,6 +28,7 @@
> #include
> #include
>
> +#include
> #include
> #include
> #include
> @@ -164,6 +165,12 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
> DRM_ERROR("Failed to create framebuffer debugfs
> file\n");
> return ret;
> }
> +
> + ret = drm_client_debugfs_init(minor);
> + if (ret) {
> + DRM_ERROR("Failed to create client debugfs file\n");
> + return ret;
> + }
> }
>
> if (dev->driver->debugfs_init) {
> diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
> index 80fe21c86f69..c3a87d6c30fc 100644
> --- a/include/drm/drm_client.h
> +++ b/include/drm/drm_client.h
> @@ -151,4 +151,6 @@ struct drm_client_buffer *
> drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32
> height, u32 format);
> void drm_client_framebuffer_delete(struct drm_client_buffer *buffer);
>
> +int drm_client_debugfs_init(struct drm_minor *minor);
> +
> #endif
> --
> 2.15.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
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/dp: try normal detection on connector force enable (rev2)
== Series Details == Series: drm/i915/dp: try normal detection on connector force enable (rev2) URL : https://patchwork.freedesktop.org/series/45056/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4346 -> Patchwork_9366 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/45056/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_9366 that come from known issues: === IGT changes === Issues hit igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927) Possible fixes igt@debugfs_test@read_all_entries: fi-snb-2520m: INCOMPLETE (fdo#103713) -> PASS igt@gem_exec_gttfill@basic: fi-byt-n2820: FAIL (fdo#106744) -> PASS igt@kms_flip@basic-flip-vs-wf_vblank: fi-glk-j4005: FAIL (fdo#100368) -> PASS igt@kms_flip@basic-plain-flip: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106744 https://bugs.freedesktop.org/show_bug.cgi?id=106744 == Participating hosts (42 -> 37) == Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4346 -> Patchwork_9366 CI_DRM_4346: 92d7e0feac3acdf911aacfcc8a5df92756e2d11a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4525: 578c645406d59138029fa6ef343fcc87c2d95d4c @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_9366: 2703dcc12d6c2781ad55288fd7fac0cc3debee65 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2703dcc12d6c drm/i915/dp: try normal detection on connector force enable == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9366/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 05/14] drm/sti: Try to fix up the tvout possible clones
2018-06-18 14:38 GMT+02:00 Ville Syrjala : > From: Ville Syrjälä > > The current possible_clones setup doesn't look sensible. I'm assuming > the 0 and 1 are supposed to refer to the indexes of the hdmi and hda > encoders? So it kinda looks like we want hda+hdmi cloning, but then > dvo also claims to be cloneable with hdmi, but hdmi won't recipricate. > > Benjamin tells me all encoders should be cloneable with each other, > so let's fix up the masks to indicate that. > > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Signed-off-by: Ville Syrjälä Acked-by: Benjamin Gaignard Thanks > --- > drivers/gpu/drm/sti/sti_tvout.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c > index 7d495307fe79..8bca519b3bfe 100644 > --- a/drivers/gpu/drm/sti/sti_tvout.c > +++ b/drivers/gpu/drm/sti/sti_tvout.c > @@ -668,7 +668,6 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, > drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > _tvout_encoder_funcs, DRM_MODE_ENCODER_LVDS, > @@ -721,7 +720,6 @@ static struct drm_encoder > *sti_tvout_create_hda_encoder(struct drm_device *dev, > drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > _tvout_encoder_funcs, DRM_MODE_ENCODER_DAC, NULL); > @@ -770,7 +768,6 @@ static struct drm_encoder > *sti_tvout_create_hdmi_encoder(struct drm_device *dev, > drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 1; > > drm_encoder_init(dev, drm_encoder, > _tvout_encoder_funcs, DRM_MODE_ENCODER_TMDS, > NULL); > @@ -786,6 +783,13 @@ static void sti_tvout_create_encoders(struct drm_device > *dev, > tvout->hdmi = sti_tvout_create_hdmi_encoder(dev, tvout); > tvout->hda = sti_tvout_create_hda_encoder(dev, tvout); > tvout->dvo = sti_tvout_create_dvo_encoder(dev, tvout); > + > + tvout->hdmi->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > + tvout->hda->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > + tvout->dvo->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > } > > static void sti_tvout_destroy_encoders(struct sti_tvout *tvout) > -- > 2.16.4 > -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH v2] drm/i915/dp: try normal detection on connector force enable
Connector force enable on DP bypasses the detect hooks, skipping all the
DPCD parameter reading and negotiation. This does not really have a
chance to work, at all, and any modesets are bound to fail.
Try to do the normal detection in the force hook on force enable.
v2: fix unused variable warnings
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103347
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106291
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6ac6c8787dcf..93db47ecda06 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4955,21 +4955,17 @@ static void
intel_dp_force(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
- struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
- struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
intel_dp_unset_edid(intel_dp);
- if (connector->status != connector_status_connected)
- return;
-
- intel_display_power_get(dev_priv, intel_dp->aux_power_domain);
-
- intel_dp_set_edid(intel_dp);
-
- intel_display_power_put(dev_priv, intel_dp->aux_power_domain);
+ /*
+* Force enable doesn't really work with DP. Try the normal detect path
+* anyway to read the DPCD etc.
+*/
+ if (connector->status == connector_status_connected)
+ drm_helper_probe_detect(connector, NULL, false);
}
static int intel_dp_get_modes(struct drm_connector *connector)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib: Spin fast, retire early
When using the pollable spinner, we often want to use it as a means of
ensuring the task is running on the GPU before switching to something
else. In which case we don't want to add extra delay inside the spinner,
but the current 1000 NOPs add on order of 5us, which is often larger
than the target latency.
Signed-off-by: Chris Wilson
Reviewed-by: Antonio Argenziano
---
lib/igt_dummyload.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/igt_dummyload.c b/lib/igt_dummyload.c
index 3809b4e61..d73b4abd5 100644
--- a/lib/igt_dummyload.c
+++ b/lib/igt_dummyload.c
@@ -77,6 +77,7 @@ fill_reloc(struct drm_i915_gem_relocation_entry *reloc,
#define OUT_FENCE (1 << 0)
#define POLL_RUN (1 << 1)
+#define SPIN_FAST (1 << 2)
static int
emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t ctx, unsigned engine,
@@ -205,7 +206,8 @@ emit_recursive_batch(igt_spin_t *spin, int fd, uint32_t
ctx, unsigned engine,
* between function calls, that appears enough to keep SNB out of
* trouble. See https://bugs.freedesktop.org/show_bug.cgi?id=102262
*/
- batch += 1000;
+ if (!(flags & SPIN_FAST))
+ batch += 1000;
/* recurse */
r = [obj[BATCH].relocation_count++];
@@ -362,7 +364,7 @@ igt_spin_batch_new_fence(int fd, uint32_t ctx, unsigned
engine)
igt_spin_t *
__igt_spin_batch_new_poll(int fd, uint32_t ctx, unsigned engine)
{
- return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN);
+ return ___igt_spin_batch_new(fd, ctx, engine, 0, POLL_RUN | SPIN_FAST);
}
/**
--
2.18.0.rc2
___
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/dp: try normal detection on connector force enable
== Series Details == Series: drm/i915/dp: try normal detection on connector force enable URL : https://patchwork.freedesktop.org/series/45056/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/intel_dp.o drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_force’: drivers/gpu/drm/i915/intel_dp.c:4959:27: error: unused variable ‘dev_priv’ [-Werror=unused-variable] struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev); ^~~~ cc1: all warnings being treated as errors scripts/Makefile.build:317: recipe for target 'drivers/gpu/drm/i915/intel_dp.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_dp.o] Error 1 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:558: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1034: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/20] drm/i915/icl: Program DSI Escape clock Divider
> -Original Message-
> From: Zanoni, Paulo R
> Sent: Friday, June 15, 2018 11:41 PM
> To: Chauhan, Madhav ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani ; Shankar, Uma
> ; Vivi, Rodrigo
> Subject: Re: [PATCH 02/20] drm/i915/icl: Program DSI Escape clock Divider
>
> Em Sex, 2018-06-15 às 23:30 +0530, Chauhan, Madhav escreveu:
> > > -Original Message-
> > > From: Zanoni, Paulo R
> > > Sent: Friday, June 15, 2018 11:00 PM
> > > To: Chauhan, Madhav ; intel-
> > > g...@lists.freedesktop.org
> > > Cc: Nikula, Jani ; Shankar, Uma
> > > ; Vivi, Rodrigo
> > > Subject: Re: [PATCH 02/20] drm/i915/icl: Program DSI Escape clock
> > > Divider
> > >
> > > Em Sex, 2018-06-15 às 15:51 +0530, Madhav Chauhan escreveu:
> > > > Escape Clock is used for LP communication across the DSI Link. To
> > > > achieve the constant frequency of the escape clock from the
> > > > variable DPLL frequency output, a variable divider(M) is needed.
> > > > This patch programs the same.
> > > >
> > > > Signed-off-by: Madhav Chauhan
> > > > ---
> > > > drivers/gpu/drm/i915/Makefile| 1 +
> > > > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > > > drivers/gpu/drm/i915/intel_dsi_new.c | 65
> > > >
> > > > 3 files changed, 67 insertions(+) create mode 100644
> > > > drivers/gpu/drm/i915/intel_dsi_new.c
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/Makefile
> > > > b/drivers/gpu/drm/i915/Makefile index 4c6adae..a5f60c8 100644
> > > > --- a/drivers/gpu/drm/i915/Makefile
> > > > +++ b/drivers/gpu/drm/i915/Makefile
> > > > @@ -142,6 +142,7 @@ i915-y += dvo_ch7017.o \
> > > > intel_dp_mst.o \
> > > > intel_dp.o \
> > > > intel_dsi.o \
> > > > + intel_dsi_new.o \
> > > > intel_dsi_dcs_backlight.o \
> > > > intel_dsi_pll.o \
> > > > intel_dsi_vbt.o \
> > > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > > b/drivers/gpu/drm/i915/i915_reg.h index bf2d3e4..55ef57d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > > @@ -9350,6 +9350,7 @@ enum skl_power_gate {
> > > > _ICL_DPHY_ESC_CL
> > > > K_DI
> > > > V0, \
> > > > _ICL_DPHY_ESC_CL
> > > > K_DI
> > > > V1)
> > > > #define ICL_ESC_CLK_DIV_MASK 0x1ff
> > > > +#define DSI_MAX_ESC_CLK2
> > > > /* in KHz */
> > > >
> > > > /* Gen4+ Timestamp and Pipe Frame time stamp registers */
> > > > #define GEN4_TIMESTAMP _MMIO(0x2358)
> > > > diff --git a/drivers/gpu/drm/i915/intel_dsi_new.c
> > > > b/drivers/gpu/drm/i915/intel_dsi_new.c
> > > > new file mode 100644
> > > > index 000..0d325ca
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/i915/intel_dsi_new.c
> > > > @@ -0,0 +1,65 @@
> > >
> > > I am not a lawyer nor a license expert, but as far as I understand
> > > (and I may be wrong):
> > >
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > >
> > > the line above...
> >
> > I was getting checkpatch warning and then I explored the options and
> > found this.
> > Looked at some of the recent files added (intel_hdcp.c) as well and
> > they have this option .
> >
> > >
> > > > +/*
> > > > + * Copyright © 2018 Intel Corporation
> > > > + *
> > > > + * Permission is hereby granted, free of charge, to any person
> > > > obtaining a
> > > > + * copy of this software and associated documentation files (the
> > > > "Software"),
> > > > + * to deal in the Software without restriction, including
> > > > without
> > > > limitation
> > > > + * the rights to use, copy, modify, merge, publish, distribute,
> > > > sublicense,
> > > > + * and/or sell copies of the Software, and to permit persons to
> > > > whom
> > > > the
> > > > + * Software is furnished to do so, subject to the following
> > > > conditions:
> > > > + *
> > > > + * The above copyright notice and this permission notice
> > > > (including
> > > > the next
> > > > + * paragraph) shall be included in all copies or substantial
> > > > portions of the
> > > > + * Software.
> > > > + *
> > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> > >
> > > KIND,
> > > > EXPRESS OR
> > > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > > > MERCHANTABILITY,
> > > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
> NO
> > > > EVENT SHALL
> > > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > >
> > > DAMAGES
> > > > OR OTHER
> > > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
> > >
> > > OTHERWISE,
> > > > ARISING
> > > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
> USE
> > >
> > > OR
> > > > OTHER
> > > > + * DEALINGS IN THE SOFTWARE.
> > >
> > > ... does not seem to match the license above.
> >
> > Can you please be more specific here??
>
> Please read the two links I gave. The file has an SPDX identifier for GPL-2.0+
> but
[Intel-gfx] [RFC PATCH] drm/i915/dp: try normal detection on connector force enable
Connector force enable on DP bypasses the detect hooks, skipping all the DPCD parameter reading and negotiation. This does not really have a chance to work, at all, and any modesets are bound to fail. Try to do the normal detection in the force hook on force enable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103347 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106291 Cc: Ville Syrjälä Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 6ac6c8787dcf..ec9c96b1d013 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4962,14 +4962,12 @@ intel_dp_force(struct drm_connector *connector) connector->base.id, connector->name); intel_dp_unset_edid(intel_dp); - if (connector->status != connector_status_connected) - return; - - intel_display_power_get(dev_priv, intel_dp->aux_power_domain); - - intel_dp_set_edid(intel_dp); - - intel_display_power_put(dev_priv, intel_dp->aux_power_domain); + /* +* Force enable doesn't really work with DP. Try the normal detect path +* anyway to read the DPCD etc. +*/ + if (connector->status == connector_status_connected) + drm_helper_probe_detect(connector, NULL, false); } static int intel_dp_get_modes(struct drm_connector *connector) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] i915: make the probe asynchronous
On Wed, Jun 20, 2018 at 10:11:34AM +0300, Jani Nikula wrote:
> On Wed, 20 Jun 2018, Feng Tang wrote:
> > Hi Takashi,
> >
> > On Wed, Jun 20, 2018 at 08:35:05AM +0200, Takashi Iwai wrote:
> >> On Wed, 20 Jun 2018 08:25:23 +0200,
> >> Feng Tang wrote:
> >> >
> >> > Hi Jani/Chris/Takashi,
> >> >
> >> > On Wed, Jun 06, 2018 at 11:21:43AM +0300, Jani Nikula wrote:
> >> > > >>
> >> > > >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-ch...@chris-wilson.co.uk
> >> > > >
> >> > > > IIUC, you are waiting for the HDA audio driver to first handle the
> >> > > > i915 sync probel case?
> >> > >
> >> > > I wouldn't hold my breath waiting. If you want to do i915 async probe,
> >> > > you'll probably have to figure hda out as well.
> >> >
> >> > I made the following patch based on 4.18-rc1, and tested on my machine,
> >> > which basically works fine with Async probe taking effect (I tried
> >> > builtin and modules way).
> >> >
> >> > Please review this initial version, and I'll separate to clean patches
> >> > if you think it's OK. thanks!
> >>
> >> When you call an i915 function from HD-audio driver, you made already
> >> a hard dependency. This is exactly what we want to avoid.
> >
> > Thanks for the info, I see your intension now.
> >
> > In previous discussion, Jani suggested to use a completion to indicate
> > the probe done, I can't figure out another way :)
>
> I suggested you do that within hdac_i915.c. Wait in snd_hdac_i915_init()
> below request_module(), complete in hdac_component_master_bind().
I thgouth this kind of cross-driver dependency is supposed to be handled
using EPROBE_DEFER? Why do we need to hand-roll that here?
Or is this some other kind of synchronization need that needs a bespoke
solution?
-Daniel
>
> BR,
> Jani.
>
> >
> > In my own debug patch, I had put a
> > #ifndef CONFIG_DRM_I915
> > static inline int wait_i915_probe_done() {return -ENODEV;}
> > #else
> >
> > #endif
> >
> > Is this fine?
> >
> > btw, for hdac_i915.c, if it is already bound with i915, can we make
> > it an separte module to dedpend on i915?
> >
> > Thanks,
> > Feng
> >
> >>
> >>
> >> thanks,
> >>
> >> Takashi
> >>
> >> >
> >> > - Feng
> >> >
> >> >
> >> > --
> >> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> >> > b/drivers/gpu/drm/i915/i915_pci.c
> >> > index 4364922..16a59ae 100644
> >> > --- a/drivers/gpu/drm/i915/i915_pci.c
> >> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> >> > @@ -671,6 +671,21 @@ static const struct pci_device_id pciidlist[] = {
> >> > };
> >> > MODULE_DEVICE_TABLE(pci, pciidlist);
> >> >
> >> > +static struct completion i915_probe_done;
> >> > +
> >> > +int wait_i915_probe_done(int timeout)
> >> > +{
> >> > +int ret;
> >> > +
> >> > +ret =
> >> > wait_for_completion_interruptible_timeout(_probe_done, timeout);
> >> > +if (ret <= 0)
> >> > +return -ENODEV;
> >> > +
> >> > +return 0;
> >> > +}
> >> > +EXPORT_SYMBOL_GPL(wait_i915_probe_done);
> >> > +
> >> > +
> >> > static void i915_pci_remove(struct pci_dev *pdev)
> >> > {
> >> > struct drm_device *dev = pci_get_drvdata(pdev);
> >> > @@ -717,6 +732,7 @@ static int i915_pci_probe(struct pci_dev *pdev,
> >> > const struct pci_device_id *ent)
> >> > return err > 0 ? -ENOTTY : err;
> >> > }
> >> >
> >> > +complete_all(_probe_done);
> >> > return 0;
> >> > }
> >> >
> >> > @@ -726,6 +742,7 @@ static struct pci_driver i915_pci_driver = {
> >> > .probe = i915_pci_probe,
> >> > .remove = i915_pci_remove,
> >> > .driver.pm = _pm_ops,
> >> > +.driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> >> > };
> >> >
> >> > static int __init i915_init(void)
> >> > @@ -755,6 +772,8 @@ static int __init i915_init(void)
> >> > return 0;
> >> > }
> >> >
> >> > +init_completion(_probe_done);
> >> > +
> >> > return pci_register_driver(_pci_driver);
> >> > }
> >> >
> >> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> >> > index c9e5a66..adae172 100644
> >> > --- a/include/drm/i915_drm.h
> >> > +++ b/include/drm/i915_drm.h
> >> > @@ -36,6 +36,12 @@ extern bool i915_gpu_lower(void);
> >> > extern bool i915_gpu_busy(void);
> >> > extern bool i915_gpu_turbo_disable(void);
> >> >
> >> > +/*
> >> > + * For use by HDA driver for now
> >> > + * Return 0 on i915 probe is done, and -ENODEV on error
> >> > + */
> >> > +extern int wait_i915_probe_done(int timeout);
> >> > +
> >> > /* Exported from arch/x86/kernel/early-quirks.c */
> >> > extern struct resource intel_graphics_stolen_res;
> >> >
> >> > diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> >> > index cbe818e..48e5039 100644
> >> > --- a/sound/hda/hdac_i915.c
> >> > +++ b/sound/hda/hdac_i915.c
> >> > @@ -17,6 +17,7 @@
> >> > #include
> >> > #include
> >> > #include
> >> > +#include
> >> > #include
> >> > #include
> >> > #include
>
Re: [Intel-gfx] [RFC] i915: make the probe asynchronous
On Wed, 20 Jun 2018, Feng Tang wrote:
> Hi Takashi,
>
> On Wed, Jun 20, 2018 at 08:35:05AM +0200, Takashi Iwai wrote:
>> On Wed, 20 Jun 2018 08:25:23 +0200,
>> Feng Tang wrote:
>> >
>> > Hi Jani/Chris/Takashi,
>> >
>> > On Wed, Jun 06, 2018 at 11:21:43AM +0300, Jani Nikula wrote:
>> > > >>
>> > > >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-ch...@chris-wilson.co.uk
>> > > >
>> > > > IIUC, you are waiting for the HDA audio driver to first handle the
>> > > > i915 sync probel case?
>> > >
>> > > I wouldn't hold my breath waiting. If you want to do i915 async probe,
>> > > you'll probably have to figure hda out as well.
>> >
>> > I made the following patch based on 4.18-rc1, and tested on my machine,
>> > which basically works fine with Async probe taking effect (I tried
>> > builtin and modules way).
>> >
>> > Please review this initial version, and I'll separate to clean patches
>> > if you think it's OK. thanks!
>>
>> When you call an i915 function from HD-audio driver, you made already
>> a hard dependency. This is exactly what we want to avoid.
>
> Thanks for the info, I see your intension now.
>
> In previous discussion, Jani suggested to use a completion to indicate
> the probe done, I can't figure out another way :)
I suggested you do that within hdac_i915.c. Wait in snd_hdac_i915_init()
below request_module(), complete in hdac_component_master_bind().
BR,
Jani.
>
> In my own debug patch, I had put a
> #ifndef CONFIG_DRM_I915
> static inline int wait_i915_probe_done() {return -ENODEV;}
> #else
>
> #endif
>
> Is this fine?
>
> btw, for hdac_i915.c, if it is already bound with i915, can we make
> it an separte module to dedpend on i915?
>
> Thanks,
> Feng
>
>>
>>
>> thanks,
>>
>> Takashi
>>
>> >
>> > - Feng
>> >
>> >
>> > --
>> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
>> > b/drivers/gpu/drm/i915/i915_pci.c
>> > index 4364922..16a59ae 100644
>> > --- a/drivers/gpu/drm/i915/i915_pci.c
>> > +++ b/drivers/gpu/drm/i915/i915_pci.c
>> > @@ -671,6 +671,21 @@ static const struct pci_device_id pciidlist[] = {
>> > };
>> > MODULE_DEVICE_TABLE(pci, pciidlist);
>> >
>> > +static struct completion i915_probe_done;
>> > +
>> > +int wait_i915_probe_done(int timeout)
>> > +{
>> > + int ret;
>> > +
>> > + ret = wait_for_completion_interruptible_timeout(_probe_done,
>> > timeout);
>> > + if (ret <= 0)
>> > + return -ENODEV;
>> > +
>> > + return 0;
>> > +}
>> > +EXPORT_SYMBOL_GPL(wait_i915_probe_done);
>> > +
>> > +
>> > static void i915_pci_remove(struct pci_dev *pdev)
>> > {
>> >struct drm_device *dev = pci_get_drvdata(pdev);
>> > @@ -717,6 +732,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
>> > struct pci_device_id *ent)
>> >return err > 0 ? -ENOTTY : err;
>> >}
>> >
>> > + complete_all(_probe_done);
>> >return 0;
>> > }
>> >
>> > @@ -726,6 +742,7 @@ static struct pci_driver i915_pci_driver = {
>> >.probe = i915_pci_probe,
>> >.remove = i915_pci_remove,
>> >.driver.pm = _pm_ops,
>> > + .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
>> > };
>> >
>> > static int __init i915_init(void)
>> > @@ -755,6 +772,8 @@ static int __init i915_init(void)
>> >return 0;
>> >}
>> >
>> > + init_completion(_probe_done);
>> > +
>> >return pci_register_driver(_pci_driver);
>> > }
>> >
>> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> > index c9e5a66..adae172 100644
>> > --- a/include/drm/i915_drm.h
>> > +++ b/include/drm/i915_drm.h
>> > @@ -36,6 +36,12 @@ extern bool i915_gpu_lower(void);
>> > extern bool i915_gpu_busy(void);
>> > extern bool i915_gpu_turbo_disable(void);
>> >
>> > +/*
>> > + * For use by HDA driver for now
>> > + * Return 0 on i915 probe is done, and -ENODEV on error
>> > + */
>> > +extern int wait_i915_probe_done(int timeout);
>> > +
>> > /* Exported from arch/x86/kernel/early-quirks.c */
>> > extern struct resource intel_graphics_stolen_res;
>> >
>> > diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
>> > index cbe818e..48e5039 100644
>> > --- a/sound/hda/hdac_i915.c
>> > +++ b/sound/hda/hdac_i915.c
>> > @@ -17,6 +17,7 @@
>> > #include
>> > #include
>> > #include
>> > +#include
>> > #include
>> > #include
>> > #include
>> > @@ -357,6 +358,7 @@ static bool i915_gfx_present(void)
>> > *
>> > * Returns zero for success or a negative error code.
>> > */
>> > +#define HDAC_WAIT_I915_LOAD_MS3000
>> > int snd_hdac_i915_init(struct hdac_bus *bus)
>> > {
>> >struct component_match *match = NULL;
>> > @@ -386,7 +388,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
>> > * Atm, we don't support deferring the component binding, so make sure
>> > * i915 is loaded and that the binding successfully completes.
>> > */
>> > - request_module("i915");
>> > + ret = wait_i915_probe_done(HDAC_WAIT_I915_LOAD_MS);
>> > + if (ret) {
>> > + dev_info(dev, "failed to wait for i915 probe
[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: make the probe asynchronous (rev2)
== Series Details ==
Series: i915: make the probe asynchronous (rev2)
URL : https://patchwork.freedesktop.org/series/44159/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4344 -> Patchwork_9364 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9364 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9364, 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/44159/revisions/2/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9364:
=== IGT changes ===
Possible regressions
igt@drv_module_reload@basic-no-display:
fi-elk-e7500: PASS -> FAIL +1
fi-snb-2520m: PASS -> FAIL +1
{fi-whl-u}: PASS -> FAIL +1
fi-ivb-3520m: PASS -> FAIL +1
fi-pnv-d510:PASS -> FAIL +1
fi-kbl-7567u: PASS -> FAIL +1
fi-glk-j4005: PASS -> FAIL
fi-bwr-2160:PASS -> FAIL +1
fi-bdw-5557u: PASS -> FAIL +1
fi-hsw-peppy: PASS -> FAIL +1
fi-hsw-4770r: PASS -> FAIL +1
fi-skl-6260u: PASS -> FAIL +1
fi-snb-2600:PASS -> FAIL +1
fi-skl-6700k2: PASS -> FAIL +1
fi-skl-6770hq: PASS -> FAIL +1
fi-byt-n2820: PASS -> FAIL +1
fi-byt-j1900: PASS -> FAIL +1
fi-kbl-7560u: PASS -> FAIL +1
fi-skl-6600u: PASS -> FAIL +1
fi-bxt-j4205: PASS -> FAIL +1
igt@drv_module_reload@basic-reload:
fi-skl-guc: PASS -> FAIL +1
fi-bdw-gvtdvm: PASS -> FAIL +1
fi-kbl-r: PASS -> FAIL +1
fi-gdg-551: PASS -> FAIL +1
fi-cfl-8700k: PASS -> FAIL +1
fi-bxt-dsi: NOTRUN -> FAIL +1
fi-hsw-4770:PASS -> FAIL +1
fi-cfl-guc: PASS -> FAIL +1
fi-ilk-650: PASS -> FAIL +1
fi-bsw-n3050: PASS -> FAIL +1
fi-ivb-3770:PASS -> FAIL +1
fi-cfl-s3: PASS -> FAIL +1
fi-skl-6700hq: PASS -> FAIL +1
fi-kbl-7500u: PASS -> FAIL +1
fi-kbl-guc: PASS -> FAIL +1
fi-blb-e6850: PASS -> FAIL +1
fi-skl-gvtdvm: PASS -> FAIL +1
igt@drv_module_reload@basic-reload-inject:
fi-skl-6260u: PASS -> INCOMPLETE
fi-snb-2600:PASS -> INCOMPLETE
fi-kbl-7560u: PASS -> INCOMPLETE
fi-skl-6770hq: PASS -> INCOMPLETE
fi-bwr-2160:PASS -> INCOMPLETE
fi-kbl-r: PASS -> INCOMPLETE
fi-cfl-s3: PASS -> INCOMPLETE
fi-gdg-551: PASS -> INCOMPLETE
fi-ilk-650: PASS -> INCOMPLETE
fi-bsw-n3050: PASS -> INCOMPLETE
fi-kbl-7567u: PASS -> INCOMPLETE
fi-ivb-3770:PASS -> INCOMPLETE
{fi-whl-u}: PASS -> INCOMPLETE
fi-skl-6700hq: PASS -> INCOMPLETE
fi-kbl-7500u: PASS -> INCOMPLETE
fi-ivb-3520m: PASS -> INCOMPLETE
fi-hsw-4770:PASS -> INCOMPLETE
fi-bdw-5557u: PASS -> INCOMPLETE
fi-cfl-8700k: PASS -> INCOMPLETE
fi-hsw-peppy: PASS -> INCOMPLETE
fi-pnv-d510:PASS -> INCOMPLETE
fi-hsw-4770r: PASS -> INCOMPLETE
fi-blb-e6850: PASS -> INCOMPLETE
fi-skl-6700k2: PASS -> INCOMPLETE
Warnings
igt@drv_module_reload@basic-reload:
fi-glk-j4005: DMESG-WARN (fdo#106248, fdo#106725) -> FAIL
== Known issues ==
Here are the changes found in Patchwork_9364 that come from known issues:
=== IGT changes ===
Issues hit
igt@drv_module_reload@basic-reload-inject:
fi-byt-j1900: PASS -> INCOMPLETE (fdo#102657)
fi-kbl-guc: PASS -> INCOMPLETE (fdo#106693)
fi-byt-n2820: PASS -> INCOMPLETE (fdo#102657)
fi-bxt-j4205: PASS -> INCOMPLETE (fdo#103927)
fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713)
fi-bdw-gvtdvm: PASS -> INCOMPLETE (fdo#105600)
fi-glk-j4005: PASS -> INCOMPLETE (fdo#103359, k.org#198133)
fi-bxt-dsi: NOTRUN -> INCOMPLETE (fdo#103927)
fi-skl-gvtdvm: PASS -> INCOMPLETE (fdo#105600)
fi-skl-6600u: PASS -> INCOMPLETE (fdo#104108)
fi-skl-guc: PASS -> INCOMPLETE (fdo#106693)
fi-cfl-guc: PASS -> INCOMPLETE (fdo#106693)
fi-elk-e7500: PASS -> INCOMPLETE (fdo#103989)
igt@gem_exec_gttfill@basic:
fi-byt-n2820: PASS -> FAIL (fdo#106744)
igt@kms_flip@basic-flip-vs-dpms:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000)
Possible fixes
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
fi-bxt-dsi:
Re: [Intel-gfx] [PATCH v4 25/41] drm/i915: Enable and Disable HDCP2.2 port encryption
On Thursday 31 May 2018 12:39 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:44PM +0530, Ramalingam C wrote:
Implements the enable and disable functions for HDCP2.2 encryption
of the PORT.
v2:
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
v3:
No Changes.
v4:
Debug msg is added for timeout at Disable of Encryption [Uma]
%s/HDCP2_CTL/HDCP2_CTL
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index bd0bfcfd5b8f..0386a67c3e32 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -19,6 +19,7 @@
(enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES5
#define HDCP2_LC_RETRY_CNT3
+#define TIME_FOR_ENCRYPT_STATUS_CHANGE 32
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
const struct intel_hdcp_shim *shim)
@@ -1397,3 +1398,59 @@ static int hdcp2_authenticate_sink(struct
intel_connector *connector)
return ret;
}
+
+static int hdcp2_enable_encryption(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS)
+ return 0;
Relying on hw status for state decisions is in my experience bad - it
papers over bugs in our state handling. We should know what the expected
state of the hardware is.
If you want to write a bit more robust code, then keep these checks, but
wrap them in a WARN_ON. That way we'll know if there's a regression in the
code (e.g. unbalanced enable/disable) right away, instead of these checks
silently papering over them.
+
+ if (hdcp->hdcp_shim->toggle_signalling)
+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, true);
+
+ if (I915_READ(HDCP2_STATUS_DDI(port)) & LINK_AUTH_STATUS) {
Same for this check here. In general control flow that depends upon
register values which can change at runtime is very suspect from a design
robustness point of view.
Sure. I will move these HW status check into the WARN_ONs.
-Ram.
-Daniel
+
+ /* Link is Authenticated. Now set for Encryption */
+ I915_WRITE(HDCP2_CTL_DDI(port),
+ I915_READ(HDCP2_CTL_DDI(port)) |
+ CTL_LINK_ENCRYPTION_REQ);
+ }
+
+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS,
+ LINK_ENCRYPTION_STATUS,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);
+
+ return ret;
+}
+
+static int hdcp2_disable_encryption(struct intel_connector *connector)
+{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
+ enum port port = connector->encoder->port;
+ int ret;
+
+ if (!(I915_READ(HDCP2_STATUS_DDI(port)) & LINK_ENCRYPTION_STATUS))
+ return 0;
+
+ I915_WRITE(HDCP2_CTL_DDI(port),
+ I915_READ(HDCP2_CTL_DDI(port)) & ~CTL_LINK_ENCRYPTION_REQ);
+
+ ret = intel_wait_for_register(dev_priv, HDCP2_STATUS_DDI(port),
+ LINK_ENCRYPTION_STATUS, 0x0,
+ TIME_FOR_ENCRYPT_STATUS_CHANGE);
+ if (ret == -ETIMEDOUT)
+ DRM_DEBUG_KMS("Disable Encryption Timedout");
+
+ if (hdcp->hdcp_shim->toggle_signalling)
+ hdcp->hdcp_shim->toggle_signalling(intel_dig_port, false);
+
+ return ret;
+}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 22/41] drm/i915: Wrappers for mei HDCP2.2 services
On Thursday 31 May 2018 12:37 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:41PM +0530, Ramalingam C wrote:
Adds the wrapper for all mei hdcp2.2 service functions.
v2:
Rebased.
v3:
cldev is moved from mei_hdcp_data to hdcp.
v4:
%s/hdcp2_store_paring_info/hdcp2_store_pairing_info
Signed-off-by: Ramalingam C
This is a bit a style nit, but I'm not convinced of the value of these
wrappers. They just do basic sanity checking (and with the component
stuff, cldev should never be NULL before we get here), and those checks
that are still needed could be done just once when we start a hdcp2
operation.
Personally I'd drop these all and directly call the mei_ functions in the
later patches (plus put just 1 set of the sanity checks at the beginning
of a hdcp flow). More direct code is generally easier to read later on.
-Daniel
Daniel,
lets say we allow dynamic component unbind on cldev removal, even then
we need to check whether component is binded/unbinded before making a
call to the service functions.
Or may be checking the function ptr will be sufficient!? Need to check
though.
In that way small wrapper looks required my side. But yes, instead of
all wrappers together, in v5 I am merging them into the consumers
patches itself.
Still if we feel wrappers are not required we could get away from it.
Thanks,
Ram
---
drivers/gpu/drm/i915/intel_hdcp.c | 194 ++
1 file changed, 194 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index c7d0fa319c01..57c380c91cd0 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -10,10 +10,13 @@
#include
#include
#include
+#include
#include "intel_drv.h"
#include "i915_reg.h"
+#define GET_MEI_DDI_INDEX(port) (((port) == PORT_A) ? DDI_A : \
+(enum hdcp_physical_port) (port))
#define KEY_LOAD_TRIES5
static int intel_hdcp_poll_ksv_fifo(struct intel_digital_port *intel_dig_port,
@@ -896,3 +899,194 @@ int intel_hdcp_check_link(struct intel_connector
*connector)
mutex_unlock(>hdcp_mutex);
return ret;
}
+
+static int
+hdcp2_prepare_ake_init(struct intel_hdcp *hdcp, struct hdcp2_ake_init
*ake_data)
+{
+ struct mei_hdcp_data *data = >mei_data;
+ struct intel_connector *connector = container_of(hdcp,
+struct intel_connector,
+hdcp);
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ if (data->port == INVALID_PORT && connector->encoder)
+ data->port = GET_MEI_DDI_INDEX(connector->encoder->port);
+
+ /* Clear ME FW instance for the port, just incase */
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return mei_initiate_hdcp2_session(hdcp->cldev, data, ake_data);
+}
+
+static int hdcp2_close_mei_session(struct intel_hdcp *hdcp)
+{
+ struct mei_hdcp_data *data = >mei_data;
+
+ if (!hdcp->cldev || data->port == INVALID_PORT)
+ return -EINVAL;
+
+ return mei_close_hdcp_session(hdcp->cldev, data);
+}
+
+static int
+hdcp2_verify_rx_cert_prepare_km(struct intel_hdcp *hdcp,
+ struct hdcp2_ake_send_cert *rx_cert,
+ bool *paired,
+ struct hdcp2_ake_no_stored_km *ek_pub_km,
+ size_t *msg_sz)
+{
+ struct mei_hdcp_data *data = >mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_receiver_cert_prepare_km(hdcp->cldev, data, rx_cert,
+ paired, ek_pub_km, msg_sz);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int hdcp2_verify_hprime(struct intel_hdcp *hdcp,
+ struct hdcp2_ake_send_hprime *rx_hprime)
+{
+ struct mei_hdcp_data *data = >mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_verify_hprime(hdcp->cldev, data, rx_hprime);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int
+hdcp2_store_pairing_info(struct intel_hdcp *hdcp,
+ struct hdcp2_ake_send_pairing_info *pairing_info)
+{
+ struct mei_hdcp_data *data = >mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+ return -EINVAL;
+
+ ret = mei_store_pairing_info(hdcp->cldev, data, pairing_info);
+ if (ret < 0)
+ mei_close_hdcp_session(hdcp->cldev, data);
+
+ return ret;
+}
+
+static int
+hdcp2_prepare_lc_init(struct intel_hdcp *hdcp, struct hdcp2_lc_init *lc_init)
+{
+ struct mei_hdcp_data *data = >mei_data;
+ int ret;
+
+ if (!hdcp->cldev)
+
Re: [Intel-gfx] [RFC] i915: make the probe asynchronous
Hi Takashi,
On Wed, Jun 20, 2018 at 08:35:05AM +0200, Takashi Iwai wrote:
> On Wed, 20 Jun 2018 08:25:23 +0200,
> Feng Tang wrote:
> >
> > Hi Jani/Chris/Takashi,
> >
> > On Wed, Jun 06, 2018 at 11:21:43AM +0300, Jani Nikula wrote:
> > > >>
> > > >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-ch...@chris-wilson.co.uk
> > > >
> > > > IIUC, you are waiting for the HDA audio driver to first handle the
> > > > i915 sync probel case?
> > >
> > > I wouldn't hold my breath waiting. If you want to do i915 async probe,
> > > you'll probably have to figure hda out as well.
> >
> > I made the following patch based on 4.18-rc1, and tested on my machine,
> > which basically works fine with Async probe taking effect (I tried
> > builtin and modules way).
> >
> > Please review this initial version, and I'll separate to clean patches
> > if you think it's OK. thanks!
>
> When you call an i915 function from HD-audio driver, you made already
> a hard dependency. This is exactly what we want to avoid.
Thanks for the info, I see your intension now.
In previous discussion, Jani suggested to use a completion to indicate
the probe done, I can't figure out another way :)
In my own debug patch, I had put a
#ifndef CONFIG_DRM_I915
static inline int wait_i915_probe_done() {return -ENODEV;}
#else
#endif
Is this fine?
btw, for hdac_i915.c, if it is already bound with i915, can we make
it an separte module to dedpend on i915?
Thanks,
Feng
>
>
> thanks,
>
> Takashi
>
> >
> > - Feng
> >
> >
> > --
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index 4364922..16a59ae 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -671,6 +671,21 @@ static const struct pci_device_id pciidlist[] = {
> > };
> > MODULE_DEVICE_TABLE(pci, pciidlist);
> >
> > +static struct completion i915_probe_done;
> > +
> > +int wait_i915_probe_done(int timeout)
> > +{
> > + int ret;
> > +
> > + ret = wait_for_completion_interruptible_timeout(_probe_done,
> > timeout);
> > + if (ret <= 0)
> > + return -ENODEV;
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(wait_i915_probe_done);
> > +
> > +
> > static void i915_pci_remove(struct pci_dev *pdev)
> > {
> > struct drm_device *dev = pci_get_drvdata(pdev);
> > @@ -717,6 +732,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> > struct pci_device_id *ent)
> > return err > 0 ? -ENOTTY : err;
> > }
> >
> > + complete_all(_probe_done);
> > return 0;
> > }
> >
> > @@ -726,6 +742,7 @@ static struct pci_driver i915_pci_driver = {
> > .probe = i915_pci_probe,
> > .remove = i915_pci_remove,
> > .driver.pm = _pm_ops,
> > + .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> > };
> >
> > static int __init i915_init(void)
> > @@ -755,6 +772,8 @@ static int __init i915_init(void)
> > return 0;
> > }
> >
> > + init_completion(_probe_done);
> > +
> > return pci_register_driver(_pci_driver);
> > }
> >
> > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> > index c9e5a66..adae172 100644
> > --- a/include/drm/i915_drm.h
> > +++ b/include/drm/i915_drm.h
> > @@ -36,6 +36,12 @@ extern bool i915_gpu_lower(void);
> > extern bool i915_gpu_busy(void);
> > extern bool i915_gpu_turbo_disable(void);
> >
> > +/*
> > + * For use by HDA driver for now
> > + * Return 0 on i915 probe is done, and -ENODEV on error
> > + */
> > +extern int wait_i915_probe_done(int timeout);
> > +
> > /* Exported from arch/x86/kernel/early-quirks.c */
> > extern struct resource intel_graphics_stolen_res;
> >
> > diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> > index cbe818e..48e5039 100644
> > --- a/sound/hda/hdac_i915.c
> > +++ b/sound/hda/hdac_i915.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -357,6 +358,7 @@ static bool i915_gfx_present(void)
> > *
> > * Returns zero for success or a negative error code.
> > */
> > +#define HDAC_WAIT_I915_LOAD_MS 3000
> > int snd_hdac_i915_init(struct hdac_bus *bus)
> > {
> > struct component_match *match = NULL;
> > @@ -386,7 +388,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
> > * Atm, we don't support deferring the component binding, so make sure
> > * i915 is loaded and that the binding successfully completes.
> > */
> > - request_module("i915");
> > + ret = wait_i915_probe_done(HDAC_WAIT_I915_LOAD_MS);
> > + if (ret) {
> > + dev_info(dev, "failed to wait for i915 probe done\n");
> > + goto out_master_del;
> > + }
> >
> > if (!acomp->ops) {
> > ret = -ENODEV;
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: make the probe asynchronous (rev2)
== Series Details == Series: i915: make the probe asynchronous (rev2) URL : https://patchwork.freedesktop.org/series/44159/ State : warning == Summary == $ dim checkpatch origin/drm-tip 23766ec5a70a i915: make the probe asynchronous -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: > >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-ch...@chris-wilson.co.uk -:51: CHECK:LINE_SPACING: Please don't use multiple blank lines #51: FILE: drivers/gpu/drm/i915/i915_pci.c:689: + + -:92: CHECK:AVOID_EXTERNS: extern prototypes should be avoided in .h files #92: FILE: include/drm/i915_drm.h:43: +extern int wait_i915_probe_done(int timeout); -:129: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 2 checks, 81 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] i915: make the probe asynchronous
On Wed, 20 Jun 2018 08:25:23 +0200,
Feng Tang wrote:
>
> Hi Jani/Chris/Takashi,
>
> On Wed, Jun 06, 2018 at 11:21:43AM +0300, Jani Nikula wrote:
> > >>
> > >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-ch...@chris-wilson.co.uk
> > >
> > > IIUC, you are waiting for the HDA audio driver to first handle the
> > > i915 sync probel case?
> >
> > I wouldn't hold my breath waiting. If you want to do i915 async probe,
> > you'll probably have to figure hda out as well.
>
> I made the following patch based on 4.18-rc1, and tested on my machine,
> which basically works fine with Async probe taking effect (I tried
> builtin and modules way).
>
> Please review this initial version, and I'll separate to clean patches
> if you think it's OK. thanks!
When you call an i915 function from HD-audio driver, you made already
a hard dependency. This is exactly what we want to avoid.
thanks,
Takashi
>
> - Feng
>
>
> --
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 4364922..16a59ae 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -671,6 +671,21 @@ static const struct pci_device_id pciidlist[] = {
> };
> MODULE_DEVICE_TABLE(pci, pciidlist);
>
> +static struct completion i915_probe_done;
> +
> +int wait_i915_probe_done(int timeout)
> +{
> + int ret;
> +
> + ret = wait_for_completion_interruptible_timeout(_probe_done,
> timeout);
> + if (ret <= 0)
> + return -ENODEV;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(wait_i915_probe_done);
> +
> +
> static void i915_pci_remove(struct pci_dev *pdev)
> {
> struct drm_device *dev = pci_get_drvdata(pdev);
> @@ -717,6 +732,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> return err > 0 ? -ENOTTY : err;
> }
>
> + complete_all(_probe_done);
> return 0;
> }
>
> @@ -726,6 +742,7 @@ static struct pci_driver i915_pci_driver = {
> .probe = i915_pci_probe,
> .remove = i915_pci_remove,
> .driver.pm = _pm_ops,
> + .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
> };
>
> static int __init i915_init(void)
> @@ -755,6 +772,8 @@ static int __init i915_init(void)
> return 0;
> }
>
> + init_completion(_probe_done);
> +
> return pci_register_driver(_pci_driver);
> }
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index c9e5a66..adae172 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -36,6 +36,12 @@ extern bool i915_gpu_lower(void);
> extern bool i915_gpu_busy(void);
> extern bool i915_gpu_turbo_disable(void);
>
> +/*
> + * For use by HDA driver for now
> + * Return 0 on i915 probe is done, and -ENODEV on error
> + */
> +extern int wait_i915_probe_done(int timeout);
> +
> /* Exported from arch/x86/kernel/early-quirks.c */
> extern struct resource intel_graphics_stolen_res;
>
> diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
> index cbe818e..48e5039 100644
> --- a/sound/hda/hdac_i915.c
> +++ b/sound/hda/hdac_i915.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -357,6 +358,7 @@ static bool i915_gfx_present(void)
> *
> * Returns zero for success or a negative error code.
> */
> +#define HDAC_WAIT_I915_LOAD_MS 3000
> int snd_hdac_i915_init(struct hdac_bus *bus)
> {
> struct component_match *match = NULL;
> @@ -386,7 +388,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
>* Atm, we don't support deferring the component binding, so make sure
>* i915 is loaded and that the binding successfully completes.
>*/
> - request_module("i915");
> + ret = wait_i915_probe_done(HDAC_WAIT_I915_LOAD_MS);
> + if (ret) {
> + dev_info(dev, "failed to wait for i915 probe done\n");
> + goto out_master_del;
> + }
>
> if (!acomp->ops) {
> ret = -ENODEV;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Geminilake GuC(11.98), HuC(3.0.2225); Icelake DMC v1.05 (rev2)
HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Patchwork > Sent: keskiviikko 20. kesäkuuta 2018 3.30 > To: Srivatsa, Anusha > Cc: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for Geminilake GuC(11.98), > HuC(3.0.2225); Icelake DMC v1.05 (rev2) > > == Series Details == > > Series: Geminilake GuC(11.98), HuC(3.0.2225); Icelake DMC v1.05 (rev2) > URL : https://patchwork.freedesktop.org/series/45036/ > State : failure > > == Summary == > > = CI Bug Log - changes from CI_DRM_4344_full -> Patchwork_9363_full = > > == Summary - FAILURE == > > Serious unknown changes coming with Patchwork_9363_full absolutely > need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_9363_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > == Possible new issues == > > Here are the unknown changes that may have been introduced in > Patchwork_9363_full: > > === IGT changes === > > Possible regressions > > igt@debugfs_test@read_all_entries: > shard-glk: PASS -> DMESG-WARN +3 > > igt@drv_selftest@mock_contexts: > shard-apl: PASS -> DMESG-FAIL > shard-kbl: PASS -> DMESG-FAIL > shard-snb: PASS -> DMESG-FAIL > shard-hsw: PASS -> DMESG-FAIL > shard-glk: PASS -> DMESG-FAIL https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9363/shard-glk3/igt@drv_selftest@mock_contexts.html > > igt@pm_rpm@debugfs-read: > shard-apl: PASS -> DMESG-WARN > > igt@prime_busy@wait-hang-vebox: > shard-kbl: PASS -> DMESG-WARN +4 These should be checked carefully if because of this series. > > > Warnings > > igt@drv_selftest@live_evict: > shard-snb: PASS -> SKIP +13 > > igt@drv_selftest@live_execlists: > shard-hsw: PASS -> SKIP +13 > > igt@drv_selftest@live_objects: > shard-glk: PASS -> SKIP +14 > > igt@drv_selftest@live_workarounds: > shard-apl: PASS -> SKIP +24 > > igt@gem_exec_blt@cold-max: > shard-kbl: PASS -> SKIP +26 > > igt@gem_mocs_settings@mocs-rc6-ctx-dirty-render: > shard-kbl: SKIP -> PASS > > > == Known issues == > > Here are the changes found in Patchwork_9363_full that come from known > issues: > > === IGT changes === > > Issues hit > > igt@gem_eio@execbuf: > shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#103359) +1 > shard-apl: PASS -> INCOMPLETE (fdo#103927) +1 > > igt@gem_eio@unwedge-stress: > shard-glk: PASS -> FAIL (fdo#105957) > > igt@gem_render_copy_redux@interruptible: > shard-kbl: PASS -> INCOMPLETE (fdo#106650, fdo#103665) > > igt@kms_available_modes_crc@available_mode_test_crc: > shard-snb: PASS -> FAIL (fdo#106641) > > igt@kms_flip@dpms-vs-vblank-race: > shard-hsw: PASS -> FAIL (fdo#103060) > > igt@kms_flip_tiling@flip-x-tiled: > shard-glk: PASS -> FAIL (fdo#104724) > > igt@kms_setmode@basic: > shard-apl: PASS -> FAIL (fdo#99912) > > igt@prime_busy@wait-hang-render: > shard-kbl: PASS -> INCOMPLETE (fdo#103665) +3 > > > Possible fixes > > igt@drv_suspend@shrink: > shard-snb: FAIL (fdo#106886) -> PASS > > igt@gem_ctx_switch@basic-all-light: > shard-hsw: INCOMPLETE (fdo#103540) -> PASS > > igt@kms_cursor_legacy@cursora-vs-flipa-toggle: > shard-glk: DMESG-WARN (fdo#105763) -> PASS > > igt@kms_flip@2x-plain-flip-ts-check: > shard-glk: FAIL (fdo#100368) -> PASS > > igt@kms_flip@dpms-vs-vblank-race-interruptible: > shard-glk: FAIL (fdo#103060) -> PASS > > igt@kms_flip_tiling@flip-to-x-tiled: > shard-glk: FAIL (fdo#104724) -> PASS > > igt@kms_frontbuffer_tracking@fbc-2p-primscrn-shrfb-plflip-blt: > shard-glk: FAIL (fdo#104724, fdo#103167) -> PASS > > > fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 > fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 > fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 > fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 > fdo#103540 https://bugs.freedesktop.org/show_bug.cgi?id=103540 > fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 > fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 > fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 > fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 > fdo#105957 https://bugs.freedesktop.org/show_bug.cgi?id=105957 > fdo#106641
Re: [Intel-gfx] [RFC] i915: make the probe asynchronous
Hi Jani/Chris/Takashi,
On Wed, Jun 06, 2018 at 11:21:43AM +0300, Jani Nikula wrote:
> >>
> >> http://patchwork.freedesktop.org/patch/msgid/20180323083048.13327-1-ch...@chris-wilson.co.uk
> >
> > IIUC, you are waiting for the HDA audio driver to first handle the
> > i915 sync probel case?
>
> I wouldn't hold my breath waiting. If you want to do i915 async probe,
> you'll probably have to figure hda out as well.
I made the following patch based on 4.18-rc1, and tested on my machine,
which basically works fine with Async probe taking effect (I tried
builtin and modules way).
Please review this initial version, and I'll separate to clean patches
if you think it's OK. thanks!
- Feng
--
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 4364922..16a59ae 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -671,6 +671,21 @@ static const struct pci_device_id pciidlist[] = {
};
MODULE_DEVICE_TABLE(pci, pciidlist);
+static struct completion i915_probe_done;
+
+int wait_i915_probe_done(int timeout)
+{
+ int ret;
+
+ ret = wait_for_completion_interruptible_timeout(_probe_done,
timeout);
+ if (ret <= 0)
+ return -ENODEV;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(wait_i915_probe_done);
+
+
static void i915_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
@@ -717,6 +732,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return err > 0 ? -ENOTTY : err;
}
+ complete_all(_probe_done);
return 0;
}
@@ -726,6 +742,7 @@ static struct pci_driver i915_pci_driver = {
.probe = i915_pci_probe,
.remove = i915_pci_remove,
.driver.pm = _pm_ops,
+ .driver.probe_type = PROBE_PREFER_ASYNCHRONOUS,
};
static int __init i915_init(void)
@@ -755,6 +772,8 @@ static int __init i915_init(void)
return 0;
}
+ init_completion(_probe_done);
+
return pci_register_driver(_pci_driver);
}
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index c9e5a66..adae172 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -36,6 +36,12 @@ extern bool i915_gpu_lower(void);
extern bool i915_gpu_busy(void);
extern bool i915_gpu_turbo_disable(void);
+/*
+ * For use by HDA driver for now
+ * Return 0 on i915 probe is done, and -ENODEV on error
+ */
+extern int wait_i915_probe_done(int timeout);
+
/* Exported from arch/x86/kernel/early-quirks.c */
extern struct resource intel_graphics_stolen_res;
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c
index cbe818e..48e5039 100644
--- a/sound/hda/hdac_i915.c
+++ b/sound/hda/hdac_i915.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -357,6 +358,7 @@ static bool i915_gfx_present(void)
*
* Returns zero for success or a negative error code.
*/
+#define HDAC_WAIT_I915_LOAD_MS 3000
int snd_hdac_i915_init(struct hdac_bus *bus)
{
struct component_match *match = NULL;
@@ -386,7 +388,11 @@ int snd_hdac_i915_init(struct hdac_bus *bus)
* Atm, we don't support deferring the component binding, so make sure
* i915 is loaded and that the binding successfully completes.
*/
- request_module("i915");
+ ret = wait_i915_probe_done(HDAC_WAIT_I915_LOAD_MS);
+ if (ret) {
+ dev_info(dev, "failed to wait for i915 probe done\n");
+ goto out_master_del;
+ }
if (!acomp->ops) {
ret = -ENODEV;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
