Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Thu, 26 Nov 2015 08:57:30 +0100, Zhang, Xiong Y wrote: > > > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new > > > > component ops to get ELD and connection states. It was posted to > > > > alsa-devel shortly ago just as a reference, but this should work well > > > > in such a case, too. The test patches are found in test/hdmi-jack > > > > branch of my sound git tree. > > > > Did you try this branch (merge onto intel-test-nightly)? > > > [Zhang, Xiong Y] Yes, this branch could fix my issue. OK, good to hear. But this isn't for 4.4 or backport, as it's more radical changes. Could you check the patch below instead? This suppresses the notifier handling during suspend. It's bad, but the hotplug should be still handled via normal unsol event, so it should keep working, good enough as a stop gap. Takashi --- diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index bdb6f226d006..f7c70e2ae65c 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int port) struct hda_codec *codec = audio_ptr; int pin_nid = port + 0x04; - check_presence_and_report(codec, pin_nid); + if (!atomic_read(&codec->core.in_pm) && + !pm_runtime_suspended(hda_codec_dev(codec))) + check_presence_and_report(codec, pin_nid); } static int patch_generic_hdmi(struct hda_codec *codec) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/drm-misc
Hi Dave, I figured it's more than time to open up drm-next for 4.5 ;-) Here's the first drm-misc pull, with really mostly misc stuff all over. Somewhat invasive is only Ville's change to mark the arg struct for fb_create const - that might conflict with a new driver pull. So better to get in fast. Cheers, Daniel The following changes since commit 1ec218373b8ebda821aec00bb156a9c94fad9cd4: Linux 4.4-rc2 (2015-11-22 16:45:59 -0800) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-11-26 for you to fetch changes up to 87069f4493b2101a71a92b7b9565f488a605a88f: drm/mm: use list_next_entry (2015-11-25 16:22:58 +0100) Archit Taneja (2): drm/imx: Remove local fbdev emulation Kconfig option drm/tegra: Remove local fbdev emulation Kconfig option Daniel Vetter (4): drm: Update GEM refcounting docs drm/gem: Update/Polish docs drm/sysfs: Grab lock for edid/modes_show drm/sysfs: Send out uevent when connector->force changes Geliang Tang (2): drm/mm: rewrite drm_mm_for_each_hole drm/mm: use list_next_entry Jani Nikula (3): drm/dp: add eDP DPCD backlight control bit definitions drm: fix potential dangling else problems in for_each_ macros drm/i915: fix potential dangling else problems in for_each_ macros LABBE Corentin (1): drm: modes: replace simple_strtoul by kstrtouint Lukas Wunner (1): drm: Remove unused fbdev_list members Maarten Lankhorst (1): drm/atomic: Small documentation fix. Markus Elfring (1): GPU-DRM: Delete unnecessary checks before drm_property_unreference_blob() Robert Fekete (1): drm: Describe the Rotation property bits. Ville Syrjälä (4): drm: Pass the user drm_mode_fb_cmd2 as const to .fb_create() drm: Keep coordinates in the typical x, y, w, h order instead of x, y, h, w drm: Add "prefix" parameter to drm_rect_debug_print() drm: Print the src/dst/clip rectangles in error in drm_plane_helper Documentation/DocBook/gpu.tmpl | 48 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 +- drivers/gpu/drm/armada/armada_fb.c | 4 +- drivers/gpu/drm/armada/armada_fb.h | 2 +- drivers/gpu/drm/ast/ast_drv.h| 3 +- drivers/gpu/drm/ast/ast_fb.c | 2 +- drivers/gpu/drm/ast/ast_main.c | 4 +- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +- drivers/gpu/drm/bochs/bochs.h| 2 +- drivers/gpu/drm/bochs/bochs_fbdev.c | 2 +- drivers/gpu/drm/bochs/bochs_mm.c | 4 +- drivers/gpu/drm/cirrus/cirrus_drv.h | 3 +- drivers/gpu/drm/cirrus/cirrus_fbdev.c| 2 +- drivers/gpu/drm/cirrus/cirrus_main.c | 4 +- drivers/gpu/drm/drm_atomic.c | 11 +-- drivers/gpu/drm/drm_atomic_helper.c | 19 +++-- drivers/gpu/drm/drm_crtc.c | 4 +- drivers/gpu/drm/drm_crtc_helper.c| 2 +- drivers/gpu/drm/drm_fb_cma_helper.c | 4 +- drivers/gpu/drm/drm_gem.c| 35 - drivers/gpu/drm/drm_modes.c | 16 ++-- drivers/gpu/drm/drm_plane_helper.c | 4 + drivers/gpu/drm/drm_probe_helper.c | 46 ++-- drivers/gpu/drm/drm_rect.c | 7 +- drivers/gpu/drm/drm_sysfs.c | 54 +++--- drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_fb.h | 2 +- drivers/gpu/drm/gma500/framebuffer.c | 6 +- drivers/gpu/drm/i915/i915_drv.h | 12 +-- drivers/gpu/drm/i915/intel_display.c | 4 +- drivers/gpu/drm/i915/intel_drv.h | 2 - drivers/gpu/drm/i915/intel_dsi.h | 2 +- drivers/gpu/drm/i915/intel_runtime_pm.c | 4 +- drivers/gpu/drm/i915/intel_sprite.c | 8 +- drivers/gpu/drm/imx/Kconfig | 9 --- drivers/gpu/drm/imx/imx-drm-core.c | 12 +-- drivers/gpu/drm/mgag200/mgag200_drv.h| 2 +- drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +- drivers/gpu/drm/mgag200/mgag200_main.c | 4 +- drivers/gpu/drm/msm/msm_drv.h| 4 +- drivers/gpu/drm/msm/msm_fb.c | 4 +- drivers/gpu/drm/nouveau/nouveau_display.c| 4 +- drivers/gpu/drm/nouveau/nouveau_display.h| 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.h | 1 - drivers/gpu/drm/omapdrm/omap_drv.h | 6 +- drivers/gpu/drm/omapdrm/omap_fb.c| 4 +- drivers/gpu/drm/qxl/qxl_display.c| 4 +- drivers/gpu/drm/qxl/qxl_drv.h| 2 +- drivers/gpu/drm/qxl/qxl_fb.c | 3 +- drivers/gpu/drm/radeon/radeon_display.c | 4 +- d
Re: [Intel-gfx] [PATCH] drm/i915: Fix up -EIO ABI per igt/gem_eio
On Wed, Nov 25, 2015 at 05:52:57PM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 06:45:26PM +0100, Daniel Vetter wrote:
> > My apologies to Chris Wilson for being dense on this topic for
> > essentially for years.
> >
> > This patch doesn't do any big redesign of the overall reset flow, but
> > instead just applies changes where it's needed to obey gem_eio. We can
> > redesign later on, but for now I prefer to make the testcase happy
> > with some minimally invasive changes:
> >
> > - Ensure that set_domain_ioctl never returns -EIO. Tricky part there
> > is that we might race with the reset handler when doing the lockless
> > wait.
> >
> > - Make sure debugfs/i915_wedged is actually useful to reset a wedged
> > gpu - atm it bails out with -EAGAIN for a terminally wedged gpu.
> > That's because reset_in_progress actually includes that terminal
> > state, which is super-confusing (and most callers got this wrong).
> > Fix this by changing the semantics of reset_in_progress to do what
> > it says on the tin (and fixup all other callers).
> >
> > Also make sure that reset_in_progress is cleared when we reach the
> > terminal "wedged" state. Without this we kept returning -EAGAIN in
> > some places forever.
> >
> > - Second problem with debugfs/i915_wedge was that we never got out of
> > the terminal wedged state. Hence manually set the reset counter out
> > of that state before starting the hung gpu recovery.
> >
> > For safety also make sure that we are consintent with resetting the
> > gpu between i915_reset_and_wakeup and i915_handler_error by just
> > passing the boolean "wedged" around instead of trying to recompute
> > it wrongly. This isn't an issue for gem_eio with the debugfs fix,
> > but just general robustness of the code.
> >
> > - Finally make sure that when gpu reset is disabled through the module
> > paramter the kernel doesn't generate dmesg noise that would upset
> > our CI/piglit. Simplest solution for that was to lift the i915.reset
> > check up into i915_reset().
> >
> > With all these changes, plus the igt fixes I've posted, gem_eio is now
> > happy on many snb.
> >
> > v2: Don't upset lockdep with my set_domain_ioctl changes.
> >
> > Cc: Chris Wilson
> > Testcase: igt/gem_eio/*
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 4
> > drivers/gpu/drm/i915/i915_drv.c | 6 ++
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > drivers/gpu/drm/i915/i915_gem.c | 23 +++
> > drivers/gpu/drm/i915/i915_irq.c | 11 ++-
> > drivers/gpu/drm/i915/intel_uncore.c | 3 ---
> > 6 files changed, 32 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 411a9c68b4ee..c4006c09ef1b 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -4744,6 +4744,10 @@ i915_wedged_set(void *data, u64 val)
> > if (i915_reset_in_progress(&dev_priv->gpu_error))
> > return -EAGAIN;
> >
> > + /* Already wedged, force us out of this terminal state. */
> > + if (i915_terminally_wedged(&dev_priv->gpu_error))
> > + atomic_set(&dev_priv->gpu_error.reset_counter, 0);
>
> What?
At least with the current reset flow we won't get out of terminally
wedged. We could instead get out of the terminal state when we attempt
another gpu reset, but that kinda defeats the idea of wedge being
terminally. Hence why I placed this here.
> > +
> > intel_runtime_pm_get(dev_priv);
> >
> > i915_handle_error(dev, val,
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index ec1e877c4a36..1f5386bb78f4 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -909,6 +909,12 @@ int i915_reset(struct drm_device *dev)
> >
> > simulated = dev_priv->gpu_error.stop_rings != 0;
> >
> > + if (!i915.reset) {
> > + DRM_INFO("GPU reset disabled in module option, not
> > resetting\n");
> > + mutex_unlock(&dev->struct_mutex);
> > + return -ENODEV;
> > + }
> > +
> > ret = intel_gpu_reset(dev);
>
> Please don't break intel_gpu_reset() like that.
It's an equivalent transformation, the only thing that changed is that we
check i915.reset 2 function calls up in the callchain. What exactly is
broken?
> I think this patch missed the point entirely.
It gets gem_eio going, and I'm not sold on reworking the overall reset
flow. First fix up the ABI, then fix up any remaining issues with the
reset flow. Or what exactly do you mean?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_eio: Resilience against "hanging too fast"
On Wed, Nov 25, 2015 at 04:28:02PM +, Chris Wilson wrote: > On Wed, Nov 25, 2015 at 05:19:24PM +0100, Daniel Vetter wrote: > > Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu > > hang we need to be careful to not run into the "hanging too fast > > check": > > That's not how it works. It restores the GPU by triggering a manual > reset. Maybe in your tree, but here it goes through the full hang recovery. And the gem_eio default context _does_ get banned without this. Maybe it's a bug in the ban logic, but it didn't look like that. After all debugfs/i915_wedged is a hack for developers - by that time userspace has already either died or fallen back to sw rendering anyway. So I figured no point in fixing this in the kernel with special cases. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_eio: Disable reset for wait subtests
On Wed, Nov 25, 2015 at 04:34:13PM +, Chris Wilson wrote: > On Wed, Nov 25, 2015 at 04:29:01PM +, Chris Wilson wrote: > > On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote: > > > This testcase tries to validate -EIO behaviour by disabling gpu reset > > > support in the kernel. Except that the wait subtest forgot to do that, > > > and therefore gets a return value of 0 instead of the expected -EIO. > > > > > > > Wrong. It was intentionally not using reset=false. > > To be more precise, the reason here is that we are not wedging the GPU > but the expectation is that a wait upon a request that hangs reports the > hang. Since the wait on GPU activity is explicit in the ioctl, the > presumption is that the user actually cares about that activity and so > should be given greater information about how it completes (timeout, GPU > hung, or success). The only place we reprt hangs is in the reset_stats_ioctl. And fundamentally wait_ioctl can't do (right now) what you want, since if the reset recovery happens before userspace calls wait_ioctl then it will happily return 0 for success. So if you want this then we need: - a reason for userspace to want this - reorg all our reset handling and move (or well copy) the reset stats to every object I don't see the point in that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use intel_pipe_will_have_type() in ironlake_crtc_compute_clock()
On Wed, Nov 25, 2015 at 04:35:30PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > ironlake_crtc_compute_clock() gets called during atomic compute phase, > so we must check the future pipe type instead of the current type. > > Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index a5669a6613e8..26cafeea2845 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8988,7 +8988,7 @@ static int ironlake_crtc_compute_clock(struct > intel_crtc *crtc, > memset(&crtc_state->dpll_hw_state, 0, > sizeof(crtc_state->dpll_hw_state)); > > - is_lvds = intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS); > + is_lvds = intel_pipe_will_have_type(crtc_state, INTEL_OUTPUT_LVDS); > > WARN(!(HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)), >"Unexpected PCH type %d\n", INTEL_PCH_TYPE(dev)); > -- > 2.4.10 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://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 http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Allow PCH DPLL sharing regardles of DPLL_SDVO_HIGH_SPEED
On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
> forbidden to set it for LVDS/CRT as well. So let's move it out of the
> ironlake_compute_dpll() and just do it on demand in the pll enable hook.
> This allows the PLL to be shared in more cases when dealing with
> different output types.
Nowhere is it forbidden feels a bit weak ... what's the benefits? Do we
really care?
-Daniel
>
> Note that we must now call the pll enable hook regarless of the current
> pll state, so that DPLL_SDVO_HIGH_SPEED gets updated appropriately.
>
> FIXME: maybe better to add a separate hook for the "pll already enabled"
> case?
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 29 +
> 1 file changed, 21 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 26cafeea2845..ae58f1105458 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1908,6 +1908,8 @@ static void intel_enable_shared_dpll(struct intel_crtc
> *crtc)
> if (pll->active++) {
> WARN_ON(!pll->on);
> assert_shared_dpll_enabled(dev_priv, pll);
> + /* to update high speed IO clock state */
> + pll->enable(dev_priv, pll);
> return;
> }
> WARN_ON(pll->on);
> @@ -8942,11 +8944,6 @@ static uint32_t ironlake_compute_dpll(struct
> intel_crtc *intel_crtc,
> dpll |= (crtc_state->pixel_multiplier - 1)
> << PLL_REF_SDVO_HDMI_MULTIPLIER_SHIFT;
>
> - if (is_sdvo)
> - dpll |= DPLL_SDVO_HIGH_SPEED;
> - if (crtc_state->has_dp_encoder)
> - dpll |= DPLL_SDVO_HIGH_SPEED;
> -
> /* compute bitmask from p1 value */
> dpll |= (1 << (crtc_state->dpll.p1 - 1)) <<
> DPLL_FPA01_P1_POST_DIV_SHIFT;
> /* also FPA1 */
> @@ -13626,7 +13623,7 @@ static bool ibx_pch_dpll_get_hw_state(struct
> drm_i915_private *dev_priv,
> return false;
>
> val = I915_READ(PCH_DPLL(pll->id));
> - hw_state->dpll = val;
> + hw_state->dpll = val & ~DPLL_SDVO_HIGH_SPEED;
> hw_state->fp0 = I915_READ(PCH_FP0(pll->id));
> hw_state->fp1 = I915_READ(PCH_FP1(pll->id));
>
> @@ -13643,10 +13640,26 @@ static void ibx_pch_dpll_mode_set(struct
> drm_i915_private *dev_priv,
> static void ibx_pch_dpll_enable(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
> {
> + struct drm_device *dev = dev_priv->dev;
> + struct intel_crtc *crtc;
> + u32 dpll = pll->config.hw_state.dpll;
> +
> + /* Configure high speed IO clock as needed */
> + for_each_intel_crtc(dev, crtc) {
> + if (intel_crtc_to_shared_dpll(crtc) == pll &&
> + crtc->config->base.active &&
> + (crtc->config->has_dp_encoder ||
> + intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
> + intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))) {
> + dpll |= DPLL_SDVO_HIGH_SPEED;
> + break;
> + }
> + }
> +
> /* PCH refclock must be enabled first */
> ibx_assert_pch_refclk_enabled(dev_priv);
>
> - I915_WRITE(PCH_DPLL(pll->id), pll->config.hw_state.dpll);
> + I915_WRITE(PCH_DPLL(pll->id), dpll);
>
> /* Wait for the clocks to stabilize. */
> POSTING_READ(PCH_DPLL(pll->id));
> @@ -13657,7 +13670,7 @@ static void ibx_pch_dpll_enable(struct
> drm_i915_private *dev_priv,
>*
>* So write it again.
>*/
> - I915_WRITE(PCH_DPLL(pll->id), pll->config.hw_state.dpll);
> + I915_WRITE(PCH_DPLL(pll->id), dpll);
> POSTING_READ(PCH_DPLL(pll->id));
> udelay(200);
> }
> --
> 2.4.10
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle
On Wed, Nov 25, 2015 at 05:02:44PM +0200, Mika Kuoppala wrote:
> Nick Hoath writes:
>
> > Use the first retired request on a new context to unpin
> > the old context. This ensures that the hw context remains
> > bound until it has been written back to by the GPU.
> > Now that the context is pinned until later in the request/context
> > lifecycle, it no longer needs to be pinned from context_queue to
> > retire_requests.
> >
> > v2: Moved the new pin to cover GuC submission (Alex Dai)
> > Moved the new unpin to request_retire to fix coverage leak
> > v3: Added switch to default context if freeing a still pinned
> > context just in case the hw was actually still using it
> > v4: Unwrapped context unpin to allow calling without a request
> > v5: Only create a switch to idle context if the ring doesn't
> > already have a request pending on it (Alex Dai)
> > Rename unsaved to dirty to avoid double negatives (Dave Gordon)
> > Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
> > Split out per engine cleanup from context_free as it
> > was getting unwieldy
> > Corrected locking (Dave Gordon)
> >
> > Signed-off-by: Nick Hoath
> > Issue: VIZ-4277
> > Cc: Daniel Vetter
> > Cc: David Gordon
> > Cc: Chris Wilson
> > Cc: Alex Dai
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/i915_gem.c | 3 +
> > drivers/gpu/drm/i915/intel_lrc.c | 124
> > +++
> > drivers/gpu/drm/i915/intel_lrc.h | 1 +
> > 4 files changed, 105 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index d5cf30b..e82717a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -889,6 +889,7 @@ struct intel_context {
> > struct {
> > struct drm_i915_gem_object *state;
> > struct intel_ringbuffer *ringbuf;
> > + bool dirty;
> > int pin_count;
> > } engine[I915_NUM_RINGS];
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index e955499..3829bc1 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1354,6 +1354,9 @@ static void i915_gem_request_retire(struct
> > drm_i915_gem_request *request)
> > {
> > trace_i915_gem_request_retire(request);
> >
> > + if (i915.enable_execlists)
> > + intel_lr_context_complete_check(request);
> > +
> > /* We know the GPU must have read the request to have
> > * sent us the seqno + interrupt, so use the position
> > * of tail of the request to update the last known position
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 06180dc..03d5bca 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -566,9 +566,6 @@ static int execlists_context_queue(struct
> > drm_i915_gem_request *request)
> > struct drm_i915_gem_request *cursor;
> > int num_elements = 0;
> >
> > - if (request->ctx != ring->default_context)
> > - intel_lr_context_pin(request);
> > -
> > i915_gem_request_reference(request);
> >
> > spin_lock_irq(&ring->execlist_lock);
> > @@ -732,6 +729,13 @@ intel_logical_ring_advance_and_submit(struct
> > drm_i915_gem_request *request)
> > if (intel_ring_stopped(ring))
> > return;
> >
> > + if (request->ctx != ring->default_context) {
> > + if (!request->ctx->engine[ring->id].dirty) {
> > + intel_lr_context_pin(request);
> > + request->ctx->engine[ring->id].dirty = true;
> > + }
> > + }
> > +
> > if (dev_priv->guc.execbuf_client)
> > i915_guc_submit(dev_priv->guc.execbuf_client, request);
> > else
> > @@ -958,12 +962,6 @@ void intel_execlists_retire_requests(struct
> > intel_engine_cs *ring)
> > spin_unlock_irq(&ring->execlist_lock);
> >
> > list_for_each_entry_safe(req, tmp, &retired_list, execlist_link) {
> > - struct intel_context *ctx = req->ctx;
> > - struct drm_i915_gem_object *ctx_obj =
> > - ctx->engine[ring->id].state;
> > -
> > - if (ctx_obj && (ctx != ring->default_context))
> > - intel_lr_context_unpin(req);
> > list_del(&req->execlist_link);
> > i915_gem_request_unreference(req);
> > }
> > @@ -1058,21 +1056,39 @@ reset_pin_count:
> > return ret;
> > }
> >
> > -void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
> > +static void __intel_lr_context_unpin(struct intel_engine_cs *ring,
> > + struct intel_context *ctx)
> > {
> > - struct intel_engine_cs *ring = rq->ring;
> > - struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
> > - struct intel_ringbuffer *ringbuf = rq->ringbuf;
> > -
> > + struct drm_i915_gem_obj
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
> On Thu, 26 Nov 2015 08:57:30 +0100, > Zhang, Xiong Y wrote: > > > > > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new > > > > > component ops to get ELD and connection states. It was posted to > > > > > alsa-devel shortly ago just as a reference, but this should work well > > > > > in such a case, too. The test patches are found in test/hdmi-jack > > > > > branch of my sound git tree. > > > > > > Did you try this branch (merge onto intel-test-nightly)? > > > > > [Zhang, Xiong Y] Yes, this branch could fix my issue. > > OK, good to hear. But this isn't for 4.4 or backport, as it's more > radical changes. > > Could you check the patch below instead? This suppresses the notifier > handling during suspend. It's bad, but the hotplug should be still > handled via normal unsol event, so it should keep working, good enough > as a stop gap. > > > Takashi > > --- > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > index bdb6f226d006..f7c70e2ae65c 100644 > --- a/sound/pci/hda/patch_hdmi.c > +++ b/sound/pci/hda/patch_hdmi.c > @@ -33,6 +33,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int > port) > struct hda_codec *codec = audio_ptr; > int pin_nid = port + 0x04; > > - check_presence_and_report(codec, pin_nid); > + if (!atomic_read(&codec->core.in_pm) && > + !pm_runtime_suspended(hda_codec_dev(codec))) > + check_presence_and_report(codec, pin_nid); > } > > static int patch_generic_hdmi(struct hda_codec *codec) [Zhang, Xiong Y] this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend(). thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Clean up locks in GuC
On 25/11/2015 19:29, Dai, Yu wrote:
From: Alex Dai
When GuC Work Queue is full, driver will wait GuC for avaliable
available
space by delaying 1ms. The wait needs to be out of spinlockirq /
unlock. Otherwise, lockup happens because jiffies won't be updated
dur to irq is disabled. The unnecessary locks has been cleared.
duebeing have
dev->struct_mutex is used instead where needed.
Issue is found in igt/gem_close_race.
v2: Clean up wq_lock too
v1: Clean up host2guc lock as well
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_debugfs.c| 12 +--
drivers/gpu/drm/i915/i915_guc_submission.c | 32 +++---
drivers/gpu/drm/i915/intel_guc.h | 4
3 files changed, 13 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a728ff1..d6b7817 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2473,15 +2473,15 @@ static int i915_guc_info(struct seq_file *m, void *data)
if (!HAS_GUC_SCHED(dev_priv->dev))
return 0;
+ if (mutex_lock_interruptible(&dev->struct_mutex))
+ return 0;
+
/* Take a local copy of the GuC data, so we can dump it at leisure */
- spin_lock(&dev_priv->guc.host2guc_lock);
guc = dev_priv->guc;
- if (guc.execbuf_client) {
- spin_lock(&guc.execbuf_client->wq_lock);
+ if (guc.execbuf_client)
client = *guc.execbuf_client;
- spin_unlock(&guc.execbuf_client->wq_lock);
- }
- spin_unlock(&dev_priv->guc.host2guc_lock);
+
+ mutex_unlock(&dev->struct_mutex);
seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ed9f100..97996e5 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -86,7 +86,6 @@ static int host2guc_action(struct intel_guc *guc, u32 *data,
u32 len)
return -EINVAL;
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
- spin_lock(&dev_priv->guc.host2guc_lock);
dev_priv->guc.action_count += 1;
dev_priv->guc.action_cmd = data[0];
@@ -119,7 +118,6 @@ static int host2guc_action(struct intel_guc *guc, u32
*data, u32 len)
}
dev_priv->guc.action_status = status;
- spin_unlock(&dev_priv->guc.host2guc_lock);
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
return ret;
@@ -249,6 +247,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
}
kunmap_atomic(base);
+
Unnecessary whitespace churn
return ret;
}
@@ -292,16 +291,12 @@ static uint32_t select_doorbell_cacheline(struct
intel_guc *guc)
const uint32_t cacheline_size = cache_line_size();
uint32_t offset;
- spin_lock(&guc->host2guc_lock);
-
/* Doorbell uses a single cache line within a page */
offset = offset_in_page(guc->db_cacheline);
/* Moving to next cache line to reduce contention */
guc->db_cacheline += cacheline_size;
- spin_unlock(&guc->host2guc_lock);
-
DRM_DEBUG_DRIVER("selected doorbell cacheline 0x%x, next 0x%x, linesize
%u\n",
offset, guc->db_cacheline, cacheline_size);
@@ -322,13 +317,11 @@ static uint16_t assign_doorbell(struct intel_guc *guc,
uint32_t priority)
const uint16_t end = start + half;
uint16_t id;
- spin_lock(&guc->host2guc_lock);
id = find_next_zero_bit(guc->doorbell_bitmap, end, start);
if (id == end)
id = GUC_INVALID_DOORBELL_ID;
else
bitmap_set(guc->doorbell_bitmap, id, 1);
- spin_unlock(&guc->host2guc_lock);
DRM_DEBUG_DRIVER("assigned %s priority doorbell id 0x%x\n",
hi_pri ? "high" : "normal", id);
@@ -338,9 +331,7 @@ static uint16_t assign_doorbell(struct intel_guc *guc,
uint32_t priority)
static void release_doorbell(struct intel_guc *guc, uint16_t id)
{
- spin_lock(&guc->host2guc_lock);
bitmap_clear(guc->doorbell_bitmap, id, 1);
- spin_unlock(&guc->host2guc_lock);
}
/*
@@ -487,16 +478,13 @@ static int guc_get_workqueue_space(struct i915_guc_client
*gc, u32 *offset)
struct guc_process_desc *desc;
void *base;
u32 size = sizeof(struct guc_wq_item);
- int ret = 0, timeout_counter = 200;
+ int ret = -ETIMEDOUT, timeout_counter = 200;
base = kmap_atomic(i915_gem_object_get_page(gc->client_obj, 0));
desc = base + gc->proc_desc_offset;
while (timeout_counter-- > 0) {
- ret = wait_for_atomic(CIRC_SPACE(gc->wq_tail, de
Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle
On 26/11/2015 08:48, Daniel Vetter wrote:
On Wed, Nov 25, 2015 at 05:02:44PM +0200, Mika Kuoppala wrote:
Nick Hoath writes:
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
retire_requests.
v2: Moved the new pin to cover GuC submission (Alex Dai)
Moved the new unpin to request_retire to fix coverage leak
v3: Added switch to default context if freeing a still pinned
context just in case the hw was actually still using it
v4: Unwrapped context unpin to allow calling without a request
v5: Only create a switch to idle context if the ring doesn't
already have a request pending on it (Alex Dai)
Rename unsaved to dirty to avoid double negatives (Dave Gordon)
Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
Split out per engine cleanup from context_free as it
was getting unwieldy
Corrected locking (Dave Gordon)
Signed-off-by: Nick Hoath
Issue: VIZ-4277
Cc: Daniel Vetter
Cc: David Gordon
Cc: Chris Wilson
Cc: Alex Dai
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/intel_lrc.c | 124 +++
drivers/gpu/drm/i915/intel_lrc.h | 1 +
4 files changed, 105 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d5cf30b..e82717a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -889,6 +889,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ bool dirty;
int pin_count;
} engine[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e955499..3829bc1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1354,6 +1354,9 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
{
trace_i915_gem_request_retire(request);
+ if (i915.enable_execlists)
+ intel_lr_context_complete_check(request);
+
/* We know the GPU must have read the request to have
* sent us the seqno + interrupt, so use the position
* of tail of the request to update the last known position
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 06180dc..03d5bca 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -566,9 +566,6 @@ static int execlists_context_queue(struct
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
- if (request->ctx != ring->default_context)
- intel_lr_context_pin(request);
-
i915_gem_request_reference(request);
spin_lock_irq(&ring->execlist_lock);
@@ -732,6 +729,13 @@ intel_logical_ring_advance_and_submit(struct
drm_i915_gem_request *request)
if (intel_ring_stopped(ring))
return;
+ if (request->ctx != ring->default_context) {
+ if (!request->ctx->engine[ring->id].dirty) {
+ intel_lr_context_pin(request);
+ request->ctx->engine[ring->id].dirty = true;
+ }
+ }
+
if (dev_priv->guc.execbuf_client)
i915_guc_submit(dev_priv->guc.execbuf_client, request);
else
@@ -958,12 +962,6 @@ void intel_execlists_retire_requests(struct
intel_engine_cs *ring)
spin_unlock_irq(&ring->execlist_lock);
list_for_each_entry_safe(req, tmp, &retired_list, execlist_link) {
- struct intel_context *ctx = req->ctx;
- struct drm_i915_gem_object *ctx_obj =
- ctx->engine[ring->id].state;
-
- if (ctx_obj && (ctx != ring->default_context))
- intel_lr_context_unpin(req);
list_del(&req->execlist_link);
i915_gem_request_unreference(req);
}
@@ -1058,21 +1056,39 @@ reset_pin_count:
return ret;
}
-void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
+static void __intel_lr_context_unpin(struct intel_engine_cs *ring,
+ struct intel_context *ctx)
{
- struct intel_engine_cs *ring = rq->ring;
- struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
- struct intel_ringbuffer *ringbuf = rq->ringbuf;
-
+ struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
+ struct intel_ringbuffer *ringbuf = ctx->engine[ring->id].ringbuf;
if (ctx_obj) {
WARN_ON(!mutex_is_locked(&ring->dev->struct_mutex));
- if (--rq->ctx->engine[ring->
Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request
On Wed, Nov 25, 2015 at 12:17:08PM +, Chris Wilson wrote: > On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote: > > On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote: > > > On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote: > > > > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote: > > > > > Instead of querying the reset counter before every access to the ring, > > > > > query it the first time we touch the ring, and do a final compare when > > > > > submitting the request. For correctness, we need to then sanitize how > > > > > the reset_counter is incremented to prevent broken submission and > > > > > waiting across resets, in the process fixing the persistent -EIO we > > > > > still see today on failed waits. > > > > > > > > tbh that explanation went straight over my head. Questions: > > > > - Where do we wait again over a reset? With all the wakeups we should > > > > catch them properly. I guess this needs the detailed scenario to help > > > > me > > > > out, since I have dim memories that there is something wrong ;-) > > > > > > TDR. In the future (and in past speculative patches) we have proposed > > > keeping requests over a reset and requeuing them. That is a complication > > > to the simplification of bailing out from the wait. What I have in mind, > > > is the recovery code has to fix up the request list somehow, though that > > > will be fun. > > > > But even with requeueing the waiters need to bail out and restart the > > ioctl. So I don't see why requeueing of requests matter. > > But why should the waiter even wake up? It is not holding any locks, all > it is just waiting for the request to complete. It is only those holding > a lock required to reset that we need to kick. Because the request might not actually be completed when we do partial resets like with TDR. And then we'd have to undo this. > > And my question was about what exactly is broken when waiting over a > > reset? As long as we detect the reset and restart the ioctl we should pick > > up any kinds of state fixups the reset work has done and recover > > perfectly. Irrespective of whether the reset work has requeued some of the > > requests or not. > > But... The reset handler clears the requests, we cannot wait over a > reset. So waiting over a reset today is clearly a bug in the kernel. > > Only in the future do we contemplate situations where a request may > survive a reset. I think I phrased my question badly: What's broken with current waiters racing against resets? Currently the should all get woken and restart, and that seems to work. It does create some ioctl restart work when a reset happens, but I think that overhead is justified given that it allows us to have no knowledge of how exactly we reset hw and sw outside of reset functions. > > > > - What precisely is the effect for waiters? I only see moving the > > > > atomic_inc under the dev->struct_mutex, which shouldn't do a hole lot > > > > for anyone. Plus not returning -EAGAIN when reset_in_progress, which > > > > looks like it might result in missed wakeups and deadlocks with the > > > > reset work. > > > > > > At the moment, I can trivially wedge the machine. This patch fixes that. > > > The patch also ensures that we cannot raise unhandled errors from > > > wait-request (EIO/EAGAIN handling has to be explicitly added to the > > > caller). > > > > Hm, how/where do we wedge the machine, and how does the fix work? > > Being able to reset a previously wedged machine. Ok, I think I get that problem now, after looking at gem_eio work. echo 1 > i915_wedged seems to have been broken since years. I haven't ever noticed that since I generally just kick the machine and restart when that happens. > > > The wait-request interface still has the wait-seqno legacy of having to > > > acquire the reset_counter under the mutex before calling. That is quite > > > hairy and causes a major complication later where we want to amalgamate > > > waiters. > > > > Yeah, that's a sensible change. But since I don't yet understand where > > exactly the current logic results in a wedge gpu I can't convince myself > > that the new one is ok. > > > > > Re EAGAIN. No, it cannot result in missed wakeups since that is internal > > > to the wait_request function, nor can it result in new deadlocks with the > > > reset worker. > > > > Yeah I think today with just struct_mutex it's impossible. But if we have > > more locks the waiting thread could continue to grab more locks instead of > > bailing out straight. And then the reset handler would be somewhat screwed > > since it isn't guaranteed to make forward progress. > > So basically if you add a deadlock/livelock, it may deadlock/livelock. The two-phase reset logic is some kind of hand-rolled special lock which makes sure nothing bad happens. As long as it's really two-phase. Essentially reset_in_progress means "everyone get of locks and stay of locks". With some small s
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Thu, 26 Nov 2015 10:16:17 +0100, Zhang, Xiong Y wrote: > > > > On Thu, 26 Nov 2015 08:57:30 +0100, > > Zhang, Xiong Y wrote: > > > > > > > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new > > > > > > component ops to get ELD and connection states. It was posted to > > > > > > alsa-devel shortly ago just as a reference, but this should work > > > > > > well > > > > > > in such a case, too. The test patches are found in test/hdmi-jack > > > > > > branch of my sound git tree. > > > > > > > > Did you try this branch (merge onto intel-test-nightly)? > > > > > > > [Zhang, Xiong Y] Yes, this branch could fix my issue. > > > > OK, good to hear. But this isn't for 4.4 or backport, as it's more > > radical changes. > > > > Could you check the patch below instead? This suppresses the notifier > > handling during suspend. It's bad, but the hotplug should be still > > handled via normal unsol event, so it should keep working, good enough > > as a stop gap. > > > > > > Takashi > > > > --- > > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > > index bdb6f226d006..f7c70e2ae65c 100644 > > --- a/sound/pci/hda/patch_hdmi.c > > +++ b/sound/pci/hda/patch_hdmi.c > > @@ -33,6 +33,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int > > port) > > struct hda_codec *codec = audio_ptr; > > int pin_nid = port + 0x04; > > > > - check_presence_and_report(codec, pin_nid); > > + if (!atomic_read(&codec->core.in_pm) && > > + !pm_runtime_suspended(hda_codec_dev(codec))) > > + check_presence_and_report(codec, pin_nid); > > } > > > > static int patch_generic_hdmi(struct hda_codec *codec) > [Zhang, Xiong Y] this patch couldn't remove the error message. So audio > controller isn't in Runtime D3 after azx_suspend(). OK, then the problem isn't about the HD-audio driver but rather i915 driver. As already mentioned, i915 driver shouldn't issue eld_notify callback in the suspend code path. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects
On Wed, Nov 25, 2015 at 09:58:28AM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 10:17:49AM +0100, Daniel Vetter wrote:
> > On Tue, Nov 24, 2015 at 11:17:38PM +, Chris Wilson wrote:
> > > On Tue, Nov 24, 2015 at 06:15:47PM +0100, Daniel Vetter wrote:
> > > > On Mon, Nov 23, 2015 at 09:20:24AM +, Chris Wilson wrote:
> > > > > If the system has no available swap pages, we cannot make forward
> > > > > progress in the shrinker by releasing active pages, only by releasing
> > > > > purgeable pages which are immediately reaped. Take total_swap_pages
> > > > > into
> > > > > account when counting up available objects to be shrunk and
> > > > > subsequently
> > > > > shrinking them. By doing so, we avoid unbinding objects that cannot be
> > > > > shrunk and so wasting CPU cycles flushing those objects from the GPU
> > > > > to
> > > > > the system and then immediately back again (as they will more than
> > > > > likely be reused shortly after).
> > > > >
> > > > > Based on a patch by Akash Goel.
> > > > >
> > > > > Reported-by: Akash Goel
> > > > > Signed-off-by: Chris Wilson
> > > > > Cc: Akash Goel
> > > > > Cc: sourab.gu...@intel.com
> > > >
> > > > Cc: linux...@kvack.org should be done on this one, just in case they
> > > > have
> > > > ideas for proper interfaces for this. Which might be, given that Jerome
> > > > Glisse is working on swaput-to-vram and other fun stuff like that.
> > > >
> > > > Also, how does stuff like zswap (or whatever "compress my swap in
> > > > memory"
> > > > is called again) factor in here? Iirc Android very much does use that.
> > >
> > > It doesn't. We would need
> > >
> > > #include
> > >
> > > static bool swap_available(void)
> > > {
> > > return total_swap_pages || frontswap_enabled;
> > > }
> > >
> > > But if that then returns true for Android it seems the primary usecase
> > > is invalidated.
> >
> > Well swapping to frontswap should be ok. Trashing not so much, and if we
> > do that I suspect there's something really loopsided with memory usage
> > balancing going on ... Does the android workload have your "only shrink
> > inactive" patch already?
>
> I'll let Akash or Sourab comment, but the background to the patch was
> that they observed that under memory pressure a framebuffer was being
> unbound (obviously not pinned as a current scanout) and then rebound
> (clflushing both ways ofc). My gut says that the priority lists in the
> kernel and userspace are akilter if we either fail to purge the LRU
> object in the kernel or if userspace then doesn't try to reuse the MRU
> backbuffer. One thing I did notice when also dealing with memory
> pressure flushing backbuffers was (a) they were unaligned and so needed
> rebinding before pinning
> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=df636036d120c6227d1918cfd6d70232d8d37b4c
Not sure I read this correctly, but shouldn't we cache the alignment for
as long as the buffer isn't purged? Your patch resets when we unpin the
last display user. So in your scenario above that could result in an
unaligned rebinding for GT first, then aligned rebinding for display. I
figured the idea is to get things right for the render right away?
Only risk is that we might overalign things, but that only happens when
userspace reuses fbs and non-fbs in a mixed fashion. But that shouldn't be
a real problem I think.
> and (b) we didn't bump the scanout on the inactive list
> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=3a23ff3e5e201a52068d6e9d65f4ffb95077c21e
Yeah bumping the inactive list when we unpin from display definitely makes
sense. Of course it only plays well together with the userspace fb cache
if that is indeed MRU, and I think Android's isn't. It's all strictly fifo
buffer queues, both between kernel and surface flinger and between surface
flinger and clients.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/i915: Cache the reset_counter for the request
On Thu, Nov 26, 2015 at 10:21:38AM +0100, Daniel Vetter wrote: > On Wed, Nov 25, 2015 at 12:17:08PM +, Chris Wilson wrote: > > On Wed, Nov 25, 2015 at 10:12:53AM +0100, Daniel Vetter wrote: > > > On Tue, Nov 24, 2015 at 09:43:32PM +, Chris Wilson wrote: > > > > On Tue, Nov 24, 2015 at 05:43:22PM +0100, Daniel Vetter wrote: > > > > > On Fri, Nov 20, 2015 at 12:43:52PM +, Chris Wilson wrote: > > > > > > Instead of querying the reset counter before every access to the > > > > > > ring, > > > > > > query it the first time we touch the ring, and do a final compare > > > > > > when > > > > > > submitting the request. For correctness, we need to then sanitize > > > > > > how > > > > > > the reset_counter is incremented to prevent broken submission and > > > > > > waiting across resets, in the process fixing the persistent -EIO we > > > > > > still see today on failed waits. > > > > > > > > > > tbh that explanation went straight over my head. Questions: > > > > > - Where do we wait again over a reset? With all the wakeups we should > > > > > catch them properly. I guess this needs the detailed scenario to > > > > > help me > > > > > out, since I have dim memories that there is something wrong ;-) > > > > > > > > TDR. In the future (and in past speculative patches) we have proposed > > > > keeping requests over a reset and requeuing them. That is a complication > > > > to the simplification of bailing out from the wait. What I have in mind, > > > > is the recovery code has to fix up the request list somehow, though that > > > > will be fun. > > > > > > But even with requeueing the waiters need to bail out and restart the > > > ioctl. So I don't see why requeueing of requests matter. > > > > But why should the waiter even wake up? It is not holding any locks, all > > it is just waiting for the request to complete. It is only those holding > > a lock required to reset that we need to kick. > > Because the request might not actually be completed when we do partial > resets like with TDR. And then we'd have to undo this. I don't think you have to undo. TDR and wait_request already doesn't mesh well, so it needs to be solved either way. More than likely we simply don't increment the global reset counter and just bump the seqno for skipped requests. > > > And my question was about what exactly is broken when waiting over a > > > reset? As long as we detect the reset and restart the ioctl we should pick > > > up any kinds of state fixups the reset work has done and recover > > > perfectly. Irrespective of whether the reset work has requeued some of the > > > requests or not. > > > > But... The reset handler clears the requests, we cannot wait over a > > reset. So waiting over a reset today is clearly a bug in the kernel. > > > > Only in the future do we contemplate situations where a request may > > survive a reset. > > I think I phrased my question badly: What's broken with current waiters > racing against resets? Currently the should all get woken and restart, and > that seems to work. It does create some ioctl restart work when a reset > happens, but I think that overhead is justified given that it allows us to > have no knowledge of how exactly we reset hw and sw outside of reset > functions. Good. Because that doesn't change. > > > > > - What precisely is the effect for waiters? I only see moving the > > > > > atomic_inc under the dev->struct_mutex, which shouldn't do a hole > > > > > lot > > > > > for anyone. Plus not returning -EAGAIN when reset_in_progress, which > > > > > looks like it might result in missed wakeups and deadlocks with the > > > > > reset work. > > > > > > > > At the moment, I can trivially wedge the machine. This patch fixes that. > > > > The patch also ensures that we cannot raise unhandled errors from > > > > wait-request (EIO/EAGAIN handling has to be explicitly added to the > > > > caller). > > > > > > Hm, how/where do we wedge the machine, and how does the fix work? > > > > Being able to reset a previously wedged machine. > > Ok, I think I get that problem now, after looking at gem_eio work. > echo 1 > i915_wedged seems to have been broken since years. I haven't ever > noticed that since I generally just kick the machine and restart when that > happens. It has been my get-of-jail card for a long time: manually grab the GPU state and reset? Yes, please. > The two-phase reset logic is some kind of hand-rolled special lock which > makes sure nothing bad happens. As long as it's really two-phase. > Essentially reset_in_progress means "everyone get of locks and stay of > locks". With some small short-lived exceptions here and there (and well > not so short-lived ones). > > Of course we can just write reset code that doesn't deadlock, but given > our history in this area I much prefer something that's more obviously > correct. No. It is nothing more than a crude leaky hack to allow you call the ring accessors from inside the reset handler. > >
Re: [Intel-gfx] [PATCH] drm/i915: Move VMAs to inactive as request are retired
On Wed, Nov 25, 2015 at 10:16:37AM +, Tvrtko Ursulin wrote:
>
> On 24/11/15 17:47, Daniel Vetter wrote:
> >On Mon, Nov 23, 2015 at 03:12:35PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Current code moves _any_ VMA to the inactive list only when
> >>_all_ rendering on an object (so from any context or VM) has
> >>been completed.
> >>
> >>This creates an un-natural situation where the context (and
> >>VM) destructors can run with VMAs still on the respective
> >>active list.
> >>
> >>Change here is to move VMAs to the inactive list as the
> >>requests are getting retired.
> >>
> >>Signed-off-by: Tvrtko Ursulin
> >>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
> >>Testcase: igt/gem_request_retire/retire-vma-not-inactive
> >>Cc: Daniel Vetter
> >>Cc: Chris Wilson
> >>---
> >> drivers/gpu/drm/i915/i915_gem.c | 17 -
> >> 1 file changed, 16 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >>b/drivers/gpu/drm/i915/i915_gem.c
> >>index cd7e102720f4..47a743246d2c 100644
> >>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>@@ -2413,17 +2413,32 @@ static void
> >> i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring)
> >> {
> >>struct i915_vma *vma;
> >>+ struct i915_address_space *vm;
> >>
> >>RQ_BUG_ON(obj->last_read_req[ring] == NULL);
> >>RQ_BUG_ON(!(obj->active & (1 << ring)));
> >>
> >>list_del_init(&obj->ring_list[ring]);
> >>- i915_gem_request_assign(&obj->last_read_req[ring], NULL);
> >>
> >>if (obj->last_write_req && obj->last_write_req->ring->id == ring)
> >>i915_gem_object_retire__write(obj);
> >>
> >>obj->active &= ~(1 << ring);
> >>+
> >>+ if (obj->last_read_req[ring]->ctx->ppgtt)
> >>+ vm = &obj->last_read_req[ring]->ctx->ppgtt->base;
> >>+ else
> >>+ vm = &obj->last_read_req[ring]->i915->gtt.base;
> >>+
> >>+ list_for_each_entry(vma, &obj->vma_list, vma_link) {
> >>+ if (vma->vm == vm &&
> >>+ vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL &&
> >>+ !list_empty(&vma->mm_list))
> >>+ list_move_tail(&vma->mm_list, &vma->vm->inactive_list);
> >>+ }
> >
> >This is only a partial solution since with schedulers and semaphores and a
> >few depencies on a given object, but in different vm you can still end up
> >with an object that is idle in a vm, but slipped through here.
>
> Could you describe the exact scenario you had in mind? I won't pretend it
> this is simple code and I have it all figured out.
Well tbh I don't fully understand what exactly your code will do in all
corner-cases since there's a lot of ifs and special cases. But
fundamentally the problem is that an object can be active in a given vm
and there's no request pointing at the corresponding context in either
last_read_req or last_write_req. It works like this:
- ctx A uses obj 1
- ctx B uses obj 1 on the same engine
Your code above will miss to retire obj 1 on ctx 1's vm, so if you then
destroy ctx A you'll hit the nice warn above (presuming ctx B keeps obj 1
busy for all that time). So not even scheduler needed.
Fundamentally if you really want to accurately keep track of vma instaed
of obj activeness, then you need to have per-vma tracking of all of it,
i.e. all the last_*_req stuff.
Without that we essentially only keep track of an lru on each vm, and the
active/inactive split is totally bogus (well not quite, but since it
reflects obj->active there's not really any value, but it does create tons
of confusion).
To unconfuse this we'd need to have proper vma active tracking (not sure
whether that's worth it) or just merge the per-vm active/inactive lists
since they're really just one big list.
> >Also, checking for the view type is some strange layering. Why that?
>
> !ppgtt to skip potential other views I thought, no?
The vma lrus should be irrespective of ggtt vs. ppgtt or exactly what kind
of view it is. If we exclude special case everywhere the might pop up but
should the code will become unreadable (and the abstraction useless). What
do you fear could blow up without this check?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_eio: Disable reset for wait subtests
On Thu, Nov 26, 2015 at 09:36:14AM +0100, Daniel Vetter wrote: > On Wed, Nov 25, 2015 at 04:34:13PM +, Chris Wilson wrote: > > On Wed, Nov 25, 2015 at 04:29:01PM +, Chris Wilson wrote: > > > On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote: > > > > This testcase tries to validate -EIO behaviour by disabling gpu reset > > > > support in the kernel. Except that the wait subtest forgot to do that, > > > > and therefore gets a return value of 0 instead of the expected -EIO. > > > > > > > > > > Wrong. It was intentionally not using reset=false. > > > > To be more precise, the reason here is that we are not wedging the GPU > > but the expectation is that a wait upon a request that hangs reports the > > hang. Since the wait on GPU activity is explicit in the ioctl, the > > presumption is that the user actually cares about that activity and so > > should be given greater information about how it completes (timeout, GPU > > hung, or success). > > The only place we reprt hangs is in the reset_stats_ioctl. And > fundamentally wait_ioctl can't do (right now) what you want, since if the > reset recovery happens before userspace calls wait_ioctl then it will > happily return 0 for success. > > So if you want this then we need: > - a reason for userspace to want this > - reorg all our reset handling and move (or well copy) the reset stats to > every object I buy that if it resets before the wait_ioctl then it is invisible, which makes the information incomplete. I still think that as a caller of wait_ioctl, knowing that my wait was broken by a reset is valuable information. The drivers use some form of waiting to throttle themselves, therefore it is a convenient way of having the information that a reset has occurred and take action. This usecase also wouldn't miss a reset happening. You may disagree about wait_ioctl, but a wait_fence must definitely report EIO. (And this is as close to wait_fence as we currently have in the code and in use today.) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_eio: Resilience against "hanging too fast"
On Thu, Nov 26, 2015 at 09:34:01AM +0100, Daniel Vetter wrote: > On Wed, Nov 25, 2015 at 04:28:02PM +, Chris Wilson wrote: > > On Wed, Nov 25, 2015 at 05:19:24PM +0100, Daniel Vetter wrote: > > > Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu > > > hang we need to be careful to not run into the "hanging too fast > > > check": > > > > That's not how it works. It restores the GPU by triggering a manual > > reset. > > Maybe in your tree, but here it goes through the full hang recovery. Right. > And > the gem_eio default context _does_ get banned without this. Wrong. > Maybe it's a > bug in the ban logic, but it didn't look like that. Indeed, that is not where the *kernel* bug is. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] intel_dp_detect redesign
On Wed, Nov 25, 2015 at 05:09:02PM +0530, Thulasimani, Sivakumar wrote: > > > > On 11/25/2015 3:34 PM, Daniel Vetter wrote: > >On Tue, Nov 24, 2015 at 08:13:06PM +0100, Daniel Vetter wrote: > >>Hi Ander&Sivakumar, > >> > >>Dave&I had a short discussion about reprobing DP (and MST) state on > >>resume. I think this is something we've missed in our dp hpd handling > >>rework thus far. And at least for SST we need to take it into account > >>since it would be a regression. > >> > >>Currently it's done through ->detect callback from > >>drm_helper_hpd_irq_event called from i915_drm_resume. Also irc logs > >>below. > >Oh and there's an issue for the hdmi hpd changes that have been merged and > >reverted too: Those will run into the same problem. Plus in addition doing > >nothing in ->detect will break storm handling (since that falls back to > >the probe helper poll work). > >-Daniel > Storm handling is done in i915_hotplug_work_func before detection is called > so it should work on top of changes planned. our change is inside > intel_dp_detect > so any flow before this is called should remain intact. the expected flow > post > the changes will be > digport_work_func -> intel_dp_hpd_pulse > if (long pulse) > handle long pulse () > return IRQ_NONE > i915_hotplug_work_func -> detect > > however good to explicitly check for this, > following needs to be tested before sending in next patch/merge > 1) MST displays verification (Ander's reported on first set of patches) > 2) check behavior on sleep - resume (dave&danvet) > 3) storm handling needs to be handled as well. (i assume this should be > fine, > but good to check explicitly) (danvet) > Yeah the storm mitigation will keep on working. What I'm worried about is that polling won't work any more: When a storm happens we disable the hpd and switch all affected connectors completely to polling. Polling happens through the probe helpers in drm_probe_helper.c, and that code exclusively uses ->detect callbacks. Which means if we no longer re-probe in detect (since we assume hpd works correctly) then this will break the storm handling code. Simplest fix (but a bit a hack) would be to check whether polling is enabled at the top of intel_hdmi_detect and if so execute a full probe. And not just return the cached values. Note that storms are only a concern for HDMI, not DP (somehow DP hw is less shit). Cheers, Daniel > regards, > Sivakumar > >>Thanks, Daniel > >> > >> danvet: so probing on resume, it seems a bit inconsistent, > >>is the kernel driver meant to be doing it? > >> I think since we stopped vt switching we've stopped doing > >>it, which is making mst docking kinda suck > >> mst was after stopping vt-switching I thought > >> but yeah we should reprobe > >> and we do (at least occasionally if it's not broken again) > >> well people are just noticing it more with mst > >> but not for mst iirc > >> mst just restores and hopes I think > >> but when you suspend in the dock, and move the laptop, and > >>resume things don't work unless you xrandr > >> and vice-versa > >> I looked into it for 5 minutes when tedtso complained an ran ;-) > >> well reproving should bring up/tear down any mst > >> hm, xrandr shouldn't be enough to fix it, we need a real hpd > >>to redo the mst stuff I thought ... > >> so I don't think mst is special here > >> we reprobe through probe helpers > >> janesma, Pali, bleh sorry.. yeah, looks like it needs a > >>stdbool.h.. not sure why I didn't hit that compile error.. sorry about > >>that.. > >> all mst stuff is done directly from hpd since it needs to > >>know long vs. short > >> so it misses out > >> if we probe a DP port and the device is gone, MST will get torn > >>down > >> danvet: not so > >> unless someone else has been hacking the driver > >>* xxmitsu (~m...@5-15-26-95.residential.rdsnet.ro) has joined #dri-devel > >> oh, the completely gone case > >>* danvet looks > >> oh maybe we don't handle that properly > >> oh you might be right, I wonder where we should hook that in > >> drm_helper_hpd_irq_event in i915_drm_resume should get this > >>right for non-mst > >> well non-DP maybe, anderco and rtshiva are reworking this > >> but it's not merged yet > >> I'm guessing detect should not if a port was in mst > >> and is now disconnected > >> ok, skeleton is there but not all > >> intel_dp_detect > >> drm_dp_mst_topology_mgr_resume should probably check the > >>entire hierarchy, not just a simple dpcd write > >> and if anything changes, we need to generate the uevent somewhere > >> so might be better to re-run the entire dp_detect pile > >> tricky part is that we need to lie about long vs. short > >> it should be treated like a long hpd if anything changed, > >>short otherwise > >> well we have mgr->cbs->hotplug in the mst manager already > >> so should reuse that hook > >> airlied, I guess just fix up drm_dp_mst_topology_mgr_resume > >>to do rescan the entire hierarchy > >> calling ->hotplug if anything
Re: [Intel-gfx] [PATCH] drm/i915: Change context lifecycle
On Thu, Nov 26, 2015 at 09:19:44AM +, Nick Hoath wrote:
> On 26/11/2015 08:48, Daniel Vetter wrote:
> >On Wed, Nov 25, 2015 at 05:02:44PM +0200, Mika Kuoppala wrote:
> >>Nick Hoath writes:
> >>
> >>>Use the first retired request on a new context to unpin
> >>>the old context. This ensures that the hw context remains
> >>>bound until it has been written back to by the GPU.
> >>>Now that the context is pinned until later in the request/context
> >>>lifecycle, it no longer needs to be pinned from context_queue to
> >>>retire_requests.
> >>>
> >>>v2: Moved the new pin to cover GuC submission (Alex Dai)
> >>> Moved the new unpin to request_retire to fix coverage leak
> >>>v3: Added switch to default context if freeing a still pinned
> >>> context just in case the hw was actually still using it
> >>>v4: Unwrapped context unpin to allow calling without a request
> >>>v5: Only create a switch to idle context if the ring doesn't
> >>> already have a request pending on it (Alex Dai)
> >>> Rename unsaved to dirty to avoid double negatives (Dave Gordon)
> >>> Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
> >>> Split out per engine cleanup from context_free as it
> >>> was getting unwieldy
> >>> Corrected locking (Dave Gordon)
> >>>
> >>>Signed-off-by: Nick Hoath
> >>>Issue: VIZ-4277
> >>>Cc: Daniel Vetter
> >>>Cc: David Gordon
> >>>Cc: Chris Wilson
> >>>Cc: Alex Dai
> >>>---
> >>> drivers/gpu/drm/i915/i915_drv.h | 1 +
> >>> drivers/gpu/drm/i915/i915_gem.c | 3 +
> >>> drivers/gpu/drm/i915/intel_lrc.c | 124
> >>> +++
> >>> drivers/gpu/drm/i915/intel_lrc.h | 1 +
> >>> 4 files changed, 105 insertions(+), 24 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >>>b/drivers/gpu/drm/i915/i915_drv.h
> >>>index d5cf30b..e82717a 100644
> >>>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>>@@ -889,6 +889,7 @@ struct intel_context {
> >>> struct {
> >>> struct drm_i915_gem_object *state;
> >>> struct intel_ringbuffer *ringbuf;
> >>>+ bool dirty;
> >>> int pin_count;
> >>> } engine[I915_NUM_RINGS];
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >>>b/drivers/gpu/drm/i915/i915_gem.c
> >>>index e955499..3829bc1 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>@@ -1354,6 +1354,9 @@ static void i915_gem_request_retire(struct
> >>>drm_i915_gem_request *request)
> >>> {
> >>> trace_i915_gem_request_retire(request);
> >>>
> >>>+ if (i915.enable_execlists)
> >>>+ intel_lr_context_complete_check(request);
> >>>+
> >>> /* We know the GPU must have read the request to have
> >>>* sent us the seqno + interrupt, so use the position
> >>>* of tail of the request to update the last known position
> >>>diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >>>b/drivers/gpu/drm/i915/intel_lrc.c
> >>>index 06180dc..03d5bca 100644
> >>>--- a/drivers/gpu/drm/i915/intel_lrc.c
> >>>+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>>@@ -566,9 +566,6 @@ static int execlists_context_queue(struct
> >>>drm_i915_gem_request *request)
> >>> struct drm_i915_gem_request *cursor;
> >>> int num_elements = 0;
> >>>
> >>>- if (request->ctx != ring->default_context)
> >>>- intel_lr_context_pin(request);
> >>>-
> >>> i915_gem_request_reference(request);
> >>>
> >>> spin_lock_irq(&ring->execlist_lock);
> >>>@@ -732,6 +729,13 @@ intel_logical_ring_advance_and_submit(struct
> >>>drm_i915_gem_request *request)
> >>> if (intel_ring_stopped(ring))
> >>> return;
> >>>
> >>>+ if (request->ctx != ring->default_context) {
> >>>+ if (!request->ctx->engine[ring->id].dirty) {
> >>>+ intel_lr_context_pin(request);
> >>>+ request->ctx->engine[ring->id].dirty = true;
> >>>+ }
> >>>+ }
> >>>+
> >>> if (dev_priv->guc.execbuf_client)
> >>> i915_guc_submit(dev_priv->guc.execbuf_client, request);
> >>> else
> >>>@@ -958,12 +962,6 @@ void intel_execlists_retire_requests(struct
> >>>intel_engine_cs *ring)
> >>> spin_unlock_irq(&ring->execlist_lock);
> >>>
> >>> list_for_each_entry_safe(req, tmp, &retired_list, execlist_link) {
> >>>- struct intel_context *ctx = req->ctx;
> >>>- struct drm_i915_gem_object *ctx_obj =
> >>>- ctx->engine[ring->id].state;
> >>>-
> >>>- if (ctx_obj && (ctx != ring->default_context))
> >>>- intel_lr_context_unpin(req);
> >>> list_del(&req->execlist_link);
> >>> i915_gem_request_unreference(req);
> >>> }
> >>>@@ -1058,21 +1056,39 @@ reset_pin_count:
> >>> return ret;
> >>> }
> >>>
> >>>-void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
> >>>+static void __intel_lr_context_unpin(struct intel_engine_cs *ring,
> >>>+ struct intel_context *ctx)
> >>> {
> >>>- struct intel_e
Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldoc indent fails
On Wed, Nov 25, 2015 at 04:21:30PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
Aside: Build htmldocs results in a lot of complaints that many irq helpers
here aren't included ... we should fix that to make it more likely the
pretty kerneldoc gets noticed.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
> drivers/gpu/drm/i915/i915_irq.c| 20 ++--
> 2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index ed9f1002ab36..a057cbd78ecb 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -677,7 +677,7 @@ static struct drm_i915_gem_object
> *gem_allocate_guc_obj(struct drm_device *dev,
> /**
> * gem_release_guc_obj() - Release gem object allocated for GuC usage
> * @obj: gem obj to be released
> - */
> + */
> static void gem_release_guc_obj(struct drm_i915_gem_object *obj)
> {
> if (!obj)
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 13445655e6b8..70d443330919 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -288,11 +288,11 @@ static i915_reg_t gen6_pm_ier(struct drm_i915_private
> *dev_priv)
> }
>
> /**
> - * snb_update_pm_irq - update GEN6_PMIMR
> - * @dev_priv: driver private
> - * @interrupt_mask: mask of interrupt bits to update
> - * @enabled_irq_mask: mask of interrupt bits to enable
> - */
> + * snb_update_pm_irq - update GEN6_PMIMR
> + * @dev_priv: driver private
> + * @interrupt_mask: mask of interrupt bits to update
> + * @enabled_irq_mask: mask of interrupt bits to enable
> + */
> static void snb_update_pm_irq(struct drm_i915_private *dev_priv,
> uint32_t interrupt_mask,
> uint32_t enabled_irq_mask)
> @@ -406,11 +406,11 @@ void gen6_disable_rps_interrupts(struct drm_device *dev)
> }
>
> /**
> - * bdw_update_port_irq - update DE port interrupt
> - * @dev_priv: driver private
> - * @interrupt_mask: mask of interrupt bits to update
> - * @enabled_irq_mask: mask of interrupt bits to enable
> - */
> + * bdw_update_port_irq - update DE port interrupt
> + * @dev_priv: driver private
> + * @interrupt_mask: mask of interrupt bits to update
> + * @enabled_irq_mask: mask of interrupt bits to enable
> + */
> static void bdw_update_port_irq(struct drm_i915_private *dev_priv,
> uint32_t interrupt_mask,
> uint32_t enabled_irq_mask)
> --
> 2.4.10
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects
On Thu, Nov 26, 2015 at 10:34:51AM +0100, Daniel Vetter wrote: > On Wed, Nov 25, 2015 at 09:58:28AM +, Chris Wilson wrote: > > One thing I did notice when also dealing with memory > > pressure flushing backbuffers was (a) they were unaligned and so needed > > rebinding before pinning > > http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=df636036d120c6227d1918cfd6d70232d8d37b4c > > Not sure I read this correctly, but shouldn't we cache the alignment for > as long as the buffer isn't purged? Your patch resets when we unpin the > last display user. So in your scenario above that could result in an > unaligned rebinding for GT first, then aligned rebinding for display. I > figured the idea is to get things right for the render right away? It was focused on the solving the problem that scanout needed to realign the buffer. I felt that keeping the maximum alignment imposed by the user was just asking for trouble. (It's actually a bug in that patch that the alignment is reset there, it should be when framebuffer_references drops to zero. Also note that is depends upon the vma being persistent until closed.) > Only risk is that we might overalign things, but that only happens when > userspace reuses fbs and non-fbs in a mixed fashion. But that shouldn't be > a real problem I think. Probably not, just I don't trust them! The goal is keep the maximum restriction for only as long as it makes sense. We want relaxed fenced layout (because space is at a scarce resource on that hw), so always binding a tiled object at its max alignment is counter productive. framebuffers are typically only created for as long as required (give or take a small amount of caching, either in the flip-sequence or by a timer on idle). So keeping the fb's vma aligned seems a worthwhile tradeoff to avoid having to rebind it just as we want to present it to the screen. We have no time bounds on the user alignment, so that will seem to be always at odds with reducing the alignment for improved packing at the earliest opportunity. I'm pretty certain that fb alignment is the only restriction we wish to keep. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move VMAs to inactive as request are retired
On Mon, Nov 23, 2015 at 03:12:35PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Current code moves _any_ VMA to the inactive list only when
> _all_ rendering on an object (so from any context or VM) has
> been completed.
>
> This creates an un-natural situation where the context (and
> VM) destructors can run with VMAs still on the respective
> active list.
>
> Change here is to move VMAs to the inactive list as the
> requests are getting retired.
>
> Signed-off-by: Tvrtko Ursulin
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
> Testcase: igt/gem_request_retire/retire-vma-not-inactive
> Cc: Daniel Vetter
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index cd7e102720f4..47a743246d2c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2413,17 +2413,32 @@ static void
> i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring)
> {
> struct i915_vma *vma;
> + struct i915_address_space *vm;
>
> RQ_BUG_ON(obj->last_read_req[ring] == NULL);
> RQ_BUG_ON(!(obj->active & (1 << ring)));
>
> list_del_init(&obj->ring_list[ring]);
> - i915_gem_request_assign(&obj->last_read_req[ring], NULL);
>
> if (obj->last_write_req && obj->last_write_req->ring->id == ring)
> i915_gem_object_retire__write(obj);
>
> obj->active &= ~(1 << ring);
> +
> + if (obj->last_read_req[ring]->ctx->ppgtt)
> + vm = &obj->last_read_req[ring]->ctx->ppgtt->base;
> + else
> + vm = &obj->last_read_req[ring]->i915->gtt.base;
> +
> + list_for_each_entry(vma, &obj->vma_list, vma_link) {
> + if (vma->vm == vm &&
> + vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL &&
> + !list_empty(&vma->mm_list))
> + list_move_tail(&vma->mm_list, &vma->vm->inactive_list);
> + }
Also, please no. This is how you make synmark angry. If there aren't
enough igt tests to demonstrate that this can hurt badly, I need to add
some more.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/gem_eio: Disable reset for wait subtests
On Thu, Nov 26, 2015 at 10:03:01AM +, Chris Wilson wrote: > On Thu, Nov 26, 2015 at 09:36:14AM +0100, Daniel Vetter wrote: > > On Wed, Nov 25, 2015 at 04:34:13PM +, Chris Wilson wrote: > > > On Wed, Nov 25, 2015 at 04:29:01PM +, Chris Wilson wrote: > > > > On Wed, Nov 25, 2015 at 04:58:19PM +0100, Daniel Vetter wrote: > > > > > This testcase tries to validate -EIO behaviour by disabling gpu reset > > > > > support in the kernel. Except that the wait subtest forgot to do that, > > > > > and therefore gets a return value of 0 instead of the expected -EIO. > > > > > > > > > > > > > Wrong. It was intentionally not using reset=false. > > > > > > To be more precise, the reason here is that we are not wedging the GPU > > > but the expectation is that a wait upon a request that hangs reports the > > > hang. Since the wait on GPU activity is explicit in the ioctl, the > > > presumption is that the user actually cares about that activity and so > > > should be given greater information about how it completes (timeout, GPU > > > hung, or success). > > > > The only place we reprt hangs is in the reset_stats_ioctl. And > > fundamentally wait_ioctl can't do (right now) what you want, since if the > > reset recovery happens before userspace calls wait_ioctl then it will > > happily return 0 for success. > > > > So if you want this then we need: > > - a reason for userspace to want this > > - reorg all our reset handling and move (or well copy) the reset stats to > > every object > > I buy that if it resets before the wait_ioctl then it is invisible, > which makes the information incomplete. I still think that as a caller > of wait_ioctl, knowing that my wait was broken by a reset is valuable > information. The drivers use some form of waiting to throttle > themselves, therefore it is a convenient way of having the information > that a reset has occurred and take action. This usecase also wouldn't > miss a reset happening. Iirc we even discussed this when doing arb robustness, but the trouble is that arb robusteness really wants its reset stats per context. Until that changes (with fences or not) I think we should just curb the EIO from wait_ioctl like in all the other places. > You may disagree about wait_ioctl, but a wait_fence must definitely > report EIO. (And this is as close to wait_fence as we currently have in > the code and in use today.) Hm, the plan for fence waiting is to use the android syncpt stuff. I didn't check whether that bothers with reporting failures, but should be simple to add. And definitely makes sense. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix up -EIO ABI per igt/gem_eio
My apologies to Chris Wilson for being dense on this topic for
essentially for years.
This patch doesn't do any big redesign of the overall reset flow, but
instead just applies changes where it's needed to obey gem_eio. We can
redesign later on, but for now I prefer to make the testcase happy
with some minimally invasive changes:
- Ensure that set_domain_ioctl never returns -EIO. Tricky part there
is that we might race with the reset handler when doing the lockless
wait.
- Make sure debugfs/i915_wedged is actually useful to reset a wedged
gpu - atm it bails out with -EAGAIN for a terminally wedged gpu.
That's because reset_in_progress actually includes that terminal
state, which is super-confusing (and most callers got this wrong).
Fix this by changing the semantics of reset_in_progress to do what
it says on the tin (and fixup all other callers).
Also make sure that reset_in_progress is cleared when we reach the
terminal "wedged" state. Without this we kept returning -EAGAIN in
some places forever.
- Second problem with debugfs/i915_wedge was that we never got out of
the terminal wedged state. Hence manually set the reset counter out
of that state before starting the hung gpu recovery.
For safety also make sure that we are consintent with resetting the
gpu between i915_reset_and_wakeup and i915_handler_error by just
passing the boolean "wedged" around instead of trying to recompute
it wrongly. This isn't an issue for gem_eio with the debugfs fix,
but just general robustness of the code.
- Finally make sure that when gpu reset is disabled through the module
paramter the kernel doesn't generate dmesg noise that would upset
our CI/piglit. Simplest solution for that was to lift the i915.reset
check up into i915_reset().
With all these changes, plus the igt fixes I've posted, gem_eio is now
happy on many snb.
v2: Don't upset lockdep with my set_domain_ioctl changes.
Cc: Chris Wilson
Testcase: igt/gem_eio/*
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/i915_drv.c | 6 ++
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 23 +++
drivers/gpu/drm/i915/i915_irq.c | 11 ++-
drivers/gpu/drm/i915/intel_uncore.c | 3 ---
6 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 411a9c68b4ee..c4006c09ef1b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4744,6 +4744,10 @@ i915_wedged_set(void *data, u64 val)
if (i915_reset_in_progress(&dev_priv->gpu_error))
return -EAGAIN;
+ /* Already wedged, force us out of this terminal state. */
+ if (i915_terminally_wedged(&dev_priv->gpu_error))
+ atomic_set(&dev_priv->gpu_error.reset_counter, 0);
+
intel_runtime_pm_get(dev_priv);
i915_handle_error(dev, val,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ec1e877c4a36..1f5386bb78f4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -909,6 +909,12 @@ int i915_reset(struct drm_device *dev)
simulated = dev_priv->gpu_error.stop_rings != 0;
+ if (!i915.reset) {
+ DRM_INFO("GPU reset disabled in module option, not
resetting\n");
+ mutex_unlock(&dev->struct_mutex);
+ return -ENODEV;
+ }
+
ret = intel_gpu_reset(dev);
/* Also reset the gpu hangman. */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a47e0f4fab56..8876b4891d56 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2939,7 +2939,7 @@ int __must_check i915_gem_check_wedge(struct
i915_gpu_error *error,
static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
{
return unlikely(atomic_read(&error->reset_counter)
- & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
+ & I915_RESET_IN_PROGRESS_FLAG);
}
static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f10a5d57377e..64c63409b9d0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -85,8 +85,7 @@ i915_gem_wait_for_error(struct i915_gpu_error *error)
{
int ret;
-#define EXIT_COND (!i915_reset_in_progress(error) || \
- i915_terminally_wedged(error))
+#define EXIT_COND (!i915_reset_in_progress(error))
if (EXIT_COND)
return 0;
@@ -1113,16 +1112,16 @@ int
i915_gem_check_wedge(struct i915_gpu_error *error,
bool interruptible)
{
+ /* Recovery complete, but the reset failed ... */
+ if (i915_terminally_wedged(error))
+ return -EIO;
+
Re: [Intel-gfx] [PATCH i-g-t] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)
On Wed, Nov 25, 2015 at 10:08:21PM +0200, Imre Deak wrote:
> On ke, 2015-11-25 at 19:16 +0200, marius.c.v...@intel.com wrote:
> > From: Marius Vlad
> >
> > Signed-off-by: Marius Vlad
> > ---
> > tests/pm_rpm.c | 120
> > +
> > 1 file changed, 120 insertions(+)
> >
> > diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> > index c4fb19c..157cf29 100644
> > --- a/tests/pm_rpm.c
> > +++ b/tests/pm_rpm.c
> > @@ -1729,6 +1729,120 @@ static void planes_subtest(bool universal, bool
> > dpms)
> > }
> > }
> >
> > +static void pm_test_tiling(void)
> > +{
> > + uint32_t *handles;
> > + uint8_t **gem_bufs;
> > +
> > + int max_gem_objs = 0;
> > + uint8_t off_bit = 20;
> > + uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
> > +
> > + uint32_t i, j, tiling_modes[3] = {
> > + I915_TILING_NONE,
> > + I915_TILING_X,
> > + I915_TILING_Y,
> > + };
> > + uint32_t ti, sw;
> > +
> > + /* default value */
> > + uint32_t stride = 1024;
> > +
> > + /* calculate how many objects we can map */
> > + for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
> > + ;
>
> With these sizes we may end up with all objects properly aligned,
> that's why I suggested smaller objects. Based on I830_FENCE_START_MASK
> we could allocate for example starting from 16kB to 256kB.
>
Initially, I've tried with smaller sizes, but the assertion(s) failed.
I'll try as you suggested.
> > +
> > + gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
> > + handles = malloc(sizeof(uint32_t) * max_gem_objs);
>
> Nitpick: sizeof(*ptr) is safer and you could've used calloc in both
> cases.
Indeed.
>
> > +
> > + /* map to gtt and store some random data */
> > + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
> > + handles[i] = gem_create(drm_fd, j);
> > + gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
> > + memset(gem_bufs[i], 0x65, j);
> > + }
> > +
> > + /* try to set different tiling for each handle */
> > + for (i = 0; i < ARRAY_SIZE(tiling_modes); i++) {
> > + disable_all_screens_and_wait(&ms_data);
> > +
> > + for (j = 0; j < max_gem_objs; j++) {
> > + gem_set_tiling(drm_fd, handles[j], tiling_modes[i],
> > stride);
> > +
> > + gem_get_tiling(drm_fd, handles[j], &ti, &sw);
> > + igt_assert(tiling_modes[i] == ti);
> > + }
> > +
> > + enable_one_screen_and_wait(&ms_data);
>
> Ok, but after the second iteration all objects could be properly
> aligned, so it's better to close/realloc/memset the objects in each
> iteration.
Alright. I'll do that.
>
> > + }
> > +
> > + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
> > + igt_assert(munmap(gem_bufs[i], j) == 0);
> > + gem_close(drm_fd, handles[i]);
> > + }
> > +
> > + free(gem_bufs);
> > + free(handles);
> > +}
> > +
> > +static void pm_test_caching(void)
> > +{
> > + uint32_t *handles;
> > + uint8_t **gem_bufs;
> > + int8_t has_caching_display = -1;
> > +
> > + uint32_t i, j, got_caching;
> > + uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
> > + uint32_t cache_levels[3] = {
> > + I915_CACHING_NONE,
> > + I915_CACHING_CACHED,/* LLC caching */
> > + I915_CACHING_DISPLAY, /* eDRAM caching */
> > + };
> > +
> > + int max_gem_objs = 0;
> > + uint8_t off_bit = 20;
> > +
> > + for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
> > + ;
>
> No need to bother about alignment here, so we can just use a single
> 16kB object for example.
Alright.
>
> > +
> > + gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
> > + handles = malloc(sizeof(uint32_t) * max_gem_objs);
> > +
> > + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
> > + handles[i] = gem_create(drm_fd, j);
> > + gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
> > + memset(gem_bufs[i], 0x65, j);
> > + }
> > +
> > + /* figure out if we have cache display available on the platform */
> > + gem_set_caching(drm_fd, handles[0], I915_CACHING_DISPLAY);
> > + if (gem_get_caching(drm_fd, handles[0]))
>
> No need to hardcode I915_CACHING_NONE here. Also I liked the original
> version to check this everywhere better, by accepting both
> CACHING_DISPLAY and CACHING_NONE as a result.
I don't think I get it.
As far as I understand CACHING_DISPLAY will fall-back to CACHING_NONE if
the platform doesn't have support for it. Is there a proper way to check
for this?
igt_require()/igt_skip_on()/igt_require_f() can indeed be used to bypass
certain test(s), but there has to be a way to determine apriori if (indeed)
the platform supports CACHING_DISPLAY, before asserting the status.
Most likely this kind of issue has come up
Re: [Intel-gfx] [PATCH] drm/i915 : Avoid superfluous invalidation of CPU cache lines
On Thu, Nov 26, 2015 at 09:09:37AM +0530, Goel, Akash wrote:
>
>
> On 11/25/2015 10:58 PM, Chris Wilson wrote:
> >On Wed, Nov 25, 2015 at 01:02:20PM +0200, Ville Syrjälä wrote:
> >>On Tue, Nov 24, 2015 at 10:39:38PM +, Chris Wilson wrote:
> >>>On Tue, Nov 24, 2015 at 07:14:31PM +0100, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 12:04:06PM +0200, Ville Syrjälä wrote:
> >On Tue, Nov 24, 2015 at 03:35:24PM +0530, akash.g...@intel.com wrote:
> >>From: Akash Goel
> >>
> >>When the object is moved out of CPU read domain, the cachelines
> >>are not invalidated immediately. The invalidation is deferred till
> >>next time the object is brought back into CPU read domain.
> >>But the invalidation is done unconditionally, i.e. even for the case
> >>where the cachelines were flushed previously, when the object moved out
> >>of CPU write domain. This is avoidable and would lead to some
> >>optimization.
> >>Though this is not a hypothetical case, but is unlikely to occur often.
> >>The aim is to detect changes to the backing storage whilst the
> >>data is potentially in the CPU cache, and only clflush in those case.
> >>
> >>Signed-off-by: Chris Wilson
> >>Signed-off-by: Akash Goel
> >>---
> >> drivers/gpu/drm/i915/i915_drv.h | 1 +
> >> drivers/gpu/drm/i915/i915_gem.c | 9 -
> >> 2 files changed, 9 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index df9316f..fedb71d 100644
> >>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>@@ -2098,6 +2098,7 @@ struct drm_i915_gem_object {
> >>unsigned long gt_ro:1;
> >>unsigned int cache_level:3;
> >>unsigned int cache_dirty:1;
> >>+ unsigned int cache_clean:1;
> >
> >So now we have cache_dirty and cache_clean which seems redundant,
> >except somehow cache_dirty != !cache_clean?
> >>>
> >>>Exactly, not entirely redundant. I did think something along MESI lines
> >>>would be useful, but that didn't capture the different meanings we
> >>>employ.
> >>>
> >>>cache_dirty tracks whether we have been eliding the clflush.
> >>>
> >>>cache_clean tracks whether we know the cache has been completely
> >>>clflushed.
> >>
> >>Can we know that with speculative prefetching and whatnot?
> >
> >"The memory attribute of the page containing the affected line has no
> >effect on the behavior of this instruction. It should be noted that
> >processors are free to speculative fetch and cache data from system
> >memory regions assigned a memory-type allowing for speculative reads
> >(i.e. WB, WC, WT memory types). The Streaming SIMD Extensions PREFETCHh
> >instruction is considered a hint to this speculative behavior. Because
> >this speculative fetching can occur at any time and is not tied to
> >instruction execution, CLFLUSH is not ordered with respect to PREFETCHh
> >or any of the speculative fetching mechanisms (that is, data could be
> >speculative loaded into the cache just before, during, or after the
> >execution of a CLFLUSH to that cache line)."
> >
> >which taken to the extreme means that we can't get away with this trick.
> >
> >If we can at least guarantee that such speculation can't extend beyond
> >a page boundary that will be enough to assert that the patch is valid.
> >
> >Hopefully someone knows a CPU guru or two.
>
> Found some relevant info at the link https://lwn.net/Articles/255364/
>
> An excerpt from the same link
> Hardware Prefetching
> "Prefetching has one big weakness: it cannot cross page boundaries.
> The reason should be obvious when one realizes that the CPUs support
> demand paging. If the prefetcher were allowed to cross page
> boundaries, the access might trigger an OS event to make the page
> available. This by itself can be bad, especially for performance.
> What is worse is that the prefetcher does not know about the
> semantics of the program or the OS itself. It might therefore
> prefetch pages which, in real life, never would be requested. That
> means the prefetcher would run past the end of the memory region the
> processor accessed in a recognizable pattern before. This is not
> only possible, it is very likely. If the processor, as a side effect
> of a prefetch, triggered a request for such a page the OS might even
> be completely thrown off its tracks if such a request could never
> otherwise happen.
>
> It is therefore important to realize that, regardless of how good
> the prefetcher is at predicting the pattern, the program will
> experience cache misses at page boundaries unless it explicitly
> prefetches or reads from the new page. This is another reason to
> optimize the layout of data as described in Section 6.2 to minimize
> cache pollution by keeping unrelated data out.
>
> Because of this page limitation the processors do not have terribly
> sop
[Intel-gfx] [PATCH] drm/i915: Fix possible null dereference in framebuffer_info debugfs function
Found by static code analysis tool.
v2: Inserted block instead of goto & renamed variables (Chris)
Signed-off-by: Namrta Salonie
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/i915_debugfs.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a3b22bd..7c068ea 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1865,31 +1865,29 @@ static int i915_gem_framebuffer_info(struct seq_file
*m, void *data)
{
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
- struct intel_fbdev *ifbdev = NULL;
- struct intel_framebuffer *fb;
+ struct intel_framebuffer *fbdev_fb = NULL;
struct drm_framebuffer *drm_fb;
#ifdef CONFIG_DRM_FBDEV_EMULATION
- struct drm_i915_private *dev_priv = dev->dev_private;
- ifbdev = dev_priv->fbdev;
- fb = to_intel_framebuffer(ifbdev->helper.fb);
-
- seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, modifier 0x%llx,
refcount %d, obj ",
- fb->base.width,
- fb->base.height,
- fb->base.depth,
- fb->base.bits_per_pixel,
- fb->base.modifier[0],
- atomic_read(&fb->base.refcount.refcount));
- describe_obj(m, fb->obj);
- seq_putc(m, '\n');
+ if (to_i915(dev)->fbdev) {
+ fbdev_fb = to_intel_framebuffer(to_i915(dev)->fbdev->helper.fb);
+ seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, modifier
0x%llx, refcount %d, obj ",
+ fbdev_fb->base.width,
+ fbdev_fb->base.height,
+ fbdev_fb->base.depth,
+ fbdev_fb->base.bits_per_pixel,
+ fbdev_fb->base.modifier[0],
+ atomic_read(&fbdev_fb->base.refcount.refcount));
+ describe_obj(m, fbdev_fb->obj);
+ seq_putc(m, '\n');
+ }
#endif
mutex_lock(&dev->mode_config.fb_lock);
drm_for_each_fb(drm_fb, dev) {
- fb = to_intel_framebuffer(drm_fb);
- if (ifbdev && &fb->base == ifbdev->helper.fb)
+ struct intel_framebuffer *fb = to_intel_framebuffer(drm_fb);
+ if (fb == fbdev_fb)
continue;
seq_printf(m, "user size: %d x %d, depth %d, %d bpp, modifier
0x%llx, refcount %d, obj ",
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: more virtual south bridge detection
Commit "30c964a drm/i915: Detect virtual south bridge" detects and
handles the southbridge emulated by vmware esx. Add the ich9 south
bridge emulated by 'qemu -M q35'.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 760e0ce..a3c482e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -531,7 +531,8 @@ void intel_detect_pch(struct drm_device *dev)
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
WARN_ON(!IS_SKYLAKE(dev));
- } else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE) {
+ } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
+ (id == INTEL_PCH_QEMU_DEVICE_ID_TYPE)) {
dev_priv->pch_type = intel_virt_detect_pch(dev);
} else
continue;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95bb27d..463ab22 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2604,6 +2604,7 @@ struct drm_i915_cmd_table {
#define INTEL_PCH_SPT_DEVICE_ID_TYPE 0xA100
#define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
#define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
+#define INTEL_PCH_QEMU_DEVICE_ID_TYPE 0x2900 /* qemu q35 has 2918 */
#define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
#define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects
On Wed, Nov 25, 2015 at 03:46:35PM -0500, Johannes Weiner wrote:
> On Wed, Nov 25, 2015 at 08:31:02PM +, Chris Wilson wrote:
> > On Wed, Nov 25, 2015 at 02:06:10PM -0500, Johannes Weiner wrote:
> > > On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> > > > +static bool swap_available(void)
> > > > +{
> > > > + return total_swap_pages || frontswap_enabled;
> > > > +}
> > >
> > > If you use get_nr_swap_pages() instead of total_swap_pages, this will
> > > also stop scanning objects once the swap space is full. We do that in
> > > the VM to stop scanning anonymous pages.
> >
> > Thanks. Would EXPORT_SYMBOL_GPL(nr_swap_pages) (or equivalent) be
> > acceptable?
>
> No opposition from me. Just please add a small comment that this is
> for shrinkers with swappable objects.
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 58877312cf6b..1c7861f4c43c 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -48,6 +48,14 @@ static sector_t map_swap_entry(swp_entry_t, struct
block_device**);
DEFINE_SPINLOCK(swap_lock);
static unsigned int nr_swapfiles;
atomic_long_t nr_swap_pages;
+/*
+ * Some modules use swappable objects and may try to swap them out under
+ * memory pressure (via the shrinker). Before doing so, they may wish to
+ * check to see if any swap space is available. The shrinker also directly
+ * uses the available swap space to determine whether it can swapout
+ * anon pages in the same manner.
+ */
+EXPORT_SYMBOL_GPL(nr_swap_pages);
Something like that, after a couple more edits?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: Nuke fbc members from intel_crtc->atomic.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> This leaves intel_crtc->atomic empty, so zap it as well.
I made some comments on this patch already. I think those are still valid:
http://lists.freedesktop.org/archives/intel-gfx/2015-November/079829.html
Ander
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 87 ++-
> -
> drivers/gpu/drm/i915/intel_drv.h | 16 ---
> 2 files changed, 33 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 95501aba7d23..7f69f98d8b23 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4734,7 +4734,6 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> struct drm_atomic_state *old_state = old_crtc_state->base.state;
> - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc->base.state);
> struct drm_device *dev = crtc->base.dev;
> @@ -4750,15 +4749,15 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
> if (pipe_config->wm_changed && pipe_config->base.active)
> intel_update_watermarks(&crtc->base);
>
> - if (atomic->update_fbc)
> - intel_fbc_update(dev_priv);
> -
> if (old_pri_state) {
> struct intel_plane_state *primary_state =
> to_intel_plane_state(primary->state);
> struct intel_plane_state *old_primary_state =
> to_intel_plane_state(old_pri_state);
>
> + if (primary_state->visible)
> + intel_fbc_update(dev_priv);
> +
> if (primary_state->visible &&
> (needs_modeset(&pipe_config->base) ||
>!old_primary_state->visible))
> @@ -4767,8 +4766,6 @@ static void intel_post_plane_update(struct
> intel_crtc_state *old_crtc_state)
>
> if (needs_modeset(&pipe_config->base))
> intel_display_power_put(dev_priv, POWER_DOMAIN_MODESET);
> -
> - memset(atomic, 0, sizeof(*atomic));
> }
>
> static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state)
> @@ -4776,7 +4773,6 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
> struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc->base.state);
> struct drm_atomic_state *old_state = old_crtc_state->base.state;
> @@ -4785,9 +4781,6 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
> drm_atomic_get_existing_plane_state(old_state, primary);
> bool modeset = needs_modeset(&pipe_config->base);
>
> - if (atomic->disable_fbc)
> - intel_fbc_disable_crtc(crtc);
> -
> if (old_pri_state) {
> struct intel_plane_state *primary_state =
> to_intel_plane_state(primary->state);
> @@ -4795,8 +4788,27 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
> to_intel_plane_state(old_pri_state);
>
> if (old_primary_state->visible &&
> - (modeset || !primary_state->visible))
> + (modeset || !primary_state->visible)) {
> + intel_fbc_disable_crtc(crtc);
> +
> intel_pre_disable_primary(&crtc->base);
> + } else if (primary_state->visible &&
> + INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv)
> &&
> + dev_priv->fbc.crtc == crtc &&
> + primary_state->base.rotation != BIT(DRM_ROTATE_0)) {
> + /*
> + * FBC does not work on some platforms for rotated
> + * planes, so disable it when rotation is not 0 and
> + * update it when rotation is set back to 0.
> + *
> + * FIXME: This is redundant with the fbc update done
> in
> + * the primary plane enable function except that that
> + * one is done too late. We eventually need to unify
> + * this.
> + */
> +
> + intel_fbc_disable_crtc(crtc);
> + }
> }
>
> if (pipe_config->disable_cxsr) {
> @@ -11686,7 +11698,6 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> struct intel_crtc *intel_crtc = to_intel_crtc(c
Re: [Intel-gfx] [PATCH] drm/i915: Fix up -EIO ABI per igt/gem_eio
On Thu, Nov 26, 2015 at 11:51:09AM +0100, Daniel Vetter wrote:
> My apologies to Chris Wilson for being dense on this topic for
> essentially for years.
>
> This patch doesn't do any big redesign of the overall reset flow, but
> instead just applies changes where it's needed to obey gem_eio. We can
> redesign later on, but for now I prefer to make the testcase happy
> with some minimally invasive changes:
>
> - Ensure that set_domain_ioctl never returns -EIO. Tricky part there
> is that we might race with the reset handler when doing the lockless
> wait.
>
> - Make sure debugfs/i915_wedged is actually useful to reset a wedged
> gpu - atm it bails out with -EAGAIN for a terminally wedged gpu.
> That's because reset_in_progress actually includes that terminal
> state, which is super-confusing (and most callers got this wrong).
> Fix this by changing the semantics of reset_in_progress to do what
> it says on the tin (and fixup all other callers).
>
> Also make sure that reset_in_progress is cleared when we reach the
> terminal "wedged" state. Without this we kept returning -EAGAIN in
> some places forever.
>
> - Second problem with debugfs/i915_wedge was that we never got out of
> the terminal wedged state. Hence manually set the reset counter out
> of that state before starting the hung gpu recovery.
>
> For safety also make sure that we are consintent with resetting the
> gpu between i915_reset_and_wakeup and i915_handler_error by just
> passing the boolean "wedged" around instead of trying to recompute
> it wrongly. This isn't an issue for gem_eio with the debugfs fix,
> but just general robustness of the code.
>
> - Finally make sure that when gpu reset is disabled through the module
> paramter the kernel doesn't generate dmesg noise that would upset
> our CI/piglit. Simplest solution for that was to lift the i915.reset
> check up into i915_reset().
>
> With all these changes, plus the igt fixes I've posted, gem_eio is now
> happy on many snb.
>
> v2: Don't upset lockdep with my set_domain_ioctl changes.
Blergh, forgotten to update the commit message:
v3: Don't special case set_domain_ioctl, instead curb all -EIO at the
source in wait_request, like in Chris' patch. That means anyone waiting
for a request will not notice the -EIO and fall over due to that. We
definitely want that for modeset code.
> Cc: Chris Wilson
> Testcase: igt/gem_eio/*
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4
> drivers/gpu/drm/i915/i915_drv.c | 6 ++
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_gem.c | 23 +++
> drivers/gpu/drm/i915/i915_irq.c | 11 ++-
> drivers/gpu/drm/i915/intel_uncore.c | 3 ---
> 6 files changed, 28 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 411a9c68b4ee..c4006c09ef1b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4744,6 +4744,10 @@ i915_wedged_set(void *data, u64 val)
> if (i915_reset_in_progress(&dev_priv->gpu_error))
> return -EAGAIN;
>
> + /* Already wedged, force us out of this terminal state. */
> + if (i915_terminally_wedged(&dev_priv->gpu_error))
> + atomic_set(&dev_priv->gpu_error.reset_counter, 0);
> +
> intel_runtime_pm_get(dev_priv);
>
> i915_handle_error(dev, val,
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ec1e877c4a36..1f5386bb78f4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -909,6 +909,12 @@ int i915_reset(struct drm_device *dev)
>
> simulated = dev_priv->gpu_error.stop_rings != 0;
>
> + if (!i915.reset) {
> + DRM_INFO("GPU reset disabled in module option, not
> resetting\n");
> + mutex_unlock(&dev->struct_mutex);
> + return -ENODEV;
> + }
> +
> ret = intel_gpu_reset(dev);
>
> /* Also reset the gpu hangman. */
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a47e0f4fab56..8876b4891d56 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2939,7 +2939,7 @@ int __must_check i915_gem_check_wedge(struct
> i915_gpu_error *error,
> static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
> {
> return unlikely(atomic_read(&error->reset_counter)
> - & (I915_RESET_IN_PROGRESS_FLAG | I915_WEDGED));
> + & I915_RESET_IN_PROGRESS_FLAG);
> }
>
> static inline bool i915_terminally_wedged(struct i915_gpu_error *error)
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f10a5d57377e..64c63409b9d0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -85,8 +85,7 @@ i9
[Intel-gfx] [PATCH 2/2] tests/gem_eio: Resilience against "hanging too fast"
Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu
hang we need to be careful to not run into the "hanging too fast
check":
- don't restore the ban period, but instead keep it at 0.
- make sure we idle the gpu fully before hanging it again (wait
subtest missted that).
With this gem_eio works now reliable even when I don't run the
subtests individually.
Of course it's a bit fishy that the default ctx gets blamed for
essentially doing nothing, but until that's figured out in upstream
it's better to make the test work for now.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
tests/gem_eio.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index 8345d1a7a429..6c07d9175b95 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -84,13 +84,17 @@ static void trigger_reset(int fd)
static void wedge_gpu(int fd)
{
+ igt_hang_ring_t hang;
+
/* First idle the GPU then disable GPU resets before injecting a hang */
gem_quiescent_gpu(fd);
igt_require(i915_reset_control(false));
igt_debug("Wedging GPU by injecting hang\n");
- igt_post_hang_ring(fd, igt_hang_ring(fd, I915_EXEC_DEFAULT));
+ hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
+ hang.ban = 0;
+ igt_post_hang_ring(fd, hang);
igt_assert(i915_reset_control(true));
}
@@ -161,10 +165,14 @@ static void test_wait(int fd)
{
igt_hang_ring_t hang;
+ /* First idle the GPU then disable GPU resets before injecting a hang */
+ gem_quiescent_gpu(fd);
+
igt_require(i915_reset_control(false));
hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
igt_assert_eq(__gem_wait(fd, hang.handle, -1), 0);
+ hang.ban = 0;
igt_post_hang_ring(fd, hang);
igt_assert(i915_reset_control(true));
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] tests/gem_eio: New ABI - no EIO even from wait_ioctl
So there's 3 competing proposals for what wait_ioctl should do wrt
-EIO:
- return -EIO when the gpu is wedged. Not terribly useful for
userspace since it might race with a hang and then there's no
guarantee that a subsequent execbuf won't end up in an -EIO.
Terminally wedge really can only be reliably signalled at execbuf
time, and userspace needs to cope with that (or decide not to
bother).
- EIO for any obj that suffered from a reset. This means big internal
reorginazation in the kernel since currently we track reset stats
per-ctx and not on the obj. That's also what arb robustness wants.
We could do this, but this feels like new ABI territory with the
usual userspace requirements and high hurdles.
- No -EIO at all. Consistent with set_domain_ioctl and simplest to
implement. Which is what this patch does.
We can always opt to change this later on if there's a real need.
To make the test really exercise this do a full wedged gpu hang, to
make sure -EIO doesn't leak out at all.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
tests/gem_eio.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/gem_eio.c b/tests/gem_eio.c
index a24c8f1c53b5..8345d1a7a429 100644
--- a/tests/gem_eio.c
+++ b/tests/gem_eio.c
@@ -161,10 +161,14 @@ static void test_wait(int fd)
{
igt_hang_ring_t hang;
+ igt_require(i915_reset_control(false));
+
hang = igt_hang_ring(fd, I915_EXEC_DEFAULT);
- igt_assert_eq(__gem_wait(fd, hang.handle, -1), -EIO);
+ igt_assert_eq(__gem_wait(fd, hang.handle, -1), 0);
igt_post_hang_ring(fd, hang);
+ igt_assert(i915_reset_control(true));
+
trigger_reset(fd);
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable shrinker for non-swapped backed objects
On Thu, Nov 26, 2015 at 10:30:57AM +, Chris Wilson wrote: > On Thu, Nov 26, 2015 at 10:34:51AM +0100, Daniel Vetter wrote: > > On Wed, Nov 25, 2015 at 09:58:28AM +, Chris Wilson wrote: > > > One thing I did notice when also dealing with memory > > > pressure flushing backbuffers was (a) they were unaligned and so needed > > > rebinding before pinning > > > http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=df636036d120c6227d1918cfd6d70232d8d37b4c > > > > Not sure I read this correctly, but shouldn't we cache the alignment for > > as long as the buffer isn't purged? Your patch resets when we unpin the > > last display user. So in your scenario above that could result in an > > unaligned rebinding for GT first, then aligned rebinding for display. I > > figured the idea is to get things right for the render right away? > > It was focused on the solving the problem that scanout needed to realign > the buffer. I felt that keeping the maximum alignment imposed by the > user was just asking for trouble. (It's actually a bug in that patch > that the alignment is reset there, it should be when > framebuffer_references drops to zero. Also note that is depends upon the > vma being persistent until closed.) > > > Only risk is that we might overalign things, but that only happens when > > userspace reuses fbs and non-fbs in a mixed fashion. But that shouldn't be > > a real problem I think. > > Probably not, just I don't trust them! The goal is keep the maximum > restriction for only as long as it makes sense. We want relaxed fenced > layout (because space is at a scarce resource on that hw), so always > binding a tiled object at its max alignment is counter productive. > framebuffers are typically only created for as long as required (give or > take a small amount of caching, either in the flip-sequence or by a > timer on idle). So keeping the fb's vma aligned seems a worthwhile > tradeoff to avoid having to rebind it just as we want to present it to > the screen. We have no time bounds on the user alignment, so that will > seem to be always at odds with reducing the alignment for improved packing > at the earliest opportunity. > > I'm pretty certain that fb alignment is the only restriction we wish to > keep. Yeah, keeping fb alignment until fb_refs drops to 0 makes sense. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Allow PCH DPLL sharing regardles of DPLL_SDVO_HIGH_SPEED
On Thu, Nov 26, 2015 at 09:41:36AM +0100, Daniel Vetter wrote:
> On Wed, Nov 25, 2015 at 04:35:31PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > DPLL_SDVO_HIGH_SPEED must be set for SDVO/HDMI/DP, but nowhere is it
> > forbidden to set it for LVDS/CRT as well. So let's move it out of the
> > ironlake_compute_dpll() and just do it on demand in the pll enable hook.
> > This allows the PLL to be shared in more cases when dealing with
> > different output types.
>
> Nowhere is it forbidden feels a bit weak ... what's the benefits? Do we
> really care?
We get to share the PLL eg. between HDMI and VGA. We already do that
anyway if we clone HDMI+VGA. Othwerwise we always run out of PLLs when
trying to do three pipes with something like VGA+HDMI+DP.
> -Daniel
>
> >
> > Note that we must now call the pll enable hook regarless of the current
> > pll state, so that DPLL_SDVO_HIGH_SPEED gets updated appropriately.
> >
> > FIXME: maybe better to add a separate hook for the "pll already enabled"
> > case?
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 29 +
> > 1 file changed, 21 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 26cafeea2845..ae58f1105458 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -1908,6 +1908,8 @@ static void intel_enable_shared_dpll(struct
> > intel_crtc *crtc)
> > if (pll->active++) {
> > WARN_ON(!pll->on);
> > assert_shared_dpll_enabled(dev_priv, pll);
> > + /* to update high speed IO clock state */
> > + pll->enable(dev_priv, pll);
> > return;
> > }
> > WARN_ON(pll->on);
> > @@ -8942,11 +8944,6 @@ static uint32_t ironlake_compute_dpll(struct
> > intel_crtc *intel_crtc,
> > dpll |= (crtc_state->pixel_multiplier - 1)
> > << PLL_REF_SDVO_HDMI_MULTIPLIER_SHIFT;
> >
> > - if (is_sdvo)
> > - dpll |= DPLL_SDVO_HIGH_SPEED;
> > - if (crtc_state->has_dp_encoder)
> > - dpll |= DPLL_SDVO_HIGH_SPEED;
> > -
> > /* compute bitmask from p1 value */
> > dpll |= (1 << (crtc_state->dpll.p1 - 1)) <<
> > DPLL_FPA01_P1_POST_DIV_SHIFT;
> > /* also FPA1 */
> > @@ -13626,7 +13623,7 @@ static bool ibx_pch_dpll_get_hw_state(struct
> > drm_i915_private *dev_priv,
> > return false;
> >
> > val = I915_READ(PCH_DPLL(pll->id));
> > - hw_state->dpll = val;
> > + hw_state->dpll = val & ~DPLL_SDVO_HIGH_SPEED;
> > hw_state->fp0 = I915_READ(PCH_FP0(pll->id));
> > hw_state->fp1 = I915_READ(PCH_FP1(pll->id));
> >
> > @@ -13643,10 +13640,26 @@ static void ibx_pch_dpll_mode_set(struct
> > drm_i915_private *dev_priv,
> > static void ibx_pch_dpll_enable(struct drm_i915_private *dev_priv,
> > struct intel_shared_dpll *pll)
> > {
> > + struct drm_device *dev = dev_priv->dev;
> > + struct intel_crtc *crtc;
> > + u32 dpll = pll->config.hw_state.dpll;
> > +
> > + /* Configure high speed IO clock as needed */
> > + for_each_intel_crtc(dev, crtc) {
> > + if (intel_crtc_to_shared_dpll(crtc) == pll &&
> > + crtc->config->base.active &&
> > + (crtc->config->has_dp_encoder ||
> > +intel_pipe_has_type(crtc, INTEL_OUTPUT_SDVO) ||
> > +intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))) {
> > + dpll |= DPLL_SDVO_HIGH_SPEED;
> > + break;
> > + }
> > + }
> > +
> > /* PCH refclock must be enabled first */
> > ibx_assert_pch_refclk_enabled(dev_priv);
> >
> > - I915_WRITE(PCH_DPLL(pll->id), pll->config.hw_state.dpll);
> > + I915_WRITE(PCH_DPLL(pll->id), dpll);
> >
> > /* Wait for the clocks to stabilize. */
> > POSTING_READ(PCH_DPLL(pll->id));
> > @@ -13657,7 +13670,7 @@ static void ibx_pch_dpll_enable(struct
> > drm_i915_private *dev_priv,
> > *
> > * So write it again.
> > */
> > - I915_WRITE(PCH_DPLL(pll->id), pll->config.hw_state.dpll);
> > + I915_WRITE(PCH_DPLL(pll->id), dpll);
> > POSTING_READ(PCH_DPLL(pll->id));
> > udelay(200);
> > }
> > --
> > 2.4.10
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6] drm/i915: Change context lifecycle
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
retire_requests.
This fixes an issue with GuC submission where the GPU might not
have finished writing back the context before it is unpinned. This
results in a GPU hang.
v2: Moved the new pin to cover GuC submission (Alex Dai)
Moved the new unpin to request_retire to fix coverage leak
v3: Added switch to default context if freeing a still pinned
context just in case the hw was actually still using it
v4: Unwrapped context unpin to allow calling without a request
v5: Only create a switch to idle context if the ring doesn't
already have a request pending on it (Alex Dai)
Rename unsaved to dirty to avoid double negatives (Dave Gordon)
Changed _no_req postfix to __ prefix for consistency (Dave Gordon)
Split out per engine cleanup from context_free as it
was getting unwieldy
Corrected locking (Dave Gordon)
v6: Removed some bikeshedding (Mika Kuoppala)
Added explanation of the GuC hang that this fixes (Daniel Vetter)
Signed-off-by: Nick Hoath
Issue: VIZ-4277
Cc: Daniel Vetter
Cc: David Gordon
Cc: Chris Wilson
Cc: Alex Dai
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 3 +
drivers/gpu/drm/i915/intel_lrc.c | 122 +++
drivers/gpu/drm/i915/intel_lrc.h | 1 +
4 files changed, 104 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d5cf30b..e82717a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -889,6 +889,7 @@ struct intel_context {
struct {
struct drm_i915_gem_object *state;
struct intel_ringbuffer *ringbuf;
+ bool dirty;
int pin_count;
} engine[I915_NUM_RINGS];
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e955499..3829bc1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1354,6 +1354,9 @@ static void i915_gem_request_retire(struct
drm_i915_gem_request *request)
{
trace_i915_gem_request_retire(request);
+ if (i915.enable_execlists)
+ intel_lr_context_complete_check(request);
+
/* We know the GPU must have read the request to have
* sent us the seqno + interrupt, so use the position
* of tail of the request to update the last known position
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 06180dc..dbe64ff 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -566,9 +566,6 @@ static int execlists_context_queue(struct
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
- if (request->ctx != ring->default_context)
- intel_lr_context_pin(request);
-
i915_gem_request_reference(request);
spin_lock_irq(&ring->execlist_lock);
@@ -732,6 +729,13 @@ intel_logical_ring_advance_and_submit(struct
drm_i915_gem_request *request)
if (intel_ring_stopped(ring))
return;
+ if (request->ctx != ring->default_context) {
+ if (!request->ctx->engine[ring->id].dirty) {
+ intel_lr_context_pin(request);
+ request->ctx->engine[ring->id].dirty = true;
+ }
+ }
+
if (dev_priv->guc.execbuf_client)
i915_guc_submit(dev_priv->guc.execbuf_client, request);
else
@@ -958,12 +962,6 @@ void intel_execlists_retire_requests(struct
intel_engine_cs *ring)
spin_unlock_irq(&ring->execlist_lock);
list_for_each_entry_safe(req, tmp, &retired_list, execlist_link) {
- struct intel_context *ctx = req->ctx;
- struct drm_i915_gem_object *ctx_obj =
- ctx->engine[ring->id].state;
-
- if (ctx_obj && (ctx != ring->default_context))
- intel_lr_context_unpin(req);
list_del(&req->execlist_link);
i915_gem_request_unreference(req);
}
@@ -1058,21 +1056,39 @@ reset_pin_count:
return ret;
}
-void intel_lr_context_unpin(struct drm_i915_gem_request *rq)
+static void __intel_lr_context_unpin(struct intel_engine_cs *ring,
+ struct intel_context *ctx)
{
- struct intel_engine_cs *ring = rq->ring;
- struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
- struct intel_ringbuffer *ringbuf = rq->ringbuf;
-
+ struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
+ struct intel_ringbuffer *ringbuf = ctx->engine[ring-
Re: [Intel-gfx] [PATCH i-g-t] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)
On to, 2015-11-26 at 12:55 +0200, Marius Vlad wrote:
> On Wed, Nov 25, 2015 at 10:08:21PM +0200, Imre Deak wrote:
> > On ke, 2015-11-25 at 19:16 +0200, marius.c.v...@intel.com wrote:
> > > From: Marius Vlad
> > >
> > > Signed-off-by: Marius Vlad
> > > ---
> > > tests/pm_rpm.c | 120
> > > +
> > > 1 file changed, 120 insertions(+)
> > >
> > > diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> > > index c4fb19c..157cf29 100644
> > > --- a/tests/pm_rpm.c
> > > +++ b/tests/pm_rpm.c
> > > @@ -1729,6 +1729,120 @@ static void planes_subtest(bool
> > > universal, bool dpms)
> > > }
> > > }
> > >
> > > +static void pm_test_tiling(void)
> > > +{
> > > + uint32_t *handles;
> > > + uint8_t **gem_bufs;
> > > +
> > > + int max_gem_objs = 0;
> > > + uint8_t off_bit = 20;
> > > + uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
> > > +
> > > + uint32_t i, j, tiling_modes[3] = {
> > > + I915_TILING_NONE,
> > > + I915_TILING_X,
> > > + I915_TILING_Y,
> > > + };
> > > + uint32_t ti, sw;
> > > +
> > > + /* default value */
> > > + uint32_t stride = 1024;
> > > +
> > > + /* calculate how many objects we can map */
> > > + for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
> > > + ;
> >
> > With these sizes we may end up with all objects properly aligned,
> > that's why I suggested smaller objects. Based on
> > I830_FENCE_START_MASK
> > we could allocate for example starting from 16kB to 256kB.
> >
>
> Initially, I've tried with smaller sizes, but the assertion(s)
> failed.
> I'll try as you suggested.
Hm, there shouldn't be any asserts. The only practical restriction is
on the stride size which on new platforms should be a multiple of 128
or 512 bytes based on the tiling mode and power-of-two on GEN < 4.
> > > +
> > > + gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
> > > + handles = malloc(sizeof(uint32_t) * max_gem_objs);
> >
> > Nitpick: sizeof(*ptr) is safer and you could've used calloc in both
> > cases.
>
> Indeed.
>
> >
> > > +
> > > + /* map to gtt and store some random data */
> > > + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
> > > + handles[i] = gem_create(drm_fd, j);
> > > + gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
> > > + memset(gem_bufs[i], 0x65, j);
> > > + }
> > > +
> > > + /* try to set different tiling for each handle */
> > > + for (i = 0; i < ARRAY_SIZE(tiling_modes); i++) {
> > > + disable_all_screens_and_wait(&ms_data);
> > > +
> > > + for (j = 0; j < max_gem_objs; j++) {
> > > + gem_set_tiling(drm_fd, handles[j], tiling_modes[i],
> > > stride);
> > > +
> > > + gem_get_tiling(drm_fd, handles[j], &ti, &sw);
> > > + igt_assert(tiling_modes[i] == ti);
> > > + }
> > > +
> > > + enable_one_screen_and_wait(&ms_data);
> >
> > Ok, but after the second iteration all objects could be properly
> > aligned, so it's better to close/realloc/memset the objects in each
> > iteration.
>
> Alright. I'll do that.
>
> >
> > > + }
> > > +
> > > + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j
> > > <<= 1, i++) {
> > > + igt_assert(munmap(gem_bufs[i], j) == 0);
> > > + gem_close(drm_fd, handles[i]);
> > > + }
> > > +
> > > + free(gem_bufs);
> > > + free(handles);
> > > +}
> > > +
> > > +static void pm_test_caching(void)
> > > +{
> > > + uint32_t *handles;
> > > + uint8_t **gem_bufs;
> > > + int8_t has_caching_display = -1;
> > > +
> > > + uint32_t i, j, got_caching;
> > > + uint32_t gtt_obj_max_size = (16 * 1024 * 1024);
> > > + uint32_t cache_levels[3] = {
> > > + I915_CACHING_NONE,
> > > + I915_CACHING_CACHED,/* LLC
> > > caching */
> > > + I915_CACHING_DISPLAY, /* eDRAM
> > > caching */
> > > + };
> > > +
> > > + int max_gem_objs = 0;
> > > + uint8_t off_bit = 20;
> > > +
> > > + for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1,
> > > max_gem_objs++)
> > > + ;
> >
> > No need to bother about alignment here, so we can just use a single
> > 16kB object for example.
>
> Alright.
>
> >
> > > +
> > > + gem_bufs = calloc(max_gem_objs, sizeof(uint8_t *));
> > > + handles = malloc(sizeof(uint32_t) * max_gem_objs);
> > > +
> > > + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j
> > > <<= 1, i++) {
> > > + handles[i] = gem_create(drm_fd, j);
> > > + gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i],
> > > j, PROT_WRITE);
> > > + memset(gem_bufs[i], 0x65, j);
> > > + }
> > > +
> > > + /* figure out if we have cache display available on the
> > > platform */
> > > + gem_set_caching(drm_fd, handles[0],
> > > I915_CACHING_DISPLAY);
> > > + if (gem_get_caching(drm_fd, handles[0]))
> >
> > No need to hardcode I915_CACHING_NONE here. Also I liked the
> > original
> > version to check this everywhere better, by accepting both
> > CACHING_DISPLAY an
[Intel-gfx] [PATCH i-g-t v4] lib/igt_core: Add kmsg capture and dumping
Capture the output from /dev/kmsg during test execution independantly
of other concurrent watchers like Piglit test runner.
The captured output is analyzed and the whole output dumped if message
with priority LOG_WARNING or higher is emitted from any domain.
Also adding igt_capture to lib/tests which will fail subtests and
produce kmsg output which should be captured by the new code.
v4:
- Do not effect return value of test, just dump (Daniel)
v3:
- Use O_CLOEXEC and clarify hex decoding (Chris)
v2:
- Reopen/close the kmsg FD per each test (Chris)
- Better commit mesage (Daniel)
- Display failure due to kmsg only as FAIL (KMSG)
Cc: Thomas Wood
Cc: Chris Wilson
Cc: Damien Lespiau
Cc: Daniel Vetter
Acked-by: Daniel Vetter
Signed-off-by: Joonas Lahtinen
---
lib/igt_core.c | 129 +++--
lib/tests/.gitignore | 1 +
lib/tests/Makefile.sources | 2 +
lib/tests/igt_capture.c| 89 +++
4 files changed, 218 insertions(+), 3 deletions(-)
create mode 100644 lib/tests/igt_capture.c
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 84cf8d2..b1aa750 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
#ifdef __linux__
@@ -211,6 +212,8 @@
* "--help" command line option.
*/
+#define IGT_KMSG_DUMP_BUF_SIZE 4096
+
static unsigned int exit_handler_count;
const char *igt_interactive_debug;
@@ -248,6 +251,10 @@ enum {
static int igt_exitcode = IGT_EXIT_SUCCESS;
static const char *command_str;
+static int igt_kmsg_capture_fd = -1;
+static int igt_kmsg_check_fd = -1;
+static char* igt_kmsg_dump_buf = NULL;
+
static char* igt_log_domain_filter;
static struct {
char *entries[256];
@@ -313,6 +320,112 @@ static void _igt_log_buffer_dump(void)
pthread_mutex_unlock(&log_buffer_mutex);
}
+static void _igt_kmsg_reset(void)
+{
+ if (igt_kmsg_dump_buf == NULL)
+ igt_kmsg_dump_buf = malloc(IGT_KMSG_DUMP_BUF_SIZE);
+
+ if (igt_kmsg_dump_buf == NULL) {
+ igt_warn("Unable to allocate memory, "
+"can not dump kmsg.\n");
+ return;
+ }
+
+ if (igt_kmsg_capture_fd == -1)
+ igt_kmsg_capture_fd = open("/dev/kmsg",
+ O_RDONLY | O_NONBLOCK | O_CLOEXEC);
+
+ if (igt_kmsg_capture_fd == -1)
+ goto err_capture;
+
+ if (igt_kmsg_check_fd == -1)
+ igt_kmsg_check_fd = open("/dev/kmsg",
+O_RDONLY | O_NONBLOCK | O_CLOEXEC);
+
+ if (igt_kmsg_check_fd == -1)
+ goto err_check;
+
+ lseek(igt_kmsg_capture_fd, 0, SEEK_END);
+ lseek(igt_kmsg_check_fd, 0, SEEK_END);
+ return;
+
+err_check:
+ close(igt_kmsg_capture_fd);
+ igt_kmsg_capture_fd = -1;
+err_capture:
+ free(igt_kmsg_dump_buf);
+ igt_kmsg_dump_buf = NULL;
+ return;
+}
+
+static int _igt_kmsg_dump(bool print, int filter_priority)
+{
+ size_t nbytes;
+ int nlines;
+ int prefix;
+ int priority;
+ char *p;
+ int fd;
+
+ fd = print ? igt_kmsg_capture_fd : igt_kmsg_check_fd;
+ if (fd == -1)
+ return 0;
+
+ nlines = 0;
+ do {
+ errno = 0;
+ nbytes = read(fd, igt_kmsg_dump_buf, IGT_KMSG_DUMP_BUF_SIZE);
+
+ if (nbytes == -1)
+ continue;
+
+ sscanf(igt_kmsg_dump_buf, "%d;", &prefix);
+ priority = prefix & 0x7;
+
+ if (priority > filter_priority)
+ continue;
+
+ nlines++;
+
+ if (!print)
+ continue;
+
+ if (nlines == 1)
+ fprintf(stderr, " KMSG \n");
+
+ p = strchr(igt_kmsg_dump_buf, ';') + 1;
+ while (p - igt_kmsg_dump_buf < nbytes) {
+ int c = *p++;
+ /* Decode non-printable characters escaped in
+* hex form (\x0f). */
+ if (c == '\\') {
+ igt_assert(*p++ == 'x');
+ igt_assert(sscanf(p, "%x", &c) == 1);
+ p += 2;
+ }
+ fputc(c, stderr);
+ }
+ } while(errno == 0);
+
+ if (print && nlines)
+ fprintf(stderr, " END \n");
+
+ if (errno != EAGAIN)
+ fprintf(stderr, "Error: Incomplete kmsg!\n");
+
+ close(fd);
+
+ if (print) {
+ igt_kmsg_capture_fd = -1;
+ free(igt_kmsg_dump_buf);
+ igt_kmsg_dump_buf = NULL;
+ } else {
+ igt_kmsg_check_fd = -1;
+ }
+
+ return nlines;
+}
+
__attribute__((format(printf, 1, 2)))
static
Re: [Intel-gfx] [PATCH] drm/i915: Fix possible null dereference in framebuffer_info debugfs function
On Thu, Nov 26, 2015 at 04:32:30PM +0530, Namrta Salonie wrote:
> Found by static code analysis tool.
>
> v2: Inserted block instead of goto & renamed variables (Chris)
>
> Signed-off-by: Namrta Salonie
> Signed-off-by: Deepak S
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 32 +++-
> 1 file changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a3b22bd..7c068ea 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1865,31 +1865,29 @@ static int i915_gem_framebuffer_info(struct seq_file
> *m, void *data)
> {
> struct drm_info_node *node = m->private;
> struct drm_device *dev = node->minor->dev;
> - struct intel_fbdev *ifbdev = NULL;
> - struct intel_framebuffer *fb;
> + struct intel_framebuffer *fbdev_fb = NULL;
> struct drm_framebuffer *drm_fb;
>
> #ifdef CONFIG_DRM_FBDEV_EMULATION
> - struct drm_i915_private *dev_priv = dev->dev_private;
>
> - ifbdev = dev_priv->fbdev;
> - fb = to_intel_framebuffer(ifbdev->helper.fb);
> -
> - seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, modifier 0x%llx,
> refcount %d, obj ",
> -fb->base.width,
> -fb->base.height,
> -fb->base.depth,
> -fb->base.bits_per_pixel,
> -fb->base.modifier[0],
> -atomic_read(&fb->base.refcount.refcount));
> - describe_obj(m, fb->obj);
> - seq_putc(m, '\n');
> + if (to_i915(dev)->fbdev) {
> + fbdev_fb = to_intel_framebuffer(to_i915(dev)->fbdev->helper.fb);
> + seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, modifier
> 0x%llx, refcount %d, obj ",
> + fbdev_fb->base.width,
> + fbdev_fb->base.height,
> + fbdev_fb->base.depth,
> + fbdev_fb->base.bits_per_pixel,
> + fbdev_fb->base.modifier[0],
> + atomic_read(&fbdev_fb->base.refcount.refcount));
These should be aligned to the opening '('
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] tests/gem_eio: Resilience against "hanging too fast"
On Thu, Nov 26, 2015 at 12:34:35PM +0100, Daniel Vetter wrote: > Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu > hang we need to be careful to not run into the "hanging too fast > check": > > - don't restore the ban period, but instead keep it at 0. > - make sure we idle the gpu fully before hanging it again (wait > subtest missted that). > > With this gem_eio works now reliable even when I don't run the > subtests individually. > > Of course it's a bit fishy that the default ctx gets blamed for > essentially doing nothing, but until that's figured out in upstream > it's better to make the test work for now. This used to be reliable. And just disabling all banning in the kernel forever more is silly. During igt_post_hang_ring: 1. we wait upon the hanging batch - this returns when hangcheck fires 2. reset the ban period to normal - this takes mutex_lock_interruptible and so must wait for the reset handler to run before it can make the change, - ergo the hanging batch never triggers a ban for itself. - (a subsequent nonsimulated GPU hang may trigger the ban though) Nak. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Keep track of the cdclk as if all crtc's were active.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> On skylake when calculating plane visibility with the crtc in
> dpms off mode the real cdclk may be different from what it would be
> if the crtc was active. This may result in a WARN_ON(cdclk < crtc_clock)
> from skl_max_scale. The fix is to keep a atomic_cdclk that would be true
> if all crtc's were active.
>
> This is required to get the same calculations done correctly regardless
> of dpms mode.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 55 ---
> -
> drivers/gpu/drm/i915/intel_drv.h | 6
> 3 files changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3caecf896f17..f3ad72abeea7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1776,7 +1776,7 @@ struct drm_i915_private {
>
> unsigned int fsb_freq, mem_freq, is_ddr3;
> unsigned int skl_boot_cdclk;
> - unsigned int cdclk_freq, max_cdclk_freq;
> + unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
> unsigned int max_dotclk_freq;
> unsigned int hpll_freq;
> unsigned int czclk_freq;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7f69f98d8b23..b2bf92a3b701 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5312,6 +5312,7 @@ static void modeset_put_power_domains(struct
> drm_i915_private *dev_priv,
>
> static void modeset_update_crtc_power_domains(struct drm_atomic_state *state)
> {
> + struct intel_atomic_state *intel_state =
> to_intel_atomic_state(state);
> struct drm_device *dev = state->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> unsigned long put_domains[I915_MAX_PIPES] = {};
> @@ -5325,13 +5326,9 @@ static void modeset_update_crtc_power_domains(struct
> drm_atomic_state *state)
> modeset_get_crtc_power_domains(crtc);
> }
>
> - if (dev_priv->display.modeset_commit_cdclk) {
> - unsigned int cdclk = to_intel_atomic_state(state)->cdclk;
> -
> - if (cdclk != dev_priv->cdclk_freq &&
> - !WARN_ON(!state->allow_modeset))
> - dev_priv->display.modeset_commit_cdclk(state);
> - }
> + if (dev_priv->display.modeset_commit_cdclk &&
> + intel_state->dev_cdclk != dev_priv->cdclk_freq)
> + dev_priv->display.modeset_commit_cdclk(state);
>
> for (i = 0; i < I915_MAX_PIPES; i++)
> if (put_domains[i])
> @@ -6039,13 +6036,18 @@ static int valleyview_modeset_calc_cdclk(struct
> drm_atomic_state *state)
> struct drm_device *dev = state->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> int max_pixclk = intel_mode_max_pixclk(dev, state);
> + struct intel_atomic_state *intel_state =
> + to_intel_atomic_state(state);
>
> if (max_pixclk < 0)
> return max_pixclk;
>
> - to_intel_atomic_state(state)->cdclk =
> + intel_state->cdclk = intel_state->dev_cdclk =
> valleyview_calc_cdclk(dev_priv, max_pixclk);
>
> + if (!intel_state->active_crtcs)
> + intel_state->dev_cdclk = valleyview_calc_cdclk(dev_priv, 0);
> +
> return 0;
> }
>
> @@ -6054,13 +6056,18 @@ static int broxton_modeset_calc_cdclk(struct
> drm_atomic_state *state)
> struct drm_device *dev = state->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> int max_pixclk = intel_mode_max_pixclk(dev, state);
> + struct intel_atomic_state *intel_state =
> + to_intel_atomic_state(state);
>
> if (max_pixclk < 0)
> return max_pixclk;
>
> - to_intel_atomic_state(state)->cdclk =
> + intel_state->cdclk = intel_state->dev_cdclk =
> broxton_calc_cdclk(dev_priv, max_pixclk);
>
> + if (!intel_state->active_crtcs)
> + intel_state->dev_cdclk = broxton_calc_cdclk(dev_priv, 0);
> +
> return 0;
> }
>
> @@ -6103,8 +6110,10 @@ static void vlv_program_pfi_credits(struct
> drm_i915_private *dev_priv)
> static void valleyview_modeset_commit_cdclk(struct drm_atomic_state
> *old_state)
> {
> struct drm_device *dev = old_state->dev;
> - unsigned int req_cdclk = to_intel_atomic_state(old_state)->cdclk;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_atomic_state *old_intel_state =
> + to_intel_atomic_state(old_state);
> + unsigned req_cdclk = old_intel_state->dev_cdclk;
>
> /*
>* FIXME: We can end up here with all power domains off, yet
> @@ -9574,7 +9583,9 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv)
> static void broxton_modeset_commit_cdclk(struct drm_atomic_state *old_s
[Intel-gfx] [PATCH] drm/i915: Check the timeout passed to i915_wait_request
We have relied upon the sole caller (wait_ioctl) validating the timeout
argument. However, when waiting for multiple requests I forgot to ensure
that the timeout was still positive on the later requests. This is more
simply done inside __i915_wait_request.
Fixes regression introduced in
commit b47161858ba13c9c7e0132230d66e008dd55
Author: Chris Wilson
Date: Mon Apr 27 13:41:17 2015 +0100
drm/i915: Implement inter-engine read-read optimisations
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 73c2c48729ec..8c19a980f5e6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1210,8 +1210,16 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
if (i915_gem_request_completed(req, true))
return 0;
- timeout_expire = timeout ?
- jiffies + nsecs_to_jiffies_timeout((u64)*timeout) : 0;
+ timeout_expire = 0;
+ if (timeout) {
+ if (WARN_ON(*timeout < 0))
+ return -EINVAL;
+
+ if (*timeout == 0)
+ return -ETIME;
+
+ timeout_expire = jiffies + nsecs_to_jiffies_timeout(*timeout);
+ }
if (INTEL_INFO(dev_priv)->gen >= 6)
gen6_rps_boost(dev_priv, rps, req->emitted_jiffies);
--
2.6.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Keep track of the cdclk as if all crtc's were active.
On Thu, 2015-11-26 at 15:31 +0200, Ander Conselvan De Oliveira wrote:
> On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> > On skylake when calculating plane visibility with the crtc in
> > dpms off mode the real cdclk may be different from what it would be
> > if the crtc was active. This may result in a WARN_ON(cdclk < crtc_clock)
> > from skl_max_scale. The fix is to keep a atomic_cdclk that would be true
> > if all crtc's were active.
> >
> > This is required to get the same calculations done correctly regardless
> > of dpms mode.
> >
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > drivers/gpu/drm/i915/intel_display.c | 55 -
> > --
> > -
> > drivers/gpu/drm/i915/intel_drv.h | 6
> > 3 files changed, 44 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 3caecf896f17..f3ad72abeea7 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1776,7 +1776,7 @@ struct drm_i915_private {
> >
> > unsigned int fsb_freq, mem_freq, is_ddr3;
> > unsigned int skl_boot_cdclk;
> > - unsigned int cdclk_freq, max_cdclk_freq;
> > + unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
> > unsigned int max_dotclk_freq;
> > unsigned int hpll_freq;
> > unsigned int czclk_freq;
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7f69f98d8b23..b2bf92a3b701 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5312,6 +5312,7 @@ static void modeset_put_power_domains(struct
> > drm_i915_private *dev_priv,
> >
> > static void modeset_update_crtc_power_domains(struct drm_atomic_state
> > *state)
> > {
> > + struct intel_atomic_state *intel_state =
> > to_intel_atomic_state(state);
> > struct drm_device *dev = state->dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > unsigned long put_domains[I915_MAX_PIPES] = {};
> > @@ -5325,13 +5326,9 @@ static void modeset_update_crtc_power_domains(struct
> > drm_atomic_state *state)
> > modeset_get_crtc_power_domains(crtc);
> > }
> >
> > - if (dev_priv->display.modeset_commit_cdclk) {
> > - unsigned int cdclk = to_intel_atomic_state(state)->cdclk;
> > -
> > - if (cdclk != dev_priv->cdclk_freq &&
> > - !WARN_ON(!state->allow_modeset))
> > - dev_priv->display.modeset_commit_cdclk(state);
> > - }
> > + if (dev_priv->display.modeset_commit_cdclk &&
> > + intel_state->dev_cdclk != dev_priv->cdclk_freq)
> > + dev_priv->display.modeset_commit_cdclk(state);
> >
> > for (i = 0; i < I915_MAX_PIPES; i++)
> > if (put_domains[i])
> > @@ -6039,13 +6036,18 @@ static int valleyview_modeset_calc_cdclk(struct
> > drm_atomic_state *state)
> > struct drm_device *dev = state->dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > int max_pixclk = intel_mode_max_pixclk(dev, state);
> > + struct intel_atomic_state *intel_state =
> > + to_intel_atomic_state(state);
> >
> > if (max_pixclk < 0)
> > return max_pixclk;
> >
> > - to_intel_atomic_state(state)->cdclk =
> > + intel_state->cdclk = intel_state->dev_cdclk =
> > valleyview_calc_cdclk(dev_priv, max_pixclk);
> >
> > + if (!intel_state->active_crtcs)
> > + intel_state->dev_cdclk = valleyview_calc_cdclk(dev_priv,
> > 0);
> > +
> > return 0;
> > }
> >
> > @@ -6054,13 +6056,18 @@ static int broxton_modeset_calc_cdclk(struct
> > drm_atomic_state *state)
> > struct drm_device *dev = state->dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > int max_pixclk = intel_mode_max_pixclk(dev, state);
> > + struct intel_atomic_state *intel_state =
> > + to_intel_atomic_state(state);
> >
> > if (max_pixclk < 0)
> > return max_pixclk;
> >
> > - to_intel_atomic_state(state)->cdclk =
> > + intel_state->cdclk = intel_state->dev_cdclk =
> > broxton_calc_cdclk(dev_priv, max_pixclk);
> >
> > + if (!intel_state->active_crtcs)
> > + intel_state->dev_cdclk = broxton_calc_cdclk(dev_priv, 0);
> > +
> > return 0;
> > }
> >
> > @@ -6103,8 +6110,10 @@ static void vlv_program_pfi_credits(struct
> > drm_i915_private *dev_priv)
> > static void valleyview_modeset_commit_cdclk(struct drm_atomic_state
> > *old_state)
> > {
> > struct drm_device *dev = old_state->dev;
> > - unsigned int req_cdclk = to_intel_atomic_state(old_state)->cdclk;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > + struct intel_atomic_state *old_intel_state =
> > + to_intel_atomic_state(old_state);
> > + unsigned req_cdclk = old_intel_state->dev_cdclk;
> >
> > /*
> > * F
Re: [Intel-gfx] [PATCH v4 2/5] drm: Add private data field to trace control block
On Tue, Nov 24, 2015 at 6:46 AM, Dmitry V. Levin wrote:
> On Mon, Sep 07, 2015 at 08:23:57PM +0200, Patrik Jakobsson wrote:
>> On Mon, Sep 7, 2015 at 6:51 PM, Dmitry V. Levin wrote:
>> > On Mon, Aug 31, 2015 at 02:37:07PM +0200, Patrik Jakobsson wrote:
>> > [...]
>> >> Here's my take on it (I assume it needs some discussion):
>> >>
>> >> int
>> >> set_tcb_priv_data(struct tcb *tcp, void *priv_data)
>> >> {
>> >> /* A free callback is required before setting private data and
>> >> private
>> >>* data must be set back to NULL before being set again.
>> >>*/
>> >
>> > I think a single function initializing both _priv_data and _free_priv_data
>> > would suffice:
>> >
>> > int
>> > set_tcb_priv_data(struct tcb *tcp, void *priv_data,
>> > void (*free_priv_data)(void *))
>> > {
>> > if (tcp->_priv_data)
>> > return -1;
>> >
>> > tcp->_free_priv_data = free_priv_data;
>> > tcp->_priv_data = priv_data;
>> >
>> > return 0;
>> > }
>>
>> Sure, and since they always come in a pairs it might be even better. If it
>> turns
>> out we need it split up it is easily done later.
>
> The discussion seems to be stalled.
> Patrik, would you like to prepare a patch?
Hi Dmitry
I'll send you new patches this weekend. Thanks for reminding me.
-Patrik
>
>
> --
> ldv
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't compare has_drrs strictly in pipe config
On Wed, 25 Nov 2015, Daniel Vetter wrote:
> On Wed, Nov 25, 2015 at 03:26:47PM +0100, Takashi Iwai wrote:
>> The commit [cfb23ed622d0: drm/i915: Allow fuzzy matching in
>> pipe_config_compare, v2] relaxed the way to compare the pipe
>> configurations, but one new comparison sneaked in there: it added the
>> strict has_drrs value check. This causes a regression on many
>> machines, typically HP laptops with a docking port, where the kernel
>> spews warnings and eventually fails to set the mode properly like:
>> [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in has_drrs
>> (expected 1, found 0)
>> [ cut here ]
>> WARNING: CPU: 0 PID: 79 at drivers/gpu/drm/i915/intel_display.c:12700
>> intel_modeset_check_state+0x5aa/0x870 [i915]()
>> pipe state doesn't match!
>>
>>
>> This patch just removes the check again for fixing the regression.
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104041
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92456
>> Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=956397
>> Fixes: cfb23ed622d0 ('drm/i915: Allow fuzzy matching in pipe_config_compare,
>> v2')
>> Cc: # v4.3+
>> Reported-and-tested-by: Max Lin
>> Signed-off-by: Takashi Iwai
>
> Reviewed-by: Daniel Vetter
Pushed to drm-intel-fixes, thanks for the patch and review.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 71860f8680f9..12a2e9d1f633 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12460,7 +12460,6 @@ intel_pipe_config_compare(struct drm_device *dev,
>> if (INTEL_INFO(dev)->gen < 8) {
>> PIPE_CONF_CHECK_M_N(dp_m_n);
>>
>> -PIPE_CONF_CHECK_I(has_drrs);
>> if (current_config->has_drrs)
>> PIPE_CONF_CHECK_M_N(dp_m2_n2);
>> } else
>> --
>> 2.6.3
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't override output type for DDI HDMI
On Tue, 24 Nov 2015, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 03:08:17PM +0200, Ville Syrjälä wrote:
>> On Tue, Nov 24, 2015 at 01:44:46PM +0100, Daniel Vetter wrote:
>> > On Fri, Nov 20, 2015 at 12:18:41PM +0100, Takashi Iwai wrote:
>> > > On Thu, 19 Nov 2015 17:04:20 +0100,
>> > > Takashi Iwai wrote:
>> > > >
>> > > > On Thu, 19 Nov 2015 16:51:05 +0100,
>> > > > Daniel Vetter wrote:
>> > > > >
>> > > > > On Thu, Nov 19, 2015 at 12:09:56PM +0100, Takashi Iwai wrote:
>> > > > > > Currently a DDI port may register the DP hotplug handler even
>> > > > > > though
>> > > > > > it's used with HDMI, and the DP HPD handler overrides the encoder
>> > > > > > type forcibly to DP. This caused the inconsistency on a machine
>> > > > > > connected with a HDMI monitor; upon a hotplug event, the DDI port
>> > > > > > is
>> > > > > > suddenly switched to be handled as a DP although the same monitor
>> > > > > > is
>> > > > > > kept connected, and this leads to the erroneous blank output.
>> > > > > >
>> > > > > > This patch papers over the bug by excluding the previous HDMI
>> > > > > > encoder
>> > > > > > type from this override. This should be fixed more fundamentally,
>> > > > > > e.g. by moving the encoder type reset from the HPD or by having
>> > > > > > individual encoder objects for HDMI and DP. But since the bug has
>> > > > > > been present for a long time (3.17), it's better to have a
>> > > > > > quick-n-dirty fix for now, and keep working on a cleaner fix.
>> > > > > >
>> > > > > > Bugzilla: http://bugzilla.opensuse.org/show_bug.cgi?id=955190
>> > > > > > Fixes: 0e32b39ceed6 ('drm/i915: add DP 1.2 MST support (v0.7)')
>> > > > > > Cc: # v3.17+
>> > > > > > Signed-off-by: Takashi Iwai
>> > > > >
>> > > > > If you plug in a hmid screen (using a level-shifter adapter), then a
>> > > > > DP
>> > > > > screen, does still everything work?
>> > > >
>> > > > That was my slight concern, too, although it seems working as long as
>> > > > I tested several HSW machines. Maybe better to double-check.
>> > >
>> > > I checked again some machines, and they all seem working.
>> > >
>> > > Actually the encoder type is set again in each detection function
>> > > (intel_hdmi_detect(), intel_dp_detect()) no matter with or without my
>> > > workaround. The problem happens when a HPD is triggered only to DP
>> > > while the HDMI is kept on. Then intel_hdmi_detect() won't be called
>> > > so the wrongly overridden encoder type remains.
>> > >
>> > > Why the override is still needed in intel_dp_hpd_pulse() isn't clear
>> > > to me, but at least it influences on the port power domain handling.
>> > > And my change won't affect in this regard.
>> >
>> > My suspicion is that we need this to reset between
>> > INTEL_OUTPUT_DISPLAYPORT and INTEL_OUTPUT_DP_MST.
>>
>> INTEL_OUTPUT_DP_MST is the type for fake mst encoders, and those
>> don't have a .hpd_pulse() hook to begin with.
>
> Hm ... that would mean we only need this for the initial hotplug when we
> go _UNKOWN -> _DISPLAYPORT. Oh well, putting it into the state properly,
> derived from what userspace wants, should be the proper fix anyway. But
> for stable this is good enough.
Pushed to drm-intel-fixes, thanks for the patch and review.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/i915: Calculate visibility in check_plane correctly regardless of dpms.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> When the crtc is configured but not active we currently clip to (0,0)x(0,0).
> This results in differences in calculations depending on dpms setting.
Is this part of "and fix BAT!"?
> When the crtc is enabled but not active run check_plane as if it were on,
> but afterwards set plane_state->visible = false for the checks.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 4 ++--
> drivers/gpu/drm/i915/intel_display.c | 9 +++--
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index a5a336863109..e0b851a0004a 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -152,9 +152,9 @@ static int intel_plane_atomic_check(struct drm_plane
> *plane,
> intel_state->clip.x1 = 0;
> intel_state->clip.y1 = 0;
> intel_state->clip.x2 =
> - crtc_state->base.active ? crtc_state->pipe_src_w : 0;
> + crtc_state->base.enable ? crtc_state->pipe_src_w : 0;
> intel_state->clip.y2 =
> - crtc_state->base.active ? crtc_state->pipe_src_h : 0;
> + crtc_state->base.enable ? crtc_state->pipe_src_h : 0;
>
> if (state->fb && intel_rotation_90_or_270(state->rotation)) {
> if (!(state->fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b2bf92a3b701..9db322182b15 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11738,8 +11738,13 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> if (!was_crtc_enabled && WARN_ON(was_visible))
> was_visible = false;
>
> - if (!is_crtc_enabled && WARN_ON(visible))
> - visible = false;
> + /*
> + * During visibility is calculated as if the crtc was on,
s/During// ?
Ander
> + * but after scaler setup everything depends on it being off
> + * when the crtc isn't active.
> + */
> + if (!is_crtc_enabled)
> + to_intel_plane_state(plane_state)->visible = visible = false;
>
> if (!was_visible && !visible)
> return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT
For dual link panel scenarios there are new fileds added in the
VBT which indicate on which port the PWM cntrl and CABC ON/OFF
commands needs to be sent.
v2: Moving the comment to intel_dsi.h(Jani)
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Yetunde Adebisi
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_bios.c | 10 ++
drivers/gpu/drm/i915/intel_bios.h | 5 -
drivers/gpu/drm/i915/intel_dsi.h | 9 +
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index ce82f9c..2d4d7a0 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -793,6 +793,16 @@ parse_mipi(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
return;
}
+ /*
+* These fileds are introduced from the VBT version 197 onwards,
+* so making sure that these bits are set zero in the pervious
+* versions.
+*/
+ if (dev_priv->vbt.dsi.config->dual_link && bdb->version < 197) {
+ dev_priv->vbt.dsi.config->dl_cabc_port = 0;
+ dev_priv->vbt.dsi.config->pwm_bkl_ctrl = 0;
+ }
+
/* We have mandatory mipi config blocks. Initialize as generic panel */
dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 7ec8c9a..9283969 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -832,7 +832,10 @@ struct mipi_config {
u16 dual_link:2;
u16 lane_cnt:2;
u16 pixel_overlap:3;
- u16 rsvd3:9;
+ u16 rgb_flip:1;
+ u16 dl_cabc_port:2;
+ u16 pwm_bkl_ctrl:2;
+ u16 rsvd3:4;
u16 rsvd4;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index e6cb252..40fd75a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -74,6 +74,15 @@ struct intel_dsi {
u8 escape_clk_div;
u8 dual_link;
+
+ /*
+* Below field will inform us on which port the panel blk_cntrl
+* and CABC ON/OFF commands needs to be sent in case of dual link
+* panels
+*/
+ u8 bkl_dcs_ports;
+ u8 pwm_blk_ctrl;
+
u8 pixel_overlap;
u32 port_bits;
u32 bw_timer;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: CABC support for backlight control
In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.
The CABC is not standardized and panel vendors are free to follow
their implementation. The CABC implementaion here assumes that the
panels use standard SW register for control.
In this design there will be no PWM signal from the SoC and DCS
commands are sent to enable and control the backlight brightness.
v2: Moving the CABC bkl functions to new file.(Jani)
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Yetunde Adebisi
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_dsi.c | 17 +++-
drivers/gpu/drm/i915/intel_dsi.h | 4 +
drivers/gpu/drm/i915/intel_dsi_cabc.c | 179 ++
drivers/gpu/drm/i915/intel_panel.c| 4 +
6 files changed, 205 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_dsi_cabc.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0851de07..2c69ed4 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -82,6 +82,7 @@ i915-y += dvo_ch7017.o \
intel_dp.o \
intel_dsi.o \
intel_dsi_panel_vbt.o \
+ intel_dsi_cabc.o \
intel_dsi_pll.o \
intel_dvo.o \
intel_hdmi.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 71bd1dc..5febde4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3392,7 +3392,7 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
u16 reg, u32 value,
enum intel_sbi_destination destination);
u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
-
+int intel_dsi_cabc_init_backlight_funcs(struct intel_connector
*intel_connector);
int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 170ae6f..f40b08f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1175,8 +1175,23 @@ void intel_dsi_init(struct drm_device *dev)
intel_dsi->ports = (1 << PORT_C);
}
- if (dev_priv->vbt.dsi.config->dual_link)
+ if (dev_priv->vbt.dsi.config->dual_link) {
intel_dsi->ports = ((1 << PORT_A) | (1 << PORT_C));
+ switch (dev_priv->vbt.dsi.config->dl_cabc_port) {
+ case CABC_PORT_A:
+ intel_dsi->bkl_dcs_ports = (1 << PORT_A);
+ break;
+ case CABC_PORT_C:
+ intel_dsi->bkl_dcs_ports = (1 << PORT_C);
+ break;
+ case CABC_PORT_A_AND_C:
+ intel_dsi->bkl_dcs_ports = intel_dsi->ports;
+ break;
+ default:
+ DRM_ERROR("Unknown MIPI ports for sending DCS\n");
+ }
+ } else
+ intel_dsi->bkl_dcs_ports = intel_dsi->ports;
/* Create a DSI host (and a device) for each port. */
for_each_dsi_port(port, intel_dsi->ports) {
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 40fd75a..0de2b4a 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -34,6 +34,10 @@
#define DSI_DUAL_LINK_FRONT_BACK 1
#define DSI_DUAL_LINK_PIXEL_ALT2
+#define CABC_PORT_A 0x00
+#define CABC_PORT_C 0x01
+#define CABC_PORT_A_AND_C 0x02
+
struct intel_dsi_host;
struct intel_dsi {
diff --git a/drivers/gpu/drm/i915/intel_dsi_cabc.c
b/drivers/gpu/drm/i915/intel_dsi_cabc.c
new file mode 100644
index 000..d14a669
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi_cabc.c
@@ -0,0 +1,179 @@
+/*
+ * Copyright © 2006-2010 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,
+ * F
Re: [Intel-gfx] [PATCH] drm/i915: Move VMAs to inactive as request are retired
On 26/11/15 10:01, Daniel Vetter wrote:
On Wed, Nov 25, 2015 at 10:16:37AM +, Tvrtko Ursulin wrote:
On 24/11/15 17:47, Daniel Vetter wrote:
On Mon, Nov 23, 2015 at 03:12:35PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Current code moves _any_ VMA to the inactive list only when
_all_ rendering on an object (so from any context or VM) has
been completed.
This creates an un-natural situation where the context (and
VM) destructors can run with VMAs still on the respective
active list.
Change here is to move VMAs to the inactive list as the
requests are getting retired.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
Testcase: igt/gem_request_retire/retire-vma-not-inactive
Cc: Daniel Vetter
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cd7e102720f4..47a743246d2c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2413,17 +2413,32 @@ static void
i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring)
{
struct i915_vma *vma;
+ struct i915_address_space *vm;
RQ_BUG_ON(obj->last_read_req[ring] == NULL);
RQ_BUG_ON(!(obj->active & (1 << ring)));
list_del_init(&obj->ring_list[ring]);
- i915_gem_request_assign(&obj->last_read_req[ring], NULL);
if (obj->last_write_req && obj->last_write_req->ring->id == ring)
i915_gem_object_retire__write(obj);
obj->active &= ~(1 << ring);
+
+ if (obj->last_read_req[ring]->ctx->ppgtt)
+ vm = &obj->last_read_req[ring]->ctx->ppgtt->base;
+ else
+ vm = &obj->last_read_req[ring]->i915->gtt.base;
+
+ list_for_each_entry(vma, &obj->vma_list, vma_link) {
+ if (vma->vm == vm &&
+ vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL &&
+ !list_empty(&vma->mm_list))
+ list_move_tail(&vma->mm_list, &vma->vm->inactive_list);
+ }
This is only a partial solution since with schedulers and semaphores and a
few depencies on a given object, but in different vm you can still end up
with an object that is idle in a vm, but slipped through here.
Could you describe the exact scenario you had in mind? I won't pretend it
this is simple code and I have it all figured out.
Well tbh I don't fully understand what exactly your code will do in all
corner-cases since there's a lot of ifs and special cases. But
fundamentally the problem is that an object can be active in a given vm
and there's no request pointing at the corresponding context in either
last_read_req or last_write_req. It works like this:
- ctx A uses obj 1
- ctx B uses obj 1 on the same engine
Your code above will miss to retire obj 1 on ctx 1's vm, so if you then
destroy ctx A you'll hit the nice warn above (presuming ctx B keeps obj 1
busy for all that time). So not even scheduler needed.
Ah yes... I was even close to figuring this one out but got too confused
and decided I am imagining things...
Fundamentally if you really want to accurately keep track of vma instaed
of obj activeness, then you need to have per-vma tracking of all of it,
i.e. all the last_*_req stuff.
Without that we essentially only keep track of an lru on each vm, and the
active/inactive split is totally bogus (well not quite, but since it
reflects obj->active there's not really any value, but it does create tons
of confusion).
To unconfuse this we'd need to have proper vma active tracking (not sure
whether that's worth it) or just merge the per-vm active/inactive lists
since they're really just one big list.
... so all in all best to drop this for now. Since it is a half
solution, plus Chris says Synmark, if I read it right, likes to use an
object from a zillion of contexts simultaneously so would be hurt by
traversing the obj->vma_list here.
Also, checking for the view type is some strange layering. Why that?
!ppgtt to skip potential other views I thought, no?
The vma lrus should be irrespective of ggtt vs. ppgtt or exactly what kind
of view it is. If we exclude special case everywhere the might pop up but
should the code will become unreadable (and the abstraction useless). What
do you fear could blow up without this check?
Nothing really, since other view types will never end up on the active
list. Just a never ending dilemma of whether to be generic or optimal. :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: more virtual south bridge detection
On Thu, Nov 26, 2015 at 12:03:51PM +0100, Gerd Hoffmann wrote:
> Commit "30c964a drm/i915: Detect virtual south bridge" detects and
> handles the southbridge emulated by vmware esx. Add the ich9 south
> bridge emulated by 'qemu -M q35'.
>
> Signed-off-by: Gerd Hoffmann
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 3 ++-
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 760e0ce..a3c482e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -531,7 +531,8 @@ void intel_detect_pch(struct drm_device *dev)
> dev_priv->pch_type = PCH_SPT;
> DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
> WARN_ON(!IS_SKYLAKE(dev));
> - } else if (id == INTEL_PCH_P2X_DEVICE_ID_TYPE) {
> + } else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
> +(id == INTEL_PCH_QEMU_DEVICE_ID_TYPE)) {
> dev_priv->pch_type = intel_virt_detect_pch(dev);
> } else
> continue;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 95bb27d..463ab22 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2604,6 +2604,7 @@ struct drm_i915_cmd_table {
> #define INTEL_PCH_SPT_DEVICE_ID_TYPE 0xA100
> #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE 0x9D00
> #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100
> +#define INTEL_PCH_QEMU_DEVICE_ID_TYPE0x2900 /* qemu q35 has
> 2918 */
>
> #define INTEL_PCH_TYPE(dev) (__I915__(dev)->pch_type)
> #define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix the SDE irq dmesg warnings properly
On Wed, 25 Nov 2015, Ville Syrjälä wrote:
> On Wed, Nov 25, 2015 at 04:47:22PM +0200, Jani Nikula wrote:
>> We had the "The master control interrupt lied (SDE)!" check and error
>> message in place for a long time without any problems, until
>>
>> commit aaf5ec2e51ab1d9c5e962b4728a1107ed3ff7a3e
>> Author: Sonika Jindal
>> Date: Wed Jul 8 17:07:47 2015 +0530
>>
>> drm/i915: Handle HPD when it has actually occurred
>>
>> caused the errors to start happening. This was bisected and reported,
>> but the error message was silenced in
>>
>> commit 97e5eddcc5300a0f59a55248cd243937a8ab
>> Author: Daniel Vetter
>> Date: Fri Oct 23 10:56:12 2015 +0200
>>
>> drm/i915: shut up gen8+ SDE irq dmesg noise
>>
>> shooting the messenger while the debugging for why Sonika's commit
>> triggered the errors was still in progress.
>>
>> It looks like we need to read and acknowledge the PCH_PORT_HOTPLUG
>> register even though the hotplug trigger indicates there isn't a hotplug
>> irq to handle.
>>
>> Cc: Ville Syrjälä
>> Cc: Sonika Jindal
>> Cc: Daniel Vetter
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084
>> Fixes: aaf5ec2e51ab ("drm/i915: Handle HPD when it has actually occurred")
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/i915_irq.c | 16
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c
>> b/drivers/gpu/drm/i915/i915_irq.c
>> index c8ba94968aaf..982951d3153a 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -1825,7 +1825,17 @@ static void ibx_hpd_irq_handler(struct drm_device
>> *dev, u32 hotplug_trigger,
>> u32 dig_hotplug_reg, pin_mask = 0, long_mask = 0;
>>
>> dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
>> +if (!hotplug_trigger) {
>> +u32 mask = PORTA_HOTPLUG_STATUS_MASK |
>> +PORTD_HOTPLUG_STATUS_MASK |
>> +PORTC_HOTPLUG_STATUS_MASK |
>> +PORTB_HOTPLUG_STATUS_MASK;
>> +dig_hotplug_reg &= ~mask;
>> +}
>> +
>> I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
>> +if (!hotplug_trigger)
>> +return;
>
> I would add some kind of comment around these parts to explain that
> somehow the PCH doesn't seem to really ack the interrupt to the CPU
> unless we touch the hotplug register.
>
> Otherwise (for both patches)
> Reviewed-by: Ville Syrjälä
Pushed to drm-intel-next-queued, with a comment added and the commit
message amended slightly, thanks for the review.
BR,
Jani.
>
> Also not sure if SKL might need something similar as well...
>
>>
>> intel_get_hpd_pins(&pin_mask, &long_mask, hotplug_trigger,
>> dig_hotplug_reg, hpd,
>> @@ -1840,8 +1850,7 @@ static void ibx_irq_handler(struct drm_device *dev,
>> u32 pch_iir)
>> int pipe;
>> u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK;
>>
>> -if (hotplug_trigger)
>> -ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_ibx);
>> +ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_ibx);
>>
>> if (pch_iir & SDE_AUDIO_POWER_MASK) {
>> int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK) >>
>> @@ -1934,8 +1943,7 @@ static void cpt_irq_handler(struct drm_device *dev,
>> u32 pch_iir)
>> int pipe;
>> u32 hotplug_trigger = pch_iir & SDE_HOTPLUG_MASK_CPT;
>>
>> -if (hotplug_trigger)
>> -ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_cpt);
>> +ibx_hpd_irq_handler(dev, hotplug_trigger, hpd_cpt);
>>
>> if (pch_iir & SDE_AUDIO_POWER_MASK_CPT) {
>> int port = ffs((pch_iir & SDE_AUDIO_POWER_MASK_CPT) >>
>> --
>> 2.1.4
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4] lib/igt_core: Add kmsg capture and dumping
On Thu, Nov 26, 2015 at 02:17:53PM +0200, Joonas Lahtinen wrote:
> Capture the output from /dev/kmsg during test execution independantly
> of other concurrent watchers like Piglit test runner.
>
> The captured output is analyzed and the whole output dumped if message
> with priority LOG_WARNING or higher is emitted from any domain.
>
> Also adding igt_capture to lib/tests which will fail subtests and
> produce kmsg output which should be captured by the new code.
>
> v4:
> - Do not effect return value of test, just dump (Daniel)
>
> v3:
> - Use O_CLOEXEC and clarify hex decoding (Chris)
>
> v2:
> - Reopen/close the kmsg FD per each test (Chris)
> - Better commit mesage (Daniel)
> - Display failure due to kmsg only as FAIL (KMSG)
>
> Cc: Thomas Wood
> Cc: Chris Wilson
> Cc: Damien Lespiau
> Cc: Daniel Vetter
> Acked-by: Daniel Vetter
Hm I guess we need to strike that ack again, more comments below.
> Signed-off-by: Joonas Lahtinen
> ---
> lib/igt_core.c | 129
> +++--
> lib/tests/.gitignore | 1 +
> lib/tests/Makefile.sources | 2 +
> lib/tests/igt_capture.c| 89 +++
> 4 files changed, 218 insertions(+), 3 deletions(-)
> create mode 100644 lib/tests/igt_capture.c
>
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 84cf8d2..b1aa750 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #ifdef __linux__
> @@ -211,6 +212,8 @@
> * "--help" command line option.
> */
>
> +#define IGT_KMSG_DUMP_BUF_SIZE 4096
> +
> static unsigned int exit_handler_count;
> const char *igt_interactive_debug;
>
> @@ -248,6 +251,10 @@ enum {
> static int igt_exitcode = IGT_EXIT_SUCCESS;
> static const char *command_str;
>
> +static int igt_kmsg_capture_fd = -1;
> +static int igt_kmsg_check_fd = -1;
> +static char* igt_kmsg_dump_buf = NULL;
> +
> static char* igt_log_domain_filter;
> static struct {
> char *entries[256];
> @@ -313,6 +320,112 @@ static void _igt_log_buffer_dump(void)
> pthread_mutex_unlock(&log_buffer_mutex);
> }
>
> +static void _igt_kmsg_reset(void)
> +{
> + if (igt_kmsg_dump_buf == NULL)
> + igt_kmsg_dump_buf = malloc(IGT_KMSG_DUMP_BUF_SIZE);
> +
> + if (igt_kmsg_dump_buf == NULL) {
> + igt_warn("Unable to allocate memory, "
> + "can not dump kmsg.\n");
> + return;
> + }
> +
> + if (igt_kmsg_capture_fd == -1)
> + igt_kmsg_capture_fd = open("/dev/kmsg",
> +O_RDONLY | O_NONBLOCK | O_CLOEXEC);
> +
> + if (igt_kmsg_capture_fd == -1)
> + goto err_capture;
> +
> + if (igt_kmsg_check_fd == -1)
> + igt_kmsg_check_fd = open("/dev/kmsg",
> + O_RDONLY | O_NONBLOCK | O_CLOEXEC);
> +
> + if (igt_kmsg_check_fd == -1)
> + goto err_check;
> +
> + lseek(igt_kmsg_capture_fd, 0, SEEK_END);
> + lseek(igt_kmsg_check_fd, 0, SEEK_END);
> + return;
> +
> +err_check:
> + close(igt_kmsg_capture_fd);
> + igt_kmsg_capture_fd = -1;
> +err_capture:
> + free(igt_kmsg_dump_buf);
> + igt_kmsg_dump_buf = NULL;
> + return;
> +}
> +
> +static int _igt_kmsg_dump(bool print, int filter_priority)
> +{
> + size_t nbytes;
> + int nlines;
> + int prefix;
> + int priority;
> + char *p;
> + int fd;
> +
> + fd = print ? igt_kmsg_capture_fd : igt_kmsg_check_fd;
> + if (fd == -1)
> + return 0;
> +
> + nlines = 0;
> + do {
> + errno = 0;
> + nbytes = read(fd, igt_kmsg_dump_buf, IGT_KMSG_DUMP_BUF_SIZE);
> +
> + if (nbytes == -1)
> + continue;
> +
> + sscanf(igt_kmsg_dump_buf, "%d;", &prefix);
> + priority = prefix & 0x7;
> +
> + if (priority > filter_priority)
> + continue;
> +
> + nlines++;
> +
> + if (!print)
> + continue;
> +
> + if (nlines == 1)
> + fprintf(stderr, " KMSG \n");
Please use the igt logging functions we have. This holds in general,
please don't use any of the raw output functions and instead use the
igt_warn/info/debug stuff in your entire patch for logging.
Also the problem with dumping into stderr is that this is at the igt_warn
level, which means if this happens your test will be considered a failure
in CI.
And there's plenty of drivers and other stuff that dump random crap at
this level into dmesg, especially over system suspend resume. Which means
your patch will regress a pile of BAT igts.
We really, really need to filter dmesg the same way as piglit does. And I
mean _exactly_ the same way. Otherwise there's differences in test status,
and that means noise in CI and frustration all around.
Other opt
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use a crtc mask instead of a active refcount for dpll functions.
On Tue, 2015-11-24 at 10:44 +0100, Maarten Lankhorst wrote:
> This makes it easier to verify correct dpll setup with only a single crtc.
> It it also useful to detect double dpll enable/disable.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 68 ---
> -
> 3 files changed, 40 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b86feeeafc45..37d4a7f3d112 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3236,7 +3236,7 @@ static int i915_shared_dplls_info(struct seq_file *m,
> void *unused)
>
> seq_printf(m, "DPLL%i: %s, id: %i\n", i, pll->name, pll->id);
> seq_printf(m, " crtc_mask: 0x%08x, active: %d, on: %s\n",
> -pll->config.crtc_mask, pll->active, yesno(pll
> ->on));
> +pll->config.crtc_mask, hweight32(pll
> ->active_mask), yesno(pll->on));
> seq_printf(m, " tracked hardware state:\n");
> seq_printf(m, " dpll:0x%08x\n", pll
> ->config.hw_state.dpll);
> seq_printf(m, " dpll_md: 0x%08x\n",
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index f3ad72abeea7..e0763c3005e8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -393,7 +393,7 @@ struct intel_shared_dpll_config {
> struct intel_shared_dpll {
> struct intel_shared_dpll_config config;
>
> - int active; /* count of number of active CRTCs (i.e. DPMS on) */
> + unsigned active_mask; /* mask of active CRTCs (i.e. DPMS on) */
> bool on; /* is the PLL actually active? Disabled during modeset */
> const char *name;
> /* should match the index in the dev_priv->shared_dplls array */
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3317db3806a8..79bb22ef67dc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1870,7 +1870,7 @@ static void intel_prepare_shared_dpll(struct intel_crtc
> *crtc)
> return;
>
> WARN_ON(!pll->config.crtc_mask);
> - if (pll->active == 0) {
> + if (pll->active_mask == 0) {
> DRM_DEBUG_DRIVER("setting up %s\n", pll->name);
> WARN_ON(pll->on);
> assert_shared_dpll_disabled(dev_priv, pll);
> @@ -1892,6 +1892,7 @@ static void intel_enable_shared_dpll(struct intel_crtc
> *crtc)
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(crtc);
> + unsigned crtc_mask = 1 << drm_crtc_index(&crtc->base);
>
> if (WARN_ON(pll == NULL))
> return;
> @@ -1899,11 +1900,16 @@ static void intel_enable_shared_dpll(struct intel_crtc
> *crtc)
> if (WARN_ON(pll->config.crtc_mask == 0))
> return;
>
> + if (WARN_ON(pll->active_mask & crtc_mask))
> + return;
> +
> DRM_DEBUG_KMS("enable %s (active %d, on? %d) for crtc %d\n",
> - pll->name, pll->active, pll->on,
> + pll->name, hweight32(pll->active_mask), pll->on,
Maybe just print active_mask, it is more informative anyway.
> crtc->base.base.id);
>
> - if (pll->active++) {
> + pll->active_mask |= crtc_mask;
> +
> + if (pll->active_mask != crtc_mask) {
> WARN_ON(!pll->on);
> assert_shared_dpll_enabled(dev_priv, pll);
> return;
> @@ -1922,30 +1928,33 @@ static void intel_disable_shared_dpll(struct
> intel_crtc *crtc)
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_shared_dpll *pll = intel_crtc_to_shared_dpll(crtc);
> + unsigned crtc_mask = 1 << drm_crtc_index(&crtc->base);
>
> /* PCH only available on ILK+ */
> - if (INTEL_INFO(dev)->gen < 5)
> + if (INTEL_INFO(dev_priv)->gen < 5)
> return;
>
> if (pll == NULL)
> return;
>
> - if (WARN_ON(!(pll->config.crtc_mask & (1 << drm_crtc_index(&crtc
> ->base)
> + if (WARN_ON(!(pll->config.crtc_mask & crtc_mask)))
> return;
>
> - DRM_DEBUG_KMS("disable %s (active %d, on? %d) for crtc %d\n",
> - pll->name, pll->active, pll->on,
> + if (WARN_ON(!(pll->active_mask & crtc_mask)))
> + return;
> +
> + DRM_DEBUG_KMS("disable %s (active %x, on? %d) for crtc %d\n",
> + pll->name, pll->active_mask, pll->on,
> crtc->base.base.id);
>
> - if (WARN_ON(pll->active == 0)) {
> + pll->active_mask &= ~crtc_mask;
> + if (pll->active_mask) {
>
Re: [Intel-gfx] [PATCH] drm/i915: Fix possible null dereference in framebuffer_info debugfs function
On Thu, Nov 26, 2015 at 12:43:19PM +, Chris Wilson wrote:
> On Thu, Nov 26, 2015 at 04:32:30PM +0530, Namrta Salonie wrote:
> > Found by static code analysis tool.
> >
> > v2: Inserted block instead of goto & renamed variables (Chris)
> >
> > Signed-off-by: Namrta Salonie
> > Signed-off-by: Deepak S
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 32 +++-
> > 1 file changed, 15 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index a3b22bd..7c068ea 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -1865,31 +1865,29 @@ static int i915_gem_framebuffer_info(struct
> > seq_file *m, void *data)
> > {
> > struct drm_info_node *node = m->private;
> > struct drm_device *dev = node->minor->dev;
> > - struct intel_fbdev *ifbdev = NULL;
> > - struct intel_framebuffer *fb;
> > + struct intel_framebuffer *fbdev_fb = NULL;
> > struct drm_framebuffer *drm_fb;
> >
> > #ifdef CONFIG_DRM_FBDEV_EMULATION
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> >
> > - ifbdev = dev_priv->fbdev;
> > - fb = to_intel_framebuffer(ifbdev->helper.fb);
> > -
> > - seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, modifier 0x%llx,
> > refcount %d, obj ",
> > - fb->base.width,
> > - fb->base.height,
> > - fb->base.depth,
> > - fb->base.bits_per_pixel,
> > - fb->base.modifier[0],
> > - atomic_read(&fb->base.refcount.refcount));
> > - describe_obj(m, fb->obj);
> > - seq_putc(m, '\n');
> > + if (to_i915(dev)->fbdev) {
> > + fbdev_fb = to_intel_framebuffer(to_i915(dev)->fbdev->helper.fb);
> > + seq_printf(m, "fbcon size: %d x %d, depth %d, %d bpp, modifier
> > 0x%llx, refcount %d, obj ",
> > + fbdev_fb->base.width,
> > + fbdev_fb->base.height,
> > + fbdev_fb->base.depth,
> > + fbdev_fb->base.bits_per_pixel,
> > + fbdev_fb->base.modifier[0],
> > + atomic_read(&fbdev_fb->base.refcount.refcount));
>
> These should be aligned to the opening '('
Patch also doesn't apply cleanly any more on top of drm-intel-nightly. Can
you please rebase and fix up the alignment problem Chris pointed out
above?
Thanks, Daniel
>
> Reviewed-by: Chris Wilson
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://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
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move VMAs to inactive as request are retired
On Thu, Nov 26, 2015 at 02:07:57PM +, Tvrtko Ursulin wrote:
>
> On 26/11/15 10:01, Daniel Vetter wrote:
> >On Wed, Nov 25, 2015 at 10:16:37AM +, Tvrtko Ursulin wrote:
> >>
> >>On 24/11/15 17:47, Daniel Vetter wrote:
> >>>On Mon, Nov 23, 2015 at 03:12:35PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Current code moves _any_ VMA to the inactive list only when
> _all_ rendering on an object (so from any context or VM) has
> been completed.
>
> This creates an un-natural situation where the context (and
> VM) destructors can run with VMAs still on the respective
> active list.
>
> Change here is to move VMAs to the inactive list as the
> requests are getting retired.
>
> Signed-off-by: Tvrtko Ursulin
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92638
> Testcase: igt/gem_request_retire/retire-vma-not-inactive
> Cc: Daniel Vetter
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c
> index cd7e102720f4..47a743246d2c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2413,17 +2413,32 @@ static void
> i915_gem_object_retire__read(struct drm_i915_gem_object *obj, int ring)
> {
> struct i915_vma *vma;
> + struct i915_address_space *vm;
>
> RQ_BUG_ON(obj->last_read_req[ring] == NULL);
> RQ_BUG_ON(!(obj->active & (1 << ring)));
>
> list_del_init(&obj->ring_list[ring]);
> - i915_gem_request_assign(&obj->last_read_req[ring], NULL);
>
> if (obj->last_write_req && obj->last_write_req->ring->id ==
> ring)
> i915_gem_object_retire__write(obj);
>
> obj->active &= ~(1 << ring);
> +
> + if (obj->last_read_req[ring]->ctx->ppgtt)
> + vm = &obj->last_read_req[ring]->ctx->ppgtt->base;
> + else
> + vm = &obj->last_read_req[ring]->i915->gtt.base;
> +
> + list_for_each_entry(vma, &obj->vma_list, vma_link) {
> + if (vma->vm == vm &&
> + vma->ggtt_view.type == I915_GGTT_VIEW_NORMAL &&
> + !list_empty(&vma->mm_list))
> + list_move_tail(&vma->mm_list, &vma->vm->inactive_list);
> + }
> >>>
> >>>This is only a partial solution since with schedulers and semaphores and a
> >>>few depencies on a given object, but in different vm you can still end up
> >>>with an object that is idle in a vm, but slipped through here.
> >>
> >>Could you describe the exact scenario you had in mind? I won't pretend it
> >>this is simple code and I have it all figured out.
> >
> >Well tbh I don't fully understand what exactly your code will do in all
> >corner-cases since there's a lot of ifs and special cases. But
> >fundamentally the problem is that an object can be active in a given vm
> >and there's no request pointing at the corresponding context in either
> >last_read_req or last_write_req. It works like this:
> >
> >- ctx A uses obj 1
> >- ctx B uses obj 1 on the same engine
> >
> >Your code above will miss to retire obj 1 on ctx 1's vm, so if you then
> >destroy ctx A you'll hit the nice warn above (presuming ctx B keeps obj 1
> >busy for all that time). So not even scheduler needed.
>
> Ah yes... I was even close to figuring this one out but got too confused and
> decided I am imagining things...
>
> >Fundamentally if you really want to accurately keep track of vma instaed
> >of obj activeness, then you need to have per-vma tracking of all of it,
> >i.e. all the last_*_req stuff.
> >
> >Without that we essentially only keep track of an lru on each vm, and the
> >active/inactive split is totally bogus (well not quite, but since it
> >reflects obj->active there's not really any value, but it does create tons
> >of confusion).
> >
> >To unconfuse this we'd need to have proper vma active tracking (not sure
> >whether that's worth it) or just merge the per-vm active/inactive lists
> >since they're really just one big list.
>
> ... so all in all best to drop this for now. Since it is a half solution,
> plus Chris says Synmark, if I read it right, likes to use an object from a
> zillion of contexts simultaneously so would be hurt by traversing the
> obj->vma_list here.
Yeah, walking obj->vma_list pretty much means unclean design.
Unfortunately we still have a pile of those left from the original ppgtt
enabling, and the fixes for those are burried in Chris' tree somewhere.
> >>>Also, checking for the view type is some strange layering. Why that?
> >>
> >>!ppgtt to skip potential other views I thought, no?
> >
> >The vma lrus should be irrespective of ggtt vs. ppgtt or exactly what kind
> >of view it is. If we exclude special case everywhere
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Perform dpll commit first.
On Tue, 2015-11-24 at 10:44 +0100, Maarten Lankhorst wrote:
> Warn for the wrong mask in enable only. Disable will have the wrong mask
> now because the new state is committed before disabling the old state.
Why?
Ander
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 79bb22ef67dc..3eb51195da72 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1897,7 +1897,7 @@ static void intel_enable_shared_dpll(struct intel_crtc
> *crtc)
> if (WARN_ON(pll == NULL))
> return;
>
> - if (WARN_ON(pll->config.crtc_mask == 0))
> + if (WARN_ON(!(pll->config.crtc_mask & (1 << drm_crtc_index(&crtc
> ->base)
> return;
>
> if (WARN_ON(pll->active_mask & crtc_mask))
> @@ -1937,9 +1937,6 @@ static void intel_disable_shared_dpll(struct intel_crtc
> *crtc)
> if (pll == NULL)
> return;
>
> - if (WARN_ON(!(pll->config.crtc_mask & crtc_mask)))
> - return;
> -
> if (WARN_ON(!(pll->active_mask & crtc_mask)))
> return;
>
> @@ -13382,7 +13379,8 @@ static int intel_atomic_commit(struct drm_device *dev,
> }
>
> drm_atomic_helper_swap_state(dev, state);
> - dev_priv->wm.config = to_intel_atomic_state(state)->wm_config;
> + dev_priv->wm.config = intel_state->wm_config;
> + intel_shared_dpll_commit(state);
>
> if (intel_state->modeset) {
> memcpy(dev_priv->min_pixclk, intel_state->min_pixclk,
> @@ -13415,8 +13413,6 @@ static int intel_atomic_commit(struct drm_device *dev,
> intel_modeset_update_crtc_state(state);
>
> if (intel_state->modeset) {
> - intel_shared_dpll_commit(state);
> -
> drm_atomic_helper_update_legacy_modeset_state(state->dev,
> state);
> modeset_update_crtc_power_domains(state);
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] tests/gem_eio: Resilience against "hanging too fast"
On Thu, Nov 26, 2015 at 12:59:37PM +, Chris Wilson wrote: > On Thu, Nov 26, 2015 at 12:34:35PM +0100, Daniel Vetter wrote: > > Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu > > hang we need to be careful to not run into the "hanging too fast > > check": > > > > - don't restore the ban period, but instead keep it at 0. > > - make sure we idle the gpu fully before hanging it again (wait > > subtest missted that). > > > > With this gem_eio works now reliable even when I don't run the > > subtests individually. > > > > Of course it's a bit fishy that the default ctx gets blamed for > > essentially doing nothing, but until that's figured out in upstream > > it's better to make the test work for now. > > This used to be reliable. And just disabling all banning in the kernel > forever more is silly. > > During igt_post_hang_ring: > 1. we wait upon the hanging batch > - this returns when hangcheck fires > 2. reset the ban period to normal > - this takes mutex_lock_interruptible and so must wait for the reset >handler to run before it can make the change, > - ergo the hanging batch never triggers a ban for itself. > - (a subsequent nonsimulated GPU hang may trigger the ban though) This isn't where it dies. It dies when we do the echo 1 > i915_wedged. I suspect quiescent_gpu or whatever is getting in the way, but I really only wanted to get things to run first. And since i915_wedged is a developer feature, and it does work perfectly if you don't intend to reuse contexts I didn't see any point in first trying to fix it up. So I still maintain that this is a good enough approach, at least if there's no obvious fix in-flight already. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Check the timeout passed to i915_wait_request
On Thu, Nov 26, 2015 at 01:31:42PM +, Chris Wilson wrote:
> We have relied upon the sole caller (wait_ioctl) validating the timeout
> argument. However, when waiting for multiple requests I forgot to ensure
> that the timeout was still positive on the later requests. This is more
> simply done inside __i915_wait_request.
>
> Fixes regression introduced in
> commit b47161858ba13c9c7e0132230d66e008dd55
> Author: Chris Wilson
> Date: Mon Apr 27 13:41:17 2015 +0100
>
> drm/i915: Implement inter-engine read-read optimisations
>
> Signed-off-by: Chris Wilson
> Cc: Lionel Landwerlin
> Cc: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: sta...@vger.kernel.org
Commit message should explain what the actual problem is - we add 1 jiffy
of delay for each wait_request, potentially waiting quite a bit longer
than what userspace asked for.
And not sure this really justifies for cc: stable, since all the wait
syscalls reserve the right to wait longer. Of course we should fix it,
just to keep validating this possible.
So with the commit message amended and cc: stable dropped this is
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 73c2c48729ec..8c19a980f5e6 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1210,8 +1210,16 @@ int __i915_wait_request(struct drm_i915_gem_request
> *req,
> if (i915_gem_request_completed(req, true))
> return 0;
>
> - timeout_expire = timeout ?
> - jiffies + nsecs_to_jiffies_timeout((u64)*timeout) : 0;
> + timeout_expire = 0;
> + if (timeout) {
> + if (WARN_ON(*timeout < 0))
> + return -EINVAL;
> +
> + if (*timeout == 0)
> + return -ETIME;
> +
> + timeout_expire = jiffies + nsecs_to_jiffies_timeout(*timeout);
> + }
>
> if (INTEL_INFO(dev_priv)->gen >= 6)
> gen6_rps_boost(dev_priv, rps, req->emitted_jiffies);
> --
> 2.6.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v4] lib/igt_core: Add kmsg capture and dumping
On to, 2015-11-26 at 15:34 +0100, Daniel Vetter wrote:
> On Thu, Nov 26, 2015 at 02:17:53PM +0200, Joonas Lahtinen wrote:
> > Capture the output from /dev/kmsg during test execution
> > independantly
> > of other concurrent watchers like Piglit test runner.
> >
> > The captured output is analyzed and the whole output dumped if
> > message
> > with priority LOG_WARNING or higher is emitted from any domain.
> >
> > Also adding igt_capture to lib/tests which will fail subtests and
> > produce kmsg output which should be captured by the new code.
> >
> > v4:
> > - Do not effect return value of test, just dump (Daniel)
> >
> > v3:
> > - Use O_CLOEXEC and clarify hex decoding (Chris)
> >
> > v2:
> > - Reopen/close the kmsg FD per each test (Chris)
> > - Better commit mesage (Daniel)
> > - Display failure due to kmsg only as FAIL (KMSG)
> >
> > Cc: Thomas Wood
> > Cc: Chris Wilson
> > Cc: Damien Lespiau
> > Cc: Daniel Vetter
> > Acked-by: Daniel Vetter
>
> Hm I guess we need to strike that ack again, more comments below.
>
> > Signed-off-by: Joonas Lahtinen
> > ---
> > lib/igt_core.c | 129
> > +++--
> > lib/tests/.gitignore | 1 +
> > lib/tests/Makefile.sources | 2 +
> > lib/tests/igt_capture.c| 89 +++
> > 4 files changed, 218 insertions(+), 3 deletions(-)
> > create mode 100644 lib/tests/igt_capture.c
> >
> > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > index 84cf8d2..b1aa750 100644
> > --- a/lib/igt_core.c
> > +++ b/lib/igt_core.c
> > @@ -43,6 +43,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #ifdef __linux__
> > @@ -211,6 +212,8 @@
> > * "--help" command line option.
> > */
> >
> > +#define IGT_KMSG_DUMP_BUF_SIZE 4096
> > +
> > static unsigned int exit_handler_count;
> > const char *igt_interactive_debug;
> >
> > @@ -248,6 +251,10 @@ enum {
> > static int igt_exitcode = IGT_EXIT_SUCCESS;
> > static const char *command_str;
> >
> > +static int igt_kmsg_capture_fd = -1;
> > +static int igt_kmsg_check_fd = -1;
> > +static char* igt_kmsg_dump_buf = NULL;
> > +
> > static char* igt_log_domain_filter;
> > static struct {
> > char *entries[256];
> > @@ -313,6 +320,112 @@ static void _igt_log_buffer_dump(void)
> > pthread_mutex_unlock(&log_buffer_mutex);
> > }
> >
> > +static void _igt_kmsg_reset(void)
> > +{
> > + if (igt_kmsg_dump_buf == NULL)
> > + igt_kmsg_dump_buf =
> > malloc(IGT_KMSG_DUMP_BUF_SIZE);
> > +
> > + if (igt_kmsg_dump_buf == NULL) {
> > + igt_warn("Unable to allocate memory, "
> > +"can not dump kmsg.\n");
> > + return;
> > + }
> > +
> > + if (igt_kmsg_capture_fd == -1)
> > + igt_kmsg_capture_fd = open("/dev/kmsg",
> > + O_RDONLY | O_NONBLOCK |
> > O_CLOEXEC);
> > +
> > + if (igt_kmsg_capture_fd == -1)
> > + goto err_capture;
> > +
> > + if (igt_kmsg_check_fd == -1)
> > + igt_kmsg_check_fd = open("/dev/kmsg",
> > +O_RDONLY | O_NONBLOCK |
> > O_CLOEXEC);
> > +
> > + if (igt_kmsg_check_fd == -1)
> > + goto err_check;
> > +
> > + lseek(igt_kmsg_capture_fd, 0, SEEK_END);
> > + lseek(igt_kmsg_check_fd, 0, SEEK_END);
> > + return;
> > +
> > +err_check:
> > + close(igt_kmsg_capture_fd);
> > + igt_kmsg_capture_fd = -1;
> > +err_capture:
> > + free(igt_kmsg_dump_buf);
> > + igt_kmsg_dump_buf = NULL;
> > + return;
> > +}
> > +
> > +static int _igt_kmsg_dump(bool print, int filter_priority)
> > +{
> > + size_t nbytes;
> > + int nlines;
> > + int prefix;
> > + int priority;
> > + char *p;
> > + int fd;
> > +
> > + fd = print ? igt_kmsg_capture_fd : igt_kmsg_check_fd;
> > + if (fd == -1)
> > + return 0;
> > +
> > + nlines = 0;
> > + do {
> > + errno = 0;
> > + nbytes = read(fd, igt_kmsg_dump_buf,
> > IGT_KMSG_DUMP_BUF_SIZE);
> > +
> > + if (nbytes == -1)
> > + continue;
> > +
> > + sscanf(igt_kmsg_dump_buf, "%d;", &prefix);
> > + priority = prefix & 0x7;
> > +
> > + if (priority > filter_priority)
> > + continue;
> > +
> > + nlines++;
> > +
> > + if (!print)
> > + continue;
> > +
> > + if (nlines == 1)
> > + fprintf(stderr, " KMSG \n");
>
> Please use the igt logging functions we have. This holds in general,
> please don't use any of the raw output functions and instead use the
> igt_warn/info/debug stuff in your entire patch for logging.
>
Actually, if you look at the code I copied;
fprintf(stderr, " DEBUG \n");
So, I was just trying to make it consistent with the existing output.
Would you like both converted to use igt_warn or igt_debug?
> Also the problem with dumping into stderr is that this is at th
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On 2015-11-26 10:24, Takashi Iwai wrote: On Thu, 26 Nov 2015 10:16:17 +0100, Zhang, Xiong Y wrote: On Thu, 26 Nov 2015 08:57:30 +0100, Zhang, Xiong Y wrote: BTW, I have a patchset to avoid the audio h/w wakeup by a new component ops to get ELD and connection states. It was posted to alsa-devel shortly ago just as a reference, but this should work well in such a case, too. The test patches are found in test/hdmi-jack branch of my sound git tree. Did you try this branch (merge onto intel-test-nightly)? [Zhang, Xiong Y] Yes, this branch could fix my issue. OK, good to hear. But this isn't for 4.4 or backport, as it's more radical changes. Could you check the patch below instead? This suppresses the notifier handling during suspend. It's bad, but the hotplug should be still handled via normal unsol event, so it should keep working, good enough as a stop gap. Takashi --- diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index bdb6f226d006..f7c70e2ae65c 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int port) struct hda_codec *codec = audio_ptr; int pin_nid = port + 0x04; - check_presence_and_report(codec, pin_nid); + if (!atomic_read(&codec->core.in_pm) && + !pm_runtime_suspended(hda_codec_dev(codec))) + check_presence_and_report(codec, pin_nid); } static int patch_generic_hdmi(struct hda_codec *codec) [Zhang, Xiong Y] this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend(). OK, then the problem isn't about the HD-audio driver but rather i915 driver. As already mentioned, i915 driver shouldn't issue eld_notify callback in the suspend code path. We don't have a complete drm log so I'm only speculating here; but the HDA log seems to indicate the power well is off when we try to talk to the HDA controller. That means either the i915 shut it down while we were holding a lock on it, or HDA tried to lock it and that didn't make it through; in which case the HDA side should handle an error from get_power more gracefully...? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Thu, 26 Nov 2015 16:08:06 +0100, David Henningsson wrote: > > > > On 2015-11-26 10:24, Takashi Iwai wrote: > > On Thu, 26 Nov 2015 10:16:17 +0100, > > Zhang, Xiong Y wrote: > >> > >> > >>> On Thu, 26 Nov 2015 08:57:30 +0100, > >>> Zhang, Xiong Y wrote: > > >>> BTW, I have a patchset to avoid the audio h/w wakeup by a new > >>> component ops to get ELD and connection states. It was posted to > >>> alsa-devel shortly ago just as a reference, but this should work well > >>> in such a case, too. The test patches are found in test/hdmi-jack > >>> branch of my sound git tree. > > > > Did you try this branch (merge onto intel-test-nightly)? > > > [Zhang, Xiong Y] Yes, this branch could fix my issue. > >>> > >>> OK, good to hear. But this isn't for 4.4 or backport, as it's more > >>> radical changes. > >>> > >>> Could you check the patch below instead? This suppresses the notifier > >>> handling during suspend. It's bad, but the hotplug should be still > >>> handled via normal unsol event, so it should keep working, good enough > >>> as a stop gap. > >>> > >>> > >>> Takashi > >>> > >>> --- > >>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > >>> index bdb6f226d006..f7c70e2ae65c 100644 > >>> --- a/sound/pci/hda/patch_hdmi.c > >>> +++ b/sound/pci/hda/patch_hdmi.c > >>> @@ -33,6 +33,7 @@ > >>> #include > >>> #include > >>> #include > >>> +#include > >>> #include > >>> #include > >>> #include > >>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, > >>> int > >>> port) > >>> struct hda_codec *codec = audio_ptr; > >>> int pin_nid = port + 0x04; > >>> > >>> - check_presence_and_report(codec, pin_nid); > >>> + if (!atomic_read(&codec->core.in_pm) && > >>> + !pm_runtime_suspended(hda_codec_dev(codec))) > >>> + check_presence_and_report(codec, pin_nid); > >>> } > >>> > >>> static int patch_generic_hdmi(struct hda_codec *codec) > >> [Zhang, Xiong Y] this patch couldn't remove the error message. So audio > >> controller isn't in Runtime D3 after azx_suspend(). > > > > OK, then the problem isn't about the HD-audio driver but rather i915 > > driver. As already mentioned, i915 driver shouldn't issue eld_notify > > callback in the suspend code path. > > We don't have a complete drm log so I'm only speculating here; but the > HDA log seems to indicate the power well is off when we try to talk to > the HDA controller. That means either the i915 shut it down while we > were holding a lock on it, or HDA tried to lock it and that didn't make > it through; in which case the HDA side should handle an error from > get_power more gracefully...? My understanding is that it's triggered *during* i915 suspend. Then the path calls the HDA callback, and HDA controller tries to get power and proceeds as it has no idea that it's being shut off. Unfortunately, neither get_power callback or the corresponding HDA code has a capability to check that state. So, changing / fixing this there would be nice but very hard. So I believe it's easier to avoid calling the eld_notify callback from i915 side during its suspend code. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On 2015-11-26 16:23, Takashi Iwai wrote: On Thu, 26 Nov 2015 16:08:06 +0100, David Henningsson wrote: On 2015-11-26 10:24, Takashi Iwai wrote: On Thu, 26 Nov 2015 10:16:17 +0100, Zhang, Xiong Y wrote: On Thu, 26 Nov 2015 08:57:30 +0100, Zhang, Xiong Y wrote: BTW, I have a patchset to avoid the audio h/w wakeup by a new component ops to get ELD and connection states. It was posted to alsa-devel shortly ago just as a reference, but this should work well in such a case, too. The test patches are found in test/hdmi-jack branch of my sound git tree. Did you try this branch (merge onto intel-test-nightly)? [Zhang, Xiong Y] Yes, this branch could fix my issue. OK, good to hear. But this isn't for 4.4 or backport, as it's more radical changes. Could you check the patch below instead? This suppresses the notifier handling during suspend. It's bad, but the hotplug should be still handled via normal unsol event, so it should keep working, good enough as a stop gap. Takashi --- diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index bdb6f226d006..f7c70e2ae65c 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, int port) struct hda_codec *codec = audio_ptr; int pin_nid = port + 0x04; - check_presence_and_report(codec, pin_nid); + if (!atomic_read(&codec->core.in_pm) && + !pm_runtime_suspended(hda_codec_dev(codec))) + check_presence_and_report(codec, pin_nid); } static int patch_generic_hdmi(struct hda_codec *codec) [Zhang, Xiong Y] this patch couldn't remove the error message. So audio controller isn't in Runtime D3 after azx_suspend(). OK, then the problem isn't about the HD-audio driver but rather i915 driver. As already mentioned, i915 driver shouldn't issue eld_notify callback in the suspend code path. We don't have a complete drm log so I'm only speculating here; but the HDA log seems to indicate the power well is off when we try to talk to the HDA controller. That means either the i915 shut it down while we were holding a lock on it, or HDA tried to lock it and that didn't make it through; in which case the HDA side should handle an error from get_power more gracefully...? My understanding is that it's triggered *during* i915 suspend. Then the path calls the HDA callback, and HDA controller tries to get power and proceeds as it has no idea that it's being shut off. Well; that can also be stopped by letting the get_power call return a failure code in case i915 is trying to suspend itself. That seems more robust to me, as it could potentially avoid other S3 races too...? Unfortunately, neither get_power callback or the corresponding HDA code has a capability to check that state. So, changing / fixing this there would be nice but very hard. Surely the i915 driver has some "am_i_suspending" variable it can check in the get_power callback? So I believe it's easier to avoid calling the eld_notify callback from i915 side during its suspend code. Takashi -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] tests/gem_eio: Resilience against "hanging too fast"
On Thu, Nov 26, 2015 at 03:46:06PM +0100, Daniel Vetter wrote: > On Thu, Nov 26, 2015 at 12:59:37PM +, Chris Wilson wrote: > > On Thu, Nov 26, 2015 at 12:34:35PM +0100, Daniel Vetter wrote: > > > Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu > > > hang we need to be careful to not run into the "hanging too fast > > > check": > > > > > > - don't restore the ban period, but instead keep it at 0. > > > - make sure we idle the gpu fully before hanging it again (wait > > > subtest missted that). > > > > > > With this gem_eio works now reliable even when I don't run the > > > subtests individually. > > > > > > Of course it's a bit fishy that the default ctx gets blamed for > > > essentially doing nothing, but until that's figured out in upstream > > > it's better to make the test work for now. > > > > This used to be reliable. And just disabling all banning in the kernel > > forever more is silly. > > > > During igt_post_hang_ring: > > 1. we wait upon the hanging batch > > - this returns when hangcheck fires > > 2. reset the ban period to normal > > - this takes mutex_lock_interruptible and so must wait for the reset > >handler to run before it can make the change, > > - ergo the hanging batch never triggers a ban for itself. > > - (a subsequent nonsimulated GPU hang may trigger the ban though) > > This isn't where it dies. It dies when we do the echo 1 > i915_wedged. That is not where it dies. > I suspect quiescent_gpu or whatever is getting in the way, but I really only > wanted to get things to run first. And since i915_wedged is a developer > feature, and it does work perfectly if you don't intend to reuse contexts > I didn't see any point in first trying to fix it up. > > So I still maintain that this is a good enough approach, at least if > there's no obvious fix in-flight already. No way. This is a kernel regression since 4.0, having just tested with v4.0 on snb/ivb/hsw. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On to, 2015-11-26 at 16:29 +0100, David Henningsson wrote: > > On 2015-11-26 16:23, Takashi Iwai wrote: > > On Thu, 26 Nov 2015 16:08:06 +0100, > > David Henningsson wrote: > > > > > > > > > > > > On 2015-11-26 10:24, Takashi Iwai wrote: > > > > On Thu, 26 Nov 2015 10:16:17 +0100, > > > > Zhang, Xiong Y wrote: > > > > > > > > > > > > > > > > On Thu, 26 Nov 2015 08:57:30 +0100, > > > > > > Zhang, Xiong Y wrote: > > > > > > > > > > > > > > > > > BTW, I have a patchset to avoid the audio h/w > > > > > > > > > > wakeup by a new > > > > > > > > > > component ops to get ELD and connection states. It > > > > > > > > > > was posted to > > > > > > > > > > alsa-devel shortly ago just as a reference, but > > > > > > > > > > this should work well > > > > > > > > > > in such a case, too. The test patches are found in > > > > > > > > > > test/hdmi-jack > > > > > > > > > > branch of my sound git tree. > > > > > > > > > > > > > > > > Did you try this branch (merge onto intel-test- > > > > > > > > nightly)? > > > > > > > > > > > > > > > [Zhang, Xiong Y] Yes, this branch could fix my issue. > > > > > > > > > > > > OK, good to hear. But this isn't for 4.4 or backport, as > > > > > > it's more > > > > > > radical changes. > > > > > > > > > > > > Could you check the patch below instead? This suppresses > > > > > > the notifier > > > > > > handling during suspend. It's bad, but the hotplug should > > > > > > be still > > > > > > handled via normal unsol event, so it should keep working, > > > > > > good enough > > > > > > as a stop gap. > > > > > > > > > > > > > > > > > > Takashi > > > > > > > > > > > > --- > > > > > > diff --git a/sound/pci/hda/patch_hdmi.c > > > > > > b/sound/pci/hda/patch_hdmi.c > > > > > > index bdb6f226d006..f7c70e2ae65c 100644 > > > > > > --- a/sound/pci/hda/patch_hdmi.c > > > > > > +++ b/sound/pci/hda/patch_hdmi.c > > > > > > @@ -33,6 +33,7 @@ > > > > > > #include > > > > > > #include > > > > > > #include > > > > > > +#include > > > > > > #include > > > > > > #include > > > > > > #include > > > > > > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void > > > > > > *audio_ptr, int > > > > > > port) > > > > > > struct hda_codec *codec = audio_ptr; > > > > > > int pin_nid = port + 0x04; > > > > > > > > > > > > - check_presence_and_report(codec, pin_nid); > > > > > > + if (!atomic_read(&codec->core.in_pm) && > > > > > > + !pm_runtime_suspended(hda_codec_dev(codec))) > > > > > > + check_presence_and_report(codec, pin_nid); > > > > > > } > > > > > > > > > > > > static int patch_generic_hdmi(struct hda_codec *codec) > > > > > [Zhang, Xiong Y] this patch couldn't remove the error > > > > > message. So audio controller isn't in Runtime D3 after > > > > > azx_suspend(). > > > > > > > > OK, then the problem isn't about the HD-audio driver but rather > > > > i915 > > > > driver. As already mentioned, i915 driver shouldn't issue > > > > eld_notify > > > > callback in the suspend code path. > > > > > > We don't have a complete drm log so I'm only speculating here; > > > but the > > > HDA log seems to indicate the power well is off when we try to > > > talk to > > > the HDA controller. That means either the i915 shut it down while > > > we > > > were holding a lock on it, or HDA tried to lock it and that > > > didn't make > > > it through; in which case the HDA side should handle an error > > > from > > > get_power more gracefully...? > > > > My understanding is that it's triggered *during* i915 > > suspend. Then > > the path calls the HDA callback, and HDA controller tries to get > > power > > and proceeds as it has no idea that it's being shut off. > > Well; that can also be stopped by letting the get_power call return a > failure code in case i915 is trying to suspend itself. That seems > more > robust to me, as it could potentially avoid other S3 races too...? > > > > > Unfortunately, neither get_power callback or the corresponding HDA > > code has a capability to check that state. So, changing / fixing > > this > > there would be nice but very hard. > > Surely the i915 driver has some "am_i_suspending" variable it can > check > in the get_power callback? As I understand this happens during the i915 system suspend/resume hooks are running. There is no reason why the getting a power domain reference would fail there. In fact we are keeping all power wells for the whole duration of these callbacks, see the call to intel_display_set_init_power(true) in i915_drm_suspend() and i915_drm_resume_early()->intel_power_domains_init_hw(). So not sure how the audio power well could be off at that time. > > > > > So I believe it's easier to avoid calling the eld_notify callback > > from > > i915 side during its suspend code. > > > > > > Takashi > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Disable shrinker for non-swapped backed objects
On Thu, Nov 26, 2015 at 11:25:14AM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 03:46:35PM -0500, Johannes Weiner wrote:
> > On Wed, Nov 25, 2015 at 08:31:02PM +, Chris Wilson wrote:
> > > On Wed, Nov 25, 2015 at 02:06:10PM -0500, Johannes Weiner wrote:
> > > > On Wed, Nov 25, 2015 at 06:36:56PM +, Chris Wilson wrote:
> > > > > +static bool swap_available(void)
> > > > > +{
> > > > > + return total_swap_pages || frontswap_enabled;
> > > > > +}
> > > >
> > > > If you use get_nr_swap_pages() instead of total_swap_pages, this will
> > > > also stop scanning objects once the swap space is full. We do that in
> > > > the VM to stop scanning anonymous pages.
> > >
> > > Thanks. Would EXPORT_SYMBOL_GPL(nr_swap_pages) (or equivalent) be
> > > acceptable?
> >
> > No opposition from me. Just please add a small comment that this is
> > for shrinkers with swappable objects.
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 58877312cf6b..1c7861f4c43c 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -48,6 +48,14 @@ static sector_t map_swap_entry(swp_entry_t, struct
> block_device**);
> DEFINE_SPINLOCK(swap_lock);
> static unsigned int nr_swapfiles;
> atomic_long_t nr_swap_pages;
> +/*
> + * Some modules use swappable objects and may try to swap them out under
> + * memory pressure (via the shrinker). Before doing so, they may wish to
> + * check to see if any swap space is available. The shrinker also directly
> + * uses the available swap space to determine whether it can swapout
> + * anon pages in the same manner.
> + */
> +EXPORT_SYMBOL_GPL(nr_swap_pages);
>
> Something like that, after a couple more edits?
The last sentence isn't necessary IMO, but other than that it looks
good to me.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote: > > > On 2015-11-26 16:23, Takashi Iwai wrote: > > On Thu, 26 Nov 2015 16:08:06 +0100, > > David Henningsson wrote: > >> > >> > >> > >> On 2015-11-26 10:24, Takashi Iwai wrote: > >>> On Thu, 26 Nov 2015 10:16:17 +0100, > >>> Zhang, Xiong Y wrote: > > > > On Thu, 26 Nov 2015 08:57:30 +0100, > > Zhang, Xiong Y wrote: > >> > > BTW, I have a patchset to avoid the audio h/w wakeup by a new > > component ops to get ELD and connection states. It was posted to > > alsa-devel shortly ago just as a reference, but this should work > > well > > in such a case, too. The test patches are found in test/hdmi-jack > > branch of my sound git tree. > >>> > >>> Did you try this branch (merge onto intel-test-nightly)? > >>> > >> [Zhang, Xiong Y] Yes, this branch could fix my issue. > > > > OK, good to hear. But this isn't for 4.4 or backport, as it's more > > radical changes. > > > > Could you check the patch below instead? This suppresses the notifier > > handling during suspend. It's bad, but the hotplug should be still > > handled via normal unsol event, so it should keep working, good enough > > as a stop gap. > > > > > > Takashi > > > > --- > > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > > index bdb6f226d006..f7c70e2ae65c 100644 > > --- a/sound/pci/hda/patch_hdmi.c > > +++ b/sound/pci/hda/patch_hdmi.c > > @@ -33,6 +33,7 @@ > >#include > >#include > >#include > > +#include > >#include > >#include > >#include > > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, > > int > > port) > > struct hda_codec *codec = audio_ptr; > > int pin_nid = port + 0x04; > > > > - check_presence_and_report(codec, pin_nid); > > + if (!atomic_read(&codec->core.in_pm) && > > + !pm_runtime_suspended(hda_codec_dev(codec))) > > + check_presence_and_report(codec, pin_nid); > >} > > > >static int patch_generic_hdmi(struct hda_codec *codec) > [Zhang, Xiong Y] this patch couldn't remove the error message. So audio > controller isn't in Runtime D3 after azx_suspend(). > >>> > >>> OK, then the problem isn't about the HD-audio driver but rather i915 > >>> driver. As already mentioned, i915 driver shouldn't issue eld_notify > >>> callback in the suspend code path. > >> > >> We don't have a complete drm log so I'm only speculating here; but the > >> HDA log seems to indicate the power well is off when we try to talk to > >> the HDA controller. That means either the i915 shut it down while we > >> were holding a lock on it, or HDA tried to lock it and that didn't make > >> it through; in which case the HDA side should handle an error from > >> get_power more gracefully...? > > > > My understanding is that it's triggered *during* i915 suspend. Then > > the path calls the HDA callback, and HDA controller tries to get power > > and proceeds as it has no idea that it's being shut off. > > Well; that can also be stopped by letting the get_power call return a > failure code in case i915 is trying to suspend itself. That seems more > robust to me, as it could potentially avoid other S3 races too...? > > > > > Unfortunately, neither get_power callback or the corresponding HDA > > code has a capability to check that state. So, changing / fixing this > > there would be nice but very hard. > > Surely the i915 driver has some "am_i_suspending" variable it can check > in the get_power callback? I don't understand why you need to do anything special. When the eld notify happens during suspend, the hardware is still fully powered up, so it should just work(tm) as long as the eld_notify is a synchronous call and it drops the power reference at the end. I guess for any get_power after i915 has suspended we'd need to just reject the get_power call. Or does something force hda to suspend before and resume after i915 always? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Thu, 26 Nov 2015 16:29:12 +0100, David Henningsson wrote: > > > > On 2015-11-26 16:23, Takashi Iwai wrote: > > On Thu, 26 Nov 2015 16:08:06 +0100, > > David Henningsson wrote: > >> > >> > >> > >> On 2015-11-26 10:24, Takashi Iwai wrote: > >>> On Thu, 26 Nov 2015 10:16:17 +0100, > >>> Zhang, Xiong Y wrote: > > > > On Thu, 26 Nov 2015 08:57:30 +0100, > > Zhang, Xiong Y wrote: > >> > > BTW, I have a patchset to avoid the audio h/w wakeup by a new > > component ops to get ELD and connection states. It was posted to > > alsa-devel shortly ago just as a reference, but this should work > > well > > in such a case, too. The test patches are found in test/hdmi-jack > > branch of my sound git tree. > >>> > >>> Did you try this branch (merge onto intel-test-nightly)? > >>> > >> [Zhang, Xiong Y] Yes, this branch could fix my issue. > > > > OK, good to hear. But this isn't for 4.4 or backport, as it's more > > radical changes. > > > > Could you check the patch below instead? This suppresses the notifier > > handling during suspend. It's bad, but the hotplug should be still > > handled via normal unsol event, so it should keep working, good enough > > as a stop gap. > > > > > > Takashi > > > > --- > > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > > index bdb6f226d006..f7c70e2ae65c 100644 > > --- a/sound/pci/hda/patch_hdmi.c > > +++ b/sound/pci/hda/patch_hdmi.c > > @@ -33,6 +33,7 @@ > >#include > >#include > >#include > > +#include > >#include > >#include > >#include > > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, > > int > > port) > > struct hda_codec *codec = audio_ptr; > > int pin_nid = port + 0x04; > > > > - check_presence_and_report(codec, pin_nid); > > + if (!atomic_read(&codec->core.in_pm) && > > + !pm_runtime_suspended(hda_codec_dev(codec))) > > + check_presence_and_report(codec, pin_nid); > >} > > > >static int patch_generic_hdmi(struct hda_codec *codec) > [Zhang, Xiong Y] this patch couldn't remove the error message. So audio > controller isn't in Runtime D3 after azx_suspend(). > >>> > >>> OK, then the problem isn't about the HD-audio driver but rather i915 > >>> driver. As already mentioned, i915 driver shouldn't issue eld_notify > >>> callback in the suspend code path. > >> > >> We don't have a complete drm log so I'm only speculating here; but the > >> HDA log seems to indicate the power well is off when we try to talk to > >> the HDA controller. That means either the i915 shut it down while we > >> were holding a lock on it, or HDA tried to lock it and that didn't make > >> it through; in which case the HDA side should handle an error from > >> get_power more gracefully...? > > > > My understanding is that it's triggered *during* i915 suspend. Then > > the path calls the HDA callback, and HDA controller tries to get power > > and proceeds as it has no idea that it's being shut off. > > Well; that can also be stopped by letting the get_power call return a > failure code in case i915 is trying to suspend itself. That seems more > robust to me, as it could potentially avoid other S3 races too...? Would be nice, but it's hard, because as mentioned, many paths evaluating the return value from get_power can't stop the things easily. Also, one thing that came to my mind now: do we have a dependency in suspend order between i915 and HDA? Wouldn't it happen that i915 driver goes to suspend while HDA still active? Then a return check from get_power doesn't necessarily help because it might hold it. > > Unfortunately, neither get_power callback or the corresponding HDA > > code has a capability to check that state. So, changing / fixing this > > there would be nice but very hard. > > Surely the i915 driver has some "am_i_suspending" variable it can check > in the get_power callback? Yeah, that's I supposed in below. > > So I believe it's easier to avoid calling the eld_notify callback from > > i915 side during its suspend code. And I think we need a quicker solution for now. My patchset to use get_eld callback removes the whole power up/down at notification, so we won't have this issue. Thus we need a fix only for 4.3/4.4. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Thu, Nov 26, 2015 at 04:23:16PM +0100, Takashi Iwai wrote: > On Thu, 26 Nov 2015 16:08:06 +0100, > David Henningsson wrote: > > > > > > > > On 2015-11-26 10:24, Takashi Iwai wrote: > > > On Thu, 26 Nov 2015 10:16:17 +0100, > > > Zhang, Xiong Y wrote: > > >> > > >> > > >>> On Thu, 26 Nov 2015 08:57:30 +0100, > > >>> Zhang, Xiong Y wrote: > > > > >>> BTW, I have a patchset to avoid the audio h/w wakeup by a new > > >>> component ops to get ELD and connection states. It was posted to > > >>> alsa-devel shortly ago just as a reference, but this should work > > >>> well > > >>> in such a case, too. The test patches are found in test/hdmi-jack > > >>> branch of my sound git tree. > > > > > > Did you try this branch (merge onto intel-test-nightly)? > > > > > [Zhang, Xiong Y] Yes, this branch could fix my issue. > > >>> > > >>> OK, good to hear. But this isn't for 4.4 or backport, as it's more > > >>> radical changes. > > >>> > > >>> Could you check the patch below instead? This suppresses the notifier > > >>> handling during suspend. It's bad, but the hotplug should be still > > >>> handled via normal unsol event, so it should keep working, good enough > > >>> as a stop gap. > > >>> > > >>> > > >>> Takashi > > >>> > > >>> --- > > >>> diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > > >>> index bdb6f226d006..f7c70e2ae65c 100644 > > >>> --- a/sound/pci/hda/patch_hdmi.c > > >>> +++ b/sound/pci/hda/patch_hdmi.c > > >>> @@ -33,6 +33,7 @@ > > >>> #include > > >>> #include > > >>> #include > > >>> +#include > > >>> #include > > >>> #include > > >>> #include > > >>> @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void *audio_ptr, > > >>> int > > >>> port) > > >>> struct hda_codec *codec = audio_ptr; > > >>> int pin_nid = port + 0x04; > > >>> > > >>> - check_presence_and_report(codec, pin_nid); > > >>> + if (!atomic_read(&codec->core.in_pm) && > > >>> + !pm_runtime_suspended(hda_codec_dev(codec))) > > >>> + check_presence_and_report(codec, pin_nid); > > >>> } > > >>> > > >>> static int patch_generic_hdmi(struct hda_codec *codec) > > >> [Zhang, Xiong Y] this patch couldn't remove the error message. So audio > > >> controller isn't in Runtime D3 after azx_suspend(). > > > > > > OK, then the problem isn't about the HD-audio driver but rather i915 > > > driver. As already mentioned, i915 driver shouldn't issue eld_notify > > > callback in the suspend code path. > > > > We don't have a complete drm log so I'm only speculating here; but the > > HDA log seems to indicate the power well is off when we try to talk to > > the HDA controller. That means either the i915 shut it down while we > > were holding a lock on it, or HDA tried to lock it and that didn't make > > it through; in which case the HDA side should handle an error from > > get_power more gracefully...? > > My understanding is that it's triggered *during* i915 suspend. Then > the path calls the HDA callback, and HDA controller tries to get power > and proceeds as it has no idea that it's being shut off. > > Unfortunately, neither get_power callback or the corresponding HDA > code has a capability to check that state. So, changing / fixing this > there would be nice but very hard. > > So I believe it's easier to avoid calling the eld_notify callback from > i915 side during its suspend code. Not calling eld_notify doesn't really help since when we suspend we do a normal modeset. And on platforms where the eld notify interrupt stuff works that will happen. This needs to be solved somewhere else I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Thu, 26 Nov 2015 16:43:23 +0100, Ville Syrjälä wrote: > > On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote: > > > > > > On 2015-11-26 16:23, Takashi Iwai wrote: > > > On Thu, 26 Nov 2015 16:08:06 +0100, > > > David Henningsson wrote: > > >> > > >> > > >> > > >> On 2015-11-26 10:24, Takashi Iwai wrote: > > >>> On Thu, 26 Nov 2015 10:16:17 +0100, > > >>> Zhang, Xiong Y wrote: > > > > > > > On Thu, 26 Nov 2015 08:57:30 +0100, > > > Zhang, Xiong Y wrote: > > >> > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new > > > component ops to get ELD and connection states. It was posted to > > > alsa-devel shortly ago just as a reference, but this should work > > > well > > > in such a case, too. The test patches are found in test/hdmi-jack > > > branch of my sound git tree. > > >>> > > >>> Did you try this branch (merge onto intel-test-nightly)? > > >>> > > >> [Zhang, Xiong Y] Yes, this branch could fix my issue. > > > > > > OK, good to hear. But this isn't for 4.4 or backport, as it's more > > > radical changes. > > > > > > Could you check the patch below instead? This suppresses the notifier > > > handling during suspend. It's bad, but the hotplug should be still > > > handled via normal unsol event, so it should keep working, good enough > > > as a stop gap. > > > > > > > > > Takashi > > > > > > --- > > > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > > > index bdb6f226d006..f7c70e2ae65c 100644 > > > --- a/sound/pci/hda/patch_hdmi.c > > > +++ b/sound/pci/hda/patch_hdmi.c > > > @@ -33,6 +33,7 @@ > > >#include > > >#include > > >#include > > > +#include > > >#include > > >#include > > >#include > > > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void > > > *audio_ptr, int > > > port) > > > struct hda_codec *codec = audio_ptr; > > > int pin_nid = port + 0x04; > > > > > > - check_presence_and_report(codec, pin_nid); > > > + if (!atomic_read(&codec->core.in_pm) && > > > + !pm_runtime_suspended(hda_codec_dev(codec))) > > > + check_presence_and_report(codec, pin_nid); > > >} > > > > > >static int patch_generic_hdmi(struct hda_codec *codec) > > [Zhang, Xiong Y] this patch couldn't remove the error message. So > > audio controller isn't in Runtime D3 after azx_suspend(). > > >>> > > >>> OK, then the problem isn't about the HD-audio driver but rather i915 > > >>> driver. As already mentioned, i915 driver shouldn't issue eld_notify > > >>> callback in the suspend code path. > > >> > > >> We don't have a complete drm log so I'm only speculating here; but the > > >> HDA log seems to indicate the power well is off when we try to talk to > > >> the HDA controller. That means either the i915 shut it down while we > > >> were holding a lock on it, or HDA tried to lock it and that didn't make > > >> it through; in which case the HDA side should handle an error from > > >> get_power more gracefully...? > > > > > > My understanding is that it's triggered *during* i915 suspend. Then > > > the path calls the HDA callback, and HDA controller tries to get power > > > and proceeds as it has no idea that it's being shut off. > > > > Well; that can also be stopped by letting the get_power call return a > > failure code in case i915 is trying to suspend itself. That seems more > > robust to me, as it could potentially avoid other S3 races too...? > > > > > > > > Unfortunately, neither get_power callback or the corresponding HDA > > > code has a capability to check that state. So, changing / fixing this > > > there would be nice but very hard. > > > > Surely the i915 driver has some "am_i_suspending" variable it can check > > in the get_power callback? > > I don't understand why you need to do anything special. When the eld > notify happens during suspend, the hardware is still fully powered up, > so it should just work(tm) as long as the eld_notify is a synchronous > call and it drops the power reference at the end. Hm, that's the question. It's never clear so far as we haven't got any detailed logs. The symptom implies that the graphics side is off while HDA tries to execute some verbs. So the power well is the first suspect. We reall need to track down the code path triggering the issue. > I guess for any get_power after i915 has suspended we'd need to just > reject the get_power call. Or does something force hda to suspend before > and resume after i915 always? The HDA code itself calls get_power at the beginning of the resume. But not sure whether this suffices for the execution ordering. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesk
Re: [Intel-gfx] [PATCH 2/2] tests/gem_eio: Resilience against "hanging too fast"
On Thu, Nov 26, 2015 at 03:34:05PM +, Chris Wilson wrote: > On Thu, Nov 26, 2015 at 03:46:06PM +0100, Daniel Vetter wrote: > > On Thu, Nov 26, 2015 at 12:59:37PM +, Chris Wilson wrote: > > > On Thu, Nov 26, 2015 at 12:34:35PM +0100, Daniel Vetter wrote: > > > > Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu > > > > hang we need to be careful to not run into the "hanging too fast > > > > check": > > > > > > > > - don't restore the ban period, but instead keep it at 0. > > > > - make sure we idle the gpu fully before hanging it again (wait > > > > subtest missted that). > > > > > > > > With this gem_eio works now reliable even when I don't run the > > > > subtests individually. > > > > > > > > Of course it's a bit fishy that the default ctx gets blamed for > > > > essentially doing nothing, but until that's figured out in upstream > > > > it's better to make the test work for now. > > > > > > This used to be reliable. And just disabling all banning in the kernel > > > forever more is silly. > > > > > > During igt_post_hang_ring: > > > 1. we wait upon the hanging batch > > > - this returns when hangcheck fires > > > 2. reset the ban period to normal > > > - this takes mutex_lock_interruptible and so must wait for the reset > > >handler to run before it can make the change, > > > - ergo the hanging batch never triggers a ban for itself. > > > - (a subsequent nonsimulated GPU hang may trigger the ban though) > > > > This isn't where it dies. It dies when we do the echo 1 > i915_wedged. > > That is not where it dies. Well at least it happens after we start the hang recover from i915_wedged. > > I suspect quiescent_gpu or whatever is getting in the way, but I really only > > wanted to get things to run first. And since i915_wedged is a developer > > feature, and it does work perfectly if you don't intend to reuse contexts > > I didn't see any point in first trying to fix it up. > > > > So I still maintain that this is a good enough approach, at least if > > there's no obvious fix in-flight already. > > No way. This is a kernel regression since 4.0, having just tested with > v4.0 on snb/ivb/hsw. Ok, I didn't realize that. I figured since i915_wedged will return -EAGAIN anyway when we are terminally wedged, and that seems to have been the case ever since we started with reset_counter this has been broken forever. I guess I missed something. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Thu, Nov 26, 2015 at 04:51:04PM +0100, Takashi Iwai wrote: > On Thu, 26 Nov 2015 16:43:23 +0100, > Ville Syrjälä wrote: > > > > On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote: > > > > > > > > > On 2015-11-26 16:23, Takashi Iwai wrote: > > > > On Thu, 26 Nov 2015 16:08:06 +0100, > > > > David Henningsson wrote: > > > >> > > > >> > > > >> > > > >> On 2015-11-26 10:24, Takashi Iwai wrote: > > > >>> On Thu, 26 Nov 2015 10:16:17 +0100, > > > >>> Zhang, Xiong Y wrote: > > > > > > > > > > On Thu, 26 Nov 2015 08:57:30 +0100, > > > > Zhang, Xiong Y wrote: > > > >> > > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new > > > > component ops to get ELD and connection states. It was posted > > > > to > > > > alsa-devel shortly ago just as a reference, but this should > > > > work well > > > > in such a case, too. The test patches are found in > > > > test/hdmi-jack > > > > branch of my sound git tree. > > > >>> > > > >>> Did you try this branch (merge onto intel-test-nightly)? > > > >>> > > > >> [Zhang, Xiong Y] Yes, this branch could fix my issue. > > > > > > > > OK, good to hear. But this isn't for 4.4 or backport, as it's more > > > > radical changes. > > > > > > > > Could you check the patch below instead? This suppresses the > > > > notifier > > > > handling during suspend. It's bad, but the hotplug should be still > > > > handled via normal unsol event, so it should keep working, good > > > > enough > > > > as a stop gap. > > > > > > > > > > > > Takashi > > > > > > > > --- > > > > diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c > > > > index bdb6f226d006..f7c70e2ae65c 100644 > > > > --- a/sound/pci/hda/patch_hdmi.c > > > > +++ b/sound/pci/hda/patch_hdmi.c > > > > @@ -33,6 +33,7 @@ > > > >#include > > > >#include > > > >#include > > > > +#include > > > >#include > > > >#include > > > >#include > > > > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void > > > > *audio_ptr, int > > > > port) > > > > struct hda_codec *codec = audio_ptr; > > > > int pin_nid = port + 0x04; > > > > > > > > - check_presence_and_report(codec, pin_nid); > > > > + if (!atomic_read(&codec->core.in_pm) && > > > > + !pm_runtime_suspended(hda_codec_dev(codec))) > > > > + check_presence_and_report(codec, pin_nid); > > > >} > > > > > > > >static int patch_generic_hdmi(struct hda_codec *codec) > > > [Zhang, Xiong Y] this patch couldn't remove the error message. So > > > audio controller isn't in Runtime D3 after azx_suspend(). > > > >>> > > > >>> OK, then the problem isn't about the HD-audio driver but rather i915 > > > >>> driver. As already mentioned, i915 driver shouldn't issue eld_notify > > > >>> callback in the suspend code path. > > > >> > > > >> We don't have a complete drm log so I'm only speculating here; but the > > > >> HDA log seems to indicate the power well is off when we try to talk to > > > >> the HDA controller. That means either the i915 shut it down while we > > > >> were holding a lock on it, or HDA tried to lock it and that didn't make > > > >> it through; in which case the HDA side should handle an error from > > > >> get_power more gracefully...? > > > > > > > > My understanding is that it's triggered *during* i915 suspend. Then > > > > the path calls the HDA callback, and HDA controller tries to get power > > > > and proceeds as it has no idea that it's being shut off. > > > > > > Well; that can also be stopped by letting the get_power call return a > > > failure code in case i915 is trying to suspend itself. That seems more > > > robust to me, as it could potentially avoid other S3 races too...? > > > > > > > > > > > Unfortunately, neither get_power callback or the corresponding HDA > > > > code has a capability to check that state. So, changing / fixing this > > > > there would be nice but very hard. > > > > > > Surely the i915 driver has some "am_i_suspending" variable it can check > > > in the get_power callback? > > > > I don't understand why you need to do anything special. When the eld > > notify happens during suspend, the hardware is still fully powered up, > > so it should just work(tm) as long as the eld_notify is a synchronous > > call and it drops the power reference at the end. > > Hm, that's the question. It's never clear so far as we haven't got > any detailed logs. > > The symptom implies that the graphics side is off while HDA tries to > execute some verbs. So the power well is the first suspect. We reall > need to track down the code path triggering the issue. > > > I guess for any get_power after i915 has suspended we'd need to just > > reject the get_power call. Or does so
Re: [Intel-gfx] [PATCH] drm/i915: Check the timeout passed to i915_wait_request
On Thu, Nov 26, 2015 at 03:49:00PM +0100, Daniel Vetter wrote: > On Thu, Nov 26, 2015 at 01:31:42PM +, Chris Wilson wrote: > > We have relied upon the sole caller (wait_ioctl) validating the timeout > > argument. However, when waiting for multiple requests I forgot to ensure > > that the timeout was still positive on the later requests. This is more > > simply done inside __i915_wait_request. > > > > Fixes regression introduced in > > commit b47161858ba13c9c7e0132230d66e008dd55 > > Author: Chris Wilson > > Date: Mon Apr 27 13:41:17 2015 +0100 > > > > drm/i915: Implement inter-engine read-read optimisations > > > > Signed-off-by: Chris Wilson > > Cc: Lionel Landwerlin > > Cc: Tvrtko Ursulin > > Cc: Daniel Vetter > > Cc: sta...@vger.kernel.org > > Commit message should explain what the actual problem is - we add 1 jiffy > of delay for each wait_request, potentially waiting quite a bit longer > than what userspace asked for. > > And not sure this really justifies for cc: stable, since all the wait > syscalls reserve the right to wait longer. Of course we should fix it, > just to keep validating this possible. Dropping stable is fine, that was just a knee jerk reaction to finding a regression. The impact is 1 jiffie for each extra active ring for a wait_ioctl with a timeout -- I don't think anyone has noticed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature
Hi, On 25/11/15 14:44, Vinay Belgaumkar wrote: These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple of stress tests which copy buffers between CPU and GPU. These tests rely on the softpin patch in order to pin buffers to a certain VA. Caveat: These tests were designed to run on 64-bit system. Future work includes adding logic to ensure these tests can run on 32-bit systems with PPGTT support. Some tests are currently disabled for 32-bit systems for that reason. v2: Added cc and signed-off-by fields v3: Fixed review comments, added helper functions. Removed userptr error scenarios covered by existing userptr tests. Modified stress test to have 100K buffers, it now runs for ~30 mins, checks every element has been written to correctly, and pins buffers at different VMAs. v4: Changed name to gem_softpin v5: More fixes. Removed the file based tests, will move them to userptr tests. Added a function that validates appropriate PPGTT support before running tests. Optimized stack space and memory footprint in stress test. Removed the eviction test, will add it back after verifying proper functionality. Cc: Michel Thierry Cc: Tvrtko Ursulin Signed-off-by: Vinay Belgaumkar --- tests/.gitignore | 1 + tests/Makefile.sources | 1 + tests/gem_softpin.c| 972 + 3 files changed, 974 insertions(+) create mode 100644 tests/gem_softpin.c diff --git a/tests/.gitignore b/tests/.gitignore index 80af9a7..424870b 100644 --- a/tests/.gitignore +++ b/tests/.gitignore @@ -21,6 +21,7 @@ gem_bad_blit gem_bad_length gem_bad_reloc gem_basic +gem_softpin gem_caching gem_close_race gem_concurrent_all diff --git a/tests/Makefile.sources b/tests/Makefile.sources index 8fb2de8..2008d4a 100644 --- a/tests/Makefile.sources +++ b/tests/Makefile.sources @@ -11,6 +11,7 @@ TESTS_progs_M = \ drv_hangman \ gem_bad_reloc \ gem_basic \ + gem_softpin \ gem_caching \ gem_close_race \ gem_concurrent_blit \ diff --git a/tests/gem_softpin.c b/tests/gem_softpin.c new file mode 100644 index 000..95b664a --- /dev/null +++ b/tests/gem_softpin.c @@ -0,0 +1,972 @@ +/* + * Copyright © 2015 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. + * + * Authors: + *Vinay Belgaumkar + *Thomas Daniel + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include "drm.h" +#include "ioctl_wrappers.h" +#include "drmtest.h" +#include "intel_chipset.h" +#include "intel_io.h" +#include "i915_drm.h" +#include +#include +#include +#include +#include "igt_kms.h" +#include +#include +#include + +#define BO_SIZE 4096 +#define MULTIPAGE_BO_SIZE 2 * BO_SIZE +#define STORE_BATCH_BUFFER_SIZE 4 +#define EXEC_OBJECT_PINNED (1<<4) +#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3) +#define SHARED_BUFFER_SIZE 4096 +#define NUM_EXEC_OBJECTS 2 I would just hardcode 2 or 3 (or 1) in relevant places since some tests use NUM_EXEC_OBJECTS + 1 anyway so it is not so useful to have a define with a long name for this. + +typedef struct drm_i915_gem_userptr i915_gem_userptr; + +static uint32_t init_userptr(int fd, i915_gem_userptr*, void* ptr, + uint64_t size, bool read_only); i915_gem_userptr *, void *ptr +static void *create_mem_buffer(uint64_t size); +static int gem_call_userptr_ioctl(int fd, i915_gem_userptr *userptr); +static void gem_basic_test(void); +static void gem_pin_invalid_vma_test(void); +static void gem_pin_overlap_test(void); +static void gem_pin_high_address_test(void); + +#define NO_PPGTT 0 +#define ALIASING_PPGTT 1 +#define FULL_32_BIT_PPGTT 2 +#define FULL_48_BIT_PPGTT 3 +/* uses_full_ppgtt + * Finds sup
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
On Thu, 26 Nov 2015 16:58:09 +0100, Ville Syrjälä wrote: > > On Thu, Nov 26, 2015 at 04:51:04PM +0100, Takashi Iwai wrote: > > On Thu, 26 Nov 2015 16:43:23 +0100, > > Ville Syrjälä wrote: > > > > > > On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote: > > > > > > > > > > > > On 2015-11-26 16:23, Takashi Iwai wrote: > > > > > On Thu, 26 Nov 2015 16:08:06 +0100, > > > > > David Henningsson wrote: > > > > >> > > > > >> > > > > >> > > > > >> On 2015-11-26 10:24, Takashi Iwai wrote: > > > > >>> On Thu, 26 Nov 2015 10:16:17 +0100, > > > > >>> Zhang, Xiong Y wrote: > > > > > > > > > > > > > On Thu, 26 Nov 2015 08:57:30 +0100, > > > > > Zhang, Xiong Y wrote: > > > > >> > > > > > BTW, I have a patchset to avoid the audio h/w wakeup by a new > > > > > component ops to get ELD and connection states. It was > > > > > posted to > > > > > alsa-devel shortly ago just as a reference, but this should > > > > > work well > > > > > in such a case, too. The test patches are found in > > > > > test/hdmi-jack > > > > > branch of my sound git tree. > > > > >>> > > > > >>> Did you try this branch (merge onto intel-test-nightly)? > > > > >>> > > > > >> [Zhang, Xiong Y] Yes, this branch could fix my issue. > > > > > > > > > > OK, good to hear. But this isn't for 4.4 or backport, as it's > > > > > more > > > > > radical changes. > > > > > > > > > > Could you check the patch below instead? This suppresses the > > > > > notifier > > > > > handling during suspend. It's bad, but the hotplug should be > > > > > still > > > > > handled via normal unsol event, so it should keep working, good > > > > > enough > > > > > as a stop gap. > > > > > > > > > > > > > > > Takashi > > > > > > > > > > --- > > > > > diff --git a/sound/pci/hda/patch_hdmi.c > > > > > b/sound/pci/hda/patch_hdmi.c > > > > > index bdb6f226d006..f7c70e2ae65c 100644 > > > > > --- a/sound/pci/hda/patch_hdmi.c > > > > > +++ b/sound/pci/hda/patch_hdmi.c > > > > > @@ -33,6 +33,7 @@ > > > > >#include > > > > >#include > > > > >#include > > > > > +#include > > > > >#include > > > > >#include > > > > >#include > > > > > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void > > > > > *audio_ptr, int > > > > > port) > > > > > struct hda_codec *codec = audio_ptr; > > > > > int pin_nid = port + 0x04; > > > > > > > > > > - check_presence_and_report(codec, pin_nid); > > > > > + if (!atomic_read(&codec->core.in_pm) && > > > > > + !pm_runtime_suspended(hda_codec_dev(codec))) > > > > > + check_presence_and_report(codec, pin_nid); > > > > >} > > > > > > > > > >static int patch_generic_hdmi(struct hda_codec *codec) > > > > [Zhang, Xiong Y] this patch couldn't remove the error message. So > > > > audio controller isn't in Runtime D3 after azx_suspend(). > > > > >>> > > > > >>> OK, then the problem isn't about the HD-audio driver but rather i915 > > > > >>> driver. As already mentioned, i915 driver shouldn't issue > > > > >>> eld_notify > > > > >>> callback in the suspend code path. > > > > >> > > > > >> We don't have a complete drm log so I'm only speculating here; but > > > > >> the > > > > >> HDA log seems to indicate the power well is off when we try to talk > > > > >> to > > > > >> the HDA controller. That means either the i915 shut it down while we > > > > >> were holding a lock on it, or HDA tried to lock it and that didn't > > > > >> make > > > > >> it through; in which case the HDA side should handle an error from > > > > >> get_power more gracefully...? > > > > > > > > > > My understanding is that it's triggered *during* i915 suspend. Then > > > > > the path calls the HDA callback, and HDA controller tries to get power > > > > > and proceeds as it has no idea that it's being shut off. > > > > > > > > Well; that can also be stopped by letting the get_power call return a > > > > failure code in case i915 is trying to suspend itself. That seems more > > > > robust to me, as it could potentially avoid other S3 races too...? > > > > > > > > > > > > > > Unfortunately, neither get_power callback or the corresponding HDA > > > > > code has a capability to check that state. So, changing / fixing this > > > > > there would be nice but very hard. > > > > > > > > Surely the i915 driver has some "am_i_suspending" variable it can check > > > > in the get_power callback? > > > > > > I don't understand why you need to do anything special. When the eld > > > notify happens during suspend, the hardware is still fully powered up, > > > so it should just work(tm) as long as the eld_notify is a synchronous > > > call and it drops the power reference at the end. > > > > Hm, that's the question. It's nev
[Intel-gfx] [PATCH] drm/i915: Don't use crtc->config when reading out infoframe state
From: Ville Syrjälä
The .get_config() hooks should not reference anything in crtc->config,
everything should be based on the passed in pipe_config instead. So
don't dig out the cpu_transcoder from crtc->config on ddi platfforms,
and also avoid using the encoder->crtc link and instead look up the
pipe via pipe_config->base.crtc.
I don't think this will actually fix anything since during the initial
state readout we set up the encoder->crtc link prior to calling
.get_config(), and during the modeset state check the encoder->crtc
ought to be correct anyway since it's that state we just programmed.
But this seems the right thing to do anyway.
While at it, do some house cleaning on the local variables in the
.infoframe_enabled() hooks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_hdmi.c | 47 +++
3 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 76ce7c2960b6..7f618cf5289c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3151,7 +3151,7 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
pipe_config->has_hdmi_sink = true;
intel_hdmi = enc_to_intel_hdmi(&encoder->base);
- if (intel_hdmi->infoframe_enabled(&encoder->base))
+ if (intel_hdmi->infoframe_enabled(&encoder->base, pipe_config))
pipe_config->has_infoframe = true;
break;
case TRANS_DDI_MODE_SELECT_DVI:
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 6ef456427db5..b2e81403c494 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -711,7 +711,8 @@ struct intel_hdmi {
void (*set_infoframes)(struct drm_encoder *encoder,
bool enable,
const struct drm_display_mode *adjusted_mode);
- bool (*infoframe_enabled)(struct drm_encoder *encoder);
+ bool (*infoframe_enabled)(struct drm_encoder *encoder,
+ const struct intel_crtc_state *pipe_config);
};
struct intel_dp_mst_encoder;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index bdd462e7c690..c3978bad5ca0 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -169,10 +169,10 @@ static void g4x_write_infoframe(struct drm_encoder
*encoder,
POSTING_READ(VIDEO_DIP_CTL);
}
-static bool g4x_infoframe_enabled(struct drm_encoder *encoder)
+static bool g4x_infoframe_enabled(struct drm_encoder *encoder,
+ const struct intel_crtc_state *pipe_config)
{
- struct drm_device *dev = encoder->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
u32 val = I915_READ(VIDEO_DIP_CTL);
@@ -225,13 +225,13 @@ static void ibx_write_infoframe(struct drm_encoder
*encoder,
POSTING_READ(reg);
}
-static bool ibx_infoframe_enabled(struct drm_encoder *encoder)
+static bool ibx_infoframe_enabled(struct drm_encoder *encoder,
+ const struct intel_crtc_state *pipe_config)
{
- struct drm_device *dev = encoder->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
+ struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
- i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
+ enum pipe pipe = to_intel_crtc(pipe_config->base.crtc)->pipe;
+ i915_reg_t reg = TVIDEO_DIP_CTL(pipe);
u32 val = I915_READ(reg);
if ((val & VIDEO_DIP_ENABLE) == 0)
@@ -287,12 +287,12 @@ static void cpt_write_infoframe(struct drm_encoder
*encoder,
POSTING_READ(reg);
}
-static bool cpt_infoframe_enabled(struct drm_encoder *encoder)
+static bool cpt_infoframe_enabled(struct drm_encoder *encoder,
+ const struct intel_crtc_state *pipe_config)
{
- struct drm_device *dev = encoder->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
- u32 val = I915_READ(TVIDEO_DIP_CTL(intel_crtc->pipe));
+ struct drm_i915_private *dev_priv = to_i915(encoder->dev);
+ enum pipe pipe = to_intel_crtc(pipe_config->base.crtc)->pipe;
+ u32 val = I915_READ(TVIDEO_DIP_CTL(pipe));
if ((val & VIDEO_DIP_ENABLE) == 0)
return false;
@@ -341,13 +341,13 @@ static void vlv_write_infoframe(struct drm_encoder
*encoder,
POSTING
[Intel-gfx] [PATCH i-g-t] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)
Signed-off-by: Marius Vlad
---
tests/pm_rpm.c | 120 +
1 file changed, 120 insertions(+)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index c4fb19c..d34b2b2 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -1729,6 +1729,120 @@ static void planes_subtest(bool universal, bool dpms)
}
}
+static void pm_test_tiling(void)
+{
+ uint32_t *handles;
+ uint8_t **gem_bufs;
+
+ int max_gem_objs = 0;
+ uint8_t off_bit = 14;
+ uint32_t gtt_obj_max_size = (256 * 1024);
+
+ uint32_t i, j, p, tiling_modes[3] = {
+ I915_TILING_NONE,
+ I915_TILING_X,
+ I915_TILING_Y,
+ };
+ uint32_t ti, sw;
+
+ /* default stride value */
+ uint32_t stride = 512;
+
+ /* calculate how many objects we can map */
+ for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
+ ;
+
+ gem_bufs = calloc(max_gem_objs, sizeof(*gem_bufs));
+ handles = calloc(max_gem_objs, sizeof(*handles));
+
+ /* map to gtt */
+ for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+ handles[i] = gem_create(drm_fd, j);
+ gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
+ }
+
+ /* try to set different tiling for each handle */
+ for (i = 0; i < ARRAY_SIZE(tiling_modes); i++) {
+ disable_all_screens_and_wait(&ms_data);
+
+ for (j = 0, p = 1 << off_bit; j < max_gem_objs; j++, p <<= 1) {
+
+ /* modify the contents each time */
+ memset(gem_bufs[j], 16 << j, p);
+
+ igt_debug("Testing tiling mode %u, gem %u, "
+ "size=%ukB (d=0x%x)\n", i, j,
+ (p / (1 << 10)), (16 << j));
+
+ gem_set_tiling(drm_fd, handles[j],
+ tiling_modes[i], stride);
+
+ gem_get_tiling(drm_fd, handles[j], &ti, &sw);
+ igt_assert(tiling_modes[i] == ti);
+
+ }
+
+ enable_one_screen_and_wait(&ms_data);
+ }
+
+ for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
+ igt_assert(munmap(gem_bufs[i], j) == 0);
+ gem_close(drm_fd, handles[i]);
+ }
+
+ free(gem_bufs);
+ free(handles);
+}
+
+static void pm_test_caching(void)
+{
+ uint32_t handle;
+ uint8_t *gem_buf;
+
+ uint32_t i, got_caching;
+ uint32_t gtt_obj_max_size = (16 * 1024);
+ uint32_t cache_levels[3] = {
+ I915_CACHING_NONE,
+ I915_CACHING_CACHED,/* LLC caching */
+ I915_CACHING_DISPLAY, /* eDRAM caching */
+ };
+
+
+ handle = gem_create(drm_fd, gtt_obj_max_size);
+ gem_buf = gem_mmap__gtt(drm_fd, handle, gtt_obj_max_size, PROT_WRITE);
+
+ for (i = 0; i < ARRAY_SIZE(cache_levels); i++) {
+ memset(gem_buf, 16 << i, gtt_obj_max_size);
+
+ disable_all_screens_and_wait(&ms_data);
+
+ igt_debug("Setting cache level %u\n", cache_levels[i]);
+
+ gem_set_caching(drm_fd, handle, cache_levels[i]);
+
+ got_caching = gem_get_caching(drm_fd, handle);
+
+ igt_debug("Got back %u\n", got_caching);
+
+ /*
+* Allow fall-back to CACHING_NONE in case the platform does
+* not support it.
+*/
+ if (cache_levels[i] == I915_CACHING_DISPLAY)
+ igt_assert(got_caching == I915_CACHING_NONE ||
+ got_caching == I915_CACHING_DISPLAY);
+ else
+ igt_assert(got_caching == cache_levels[i]);
+
+ enable_one_screen_and_wait(&ms_data);
+ }
+
+ igt_assert(munmap(gem_buf, gtt_obj_max_size) == 0);
+ gem_close(drm_fd, handle);
+}
+
+
+
static void fences_subtest(bool dpms)
{
int i;
@@ -1927,6 +2041,12 @@ int main(int argc, char *argv[])
igt_subtest("gem-execbuf-stress-extra-wait")
gem_execbuf_stress_subtest(rounds, WAIT_STATUS | WAIT_EXTRA);
+ /* power-wake reference tests */
+ igt_subtest("pm-tiling")
+ pm_test_tiling();
+ igt_subtest("pm-caching")
+ pm_test_caching();
+
igt_fixture
teardown_environment();
--
2.6.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] scripts: Add feature list file for piglit 'summary feature'
On 25 November 2015 at 12:12, Gabriel Feceoru wrote:
> This is a placeholder for the feature list file. Its content is just
> an example.
It would be useful if the example applied directly to intel-gpu-tools
tests. Perhaps just a single feature to start with?
Since this isn't a script as such, would it be better placed in the
tests directory where the test list is generated?
It would probably be useful to integrate it with the run-tests.sh
script as well.
> This needs to be filled in by feature owners with the feature name
> and the corresponding tests regex.
>
> Please refer to this piglit commit for more info on this feature.
>
> commit f16d011db75b08ceae241e7370599146691340ab
> Author: Feceoru, Gabriel
> Date: Tue Nov 3 17:50:41 2015 +0200
>
> framework: Add support for feature readiness.
>
> Signed-off-by: Gabriel Feceoru
> ---
> scripts/feat_profile.json | 12
> 1 file changed, 12 insertions(+)
> create mode 100644 scripts/feat_profile.json
>
> diff --git a/scripts/feat_profile.json b/scripts/feat_profile.json
> new file mode 100644
> index 000..f3a21a3
> --- /dev/null
> +++ b/scripts/feat_profile.json
> @@ -0,0 +1,12 @@
> +{
> +"glsl" : {
> +"include_tests" : "glsl",
> +"exclude_tests" : "",
> +"target_rate" : 90
> +},
> +"arb" : {
> +"include_tests" : "ARB_shader|deqp.arb shader",
> +"exclude_tests" : "",
> +"target_rate" : 10
> +}
> +}
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] About dealing with CSB.context element switch in execlist mode.
On 25/11/15 13:17, Wang, Zhi A wrote: OK. I see. Thanks Michel! :) Have a nice day. :) Thanks, Zhi. -Original Message- From: Thierry, Michel Sent: Wednesday, November 25, 2015 9:15 PM To: Wang, Zhi A; intel-gfx@lists.freedesktop.org Cc: Han, Xu; Li, Weinan Z; He, Min; Lv, Zhiyuan; Tian, Kevin Subject: Re: [Intel-gfx] About dealing with CSB.context element switch in execlist mode. On 11/25/2015 1:00 PM, Wang, Zhi A wrote: Another question about EXECLIST is: Can a preemption happen between element switch? I know this is beyond the scope of i915 a little. I'm just curious if it's possible. Let's say we have context A B C At first, we submit context A B in one ELSP write. Then, we submit context C in another ELSP write at some time. If context A or B is running and gets preempted, then there will be CSB.preempted in CSB buffer. This is the normal behavior. I'm wondering that if there is any possibility that a preemption can happen between the two elements. Then the CSB should look like: [CSB 0 idle-to-active] [CSB 1 CTX A element_switch/context_complete] [CSB 2 CTX C active-to-idle/context_complete] Is it possible? I would expect to always have a preempted event in the CSB, even in the remote case that A already completed and B hasn't started; there was an active execlist and it has been replaced by a new one: [CSB 0 idle-to-active] [CSB 1 CTX A element_switch/context_complete] [CSB 2 preempted ] [CSB 3 CTX C active-to-idle/context_complete] ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx A few examples of CSB sequences you may see: CSB[1]: 0x000.0 / 0x0001 I->A CSB[2]: 0x201.018df / 0x0018 A->I DONE CSB[3]: 0x000.0 / 0x0001 I->A CSB[4]: 0x201.018df / 0x0018 A->I DONE CSB[5]: 0x000.0 / 0x0001 I->A CSB[0]: 0x201.018df / 0x0018 A->I DONE This is as simple as it gets. A single context is repeatedly submitted, and each time it completes before being resubmitted. CSB[3]: 0x000.0 / 0x0001 I->A CSB[4]: 0x601.018e6 / 0x8002 PRMTLITE CSB[5]: 0x601.018e6 / 0x0018 A->I DONE CSB[0]: 0x000.0 / 0x0001 I->A CSB[1]: 0x601.018e6 / 0x8002 PRMTLITE CSB[2]: 0x601.018e6 / 0x0018 A->I DONE Here again a single context is in use, but this time it was submitted, then updated and resubmitted while still executing (lite restore), then completed. This whole sequence repeats twice. CSB[4]: 0x001.02935 / 0x0018 A->I DONE CSB[5]: 0x000.0 / 0x0001 I->A CSB[0]: 0x001.02935 / 0x0018 A->I DONE CSB[1]: 0x000.0 / 0x0001 I->A CSB[2]: 0x001.02935 / 0x0002 PRMT CSB[3]: 0x001.02950 / 0x0018 A->I DONE This is a genuine preemption. We see context A (02935) being submitted and completed twice, but during the third execution is gets preempted. The last line shows the completion of context B (02950) that preempted context A. CSB[3]: 0x000.0 / 0x0001 I->A CSB[4]: 0x001.018ed / 0x0002 PRMT CSB[5]: 0x001.01908 / 0x0018 A->I DONE CSB[0]: 0x000.0 / 0x0001 I->A CSB[1]: 0x001.01908 / 0x0018 A->I DONE CSB[2]: 0x000.0 / 0x0001 I->A Here, context A (018ed) was started, then preempted by a higher-priority context B (01908), which got to run to completion twice before another context (presumably A) was (re)started. We infer that A (or whatever other context was most recently submitted) was still running at the instant when this trace was captured. The PRMT (without LITE) event always indicates the identity of the context that was preempted. In the case of preemption after a dual submission, it may be either the first or the second workload that gets preempted, but it must be one or the other (there's no "idle" window between finishing the first and starting the second in which preemption could occur). In addition, preemption is actually disabled while context restore is in progress, so if the ELSP is written after the GPU has committed to loading a context, the preemption won't happen until the load is completed. [This is subject to change, but this how it's set up on Skylake today]. HTH, .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix kerneldoc indent fails
On Thu, Nov 26, 2015 at 11:09:44AM +0100, Daniel Vetter wrote:
> On Wed, Nov 25, 2015 at 04:21:30PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: Daniel Vetter
Pushed to dinq. Thanks for the review.
>
> Aside: Build htmldocs results in a lot of complaints that many irq helpers
> here aren't included ... we should fix that to make it more likely the
> pretty kerneldoc gets noticed.
> -Daniel
>
>
> > ---
> > drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
> > drivers/gpu/drm/i915/i915_irq.c| 20 ++--
> > 2 files changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> > b/drivers/gpu/drm/i915/i915_guc_submission.c
> > index ed9f1002ab36..a057cbd78ecb 100644
> > --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> > @@ -677,7 +677,7 @@ static struct drm_i915_gem_object
> > *gem_allocate_guc_obj(struct drm_device *dev,
> > /**
> > * gem_release_guc_obj() - Release gem object allocated for GuC usage
> > * @obj: gem obj to be released
> > - */
> > + */
> > static void gem_release_guc_obj(struct drm_i915_gem_object *obj)
> > {
> > if (!obj)
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 13445655e6b8..70d443330919 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -288,11 +288,11 @@ static i915_reg_t gen6_pm_ier(struct drm_i915_private
> > *dev_priv)
> > }
> >
> > /**
> > - * snb_update_pm_irq - update GEN6_PMIMR
> > - * @dev_priv: driver private
> > - * @interrupt_mask: mask of interrupt bits to update
> > - * @enabled_irq_mask: mask of interrupt bits to enable
> > - */
> > + * snb_update_pm_irq - update GEN6_PMIMR
> > + * @dev_priv: driver private
> > + * @interrupt_mask: mask of interrupt bits to update
> > + * @enabled_irq_mask: mask of interrupt bits to enable
> > + */
> > static void snb_update_pm_irq(struct drm_i915_private *dev_priv,
> > uint32_t interrupt_mask,
> > uint32_t enabled_irq_mask)
> > @@ -406,11 +406,11 @@ void gen6_disable_rps_interrupts(struct drm_device
> > *dev)
> > }
> >
> > /**
> > - * bdw_update_port_irq - update DE port interrupt
> > - * @dev_priv: driver private
> > - * @interrupt_mask: mask of interrupt bits to update
> > - * @enabled_irq_mask: mask of interrupt bits to enable
> > - */
> > + * bdw_update_port_irq - update DE port interrupt
> > + * @dev_priv: driver private
> > + * @interrupt_mask: mask of interrupt bits to update
> > + * @enabled_irq_mask: mask of interrupt bits to enable
> > + */
> > static void bdw_update_port_irq(struct drm_i915_private *dev_priv,
> > uint32_t interrupt_mask,
> > uint32_t enabled_irq_mask)
> > --
> > 2.4.10
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Display irq enable/disable OCD
On Mon, Nov 23, 2015 at 06:06:14PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I spotted that we're duplicating the BDW+ pipe IMR frobbing a few
> places, so I figured I'd consolidate that. And while doing that I
> also cleaned up the ibx/ilk stuff a bit as well.
>
> Ville Syrjälä (3):
> drm/i915: Make ibx_{enable,disable}_display_interrupt() static inlines
> drm/i915: Make ironlake_{enable,disable}_display_irq() static inlines
> drm/i915: Introduce bdw_{update,enable,disable}_pipe_irq()
Series pushed to dinq. Thanks for the reviews.
>
> drivers/gpu/drm/i915/i915_drv.h| 46 +
> drivers/gpu/drm/i915/i915_irq.c| 65
> +++---
> drivers/gpu/drm/i915/intel_fifo_underrun.c | 16 +++-
> 3 files changed, 85 insertions(+), 42 deletions(-)
>
> --
> 2.4.10
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [iGVT-g] XenGT for PV guest
Hello all, Do you have any ideas about previously mentioned question? With best regards, Oleksii On Tue, Nov 24, 2015 at 6:48 PM, Oleksii Kurochko < oleksii.kuroc...@globallogic.com> wrote: > Hi all, > > I am trying to enable XenGT for Android on board vtc1010 in PV mode. > Used: > - Intel® Atom™ processor E3827 > - Xen 4.3.1 on branch "byt_experiment". > - dom0: ubuntu 14-04 with linux vgt 3.11.6-vgt+ kernel version > - domU: Android-IA 5.1 with 3.11.6-vgt+ (added Android configs) kernel > version > > vgt was successfully started in dom0. > vgt does not start in domU. After registration of pci dev in i915_init() > there is no call of i915_pci_driver.probe(). Inte HD Graphics is on pci > bus, but it is not passthrough to domU. When tried to passtrough it to domU > than dom0 crashes in drm_framebuffer_remove(). More than that it is not my > case because of intel hd graphics need to be working in dom0 and domU. > > So could U give advice how to probe i915 driver in domU? > > With best, > Oleksii > > > -- > Oleksii Kurochko | Embedded Dev > GlobalLogic > www.globallogic.com > -- Oleksii Kurochko | Embedded Dev GlobalLogic www.globallogic.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't need a timer to wake us up
From: Tvrtko Ursulin
Looks like the sleeping loop in __i915_wait_request can be
simplified by using io_schedule_timeout instead of setting
up and destroying a timer.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 33adc8f8ab20..efb3eb8b4a5e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1135,11 +1135,6 @@ i915_gem_check_wedge(struct i915_gpu_error *error,
return 0;
}
-static void fake_irq(unsigned long data)
-{
- wake_up_process((struct task_struct *)data);
-}
-
static bool missed_irq(struct drm_i915_private *dev_priv,
struct intel_engine_cs *ring)
{
@@ -1231,7 +1226,7 @@ int __i915_wait_request(struct drm_i915_gem_request *req,
}
for (;;) {
- struct timer_list timer;
+ long sched_timeout;
prepare_to_wait(&ring->irq_queue, &wait,
interruptible ? TASK_INTERRUPTIBLE :
TASK_UNINTERRUPTIBLE);
@@ -1262,21 +1257,14 @@ int __i915_wait_request(struct drm_i915_gem_request
*req,
break;
}
- timer.function = NULL;
- if (timeout || missed_irq(dev_priv, ring)) {
- unsigned long expire;
-
- setup_timer_on_stack(&timer, fake_irq, (unsigned
long)current);
- expire = missed_irq(dev_priv, ring) ? jiffies + 1 :
timeout_expire;
- mod_timer(&timer, expire);
- }
-
- io_schedule();
+ if (timeout)
+ sched_timeout = timeout_expire - jiffies;
+ else if (missed_irq(dev_priv, ring))
+ sched_timeout = 1;
+ else
+ sched_timeout = MAX_SCHEDULE_TIMEOUT;
- if (timer.function) {
- del_singleshot_timer_sync(&timer);
- destroy_timer_on_stack(&timer);
- }
+ io_schedule_timeout(sched_timeout);
}
if (!irq_test_in_progress)
ring->irq_put(ring);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Fix uninitialized variables in intel_check_sprite_plane
On 11/18/2015 10:56 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 10:33:55PM +0530, Maiti, Nabendu Bikash wrote:
On 11/18/2015 7:00 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 06:48:37PM +0530, Maiti, Nabendu Bikash wrote:
On 11/18/2015 6:22 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 12:19:06PM +, Chris Wilson wrote:
On Wed, Nov 18, 2015 at 05:43:52PM +0530, Nabendu Maiti wrote:
Uninitialized variables (width, Height) in intel_check_sprite_plane
leads to compilererror in O1 level. Initialize all declared variables
to fix this issue.
Signed-off-by: Nabendu Maiti
Or perhaps:
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2b96f336589e..8d7b4eb5b5b9 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -747,7 +747,6 @@ intel_check_sprite_plane(struct drm_plane *plane,
struct drm_framebuffer *fb = state->base.fb;
int crtc_x, crtc_y;
unsigned int crtc_w, crtc_h;
- uint32_t src_x, src_y, src_w, src_h;
struct drm_rect *src = &state->src;
struct drm_rect *dst = &state->dst;
const struct drm_rect *clip = &state->clip;
@@ -813,6 +812,8 @@ intel_check_sprite_plane(struct drm_plane *plane,
crtc_h = drm_rect_height(dst);
if (state->visible) {
+ u32 src_x, src_y, src_w, src_h;
+
/* check again in case clipping clamped the results */
hscale = drm_rect_calc_hscale(src, dst, min_scale,
max_scale);
if (hscale < 0) {
@@ -871,10 +872,9 @@ intel_check_sprite_plane(struct drm_plane *plane,
if (crtc_w == 0)
state->visible = false;
}
- }
/* Check size restrictions when scaling */
- if (state->visible && (src_w != crtc_w || src_h != crtc_h)) {
+ if (src_w != crtc_w || src_h != crtc_h) {
That would change what it does.
yes, checked the code where inside each if condition loop we may be
changing the state->visible var itself. Next condition check it may be
false too.
The place giving compiler error
src->x1 = src_x << 16;
src->x2 = (src_x + src_w) << 16;
src->y1 = src_y << 16;
src->y2 = (src_y + src_h) << 16;
Then just one line change of initializing the variables is better?
Or maybe fix your compiler instead? I don't get any warning/errors from
this. What version of gcc are you using?
I still get the warning and error if -Werror is enabled, And on
Makefile O1 optimization is enabled.
And why exactly are you building with -O1?
I am using it for platform level debug symbol inclusion in elf which are
excluded in Os/O2 . We need it.Else it will break generic kernel.
(note on Android build by default
Werror is enabled and gcc-- GCC: (GNU) 4.9.2
)
on generic build, gcc --gcc (Ubuntu 4.9.3-5ubuntu1~14.04) 4.9.3
following are the error..
CC drivers/staging/android/timed_gpio.o
/home/nbikash/PROJ_CODEBASE/MDsrt_WW44.2/kernel/bxt/drivers/gpu/drm/i915/intel_sprite.c:
In function 'intel_check_sprite_plane':
/home/nbikash/PROJ_CODEBASE/MDsrt_WW44.2/kernel/bxt/drivers/gpu/drm/i915/intel_sprite.c:1241:20:
error: 'src_h' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
src->y2 = (src_y + src_h) << 16;
^
/home/nbikash/PROJ_CODEBASE/MDsrt_WW44.2/kernel/bxt/drivers/gpu/drm/i915/intel_sprite.c:1239:20:
error: 'src_w' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
src->x2 = (src_x + src_w) << 16;
^
/home/nbikash/PROJ_CODEBASE/MDsrt_WW44.2/kernel/bxt/drivers/gpu/drm/i915/intel_sprite.c:1241:20:
error: 'src_y' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
src->y2 = (src_y + src_h) << 16;
^
/home/nbikash/PROJ_CODEBASE/MDsrt_WW44.2/kernel/bxt/drivers/gpu/drm/i915/intel_sprite.c:1238:19:
error: 'src_x' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
src->x1 = src_x << 16;
unsigned int width_bytes;
WARN_ON(!can_scale);
@@ -898,7 +898,6 @@ intel_check_sprite_plane(struct drm_plane *plane,
}
}
- if (state->visible) {
src->x1 = src_x << 16;
src->x2 = (src_x + src_w) << 16;
src->y1 = src_y << 16;
And make both the compiler and reader happier
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mai
Re: [Intel-gfx] [PATCH] drm/i915: Don't need a timer to wake us up
On Thu, Nov 26, 2015 at 05:15:46PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Looks like the sleeping loop in __i915_wait_request can be > simplified by using io_schedule_timeout instead of setting > up and destroying a timer. Simplified by duplicating code? I liked the explicit handling for its obviousness and simplicity. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add BXT Sprite plane fractional scalings
On 11/18/2015 06:49 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 06:37:17PM +0530, Maiti, Nabendu Bikash wrote:
On 11/18/2015 5:41 PM, Ville Syrjälä wrote:
On Wed, Nov 18, 2015 at 05:13:01PM +0530, Nabendu Maiti wrote:
On older platforms scalers/cliping used to provide destination size an
exact multiple of src size.
Gen-9 and above support fractional ratio of dst/src so that source is
not manipulated to meet the exact multiple factor.
Signed-off-by: Nabendu Maiti
---
drivers/gpu/drm/i915/intel_sprite.c | 48
+
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2b96f33..e8c17ae 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -813,29 +813,37 @@ intel_check_sprite_plane(struct drm_plane *plane,
crtc_h = drm_rect_height(dst);
if (state->visible) {
- /* check again in case clipping clamped the results */
- hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
- if (hscale < 0) {
- DRM_DEBUG_KMS("Horizontal scaling factor out of
limits\n");
- drm_rect_debug_print("src: ", src, true);
- drm_rect_debug_print("dst: ", dst, false);
-
- return hscale;
- }
- vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
- if (vscale < 0) {
- DRM_DEBUG_KMS("Vertical scaling factor out of
limits\n");
- drm_rect_debug_print("src: ", src, true);
- drm_rect_debug_print("dst: ", dst, false);
+ /* Gen 9 and above has fractional scaling support */
+ if (INTEL_INFO(plane->dev)->gen < 9) {
- return vscale;
- }
+ /* check again in case clipping clamped the results */
+ hscale = drm_rect_calc_hscale(src, dst, min_scale,
max_scale);
+ if (hscale < 0) {
+ DRM_DEBUG_KMS("Horizontal scaling factor out of
limits\n");
+ drm_rect_debug_print("src: ", src, true);
+ drm_rect_debug_print("dst: ", dst, false);
+
+ return hscale;
+ }
+
+ vscale = drm_rect_calc_vscale(src, dst, min_scale,
max_scale);
+ if (vscale < 0) {
+ DRM_DEBUG_KMS("Vertical scaling factor out of
limits\n");
+ drm_rect_debug_print("src: ", src, true);
+ drm_rect_debug_print("dst: ", dst, false);
- /* Make the source viewport size an exact multiple of the scaling factors. */
- drm_rect_adjust_size(src,
-drm_rect_width(dst) * hscale -
drm_rect_width(src),
-drm_rect_height(dst) * vscale -
drm_rect_height(src));
+ return vscale;
+ }
+
+ /*
+* Make the source viewport size an exact
+* multiple of the scaling factors.
+*/
+ drm_rect_adjust_size(src,
+drm_rect_width(dst) * hscale -
drm_rect_width(src),
+drm_rect_height(dst) * vscale -
drm_rect_height(src));
+ }
NAK. This code just makes sure the actual scaling ratio matches what we
calculated. As in there may have been some amount of rounding involved
etc.
The part you actually want to change is what comes after this where we
throw away the fractional part of the coordinates. And then you need to
change the actual hw programming so that we actually feed the sub-pixel
coordinates to the hardware.
In line
drm_rect_adjust_size(src,
+drm_rect_width(dst) * hscale -
drm_rect_width(src),
+drm_rect_height(dst) * vscale -
drm_rect_height(src));
I think we throw away the fractional part,
No, we don't.
It get changed for example src size 400x596 to destination 1055x700.
then i.e. u32/int hscale = (src * 0x1)/dst = 0x190/0x41f =
26214400/1055= 24847 (actually 24847.772511848)
so in next line it get modified .
drm_rect_adjust_size(src,
+drm_rect_width(dst) * hscale -
drm_rect_width(src),
+drm_rect_height(dst) * vscale -
drm_rect_height(src)); ,
Src width become 399, which is used for further calculation & commiting.
following logs also shows same result
[ 144.749628] [drm:intel_check_sprite_plane] NBM T00: src- x1:y1-> 0:0
x2:y2->26214400:39059456
Re: [Intel-gfx] [PATCH] drm/i915: Don't need a timer to wake us up
On Thu, Nov 26, 2015 at 05:55:39PM +, Chris Wilson wrote: > On Thu, Nov 26, 2015 at 05:15:46PM +, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > Looks like the sleeping loop in __i915_wait_request can be > > simplified by using io_schedule_timeout instead of setting > > up and destroying a timer. > > Simplified by duplicating code? I liked the explicit handling for its > obviousness and simplicity. To be slightl more gracious, after we eliminate the irq handling from this function, the waiter does look like this, albeit I still think it is cleaner to keep the timeout handling distinct from the indefinite waits. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/pm_rpm tests for set_caching and set_tiling ioctl(s)
On to, 2015-11-26 at 18:32 +0200, Marius Vlad wrote:
> Signed-off-by: Marius Vlad
> ---
> tests/pm_rpm.c | 120
> +
> 1 file changed, 120 insertions(+)
>
> diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
> index c4fb19c..d34b2b2 100644
> --- a/tests/pm_rpm.c
> +++ b/tests/pm_rpm.c
> @@ -1729,6 +1729,120 @@ static void planes_subtest(bool universal, bool dpms)
> }
> }
>
> +static void pm_test_tiling(void)
> +{
> + uint32_t *handles;
> + uint8_t **gem_bufs;
> +
> + int max_gem_objs = 0;
> + uint8_t off_bit = 14;
> + uint32_t gtt_obj_max_size = (256 * 1024);
> +
> + uint32_t i, j, p, tiling_modes[3] = {
> + I915_TILING_NONE,
> + I915_TILING_X,
> + I915_TILING_Y,
> + };
> + uint32_t ti, sw;
> +
> + /* default stride value */
> + uint32_t stride = 512;
> +
> + /* calculate how many objects we can map */
> + for (j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, max_gem_objs++)
> + ;
> +
> + gem_bufs = calloc(max_gem_objs, sizeof(*gem_bufs));
> + handles = calloc(max_gem_objs, sizeof(*handles));
> +
> + /* map to gtt */
> + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
> + handles[i] = gem_create(drm_fd, j);
> + gem_bufs[i] = gem_mmap__gtt(drm_fd, handles[i], j, PROT_WRITE);
> + }
> +
> + /* try to set different tiling for each handle */
> + for (i = 0; i < ARRAY_SIZE(tiling_modes); i++) {
This still has the problem that we don't rebind the objects in each
iteration before disable_all_screens_and_wait(). So please move the
above "map to gtt" loop allocating and mmaping the objects and the
memset(gem_bufs[]) below here, and ..
> + disable_all_screens_and_wait(&ms_data);
> +
> + for (j = 0, p = 1 << off_bit; j < max_gem_objs; j++, p <<= 1) {
> +
> + /* modify the contents each time */
> + memset(gem_bufs[j], 16 << j, p);
> +
> + igt_debug("Testing tiling mode %u, gem %u, "
> + "size=%ukB (d=0x%x)\n", i, j,
> + (p / (1 << 10)), (16 << j));
> +
> + gem_set_tiling(drm_fd, handles[j],
> + tiling_modes[i], stride);
> +
> + gem_get_tiling(drm_fd, handles[j], &ti, &sw);
> + igt_assert(tiling_modes[i] == ti);
> +
> + }
> +
> + enable_one_screen_and_wait(&ms_data);
move the loop below doing the munmap() and gem_close() on the objects
here. With that fixed this looks ok to me:
Reviewed-by: Imre Deak
> + }
> +
> + for (i = 0, j = 1 << off_bit; j <= gtt_obj_max_size; j <<= 1, i++) {
> + igt_assert(munmap(gem_bufs[i], j) == 0);
> + gem_close(drm_fd, handles[i]);
> + }
> +
> + free(gem_bufs);
> + free(handles);
> +}
> +
> +static void pm_test_caching(void)
> +{
> + uint32_t handle;
> + uint8_t *gem_buf;
> +
> + uint32_t i, got_caching;
> + uint32_t gtt_obj_max_size = (16 * 1024);
> + uint32_t cache_levels[3] = {
> + I915_CACHING_NONE,
> + I915_CACHING_CACHED,/* LLC caching */
> + I915_CACHING_DISPLAY, /* eDRAM caching */
> + };
> +
> +
> + handle = gem_create(drm_fd, gtt_obj_max_size);
> + gem_buf = gem_mmap__gtt(drm_fd, handle, gtt_obj_max_size, PROT_WRITE);
> +
> + for (i = 0; i < ARRAY_SIZE(cache_levels); i++) {
> + memset(gem_buf, 16 << i, gtt_obj_max_size);
> +
> + disable_all_screens_and_wait(&ms_data);
> +
> + igt_debug("Setting cache level %u\n", cache_levels[i]);
> +
> + gem_set_caching(drm_fd, handle, cache_levels[i]);
> +
> + got_caching = gem_get_caching(drm_fd, handle);
> +
> + igt_debug("Got back %u\n", got_caching);
> +
> + /*
> + * Allow fall-back to CACHING_NONE in case the platform does
> + * not support it.
> + */
> + if (cache_levels[i] == I915_CACHING_DISPLAY)
> + igt_assert(got_caching == I915_CACHING_NONE ||
> + got_caching == I915_CACHING_DISPLAY);
> + else
> + igt_assert(got_caching == cache_levels[i]);
> +
> + enable_one_screen_and_wait(&ms_data);
> + }
> +
> + igt_assert(munmap(gem_buf, gtt_obj_max_size) == 0);
> + gem_close(drm_fd, handle);
> +}
> +
> +
> +
> static void fences_subtest(bool dpms)
> {
> int i;
> @@ -1927,6 +2041,12 @@ int main(int argc, char *argv[])
> igt_subtest("gem-execbuf-stress-extra-wait")
> gem_execbuf_stress_subtest(rounds, WAIT_STATUS | WAIT_EXTRA);
>
> + /* power-wake reference tests */
> + igt_subtest("pm-tiling")
> + pm_test_tiling();
> + igt_subte
[Intel-gfx] [PATCH] drm/i915/guc: Correct spelling error of a define
s/prempt/preempt Cc: Alex Dai Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/intel_guc_fwif.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h index 40b2ea5..11298af 100644 --- a/drivers/gpu/drm/i915/intel_guc_fwif.h +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h @@ -108,7 +108,7 @@ #define GUC_CTL_DISABLE_SCHEDULER(1 << 4) #define GUC_CTL_PREEMPTION_LOG (1 << 5) #define GUC_CTL_ENABLE_SLPC (1 << 7) -#define GUC_CTL_RESET_ON_PREMPT_FAILURE (1 << 8) +#define GUC_CTL_RESET_ON_PREEMPT_FAILURE (1 << 8) #define GUC_CTL_DEBUG 8 #define GUC_LOG_VERBOSITY_SHIFT 0 #define GUC_LOG_VERBOSITY_LOW(0 << GUC_LOG_VERBOSITY_SHIFT) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Correcting proper src & dst height - width comparision for 90/270 rotation.
On 11/18/2015 05:44 PM, Ville Syrjälä wrote: On Wed, Nov 18, 2015 at 05:19:26PM +0530, Nabendu Maiti wrote: On 90/270 rotation case source width and height was not compared properly with destination height and width check plane.Which added erroneous check while doing scaling or normal 90/270 rotation. Signed-off-by: Nabendu Maiti --- drivers/gpu/drm/i915/intel_display.c | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 688d484..cd5bb28 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -13723,6 +13723,9 @@ intel_check_primary_plane(struct drm_plane *plane, int min_scale = DRM_PLANE_HELPER_NO_SCALING; int max_scale = DRM_PLANE_HELPER_NO_SCALING; bool can_position = false; + struct drm_rect *src = &state->src; + struct drm_rect *dest = &state->dst; + int ret = -1; /* use scaler when colorkey is not required */ if (INTEL_INFO(plane->dev)->gen >= 9 && @@ -13732,11 +13735,26 @@ intel_check_primary_plane(struct drm_plane *plane, can_position = true; } - return drm_plane_helper_check_update(plane, crtc, fb, &state->src, -&state->dst, &state->clip, + /* +* FIXME the following code does a bunch of fuzzy adjustments to the +* coordinates and sizes for rotations. We probably need some way to +* decide whether more strict checking should be done instead. +*/ + if (fb) + drm_rect_rotate(src, fb->width << 16, fb->height << 16, + state->base.rotation); + + ret = drm_plane_helper_check_update(plane, crtc, fb, src, +dest, &state->clip, min_scale, max_scale, can_position, true, &state->visible); + + /* Restore the originl unrotated co-ordinates */ + if (fb) + drm_rect_rotate_inv(src, fb->width << 16, fb->height << 16, + state->base.rotation); We should put the rotation handling into helper. And someone should really just move all the good code from intel_sprite into the helper instead of having two totally different ways of doing things. Yes right.I learned that there is an effort going on unification of primary and sprite plane. To put this in helper function is a bigger modifications . In the meantime in android we need this fix. So if you suggest I will hold the patch until the unification completes anf float it once again if required. + return ret; } static void -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add BXT Sprite plane fractional scalings
On Thu, Nov 26, 2015 at 11:49:43PM +0530, Nabendu Maiti wrote:
>
>
> On 11/18/2015 06:49 PM, Ville Syrjälä wrote:
> > On Wed, Nov 18, 2015 at 06:37:17PM +0530, Maiti, Nabendu Bikash wrote:
> >>
> >> On 11/18/2015 5:41 PM, Ville Syrjälä wrote:
> >>> On Wed, Nov 18, 2015 at 05:13:01PM +0530, Nabendu Maiti wrote:
> On older platforms scalers/cliping used to provide destination size an
> exact multiple of src size.
> Gen-9 and above support fractional ratio of dst/src so that source is
> not manipulated to meet the exact multiple factor.
>
> Signed-off-by: Nabendu Maiti
> ---
> drivers/gpu/drm/i915/intel_sprite.c | 48
> +
> 1 file changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 2b96f33..e8c17ae 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -813,29 +813,37 @@ intel_check_sprite_plane(struct drm_plane *plane,
> crtc_h = drm_rect_height(dst);
>
> if (state->visible) {
> -/* check again in case clipping clamped the results */
> -hscale = drm_rect_calc_hscale(src, dst, min_scale,
> max_scale);
> -if (hscale < 0) {
> -DRM_DEBUG_KMS("Horizontal scaling factor out of
> limits\n");
> -drm_rect_debug_print("src: ", src, true);
> -drm_rect_debug_print("dst: ", dst, false);
> -
> -return hscale;
> -}
>
> -vscale = drm_rect_calc_vscale(src, dst, min_scale,
> max_scale);
> -if (vscale < 0) {
> -DRM_DEBUG_KMS("Vertical scaling factor out of
> limits\n");
> -drm_rect_debug_print("src: ", src, true);
> -drm_rect_debug_print("dst: ", dst, false);
> +/* Gen 9 and above has fractional scaling support */
> +if (INTEL_INFO(plane->dev)->gen < 9) {
>
> -return vscale;
> -}
> +/* check again in case clipping clamped the
> results */
> +hscale = drm_rect_calc_hscale(src, dst,
> min_scale, max_scale);
> +if (hscale < 0) {
> +DRM_DEBUG_KMS("Horizontal scaling
> factor out of limits\n");
> +drm_rect_debug_print("src: ", src,
> true);
> +drm_rect_debug_print("dst: ", dst,
> false);
> +
> +return hscale;
> +}
> +
> +vscale = drm_rect_calc_vscale(src, dst,
> min_scale, max_scale);
> +if (vscale < 0) {
> +DRM_DEBUG_KMS("Vertical scaling factor
> out of limits\n");
> +drm_rect_debug_print("src: ", src,
> true);
> +drm_rect_debug_print("dst: ", dst,
> false);
>
> -/* Make the source viewport size an exact multiple of
> the scaling factors. */
> -drm_rect_adjust_size(src,
> - drm_rect_width(dst) * hscale -
> drm_rect_width(src),
> - drm_rect_height(dst) * vscale -
> drm_rect_height(src));
> +return vscale;
> +}
> +
> +/*
> + * Make the source viewport size an exact
> + * multiple of the scaling factors.
> + */
> +drm_rect_adjust_size(src,
> + drm_rect_width(dst) *
> hscale - drm_rect_width(src),
> + drm_rect_height(dst) *
> vscale - drm_rect_height(src));
> +}
> >>> NAK. This code just makes sure the actual scaling ratio matches what we
> >>> calculated. As in there may have been some amount of rounding involved
> >>> etc.
> >>>
> >>> The part you actually want to change is what comes after this where we
> >>> throw away the fractional part of the coordinates. And then you need to
> >>> change the actual hw programming so that we actually feed the sub-pixel
> >>> coordinates to the hardware.
> >> In line
> >>
> >> drm_rect_adjust_size(src,
> >> + drm_rect_width
Re: [Intel-gfx] [PATCH] drm/i915: Add BXT Sprite plane fractional scalings
On Thu, Nov 26, 2015 at 08:33:42PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 26, 2015 at 11:49:43PM +0530, Nabendu Maiti wrote:
> >
> >
> > On 11/18/2015 06:49 PM, Ville Syrjälä wrote:
> > > On Wed, Nov 18, 2015 at 06:37:17PM +0530, Maiti, Nabendu Bikash wrote:
> > >>
> > >> On 11/18/2015 5:41 PM, Ville Syrjälä wrote:
> > >>> On Wed, Nov 18, 2015 at 05:13:01PM +0530, Nabendu Maiti wrote:
> > On older platforms scalers/cliping used to provide destination size an
> > exact multiple of src size.
> > Gen-9 and above support fractional ratio of dst/src so that source is
> > not manipulated to meet the exact multiple factor.
> >
> > Signed-off-by: Nabendu Maiti
> > ---
> > drivers/gpu/drm/i915/intel_sprite.c | 48
> > +
> > 1 file changed, 28 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 2b96f33..e8c17ae 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -813,29 +813,37 @@ intel_check_sprite_plane(struct drm_plane *plane,
> > crtc_h = drm_rect_height(dst);
> >
> > if (state->visible) {
> > - /* check again in case clipping clamped the results */
> > - hscale = drm_rect_calc_hscale(src, dst, min_scale,
> > max_scale);
> > - if (hscale < 0) {
> > - DRM_DEBUG_KMS("Horizontal scaling factor out of
> > limits\n");
> > - drm_rect_debug_print("src: ", src, true);
> > - drm_rect_debug_print("dst: ", dst, false);
> > -
> > - return hscale;
> > - }
> >
> > - vscale = drm_rect_calc_vscale(src, dst, min_scale,
> > max_scale);
> > - if (vscale < 0) {
> > - DRM_DEBUG_KMS("Vertical scaling factor out of
> > limits\n");
> > - drm_rect_debug_print("src: ", src, true);
> > - drm_rect_debug_print("dst: ", dst, false);
> > + /* Gen 9 and above has fractional scaling support */
> > + if (INTEL_INFO(plane->dev)->gen < 9) {
> >
> > - return vscale;
> > - }
> > + /* check again in case clipping clamped the
> > results */
> > + hscale = drm_rect_calc_hscale(src, dst,
> > min_scale, max_scale);
> > + if (hscale < 0) {
> > + DRM_DEBUG_KMS("Horizontal scaling
> > factor out of limits\n");
> > + drm_rect_debug_print("src: ", src,
> > true);
> > + drm_rect_debug_print("dst: ", dst,
> > false);
> > +
> > + return hscale;
> > + }
> > +
> > + vscale = drm_rect_calc_vscale(src, dst,
> > min_scale, max_scale);
> > + if (vscale < 0) {
> > + DRM_DEBUG_KMS("Vertical scaling factor
> > out of limits\n");
> > + drm_rect_debug_print("src: ", src,
> > true);
> > + drm_rect_debug_print("dst: ", dst,
> > false);
> >
> > - /* Make the source viewport size an exact multiple of
> > the scaling factors. */
> > - drm_rect_adjust_size(src,
> > - drm_rect_width(dst) * hscale -
> > drm_rect_width(src),
> > - drm_rect_height(dst) * vscale -
> > drm_rect_height(src));
> > + return vscale;
> > + }
> > +
> > + /*
> > + * Make the source viewport size an exact
> > + * multiple of the scaling factors.
> > + */
> > + drm_rect_adjust_size(src,
> > + drm_rect_width(dst) *
> > hscale - drm_rect_width(src),
> > + drm_rect_height(dst) *
> > vscale - drm_rect_height(src));
> > + }
> > >>> NAK. This code just makes sure the actual scaling ratio matches what we
> > >>> calculated. As in there may have been some amount of rounding involved
> > >>> etc.
> > >>>
> > >>> The part you actually want to change is what comes after this where we
> > >>> throw away the fractional part of the coordinates. And then you need to
> > >>> change the actual hw programming so
[Intel-gfx] [PATCH 1/2] drm/i915: Add HAS_PCH_LPT_H()
From: Ville Syrjälä
We have HAS_PCH_LPT_LP() already, so add HAS_PCH_LPT_H() and use it
where appropriate.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915/intel_dp.c| 2 +-
drivers/gpu/drm/i915/intel_panel.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bc865e234df2..9ab3e25ddf38 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2615,6 +2615,7 @@ struct drm_i915_cmd_table {
#define HAS_PCH_SPT(dev) (INTEL_PCH_TYPE(dev) == PCH_SPT)
#define HAS_PCH_LPT(dev) (INTEL_PCH_TYPE(dev) == PCH_LPT)
#define HAS_PCH_LPT_LP(dev) (__I915__(dev)->pch_id ==
INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
+#define HAS_PCH_LPT_H(dev) (__I915__(dev)->pch_id ==
INTEL_PCH_LPT_DEVICE_ID_TYPE)
#define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
#define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 634dba423ae9..644e2fc9c67d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -711,7 +711,7 @@ static uint32_t hsw_get_aux_clock_divider(struct intel_dp
*intel_dp, int index)
if (index)
return 0;
return DIV_ROUND_CLOSEST(dev_priv->cdclk_freq, 2000);
- } else if (dev_priv->pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
+ } else if (HAS_PCH_LPT_H(dev_priv)) {
/* Workaround for non-ULT HSW */
switch (index) {
case 0: return 63;
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index a24df35e11e7..d4c81df318b6 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -1300,7 +1300,7 @@ static u32 lpt_hz_to_pwm(struct intel_connector
*connector, u32 pwm_freq_hz)
else
mul = 128;
- if (dev_priv->pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE)
+ if (HAS_PCH_LPT_H(dev_priv))
clock = MHz(135); /* LPT:H */
else
clock = MHz(24); /* LPT:LP */
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: Ignore transcoder B/C on LPT/WPT FIFO underrun handling
From: Ville Syrjälä
LPT/WPT only have transcoder A, so we shouldn't look at FIFO underruns
for transocoder B/C. And more importnatnly we should not consider
the state of underrun reporting for transcoders B/C when checking
whether we can enable the south error interrupt.
The whole thing is a bit of mess since we store the underrun reporting
state for transcoder A under intel_crtc for pipe A, irrespective of
which pipe may actually be driving the transcoder. But I figured trying
to change that would result in more churn.
Caveat: Still untested
v2: Use HAS_PCH_LPT_H instead of HAS_DDI
Use cpt_check_pch_fifo_underruns() on LPT-H/WPT-H too
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_fifo_underrun.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fifo_underrun.c
b/drivers/gpu/drm/i915/intel_fifo_underrun.c
index bda526660e20..3d3acc8b8367 100644
--- a/drivers/gpu/drm/i915/intel_fifo_underrun.c
+++ b/drivers/gpu/drm/i915/intel_fifo_underrun.c
@@ -48,6 +48,14 @@
* The code also supports underrun detection on the PCH transcoder.
*/
+static bool cpt_transcoder_exists(struct drm_i915_private *dev_priv,
+ enum transcoder pch_transcoder)
+{
+ /* LPT-H/WPT-H have only transcoder A */
+ return HAS_PCH_CPT(dev_priv) ||
+ (HAS_PCH_LPT_H(dev_priv) && pch_transcoder == TRANSCODER_A);
+}
+
static bool ivb_can_enable_err_int(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -69,13 +77,16 @@ static bool ivb_can_enable_err_int(struct drm_device *dev)
static bool cpt_can_enable_serr_int(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- enum pipe pipe;
- struct intel_crtc *crtc;
+ enum transcoder pch_transcoder;
assert_spin_locked(&dev_priv->irq_lock);
- for_each_pipe(dev_priv, pipe) {
- crtc = to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
+ for_each_pipe(dev_priv, pch_transcoder) {
+ struct intel_crtc *crtc =
+
to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pch_transcoder]);
+
+ if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
+ continue;
if (crtc->pch_fifo_underrun_disabled)
return false;
@@ -206,6 +217,9 @@ static void cpt_check_pch_fifo_underruns(struct intel_crtc
*crtc)
assert_spin_locked(&dev_priv->irq_lock);
+ if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
+ return;
+
if ((serr_int & SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder)) == 0)
return;
@@ -222,6 +236,9 @@ static void cpt_set_fifo_underrun_reporting(struct
drm_device *dev,
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ if (!cpt_transcoder_exists(dev_priv, pch_transcoder))
+ return;
+
if (enable) {
I915_WRITE(SERR_INT,
SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
@@ -436,7 +453,7 @@ void intel_check_pch_fifo_underruns(struct drm_i915_private
*dev_priv)
if (crtc->pch_fifo_underrun_disabled)
continue;
- if (HAS_PCH_CPT(dev_priv))
+ if (HAS_PCH_CPT(dev_priv) || HAS_PCH_LPT_H(dev_priv))
cpt_check_pch_fifo_underruns(crtc);
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6
Hi Sagar,
sorry for the delay, see below for my comments.
On Wed, 2015-11-04 at 15:34 +0530, Sagar Arun Kamble wrote:
> RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
> setup registers. If those are not setup Driver should not enable RC6.
> For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
> to know if BIOS has enabled HW/SW RC6.
> This will also enable user to control RC6 using BIOS settings alone.
> RC6 related instability can be avoided by disabling via BIOS settings
> till driver fixes it.
>
> RC6 setup is shared between BIOS and Driver. BIOS sets up subset of
> RC6 configuration registers. If those are not setup Driver should not
> enable RC6.
> For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
> to know if BIOS has enabled HW/SW RC6.
> This will also enable user to control RC6 using BIOS settings alone.
>
> v2: Had placed logic in gen8 function by mistake. Fixed it.
> Ensuring RPM is not enabled in case BIOS disabled RC6.
>
> v3: Need to disable RPM if RC6 is disabled due to BIOS settings. (Daniel)
> Runtime PM enabling happens before gen9_enable_rc6.
> Moved the updation of enable_rc6 parameter in intel_uncore_sanitize.
>
> Change-Id: If89518708e133be6b3c7c6f90869fb66224b7b87
> Signed-off-by: Sagar Arun Kamble
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_uncore.c | 27 +++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8942532..6ed3542 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6823,6 +6823,7 @@ enum skl_disp_power_wells {
> #define GEN6_RPDEUC 0xA084
> #define GEN6_RPDEUCSW0xA088
> #define GEN6_RC_STATE0xA094
> +#define RC6_STATE(1<<18)
> #define GEN6_RC1_WAKE_RATE_LIMIT 0xA098
> #define GEN6_RC6_WAKE_RATE_LIMIT 0xA09C
> #define GEN6_RC6pp_WAKE_RATE_LIMIT 0xA0A0
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index f0f97b2..bedb089 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -364,8 +364,35 @@ void intel_uncore_early_sanitize(struct drm_device *dev,
> bool restore_forcewake)
> i915_check_and_clear_faults(dev);
> }
>
> +static void sanitize_bios_rc6_setup(const struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + bool hw_rc6_enabled = false, sw_rc6_enabled = false;
> +
> + if (IS_BROXTON(dev)) {
> + /* Get forcewake during program sequence. Although the driver
> + * hasn't enabled a state yet where we need forcewake, BIOS may
> have.*/
> + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
Do we really need FW for reading? We don't program things here and
I915_READ() does take FW for the access itself.
> +
> + /* Check if BIOS has enabled HW/SW RC6. Only then enable RC6 */
> + hw_rc6_enabled = I915_READ(GEN6_RC_CONTROL) &
> + (GEN6_RC_CTL_RC6_ENABLE |
> GEN6_RC_CTL_HW_ENABLE);
> + sw_rc6_enabled = !(I915_READ(GEN6_RC_CONTROL) &
> GEN6_RC_CTL_HW_ENABLE)
> + && (I915_READ(GEN6_RC_STATE) &
> RC6_STATE);
Could you also add the following checks and bail out if anyone is
invalid?:
RC6LOCATION (0xd40) [0] should be 1.
RC6CTXBASE (0xd48) [31:4] should be non-zero. We could also check if it
falls within the WOPCM as it should.
PWRCTX_MAXCNT_RCSUNIT (0x2054),
PWRCTX_MAXCNT_VCSUNIT0 (0x12054),
PWRCTX_MAXCNT_BCSUNIT (0x22054),
PWRCTX_MAXCNT_VECSUNIT (0x1A054),
PWRCTX_MAXCNT_VCSUNIT1 (0x1C054) [19:0] should be greater than 1.
> +
> + intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> +
> + if (!hw_rc6_enabled && !sw_rc6_enabled) {
> + i915.enable_rc6 = 0;
> + DRM_INFO("RC6 disabled by BIOS\n");
> + }
> + }
> +}
> +
> void intel_uncore_sanitize(struct drm_device *dev)
> {
> + sanitize_bios_rc6_setup(dev);
> +
I'd prefer keeping this together with the RC6-sanitize code done for
other platforms in intel_init_gt_powersave(). You could also add a
broxton_check_pctx() similar to VLV/CHV that would perform the above
sanity checks any time intel_enable_gt_powersave() is called (in
addition to the check during intel_init_gt_powersave()).
> /* BIOS often leaves RC6 enabled, but disable it for hw init */
> intel_disable_gt_powersave(dev);
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] tests/gem_eio: Resilience against "hanging too fast"
On Thu, Nov 26, 2015 at 04:51:13PM +0100, Daniel Vetter wrote: > On Thu, Nov 26, 2015 at 03:34:05PM +, Chris Wilson wrote: > > On Thu, Nov 26, 2015 at 03:46:06PM +0100, Daniel Vetter wrote: > > > On Thu, Nov 26, 2015 at 12:59:37PM +, Chris Wilson wrote: > > > > On Thu, Nov 26, 2015 at 12:34:35PM +0100, Daniel Vetter wrote: > > > > > Since $debugfs/i915_wedged restores a wedged gpu by using a normal gpu > > > > > hang we need to be careful to not run into the "hanging too fast > > > > > check": > > > > > > > > > > - don't restore the ban period, but instead keep it at 0. > > > > > - make sure we idle the gpu fully before hanging it again (wait > > > > > subtest missted that). > > > > > > > > > > With this gem_eio works now reliable even when I don't run the > > > > > subtests individually. > > > > > > > > > > Of course it's a bit fishy that the default ctx gets blamed for > > > > > essentially doing nothing, but until that's figured out in upstream > > > > > it's better to make the test work for now. > > > > > > > > This used to be reliable. And just disabling all banning in the kernel > > > > forever more is silly. > > > > > > > > During igt_post_hang_ring: > > > > 1. we wait upon the hanging batch > > > > - this returns when hangcheck fires > > > > 2. reset the ban period to normal > > > > - this takes mutex_lock_interruptible and so must wait for the reset > > > >handler to run before it can make the change, > > > > - ergo the hanging batch never triggers a ban for itself. > > > > - (a subsequent nonsimulated GPU hang may trigger the ban though) > > > > > > This isn't where it dies. It dies when we do the echo 1 > i915_wedged. > > > > That is not where it dies. > > Well at least it happens after we start the hang recover from i915_wedged. > > > > I suspect quiescent_gpu or whatever is getting in the way, but I really > > > only > > > wanted to get things to run first. And since i915_wedged is a developer > > > feature, and it does work perfectly if you don't intend to reuse contexts > > > I didn't see any point in first trying to fix it up. > > > > > > So I still maintain that this is a good enough approach, at least if > > > there's no obvious fix in-flight already. > > > > No way. This is a kernel regression since 4.0, having just tested with > > v4.0 on snb/ivb/hsw. > > Ok, I didn't realize that. I figured since i915_wedged will return -EAGAIN > anyway when we are terminally wedged, and that seems to have been the case > ever since we started with reset_counter this has been broken forever. I > guess I missed something. The bug I see is SNB specific, and introduced between v4.0 and v4.1. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [iGVT-g] XenGT for PV guest
On 11/27/2015 01:10 AM, Oleksii Kurochko wrote: Hello all, Do you have any ideas about previously mentioned question? With best regards, Oleksii On Tue, Nov 24, 2015 at 6:48 PM, Oleksii Kurochko mailto:oleksii.kuroc...@globallogic.com>> wrote: Hi all, I am trying to enable XenGT for Android on board vtc1010 in PV mode. Used: - Intel® Atom™ processor E3827 - Xen 4.3.1 on branch "byt_experiment". - dom0: ubuntu 14-04 with linux vgt 3.11.6-vgt+ kernel version - domU: Android-IA 5.1 with 3.11.6-vgt+ (added Android configs) kernel version vgt was successfully started in dom0. vgt does not start in domU. After registration of pci dev in i915_init() there is no call of i915_pci_driver.probe(). Inte HD Graphics is on pci bus, but it is not passthrough to domU. When tried to passtrough it to domU than dom0 crashes in drm_framebuffer_remove(). More than that it is not my case because of intel hd graphics need to be working in dom0 and domU. So could U give advice how to probe i915 driver in domU? The difficult part may not be how to probe i915 driver, but how to implement all necessary MPT(Mediated Pass-Through) ops for PV guests. What reminds me right now is, how to trapp guest GTT without EPT support? I'm not familiar with PV, however, on my gut feelings there should be PV ops to be added, which should not be trivial. With best, Oleksii -- Thanks, Jike ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events
> > On Thu, 26 Nov 2015 16:58:09 +0100, > Ville Syrjälä wrote: > > > > On Thu, Nov 26, 2015 at 04:51:04PM +0100, Takashi Iwai wrote: > > > On Thu, 26 Nov 2015 16:43:23 +0100, > > > Ville Syrjälä wrote: > > > > > > > > On Thu, Nov 26, 2015 at 04:29:12PM +0100, David Henningsson wrote: > > > > > > > > > > > > > > > On 2015-11-26 16:23, Takashi Iwai wrote: > > > > > > On Thu, 26 Nov 2015 16:08:06 +0100, > > > > > > David Henningsson wrote: > > > > > >> > > > > > >> > > > > > >> > > > > > >> On 2015-11-26 10:24, Takashi Iwai wrote: > > > > > >>> On Thu, 26 Nov 2015 10:16:17 +0100, > > > > > >>> Zhang, Xiong Y wrote: > > > > > > > > > > > > > > > > On Thu, 26 Nov 2015 08:57:30 +0100, > > > > > > Zhang, Xiong Y wrote: > > > > > >> > > > > > > BTW, I have a patchset to avoid the audio h/w wakeup by a > new > > > > > > component ops to get ELD and connection states. It was > posted to > > > > > > alsa-devel shortly ago just as a reference, but this should > work well > > > > > > in such a case, too. The test patches are found in > test/hdmi-jack > > > > > > branch of my sound git tree. > > > > > >>> > > > > > >>> Did you try this branch (merge onto intel-test-nightly)? > > > > > >>> > > > > > >> [Zhang, Xiong Y] Yes, this branch could fix my issue. > > > > > > > > > > > > OK, good to hear. But this isn't for 4.4 or backport, as it's > > > > > > more > > > > > > radical changes. > > > > > > > > > > > > Could you check the patch below instead? This suppresses the > notifier > > > > > > handling during suspend. It's bad, but the hotplug should be > > > > > > still > > > > > > handled via normal unsol event, so it should keep working, good > enough > > > > > > as a stop gap. > > > > > > > > > > > > > > > > > > Takashi > > > > > > > > > > > > --- > > > > > > diff --git a/sound/pci/hda/patch_hdmi.c > b/sound/pci/hda/patch_hdmi.c > > > > > > index bdb6f226d006..f7c70e2ae65c 100644 > > > > > > --- a/sound/pci/hda/patch_hdmi.c > > > > > > +++ b/sound/pci/hda/patch_hdmi.c > > > > > > @@ -33,6 +33,7 @@ > > > > > >#include > > > > > >#include > > > > > >#include > > > > > > +#include > > > > > >#include > > > > > >#include > > > > > >#include > > > > > > @@ -2352,7 +2353,9 @@ static void intel_pin_eld_notify(void > *audio_ptr, int > > > > > > port) > > > > > > struct hda_codec *codec = audio_ptr; > > > > > > int pin_nid = port + 0x04; > > > > > > > > > > > > - check_presence_and_report(codec, pin_nid); > > > > > > + if (!atomic_read(&codec->core.in_pm) && > > > > > > + !pm_runtime_suspended(hda_codec_dev(codec))) > > > > > > + check_presence_and_report(codec, pin_nid); > > > > > >} > > > > > > > > > > > >static int patch_generic_hdmi(struct hda_codec *codec) > > > > > [Zhang, Xiong Y] this patch couldn't remove the error message. > So audio controller isn't in Runtime D3 after azx_suspend(). > > > > > >>> > > > > > >>> OK, then the problem isn't about the HD-audio driver but rather > i915 > > > > > >>> driver. As already mentioned, i915 driver shouldn't issue > eld_notify > > > > > >>> callback in the suspend code path. > > > > > >> > > > > > >> We don't have a complete drm log so I'm only speculating here; but > the > > > > > >> HDA log seems to indicate the power well is off when we try to talk > to > > > > > >> the HDA controller. That means either the i915 shut it down while > > > > > >> we > > > > > >> were holding a lock on it, or HDA tried to lock it and that didn't > > > > > >> make > > > > > >> it through; in which case the HDA side should handle an error from > > > > > >> get_power more gracefully...? > > > > > > > > > > > > My understanding is that it's triggered *during* i915 suspend. Then > > > > > > the path calls the HDA callback, and HDA controller tries to get > > > > > > power > > > > > > and proceeds as it has no idea that it's being shut off. > > > > > > > > > > Well; that can also be stopped by letting the get_power call return a > > > > > failure code in case i915 is trying to suspend itself. That seems more > > > > > robust to me, as it could potentially avoid other S3 races too...? > > > > > > > > > > > > > > > > > Unfortunately, neither get_power callback or the corresponding HDA > > > > > > code has a capability to check that state. So, changing / fixing > > > > > > this > > > > > > there would be nice but very hard. > > > > > > > > > > Surely the i915 driver has some "am_i_suspending" variable it can > > > > > check > > > > > in the get_power callback? > > > > > > > > I don't understand why you need to do anything special. When the eld > > > > notify happens during suspend, the hardware is still fully powered up, > > > > so it should just work(tm) as long as
